Multichannel case processor (MCP) framework purpose is to speed up implementation of Pega7 applications that interacts with user leveraging integration with third party communication channels. The only assumption for channel is that communication is of conversational type that is question - answer. Facebook Messenger, IVR Systems, SMS, Skype are examples of channels with question - answer communication and may be build base on MCP framework. Channels that deliver multi fields structural data (form) are not good candidates to integrate using MCP channel.
Main functionality of framework is to process business cases created in Pega7 platform. Additionally it allows to define commands (like simple text response or menu) which can produce answer for use request outside the case. Framework allow to define processors to analyze user input, and have build-in analyzer of user's intention detection (integration with Pega7 Natural Language Processing NLP). NLP analyzer gives possibility to analyze input and as result create appropriate case or call one of defined commands. Like most of frameworks it supports customization, there are some main components which can be implemented on application or channel layer - like custom commands, custom text analyzers or case processors.
The MCP framework operates on data model independent of channel's one so each channel implementation is responsible to translate its own data representation into common MCP model. Entire interaction using particular channel takes place in context of Interaction Case which is persisted from one request to another so it could be treated as user's session. Interaction case contains standard data for work objects and inbound and outbound messages of channel's conversation (MCP model), additionally it keeps history of conversation and contains data about interacting channel's user. Core of interaction case is defined in MCP framework itself but may be enhanced by channel implementation with additional channel or application specific properties. Those properties, that add channel or application context information, are available in entire processing. MCP framework exposes number of extension points (plugin) activities where this information may be used. Additional properties may also be needed in the end phase to create correspondent response to physical channel.
Diagram describes MCP framework as channel independent abstraction layer.
MCP processing could be divided into three phases:
Input analysis - inbound message is processed by chain of configured Text Analyzers in specified order
Command's execution - if inbound messages contains command to execute, the list of configured responses and case types are considered for execution using their name (keyword)
Work processing - if the message doesn't contain explicit command, next assignment (based on operator's worklist) is processed using available Case Processors (by default - Question based assignments)
The diagram beneath shows the phases of processing and the boundaries of the framework and what need be implemented by channel developer
In typical scenario conversation is initiated on channel client side by sending request to Pega7 end point that mainly will be HTTP/REST service. These types of service are defined globally in Pega7 so part of authentication process must be to determine with which Pega7 application we want to talk to.
The fundamental assumption is that every channel presents itself with unique identifier, that allow to lookup directly to proper configuration of channel. Pega7 application identifier is essential part of this configuration as well and this allow to switch to context of application.
The second responsibility of authentication process is to choose Pega7 operator. The build-in functionality of MCP framework uses context of authenticated user in many areas such as case processing, lookup worklist etc. However there is also possibility to override default functionality by implementing extension points and change mechanism of choosing work item to process etc., bearing in mind that MCP framework calls standard Pega7 API methods to finish assignment, create work and similar.
Interaction case is the work item within context entire conversation takes place, it contains standard data for work items as well as MCP related stuff like inbound and outbound messages. Context of this page has to be established by channel developer in the very beginning of interaction, then it passed as well known page through processing and it's primary page for almost all pieces of MCP internals. As other pieces in framework the Interaction case could be simply extended to provide additional properties specifically for different channels, it ensures that they will be available in entire flow. Interaction case as all Pega7 cases is persisted and could be reviewed at any time, it contains history of the whole conversation. It is possible to resolve this case using custom commands, manually or using build-in mechanism of inactivity timeout defined in configuration.
Page of interaction case is always (since successfully acquired) available as clipboard page of pyInteractionCase name.
Channel configuration defines how the interaction with particular channel instance occur. Runtime engine uses this definition to fetch and execute the list of Text Analyzers, match commands (responses and case types) and execute them with appropriate parameters. Additionally this configuration contains system responses where user is able to define how the engine will react on system events (like internal error) and all parameters needed to establish connection to external channel's service. Similarly to Interaction case it is possible to extend the configuration with attributes specific for particular channel type. Every channel implementation must have its own configuration class that inherit from Data-Channel-Configuration. MCP framework dynamically discover all classes derived from Data-Channel-Configuration and treat them as implementation of channels so this base class cannot be used to any other purposes.
Page of configuration is always (since sucessfully readed) available within the pyBotConfigname.
Commands (responses and case types)
Configuration allows to call command which is ment to be simple action to be launched as part of processing. Commands are spitted into two lists:
Case types - where you can configure which case should be created when the command is invoked. This list is a set of commands with CreateWork action described underneath.
Responses - where you can setup response to channel outside the case processing
Generally the command is a wrapper for different actions which gives them unique name treated as activation keyword. If some of command's name matches inbound's command the action underneath will be called during processing.
MCP action is part of every command, it enclosing process method and execution parameters (parameters can be defined in design time within channel config for each command's separately).
Framework allows to create custom channel's (available only for one channel's type) or app specific (for all channels) actions which will be dynamically fetched and displayed as possible option in responses list.
Text - simple text will be added to outbound messages
Menu - title with possible choices (options) will be added to outbound messages
Cancel - currently processed work will be canceled (withdrawn). Allows to define menu to be added to outbound messages
Restart - currently processed work will be canceled (withdrawn). New case will be created. Allows to define Text to be added to outbound messages
MCP framework give possibility to analyze user input by configuring a chain of Text Analyzers which are launched in defined order against interaction case (inbound message). The assumption is, this analysis will transform the inbound message or determine (detect) command to be invoked as the user's intention. The chain could be configured in two modes:
Simple - simplest match with basic NLP analysis (could be configured via EditIntents button or from response/caseType edit form)
Advanced - gives possibility to add multiple analyzers with different configurations, set their context of execution and specify order
Framework allows to create channel's or app specific text analyzer which will be dynamically fetched and displayed as possible option in advanced analyzers configuration.
Analyzers are launched in specified order until command is found, additionally it is possible in which situation particular analyzer should process the input (advanced mode):
Apply in context of a case - if checked, analyzer run if there's work to process (if assignment exists)
Apply outside of a case - if checked, analyzer run if there's no work to process (empty worklist)
(checking them both - it will analyze input ALWAYS)
Pega NLP generated - uses simplest Pega text analysis, it takes auto-generated taxonomy which allows user to define (inline) the text matches from response/case type configuration (or Edit Intents button)
Exact match - lookup whether text equals to on defined command's keyword (case insensitive matching)
Pega NLP - advanced Pega text analysis, gives possibility to set Pega Text Analyzer rule for runtime processing.
Engine of framework handles special situations which are not the intent of the end user and are not called explicitly by any action, such event is called System Response. User is able to configure how the outbound message should look like in case of such situation. Model underneath is the same as in standard command's but there's no possibility to add name(keyword) as these responses are set internally by engine.
Available system responses:
Welcome - used on very first interaction for particular user (where the user requests system first time)
No match - if there's no command detected and no case to process. System doesn't know what to do
Multiple matches - (for NLP analyzers) - if NLP analysis returned multiple matching words (limited to Text action as it will add returned matches as menu choices)
Internal error - If any error occurred
Case processing is part of MCP core, it allows to process standard Pega cases using inbound and outbound messages model. Framework introduces case processor component which is adapter between internal MCP model and specific assignment model (shape). Currently it supports only Question assignmnent shapes, other "background" processes like utilities etc. will work OOTB - only user's assignments are processed. Default behavior is based on operator worklist and first available assignment is taken into consideration as ongoing work.
Framework allows to create custom case processors which will be dynamically fetched and used in runtime processing. The system will browse all available case processors and use proper one for current assignment (chain of responsibility pattern).