Defining a TCP transport

The TCP transport definition panel allows you to specify the IP address or host name, and port number of the TCP server application. It also allows you to specify:

Connection and Transaction timeouts
The connection mode: connection_oriented or connectionless
If the transport will receive and process response data sent from the TCP server application.

Procedure

Follow these steps:

Using the Workbench access a node and navigate to the transport panel and select the New button to bring up a transport definition panel.
In the Name parameter, type a unique name for the transport.
A TCP transport name can be up to 64 characters in length and can include letters, numbers, and the underscore character. You will not be able to type invalid characters. For example, spaces are not allowed. You will not be able to insert a space in the name.
Use the Type down-arrow, and then select TCP.
The Transport window changes to accommodate the definition of a TCP transport.

Parameters tab

Parameter	Description
Host	The IP address or host name of the computer where you want the messages sent. This is where the TCP server application program is running.
Port	The port number to use to connect to the TCP server application.
Mode	The type of TCP connection management The options are: connection_oriented - a TCP connection is established by the Transaction Server and maintained for subsequent sending of data to the TCP server application. connectionless - a TCP connection is established by the Transaction Server, the data is sent to the TCP server application and then the connection is closed. When the next Transaction action supplied data is processed by the transport, a new connection is established.
Load transport at initialization	An option to have the TCP transport connect to the TCP server application when the node starts.
Include header in payload	The data, or payload, that is sent by the TCP transport will begin with an 8-byte header. The first 4-bytes will be the length of the data (not including the 8-byte header), and the next 4 bytes are set to zero and reserved for future use. Sending a header with the data makes it easier and more efficient for the TCP server application program to know how many bytes to receive and process. The byte ordering of the header is big-endian.
Handle Response	An option to indicate that the TCP Transport can receive response data sent by the TCP application. This feature is only allowed when the Mode is set to connectionless and the Include header in payload checkbox is unchecked. You specify how the response data is to be processed in a Transport Map. When this option is selected, additional fields become enabled as described below.
Timeout (sec)	The number of seconds that the TCP transport will wait for response data from the TCP server application. This value should be less than the Execution timeout specified on the Timeout tab. If the Transaction action that is being processed has output data parameters the TCP transport will wait until one of the following conditions occurs: The TCP server application sends response data and closes the socket. The TCP transport will map response data to the output map parameters as defined in the transport map. The Max Msg Size(KB) amount of data has been received. This will result in a failure of the Transaction action. The Timeout (sec) number of seconds has elapsed. This will result in a failure of the Transaction action.
Max Msg Size(KB)	The maximum response message size in Kilo-Bytes that the TCP transport will receive in a response from the TCP server application. If there are more bytes available in the response, the transport will report this as an error.

Timeout tab

Parameter	Description
Connection (seconds)	The length of time the system will try to connect to a target TCP server application. For more information, see Connection timeout.
Execution (seconds)	How long the system should wait (once the connection is made) for a TCP transaction to complete. For more information, see Execution (sec). If you have defined the TCP transport to handled response data, make sure that this value is greater than the Timeout specified in the Handle Response section.

Custom Payloads tab

For information on the Custom Payloads tab, see Custom Payloads tab.

Testing and saving the TCP transport

To test the connection, select Validate. The validation consists of establishing a connecting to the TCP server application.
If no errors are received, select Save. The transport definition is saved to the node.

The name of the new transport is added to the Transports tab and will be available for use by a transport map.

Limitation (failure to detect the connection has been reset)

This limitation applies to release 13.1 and earlier (for the Mitsubishi MESInterface IT product, version 1.12N and earlier). In release 13.2 (and version 1.14Q), the TCP transport's support of the connection_oriented mode includes improved detection of the partner TCP server application terminating the connection.

It is possible the TCP transport might not detect that the connection has been terminated by the TCP server application.
When this occurs, the specific behavior depends on the operating systems involved with the node and the TCP server application. The transactions sent through the TCP transport after the TCP server application terminates the connection might appear to be successful on the transport side, but the TCP server application does not actually receive the data.

¹Possible work around

If the application logic allows it, trigger actions can be used to control the state of the TCP connection. In the trigger where the Transaction action is used to send data via the TCP transport, insert the Control Transport State (Resume Operation) and Control Transport State (Suspend Operation) around the Transaction action. This will cause the TCP transport to connect (on the Resume) before the action and disconnect (on the Suspend) after the action every time the trigger sends a transaction.
The possibility of an old connection is greatly reduced, since the connections are not maintained between the sending of the data.