Question
· Oct 25, 2024

ForEach with Assign only returning the second looped aux value in foreach when sending from rule editor

We have a scenario where we use the best practice article of a BP and DTL to split up HL7 messages mainly ORUS 

https://community.intersystems.com/post/splitting-oru-messages-using-obj...

It is really useful but we have this code in many places that we are trying to consolidate it in one place. 

We do not want to split it at the first stage in our rules as there is a lot of messages that go to sink. So we are trying for specific rules and the incoming hl7 matches certain rules and classified for certain downstream systems that it is then split and transformed. 

The problem is that when assigning the value to aux.RuleUserData although the message is split up the value in the assign is always set to 2 when the send is being sent even though the value of Segment.{SetIDOBR} is both 1, and then 2.

 

i.e. souuce

first message is HSR2

The trace element is both 1 and 2 

The error is not the setIDOBR 

If I hardcode to 1 it will send the first obr out twice 

Why is assign not setting the value as both 1 and then 2 in the foreach as it is sending the message twice. I think this may be linked to the answer in https://community.intersystems.com/post/how-do-i-pass-auxruleuserdata-un... but for me I don't fully understand this answer. 

Is there a way to pass the counter of the foreach in any way to to DTL? 

Product version: HealthShare 2024.1
$ZV: RIS for Windows (x86-64) 2024.1.1 (Build 347U) Thu Jul 18 2024 17:35:51 EDT
Discussion (3)1
Log in or sign up to continue

I think it might be my misunderanding of how the rule editor works with foreach but the documentation is not clear 

I would expect to see trace "1" send, trace "2" send, not it running through the foreach until the end have a count of how much it succeeded and then send with userdata "2" twice. Is there a way to change this? Why it is this way around?

Some clarification from WRC: "The "RuleActionUserData" is a value set in the rule when or otherwise clause and can be overwritten at each iteration of the <foreach>. The <Send> action is not executed immediately at each iteration, but a list of <Send> action is generated while evaluating the <When> condition and will be execuated all at once after the evaluation. That's why the last value set in the RuleActionUserData was sent to the same DTL twice in this case."

In the end, we were able to get this work by instead passing a list of the segment IDs, and then modifying the list within the transform.

Here, each iteration of the RGS segment appends the IDRGS to the comma delimited list, and then in the transform, we grab the first piece, and then if it is not the last item on the list, we modify the list (so the next Send action will get the next item):

This resulted in the previously expected behavior of one message with each RGS segment.