The information in this topic applies to both output nodes and message processing nodes. Both of these node types can be considered together, because although a message processing node is typically used to process a message, and an output node is used to provide an output, in the form of a bitstream, from a message, you can use either type of node to perform either of these functions.
During the instantiation phase, an instance of a user-defined message processing node is created. The phase starts when the broker receives the table of function pointers, and calls the cniCreateNodeContext function for each instantiation of the user-defined node. The cniCreateNodeContext function is called for each message flow that is using your user-defined message processing node. This function should allocate memory for that instantiation of the user-defined node to hold the values for the configured attributes.
Within cniCreateContext, the broker calls the two functions cniCreateInputTerminal and cniCreateOutputTerminal to establish what input and output terminals the message processing node has.
A user-defined message processing node is registered with the broker when when the LIL containing the node has been loaded and initialized by the operating system.
The broker calls bipGetMessageflowNodeFactory to establish the function of your LIL, and how it should be called.
The bipGetMessageflowNodeFactory function in turn calls the cniCreateNodeFactory function, which returns a factory or group name for all the nodes supported by your LIL.
The LIL should then call the utility function cniDefineNodeClass to pass the name of each node and a virtual function table of the addresses of the implementation functions.
During the processing phase of the life-cycle of a user-defined message processing node, the message is transformed in some way, when some processing operation takes place on the input message.
When the broker retrieves a message from the queue and that message arrives at the input terminal of your user-defined node, the broker calls the implementation function cniEvaluate. This function is used to decide what to do with the message.
You can use a range of node utility functions in your user-defined message processing node to perform a range of message processing functions, such as accessing the message data, accessing ESQL, transforming a message object, and propogating a message. You should include the node utility functions you are going to use to process the message within the cniEvaluate function.
This interface does not automatically generate a properties subtree for a message. It is not a requirement for a message to have a properties subtree, although you might find it useful to create one to provide a consistent message tree structure regardless of input node. If you want a properties subtree to be created in a message, and you are also using a user-defined input node, you must do this yourself
When a user-defined message processing node has processed a message, you should ensure that it is destroyed, to release any system resources that it used, and to release any data areas specific to the node instance, such as context, that were acquired when the message was constructed or processed.
An instance of a user-defined message processing node is destroyed when the broker calls the cniDeleteNodeContext function. The broker calls cniDeleteNodeContext when
The registration phase occurs when a user-defined message processing node written in Java makes itself known to, or registers with, the broker.
Whenever a broker starts, it loads all relevant lils and java classes. To ensure that a message processing node is registered with the broker, you must provide the broker with a class that implements the MbNodeInterface interface, and is contained in the broker's classpath.
A Java User-defined message processing node is instantiated when a broker deploys a message flow containing the user-defined message processing node. When the node is instantiated, the constructor of the message processing node's class is called.
When a node is instantiated, any terminals you have specified using the relevant methods are created. A message processing node can have any number of input and output terminals associated with it. You must include the createInputTerminal and createOutputTerminal methods in your node constructor to declare these terminals.
Output terminals include out, failure, and catch terminals. Use the createOutputTerminal class within the node class constructor to create as many output terminals as you require.
As a minimum, you only need to create these output terminals using your constructor class. However, if you need to initialize attribute values, you should also include that code at this point in your message processing node.
If you want to handle exceptions that are passed back to your message processing node, it is good practice to do this by creating a failure terminal for your user-defined message processing node, using the createOutputTerminal method. It is sensible to use the failure terminal for this process because that is where WebSphere Business Integration Message Broker propgates errors to.
You should make sure that any exceptions caught by the message processing node are properly dealt with. If you do not include a failure terminal, the message processing node will not attempt to handle the exception. If your message flow does not contain any method of exception handling, any exceptions thrown are passed back to the input node, where they will be dealt with.
If you do catch exceptions, you should make sure that you rethrow any that the message processing node cannot deal with itself, so that the exception is passed to the input node for handling, for instance to rollback a transaction.
During the processing phase of the life-cycle of a user-defined message processing node, the message processing node takes the logical hierarchy of the message and processes it in some way.
A Java user-defined message processing node is destroyed when the node is deleted or the broker is shut down. You do not need to include anything in your code that specifies the node should be physically deleted, because this can be handled by the garbage collector.
However, if you want to be notified that a node is about to be deleted, you can use the onDelete method. You might want to do this if there are resources other than those that will be garbage collected that you want to delete. For example, if you have opened a socket, this will not be properly closed again when the node is automatically deleted. You can include this instruction in your onDelete method to ensure that the socket is properly closed.
Notices |
Trademarks |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
as01394_ |