Has anyone ever had a need to control the speed of delivery of documents to a particular partner? Normally we deliver documents as they come in and deliver them individually (asynchronously) to whoever should get them. One partner can’t handle the docs we’re sending, so we’re looking at the possibility of sending them sequentially with a small gap of time in between. We use delivery services which call a web service to deliver the docs.

I’ve been using TN for years and don’t think it’s provided out of the box, but thought I would double-check.

Have you looked into scheduled delivery using delivery queues for the trading partners. In there, you can put a small lapse of delay for each msg delivery.

I think you’re referring to the delay in between each retry upon failed delivery attempt…

Wkriski,

Ylo is actually talking about the Delivery Queues that TN provides. See chapter 16 of the TN User’s Guide 6.1.

• Percio

My thought is the same as ylo’s and Percio’s–try the scheduled delivery facilities instead of the immediate delivery to pace things.

I’ve read about scheduled delivery. At certain times, it will trigger all the queued tasks to be sent individually or in batch. I’m asking if you can control the speed of outgoing docs as they are sent individually to one partner. I haven’t seen it in the docs. I’d appreciate it if someone could respond who’s actually done it. ;o)

Wkriski,

There are built-in TN services that allow you to create your own delivery service (search for Delivery Service in the TN User’s Guide.) Therefore, you could still use the TN queues, but have your own delivery service retrieve the queued documents and deliver them to the partner one by one at whatever pace you’d like.

HOWEVER, is it really worth it? Should you be adding this much complexity to your system because one Trading Partner can’t handle the speed in which you’re sending the messages? By the way, what is the exact problem they are claiming to have?

In my humble opinion, if your partner can’t handle receiving the messages in real-time, then I’d suggest staying away from synchronous real-time communication. FTP, for example, may be more suitable. Don’t cripple your system to work-around someone else’s inefficiencies.

• Percio

If I’m reading your comment right (no guarantees on that!) batch delivery doesn’t wake up all the tasks at a certain time. Meaning, if you have 10 tasks in the queue, it doesn’t wake up all 10 tasks to go simultaneously. It loops through each of the tasks in the queue and delivers the associated doc one at a time. Serial delivery. Is that what you need?

If you need a delay between each task/document even in a serialzied mode, then you’ll want to implement what Percio described for the custom batch delivery service. I’ve done this particular thing before, though I haven’t throttled the pacing (e.g. no sleep between docs–just get a task/doc, send it, get a task/doc, send it, etc.).

I ended up abandoning the use of TN public queues because of the persnickety nature of the task objects. If you didn’t manage the task status exactly right, there’d be problems. Even when you try/catch everything and set the status, there were cases where things went south that we couldn’t figure out (this was in 6.1 days–may be better now). So instead of public queues we ended up using User Status and doc queries to manage queuing and batch delivery.

Hope this info helps!

Rob,

That’s interesting! Over here, we actually started with User Status and queries because queues weren’t available back in 4.x and then we moved to queues once we upgraded to 6.1. Hopefully, we won’t run into the problems you ran into and have to switch back. Fingers crossed!

• Percio

That is indeed an odd turn of events!

I agree that it doesn’t make sense to create this due to client issues.

It seems that queues with scheduled delivery would pass a batch of documents to my service so I could then control how I delivered them. But iit looks like they expect you to send them as a batch (so that it can be retried as a whole). This opens up other questions - if I loop around the docs and http each one do I have the ability to retry each http request (which I currently do with the individual delivery) and what happens if something fails in the loop. Does TN send the entire batch to the delivery service again…

My client has some previously written custom code to do queueing as well (not sure why). I have also seen strange behavior with tasks and it does add complexity with a lot of tasks being created and having to be managed.
Thanks to everyone who responded.

Each msg to be delivered is put into a delivery queue as a task. If one task fails, it will flag that as failed only. You can then create another service to re-execute any failed delivery task at a later time, say every hour or so.