vendor wants our CL tcp/ip outbound thread to ‘offer’ msgs

This topic has 12 replies, 4 voices, and was last updated 7 years, 9 months ago by Peter Heggie.

Creator

Topic
May 8, 2017 at 8:38 pm #55385
Peter Heggie
Participant
I’m probably just not able to wrap my head around this concept..

We have a tcp/ip thread set as outbound-only that connects to a vendor interface, which has been working fine since July.

They are upgrading their application and their server and now they want this Cloverleaf interface, which is outbound from us to them, to act as a server, such that they would connect and pull messages from us.

I have only dealt with interfaces where either an interface is a client or a server, and if it is a client, it is pushing messages to another endpoint, or it is a server, and some other endpoint is pushing messages to it. This seems to be as third option..

Am I missing something? How would I configure this?

Peter Heggie
PeterHeggie@crouse.org
Creator

Topic

Viewing 11 reply threads

Author

Replies
- May 8, 2017 at 9:59 pm #85140
  Max Drown (Infor)
  Keymaster
  You can configure the protocol to act as a server instead of a client and it will work just fine. But the interface will push the messages across just like it normally would. If they are wanting to query Cloverleaf for messages, perhaps you could store them in a SQLite database and use the web services protocols?
  
  -- Max Drown (Infor)
- May 8, 2017 at 9:59 pm #85141
  David Barr
  Participant
  Just go into the protocol and change it from client to server. It can still be an outbound only thread.
  
  The conventional way of setting up interfaces is that the sender is the client and the receiver is the server, but there’s no technical reason why you can’t do the opposite.
- May 9, 2017 at 12:15 pm #85142
  Peter Heggie
  Participant
  It seems to work – thank you both. I changed the TCP/IP Options Type to server, and touched nothing else, and restarted. Two messages were in the queue and were picked up.
  
  The inbound SMATDB has two new ACK messages and the outbound SMATDB has multiple messages from yesterday – when the messages first came into the outbound queue and then waited there (until today, when they were picked up).
  
  I’ll keep an eye on the queues and have more test transactions sent through.
  
  Peter Heggie
  PeterHeggie@crouse.org
- May 9, 2017 at 12:59 pm #85143
  Peter Heggie
  Participant
  We had another message go across, so I think this is working.
  
  But every 5 minutes we get this in the log:
  
  [pdl :PDL :ERR /0:to_financials:05/09/2017 08:43:47] read returned error 0 (Error 0)
  
  Not sure why – should we change the Auto-Reconnect option (currently enabled) or the Delay connection until needed (currently disabled)?
  
  Peter Heggie
  PeterHeggie@crouse.org
- May 9, 2017 at 1:16 pm #85144
  Max Drown (Infor)
  Keymaster
  Wouldn’t hurt to try in this case. I suspect you may just have to live with this error in the log if the client connects and reconnects all day long.
  
  -- Max Drown (Infor)
- May 9, 2017 at 1:21 pm #85145
  Peter Heggie
  Participant
  OPENLINK – ARGG!
  
  Peter Heggie
  PeterHeggie@crouse.org
- May 9, 2017 at 1:23 pm #85146
  Max Drown (Infor)
  Keymaster
  Openlink is the connecting application?
  
  -- Max Drown (Infor)
- May 9, 2017 at 1:52 pm #85147
  Peter Heggie
  Participant
  I believe so – we have four connections, two are OpenLink and two are direct to the application, I think this is one of the OpenLink connections.
  
  Peter Heggie
  PeterHeggie@crouse.org
- May 9, 2017 at 4:30 pm #85148
  Michael Hertel
  Participant
  Point out to them that they are dropping the connection every 5 minutes and that you need a persistent connection to avoid your alerts going off.
  
  They probably don’t realize that they are doing that. I find connecting with Mirth on the other end has this happen until I bring it to their attention.
  
  Even if your alerts aren’t going off, tell them that they are so that they know this is important to you in a production environment.
  
  I don’t mind them bouncing once or twice a day, but when you can see this type of stuff going on, it needs to be addressed right away.
  
  At a minimum have them change the cycle time to once every 12 hours instead of the 5 minutes.
  
  My 2 cents… 🙂
- May 9, 2017 at 4:43 pm #85149
  Peter Heggie
  Participant
  thank you – I will ask them. We have a call in a few minutes…
  
  Peter Heggie
  PeterHeggie@crouse.org
- May 9, 2017 at 7:20 pm #85150
  Peter Heggie
  Participant
  I found out this is not OpenLink. The interface functionality is built into the ancillary system.
  
  I resent three messages and they were all picked up immediately. Then when the 5 minute interval passed, I got the error message. Still, the interface is working and messages are flowing. Its just annoying at this point. I asked for them to look at the connection loss every 5 minutes and they could not find this evident at the time of the conference call, so they are taking it as an action item.
  
  I tried different variations of Auto-reconnect, Delay-connection and Close After Write (the latter took the interface down). But I’m pretty sure it is not on our side.
  
  Peter Heggie
  PeterHeggie@crouse.org
- May 10, 2017 at 7:17 pm #85151
  Peter Heggie
  Participant
  The rest of the story – it is OpenLink. After looking at it, I realized I had another outbound thread in the same process and it was that thread’s messages I was seeing.
  
  So this had nothing to do with changing the outbound thread from a client to a server. It was a different outbound thread, connecting to OpenLink. I’ve asked someone to confirm that this is the OpenLink ‘Disconnect On Idle’ setting.
  
  Peter Heggie
  PeterHeggie@crouse.org
Author

Replies

Viewing 11 reply threads

The forum ‘Cloverleaf’ is closed to new topics and replies.