Use chaining to consolidate ADT Xlates

[Daniel Lee]

We are using Cloverleaf 5.8.4 on Windows and are considering using chaining to create a parent/child Xlate chain and were wondering if anyone has had issues with Chaining in Cloverleaf before we go down that path.

We are in the middle of a conversion of EMR’s where we are completely re-writing all of our ADT interfaces.  We are spending a lot of time replicating xlate code for all of our trigger events for each downstream system.  In other words, if we have to translate data in a field we have to do it in the xlates for A01, A02, A03, etc.  Very time consuming.  We do not want to use wild card routes because we want there to be a route for each message type. The main reason for not wanting to use wildcard routs is because not all of our staff understands regular expressions and if they right mouse click on the route in the monitor they won’t be able to tell what messages are being routed.  From analyzing our variant, we find that the only difference between the ADT trigger events is at the segment level therefore we can create one ADT_Parent message type in our variant that will work for all ADT message types.

We will then create a parent Xlate for each downstream system that has the stuff that is common to all ADT messages in that Xlate.  The parent Xlate will use the ADT_Parent message structure in the variant.  If a downstream system has any translations that are specific to a trigger event that can’t be applied to all ADT messages we will create a child Xlate for just that trigger event and chain it behind the parent for the route for that given ADT trigger event.  This will allow us to make the changes that are true for all ADT messages in the Parent xlate one time and it will work for all the children.  This hopefully will speed up our development and reduce maintenance.

Back to the question, since chaining is relatively new, has anyone seen any issues with chaining that we need to be aware of?

Topic

[bill bearden]

Nothing major. The thing I ran into when I started chaining using existing xlates was that the xlates had SEND commands in them instead of CONTINUEs. It didn’t matter before, I guess. But when I put one of these older xlates at the beginning of a chain, the SEND caused the message to skip the next step(s) in the chain.

Just realize that SEND and CONTINUE do slightly different things in a chain where they do basically the same thing in a route with just one xlate (and no post procs and other stuff).

If I have misstated this, please someone chime in and correct me.

[Daniel Lee]

Thanks Bill.  That’s a good thing for us to be aware of.

[James Cobane]

SEND puts the message directly to the outbound data queue of the destination thread, thus skips any post-xlate procs on the route.

The CONTINUE action generates a message from all the translated elements up to the Continue, and places it on the disposition list as CONTINUE. This includes further processing of the generated message through post-xlate procs, etc.

So using SEND and CONTINUE may look the same on a single route, but if you have any post-xlate processing/procs on the route, SEND would skip them, CONTINUE would not.

Hope this helps.

Jim Cobane

Henry Ford Health

[Jim Kosloskey]

Bill,

You are correct.

CONTINUE says continue the message on through the engine, SEND says send the message to the destination thread bypassing the states after the Xlate.

My standard is to always use CONTINUE unless I specifically see an incontravertible need for SEND.

Everyone I help with creating multiple messages from one message I make a point to explain that difference as it is subtle but important and can be difficult to trouble shoot when it does not work as intended.

As far as chaining, I have no experience yet as we are still on 5.6.  However, I would say attention may need to be paid to the variants deployed at various stages.

If one wanted to take the approach of using the Xlate for filtering I suppose now one could have ‘filter’ Xlates which only filter messages. A BULKCOPY or a series of PATHCOPYs would probably be used therein and the same variant in and out. A challenge would be determining if an Xlate were a filter Xlate or not. Simply saying the first Xlate of a set is a filter Xlate would only work if there were no other reason for chaining. Otherwise I suppose using a naming convention could work but would be challenged in the cases of severly complex filtering.

I suspect the same challenge may arise with the intended ‘Parent/Child’ relationship in that some method needs to be deployed to quickly and externally indicate that relationship is being deployed.

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Daniel Lee]

Thanks Jim.  We have discussed havining naming conventions that reflect the chain but we will make sure to pay paticular attention to that.  We do have quite an extensive test plan so hopfully any issues will be flushed out in testing.

[Jim Kosloskey]

Daniel,

Very good – please post your results or contact me directly as I am very interested in how you get this functioning.

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Daniel Lee]

We should have more data for you next week.  We’re moving fast and furious on creating those parents for the chain to try to save on build time and maintenance.

[Author]

Replies