cniRun
This function declares the node as an input node.
Message processing nodes and output nodes do not use it, and you do not need to call cniEvaluate. The integration node allocates a thread, and calls this function on that thread.
| Defined In | Type | Member |
|---|---|---|
| CNI_VFT | Conditional | iFpRun |
Syntax
int cniRun(
CCiContext* context,
CCiMessage* localEnvironment,
CciMessage* exceptionList,
CciMessage* message
);Parameters
context- The address of the context for the instance of the node, as created by the node and returned by the cniCreateNodeContext function (input).
localEnvironment- The address of the input local environment object (input).
For compatibility with earlier versions, you can refer to this parameter as
destinationList. exceptionList- The address of the exception list for the message (input).
message- The address of the message object to which the data is attached
(input).
The user-defined node can call cniSetInputBuffer to associate a bit stream with this message. Populating the tree of this message is not supported, therefore calls to functions such as cniAddAsLastChild or cniCreateElementAsLastChildFromBitstream do not work. To build parts of the tree, create a new message using cniCreateMessage rather than providing a buffer to be parsed as the whole message.
For example, if you have a bit stream that is to be used as the payload part of the message, and you also want to add a header, take the following steps:- Create a new message using cniCreateMessage.
- Create the header part in this new message by using the Syntax Element Access Utility functions, for example cniCreateElementAsLastChildUsingParser, and passing in the root element of this new message.
- Add fields to the header by using functions such as cniCreateElementAsLastChild.
- Create the body of the message by parsing your bit stream through calling cniCreateElementAsLastChildFromBitstream, and passing in the root element of this new message.
Return values
This function is called by the integration node as part of a loop. The meaning of the return value is as follows:
CCI_TIMEOUT- The input node did not receive its input data. This value means that control should be returned to the integration node in case message flow reconfiguration is being requested. A user-defined input node should return regularly to give control back to the integration node.
CCI_SUCCESS_CONTINUE- A message was successfully processed. The integration node performs default transaction commit processing. The input node's cniRun implementation function is called immediately so that the node can continue processing.
CCI_SUCCESS_RETURN- A message has been successfully processed. The integration node performs default transaction commit processing. The input node has determined that the thread is not required, and it is returned to the message flow thread pool. If this processing is performed on the only thread, or the last active thread, the integration node prevents this last thread being returned to the pool, otherwise no active threads are available to dispatch another thread. In this situation, the integration node invokes the cniRun implementation function immediately, as if CCI_SUCCESS_CONTINUE was returned.
CCI_FAILURE_CONTINUE- An error was detected in the processing of a message, and the node is requesting that transaction rollback processing is performed. The input node's cniRun implementation function is called immediately.
CCI_FAILURE_RETURN- An error was detected in the processing of a message, and the node is requesting that transaction rollback processing is performed. However, the input node has determined that the thread is not required and it can be returned to the message flow thread pool. If this processing is performed on the last active thread, the integration node prevents this last thread being returned to the pool, otherwise no active threads are available to dispatch another thread. In this situation the integration node invokes the cniRun implementation function immediately, as if CCI_FAILURE_CONTINUE was returned.