Question

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!!

  1. setInterval(function(){
  2. InitiateAutoSave();
  3. }, 60000);
  4.  
  5.  
  6. function InitiateAutoSave()
  7. {
  8. if(window.parent.ValStudioDirtyCheck==true)
  9. {
  10. var callback = {success: SuccessSave, failure: FailureSave};
  11. var oSafeUrl = null;
  12. var postData = "";
  13.  
  14. oSafeUrl = SafeURL_createFromURL("pyActivity=MyActivity&pzPrimaryPageName=pyWorkPage");
  15.  
  16. pega.u.d.asyncRequest('POST',oSafeUrl,callback,postData);
  17. }
  18.  
  19. }

***Edited by Moderator Marissa to update platform capability tags; update SR Details****

Group Tags

Comments

Keep up to date on this post and subscribe to comments

Pega
June 16, 2019 - 11:48pm

June 17, 2019 - 7:11am
Response to Evita_08

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

Pega
June 17, 2019 - 3:26am

Have you tried to trace the first and subsequent calls? Are there any exceptions/errors present?

 

June 17, 2019 - 7:02am
Response to pa1singh

I did trace. No error or exceptions. Even the callback executes success call back.

 

June 17, 2019 - 12:19pm

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

July 4, 2019 - 3:31pm

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

Pega
July 8, 2019 - 5:17am

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();

July 8, 2019 - 11:46am
Response to sahuv1

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.

Pega
July 10, 2019 - 3:07am
Response to Murthy.1303

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.

July 12, 2019 - 4:20pm
Response to sahuv1

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.

 

July 16, 2019 - 3:05pm

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.

https://community.pega.com/sites/default/files/help_v82/procomhelpmain.htm#engine/high-availability/overview/eng-high-availability-overview-con.htm

Thanks,
Mike

 

 

July 16, 2019 - 7:45pm
Response to MikeTownsend_GCS

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.

July 17, 2019 - 1:23pm

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

July 18, 2019 - 12:21pm
Response to MikeTownsend_GCS

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.

July 18, 2019 - 1:19pm

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
 

July 18, 2019 - 3:59pm
Response to MikeTownsend_GCS

Thanks Mike for spending time on this. I have raised SR but they are simply redirecting me to PDN. 

Will try to pursue over SR.