Why use a user exit?

Use a user exit to intercept the progress of messages through message flows without having to redesign the message flow.

User exits provide a mechanism to apply actions (such as monitoring, message tracking, and auditing) operationally to deployed message flows at run time.

You can use user exits to call (by using callbacks) your custom C code, which is provided in a loadable exit library (LEL), at key points in message transactions in deployed message flows. These user exits can use utility functions from the user-defined extensions APIs to extract details of the integration node, integration server, message flow, node, and message assembly. In addition, the user exits can use utility functions from the user-defined extensions APIs to modify parts of the message assembly.

To write user exits, you must be a skilled programmer with an understanding of IBM® Integration Bus and its architecture. Testing and debugging user exits can be time-consuming, and must be done in a safe environment. You must also maintain and service your own user exit.

Consider the following design factors when you plan and write a user exit:
  • The effect on performance

    User exit callbacks are run inline with the current message transaction; that is, progress of the transaction is blocked until the return from the callback is received. Updating the message in a user exit callback can affect performance, particularly if the input message would not otherwise be changed in the message flow.

  • Message parse timing

    On-demand parsing, referred to as partial parsing, is used to parse a message bit stream only as far as is necessary to satisfy the current reference in the message assembly. A user exit can navigate the message at each of its callback points, which can mean that the parse timing of the message flow is changed when you enable the user exit.

  • Error handling
    To ensure that the error handling that is provided by the designer of a message flow that is being intercepted by a user exit continues to operate as designed, you must program the user exit in the following way:
    • All internal errors must be handled within the user exit, and the normal return from the callback must enable the message flow transaction to complete as normal.
    • All exception condition that is encountered when the user exit calls utility functions in the user-defined extensions APIs must be returned to the flow for normal error processing. This behavior is achieved by calling cciRethrowLastException() to cut short the callback processing.