Question
Virtusa
LK
Last activity: 3 Feb 2021 0:48 EST
Accessing DataPage in Java PRPC 8.5.2
We used to access Data Page in Java code using below code in PRPC 7. But once it is Upgraded to 8.5.2 the code would not return the AssignmentPage.
D_DataPage has one Parameter which is WOInsKey. It is a thread level DPage with reload once per interaction.
ParameterPage pp = new ParameterPage();
pp.put("WOInsKey", pzInsKey);
ClipboardPage AssignmentPage = tools.findPage("D_DataPage",pp,true);
String Count = AssignmentPage.getString("pxResultCount");
Is there any other ways to Load and Access DPage inside Java.
Accepted Solution
Updated: 3 Feb 2021 0:48 EST
Pegasystems Inc.
AU
My general recommendation here is to prepare an Activity that does the equivalent of what that part of your Java code needs to do, and then use View Java from the Actions menu to see what Java code Pega will execute at runtime to achieve the outcome. Then use that for inspiration.
I'm curious as to why this needs to be in Java code, since (depending on how pzInsKey is made available) a Data Transform whose Source side says ...
D_DataPage[pzInsKey].pxResultCount
... gets you the same result without breaking out into Java code.
This way you protect yourself from exactly this problem ... where the code that Pega uses to execute your configuration gets changed between releases (which Pega is entitled to do, by the way).
Assuming the snippet above is perhaps simplified, or part of a bigger orchestration from Java, it would be better (for the above reason) to have your Java 'orchestration' invoke rules to execute those parts of that are configurable in the model. You can call Data Transforms, Activities, When rules and other rule types from Java.
My general recommendation here is to prepare an Activity that does the equivalent of what that part of your Java code needs to do, and then use View Java from the Actions menu to see what Java code Pega will execute at runtime to achieve the outcome. Then use that for inspiration.
I'm curious as to why this needs to be in Java code, since (depending on how pzInsKey is made available) a Data Transform whose Source side says ...
D_DataPage[pzInsKey].pxResultCount
... gets you the same result without breaking out into Java code.
This way you protect yourself from exactly this problem ... where the code that Pega uses to execute your configuration gets changed between releases (which Pega is entitled to do, by the way).
Assuming the snippet above is perhaps simplified, or part of a bigger orchestration from Java, it would be better (for the above reason) to have your Java 'orchestration' invoke rules to execute those parts of that are configurable in the model. You can call Data Transforms, Activities, When rules and other rule types from Java.
How? You guessed it ... configure an Activity that calls those rules and use View Java to see how Pega does it. An additional benefit of this approach is that these parts of your execution will show up the in the Tracer. Anything in Java is not visible in the Tracer (until it throws an Exception!)
The less you have in Java code the better, to the extent that once you've broken down your Java logic into its component parts, you could do each of the components in a Pega rule and didn't need Java after all !