Message control Ids do not match - ever

[Coooz]

Hi,

With a customer of ours, all sent messages get an ERROR status because of not matching control ids:

The destination is a TCP Sender. Keep Connection Open is set to No.

In an attempt to solve it, we copy the last incoming message, stop the channel where the messages come in - which is a TCP Listener - provide a different port number and redeploy this channel. Then we send this last message again to the new port number, using a different app.

The idea is that the sending system doesn't recognize the new port number and won't therefore be able to deliver new messages, so this way we as it were put in 1 extra message to make up for the difference of 1 in the control ids.
If we see in the app that an MSA is returned with a control id that matches the one we sent, then we can assume the messages to be in sync again, and we restore the original port number.

An example - maybe not necessary but just to make sure it is clear: the last message sent by the sending system has control id 6 and returned control id 5. The app sends control id 6 again and returns the next control id: 6 . The next message sent by the sending system will have control id 7 and since control id 6 has already been returned, control id 7 will be returned as well.

This approach has worked with other customers in the past - but now it apparently doesn't. Mirth Connect 4.4.2 is used. The difference between the control ids is always 1.

What could be the cause of the control id mismatch, and what would be a different approach to tackle the problem?

[pacmano1]

If the messages are otherwise successful, just disable the control ID check on the sender. You'd have to ask them why their control IDs are mismatched.

[pacmano1]

I should probably add that I've only seen this once in about 15 years. And the other side recognized their problem and fixed it. There was no middleware or other integration engine in the middle. Also, using an incremental values for message IDs is typically not done. Instead, a UID or a date time stamp with sub seconds.

You should Google / chatGPT best practices on that. Your current practice is not best practice.

[pacmano1]

There is one other option - in that red box you could create a channelMap var that is +1 for your ID and validate that ID.

So things to do:

1. Don't use incremental numeric IDs for MSH-10, they are not unique.
2. Tell the client to fix there stuff
3. last resort - modify stuff below

 

[Coooz]

Thanks for replying @pacmano1 .
Unfortunately using anything other than an incremental number in MSH.10 is not something I'm allowed to change. But I'll keep it in mind for when revisions are planned.
I've found that the problem is indeed at the customer's site. Sending messages fails at about 30% of the time, probably because of their network. I highly suspect that to be the cause and I've asked them to delve into it. The messages that do get sent are indeed successful, so I've suggested to disable message control id validation to prevent further errors.