SiebelRequest node
Use the SiebelRequest node to interact with a Siebel application.
- Developer
- Application Integration Suite
- Standard
- Advanced
- Scale
- Adapter
This topic contains the following sections:
Purpose
Use the SiebelRequest node to interact with Siebel applications. For example, a SiebelRequest node requests information from a Siebel Enterprise Information System (EIS). A customer business object is sent to Siebel, causing Siebel to retrieve information about a customer, such as an address and account details. The response information that is retrieved by the SiebelRequest node can then be used by the rest of the message flow. The SiebelRequest node can send and receive business data.
The SiebelRequest 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:
Using this node in a message flow
To function correctly, the SiebelRequest node needs an adapter component, which you set using the Adapter component node property, and business object definitions, which are stored in the message set that you reference from the node. For this reason, you must provide a message set. By default, the message that is propagated from the SiebelRequest node is in the DataObject domain, so the Message domain property is set to DataObject. You cannot specify a different domain. The message type is detected automatically by the node.
To maximize performance and avoid unnecessary data conversion, ensure that messages that are passed to the SiebelRequest node contain the correct data types. The DataObject domain is the default domain when parsing messages that are produced by the SiebelRequest node. However, when passing data to the SiebelRequest node (for example, by using an MQInput node), the use of a different domain can improve performance. For example, use the XMLNSC parser with the MQInput node to parse XML messages.
The SiebelRequest node supports local transactions by using the local transaction manager for the integration node, and global transactions by using the external syncpoint coordinator for the integration node.
To effectively maintain the pool of connections to Siebel, you can set a connection timeout value on a configurable service. For more information, see Configuring EIS connections to expire after a specified time.
You can deploy several WebSphere® Adapters request nodes that use the same adapter component to an integration server.
The SiebelRequest node can use an identity that is present on an input message, and propagate it to Siebel, by using the Propagate property on the security profile that is defined on the node. For more information, see Propagating security credentials to Siebel and SAP requests.
mqsisetdbparms integrationNodeName -n adapter name -u user name -p password
For
example:mqsisetdbparms BRK1 -n eis::SiebelCustomerOutbound.outadapter -u siebeluid -p ********
Using configurable services for Siebel nodes
Siebel nodes can get Siebel connection details from either the adapter component or a configurable service. By using a configurable service, you can change the connection details for an adapter without the need to redeploy the adapter. For more details about creating, changing, reporting, and deleting the configurable services for Siebel, see Changing connection details for Siebel adapters.
You can also connect to different versions of Siebel by creating a custom EISProviders configurable service and setting the location of the appropriate library files. For more information, see Connecting to different versions of Siebel.
Terminals and properties
When you have put an instance of the SiebelRequest 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 SiebelRequest 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 SiebelRequest 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 SiebelRequest 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 SiebelRequest node Description properties are described in the following table.
Property | M | C | Default | Description |
---|---|---|---|---|
Node name | No | No | The node type, for example, SiebelRequest | 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. |
Property | M | C | Default | Description | mqsiapplybaroverride command property |
---|---|---|---|---|---|
Primary 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. When theSiebelRequest node
receives data from the Siebel system, it associates that
data with a method name. The SiebelRequest node
attempts to call methods that are defined in the primary
adapter. If the method is not defined in the primary adapter,
the node can call methods that are defined in matching
secondary adapters that are deployed to the same integration
server.
Note: You can override the properties in the adapter
file at run time by creating a SiebelConnection configurable
service that has the same name as the adapter file. For
more information see Changing connection details for Siebel adapters
|
||
Secondary adapter mode | No | Yes | None | Specifies whether the node can call methods
that are defined in secondary adapters. If you set the Secondary adapter mode property to None, the SiebelRequest node calls only methods that are defined in the primary adapter. If the method is not defined in the primary adapter, an error occurs. If you set this property to All adapters in application, the node can call methods that are defined in any Siebel outbound adapter that is deployed to the same application. If the node is deployed as an independent resource (that is, it is not contained within an application), the node can call methods that are defined in any Siebel outbound adapter that is also deployed as an independent resource. |
secondaryAdapterMode |
Default method | Yes | Yes | The default method binding to use. | defaultMethod |
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 SiebelRequest node is in the DataObject domain. You cannot specify a different domain. |
Message model | Yes | No | Set automatically | The name or location of the message model schema
file 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 model reference, a warning is issued. Either update the Message model property, or restore the reference to this message model. |
Message | No | No | The name of the response message. The node detects the message type automatically. You cannot set this property. | |
Physical format | No | No | The name of the physical format of the response message. You cannot set this property. |
Property | M | C | Default | Description |
---|---|---|---|---|
Transaction mode | No | No | No | This property specifies that updates are performed independently, not as part of a local transaction. You cannot change this property. |
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 SiebelRequest 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 SiebelRequest node to the EIS. |
Property | M | C | Default | Description |
---|---|---|---|---|
Output data location | No | No | $OutputRoot | The message tree location to which the SiebelRequest 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. So 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. So if a node changes the local environment, those changes are seen by the upstream nodes. |
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. |