a js runs on a periodic basis and inside its activity it fetches from a connect rest and updates the case now if the case it has to update is already locked how to handle this situation,the case data should not be lost
A jobscheduler runs on a periodic basis and inside its activity it fetches from a connect rest and updates the case now if the case it has to update is already locked how to handle this situation,the case data should not be lost
Accepted Solution
Updated: 19 Jun 2024 13:43 EDT
Maantic Inc
IN
If you're using optimistic locking, then the case data will be updated and the user who's locked the case at that time will receive a notification to refresh as the case has been updated. This part Pega handles automatically but the drawback is that the user's current changes would be overridden.
If you're using default locking, then before updating the case you need to add an exception handling to queue the process unless if a lock is not available. During the queue process again you need to check the availability of lock, if still there's an issue then you need to save the data onto a table from which another retry mechanism can be created.
Cognizant
IN
@SohamM95 " During the queue process again you need to check the availability of lock, if still there's an issue then you need to save the data onto a table from which another retry mechanism can be created."-what should be the logic to configure this?like how to check if the lock is there and again add it to a table and configure retry mechanism?
Maantic Inc
IN
You need to check if the lock for the work object exists in the pr_sys_locks table. If yes then you can maybe set a flag. Use that flag to check the table later as a retry mechanism.
HCL
NL
@TanyaS58 in the after steps of connect rest and before updating the case , did you try call workUnlock and update the data.
the concept used to be in this situation seems to be aquiring the lock on the case explicitly and release by commit.
TSPI
IN
When ever lock failed use Queprocessor for processing that item or Case, you can mention retry attemps with 30 minutes initervals. You can reuse same connector to fetch the details and include same logic in queue processor activity. Queue processor adds benefit when it fails we can view the reason for failure.
Always recommended to use Queue processor with Job schedulers to track the record failed to process via job scheduler.
Pegasystems Inc.
CA
It's preferred to go with the default locking in this particular scenario so that the case data won't be lost when the job scheduler acquires the lock on that particular case. The user will receive an error when he tries to open the same case.
In case of optimistic locking, the case data will lost because both can act in parallel, whoever submits the data first will be saved and other user have to refresh and update the data (during the refresh the case info will be lost entered by the other user)
I hope this helps!