IBM Integration Bus, Version 9.0.0.8 Operating Systems: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS

See information about the latest product version

TwineballRequest node

Use the TwineballRequest node to discover out how WebSphere® Adapters nodes work.

This topic contains the following sections:

Purpose

The TwineballRequest node is provided for educational purposes and helps you to see how the WebSphere Adapters nodes work. The TwineballRequest node is a sample node with its own sample EIS. You cannot use the TwineBall nodes to connect to the external SAP, Siebel, and PeopleSoft EIS systems. Do not use this node in production.

The TwineballRequest node is contained in the WebSphere Adapters drawer of the message flow node palette, and is represented in the IBM® Integration Toolkit by the following icon:

TwineBallRequest node icon
You can use the mqsisetdbparms command in the following format to configure an account name with a user name and password for the Twineball adapter.
mqsisetdbparms broker name -n adapter name -u user name -p password
For example:
mqsisetdbparms BRK1 -n eis::TwineballOutbound.outadapter -u mqbroker -p ********
Look at the following sample to see how to use this node:

You can view information about samples only when you use the product documentation that is integrated with the IBM Integration Toolkit or the online product documentation. You can run samples only when you use the product documentation that is integrated with the IBM Integration Toolkit.

Terminals and properties

When you have put an instance of the TwineballRequest node into a message flow, you can configure it; see Configuring a message flow node. The properties of the node are displayed in the Properties view. If you double-click a TwineballRequest node, you open the Adapter Connection wizard. All mandatory properties for which you must enter a value (those that do not have a default value defined) are marked with an asterisk.

The TwineballRequest node terminals are described in the following table.

Terminal Description
In The input terminal that accepts the request business object.
Out The output terminal to which the response business object is sent if it represents successful completion of the request, and if further processing is required within this message flow.
Failure If an error happens in the TwineballRequest node, the message is propagated to the Failure terminal. Information about the error, and business object events can also be propagated to the Failure terminal.

The following tables describe the node properties. The column headed M indicates whether the property is mandatory (marked with an asterisk on the panel 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).

The TwineballRequest node Description properties are described in the following table.

Property M C Default Description
Node name No No The node type, TwineballRequest The name of the node.
Short Description No No   A brief description of the node.
Long Description No No   Text that describes the purpose of the node in the message flow.
The TwineballRequest node Basic properties are described in the following table.
Property M C Default Description mqsiapplybaroverride command property
Adapter component Yes No   The name of the adapter component that contains configuration properties for the adapter. Either enter a name of an adapter file, or click Browse to select an adapter file from the list of files that are available in referenced message set projects.  
Default method Yes Yes   The default method binding to use. defaultMethod
The TwineballRequest node Response Message Parsing properties are described in the following table.
Property M C Default Description
Message domain No No DataObject The domain that is used to parse the response message. By default, the response message that is propagated from the TwineballRequest node is in the DataObject domain. You cannot specify a different domain.
Message set Yes No Set automatically The name of the message set in which the incoming message is defined. This field is set automatically from the Adapter component property.

If you set this property, then subsequently update the project dependencies to remove this message set reference, a warning is issued. Either update the Message set property, or restore the reference to this message set project.

Message type No No   The name of the response message. The node detects the message type automatically. You cannot set this property.
Message format No No   The name of the physical format of the response message. You cannot set this property.
The TwineballRequest node Transactionality properties are described in the following table.
Property M C Default Description
Transaction mode No No Automatic This property specifies how updates are handled. If you select Yes, updates are performed in a single transaction. If you select No, updates are performed independently.
The TwineballRequest node Request properties are described in the following table.
Property M C Default Description
Method Location Yes No $LocalEnvironment/Adapter/MethodName The location of the business method (such as createPurchaseOrder or deletePurchaseOrder) that is used to trigger the TwineballRequest node to perform an action on the external system.
Data Location Yes No $Body The location in the incoming message tree from which data is retrieved to form the request that is sent from the TwineballRequest node to the EIS.
The TwineballRequest node Result properties are described in the following table.
Property M C Default Description
Output data location No No $OutputRoot The message tree location to which the TwineballRequest node sends output.
Copy local environment No No Selected This property controls how the local environment is copied to the output message. If you select the check box, at each node in the message flow, a new copy of the local environment is created in the tree, and it is populated with the contents of the local environment from the preceding node. If a node changes the local environment, the upstream nodes do not see those changes because they have their own copies. This behavior might be an issue if you are using a FlowOrder node, or if you use the propagate command on a Compute node.

If you clear the check box, each node does not generate its own copy of the local environment, but it uses the local environment that is passed to it by the previous node. If a node changes the local environment, those changes are seen by the upstream nodes.

The Monitoring properties of the node are described in the following table.
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 using monitoring properties for details.

You can enable and disable events that are shown here by selecting or clearing the Enabled check box.


ac37360_.htm | Last updated Friday, 21 July 2017