When assignment is being worked upon by user and SLA deadline is met what should be the ideal behavior?
When an assignment is being performed and SLA deadline is met, since the lock can not be acquired SLA escalation action is not fired. Even if we make the locking strategy optimistic, experience is not seemless.
What should be the ideal behavior?
**Moderation Team has archived post**
This post has been archived for educational purposes. Contents and links will no longer be updated. If you have the same/similar question, please write a new post.
Pegasystems Inc.
US
Depends what you want your escalation activity to do.
A case lock is not truly necessary for certain actions to be performed - for example send a notify email.
You could spin off an email-sending subcase that does not lock its cover.
The email would be configured as Attach & Hold until sent by an SLA.
Pegasystems Inc.
IN
Pegasystems Inc.
US
If performing the escalation at a specific time is a higher priority than interrupting the current user then optimistic locking can be used.
Allianz Germany
DE
Would Optimistic Locking also work between Batch Users (like SLA) and Operators ? I was told sometime back that the SLA is unable to handle situation when an Operator (Application User) makes changes to an assignment in case of Optimistic Locking. It looks like Optimistic locking is geared more towards multiple Operators than between Batch User and Application User .
Pegasystems Inc.
US
When a case has been optimistically updated, by either a human operator or an SLA, extra care is taken to inform other human operators that the state of the case has changed.
The other human operator is given the opportunity to save, somewhere else, browser-resident "dirty" edits and unsaved Clipboard pages before refreshing the case.
An SLA does not have any notion of a "browser" but it can accumulate unsaved data on the Clipboard before attempting a Save. If a human operator were to have updated a case prior to the SLA attempting a Save, one would think an exception would be thrown resulting in the data not being saved.
To test this an SLA activity or, better a Standard Agent activity, could be defined that outputs a log message, then sleeps for a long time, then attempts to update the case from which the Standard Agent was queued. While the Standard Agent is sleeping, a human could update the case. My suspicion is that the Standard Agent activity would fail.
Pegasystems Inc.
US
Having an agent sleep for a long time is poor practice. A Use Case for a batch requestor "stealing" an assignment from a user is when an absolute deadline has been reached and the case absolutely must move forward.
- Suppose a deadline is imposed on comment submittal regarding a proposal. Any user in the process of the entering a comment during the deadline would see the assignment disappear due to the assignment's SLA invoking Resume Flow.
- Another scenario is an auction. The highest bidder at the time the deadline is reached is the one who is awarded the item.
Verizon
IN
Hi Pedel,
Thank you for the quick response.
I would like to know in implementation standpoint as well. It seems we can use only Agent in this scenario. Is there anyway we can use SLA to handle this ?
Thanks!
-Rajasri
Pegasystems Inc.
US
SLAs are Standard Agent-based. An SLA queues System-Queue-ServiceLevel instances as opposed to System-Queue-DefaultEntry instances. With optimistic locking, when an SLA's Deadline is reached, it is free to invoke Resume Flow or pxChangeStage as an escalation action regardless whether the case was opened in a Perform harness by a Browser Requestor.
Cigna
US
Hi Pedel,
Imagine in a multi node environment I configure an Advanced Agent to update some property on all WOs of a particular type. Case Type for this WO has Optimistic locking enabled. What will happen if a particular WO is being updated by 2 or more BATCH requestors on different nodes?
Also if BROWSER and BATCH requestor open the case at same point of time but Browser requestor saves the instances first; when AGENT activity finishes its execution, will the Batch requestor experience an exception? If so, how to handle?
Please share your thoughts!!
Kaushal
Pegasystems Inc.
US
Bear in mind that a BROWSER requestor interacts with the server completely differently than a BATCH requestor.
A BROWSER requestor uses the HTTP stateless protocol which is request/response-based. Similar to a JSESSIONID cookie being returned in a response, the last time that a case was updated can be returned as is done with the Pega API where an "ETag" is returned in the response header. When a subsequent attempt is made to update the case using a PUT, the previous ETag value must be used to populate the "If-Match" request header value. When the server receives the PUT request and the "If-Match" does not match the ETag value it would return had the request been a GET, an error is returned.
A BATCH requestor runs on the server. Unless you implement something similar to a request/response ETag/If-Match error check within the BATCH requestor's Activity there is no reason for it to throw an exception.