Reasons to use Code Actions in a DTL?

Question

Question

Jenny Ames · Jun 8, 2016

Do you find yourself commonly adding code actions to your data transformations? If so, what do these contain? Is there a reason you choose to add a code action over creating a custom function that you can call?

Discussion (10)1

Log in or sign up to continue

Elizabeth Harding · Jun 10, 2016

I haven't coded DTLs for quite some time, but recall that I used code actions in a few places to set/use local variables, for example, to help keep track of the number of occurrences of lines in blocks of NTE or OBX segments in result messages. One scenario I recall is where a lab system wasn't sending comments in the right place for the receiving system (since in an ORU_R01 message, NTEs can exist after the PID, OBR or OBX segments) and so we needed to move/copy the notes somewhere else in the msg. Undoubtedly, this could have been handled by a custom function, but sometimes developers just do things the way they know how to, and not necessarily the 'best' way!

The team would also use code actions quite often to insert comments into DTLs to help explain or document particular processing etc.

1 0

Andy Picou · Oct 11, 2016

I insert a code block in a DTL when the source OBX(1):5 contains multiple lines delimited by "\.br\" and the target message requires one line per OBX. Using standard DTL I can <assign value='$LFS(source.{OBX:5},"\.br\") property='tList'. And in a code block "While $Listnext" through the list populating the target OBX(n)

1 0

score 1 · Answer 1 · 2016-06-08T15:49:05-04:00

To get the conversation started: One interesting way I've seen people use code actions is to comment out several actions while debugging. Since its not immediately apparent what is in a code block, you need to be careful to clean up your work when you are finished (potentially removing actions you no longer want as well as removing your code block) so others (and let's face it, you!) don't get confused later.

score 1 · Answer 2 · 2016-06-09T12:50:10-04:00

Code actions are also useful to get immediate feedback on operations performed in the DTL when using the Test facility. The output of write functions will display just above the transformation output.

score 0 · Answer 3 · 2016-06-21T13:21:41-04:00

Jenny Ames · Jun 21, 2016

Great idea Jeffrey! Thanks for sharing!

0 0

score 0 · Answer 4 · 2016-09-09T13:33:45-04:00

Hi Jeff, thanks again for your suggestion! We actually included this in one of our newer online courses Advanced Data Transformations. Thanks!

Jenny

score 0 · Answer 5 · 2016-06-21T13:27:45-04:00

I can imagine moving NTEs would be a common use case as v2 does provide a bit of optionality in implementation but if its the only place that's needed, using a Code Action makes sense to me! Thanks Liz!

score 1 · Answer 6 · 2016-09-21T12:02:00-04:00

This may be slightly dodgy as it depends on assuming how the DTL will be compile, but I have used them to implement a loop around a set of standard DTL actions.

For one the source message had a stream with a document in it, and it needed to be chopped up into chunks, each one being put in a field in an HL7 v2 OBX segment. So an initial CODE action opens the loop with something like "Do {", gets the next chunk and quits if none. Then there are some normal ASSIGN actions setting up the new segment - easy to put in and appear in the DTL display. And finally there is a second CODE action to end the loop with "}".

It works, but only as long as InterSystems keep the compiled code for the assigns nice and simple.

A similar use was when dealing with xml documents. Again I needed a loop that enclosed normal ASSIGN actions, but this time for things like stepping backwards and deleting unwanted elements, or creating them from an array.

Also, I used a CODE action to work out if a DTL was running inside a business process, or just in the Studio for testing, so that some expected properties could be created to allow the test to run. Just for debugging.

Regards,

Mike

score 0 · Answer 7 · 2016-09-21T15:51:14-04:00

Very interesting Mike! Thanks for sharing. There are always multiple ways to solve a problem but I think you're on to something here...

So thinking through a bit more about when this approach might make more sense than using a built in loop (like a foreach): Because the stream was one item, it sounds like a foreach would probably have been more difficult in that situation? Were there other ways you considered doing this? And if so, what went into the decision to use the code action here? I'm assuming this was called from a business process built using the Business Process Designer?

That's a cool idea of setting variables in debug/testing mode!

score 0 · Answer 8 · 2016-09-22T04:17:40-04:00

Hi Jenny,

The FOREACH has to iterate over something, but there is only one input field, so I don't think there is any other way than a CODE action in a DTL (at least on v2012). I could have done the whole loop in the one CODE, or called an outside function, but I preferred to use the GUI to set up the ASSIGN actions for me, to provide the extra validation and visual links in the DT Builder. I have used DTL whenever possible in other areas like in BPL to extract data from messages into temporary variables. Maybe not always the quickest or easiest way, but I think it makes the system more transparent.

For the loop the DT is actually called from a routing rule. The source is a simple message class with a few fields, and the target an HL7 v2 MDM_T02 message. I suppose if a full BP was involved then the loop could have been implemented in BPL in some way, but I think that would get complicated. Perhaps DTL needs a more general WHILE/UNTIL loop action added?