Posted: 6 Jun 2017 5:42 EDT Last activity: 23 Jun 2017 10:40 EDT
Parameters to be passed along with jump to later steps
Today pega behaves like below. If I have to provide various message for different authtypes, I need to add multiple steps (property-set) like below.
In the step when condition,
when Authcode=='001', jump to later step - DO1
when Authcode=='002', jump to later step - DO2
Set MessageDesc="Processed By Iseries"
Set MessageDesc="Processed By AI"
My expectation is below
In the step when condition,
when Authcode=='001', jump to later step - DO1(param1=(Authcode), param2=(AuthMessage))
when Authcode=='002', jump to later step - DO1(param1=(Authcode), param2=(AuthMessage))
Set MessageCode=param1 (001/002)
Set MessageDesc=Param2 ("Processed By Iseries" / "Processed By AI")
The advantage is avoiding multiple steps and returning the value to the user from a single step.
It sounds like you'd be better off encapsulating the parameterized part as an inner activity so instead of merely branching, you'd have both branches call the same inner activity with the appropriate parameters.
I would create 2 Map Value rules which map the auth code into the appropriate MessageCode and MessageDesc. (It may be possible to do this with a single, or cascading rule, but I'm not sure about that). You would then call Property-Map-Value on the first map value to get the MessageCode and insert that into a parameter. Then call the second Map-Value rule to get the MessageDesc and insert that into a parameter. Then do the single Property-Set.
Your Map Value rules will have as many rows as you have auth codes.
Alternatively, you may also want to try setting MessageCode & MessageDesc (with appropriate When conditions) using a Data-Transform rule, instead of an Activity rule.
If the use of Activity is must, then I would like to add by saying: try to avoid Jump conditions because we must remember that Activity only supports jumping to a later step, because the steps are always procedural.
May be I need to make it more clear on my requirement. I added a simple example, but unfortunately it turns into a different direction in solution wise.
Actual scenario is a serious of steps performed before complete an Operation
Step1: Obj-Browse - Get Details of Operator By OperatorID
Step2 : If Operator.Recordcount>0 Continue When, Else Jump To Later Step - Property-Set - MessageDesc : Operator Doesn't exist
Step3: If Organization Exist , Continue When, Else Jump To Later Step - Property-Set - MessageDesc : Organization Doesn't Exist
Step4: If WorkGroup Exist, Continue When, Else Jump To Later Step - Property-Set - MessageDesc : WOrk Group Doesn't exist
Step5: If OrgDiv Exist, Continue When, ELse Jump To Later Step - Property-Set - MessageDesc : Divison Doesn't exist
Step6 : Obj-Save
The above activity is called from a rest service, where these [OperatorID, Organization, WorkGroup, Division] fields are send in parse xml format. we are using various property-sets, for input validations to return the valid response message to the user,. The question is How to avoid various property-sets for each types of messages
Sample XML : Here each xml element are validated before we do a obj-save
As far as I understand, you are looking to refactor this so that all message's setting is moved to one place for better maintainability.
But my concern is that even if find a way to pass params in Jump to later step, that step should still do something. Then why not set params in that step only and then finally jump to a step which takes those params and set into actually output property?