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 | The wm.tn.transport:batchFtp Built-in Service
 
The wm.tn.transport:batchFtp Built-in Service
Trading Networks provides one built-in scheduled delivery service, wm.tn.transport:batchFtp, which is shown below. This service delivers a batch of documents using the FTP protocol to a single destination. It is written in the flow language. Use this service as a model if you are creating your own custom scheduled delivery service.
Figure 1. The wm.tn.transport:batchFtp Service
The diagram illustrates the operations in the wm.tn.transport:batchFtp Service
The following table lists the operations illustrated in the image for wm.tn.transport:batchFtp Service:
Flow Operations
Description
1
The INVOKE flow operation invokes the wm.tn.queuing:getQueuedTask built-in service to retrieve the first delivery task from the queue. The service returns the task information in the task variable.
2
If the variable, task, is null, the queue is empty. In this case, map text to the output variable, logMsg, and exit the service.
3
If the queue contains delivery tasks, attempt to log in to the remote FTP server.
4
An input to the wm.tn.transport:batchFtp service is the variable, directory. If this variable was specified, cd to the specified directory.
5
If the cd to the specified directory fails, map a message to the output variable, logMsg, and exit the service.
6
The REPEAT flow operation causes the service to loop over the delivery tasks in the queue.
7
The INVOKE flow operation invokes the wm.tn.doc:getDeliveryContent built-in service to retrieve the document content to be delivered.
8
The operations in the SEQUENCE flow operation form the file name to use for the document being delivered. The file name will be internalID.ext, where internalID is the Trading Networks generated internal ID for the document and ext is the file extension.
The first INVOKE flow operation in the sequence invokes the pub.string:concat service to append a period to the internal ID. The BRANCH flow operation determines the file extension. An input to the wm.tn.transport:batchFtp service is the variable, fileExtension. If this variable was not specified, the file extension defaults to “xml”. Otherwise, the file extension is the value specified for the fileExtension variable.
9
This INVOKE flow operation invokes the pub.client.ftp:put service that transmits the file using FTP.
10
If the return code from the pub.string:concat service is 226, the file was transmitted successfully. In this case, the MAP flow operation sets the value of the status variable in Pipeline Out to “success.”
For any other return code the other MAP flow operation sets the value of the status variable in Pipeline Out to “fail.”.
11
The first INVOKE flow operation invokes the wm.tn.queuing:updateQueuedTask built-in service to update the status of the delivery task. One of the inputs to the service is status that was set to either “success” or “fail”.
The second INVOKE flow operation invokes the wm.tn.queuing:getQueuedTask service to retrieve the next delivery task from the delivery queue.
12
If the wm.tn.queuing:getQueuedTask service returned a delivery task, continue in the REPEAT loop. If the service returned null, the queue is empty; exit the REPEAT loop.
13
After looping through all delivery tasks, log out of the remote FTP server.
The wm.tn.transport:batchFtp service does not do any exception handling. All transport-level exceptions cause the current invocation of the wm.tn.transport:batchFtp service to terminate, and the exception will be handled by its caller, the wm.tn.queuing:deliverBatch built-in service. The wm.tn.transport:batchFtp service will be invoked again for the delivery queue, according to the queue’s schedule.