Trading Networks 10.3 | Administering and Monitoring B2B Transactions | Trading Networks Administrator's Guide | Preparing for Document Delivery | Creating Custom Scheduled Delivery Services | Creating a Custom Scheduled Delivery Service | Typical Logic to Include in the Scheduled Delivery Service
 
Typical Logic to Include in the Scheduled Delivery Service
A typical scheduled delivery service might deliver all the batched documents to a single destination. The wm.tn.transport:batchFtp built-in scheduled delivery service behaves in this manner and is a good sample to refer to when creating your own scheduled delivery service. For more information, see The wm.tn.transport:batchFtp Built-in Service.
The following shows steps you might want to include in your scheduled delivery service to deliver all documents to the same destination.
// Retrieve a delivery task from the queue:
 
If the queue is empty
   Exit the service
 
Open a connection to the remote server
 
While queue is not empty
   // Try to deliver the document associated with the delivery task
   // Update the task with the results of the delivery (e.g., success or fail)
   // Retrieve the next delivery task from the queue
 
Close the connection to the remote server
The actions in italics are items that all scheduled delivery services should perform.
The above shows only one way to create the service. You might have different requirements for your service. For example, you might want to combine several documents and transmit them as one large document or might want to limit the number of documents sent to a destination in a single invocation of your service.
As shown above, the scheduled delivery service might need to make a connection to a remote server. The typical approach is to open the connection after you have determined that the queue has delivery tasks in it (that is, the queue is not empty). You can determine whether the queue is empty by invoking the wm.tn.queuing:getQueuedTask built-in service. If this service returns null, the queue is empty. After your scheduled delivery service has acted on the delivery tasks in the queue, your service can close the connection to the remote server.
Some transport protocols require additional actions after opening a connection and before you begin delivering documents. For example, for the FTP protocol, after performing the LOGIN to connect to the remote server, a cd (change directory) is performed to navigate to the appropriate directory.