message forwarding using the DESTCONN

[Kevin Scantlan]

I want to re-route a message from an outbound thread to different thread and hence a new destination.  I want the message run through all the outbound TPS scripts, but in the last thread, based upon certain criteria, not to be sent on to it’s original destination but be routed to a new thread.  I created a script to look at the message and using “msgmetaset DESTCONN $newthread”  tried to reroute it.  It changed the DESTCONN value, but sent it on to it’s original destination.  I returned from the script using the normal “return {CONTINUE $mh}” as always.  Where did I go wrong?

Topic

[Jim Kosloskey]

Kevin,

Maybe you need to OVER it rather than CONTINUE so that it can be seen as an inbound and thus routable message.

As a matter of fact why not just do an OVER then on the TRXID or via normal routing definitions route to where you want – less ‘hidden that way I would think.

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

[Kevin Scantlan]

Without going into all the detail, we have about 5 non-prod domains of a particular system.  We have approximately 20 interfaces (inbound and outbound) that are duplicated for each domain.  Currently, we point to only one domain at a time.  When we want to switch, we have a script that reads a table of ports and IP address for each domain, changes the NetConfig file with the ports and IP address for the new domain, then bounces the threads to now start using the new ports and IP addresses.  We have a front end application that allows the application support staff to control which domain is the current domain.  The problem is that we can only point to one at a time, which can run into a scheduling nightmare.  We would like to be able to send to any of the domains at any one time based upon some field that could control the routing.  For outbounds, I want to place a script as the last script in the outbound TPS to route the message so that we do not have a duplicate all the translations and scripts that a message would have to go to get to that point.  I would like a single thread for each domain (a portal, so to speak), that I could route the outbound message to send it another site that contains all the outbounds for that domain.  It’s complicated, but simply put, I want to send a message from one outbound to another, conditionally,  without having to build routes.  I was hoping that the DESTCONN would do the trick.

[Jim Kosloskey]

Kevin,

It is possible DestConn may do the trick (you may also need to se the original thread metadata (I don’t recall that metadata name off hand to the outbound thread (original destination) name.

But you may still need to OVER the message so it can be routed from the inbound side.

Maybe dynamic routing on the routing definition is a better solution than specific routes (I think you still need to OVER) or perhaps doing this metadata change post Xlate but pre outbound thread.

I have not tried exactly what you are attempting (the dynamic thing) but I think that is why dynamic routing exists.

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

[Alex Puzikov]

Hi Kevin.

We are currently supporting multiple Cerner Millennium domains and multiple epic environments in our cloverleaf test.

In our case patient data originates from Epic and goes to Cerner and charges coding etc. – coming back from Cerner Millennium to Epic.

We made a decisions to route patients to Cerner specific domain by first letter of their first name (Bob goes to Build, Tom goes to Test).

We also made a dessision on Epic side to have different ranges for MRNs and ACCOUNT Numbers so Epic Test would have MRN range of 600000, Dev range of 700000, etc.

SO messages that come back from Multiple destinations will be routed back to Epic by MRN ranges.

To manage that and preserve similarity between Cloverleaf Production and test we created additional routing site and pointed our test site to that site.

We also modified our inbound threads to become a MultiServer  (accepting connections from more than one system).

All destination routing done in the routing site (by simple trix_id script) and does not affect any work that done in the Cloverleaf.

The only side effect (positive or negative you decide)  is that any changes that done in Cloverleaf Test immediately affect all downstream systems regardless of domain.  

I hope this helps.

Alex

[dante rand]

Hi Kevin & Alex –

We do something similar to Alex but use the patient last name as the domain – so MHBLD, MHDEV, MHCRT, MHMK – are the first digits of the last name.

[Author]

Replies