This topic describes use of the
CDOutput node in a message
flow and assumes that the rest of the flow has been developed, for
example, an
MQInput to
a
CDOutput node.
Multiple CDOutput nodes can be deployed
to the same integration server, or to different integration servers in the
same broker. CDOutput nodes
can send one file per transfer. Each file can have multiple records;
each record can have multiple elements. Transfers from the CDOutput node are non-blocking.
Complete
the following steps:
- Set the required node properties on the CDOutput node.
If
you set the
Destination file name only,
and leave all the other options at their default values, the file
is transferred:
- From the primary Connect:Direct server (PNODE)
back to itself
- Into the default transfer directory using the default process
name.
Additionally, the file is created if it does not exist, or replaced
if it already exists.
The following table summarizes the
CDOutput node properties that
you can set, on which tab they appear, and a value that you can select:
| Tab |
Property |
Value |
|---|
| Basic |
Process name |
You can use any name you want for the process.
Note, however, that the name must be a maximum of eight characters
and cannot contain any spaces. |
| SNODE |
The secondary Connect:Direct server to which the file is being
transferred. |
| Destination
file directory |
TestDir on
secondary Connect:Direct server (SNODE). |
| Destination
file name |
Filename on
secondary Connect:Direct server (SNODE). |
| Disposition |
RPL |
| Transfer mode |
Text mode |
- Setup the username and password that
is required for the CDOutput node
to connect to the primary Connect:Direct server using
the mqsisetdbparms command.
- Deploy the message flow to the broker. See Packaging and deploying.
- Send the file to the In terminal of the CDOutput node.
The following actions occur when you perform these steps:
- The file is constructed in accordance with the values set in the
properties of the CDOutput node.
- The file is staged in the local file system and then a command
is sent to the Connect:Direct server to cause
the transfer to occur.
- If a file of the same name exists in the selected directory on
the secondary Connect:Direct server, the
processing of the existing file is determined by the value of the Disposition property;
in this example, the file is replaced.
Once the transfer has completed
the local, staged file is deleted.
Note, that when sending a file, you can dynamically set the
following properties:
- Secondary Connect:Direct server
(SNODE)
- Process name
- Accounting data
- Destination file directory
- Destination file name
- Copy from options
- Copy to options
You have complete control of the Copy statements.
For
example:
LocalEnvironment.Destination.CD.Copy.To.Option.PERMISS = '777'
causes
IBM Sterling Connect:Direct to set the permissions on the
destination file to
777 (or
RWX RWX RWX)
if the destination file is on a
UNIX operating
system, or within Unix System Services on
z/OS®.
However, if you enter
an incorrect format, a syntax error is detected when the process script
is submitted and this causes an error to be thrown in the node.
For
example:
LocalEnvironment.Destination.CD.Copy.To.Option.PERMISS = '7xddd'
causes a syntax error because
'7xddd' is
not of the format
nnn. When an error occurs the process
script is available in the exception thrown and the user trace.
Tip: To help you with problem determination, you can view the
script generated by the CDOutput node
by turning on user trace.
Last updated Friday, 21 July 2017