JDEdwardsRequest node
Use the JDEdwardsRequest node to interact with a JD Edwards EnterpriseOne server.
- Developer
- Application Integration Suite
- Standard
- Advanced
- Scale
- Adapter
This topic contains the following sections:
Purpose
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.
Using this node in a message flow
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 integration node, and global transactions by using the external syncpoint coordinator of the integration node.
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 integrationNodeName -n adapter name -u user name -p password
For
example:mqsisetdbparms BRK1 -n eis::JDEdwardsCustomerOutbound.outadapter -u jdedwardsuid -p ********
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.
Terminals and properties
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.
Note: You can override the properties in the adapter
file at run time by creating a JDEdwardsConnection configurable
service that has the same name as the adapter file. For
more information see Changing connection details for JD Edwards 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 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 model | No | 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 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 by using monitoring properties for details. You can enable and disable events that are shown here by selecting or clearing the Enabled check box. |