The task is to retrive documents from VAN based on a specific time interval. The existing queue mechanism in TN can put the outbound files and get the inbound files from VAN. But the polling happening only if any outbound documents are available to deliver to the VAN.
Is there any better way to poll the VAN for inbound documents using the TN queue mechanism?.
This can be achived by writing a flow service and scheduling it in IS. Would like to use TN and trying to avoid flows.
You may be able to use the TN queue facility.
Register a custom delivery service. The docs have instructions for this. Probably use VAN.VANConnectivity:getFromVAN in the WmTNforEDI package as the service.
Define a public queue. Set the delivery service to the one you just registered. Set the inputs as desired (getFromVAN has a bunch).
Set the schedule.
Not sure if this will work but it may be worth a try.
Rob:
A delivery service is a service that TN invokes to deliver documents to trading partners. Again this service will be executed when you have some documents to be delivered to partners.
I can directly use getFromVAN in a wrapper and schedule it. But this is an overhead because the connectivity details needs to be hard coded again in wrapper. And the pulled files needs to be submitted to TN using some file polling mechanism.
wM should include this in TN as feature to create a automic polling queue to pull documents.
“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.
HTH
Jey:
From your first post: “But the polling happening only if any outbound documents are available to deliver to the VAN.”
This is not a complete picture. It’s true that the connection to the VAN doesn’t occur unless there are docs to deliver, but the scheduled task does indeed fire. It’s just that the putToVAN service doesn’t do the get unless it first does a put.
So yet another solution would be to clone the putToVAN service (it’s a FLOW service so you can copy it). Or you could modify the existing service, but you’d need to be careful about upgrades. The change needed would be to simply disable the first BRANCH that checks if a task was retrieved from the queue and place the REPEAT inside a BRANCH to check for a task at that point. If no tasks are queued, then execution will proceed to the “getInbound” branch.
If you clone the service, then you’ll need to register it as a new delivery service and use that on your queue config. Then your gets will happen every time the task fires.
Hopefully one of these approaches will work out for you.
Rob:
In case to use putToVAN the flow starts with getting the queue tasks invoked to retrive queued documents and branch outs if no tasks. This step can be disabled and made as delivery service. I like this option to be used with out big effort.
Will post the updates. I Appreciate your time.
I am able to clone the putToVAN as delivery service.
FYI: One more issue to handle in this option.
There are some cases, need only pull from VAN with out a delivery. So this clonned delivery service will not be fired unless TN receives a document to deliver in the queue for that specific partner.
“There are some cases, need only pull from VAN with out a delivery. So this clonned delivery service will not be fired unless TN receives a document to deliver in the queue for that specific partner.”
The delivery service is always fired on the schedule, whether or not a document is in the queue. As mentioned earlier, putToVAN gets invoked on the schedule (say every 5 minutes or whatever) even when the queue is empty. However, the first thing the service does is check if there is a doc on the queue and if not it exits. Change the logic of your cloned service to not exit when the queue is empty.
Rob:
Sorry about that. I overlooked the issue in terms of configuration in TN. I can the schedule in IS console. Thanks again.
Hi
I am new to the VAN world. We want to use VAN and the VAN.VANConnectivity:getFromVAN is out of thr box from webMethods to get the files from VAN. I checked the service and it looks to me a simple ftp service.My question is that do I need to delete the message from the VAN after the getFromVAN service or its VAN feture to remove the message once the service reads the message? Do I need to change the VAN.VANConnectivity:getFromVAN to delete the messages from the VAN.Please help me to understand the VAN.
Thanks
Govind
Most VANs will delete the file automatically after a successful get. You’ll want to check the VAN documentation or contact them to find out for sure.
NEVER change the built-in services directly. If you must modify the behavior, copy the service to your own package/folder then modify and use that service.