Tickets Usage and Configurations in Pega
In this article, we will see how we can configure tickets in Pega and its use cases.
I will start with a story!! Once we friends went to an amusement park. That was a holiday and so It was quite busy out there and we were standing in a queue for more than an hour. We saw few people evade the long queue and went straight inside. Totally annoyed we checked and found that they booked tickets online. So, if you book ticket online, you can take a shortcut and jump straight inside 😊 ☹
I will give you a developer situation 😉. When there is a critical production ticket raised, what you will do?! You put all your works down and jump straight to the ticket right?!
What is ticket in Pega?
Ticket can be defined as an entry point in flow in certain situations.
We know that the flow processing always starts from the start shape and follows the path of connectors. But in some situations, you need to skip a few steps and connectors and jump direct to a certain step (shape).
The situation can be an error, exception case or any event (like child cases resolved, withdrawn etc)
Business scenario: Say XYZ is a banking organization with a main central branch and many local bank branches. They provide loans to customers and the central bank uses a Pega application to service the customer who falls into arrears.
I am going to break the business requirement into four use cases.
– The central bank uses the Pega application to treat the customer who fell into arrear by creating an arrear case.
– The central bank can treat the customers only after 60 day, so it should wait. Meanwhile a parallel process – local bank permission should be invoked to check if the customer can be treated from the local bank.
– If the central bank doesn’t hear from local bank for 60 days, then we should automatically end the local bank permission flow and start treating the customer in central bank.
– Similarly, if the local bank says it can treat the customer, then end the current process in the central bank.
Just like how team lead delegates the work to their team members. Team lead only involve if the tasks cannot be completed by their team members within the deadline.
Tip: whenever you hear any requirement, try to decimate it as small as possible. This can help you speeding up the development process 😊 I guarantee it works!
Different Use cases to implement tickets
Let’s start with implementing the first use case.
First use case: The central bank uses the Pega application to treat the customer who fell into arrear by creating an arrear case
For now, I am customizing the starter flow rule on Arrear class for testing purpose, so that I can create case and test straight away. The simple arrear case contains a simple assignment shape.
Second Use case: The central bank can treat the customers only after 60 days, so it should wait. Meanwhile a parallel process – local bank permission should be invoked to check if the customer can be treated from the local bank.
Step 1: Create a new flow rule for local bank permission. Just keep it very simple with a single assignment.
Step 2: Include the newly created Local bank permission flow as a spin off subprocess to the starter flow (parallel flow processing)
Make sure you check the spinoff flow for parallel processing.
Step 3: Include the 60 days wait shape after the spinoff parallel process.
Before implementing the third use case, test the steps by creating a new arrear case
Step 1: Run the starter flow and create a new case.
You will see a new case created and waits in the wait shape for 60 days.
In the open assignment you see the parallel process ‘LocalBankPermission’ invoked.
Step 2: Open the clipboard to check the pyWorkPage.pxFlow page group property.
You see there are 3 pagegroups on LocalBankPermission, pzInternalCaseFlow and pyStartCase.
pyStartCase is the main flow and LocalBankPermission is the parallel flow right.
One thing to note is pxFlow page group will be created for all the open flow rules and get removed automatically when the flow ends!
Let’s get back to the third use case.
Third use case: If the central bank doesn’t hear from the local bank for 60 days, then we should automatically end the local bank permission flow and start treating the customer in the central bank.
How to end the local bank permission flow automatically?
The answer is by raising the ticket.
How to create a new ticket?
Ticket rule belongs to Process category
Step 1: Create a new ticket rule Records -> Process -> Ticket -> Create new
Step 2: There is no configuration in the ticket rule. Only the name is enough.
Now we created a new ticket.
Where can we refer the ticket?
Tickets can be referenced in almost all of the shapes in the flow rule. By referring the ticket in the flow shape, it provides an entry point for a jump from any other point.
In our use case, we need to end the local bank permission flow after 60 days waiting. So you know in which shape you need to refer the ticket 😊 – Yeah its end shape, so that you can end the flow
Double on the end shape in the local bank permission flow.
Specify the newly created ticket name – EndPermission
You will see the ticket indicator in the end shape. So you have successfully specified the ticket.
Note: You can always specify more than one ticket in a single flow shape
The next step is you need to conditionally raise the ticket ( JUMP statement)
How to raise a ticket?
There are two ways to raise a ticket.
a) Obj-Set-Tickets method – You can use the method in the activity step to raise a ticket. The method accepts the ticket name as the parameter.
b) Pega API activity – SetTicket – This accepts ticket name as the parameter.
In the flow rule, we can use the utility shape and call the activity – SetTicket by passing the ticket name as the parameter – EndPermission.
Add a new utility shape after the wait shape. So after waiting for 60 days in the wait shape, flow automatically moves to the next utility shape and the ticket gets raised.
Save the flow rule.
At which context do we need to raise a ticket?
Usually, we raise a ticket at the case context. Primarily on the work page (pyWorkPage or pyWorkCover)
So technically when a ticket is raised for a case, primarily on the case workpage as a step page, Pega engine checks if the ticket is specified on any of the opened flows in the case using the page group
pyWorkPage.pxFlow or pyWorkCover.pxFlow. If it is specified, then it moves the flow rule to the specified ticket shape.
Now save both the flows.
Time to test the ticket raising 😊
Step 1: Create a new arrear case by running the pyStartCase.
The case stays in the wait shape.
Step 2: Start the tracer and click continue.
Note: You need to allow the continue option in the wait shape
In the tracer, you will the activity – FlowTicketEvaluate is responsible for evaluating the raised ticket in all the open flows in the case.
Step 3: Open the activity – FlowTicketEvaluate. You will see the Java step performing the evaluation on the opened flows.
Step 4: Now check the clipboard of the case. You will see the LocalBankPermission flow has because eof the raised ticket and hence it is automatically removed from the pxFlow page group.
Fourth use case: Similarly, if the local bank says it can treat the customer, then end the current arrear process in the central bank.
This can also be implemented using setting tickets and raising tickets.
Just follow the steps
a) Create a new ticket rule – EndArrearProcess
b) Set the ticket in the main flow end shape
c) Raise the ticket in the local bank permission flow.
You can test this on your own.
Important note: Ticket is not restricted that you can jump only forward! You can also jump backward.
What are the standard tickets used by Pega?
There are few standard tickets, the engine automatically raises on certain events or exceptions like resolve, withdraw etc
- Status-Resolved – Whenever a case is resolved, pega raises this ticket.
- Withdraw – Whenever a case is withdrawn
- AllCoveredResolved – This ticket is raised when all the child cases are resolved.
So, using the above tickets, you can jump to any shape in the flow by specifying the standard tickets in the right shapes, based on the events
Remember, Pega automatically raises these tickets! Do not worry about raising this manually!
Things to remember
– Ticket is an exact implementation of JUMP or GOTO statements.
– You can jump to any shape in the flow rule, either forward or backward.
– Almost all the shapes in the flow supports associating tickets.
– Tickets can be raised by API activity – SetTicket or by the activity method – Obj-Set-Tickets
– Once a ticket is raised, pega engines checks if the ticket is associated with any of the open flow shapes within the case. If yes, the flow jumps to the ticket shape.
With the improvements in case management, the usage of tickets is limited to a greater extent.
Ticket usage can now be replaced with change stage utilities in case management.
