Start with Hold Inbound

[Paul Johnston]

Hi All,

We have built Inbound Threads to accept data from our Meditech system.

We originally had issues with the thread staying up and we switched to Multi-Server thread configuration.

When we use the ‘start with hold’ option on the Inbound threads it does not Hold the messages.

Is this because of the Multi-Server configuration ?  What would be other reasons or thoughts on what is causing the anomaly.?

Thank you

Topic

[Keith McLeod]

I believe hold typically works on the outbound queue. So on an inbound thread you would most likely be holding your reply messages from going out.

[Paul Johnston]

Thanks Keith.

I just tried on the Outbound thread and it works.

I thought for sure I was able to use the “Start with Hold” on the Inbound thread before.  😕

Can anyone at Infor confirm if this functionality should be working on any thread, Inbound or Outbound.

Greatly appreciated

[Jim Kosloskey]

Paul,

What is it you are trying to accomplish by putting the inbound on hold?

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

[Paul Johnston]

Hi Jim ,

With the Inbound on Hold we would be able to queue the messages in the

Meditech (source) system therefore not holding ALL the messages in the Engine. We are expecting several thousand messages to be queued in Meditech which will be routed through the engine.

Hope that makes sense, Jim

Thanks

[Jim Kosloskey]

Paul,

That makes sense but can Meditech really queue the messages without issue?

Is this an exception situation (meaning normally would not want Meditech to queue)?

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

[Keith McLeod]

Holding the reply is a valid way of causing the sending system to pause. Are you looking to slow down or regulate the flow from Meditech?

[Paul Johnston]

Jim ,

That is correct and that is our hope, for Meditech to hold the messages as I have more concerns with them being held in the Engine.

Keith ,

Yes, we were also hoping to throttle / regulate the messages from Meditech?

As I mentioned to Jim , having concerns of the number of messages held in the Engine.

[Jim Kosloskey]

Paul,

Be careful if you plan on using Tcl to pause for some period of time before sending the acknowledgment as that will likely pause the entire process.

If it were me I would make sure Meditech can indeed queue the messages without loss or siezure rather than hope.

I would imagine the messages should move through Cloverleaf rather quickly – unless receiving systems cannot keep up (that is another issue which should be addressed with those systems). However, some archtectural design can isolate the impact of some receiving systems not keeping up.

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

[Paul Johnston]

Hi Jim ,

Thanks for your insight. Our situation is tricky in that our GOLive is not until this Saturday. We are converted all of our Interfaces with addition of some new ones but we are not starting all of them at the same time. Messages will need to be queued somewhere.  It will take some clever logistics no matter how we look at it.

Let it be known I am not having a good time with Meditech.

Thank you .

[Author]

Replies