Skip to main content


         This documentation site is for previous versions. Visit our new documentation site for current releases.      
 

This content has been archived and is no longer being updated.

Links may not function; however, this content may be relevant to outdated versions of the product.

Interaction API components

Updated on March 11, 2021

The Interaction API includes multiple default components under the Data-Decision-Request and Data-Decision-Response classes.

These components include the pyInteractionDF data flow, decision strategies, decision tables, and the default pyInteractionTA text analyzer. You can extend these rules to adjust the API to your business needs. For more information, see Extending Interaction API.

The Data-Decision-Request class contains the rules to handle the interaction input. These rules are combined into the pyInteractionDF data flow that drives the Interaction API. This class has the following data model:

Data-Decision-Request data model

Property nameModeString type
pyTextSingle valueText
pySubjectIDSingle valueText
pyDecisionIDSingle valueText
pyChannelSingle valueIdentifier

The Data-Decision-Response class contains the rules to handle the interaction output, for example, the outcome of natural language processing and decision results. This class has the following data model:

Data-Decision-Response data model

Property nameModeString type
pySubjectIDSingle valueText
pyStatusSingle valueText
pyDecisionIDSingle valueText
pyNLPOutcomePagePage
pyDecisionResultsPage ListPage List

The strategy outcome is captured in the pyDecisionResult property that belongs to the Data-pxStrategyResult class.

pyInteractionDF data flow

The pyInteractionDF data flow performs natural language processing (NLP) through the referenced text analyzer and feeds the outcome to the interaction strategy. When the data is processed, the data flow generates a response as part of the pyNLPOutcome property on the Data-pxStrategyResult page. In addition, the interaction results are recorded as part of the interaction history.

See the following figure for reference:

pyInteractionDF configuration
The components of the pyInteractionDF data flow and the connections between them.

The pyInteractionDF data flow is customizable and you can adjust its configuration to your business needs. To prevent the interaction history size from becoming too large, the data flow checks whether the record is a result of a simulation run. If true, the data flow prevents the simulation records from being saved in the interaction history.

Next, the data flow filters out all entities. As a result of natural language processing, each record becomes associated with a single value for sentiment (that is, the opinion that is expressed, for example, positive, negative, or neutral) and topic (that is, the talking point). However, the text analyzer can detect multiple entities in each record. Common examples include names of people, emails, postal codes, names of companies, products, and so on. Because of that, such records as emails can contain multiple entities. Therefore, avoid saving entities in the interaction history to prevent any system issues that could be caused by an increased interaction history size.

Decision strategies

The pyInteractionStrategy is the top-level decision strategy that is called from the pyInteractionDF data flow. This strategy references the following substrategies:

pyConvertNLPOutcome
This strategy integrates the NLP outcome from the text analyzer that is referenced in the pyInteractionDF data flow with other next-best-action components. As a result of this strategy, the detected topics and entities are put into the pxStrategyResult class.
pyGetActionStrategy
This strategy initiates a case type, based on the mapping defined in the pyGetActionFromIVAConfig decision table.
pyGetBestPropositions
This strategy presents the next best action, based on natural language processing. You can extend this strategy by importing channel-specific propositions or referencing any of your existing strategies to provide the next best action.

The following figure provides an overview of the strategy structure within the Interaction API:

Interaction API strategies
A flowchart showing the relations between the decision strategies within the Interaction API.

Decision table

The pyGetActionStrategy is a strategy that includes the pyGetActionFromIVAConfig decision table. You can use this decision table to map text analyzer topics from the channel configuration to case types, as shown in the following example:

A sample mapping between topics and NLPSample cases
A decision table in Pega that maps a change address topic to a specific case type.

The Command column contains the topics to be detected by the text analyzer. The Return column contains case types names to initiate when the corresponding topic is detected. The NO_COMMAND_FOUND action is returned when no topics that are listed in the decision table were detected. Depending on your business needs, you can customize the pyGetActionStrategy strategy to take action when no topic is detected, for example, by presenting a proposition.

Interaction taxonomy

The Interaction taxonomy contains an empty rule-based topic detection model. Populate this model with your topic-keyword configuration or override this model, based on your channel configuration. For more information about how to create a topic detection model, see:

Text analyzer

The Interaction API contains a default pyInteractionTA text analyzer rule. You can override this rule through the channel configuration menu to provide channel-specific treatment. This text analyzer rule supports sentiment analysis, topic detection, and text categorization. By default, the pyInteractionTA text analyzer rule performs email parsing. The following figure shows the pyInteractionTA text analyzer configuration in the pyInteractionDF data flow:

Parsing emails in Interaction API
A configuration table with email parsing settings.

When email is the conversational channel, the pxEmailParser text extraction rule identifies such email components as signature, greeting, body, and disclaimer. You can choose what type of analysis to perform on each email component, depending on your business needs, as shown in the preceding example.

Have a question? Get answers now.

Visit the Support Center to ask questions, engage in discussions, share ideas, and help others.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best.

Pega.com is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us