Other background processing options

Listeners are background processes in Pega Platform that wait for inbound network requests or messages. In a high-availability environment, listeners should be distributed across hosts and Pega Platform servers by using node types to assure redundancy.
The listeners available in Pega Platform are:

• Email
• File
• Java Message Service (JMS)
• Message Queue for IBM Websphere (MQ)

JMS and MQ Listeners are available only when Pega Platform is deployed as a Web application. The JMS MDB Listener is deprecated and should be replaced with the JMS Listener.
To effectively use node classification, you must associate listeners with node types so that only nodes with this node type assignment process the listener work requests.
Listeners are managed from Admin Studio. You can Start, Stop, Trace, View details, and Restart a listener from Admin Studio.

Email listeners provide Pega Platform with the information it needs to route incoming email messages to an email service rule (Rule-Service-Email). Email listener is configured with the email account name, the name of the mail folder to monitor, the message format of the incoming messages, and the email service rule to which to route the messages.

Email Listeners can be created manually from Dev Studio and App Studio. As a best practice, create these Configurations in App Studio. However, Email Listeners are automatically generated with certain Configurations, for example, creating an Email Channel or enabling Case Creation by email. Email Listeners can be configured to run on all Nodes or can be configured to run on specific Nodes.

When an Email Listener routes a message with attached files, the listener creates a pyAttachmentPage in the Data-ServiceMessage Class and puts the files on that page by using the pyAttachNames and pyAttachValues properties. When you use the Email wizard to configure inbound email, the system configures the generated Service Activity to extract files from the pyAttachmentPage and attach them to the Work Item as Work Item Attachments.

Best practice is to configure one Email Listener to monitor an email account. Having multiple listeners to monitor the same inbox can result in throttling and inconsistent results.
 

Use a File Listener with a File Service to import and process files from another system or created by application users. The File Listener monitors the file directory. When files that match the pattern the File Listener is listening for arrive, the listener moves the files into the work_<name of listener> directory and calls the File Service. The File Service uses a Parsing Rule to open and read the file, evaluates each input record, divides the record into Fields, and then writes the Fields to the Clipboard. 
A Service Activity called by the File Service rule processes the data. Using File Listener, you can import data that is used to create a case instance or data instance. File Listeners can have pre and post-operation activities defined to handle the required business actions.

The most common use case is to import a CSV file and map the properties to the fields. The other use cases are processing XML, JSON, and Structured files.

Best practices in using file listener
Improve the resiliency of your File Listeners by observing best practices for file processing:

• Prevent processing failures caused by partially written files by using different file names or extensions that do not match with the File Listener source name.
• Prevent redundant file processing in multi-node environments by configuring temporary file locking and duplicate file name handling.
• Automate error recovery for intermittent processing failures.
• Process records from very large, delimited files in small batches.
• Reduce the risk of data loss by streamlining file-processing Activities
   

The JMS Listener provides Pega Platform with the information it needs to route Java Message Service (JMS) messages from a specific Topic or Queue to a Pega Platform JMS Service (Rule-Service-JMS). A JMS Listener or JMS MDB Listener data instance specifies which Queue or Topic contains the messages to consume and which JMS Service rules process the messages.

JMS Listeners can be implemented in one of two ways:

• When your system is deployed as a Web Application, the Listener runs as a Java thread that is created when the system starts. The Listener waits for incoming messages on the JMS Destination (Queue or Topic). At regular intervals (as specified on the Listener form), the Listener checks to see if the system issued a request for it to stop running. If your system is deployed as a Web Application, configure JMS Listeners with this JMS Listener.
• When your system is deployed as an Enterprise Application, the Listener is a Message-Driven Bean (MDB) deployed inside your PegaRULES Application. The MDB routes messages to the JMS Service rule.
   

MQ listeners provide the information needed to route WebSphere MQ messages from a specific queue to an MQ service rule. An MQ listener specifies which queue contains the messages to be consumed and which MQ service rules process the messages.

You can use MQ listeners with MQ services only when Pega Platform is deployed as a Web application. When Pega Platform is deployed as an enterprise application, you use a message-driven bean (MDB) as the listener for message-based services — that is, JMS and MQ. Although you can use WebSphere MQ as a JMS service provider, use only JMS MDB listeners with JMS service rules, rather than MQ listeners with MQ services, when Pega Platform is deployed as an enterprise application.
Unlike other listeners, you cannot manage JMS MQ listeners from Admin Studio. You can manage JMS MQ listeners only through the local Admin Console.

A Service-Level Agreement (SLA) establishes a Work Completion deadline. Organizations often establish SLAs to enforce on-time performance. These obligations range from informal response-time promises to negotiated contracts.

SLAs define the intervals of time that standardize how you resolve Work in your application. You can apply a Service-Level Agreement to Cases, Stages, Steps, Approval Steps, Flows, and Assignments. By enforcing Service-Level Agreements and implementing escalation Actions, you enforce timely resolution of Cases.
Using SLAs is a viable alternative to using an Agent in some situations. You can invoke Agent functionality without creating a new Agent with an SLA escalation Activity. For example, if you need to provide a solution to conditionally add a Subcase at a specific time in the future, then adding a Parallel Step in the main Case incorporating an Assignment with an SLA and escalation Activity can perform this action.

Pega Platform can initiate an SLA in the context of a Case only. Any delay in triggering an SLA impacts the timeliness of executing the escalation Activity. Do not use SLAs for polling or periodic update situations.

The Assignment Ready setting of an SLA enables you to control when the Assignment is ready to be processed by the SLA Agent. For example, you can create an Assignment today but configure it to process tomorrow. An Operator can still access the Assignment if there is direct access through a Worklist or Workbasket
Pega Platform supports the following ways of Background Processing for SLAs:

• By default, the system uses the Agent's infrastructure to process the SLA items. The Class in which the system stores items for Agent processing of SLAs is System-Queue-ServiceLevel.
• A Queue Processor, for better scalability, ease of use, and faster Background Processing, you can enable a Queue Processor for Background Processing of SLAs in your application. The Class that the system uses to store items for the Queue Processor processing of SLAs is System-Message-QueueProcessor-DelayedItem.

Wait shapes provide a viable solution in place of creating a new Agent or using an SLA. The Wait shape is applicable only in a Case that is in a Flow Step and waits for a single event (Timed or Case Status), before it allows the Case to advance. Single-event triggers in a Case represent the most suitable use case for the Wait Shape. The desired Case functionality occurs when the Wait shape runs at the designated time or status.

Wait shape pause-and-resume processes when a Case meets the conditions that you define. When you create dependencies between your Cases, the ability to pause processes can facilitate the resolution of complex Cases that require other processes to end.

The following are possible Wait scenarios in an Application run:

• Wait until all Child Cases reach a resolution
• Wait until one or all Child Cases reach a resolution
• Wait until one or all Child Cases reach a specific Status
• Wait until a set amount of time passes
• Wait until a specific date or time

Pega Platform provides a configuration option where Case Workers can cancel the wait conditions and continue processing a Case.

Check your knowledge with the following interaction: