"Please resubmit" message
When email sending occurs after work item was opened user gets system message: "Please resubmit" and is forced to refresh user form.
Forcing to refresh screen form leads to loss of data and causes significant business impact.
We expect that sending email shouldnt affect major business flow and such error messages shouldnt be thrown or at least user shouldnt be forced to refresh user form.
How to achieve expected behaviour?
Accepted Solution
Pegasystems Inc.
US
Andrey Kostikov wrote:
Hi, Ken.
Thank you for response.
I undrestand that it is probably correct behaviour. At least explainable.
Could you please describe how do you plan application design with optimistic\default locking, agents and other things?
What is your approach to avoid such situation?
When using Optimistic Locking, you have to be respectful of the end user, and look for ways to minimize the distraction of a stale form. One day when we offer auto-merge this will be less of an issue. Until then, you need to think about when will the end user likely be editing the case, and when will other users or agents. If the user is expected to be filling out a form for an assignment as soon as he lands on it, then any agents for the case shouldn't be scheduled to run within a reasonable time frame for the completion of that form. As a general rule, we recommend Default Locking if you are using service levels in particular.
Andrey Kostikov wrote:
Hi, Ken.
Thank you for response.
I undrestand that it is probably correct behaviour. At least explainable.
Could you please describe how do you plan application design with optimistic\default locking, agents and other things?
What is your approach to avoid such situation?
When using Optimistic Locking, you have to be respectful of the end user, and look for ways to minimize the distraction of a stale form. One day when we offer auto-merge this will be less of an issue. Until then, you need to think about when will the end user likely be editing the case, and when will other users or agents. If the user is expected to be filling out a form for an assignment as soon as he lands on it, then any agents for the case shouldn't be scheduled to run within a reasonable time frame for the completion of that form. As a general rule, we recommend Default Locking if you are using service levels in particular.
When you think of the user experience of a stale form - the system tells you that someone got there ahead of time - the user must copy all of his edits off into notepad, refresh the perform harness, and paste them back in. That is a pain, and it tells you that forms involved with Optimistic Locking should be short, unless there is certainty of no collisions. It also tells you that the fields in such a form should at least have a copy/paste option, rather than being full of dropdowns and radio buttons that must be manually rechosen.
Drew Piekarski, can you add anything to the best practices of working with optimistic locking?
Pegasystems Inc.
IN
Hi
How are you sending the email ? Is it part of a flow action or on click of a button on screen ?
Sberbank
RU
1) Create case
2) Create single assignment
3) Define SLA on assignment with goal (deadline) time = assignment ready + 30 seconds
4) Run case
5) Hold on assignment till email is received
6) Submit form
7) Get message
Pegasystems Inc.
IN
Hi
Thanks for the input.You have created a case and then wait for the 30 sec interval for the SLA to run. During this process you have not closed the assignment ,When your SLA works on an assignment it first acquires a lock on the assignment, performs the activity ( e.g sending emails ) and then release the lock.
This definitely modifies few of the work object information , so after the SLA finished its work, when you want to submit assignment
At this point if you want to work on the already open assignment , PRPC will ask you to refresh the page in order to make sure that the recent data are available in the page.
So this is expected behavior.
Pegasystems Inc.
IN
>>> so after the SLA finished its work, when you want to submit assignment. At this point if you want to work on the already open assignment , PRPC will ask you to refresh the page
- would it be convincing to attempt by adding a pre-condition when rule pzHasLock step to the method Obj-Refresh-And-Lock?
Please share your comments/observations, Thank you!
psahukaru
Pegasystems Inc.
IN
When you have assignment opened and SLA is trying to process the same assignment, SLA processing itself should fail (not able to acquire lock) unless you have optimistic locking configured.
Can you confirm if you have optimistic locking enabled for this case ?
If you have optimistic locking configured, which I am sure you have. Even Phani's solution might now work.
One other idea could be just configure a utility before that assignment to send email and put a wait time of 30 seconds before sending (Not wait shape, inside activity to send email).
If you use SLA agent it will get lock on work object for sure and will impact the refresh scenario in your case.
Or you can use a Periodic agent and QueueForAgent activity to run and send email.
Updated: 29 Dec 2015 3:08 EST
Sberbank
RU
Yes, I use optimistic locking.
Could you please explain in more detail Phani's solution and idea with periodic agent?
Scenario I wrote is just simple example.
We have real sla with goal and deadline times defined in dictionary.
Customer will enter lot of projects with passed deadline dates so error might be quite often which will be irritating for customer.
Pegasystems Inc.
IN
Hi All,
This is to inform you that I am handling this SR. Pankaj/Phani Can you please elaborate your solutions in detail?
Regards
Suruchi Gupta
Pegasystems Inc.
US
I'm not showing that there is an SR associated with this thread. Could you please reply with the SR number so that we may track it?
Thanks in advance!
Pegasystems Inc.
US
Andrey Kostikov wrote:
1) Create case
2) Create single assignment
3) Define SLA on assignment with goal (deadline) time = assignment ready + 30 seconds
4) Run case
5) Hold on assignment till email is received
6) Submit form
7) Get message
This is what you wrote. It doesn't make sense to define an SLA goal of 30 seconds. What human being can be expected to perform a task that fast? Clearly then, you are using an SLA agent just as a way of doing something in the background (even though by default emails already go to the background). But then you're asking the user to hold on the assignment!!!!
If the user is expected to wait, do the operation in the foreground.
Sberbank
RU
30 seconds is just example for test purposes.
In practice SLA depends on business date. Normally it will be future date like days or even months forward.
But test users enter random values like current datetime. Also as I mentioned before end user would like to enter some archived projects in system with passed deadline business dates.
1) So I am just curious, is there any workaround to avoid update case in these may be uncommon situiations? Or such behaviour is considered correct in current version of product?
2) Why does SLA agent update case?
3) Why does Mail agent update case?
Pegasystems Inc.
US
Andrey Kostikov wrote:
30 seconds is just example for test purposes.
In practice SLA depends on business date. Normally it will be future date like days or even months forward.
But test users enter random values like current datetime. Also as I mentioned before end user would like to enter some archived projects in system with passed deadline business dates.
1) So I am just curious, is there any workaround to avoid update case in these may be uncommon situiations? Or such behaviour is considered correct in current version of product?
2) Why does SLA agent update case?
3) Why does Mail agent update case?
If you are using 30 seconds just for testing purposes, then the user won't actually be filling out the next form. Make your test users aware that there is an inherent conflict in testing with too quick an sla time with optimistic locking and more forms to fill out.
To your numbered questions:
1) No 'workaround'; you've set the system up for a collision between the agent and the end user.
2) The SLA agent's activities have the case as their primary page, many of the actions involve changes to it. Besides urgency increases, there's advancing the flow, applying a data transform, etc.
3) We have this 'party notified' flag in the pxFlow page, and there's this 'corr summary' pagelist. Both of these need to be converted to declarative, so that they are set when used by running a report/looking at other data.
Andrey Kostikov wrote:
30 seconds is just example for test purposes.
In practice SLA depends on business date. Normally it will be future date like days or even months forward.
But test users enter random values like current datetime. Also as I mentioned before end user would like to enter some archived projects in system with passed deadline business dates.
1) So I am just curious, is there any workaround to avoid update case in these may be uncommon situiations? Or such behaviour is considered correct in current version of product?
2) Why does SLA agent update case?
3) Why does Mail agent update case?
If you are using 30 seconds just for testing purposes, then the user won't actually be filling out the next form. Make your test users aware that there is an inherent conflict in testing with too quick an sla time with optimistic locking and more forms to fill out.
To your numbered questions:
1) No 'workaround'; you've set the system up for a collision between the agent and the end user.
2) The SLA agent's activities have the case as their primary page, many of the actions involve changes to it. Besides urgency increases, there's advancing the flow, applying a data transform, etc.
3) We have this 'party notified' flag in the pxFlow page, and there's this 'corr summary' pagelist. Both of these need to be converted to declarative, so that they are set when used by running a report/looking at other data.
Sberbank
RU
Hi, Ken.
Thank you for response.
I undrestand that it is probably correct behaviour. At least explainable.
Could you please describe how do you plan application design with optimistic\default locking, agents and other things?
What is your approach to avoid such situation?
Pegasystems Inc.
IN
Hi Ken,
Good Afternoon
Hope you must be fine.
As diuscussed, could you please reply back to Andrey's reply.
Thanking you.
Suruchi Gupta
Accepted Solution
Pegasystems Inc.
US
Andrey Kostikov wrote:
Hi, Ken.
Thank you for response.
I undrestand that it is probably correct behaviour. At least explainable.
Could you please describe how do you plan application design with optimistic\default locking, agents and other things?
What is your approach to avoid such situation?
When using Optimistic Locking, you have to be respectful of the end user, and look for ways to minimize the distraction of a stale form. One day when we offer auto-merge this will be less of an issue. Until then, you need to think about when will the end user likely be editing the case, and when will other users or agents. If the user is expected to be filling out a form for an assignment as soon as he lands on it, then any agents for the case shouldn't be scheduled to run within a reasonable time frame for the completion of that form. As a general rule, we recommend Default Locking if you are using service levels in particular.
Andrey Kostikov wrote:
Hi, Ken.
Thank you for response.
I undrestand that it is probably correct behaviour. At least explainable.
Could you please describe how do you plan application design with optimistic\default locking, agents and other things?
What is your approach to avoid such situation?
When using Optimistic Locking, you have to be respectful of the end user, and look for ways to minimize the distraction of a stale form. One day when we offer auto-merge this will be less of an issue. Until then, you need to think about when will the end user likely be editing the case, and when will other users or agents. If the user is expected to be filling out a form for an assignment as soon as he lands on it, then any agents for the case shouldn't be scheduled to run within a reasonable time frame for the completion of that form. As a general rule, we recommend Default Locking if you are using service levels in particular.
When you think of the user experience of a stale form - the system tells you that someone got there ahead of time - the user must copy all of his edits off into notepad, refresh the perform harness, and paste them back in. That is a pain, and it tells you that forms involved with Optimistic Locking should be short, unless there is certainty of no collisions. It also tells you that the fields in such a form should at least have a copy/paste option, rather than being full of dropdowns and radio buttons that must be manually rechosen.
Drew Piekarski, can you add anything to the best practices of working with optimistic locking?
Pegasystems Inc.
IN
Hi Andrey, Good Morning!
>>>
1) Create case
2) Create single assignment
3) Define SLA on assignment with goal (deadline) time = assignment ready + 30 seconds
4) Run case
5) Hold on assignment till email is received
6) Submit form
7) Get message
>>>
- would it be convincing to invoke OOTB Work-.ResumeFlow on successful email delivery...?
Please share your thoughts/comments, Thank you!
psahukaru
- again, adding Obj-Refresh-And-Lock with precondition pzHasLock tries to steal the lock while advancing the flow.
- may be calling RefreshOnConflicts as post activity during the form submission (at exception scenarios) and reloading (ReOpen) the case to progress in the flow make sense?
Updated: 11 Jan 2016 3:23 EST
Sberbank
RU
Hi, Phani!
Sorry for delay in response, have been on holiday.
1) "pzHasLock" checks if passed work page is locked. In our case we use optimistic locking, so normally "pzHasLock" will always return FALSE.
2) RefreshOnConflicts just simply refreshes work item and stays on current assignment.
I am looking for some mechanism to ignore or suppress this error situation for end user and continue work with the next assignment.
May be there is completely different approach or solution to redesign processing of SLAs and emails in a way that it wont affect user's work?
I believe in a well thought-out system events such sending emails shouldnt lead to incomperehensible for end user messages.
Do you agree with me?
Pegasystems Inc.
IN
Hi Andrey, Good Morning!
- would it be convincing to invoke OOTB Work-.ResumeFlow on successful email delivery...?
Please share your thoughts/comments, Thank you!
psahukaru
Pegasystems Inc.
US
Andrey,
You mentioned you are using optimistic locking. Is that something that you need? The classic locking would prevent the SLA from firing until the user returned the lock. It sounds like that would meet your needs. Obviously, if you need optimistic locking for something else, then that would be a consideration, but if not, that would probably be the simplest solution.
Regards,
Mike
Pegasystems Inc.
IN
As I mentioned earlier as far as I understand only way to get around this would be to create the custom agent and then use Queue-For-Agent utility before SLA assignment.
In custom agent, we will not be taking a lock on the case since sending emails and attaching them to WO should not require any locking.
I will try to prepare a small prototype for the solution and post here soon.
Sberbank
RU
1) You suggest to reject using standard SLA rule? It will also lead to lot of rework.
Furthermore, it will force us to develop custom mechanism to update dates and color deadline tasks.
2) Are you sure that sending emails doesnt lead to update of work item?
I didnt checked it, but at least during sending email there some things that may cause update:
-CorrAttach whick attaches email to work object
-OnSend activity which has property sets on workobject
Pegasystems Inc.
IN
I was suggesting to keep the SLA rule and just for sending email use a custom advanced agent.
Attaching an attachment to a Work Object doesn't require a lock.
But you are right, OnSend actually writes data on work page and saves it.So even an advanced agent will not help.
Should have asked earlier but better late than never.
What is the exact use case of keeping the assignment open and waiting for an email? Is that email a kind of reminder?
Sberbank
RU
There SLAs and sending emails tied to some business dates.
In real project these days probably will be future dates. So problem will be relatively rare.
On the other hand during testing we got thise issue all the time, because testers enter current or past business dates.
Also customer probably will enter some old or archived project (with passed business dates) into system.
Pegasystems Inc.
US
I'm not sure I understand the problem this mesh discussion is about. Perhaps if someone could give a nice summary?
It is expected that if there are short SLAs involved, the user goes to the Confirm harness and ceases work on the case. Also keep in mind that depending upon the SLA settings, foreground users could find it a nuisance when they submit forms and are told it failed because 'the sla agent got there first'.
In the long term it is a goal of mine to make sure that both correspondence sending and creating an attachment do not require a lock on the case.
Pegasystems Inc.
IN
Hi Ken
Here is Andrey's problem summary.
A Case has optimistic locking configured. One of the assignment in that case, has short time SLA defined to send out an email. User is working on that assignment (a big form).
When he submits he is asked to refresh the form since SLA is already fired and got their first. Now only option with user is to Refresh and loose all data.
I was always assuming that sending attachments and emails doesn't require lock. But looks like sending correspondence does.
I agree with you, we need to make locking little smart in these cases.
Pegasystems
US
Hello,
Ken has clarified that as of today, a correspondence require locking, and that for the future he would like to remove that restriction.
Due to that restriction's existence today, I suggest that you consider Mike's suggestion to use regular locking instead of optimistic locking, since as you have already discovered and told us, if an SLA kicks in and corresponds while the user happens to be filling in their long form, they will be forced to refresh and lose the data (unless they tediously copy each field to somewhere else).
You responded to Mike by saying
>>> Currently we have a lot of logic tied to Optimistic locking.
>>> It would be difficult task to switch to Default locking.
I don't understand this. What is the difficulty in switching ? Perhaps you could explain this a bit.
Here within Pega, we have a an application that hundreds of employees use every day. That application includes both listeners to RECEIVE email for work objects, and SLA activities that SEND emails to the work object. We have chosen to use REGULAR locking because if we used optimistic locking, the user would lose data when they clicked SUBMIT, whenever the LISTENER or SLA activity happened to run during the time the user was composing their form for submission.
Hello,
Ken has clarified that as of today, a correspondence require locking, and that for the future he would like to remove that restriction.
Due to that restriction's existence today, I suggest that you consider Mike's suggestion to use regular locking instead of optimistic locking, since as you have already discovered and told us, if an SLA kicks in and corresponds while the user happens to be filling in their long form, they will be forced to refresh and lose the data (unless they tediously copy each field to somewhere else).
You responded to Mike by saying
>>> Currently we have a lot of logic tied to Optimistic locking.
>>> It would be difficult task to switch to Default locking.
I don't understand this. What is the difficulty in switching ? Perhaps you could explain this a bit.
Here within Pega, we have a an application that hundreds of employees use every day. That application includes both listeners to RECEIVE email for work objects, and SLA activities that SEND emails to the work object. We have chosen to use REGULAR locking because if we used optimistic locking, the user would lose data when they clicked SUBMIT, whenever the LISTENER or SLA activity happened to run during the time the user was composing their form for submission.
One thing I will mention is that in our Pega application, if the user takes too long in filling in their data, and hence the LISTENERS or SLA activities can't proceed because the user has the work locked, an email warning is sent directly to the user to remind them that the listener or SLA activity is being blocked from doing its job, so the user should unlock the work as soon as it is convenient to do so. If you take our advice and switch to regular locking, you may want to add this warning as well.
/Eric
Updated: 15 Jan 2016 2:02 EST
Sberbank
RU
Eric, thank you for clarification.
Its always interesting to get to know real experience.
We have integration via JMS.
Current data model is build in a way that data received is to be written directly to work object.
User after submitting request waits for response on the same form.
So in case of Default locking agent will be never able to update WO.
To implement Optimistic locking we will need to redesign data model and get this data out from work object.
Pegasystems Inc.
US
Andrey Kostikov wrote:
Eric, thank you for clarification.
Its always interesting to get to know real experience.
We have integration via JMS.
Current data model is build in a way that data received is to be written directly to work object.
User after submitting request waits for response on the same form.
So in case of Default locking agent will be never able to update WO.
To implement Optimistic locking we will need to redesign data model and get this data out from work object.
Waiting for a response on a PERFORM harness makes no sense. The reason a user is on a perform harness is because he is expected to fill out a form and submit it. Have them wait on a CONFIRM harness if you must.
Sberbank
RU
As I understand you suggest to do integration request after user submits current assignment.
We discussed it with analysts. The reason user stays on current assignment is that he probably would have to make another integration request if the first gets nothing or in case or typing error.
Anyway it's unlikely that we will do changes in this part for now.
Lets stick to topic.
Pegasystems Inc.
US
Don't send the email in the background then. The VerifySendCorr flow takes a BatchSend parameter; I don't quite remember how to alter that parameter but once we figure that out, set it to false. Have the email be sent as part of the flow action submit.
Pegasystems
US
Hello Andrey,
In the general case, all of the following are likely to be business requirements:
1) The interactive user's screen needs to exclusively lock the work
2) The SLA activity needs to lock the work
3) The user expects that when they click "submit" on their screen, their recent-typing will be saved and not have to be re-typed.
Even if we make some changes here at Pega to help with some of it, since we can't cover all the general situations, I suggest you design your code like this:
1) Use regular locking, not "optimistic" locking, since that way the user will be confident that during the few minutes it takes them to type in their screen data, no SLA will interfere. (Instead, a clashing SLA will merely try again in a few minutes).
2) Design your SLA's to do very quick amounts of work so the work isn't locked long.
3) After your user submits new screen data, don't leave the work locked long. This allows SLA's to run. If user puppy-guards a locked screen, sound and show a warning so they know they need to release the lock to allow the SLA to run.
/Eric
Pegasystems Inc.
IN
I yet didn't see the way to avoid that message.
I am also facing this issue now in my new app. Can anyone guide me how to stop that. I am using optimistic locking and don't have any SLA.