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.
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.
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.
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.
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.
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?