Capturing business exceptions in a flow

A ticket in a process flow marks a location or starting point for business exceptions that may arise at any point in a flow. When an external event, such as a cancellation, interrupts the planned progress of a work item through the process flow, the ticket marks the point in the flow where processing should resume whenever the ticket is activated. The scope of a raised ticket includes all flows on the current work item.

Standard tickets are available. For example, the SkipFlowStep ticket can be used in a process flow as the destination when part of the flow can be bypassed or skipped over. Withdraw can be used to mark processing that is to occur if the work item is withdrawn by its originator.

Use the Tickets gadget (Designer Studio> Process and Rules > Work Management > Tickets) to verify which tickets are in active use, and by which flows or activities, in the current application.

Include tickets and utility tasks to accommodate cancellations, rollbacks (sometimes called compensating transactions), errors, and similar exceptions.

To set or raise a ticket, you can:

• call an existing activity @baseclass.SetTicket
• select a flow action, as allowed by the flow, Work-.ActionSetTicket
• create an activity to execute the @baseclass.SetTicket method with the ticket name as a parameter

In Process Modeler, specific shapes have the ticket functionality built into the properties panel. The symbol appears on shapes that have an assigned ticket. Assigned ticket names appear beside this icon on the flow. Assigned ticket names appear beside this icon on the flow. The following shapes allow tickets:

Adding a ticket to the flow

The shapes listed above may have tickets assigned. On the Tickets section in a shape's Properties panel, complete the field according to the table below.

Example

Processing is connected to a ticket to respond to a business exception, error flow or event. For example, if a mortgage application is withdrawn after some, but not all, of the application processing is completed, a mortgage processing flow can:

• Include a ticket named Withdrawn on a utility shape that computes the fees due for work done so far, and any refund amount
• Follow the utility shape with another that produces correspondence, to alert all parties working on the mortgage that it was withdrawn
• Connect to external systems to back out (rollback) changes or void accounting entries as appropriate

Work Items with Covers

If a work item is covered, and its status becomes Resolved:

• The immediate parent cover is checked to see if the open cover count is zero. If the count is zero, the AllCoveredResolved ticket is raised on the cover. AllCoveredResolved is the only ticket that gets this special processing.
• If the flow processing of AllCoveredResolved on the immediate parent cover resolves this cover, then, cascading upward, its immediate parent cover is checked to see if the covered count is zero. If the count is zero, the AllCoveredResolved ticket is raised on the cover's cover, and the upward cascade continues.

Limits on looping

A flow execution can loop back to a task completed earlier, either through connector or a ticket. The system enforces maximum limits of 500 executions of a task (on a single work item), to detect and prevent infinite looping. In addition, a flow execution can be resumed (such as through a specific ticket) a maximum of 500 times. If necessary, you can adjust these limits by overriding standard System Settings rules Pega-ProCom.MaxFlowEnteredCount and Pega-ProCom.MaxFlowLoopCount

Open topic with navigation