Question
Pegasystems Inc.
IN
Last activity: 29 Sep 2019 23:59 EDT
Creating a data page to save data
Dear Leads,
"Creating a data page to save data" feature of Pega 7.4 is interesting feature, but is it really to have the Data Page to Save Data.
any one knows , Why Pega has come up with this option ? what are the technical benefits ?? Any impact on the performance ???
Please share if you have a case study to support this Pega 7.4 feature.
Thanks
-
Like (0)
-
Share this page Facebook Twitter LinkedIn Email Copying... Copied!
Pegasystems Inc.
US
Data integrity, redundancy elimination, BLOB size.reduction.
Suppose a multi-level case hierarchy that can be > 2 levels deep; hence use of pyWorkCover cannot be assumed.
The root case contains a list that it saves using a Savable Data Page, each row containing the root case's pzInsKey.
As opposed to Data-Propagating the entire list to every subcase, only a .RootCaseKey property needs to be propagated.
Data integrity, redundancy elimination, BLOB size.reduction.
Suppose a multi-level case hierarchy that can be > 2 levels deep; hence use of pyWorkCover cannot be assumed.
The root case contains a list that it saves using a Savable Data Page, each row containing the root case's pzInsKey.
As opposed to Data-Propagating the entire list to every subcase, only a .RootCaseKey property needs to be propagated.
Similar to the Work- .pyAttachments property, subcases can load a List Data Page by reference using .RootCaseKey as the lookup parameter.
Other Use Cases come to mind such as implementing the Memento Design Pattern,
CYBG
GB
Apologies for my ignorance, but that sounds like an extreme corner case. Do you have any "normal" uses of such a feature that would improve efficiency over the tried-and-tested use of an activity? Activities are generally the most useful way of persisting data, mainly due to the level of control it gives us (despite Pega's constant exhortations not to use them). Why should we change?
I am not suggesting we shouldn't use this new feature, I just can't see any reason why I should give up solid, reliable logic for something new just because it's "shiny".
-
Kensho Tsuchihashi Cloe Walker Aparna Vara Michael Verhaar
Anamata
NL
I do not believe that it's Pega's intent to replace activities by introducing savable data pages. Activities give developers a lot of flexibility. However, by introducing this feature you have alternate possibility to consider for saving data rather than merely through usage of an activity. Activities are easy to configure and maintain for developers, however not so much for less tech-skilled users. I'm assuming that Pega might be prepping for possibilities to delegate more towards these users.
-
Norman Isaacs
Pegasystems Inc.
US
I've recently worked with a lot of ReST service calls and found that wrapping the connectors in data pages is a useful pattern with several benefits, whether querying or updating the external SoR.
- It's easy to implement a data page that uses a connector as a source. The initial data page is created by the integration wizard.
- You can re-wrap the connector in different data pages with unique names to implement specific query or update functions and make the purpose clear to other developers. For example, these data pages might all use the same connector with different input params and different request data transforms:
- D_GetAccountInfo
- D_SetAccountStatus
- D_DeleteAccount
- The same response data transform can be used for all data pages that use the same connector source.
- Error handling can be encapsulated in the response data transforms and reused across multiple service calls.
Yes, you can do all this with activities but I've found that with this pattern I rarely need to write an activity. Data transforms are sufficient and the code is easier to maintain.
Pegasystems Inc.
US
You are free to choose "Activity" as a "Save type" when configuring a Savable Data Page.
Other options are Robotic Automation, and Robotic Desktop Automation.
For Structure=Page Data Pages a fourth option exists, namely, "Database save".
It makes sense that if you can configure a Data Page to do a Lookup you should also be able to define a Structure=Page Savable Data Page to update that row in the database, or if the row does not currently exist, insert it. No Activity required.
For Structure=List Savable Data Pages, when not using Robotics, an Activity must be used to save the data.
-
Pooja Gadige Deepak Kumar Richard Marsot
Coforge Technologies (Erstwhile Incessant Technologies)
GB
Savable Data pages is a best option to seperate persistance logic from business logic of activities, where there is persistance logic only required without processing data like post flowaction or within the flow directly Savable Data pages can be referred instead of calling activities with "Obj-Save" methods.
NTT Data
US
One more point is you need to deal -when you have WSDL with Complex Type Data Elements in Robotic Automation you have to use Service Client , Service Client do not have easy way to form request or even map the response , all you need to do in your string utils and other manipulation , no automatic way to form different parsing rules , forming request extra. So this situation we can utilize Data Pages , recent latest version of Robotic Studio SP- included Data Pages, it helps big time.
-
deivit mamani Maciek Zmudzki Marissa Rogers sailaja rachapudi Dongsheng Zhang and 9 More
Coforge Technologies (Erstwhile Incessant Technologies)
GB
Can you please provide an example for this.
Reply
IT
I found them to be a great addition when you're working with locally stored data not tied to a specific case.
Suppose you have a list a products and you need to update the price. Before you had to create an activity just to do an obj open, apply a data transform and perform an obj-save. Now you can use a savable data page which is much more intuitive.
As i see it activities should be your last resource for complex logic. Updating a value in a SOR should (and now is) accomplished without activity.
Now it would be great if we could insert records too and not only update them :)
Alpharetta Consulting
US
I like them for the same use case, and I have the same wish for a simple way to insert a new record =)
Pegasystems Inc.
US
You can insert records using a Savable Data Page.
Start with an embedded page property NOT sourced to a Savable Data Page.
Next create a Data Transform that has the same applies-to class as the embedded page property .
Call the Data Transform from the case, for example as a Flow Action post transform.
If any embedded page property used as a unique key does not contain a value, the Data Transform should set one. For example if the data instance uses pyGUID as a unique key, set it equal to @Utilities.pxGetNewGUID() or just check the "Automatically generate a unique ID for records of this type" box within the Class rule.
Next update the Savable Data Page setting it equal to the embedded page property. The syntax for the Savable Data Page will require that you to supply the value for each unique key as a parameter.
Afterward use a Save Data Page step to save the data. That step will ask you to supply the keys.
If you trace the Savable Data Page you will see it complain about lookup failing. Nonetheless the Savable Data Page will contain the properties copied from the embedded page.
Alpharetta Consulting
US
Thanks, Lee. I still hope that the Product or Engineering department will decide to add a simpler option to insert from a savable data page, but in the meantime, I'll try your solution the next time I find myself wanting to insert from a savable data page.