Use event emissions to monitor services. Events can be used to log details of service requests and responses to demonstrate which interactions happened at a particular date and time, and whether those interactions were successful.
The events that are emitted by the local mapping service are published to a JMS topic that can be specified when you configure event emission. By subscribing to this JMS topic, you can use this event information to monitor the business status of your systems. You can choose how to view these events. IBM Integration Bus has built-in functions for viewing and processing the events that are produced by the local mapping service. Alternatively, you can publish the events into any JMS provider that you configure in WebSphere Application Server.
Using IBM Integration Bus to consume the events allows you to use its data capture functions. You can store the data, and then view the recorded data through the web user interface or programmatically. You can use these data capture functions for archive, audit, or problem determination purposes. For more information, search for "record and replay" in the IBM Integration Bus information center.
To configure IBM Integration Bus to view the events, you must configure JMS resources that connect to the WebSphere MQ queue manager of IBM Integration Bus and publish messages to a WebSphere MQ topic. For more information about how to configure these resources, see Producing events for consumption by IBM Integration Bus.
For any of these scenarios, you must also configure a JMS unified connection factory and a JMS topic for the messaging provider. You can specify which JMS topic to publish the events to when you create the event point. For more information about these options, and how to configure the required JMS resources, see Producing events for consumption by JMS applications. The following diagram shows an example of a possible topology, with a message-driven bean that processes events that are emitted by the local mapping service.
$SYS/AppServer/<cell_name>/<node_name>.<server_name>|<cluster_name>/<client_application_name>/<LMS_name>/<operation_name>
Where either <node_name>.<server_name> must
be specified, or <cluster_name> must
be specified, depending on your configuration.You can also set up the event point to participate in global transactions, by sending events from the local mapping service only when the global transaction is committed. By participating in a global transaction you can ensure that events are emitted only when the entire service request and response complete. Service requests can be included in the global transaction by using the Web Services Atomic Transaction (WS-AT) standard, see WS-Transaction.
Because the event point is created on a local mapping service, the event point is a cell-wide configuration. Service client requests from any application within the cell can be intercepted by the local mapping service and can cause an event to be published. If the local mapping service is stopped, events are not published. For more information about how to create an event point for service mapping, see Creating an event point on a local mapping service.
The emitted events are in an XML format and follow the schema that is described in Service Mapping events schema. If the event point has been configured to include request or response data within the event, that data is based on the state of the SOAP request when it is intercepted. The event can contain unencrypted data because the local mapping service intercepts service requests before any WS-Security or transport-level encryption, and intercepts responses after decryption. If you are using the default messaging provider for WebSphere Application Server, see Administering topic space root roles for more information about topic space security. If you are using the WebSphere MQ messaging provider, search for "publish/subscribe security" in the WebSphere MQ Information Center for more information about configuring access to topics.