Question
Capgemini
CA
Last activity: 20 Jul 2019 17:42 EDT
pzTransactionId not updated after pega.u.d.asyncRequest which calls DoSave activity
We are trying to achieve auto safe feature, which would be responsible to Save user in progress data every few mins if the page is stale.
Below is the code I am using. MyActivity calls DoSave activity. Which means a commit is performed and new transaction id is generated.
The first call is successful, however subsequent calls are not. Because the new transaction id is not update on client UI.
This is a high priority client requirement. Any advise on how to resolve this would be greatly appreciated!!
setInterval(function(){
InitiateAutoSave();
}, 60000);
function InitiateAutoSave()
{
if(window.parent.ValStudioDirtyCheck==true)
{
var callback = {success: SuccessSave, failure: FailureSave};
var oSafeUrl = null;
var postData = "";
oSafeUrl = SafeURL_createFromURL("pyActivity=MyActivity&pzPrimaryPageName=pyWorkPage");
pega.u.d.asyncRequest('POST',oSafeUrl,callback,postData);
}
}
***Edited by Moderator Marissa to update platform capability tags; update SR Details****
Pegasystems Inc.
IN
Hello,
Please have a look at the below article:
https://collaborate.pega.com/question/ability-auto-save-open-forms
Capgemini
CA
Hi,
I did take this as reference for implementation.
However only first call made is successful, rest all subsequent calls does not save the updated values from UI.
I see that the latest values from UI are posted, but does not get saved. I suspect since the url getting fired has old pzTransactionId which is not honored by server anymore is the root cause.
I could not figure out a way to update the pzTransactionId in pega.u.d.url after pega.u.d.asyncRequest('POST',oSafeUrl,callback,postData); call
Capgemini
CA
Hi Guys,
Can any one help or pull corresponding SME's to help.
I am running out of time and this is a critical business ask.
Thanks in Advance,
Satya
Capgemini
CA
Hi Guys,
Can any one help or pull corresponding SME's to help.
I am running out of time and this is a critical business ask.
Thanks in Advance,
Satya
Pegasystems Inc.
IN
Hi ,
Try to call the below code before any UI call and after your auto save . CHeck if it works:
var newurl = SafeURL_createFromURL(pega.u.d.url);
newurl.put("pzFromFrame","");
Hi ,
Try to call the below code before any UI call and after your auto save . CHeck if it works:
var newurl = SafeURL_createFromURL(pega.u.d.url);
newurl.put("pzFromFrame","");
pega.u.d.url = newurl.toURL();
var url = document.forms[0].action;
var formURL = SafeURL_createFromURL(url);
formURL.put("pzFromFrame","");;
document.forms[0].action= formURL.toURL();
Capgemini
CA
The whole problem is using pega.u.d.url.
I noticed that pega.u.d.url has old transaction id. Which means if I say var newurl = SafeURL_createFromURL(pega.u.d.url) it is still building new url with old transaction id. This is because, since this an ajax call with commit is fired and UI is not refreshed, pega.u.d.url is not updated on the client side.
Which needs to be remediated. I some how need to update the transaction id in pega.u.d.url.
Pegasystems Inc.
IN
Hi Murthy,
Will the section/harness refresh will work ,as the pega.u.d.url is having the old transaction id. Which might try to sync the transaction id between the server and client.
Capgemini
CA
Yes Refresh Harness will bring back the updated pzTransactionId. But we want to avoid a UI refresh.
Imagine you are on a lengthy page which refreshes every min while you are typing into fields. And you loose focus and you have to navigate to the respective field and then refresh happens again.
Pegasystems Inc.
US
Hello,
Every time you commit, you will get a new transaction ID and you will need to update the client with that ID and use it for any subsequent requests to the server. It is required for data consistency. You shouldn't be trying to hack around it. Not only will it take you out of guardrails, but will open you up to potentially overwriting good data with bad.
I'm a bit concerned about the design you are proposing in general. If you force the client to update the server every 60 seconds, even when a user is not at the desk, that requestor will never passivate. There are long term memory/performance implications. What is the fundamental business problem you are trying to solve? I suspect this is probably not the best way to solve it. Are you concerned about things like browser crashes and trying to recover from that? If so, you should look at the out of the box high availability features. I'm not an HA expert, but I believe it saves off changes somewhere as you go, so that if your session is interrupted, you can pick up where you left off. That may meet your business needs without requiring you to go outside the guardrails.
Thanks,
Mike
Capgemini
CA
Hi Mike,
Thanks for detailed response. I am not trying to hack, instead, I am trying to find a way to update pzTransactionID on client side with out UI refresh.
Also we have a way to track if client UI is stale (changes in form content). We check for staleness every 60 secs, and initiate save only if the form is stale.
Use Case:
- BU keeps questioning the need to refresh UI after every user initiated Save. They say it is hindering user experience
- Further our UI are really heavy and chances of crashing is also very high. We currently have users complaints in prod complaining of browser crashes and loss of work in progress data.
- We have multiple CKE on multiple screens, where users enter couple of pages worth data in each CKE.
- We use mathjax plugin, using with users enter formulas into CKE. Couple of 100's of formulas are entered in each E.
- Also quite some images in Each CKE are input into each of these CKE's.
- Due to such heavy client UI, users are reporting browser crashes.
Because of this, we are trying to implement AutoSave feature.
Hi Mike,
Thanks for detailed response. I am not trying to hack, instead, I am trying to find a way to update pzTransactionID on client side with out UI refresh.
Also we have a way to track if client UI is stale (changes in form content). We check for staleness every 60 secs, and initiate save only if the form is stale.
Use Case:
- BU keeps questioning the need to refresh UI after every user initiated Save. They say it is hindering user experience
- Further our UI are really heavy and chances of crashing is also very high. We currently have users complaints in prod complaining of browser crashes and loss of work in progress data.
- We have multiple CKE on multiple screens, where users enter couple of pages worth data in each CKE.
- We use mathjax plugin, using with users enter formulas into CKE. Couple of 100's of formulas are entered in each E.
- Also quite some images in Each CKE are input into each of these CKE's.
- Due to such heavy client UI, users are reporting browser crashes.
Because of this, we are trying to implement AutoSave feature.
- Wake up every 60 secs
- Check if the form is stale
- If stale, post data to server
- Initiate save with commit
- ** If save is success in callback, I need to somehow update the pzTransactionID on client UI without refreshing user sections
- Also since our UI's are heavy, users wanted to do away with Refresh even on User initiated Save
- BU keeps questioning the need to refresh UI after every user initiated Save. They say it is hindering user experience
To address both, we need a way to update pzTransactionID every time commit is performed.
Right now, I see PEGA uses pzTransactionID from pega.u.d.url. I need to figure out a way to fetch the latest pxClientExchange from clipboard(server) and update the pzTransactionID on client UI.
Pegasystems Inc.
US
Hello,
Unfortunately, you need to transport the new transaction ID back to the client after a database commit. I don't know how to do this without at least refreshing a section. You might be able to get away with refreshing a very small section and then using JavaScript to update the pzTransactionID, pxClientExchange, and any other field with that value in the DOM that I'm not thinking of at the moment, but that is completely outside of the guardrails and it would be incumbent on you to test/keep that up to date as things change in the platform because transaction ID is an internal value and not something we expect clients to be fiddling with. Again, I worry about your approach. I think it is going to give you problems down the line.
Hello,
Unfortunately, you need to transport the new transaction ID back to the client after a database commit. I don't know how to do this without at least refreshing a section. You might be able to get away with refreshing a very small section and then using JavaScript to update the pzTransactionID, pxClientExchange, and any other field with that value in the DOM that I'm not thinking of at the moment, but that is completely outside of the guardrails and it would be incumbent on you to test/keep that up to date as things change in the platform because transaction ID is an internal value and not something we expect clients to be fiddling with. Again, I worry about your approach. I think it is going to give you problems down the line.
Have you tried high availability? It sounds like that is probably a better, more future proof solution to the problem of having your browser session crash frequently. It's not my area, so I don't know if it saves things to the work object or somewhere else in the background, but I know it is saving as you go, so that you can recover from a crash with minimal disruption. Honestly, even if it is saving the data to some other object, you might be able to get away with using declaratives on the server to update the work object, or something clever like that. If you are calling obj-save with write now checked, it creates a new transaction, and I'm pretty sure it doesn't increment the transaction ID. Potentially, you might be able to get away with that in your current implementation as well. There are other potential problems with that solution, since any deferred saves of the object will now be stale, so you will need to test/account for things like that.
Another thought would be to break your large screens into screen flows so that you can save as you navigate from one to another (perhaps something like a tabbed screen flow to give the users the feel that all of the fields are available). That would also minimize the amount of data to refresh at any given time because you are spreading them out.
I wish I had a better answer for you, but really what you are trying to do is fundamentally not recommended, so there isn't an easy way to do it.
Thanks,
Mike
Capgemini
CA
Thanks Mike. The real question is, what is the section that is to be refreshed to transport new transaction ID back to client. And I need to refresh this section, with out impacting user screens.
We already bifurcated into multiple screens, to the minimum viable.
I don't think high availability is going help much. I have been reading specs you provided, it says too many things to time to be able to recover a session.
User needs to hit the exact node his session crashed on is one of the criteria to be able to recover his browser session.
Please let me know if there a section that I should refresh to be able to update the pzTransactionID on the current browser pega.u.d.url.
Pegasystems Inc.
US
There isn't an OOTB section that is the home of the transaction ID or anything like that. You will need custom code, I think any section should do, but I have never tried this, so I could be wrong. You may need it to have data to submit, but I think it can be a subsection, so it doesn't have to be the entire form. Of course I suspect the more narrow it is, the further in the DOM from where the data you *really* need to update resides, so there will be a lot more work on the scripting side. You should see the transaction ID in the HTTP traffic. If not, then it's not the right section. I wish I could provide more specifics, but this isn't something I've done before.
Thanks,
Mike
Pegasystems Inc.
US
Hi. Sorry I couldn't be more helpful. I was actually one of the people who suggested to route you here previously, because it isn't a product defect, so an SR isn't really the right vehicle (and hopefully other people find this conversation helpful). The transaction ID code is working correctly, you just want to make it work differently. I expect you can, but it will require a lot of custom work to implement. If none of this pointed you in the right direction, you may need a consulting engagement. They could come in and really understand your business requirements/find an optimal solution. I'm pretty sure there has to be a better way than fighting with the transaction ID code to get it to behave the way you want. Ideally, something more in the guardrails. Unfortunately I haven't been able to pin it down.
Good luck with this!
- Mike
Capgemini
CA
Hi Mike,
I have an observation, may be you will be able to help me with this.
In the success callback of pega.u.d.asyncRequest('POST',oSafeUrl,callback,postData), I have placed below code to update the pega.u.d.url pzTransactionID. And I see that pzTransactionID is indeed updated. But the subsequent pega.u.d.asyncRequest call still has the old pzTransactionID. Would you happen to know from where pega.u.d.asyncRequest call picks pzTransactionID?
var newurl = SafeURL_createFromURL(pega.u.d.url);
newurl.put("pzTransactionId",<New pzTransactionID>);
pega.u.d.url = newurl.toURL();
var url = document.forms[0].action;
var formURL = SafeURL_createFromURL(url);
formURL.put("pzTransactionId",<New pzTransactionID>);
document.forms[0].action= formURL.toURL();
console.log("Pega u d url: " + pega.u.d.url); //This log does print new pzTransactionID