Hi Team,
I have created a savable DP with source as DT, i have called this DP from flow shape to save details to DB. When DP got executed instead of current case details , previous case details are getting saved. I see this issue if i use pyWorkPage reference inside the data transform Attaching the code that have added in DT. Please help me to understand.
Regards.
In Constellation I would avoid relying on pyWorkPage. This is due to stateless nature of Constellation. You can not be sure of content pyWorkPage when data page is called - this is separate API call.
As solution please pass the required case data explicitly into the data page using parameters instead of reading directly from pyWorkPage, like pzinskey or case id.
if you observe my image first the 4 steps i have passed the values to the parameters from the casetype itself which is working completly fine is that what you are suggesting? if yes, what if i have 10 number of properties will that not looks clumsy?
can you try with using other name than pyWorkPage?
if i use other than pyWorkPage, i cant access the data elements from the work object right?
That is the point. You pass parameters (like case id), you need to open work object and use this data as source. Using pyWorkPage is not reliable
I understand your issue. Once try this approach.
You can call your Data Transform in the Data Page “Data save options” section, as shown in the below image.
Hey sohan, this approcah worked can you help me to understand why it is required to give DT here? we have already given the DT as a source to DP right. Whats the reason behind this approach
I got it, i will try this as well. you mean to say just instead of using the pyworkpage directly we can open the workobject and get the details into a page and use that. Also can you help me to understand “You can not be sure of content pyWorkPage when data page is called - this is separate API call.”
Good to hear the approach worked. Let me clarify why we need to give a Data Transform in the Data Save Options even when the Data Page already has a DT as its source.
The Source DT is only used when the Data Page is loaded. It defines how data is fetched and structured in memory.
The Save Options DT is separate — it tells Pega how to persist changes back to the system of record (database, connector, etc.).
Without the Save DT, the Data Page would remain read-only. Even if you update values in the case, Pega won’t know how to push those changes back.
Thanks for the clarity sohan, but how this approach is different from traditional UI to constellation. The approach which i have followed (with out DT in DB save options) works in traditional UI where i can persist data without adding DT in database save options.
In Traditional architecture, the entire execution happens within the same server thread. Because of this shared state, pyWorkPage is readily available in memory when the Savable Data Page is invoked, allowing data to persist implicitly.
Constellation completely changes this paradigm by moving to a stateless, API-driven architecture.
In Constellation as @Kamil_Janeczek mentioned in above reply , every action—whether it is loading a data page, opening an assignment, or performing a case step—is executed as an isolated, independent REST API call to the backend. Because these API endpoints are atomic and decoupled, the data page execution context has no inherent awareness of the active case’s pyWorkPage. You can observe the same when you turn on the tracer. You will see multiple requestors running each API call and see that while Data Page is being executed, you will not have the context of pyWorkPage.
Thanks for the explanation, so the ideal solution for such scenarios is to get the context of workpage either by opening or something like that?
@RamS17794658 Are you in the User Experience Expert Circle? I would like to move this under that area, so it can be found with other Constellation questions. However, if you are not a member you won’t be able to respond (until you join), so don’t want to just move on you.
Please let me know if you join and i’ll move.
Hey marc, joined
Possible solutions
pyWorkPage was always a controversial practice even in Traditional UI… There are a few different ways, I honestly don’t know what rule/class context to use each. Sometimes primary works, some times caseInfo api works, most of the time TOP works. If anyone knows when to use what, I’d love a Constellation 101 on the topic 
@RamS17794658 just re-reading your post. I had a similar issue a couple of years ago in a Constellation app.
I found removing the property that had the saveable datapage defined helped clear any cached data. That way i could run my DT clean from any previous details. So maybe its not your setup but the difference in how data pages are cached in Constellation?
Hey @MarcCheong i even tried removing the property which i m trying to copy but it did not worked, what worked for me is as @Sohan_Reddy_Anugu suggested i have added my DT (you can refer image at start of thread) at Database save options again so it worked.
Keep a parameter of type string “WorkPage” in the datapage, and keep the same parameter as type of Page within the Source DT , and while calling the dataPage just give the pyWorkpage or Copy the pyWorkPage value to TempPage and pass the same to WorkPage Parameter while Calling Dpage
Hi Srinivasan, this is exact solution i have tried earlier but still i can see dp is saving previous instance information only.
