Use the JDEdwardsRequest node to interact with a JD Edwards EnterpriseOne server.
This topic contains the following sections:
Use the JDEdwardsRequest node to discover JD Edwards EnterpriseOne business functions and XML lists. For example, a user might want to retrieve address details for a person where the record exists on a JD Edwards server.
The JDEdwardsRequest node can send and receive business data.
The JDEdwardsRequest 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:
To enable function that becomes available in IBM Integration Bus fix packs, use the -f parameter on the mqsichangebroker command. For more information, see mqsichangebroker command.
Before you can develop message flows that use WebSphere® Adapters nodes, you must add prerequisite files to the runtime environment (as described in Adding external software dependencies for JD Edwards EnterpriseOne).
To function correctly, the JDEdwardsRequest node needs an adapter component (see Connecting to an EIS by using the Adapter Connection wizard), which you set by 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 JDEdwardsRequest node is in the DataObject domain, therefore 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 JDEdwardsRequest node contain the correct data types. The DataObject domain is the default domain when parsing messages that are produced by the JDEdwardsRequest node. However, when passing data to the JDEdwardsRequest 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 JDEdwardsRequest node supports local transactions by using the Local Transaction Manager of the broker, and global transactions by using the external syncpoint coordinator of the broker.
To effectively maintain the pool of connections to JD Edwards, 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.
mqsisetdbparms broker name -n adapter name -u user name -p passwordmqsisetdbparms BRK1 -n eis::JDEdwardsCustomerOutbound.outadapter -u jdedwardsuid -p ********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.
Using configurable services for JD Edwards nodes
JD Edwards nodes can get JD Edwards 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 JD Edwards, see Changing connection details for JD Edwards adapters.
When you have put an instance of the JDEdwardsRequest 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 JDEdwardsRequest node, you open the Adapter Connection wizard. All mandatory properties for which you must enter a value (those properties that do not have a default value defined) are marked with an asterisk.
The JDEdwardsRequest node terminals are described in the following table.
| Terminal | Description |
|---|---|
| In | The input terminal that accepts a message for processing by the JDEdwardsRequest node. The JDEdwardsRequest node is driven by a message arriving on the In terminal. |
| Out | The output terminal from which the message tree is propagated. |
| Failure | If an error happens in the JDEdwardsRequest node, the message is 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 JDEdwardsRequest node Description properties are described in the following table.
| Property | M | C | Default | Description |
|---|---|---|---|---|
| Node name | No | No | The node type, for example, JDEdwardsRequest | 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 theJDEdwardsRequest node receives data from the JD Edwards system, it associates that data with a method name. The JDEdwardsRequest 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. |
||
| 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 JDEdwardsRequest 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 JD Edwards 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 JD Edwards outbound adapter that is also deployed as an independent resource. For more information, see Calling new services from a WebSphere Adapters request node without changing existing deployed resources. |
secondaryAdapterMode |
| Default method | Yes | Yes | The default method binding to use. This property
lists the methods that are defined by the adapter. You can override
this property by setting the method name in the LocalEnvironment.Adapter
subtree. For more information, see Local environment tree structure. The method names correspond to the Service Operation names, which are configured by the Adapter Connection wizard. In most cases, the names are based on the name of the service that is being discovered. |
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 JDEdwardsRequest node is in the DataObject domain. You cannot specify a different domain. |
| Message set | No | 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. |
| 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 function or XML list method that is used to trigger the JDEdwardsRequest 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 JDEdwardsRequest node to the
EIS. The default value, $Body, represents the incoming message body. You can enter any XPath or ESQL expression that defines the location of the message tree to serialize and send. |
| Property | M | C | Default | Description |
|---|---|---|---|---|
| Output data location | No | No | $OutputRoot | The message tree location to which the JDEdwardsRequest node sends
output. The default value, $OutputRoot, replaces the incoming message with the response. |
| Copy local environment | No | No | Selected | This property controls whether to copy the incoming local environment or propagate the incoming local environment. By default, this check box is selected, which signifies that the local environment is copied so that the incoming local environment is preserved. The additions to the local environment are visible only to nodes downstream of this node. If this check box is cleared, the incoming local environment is used for the outgoing message. Any modifications that are made to the local environment by this node are visible to both downstream and upstream nodes after this node has completed. |
| 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. |
Last updated Friday, 21 July 2017