There are many posts on how to pass page as parameter from one activity to other and also passing pyWorkPage as parameter from one activity to another. I am clear on how to pass pyWorkPage or page as parameter.
But, i am trying to understand what are the situations that lead to passing pyworkpage as parameter? When we are supposed to pass pyWorkPage as parameter ? may be you can take Sales Automation framework ( PCF, CPQ, SA) as an example to explain this point.
My intension is to avoid pyWorkPage hardcoding. So, i need info on when we call using pyWorkPage is hardcoding.
Fantastic that you are actively looking to avoid hard-coding pyWorkPage. Please tell your friends!
Ideally you would never hard-code pyWorkPage, for there are a small number of occasions when the assumption that “pyWorkPage is always the current work item” does not hold true.
Depending on the rule you are looking to make the call from (such as a Post Processing Activity), Param.workPage may already hold the name of the current work page, so you could reference that in the “Page name” parameter of the rule you are calling.
In many of these situations though (like Post-Processing Activities), as well as in other occasions when the Primary page of your calling rule is the current work page, assign the result of @pxPrimaryPageGetReference(tools) to a local variable (Activity) or parameter page item (Data Transform). Passing this as your “Page name” parameter gets the intended page name into the called rule at runtime without hardcoding “pyWorkPage” at design-time.
I prefer the function call as it makes the calling rule more reusable. Rules with a dependency on Param.workPage can only be used from flow processing.
The main situation where this assumption doesn’t hold true is when a subcase has been added to a parent case and is currently in that part of its workflow that is before it reaches its first assignment.
In this situation:
pyWorkPage is the parent case that is blocked waiting for the “Create Case” shape to finish; and
the subcase is therefore named something else
Once the subcase reaches its first assignment (or it resolves in the event of no assignments), the Create Case shape finishes on the parent case and it proceeds to the next lifecycle step.
Any rules on the subcase case type invoked before its first assignment, which assume pyWorkPage refers to an instance of itself, are making an invalid assumption as pyWorkPage still points to the parent case.
Other scenarios to watch out for is where custom configuration - such as a Service, Agent or Queue Processor activity - creates a new top-level case and starts the workflow. The configurer can name the clipboard page holding the new work item whatever they want, for example: NewWorkItemPage. In this situation there is again a window when the rules being performed on the workflow of the current work item which is not named pyWorkPage on the clipboard.
It is again likely that the “Primary” page of the rule is the current work item, and configuring your rules to reference the Primary page rather than “pyWorkPage” provides more resilience.
Your point is absolutely correct until the subcase reaches its first assignment during creation ,the pyWorkPage context will be of the Parent case. Secondly if there are any pre-processing activity/DT called in subcase assignment it will pick up the parent case pyWorkPage context.
Sorry, catching up on some old threads that I didn’t get notifications on
You are probably (?) okay with Pre-Processing rules for subcase assignments as these don’t run until the UI is about to be shown for that Flow Action. Pega may (?) by that time have already switched the pages around so that the subcase is pyWorkPage and the parent case is pyWorkCover.
If you were using Primary, you are assured to be fine … best to be using Primary everywhere!
… best to be using Primary everywhere!