DCR iplementation between FW and App flows and route to logic
Hi Pega Experts,
Can you help me how to implement DCR for below requirement.(pls tolerate my over intelligence questions or silly questions as I have more theoretical exposure and little practical pega development exp, kindly help it wold be grateful)
1.Have a "rolemodelFWFlow" Defined in FW with two assignments -1st assignment routed to "currentoperator" , 2nd assignment routed to "WorkQueue"[workQueue in 2nd assignment should be configurable].
2. Need Two Applications with Flows namely "App1.FollowerFlow1" and "App2.FollowerFlow1" with same steps as "rolemodelFWFlow" Defined in FW but the 2nd assignment need to be routed to supplied App1.WB1 and App2.WB1 for respective application Flows App1 and App2.
1a.Do we need to define two separate flows in two applications App1.FollowerFlow1 and App2.FollowerFlow1 and call "rolemodelFWFlow" while passing the relevant work queues - App1.WB1 and App2.WB1 for respective application Flows from App1 and App2.?
1b.launch the "rolemodelFWFlow" while passing the relevant work queues - App1.WB1 and App2.WB1 for respective application Flows from App1 and App2.?
If approach 1a is suggested then we need to duplicate same flow in three different places which is defeating the idea of reusability !!
If 1b is suggested - If each application (App1 and App2) users are different and they are tied with (App1 built on FW) and (App2 built on FW) will they need to switch to the FW application to create the case?
3. Request you to suggest a correct step by step implementation.
First of all you should avoid routing to current operator. Everyone who uses an application does so in the context of an Access Role. Set pyWorkParty( <role> ) using the CurrentOperator data transform then use ToWorkParty as the routing activity specifying <role>. You can do this with the very first assignment in a top-level case using VOE within the case’s WorkParties rule.
As for the second question, there is no need to define two different, but virtually identical flows, the only difference between the two flows being a hard-coded workbasket name. This is one of the benefits of using DCR.
Are you sure you truly need an FW layer? Has Business stated whether they want these two applications deployed to the same database or to separate databases? You would need a very generic FW layer before it make sense to build two different applications on top yet host those two applications in the same database. Each application would have a different workpool class, hence different work table but those two applications would share other tables in the database such as PC_ASSIGN_WORKLIST.
Have you read the 7.3 Lead System Architect course? That course spells out when developing a framework layer makes sense and when it does not.
"As for the second question, there is no need to define two different, but virtually identical flows, the only difference between the two flows being a hard-coded workbasket name. This is one of the benefits of using DCR."
how to refer/invoke that one flow created /saved in the FWlayer "from and for" App1 impl and App2 Impl - steps.
I am hoping this is a learning exercise only. In the 7.3 course we teach specialization outside the concept of "FW layers". Any class be specialized in Pega, not just FW case types. If even an implementation case type can be specialized, why create an FW class?
To answer your question, In your "FW" layer assignment you have the option of using "Other" as opposed to "Workbasket". Choose "Other" then enter a DCR-derived property such as .AppExtension.ImplSpecializedWB where ,AppExtension references a DCR Data Page such as D_AppExtension.
FYI: If purely interested in dynamically specifying a workbasket name, regardless whether specialization occurs afterward, there are three flavors of decision-based routing activities to choose from, namely, ToDecisionTable, ToDecisionTree, and ToDecisionMap.
The Decision Table, Tree, or Map invoked by these routing activities could be overridden within a specialization layer,
In DCR, a Data Transform is typically overridden.
A Data Transform is a centralized way to manage dynamic behavior, i.e., only one rule needs to be overridden, not several.