Event emissions when using service mapping

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.

You can configure a local mapping service to emit events when a service request or response message is intercepted by that local mapping service. The events are published to a specified JMS topic, and contain details about the message. For example, the event contents can include the following pieces of information:
  • The date and time of the message
  • Whether the message is a request, a response, or a fault
  • The contents of the message
Events are emitted at two points during a service interaction:
  • When a request is intercepted by the local mapping service, before any routing or transformation has taken place (pre-map request). The event that is emitted contains the message that is sent by the client.
  • When a response is intercepted by the local mapping service, after any routing or transformation has taken place (post-map response). The event that is emitted contains the message that is received by the client.
Note: A service map does not need to be attached to the local mapping service in order for the local mapping service to emit events. A local mapping service without an attached service map can emit events, but does not perform any routing or transformation on the service messages that it intercepts.
The following diagram shows the two points during a service interaction when events are emitted by the local mapping service. The two arrows show the direction of flow of the service request or response when an event is emitted.
The diagram shows a service client that is connected to a service provider through a local mapping service. There is an arrow, labeled pre-map request, showing the flow of a service request from the service client to the local mapping service. A second arrow, labeled post-map response, shows the flow of a response message from the local mapping service to the service client. The service client and the local mapping service are shown in the same rectangle, which is labeled WebSphere Application Server, indicating they are hosted on the same application.
To use events, you must carry out the following steps:
  • In WebSphere® Application Server, configure JMS resources that the local mapping service uses to publish events
  • Configure the local mapping service to emit events to a JMS topic, by creating and enabling an event point
For more information about these configuration steps, see Producing and consuming service mapping events.

Options for consuming events

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.

The following diagram shows a topology where IBM Integration Bus is used to view events that are emitted by the local mapping service.
The diagram shows a service client that is connected to a service provider through a local mapping service. The service client and the local mapping service are shown in the same rectangle, which is labeled WebSphere Application Server. This rectangle also contains a JMS connection factory and a JMS topic. The JMS topic is connected to a WebSphere MQ queue manager by a client connection. The queue manager is connected to a DataCaptureSource configurable service and a DataCaptureStore configurable service. These configurable services are connected to a database. The queue manager, configurable services, and database are inside a rectangle that is labeled IBM Integration Bus.
If you are not using IBM Integration Bus, you can configure another JMS provider to distribute the events to a consuming application. For example, you can use the following topologies:
  • You can publish the events to the default messaging provider for WebSphere Application Server, and use a JMS application running in WebSphere Application Server to subscribe to this provider, so that you are notified of each event.
  • You can publish the events to a WebSphere MQ messaging provider, and use a JMS application to subscribe to the topic.
  • You can publish the events to any JMS messaging provider, and use a JMS application to subscribe to the JMS topic.

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.

The diagram shows a service client that is connected to a service provider through a local mapping service. The service client and the local mapping service are shown in the same rectangle, which is labeled WebSphere Application Server. This rectangle also contains a JMS connection factory, a JMS topic, and a message-driven bean.

Event points

To configure a local mapping service to emit events, you must create an event point on that local mapping service. An event point describes:
  • When the events are emitted
  • The event contents
  • The JMS topic that the events are published to
  • The details of the JMS connection factory that the JMS client uses to connect to the JMS provider
You can configure the event point to publish to a specified JMS topic. If a JMS topic is not specified, events are published to a topic by using the default topic string:
$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.
Note: This default topic string is passed to the Session.createTopic() method of the JMS provider. The string is compatible with both the default messaging provider for WebSphere Application Server and WebSphere MQ JMS providers. However, the string might not be compatible with other JMS providers. For JMS providers where the default topic string is not compatible with the Session.createTopic() method, you must specify a JMS topic when you create the event point.
You can configure the event point to affect the service request by canceling the service request if an event fails to publish, to ensure that every service request that is made has an associated published event.

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.

Event contents and schema

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.


Icon that indicates the type of topic Concept topic

Terms and conditions for information centers | Feedback


Timestamp icon Last updated: Tuesday, 22 April 2014
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=phil&product=was-express-iseries&topic=csmwas_eventemissions
File name: csmwas_eventemissions.html