inter-site routing error

[David Barr]

I’m running 5.8.4, and I’m trying to use a destination to route from site1 to an outbound thread in site2. Then in my outbound thread (in the outbound tps), I’m trying to return the message with an OVER disposition so that I can route to other threads in site2. I also set the SOURCECONN in the metadata to the first thread in site2.

This proc that I use to OVER the message works when I use it on outbound threads with a source in the same site, but the inter-site routing is causing an error. This is the error that I’m getting in the process log on site2:

[xlt :form:ERR /0:    adt_xlate:11/22/2011 15:05:59] Can’t get format type for trxid.

[xlt :form:ERR /0:    adt_xlate:11/22/2011 15:05:59] XLATE Format DATAFORMAT load for epic_adt_in failed

[xlt :xlat:ERR /0:    adt_xlate:11/22/2011 15:05:59] Cannot find data CnxnFormat for ‘epic_adt_in’

What does this error mean? “epic_adt_in” is the original source thread in site1 that doesn’t exist in site2. I’ve tried changing the trid determination to several values (hl7, upoc, field) and there are no xlates being used in the threads that are involved.

Topic

[David Barr]

Perhaps I need to phrase my issue more generically.

We have inbound threads in site1 that need to be sent to multiple outbound threads in both site1 and site2. Prior to 5.8, we would make an outbound thread in site1 that would make a tcp/ip connection to an inbound thread in site2, then we could route to multiple threads in site2.

When I heard that 5.8 supported inter-site routing, I thought it sounded great. I can get rid of the tcp/ip connection, and I can let Cloverleaf handle the routing, and my message metadata is now preserved, too.

The problem is that inter-site routing sends messages to outbound threads in site2. That means that I need to create a destination in site1 for every single outbound thread in site2. This seems pretty inefficient, especially considering that Cloverleaf is using tcp/ip to do the routing. I now have to manage inter-site port numbers for every destination rather than a single port for all routing from site1 to site2.

I thought I could work around this problem by using “OVER” to turn the outbound destination thread into an inbound thread, but I’m getting the xlate error. So unless I hear any better solutions, I’m back to using my own tcp/ip localhost thread pairs for routing instead of native inter-site routing.

[Mitchell Rawlins]

I came up with a nearly identical approach to inter-site routing on our systems, and hit the same snag.

[David Barr]

What we ended up doing was renaming the public thread in the second site to have the same name as the original source thread in the first site. This got rid of the errors. Also we reported the problem to Lawson as a bug which they will hopefully address in a future release.

[Mitchell Rawlins]

I found something that seems to work.  In my proc to  OVER the message, I first set the SOURCECONN metadata to the thread name in the destination site.  I’m using a Java UPoC for this.

Code:

public class Resubmit extends TPS {

public DispositionList process(CloverEnv cloverenv, String context, String mode,
Message msgobj) throws CloverleafException {
DispositionList dl = new DispositionList();
if(msgobj == null){
return dl;
}
msgobj.metadata.set(”SOURCECONN”,cloverenv.getThreadName());
dl.add(DispositionList.OVER,msgobj);
return dl;
}
}

The Tcl equivalent using msgmetaset should be just as straightforward.

The thread name could be hard-coded in, or passed as a parameter, with different pros and cons for each option.  I initially tried setting the SOURCECONN equal to the previous DESTCONN (because presumably that’s where we are now); this didn’t behave well with the inter-site messages.

[David Barr]

That’s a good idea. I’ll have to keep that in mind if we need to make changes to our code.

[David Barr]

I just double checked our code, and we are already setting SOURCECONN and it wasn’t working, so maybe we are doing something else differently.  Here’s the code we use:

Code:

       run {
           # ‘run’ mode always has a MSGID; fetch and process it
           keylget args MSGID mh
           msgmetaset $mh SOURCECONN $HciConnName
           lappend dispList “OVER $mh”
       }

[Mitchell Rawlins]

That’s really quite bizarre.  I’ve been running tests most of the afternoon and haven’t had trouble.  We’re on 5.8.4 right now, for what it’s worth.

I’ve currently got a proc that I use for troubleshooting that outputs a bunch of the metadata fields.  For one message, I get this in the outbound: (before the OVER proc)

Code:

XLTTHREAD:
SKIPXLT: 0
CLASS: engine
STATE: 10
DESTCONN: xt_radord:vm-engine-d2:10700:epic_rad::xt_radord
SOURCECONN: ib_epic_adt
ORIGDESTCONN: xt_radord:vm-engine-d2:10700:epic_rad::xt_radord
ORIGSOURCECONN: ib_epic_adt
com.quovadx.cloverleaf.upoc.MessageMetadata@8a0d5d
driverctl:
DATAFMT:

And this on the inbound (after the OVER proc)

Code:

XLTTHREAD:
SKIPXLT: 0
CLASS: protocol
STATE: 1
DESTCONN: xt_radord:vm-engine-d2:10700:epic_rad::xt_radord
SOURCECONN: xt_radord
ORIGDESTCONN: xt_radord:vm-engine-d2:10700:epic_rad::xt_radord
ORIGSOURCECONN: ib_epic_adt
com.quovadx.cloverleaf.upoc.MessageMetadata@173831b
driverctl:
DATAFMT:

There really won’t be a Tcl equivalent to the com.quovadx line, but otherwise all these should be accessible in Tcl.  It goes through TrxID normal for us.

Your code looks good as near as I can tell; I may plug it into our test system and give it a whirl to see if it really works any different than the Java proc.

[David Barr]

What kind of route are you using from your public thread to your outbound thread?

[Mitchell Rawlins]

It’s an HL7 wildcard raw (with UPoC).  If Xlate looks at additional metadata fields that aren’t re-set then that could cause trouble.  

One option I considered was creating a new message, copying the content from the old, killing the old, and re-submitting the new.  There would likely be a performance hit doing it that way, and I’m not sure it’s worth the effort at that point.  It seems that as long as SOURCECONN is set right that the raw works okay.  Some of the other route types may require DESTCONN to be re-set, though I’m not sure what to.

[David Barr]

I think the route type is probably our issue. Changing the thread name allows us to use HL7 Trx id routing.

[Author]

Replies