Trading Networks 10.3 | Administering and Using Trading Networks | Administering Trading Networks | Preparing for Document Delivery | Creating Custom Scheduled Delivery Services | Creating a Custom Scheduled Delivery Service | Required Logic to Include in the Scheduled Delivery Service
 
Required Logic to Include in the Scheduled Delivery Service
The following table lists actions that you must include in all scheduled delivery services and the built-in service to use to accomplish each action.
Action
Built-In Service to Use
Retrieve a delivery task from a queue
wm.tn.queuing:getQueuedTask service.
When you invoke this service, you pass it the name of the queue from which you want a delivery task. The service returns the oldest task in the queue; the task includes the document to deliver.
When you retrieve a task from the queue, the task is not removed from the queue. Instead, the status of the delivery task is updated from QUEUED to DELIVERING.
How the delivery task is represented depends on how your scheduled delivery service is written:
*Flow service: IS document (IData object) that has a structure defined by the wm.tn.rec:Task IS document type.
*Java Service: com.wm.app.tn.delivery.GuaranteedJob object (see the webMethods Trading Networks Java API Reference).
Typically, your scheduled delivery service should invoke the wm.tn.queuing:getQueuedTask service and process delivery tasks until the queue is empty (that is, until you have processed each of the QUEUED delivery tasks in the queue). When the queue is empty, the wm.tn.queuing:getQueuedTask service returns null for the task variable.
Note:
The wm.tn.queuing:getQueuedTask service places the timeDequeued variable in the pipeline. Trading Networks uses this variable to calculate the amount of time it takes to transmit the document. Do not update or drop this variable from the pipeline.
Deliver the document
One of the built-in services in the pub.client folder, or one of your own custom transport services.
After your scheduled delivery service retrieves a delivery task, it should deliver the document that is returned with the task information.
Update the delivery task
wm.tn.queuing:updateQueuedTask service. the service uses the returned status to update the delivery task status:
*If status is success, the service updates the task status to DONE.
*If status is fail, the service updates the task’s retry count.
*If the maximum retry count has not been reached, the service updates the task status to QUEUED. The next time the queue schedule invokes your delivery service, the delivery task will try again to deliver the document.
*If the maximum retry count has been reached, the service updates the task status to FAILED.
The wm.tn.queuing:updateQueuedTask service also takes care of logging the results of the delivery to the activity log.