Holding Future Orders on the Engine

[glo3trips]

I am working in monk 4.5.3 and have been asked to hold Future diet orders on the engine until midnight of the current day they are ordered. If you have any ideas, I would greatly appreciate hearing them. Thank you in advance.

 

[Kozusnik]

Within your outbound eWay, you could set times for it to start and stop. Just let the messages queue up during the day.

Or capture all of the messages with an outbound file eWay, then schedule a perl script to read the file and pass each message to a local tcpip eway at midnight.

I'd use the first. Although I haven't played with that functionality.

Mark

 

[Kozusnik]

Not sure if I answered the right question...

Are you having trouble holding them, or deciding if they are actually "Future" orders?

Are you using Monk or Java?

On our HIS (ordering system), we set a flag to tell when the future orders leave the system. Future orders will transmit 3 hours before they need to be completed. Maybe that's another option for you.

Mark

 

[glo3trips]

I will try this, the orders are coming out of Cerner, so what I have been asked to do. Is send the current orders on, and hold the future orders on the engine. So that is why I am thinking another file eway.

 

[Kozusnik]

You could create two etds, publish the regular orders as one and the future as the other. Create a bob to start and stop (I think you can do it with bobs --- it's been a while). The new bob checks the iq for the new etd and passes them along.

Let me know if you get it.

Mark

 

[glo3trips]

See, I started to think about a bob, but I went away from this. It wasn't making sense. But, now that you are bringing it up again, it makes me wonder if I was close.

Maybe if you elaborate a little more the light bulb will click on, if you know what I mean.

I appreciate your feedback here.

Thank you

 

[kontreren]

I would stay away from the start/stop feature on the eway properties startup tab if that is what is being referred to. I've heard ugly storys that once set it will never go away even when you change it unless you delete the component entirely and start over. I do not know if this has been fixed in 4.5.3 or not.

One possible solution on the outbound eway is to use a single event type, a single collab and translate either message to the receiving systems desired format. Inside the collab, after the translating is done use an IF statement to determine if it is current or future order. For future orders write them to a file in a local directory somewhere in a subdirectory (just make sure you use the same filesystem) then do the usual (copy "" ~output%RootNode:0-END "") thing to tell egate suppress publication to External but ack the queue as if you published. For the current orders you simply do nothing in the else part and it will fall out of the tsc file and egate will forward it to the external. NOTE: You will want to open, append, close the file with each message.

Then you have an inbound batch eway that is scheduled to pick up the file you created above at midnight, ensure the interval is set to pickup only once per day. If you are concerned or have problems with file contention then might I suggest a date function in the aforementioned outbound (inside the IF FUTURE ORDER) that says if current time = midnight then sleep 10 seconds. You can tweak the sleep time in accordance with how long it takes to read the file. Unix file I/O is so fast these days it should pick it up in a snap.

Just one idea.
kontreren

 

[Madere]

Why not keep the orders (= messages) in the queue and use the schedule eWay to create your outgoing messages at the time you wish?

The schedule event should be generated around mignight in your case. Then read all orders from the queue and do what ever is needed with them.

 

[kontreren]

Madere, What if you do not have the schedule eway. Is it a free offering from Sun/SeeBeyond? For some of my projects I would be using the Oracle Native eWay if it didn't cost a fortune. I really do not know the current status of ordering adapters for the 4.5.x versions. If you already own the schedule eway then absolutely. I was under the impression that the poster, glo3trips, didn't have that eway adapter at their disposal.

 

[bgollifer]

If you are using java and a jms queue you should look at els event linking and sequencing. I think there might be some options in there to set things loose from the queue based on times.

 

[Kozusnik]

I have used the start/stop feature of the eWay and it works well. The other option is to use the sleep function. To use it, you need to create and initialization file with one fully qualified path to the dll which has that function.

Mark