CDOutput node
Use the CDOutput node when using IBM® Sterling Connect:Direct® with IBM Integration Bus.
- Developer
- Application Integration Suite
- Standard
- Advanced
- Adapter
Information about file transfers is held on storage queues that are controlled by WebSphere® MQ, so you must install WebSphere MQ on the same computer as your integration node if you want to use the capabilities provided by the CDOutput node. The storage queues that hold the transfer information are owned by the queue manager that is specified on the integration node, and you specify this queue manager by using the -q property of the mqsicreatebroker command. For more information about specifying a queue manager on the integration node, see Creating an integration node and mqsicreatebroker command. You must also create the system queues required by the CDOutput node; see Creating the default IBM Integration Bus queues on a WebSphere MQ queue manager.
This topic contains the following sections:
Purpose
Use the CDOutput node to serialize the message tree to a file and then transfer it between two Connect:Direct servers. A directory under the work path within the integration server is used as the staging area, until the file is ready to be transferred. Once the file is transferred, it is deleted from the staging area.
The CDOutput node is contained in the File drawer of the palette, and is represented in the IBM Integration Toolkit by the following icon:
Using this node in a message flow
You can use the CDOutput node in conjunction with another transport input node, for example, MQInput. Any data received from WebSphere MQ is sent to the CDOutput node which writes the file to an internal directory using the file name given on the node. The file is then transferred across to the destination Connect:Direct server, where it is written to the directory and file name given on the node.
Terminals and properties
The CDOutput node terminals are described in the following table:
Terminal | Description |
---|---|
In | The input terminal that accepts a message for processing by the node. |
Finish File | The input terminal that accepts a message that triggers the final processing of a file. |
Out | The message received on the In terminal is propagated to this terminal if the record is written successfully. The message is unchanged except for status information in the Local Environment. |
End of Data | The message received on the Finish File terminal is propagated to this terminal if the file is processed successfully. |
Failure | The output terminal to which the message is routed if a failure is detected when a message is propagated. |
The following tables describe the node properties that you can set on a specified tab. The column headed M indicates whether the property is mandatory (marked in the IBM Integration Toolkit with an asterisk if you must enter a value when no default is defined). The column headed C indicates whether the property is configurable (you can change the value when you add the message flow to the BAR file to deploy it).
When the CDOutput node propagates a
message, either to the Out terminal or to the End of Data terminal,
it stores information about it in the LocalEnvironment.WrittenDestination.CD
message
tree.
- Secondary Connect:Direct server (SNODE)name
- Process name
- Accounting data
- Destination file directory
- Destination file name
- Copy from options including SYSOPTS
- Copy to options including SYSOPTS
LocalEnvironment.Destination.CD
message
tree; see Using local environment variables with file nodes for more information.Description properties
Property | M | C | Default | Description |
---|---|---|---|---|
Node name | No | No | CDOutput | The name of the node. |
Short Description | No | No | None | A brief description of the node. |
Long Description | No | No | None | Text that describes the purpose of the node in the message flow. |
Basic properties
Property | M | C | Default | Description | mqsiapplybaroverride command property |
---|---|---|---|---|---|
SNODE | No | Yes | The same as the PNODE being used | The secondary Connect:Direct server (SNODE) to which the file
is being transferred. If this is not set, the file is transferred back to the primary Connect:Direct server server (PNODE). You must set up a Netmap in the netmap.cfg file on the PNODE to ensure that the transfer reaches the SNODE. The Netmap entry for this SNODE must contain the operating system type in the appropriate field. If the PNODE is on a UNIX operating system, you must use the description field in the Netmap to store this information. The description
must contain the string remoteos=xxx , where the value is Windows, UNIX or
OS390. For example, Windows would
be The CDOutput node cannot be used to transfer to a SNODE on operating systems other than these. |
snode |
Destination file directory | No | Yes | Empty string | The directory to which the file is being transferred
on the secondary Connect:Direct server (SNODE). Note that the directory must exist. If this field is left blank, the default directory is used by the SNODE. On z/OS®, if the File name is a sequential dataset, or partitioned dataset member, leave the directory field blank. |
destinationDirectory |
Destination file name | Yes | Yes | None | The specific file name or a pattern containing
a single wildcard that defines the name of the file to be created
by the secondary Connect:Direct server (SNODE). The
File name can be a pattern that contains a single wildcard. The wildcard
value is taken from the element in the local environment folder called
For
example, if the CDInput node
sets its file pattern to The
file name must be set, but can be overridden using the local environment
field You
can specify z/OS sequential datasets
or partitioned data set members. For whole, sequential data sets,
specify the full name for the dataset, for example, For
a member within a partitioned dataset, use brackets to specify the
member name, for example, One wildcard character can be used anywhere within a dataset name, and works in the same way as for normal file name patterns. |
destinationFileName |
CDServer configurable
service |
No | Yes | Default | The name of the configurable service being used
to connect to the primary Connect:Direct server (PNODE),
in order to initiate the transfer. If this value is not set, the default configurable service (named "Default") is used. The default configurable service connects to a PNODE located on the same machine as the integration node, and using default port configurations. The
default configurable service also uses the "default" security identity,
which must be created using the mqsisetdbparms command; for example: For information on various configurations when using IBM Sterling Connect:Direct, see Advanced configuration properties when using IBM Sterling Connect:Direct nodes and refer to the Output sections. |
|
Process name | No | Yes | None | The name used for the process script generated
to send the file from the primary Connect:Direct server (PNODE) to the secondary Connect:Direct server (SNODE). Use this option if you want to identify this transfer uniquely. If this value is not set, the process name WMBPROC is used. You can use any name you want in the process script. Note, however, that the name must be a maximum of eight characters and cannot contain any spaces. |
processName |
Disposition | Yes | Yes | RPL - replace file | How to create the file on the secondary system:
On z/OS, for partitioned
datasets, only RPL and NEW options are supported. NEW attempts to
allocate a new partitioned dataset, with the following IBM Sterling Connect:Direct SPACE options: ' You
can override these values in the local environment by using: |
disposition |
Transfer Mode | yes | Yes | Binary transfer (no conversion) | The mode in which to transfer the file. binary - The file is transferred as binary, with no conversion text - The file is transferred with conversion between local codepages, as required. When using transfer mode "text" on z/OS, IBM Sterling Connect:Direct requires that the file contains at least one newline character. You must ensure that the file is created in the correct form for IBM Sterling Connect:Direct to successfully complete the text transfer. |
transferMode |
Request properties
Property | M | C | Default | Description |
---|---|---|---|---|
Data location | No | No | $Body | The location in the input message tree that contains the record to be written to the output file. The default value, $Body, means the entire message. |
Records and Elements properties
Property | M | C | Default | Description |
---|---|---|---|---|
Record definition | Yes | No | Record is Whole File | Specifies how records are placed
in the output file. Valid options are:
|
Length (bytes) | Yes | No | 80 | The required length of the output record. The property is available only when Record is Fixed Length Data is specified in Record definition. |
Padding byte (hexadecimal) | Yes | No | 20 | The 2-digit hexadecimal byte to be used to pad short messages. The property is available only when Record is Fixed Length Data is specified in Record definition. |
Delimiter | Yes | No | Broker System Line End | The delimiter to be used. The property
is available only when Record
is Delimited Data is specified in Record definition. Valid options
are:
|
Custom delimiter (hexadecimal) | Yes | No | None | The delimiter byte sequence to be used. The property is available only when Record is Delimited Data is specified in the Record definition property, and Custom Delimiter (hexadecimal) is specified in the Delimiter property. |
Delimiter type | Yes | No | Postfix | This property specifies how delimiters
are to be inserted between records. The property is available only
when Record is Delimited Data is
specified in Record definition.
Valid options are:
|
Validation properties
For a full description of these properties, see Validation properties.
Property | M | C | Default | Description | mqsiapplybaroverride command property |
---|---|---|---|---|---|
Validate | Yes | Yes | Inherit | This property controls whether validation takes
place. Valid values are:
|
validateMaster |
Failure action | Yes | No | Exception | This property controls what happens if validation
fails. The property is available only if you set Validate to Content or Content and Value. Valid values
are:
|
Property | M | C | Default | Description |
---|---|---|---|---|
Events | No | No | None | Events that you have defined for the node are
displayed on this tab. By default, no monitoring events are defined
on any node in a message flow. Use Add, Edit,
and Delete to create, change or delete monitoring
events for the node; see Configuring monitoring event sources by using monitoring properties for details. You can enable and disable events that are shown here by selecting or clearing the Enabled check box. |