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

Planning user-defined input nodes

Before you develop a user-defined input node, plan and design its content and purpose.

Analysis

Before you develop a user-defined input node, ask yourself the following questions:

Do you need to create a custom input node?
You must include at least one input node in a message flow. Which one you choose depends on the source of the input messages:
- If the messages arrive at the broker on a WebSphere® MQ queue, use the MQInput node.
- If SOAP messages are received over HTTP, use the SOAPInput node.
- If other messages are received over HTTP, use the HTTPInput node.
- If the messages are received from a JMS source, use the JMSInput node.
- If the messages are received from an EIS, use the PeopleSoftInput, SAPInput, or SiebelInput node.
- If the messages are retrieved from files, use the FileInput node.
- If the message source is any other, you must use a user-defined input node.
For information about using more than one input node in a message flow, see Using more than one input node.
To successfully input the data concerned, does the input node have to interface with vendor software? If so, does the API that enables access to this software break your threading model?
Do you need a new user-defined parser to interpret the body (payload) of the message generated by this input node, or can it be parsed by a standard built-in parser?
Do you need the user-defined input node to operate the message flow instance in which it resides under transactional control as a globally-coordinated transaction?
Do you need the new user-defined input node to offer configuration options?
Do you need messages propagated by this input node to be processed by the following primitives?
- All primitive output nodes
- ResetContentDescriptor nodes

Design considerations

Before developing and implementing your input node, decide on the following factors:

Which message parser will initially parse the input message.
Whether to override the default message parser attribute values for this input node.
Which threading model is appropriate for the input node.
What kind of message processing and transaction support will the node support.
Which configuration attributes required by the input node should be externalized for alteration by the message flow designer.
What optional node APIs will the user-defined node provide.
How you will handle general development issues:
- Threading considerations for user-defined extensions
- Storage management in user-defined nodes
- String handling in user-defined nodes
- Errors and exception handling
- Expected message formats for primitive nodes that expect specific header folders.

When you design nodes to be used as extensions to WebSphere Event Broker, the following restrictions apply:

User-defined input nodes can support only XML, BLOB, and the WebSphere MQ parsers, because the MRM parser is not shipped with WebSphere Event Broker and user-defined parsers are not supported.
User-defined nodes must not allow users to evaluate user ESQL code, because the use of ESQL in WebSphere Event Broker is not supported. For example, nodes that expose the input to MbSQLStatement as a node attribute are effectively emulating a Compute node.

as01392_.htm |

Last updated Friday, 21 July 2017