Dropping xlate output msg not in RESEND_DEST_OVERRIDE list

[Noel Field]

I am trying to resend a message using the ide and i receive t his error. I posted a question similar to this in 2014 but i never understood what caused it nor did i understand why it suddenly went away . Sunspots perhaps. Would greatly appreciate any insights y’all might have on this topic

Topic

[Robert Kersemakers]

Hi Noel,

We see this behaviour on occasion as well and I couldn’t put my finger on it either. So did a few tests and I think I figured it out.

We have a few jump/hop threads:

Code:

A -> B_out

B_in -> C
    -> D

So thread A will route to B_out, which is a tcp/ip connection sending the messages on to B_in. B_in will route to C and D.

Normally we will keep a smat of all threads, but in this case it’s weird to keep smats for B_out AND B_in, as the messages are the same. So we only keep a smat for B_out.

Now, if you take messages from smat B_out and resend them from B_in (inbound post), then you will get this message in the log:

Code:

[xlt :xlat:WARN/0:adt_out_xlate:09/01/2016 11:00:25] [0.0.177374793] Dropping xlate output msg not in RESEND_DEST_OVERRIDE list: B_out
[xlt :xlat:WARN/0:adt_out_xlate:09/01/2016 11:00:25] [0.0.177374795] Dropping xlate output msg not in RESEND_DEST_OVERRIDE list: B_out

So the engine notices that the messages are originally destined for another thread and you haven’t specified ‘destination threads’ while resending, so it will not process these messages. Problem here is that ‘outbound’ messages are suddenly used as ‘inbound’ messages and in the metadata it says to which thread the message needs to be routed.

If you have a smat on B_in and you resend messages from that smat, then all will work.

So to solve this you either specify destination threads when resending or uncheck the box ‘Include Metadata’ when resending or you will need to define the smat on B_in instead of B_out.

Zuyderland Medisch Centrum; Heerlen/Sittard; The Netherlands

[Noel Field]

Thanks so much for the quick reply and explanation… i really appreciate it

Thanks again

Noel Field

Centra Health

[Peter Heggie]

I appreciate it too! We have the same situation and to save space we are saving only one copy of the message. So if we resend from that copy, but send using different inbound and outbound threads, we will have the same problem. So now we know to specify both inbound and outbound threads, even if there is only one outbound thread.

Peter Heggie
PeterHeggie@crouse.org

[Robert Kersemakers]

That was the theory…

A few days ago I needed to resend some 200 messages again and remembered that I should specify the destination thread. I did, and still got the errors. It was late, I was irritated that I made a mistake causing messages to fail/not get send on, so tried some things which all didn’t work (including not sending the original metadata, I think).

In the end I resend from the outbound (B_out) thread. Grrr… Should try to replicate this, when I have some spare time left; I now think you need to do both: specify destination threads AND uncheck ‘Include Metadata’.

Zuyderland Medisch Centrum; Heerlen/Sittard; The Netherlands

[Robert Milfajt]

Robert, spare time?  What’s that?

Robert Milfajt
Northwestern Medicine
Chicago, IL

[Jim Kosloskey]

That tis the post-mortem time (your post-mortem) 😆

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

[Robert Kersemakers]

I know, right? Once upon a time…

Zuyderland Medisch Centrum; Heerlen/Sittard; The Netherlands

[Steve Williams]

I recently ran into this same issue where we’re using the feature “Messages routed to this connection treated and inbound.” Which means I no longer have to use a TCL script to OVER the message to chain threads.

The problem appeared when we resent a few ADT messages from the ADT root thread to the NICU group. Once the messages hit the middle man thread and get “re” routed, the RESEND_DEST list caused all the messages to get killed inside the engine. I call these middle man threads “recirculators.”

Until Infor can address the issue, I wrote a TCL script to handle the issue of clearing the RESEND_DEST list when appropriate for the Recirc threads so the support team doesn’t have to second guess “from where” the resend messages at 2 AM.

Script is attached.

[Peter Heggie]

Thank you so much for your code, and the work behind it. I had a similar issue where I have to OVER a message from the outbound queue to the inbound queue, and it would not route to its new destination because that was not the same value in the original RESEND_DEST_OVERRIDE list.

Peter Heggie
PeterHeggie@crouse.org

[Jon Blanchard]

Cloverleaf 6.1.2 on AIX.

I am experiencing this issue but, using the example that Jim presented:

Code:

A -> B_out

B_in -> C
    -> D

I am sending from the B_in smat file, setting the destination thread and unchecking the “include Metadata” checkbox.  Still getting the RESEND_DEST_OVERRIDE response.

Migration Consultant
Coffee Regional Medical Center
Eastern Time Zone

[Steve Williams]

Hi Jon,

  If I read your post correctly, you should not get that error at all. As your SMAT source is B_in and the selected destination should be either C or D (or both). In this case, it’s just a normal resend (with or without metadata).

If this is the case then you’ll need to enable_all engine output on the B_in thread and try the resend again and then inspect log for the errors. If you did get that error, then I suspect there’s more to your situation than just

A -> B_out  ==>  B_in -> C, D.

[Author]

Replies