Running the TCPIP Client Nodes sample
After you have imported and deployed the sample, you
can run it by following the instructions in the Running the asynchronous sample
and
Running the synchronous sample sections.
For information about the stream control options available on the
Advanced tab,
see Advanced options.
For an overview of how these nodes work and are configured,
see TCP/IP overview
in the WebSphere Message Broker documentation.
This sample can also be extended to communicate with a separate TCP/IP server; see
Extending the TCPIP Client Nodes sample.
If you encounter any problems when you run the sample,
see Resolving problems when running samples
in the WebSphere Message Broker documentation.
This sample uses the message flows TCPIPAsyncIn, TCPIPAsyncOut, and TCPIPServerSimulation.
To run the sample:
- In the Broker Development view, expand the TCPIPClientNodesSampleFlowProject.
- Expand the Flow Tests directory, and double-click
TCPIPAsyncTest.mbtest to open the message in the Test Client.
Click Enqueue.
- Click Send Message in the Detailed Properties panel.
The following events occur:
- A WebSphere MQ request message is placed on the TCPIP_ASYNC_IN queue.
This request is read by the TCPIPAsyncOut message flow.
- The JavaCompute node checks whether the server host name and port number are specified within
the message body. These fields are not yet set, and the JavaCompute node has no effect.
For an example of how this JavaCompute node is used, see
Extending the TCPIP Client Nodes sample.
- The message is sent by using the TCPIPClientOutput node on port 7777.
On the Request tab of this node the Reply
ID location property associated with this
TCP/IP connection is set to the WebSphere MQ ReplyToQ.
- The TCPIPServerInput node in the TCPIPServerSimulation flow is listening on port 7777 and
accepts the connection from the TCPIPClientOutput node.
- The TCPIPServerSimulation flow amends the message by adding
<ServerUpdate>OK</ServerUpdate>
and sends the message back on port 7777.
- The TCPIPClientInput node in the TCPIPAsyncIn message flow receives the data.
The TCPIPClientInput node resets the WebSphere MQ ReplyToQ property from the Reply ID
that is associated with the connection.
- The message is propagated back through an MQReply node.
- Click Dequeue.
- Click Get Message in the Detailed Properties
panel.
- Check that the updated message has been successfully sent back over WebSphere MQ:
- View the reply message in the Detailed Properties panel by using the XML Structure view.
- Compare this reply message with the message previously sent through the Enqueue event.
The element <ServerUpdate>OK</ServerUpdate>
has been added to the Header section of the message body.
If all the previous steps are successful, the sample is complete.
Look at the nodes in the three message flows, to see how the
results were achieved.
This sample uses the message flows TCPIPSync and TCPIPServerSimulation.
To run the sample:
- The asynchronous and synchronous parts of this sample use the same port number;
you must, therefore, ensure that the correct flows are deployed for the synchronous sample:
- In the WebSphere Message Broker Toolkit, select the Brokers view.
- Right-click TCPIPClientNodesSampleExecutionGroup
and click
Delete > All flows and resources.
- Select and open TCPIPClientNodesSampleArchive.bar.
On the Prepare tab,
clear the TCPIPAsyncIn and TCPIPAsyncOut message flows, and select the TCPIPSync message flow.
Ensure that the TCPIPServerSimulation flow and
TCPIPClientNodesSampleJavaProject are still selected.
- Click Build and Save..., and save the BAR file.
- Drag the BAR file onto the TCPIPClientNodesSampleExecutionGroup.
- Check that the
following objects have been deployed:
- TCPIPSync message flow
- TCPIPServerSimulation message flow
- TCPIPClientNodesSampleJavaProject
- In the Broker Development view, expand TCPIPClientNodesSampleFlowProject.
- Expand the Flow Tests directory, and double-click TCPIPSyncTest.mbtest to open the message in the Test Client.
Click Enqueue.
- Click Send Message in the Detailed Properties panel.
The following events occur:
- A WebSphere MQ request message is placed on the TCPIP_SYNC_IN queue.
This request is read by the TCPIPSync message flow.
- The message is sent by using the TCPIPClientOutput node on port 7777.
Unlike the asynchronous model, the ReplyToQ does not need to be explicitly saved,
because it remains unchanged in the message tree through this synchronous flow.
- The TCPIPClientReceive node waits for a response from the server.
- The TCPIPServerInput node in the TCPIPServerSimulation flow is listening on port 7777
and accepts the connection from the TCPIPClientOutput node.
- The TCPIPServerSimulation flow amends the message by adding
<ServerUpdate>OK</ServerUpdate>
and sends the message back on port 7777.
- The TCPIPClientReceive node in the TCPIPSync message flow receives the data.
On the Result tab of this node,
the response message is explicitly embedded as a response element
within the original message.
- The message is propagated back through an MQReply node.
- Click Dequeue.
- Click Get Message in the Detailed Properties
panel.
- Check that the updated message has been successfully sent back over WebSphere MQ:
- View the reply message in the Detailed Properties panel using the XML Structure viewer.
- Compare this message with the message previously sent through the Enqueue event.
The entire response message is visible as a <Response> element
embedded within the message following the original Header, SaleList, and Trailer elements.
Expand this response message; <ServerUpdate>OK</ServerUpdate>
has been added to the Header section of the message body.
If all the previous steps are successful, the sample is complete.
Look at the nodes in the two message flows to see how the
results were achieved.
All the TCPIP nodes contain stream control options on their
Advanced tabs.
The following details give an overview of how the stream control properties are set
within the TCPIP Client Nodes sample:
TCPIPAsyncOut message flow
- TCPIPClientOutput node
- The Input stream modification
property is left unchanged.
- The Output stream modification property is reserved for
use by nodes that come after this node in the message flow.
No other instances of the flow can use this specific stream until
the stream is released.
TCPIPAsyncIn message flow
- TCPIPClientInput nodes
- The Input stream modification property is left unchanged.
- The Output stream modification property is released.
This stream is finished with; it is therefore released back to the pool.
TCPIPSync message flow
- TCPIPClientOutput node
- The Input stream modification property is left unchanged.
- The Output stream modification property is reserved for
use by nodes that come after this node in the message flow,
and is released at the end of the flow.
The TCPIPSync message flow functions act differently to the TCPIPAsyncOut
message flow,
in that the TCPIPSync message flow performs all its processing
(input and output) in a single flow,
rather than in separate subflows for input and output.
As a result you can explicitly configure when the output connection is released.
- TCPIPClientReceive node
- The Input stream modification property is left unchanged.
- The Output stream modification property is left unchanged.
This stream is configured in the TCPIPClientOutput node;
you are not required to explicitly release the stream in the TCPIPClientReceive node.
TCPIPServerSimulation message flow
- TCPIPServerInput node
- The Input stream modification property is reserved,
and released at end of flow.
No new clients are allowed to connect on this specific
stream until the processing is finished.
- The Output stream modification property is unchanged.
- TCPIPServerOutput nodes
- The Input stream modification property is left unchanged.
Modification of this property is not required,
because the way this stream is handled has already been configured in the
TCPIPServerInput node.
- The Output stream modification property is left unchanged.
Back to sample home