Before you start
A loadable implementation library, or a LIL, is the implementation module for a C node (or parser). A LIL is implemented as a dynamic link library (DLL). It does not have the file extension .dll but .lil.
The implementation functions that have to be written by the developer are listed in C language node implementation functions. The utility functions that are provided by WebSphere Business Integration Message Broker to aid this process are listed in C language node utility functions.
WebSphere Business Integration Message Broker provides the source for two sample user-defined nodes call SwitchNode and TransformNode. You can use these nodes in their current state, or you can modify them.
An input node can receive data from any type of external source, such as a file system or FTP connections, as long as the output from the node is in the correct format. For connections to queues or databases, you should use the IBM primitive nodes and the API calls supplied, principally because the primitive nodes are already set up for error handling. Do not use the mqget or mqput commands for direct access to database tables.
{ static char* functionName = (char *)"_Input_run()"; void* buffer; CciTerminal* terminalObject; int buflen = 4096; int rc = CCI_SUCCESS; int rcDispatch = CCI_SUCCESS; char xmlData[] = "<A>data</A>"; buffer = malloc(buflen); memcpy(buffer, &xmlData, sizeof(xmlData)); cniSetInputBuffer(&rc, message, buffer, buflen); } /*propagate etc*/ free(buffer);The above example illustrates an area of memory being allocated (buffer = malloc(buflen);). When programming in C, whenever you allocate memory you must free it when you no longer need it. The broker might attempt to access this memory at any time whilst the message is being propagated through the flow, so you should free the memory only after calling cniPropagate on the same CciMessage.
An input node has a responsibility to perform appropriate end of message processing when a message has been propagated through a message flow. Specifically, the input node needs to cause any transactions to be committed or rolled back, and return threads to the thread pool.
Each message flow thread is allocated from a pool of threads maintained for each message flow, and starts execution in the cniRun function. You determine the behavior of a thread using the cniDispatchThread utility function together with the appropriate return value.
The term transaction is used generically here to describe either a globally coordinated transaction or a broker controlled transaction. Globally coordinated transactions are coordinated by either WebSphere MQ as an XA compliant Transaction Manager, or Resource Recovery Service (RRS) on z/OS . WebSphere Business Integration Message Broker controls transactions by committing (or rolling back) any database resources and then committing any WebSphere MQ units of work, however, if a user-defined node is used, any resource updates cannot be automatically committed by the broker. The user-defined node uses return values to indicate whether a transaction has been successful, and to control whether transactions are committed or rolled-back. Any unhandled exceptions are caught by the broker infrastructure, and the transaction is rolled back.
The following table describes each of the supported return values, the affect each one has on any transactions, and what the broker does with the current thread.
Return value | Affect on transaction | Broker action on the thread |
---|---|---|
CCI_SUCCESS_CONTINUE | committed | Calls the same thread again in the cniRun function. |
CCI_SUCCESS_RETURN | committed | Returns the thread to the thread pool. |
CCI_FAILURE_CONTINUE | rolled back | Calls the same thread again in the cniRun function. |
CCI_FAILURE_RETURN | rolled back | Returns the thread to the thread pool. |
CCI_TIMEOUT | Not applicable. The function periodically times out while waiting for an input message. | Calls the same thread again in the cniRun function. |
{ ... cniDispatchThread(&rcDispatch, ((NODE_CONTEXT_ST *)context)->nodeObject); ... if (rcDispatch == CCI_NO_THREADS_AVAILABLE) return CCI_SUCCESS_CONTINUE; else return CCI_SUCCESS_RETURN; }
Before you propagate a message, you have to decide what message flow data you want to propagate, and what terminal is to receive the data.
The terminalObject is derived from a list that the user-defined node maintains itself.
if (terminalObject) { if (cniIsTerminalAttached(&rc, terminalObject)) { if (rc == CCI_SUCCESS) { cniPropagate(&rc, terminalObject, destinationList, exceptionList, message); } }
In the above example, the cniIsTerminalAttached function is used to test whether the message can be propagated to the specified terminal. If you do not use the cniIsTerminalAttached function, and the terminal is not attached to another node by a connector, the message is not propagated. If you do use this function, you can modify the node's behavior when a terminal is not connected.
A user-defined node identifies itself as providing the capability of an input node by implementing the cniRun implementation function. User-defined input nodes have to implement a cniRun function, otherwise the broker does not load the user-defined node, and the cniDefineNodeClass utility function fails, returning CCI_MISSING_IMPL_FUNCTION. When a message flow containing a user-defined input node is deployed successfully, the broker calls the node's cniRun implementation function at regular intervals.
int cniRun( CciContext* context, CciMessage* destinationList, CciMessage* exceptionList, CciMessage* message ){ ... /* Get data from external source */ return CCI_SUCCESS_CONTINUE; }The return value should be used to return control periodically to the broker.
When a message flow containing a user-defined input node is deployed successfully, the node's cniRun function is called for each message passed through the message flow.
Input nodes can also implement cniEvaluate, however this is not recommended.
Attributes are set whenever you start the broker, or when you redeploy the message flow with new values.
{ const CciChar* ucsAttr = CciString("nodeTraceSetting", BIP_DEF_COMP_CCSID) ; insAttrTblEntry(p, (CciChar*)ucsAttr, CNI_TYPE_INTEGER); _setAttribute(p, (CciChar*)ucsAttr, (CciChar*)constZero); free((void *)ucsAttr) ; } { const CciChar* ucsAttr = CciString("nodeTraceOutfile", BIP_DEF_COMP_CCSID) ; insAttrTblEntry(p, (CciChar*)ucsAttr, CNI_TYPE_STRING); _setAttribute(p, (CciChar*)ucsAttr, (CciChar*)constSwitchTraceLocation); free((void *)ucsAttr) ; }
When the broker knows that it has an input node, it calls the cniRun function of this node at regular intervals. The cniRun function must then decide what course of action it should take. If data is available for processing, the cniRun function should call cniDispatchThread and process the message, or return with CCI_TIMEOUT so that the broker can continue to process other messages on other threads. If a thread is not dispatched, the broker spends all of its time within this thread, which stops it from doing anything else.
If ( anything to do ) CniDispatchThread; /* do the work */ If ( work done O.K.) Return CCI_SUCCESS_CONTINUE; Else Return CCI_FAILURE_CONTINUE; Else Return CCI_TIMEOUT;
An input node implementation normally determines what message parser initially parses an input message. For example, the primitive MQInput node dictates that an MQMD parser is required to parse the MQMD header. A user-defined input node can select an appropriate header or message parser, and the mode in which the parsing is controlled, by using the following attributes that are included as default, which you can override:
CciFactory LilFactoryExportPrefix * LilFactoryExportSuffix bipGetMessageflowNodeFactory() { .... CciFactory* factoryObject; .... factoryObject = cniCreateNodeFactory(0, (unsigned short *)constPluginNodeFactory); ... vftable.iFpCreateNodeContext = _createNodeContext; vftable.iFpSetAttribute = _setAttribute; vftable.iFpGetAttribute = _getAttribute; ... cniDefineNodeClass(&rc, factoryObject, (CciChar*)constSwitchNode, &vftable); ... return(factoryObject); }
CciContext* _createNodeContext( CciFactory* factoryObject, CciChar* nodeName, CciNode* nodeObject ){ NODE_CONTEXT_ST* p; ... /* Allocate a pointer to the local context */ p = (NODE_CONTEXT_ST *)malloc(sizeof(NODE_CONTEXT_ST)); /* Create attributes and set default values */ { const CciChar* ucsAttrName = CciString("firstParserClassName", BIP_DEF_COMP_CCSID) ; const CciChar* ucsAttrValue = CciString("MYPARSER", BIP_DEF_COMP_CCSID) ; insAttrTblEntry(p, (CciChar*)ucsAttrName, CNI_TYPE_INTEGER); /*see sample BipSampPluginNode.c for implementation of insAttrTblEntry*/ _setAttribute(p, (CciChar*)ucsAttrName, (CciChar*)ucsAttrValue); free((void *)ucsAttrName) ; free((void *)ucsAttrValue) ; }
Nodes are destroyed when a message flow is redeployed, or when the execution group process is stopped (using the mqsistop command). When a node is destroyed, it should free any used memory and release any held resources. You do this using the cniDeleteNodeContext function. For example:
void _deleteNodeContext( CciContext* context ){ static char* functionName = (char *)"_deleteNodeContext()"; return; }
Notices |
Trademarks |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
as09960_ |