Other background processing options

Use listeners for email, file, or inbound network requests or messages. In a high-availability environment, listeners are distributed across hosts and Pega Platform servers by using node types to assure redundancy.

File listener

Use a file listener with a file service to import and process files from another system or that have been created by application users. For example, you can import data that is used to create a work object.

The file listener monitors the file directory. When files match the pattern that 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 parse rule to open and read the file, evaluate each input record, divide the record into fields, and then write the fields to the clipboard, and a service activity processes the data.

Email listener

Email listeners provide the Pega Platform with the information it needs to route incoming email messages to an email service rule (Rule-Service-Email rule type). They identify the Listener, the email account name, the name of the mail folder to monitor, the message format of the incoming messages, which email service rule to route messages to, and so on.

When an email listener routes a message with files attached to it, the listener creates a page named pyAttachmentPage (of class Data-ServiceMessage) and puts the file(s) on that page, using the properties pyAttachNames and pyAttachValues. When you use the Email Wizard to configure inbound email, the generated service activity is configured to extract files from the pyAttachmentPage and attach them to the work item as work item attachments.

JMS listeners provide 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 rule type). A JMS listener or JMS MDB listener data instance specifies which queue or topic contains the messages to be consumed and which JMS service rule(s) will process the messages.

A service-level agreement establishes a work completion deadline. Organizations often establish SLA to enforce on-time performance. These obligations range from informal response-time promises to negotiated contracts.

An SLA defines intervals of time that are used to standardize how you resolve work in your application. You can apply a service-level agreement to cases, stages, steps, flows, and assignments.

Using SLAs is a viable alternative to using an agent in some situations. An SLA escalation activity provides a method for you to invoke agent functionality without creating a new agent. 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.

An SLA must always be initiated in the context of a case. Any delay in triggering an SLA impacts the timeliness of executing the escalation activity. It should not be used for polling or periodic update situations.

The SLA Assignment Ready setting allows 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 to the assignment through a worklist or workbasket.

The Wait shape provides a viable solution in place of creating a new agent or using an SLA. The Wait shape is applicable against only 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 that are applied against a case represent the most suitable use case for the Wait shape. The desired case functionality at the designated time or status follows the Wait shape execution.

In the FSG Booking application, a good example of Timer Wait Shape is desirable in a loop-back polling situation where a user may want to have an operation executed immediately within the loop-back. In this example, a user may want to poll for the current weather forecast instead of waiting for the next automated retrieval to occur. 

Question: As part of an underwriting process, the application must generate a risk factor for a loan and insert the risk factor into the Loan case. The risk factor generation is an intensive calculation that requires several minutes to run. The calculation slows down the environment. You would like to have all risk factor calculations run automatically between 10:00 PM, and 6:00 AM to avoid the slowdown during daytime working hours. Design a solution to support this.

Answer: Use a delayed dedicated queue processor. Set the DateTime for processing to 10:00 PM. The case waits for the queue processor to resume the flow for the next processing.

If enabled on other nodes, it can take advantage of other claims processing queue processors, reducing the time it takes to stop process all of the loan risk assessments.

Question: You need to automate a claim adjudication process in which files containing claims are parsed, verified, adjudicated. Claims which pass those initial steps are automatically created for further processing. A single file containing up to 1,000 claims is received daily before 5:00 PM. Claim verification is simple and takes a few milliseconds. Still, claim adjudication might take up to five minutes.

Answer: In an activity, invoke the Queue-For-Processing method against each claim.

Using the File service activity only to verify claims and then offload the task to the queue processor is preferred because it does not significantly impact the intake process. It can also take advantage of multinode and threading processing if available. Furthermore, the modular design of the tasks would allow for reuse and extensibility if required in the future. However, using the same file service activity for claim adjudication impacts the time required to process the file. Processing is only available on a single node, and there is little control over the time frame while the file service runs. Extensibility and error handling might also be more challenging.

Consideration must be given to the time that it takes a queue processor requires to complete the task. For example, the time required to process the claims by a queue processor is 5,000 minutes (83.33 hours); this is not suitable for a single queue processor running on a single node to complete the task. A system with the queue processor enabled on multiple nodes with multiple threads could perform the off-hours task. An alternative solution is to split the file into smaller parts, which are then scheduled for different queue processors (assuming there is enough CPU available for each Queue processor to perform its task).

Question: ABC Company is a distributor of discount wines and uses Pega Platform for order tracking. There are up to 100 orders each day. There are up to 40 different line items in each order that specify the product and quantity. Up to 5,000 varieties of wines continuously change over time as new wines are added to and dropped from the list. ABC Company wants to extend the functionality of the order tracking application to determine recent hot-selling items by recording the top 10 items ordered by volume each day. This information is populated in a table and used to ease historical reporting.

Answer: Use job schedulers, which runs after the close of business each day, and it performs the following tasks:

• Opens all order cases for that day and tabulates the order volume for each item type.
• Determines the top 10 items ordered and records these in the historical reporting table.

The activity should leverage a report to easily retrieve and sort the number of items ordered in a day. When recording values in the historical table, include a commit and error handling step in the activity.