Routing Messages Intermittently

[Jon Melin]

Hello,

I am setting up a several new routes to a new test destination with the catch that this destination will only want messages for a certain period of time, intermittently. So an hour now, then connected for another hour tomorrow sometime, etc. I do not want messages to queue up in the recovery database and send once connectivity is re-established because the destination side will not like hours of saved messages coming at once.

I would prefer not to add and remove the routes every time we stop connectivity.

Is there a typical “rule of thumb” for this type of scenario? Are you all using the forward feature and sending them to the void? Are people just disabling the recovery database for that thread and letting the destination side stop connectivity, or are people just adding a kill tcl to that threads outbound?

On a side note, other traffic from this source thread (to other destinations) needs to stay up and running the entire time (thread cycles are ok).

Please let me know if you have any ideas of the best approach.

Thank you,

Jon

Topic

[Jim Kosloskey]

Jon,

So the receiving system wants to receive messages:

– whenever they are ready – at no particular time

– don’t want any messages which may have been available in the interim.

Do they control the connection? In other words do they bring their connection up when they want messages and stop it when they don’t?

If the above is true possibly this will work:

At the route pre-route use Tcl to check (via msi stats?) the state of the destination thread. If it is not ‘UP’ kill the messages other wise route the messages.

You will check with every message and whenever they have their connection up they will receive messages. This will not interfere with the other routes and their message will only be in the Recovery DB until the route.

personally unless I knew more I would dope slap these guys  🙄

email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 60 years IT – old fart.

[Jon Melin]

Jim,

They can control the connection and your assumptions are correct. I will have to see if their end automatically sets the connection to show UP status instead of waiting until another message comes through.

I haven’t used the msi stats yet but I will take a look and see what I can make happen. I appreciate the suggestion, that sounds like the best approach so far.

Yes – it’s an odd request yes, but I think it’s due to a limitation 😀

Thank you,

Jon

[Russ Ross]

I searched my posts for msi and got a hit that will provide you some example TCL source code of using msiAttach and related commands to access thread stats.

The proc I post that illustrates usage of msi stats at this URL is called oth_get_stats:

<a href="https://usspvlclovertch2.infor.com/viewtopic.php?t=4063&#8243; class=”bbcode_url”>https://usspvlclovertch2.infor.com/viewtopic.php?t=4063

Off the top of my head the status might be a numeric value (ex: 1, 2, 3 …) instead of a word like UP.

Russ Ross
RussRoss318@gmail.com

[Author]

Replies