“A delivery service is a service that TN invokes to deliver documents to trading partners.”
Understood. Was offering a hack in which the “delivery” service didn’t deliver but retrieved instead. Here’s what the queue facility does (for readers that are not familiar):
Configure a public queue. Give it a name. Set up a schedule for it to invoke a delivery service periodically. The services you can pick from to execute are limited to those that are registered as delivery services.
Once established, documents can be placed into the queue via processing rule action.
When the scheduled task fires, it invokes the configured delivery service, passing the name of the queue as a parameter. The service is executed on the schedule, whether or not documents are in the queue.
The service is expected to use the queue name to retrieve queued documents (actually, tasks are on the queue, which are associated with a bizdoc–but that’s a detail for another discussion). If no queued docs exist, then the service is expected to just exit. For each document on the queue, the service transpots the contents however it sees fit. It is expected to retrieve profile info if needed/as appropriate to get the transport config.
The service that is invoked can do anything it wants, in reality. It doesn’t have to read anything off the queue. It can perform any activity at all. If one doesn’t put documents on the queue, then you’re essentially using the public queue and its scheduled task as a job scheduler. In Jey’s case, the service could poll the VAN to retrieve documents.
Why would someone want to do this? Wouldn’t it be better to just use the IS Admin scheduled task screens?
The nice thing about the queue config is that you can set parms on the scheduled service, unlike when using the IS Admin to setup the scheduled task. This would avoid the need to use a wrapper service, which you had indicated you wished to avoid.
But if you’re willing to do a wrapper, here’s an approach that might be acceptable:
Write a polling service. It would read connection config information from the appropriate profile. Either hard-code the profile name or figure out a way to externally specify it (config file, system property, whatever). Or put the connection config in your own config file (duplicating connection info, which may or may not be a big deal).
Use that info to call getFromVAN with the right parameters. If you have getFromVAN submit to TN, the service is done. If you don’t, you can do whatever you need with the retrieved files (bytes/stream).
Use IS Admin to schedule a task to invoke your poll service.
“And the pulled files needs to be submitted to TN using some file polling mechanism.”
getFromVAN can submit the retrieved file(s) directly to TN right away. It has a parm to indicate to do that or not.
I agree that it would be nice if TN provided a VAN/FTP server polling facility that wouldn’t force us to write additional services and store config info in another spot.