Posted: 28 Dec 2015 1:30 EST Last activity: 18 Apr 2016 6:02 EDT
"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.
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.
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.
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.
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?
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.
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.
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.
Posted: 5 years ago
Updated: 5 years ago
Posted: 15 Jan 2016 1:59 EST Updated: 15 Jan 2016 2:02 EST
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.
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.
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.