Problems with ACK processing with HSM billing interface

[Alice Kazin]

We are having problems with our ACK processing for this particular inbound connection from HSM.   The vendor indicates that they are timing out before receiving our ACK.   Therefore, I turned on ENABLE_PDL engine output.  What I am seeing is multiple copies of the same message received in one buffer.   In one example, I see the same message four times with the proper MLP separators – 0b at the beginning and 0d 1c 1d 0d at the end of each of the 4 messages.  I sent back two ACK messages. Then I received the next message which only contained 1 message.  This type I sent the other 2 ACKs from the first message followed by the ACK for the message.   Is there anything I can do on the Engine side to resolve this problem?  When I send back multiple ACKs, they kick them out as invalid.   I am also creating duplicate charges.

Topic

[Chad Flodman]

We also have HSM and we haven’t had any issues with the charges / ACK processing.  So I checked our set-up in HSM for their interface set-up.

HSM Interface Configuration GUI: Connection Info > Global TCP/IP settings:

ACK Error Handling: set this to NO

(Should the interface end TCP/IP charge message output for a bad or timed out ACK)

Then I just use the standard create_ack tcl in the IB Data TPS for the protocol thread for the inbound charge messages.  This prevents HSM from dropping the connection or stopping the charge message transmission if they don’t like the ACK they get.

[Alice Kazin]

Chad, we are not doing anything special in our Ack proc which we use everywhere  but could you send us a copy of your ACK proc.

[Russ Ross]

Alice Kazin:

I can’t speak to your specific situation but I can share something similar that your situation reminds me of.

I was attempting to do a real-time charge integration many years ago from our Anatomical Pathology system (Tamtron).

I ended up with duplicate charges once the charges passed through the cloverleaf integration engine.

After investigating, I found the cloverleaf listener interface took about 10 seconds to startup.

This 10 second startup on cloverleaf caused the Tamtron foreign interface sender to do about 10 resends.

By the time the cloverleaf interface listener was up and running I already had the same charge queued up 10 times.

Each of the 10 duplicate charges were encapsulated properly and not concatenated like your situation.

I was able to eliminate the problem by having the vendor set their resend rate to higher than 10 seconds.

However, I decided I would never be comfortable with a real-time billing interface because there are other ways to generate undesired resends/duplicates.

It was at that point I decided to play it safe and only do batch integrations for charges.

If I absolutely had to do a real-time charge integration, I would add as much checking of sequential sequence numbers as possible to gain confidence no charges are duplicated as the result of any resend issues along the way.

Russ Ross
RussRoss318@gmail.com

[Chad Flodman]

Alice:  Here is the ACK process I use on most every thread.

Also, Russ raises a valid point the inbound protocol thread on cloverleaf must be started first to give cloverleaf time to be up and waiting OR the HSM settings must be set to delay transmission until x seconds post connection.

I’ve included the following inbound protocol thread information from my HSM connection:

Auto-reconnect time is set to 5 seconds

Outbound Replies–> Retries -1 (indefinite)

Outbound Replies–> Interval 10

[Alice Kazin]

Thanks Chad for the tcl proc.  Our settings are the same as yours.

Our reply tcl proc is very simple.  I added our tcl proc as an

attachment.

[Alice Kazin]

Does anyone have a tcl proc they would be willing to share where they do sequence number checking in an Inbound interface?

[Alice Kazin]

We found the source of our slowness in returning ACK to Inbound connection.  One of our TCL procs was changed to include “SLEEP 120”. We removed the Sleep command and are having no more Errors.

[Author]

Replies