Troubleshooting common CEI-related issues with IBM Business Monitor

The Common Event Infrastructure (CEI) provides facilities for the runtime environment to persistently store and retrieve events from many different programming environments. Events flow from applications to the CEI and then to IBM® Business Monitor. This article shows you how to identify and troubleshoot some common CEI related errors in a Business Monitor application and the corresponding server configuration that might prevent you from seeing data in your dashboards. You'll learn how to validate and fix your event process configuration and how to tune CEI for Business Monitor performance improvements.

Yan Fang (fangyyan@cn.ibm.com), Advisory Software Engineer, IBM

Yan Fang photoYan Fang is an Advisory Software Engineer on the Asia Pacific customer technical support team. She provides worldwide Level 2 technical support for WebSphere Business Modeler, WebSphere Business Monitor, WebSphere Business Compass, and Business Space.



Pinyi Liu (liupinyi@cn.ibm.com), Staff Software Engineer, IBM

Pin Yi Liu photoPin Yi Liu is a staff software engineer on the Asia Pacific customer technical support team. He provides worldwide Level 2 technical support for WebSphere Business Modeler, WebSphere Business Monitor, WebSphere Business Compass & Business Space.



Qing Zou (qingzou@cn.ibm.com), Staff Software Engineer, IBM

Qing Zou photoQing Zou is a Staff Software Engineer on the Asia Pacific customer technical support team. She provides worldwide Level 2 technical support for WebSphere Business Modeler, WebSphere Business Monitor, WebSphere Business Compass, and Business Space.



20 September 2012

Introduction

IBM Business Monitor (Business Monitor) is a comprehensive business activity monitoring (BAM) software product that provides an up-to-date view of your business performance, as well as predictions so that you can take action before problems occur. If you find you are unable to monitor instances in the Business Monitor dashboard views, there may be a problem with your event process configuration might not be correct. Business Monitor consumes Common Base Events delivered by the CEI. This article will:

  • Help you troubleshoot event flow issues and provide additional debugging tips for common CEI-related issues in WebSphere Business Monitor V7, and IBM Business Monitor V7.5 and V8.
  • Specify some general steps to verify Business Monitor event processing issues
  • Describe how you can configure event group profiles and minimize unnecessary processing for better performance.

This article applies to BPEL-based event monitoring with Business Monitor. It does not cover all possible cases, but serves as a guideline when you encounter the symptoms defined in this article.


Collecting problem information

This section describes the basic information you should gather for Business Monitor event processing issues. This information is useful for your own problem investigation or when asking for support. For more information about the MustGather data for Business Monitor, refer to Collect troubleshooting data for WebSphere Business Space V6.1, V6.2 and V7.0, V7.5, V7.5.1.

  1. Problem Description: Provide a detailed description of the problem along with your own analysis of the problem.
    1. List the names of any models, events, or metrics that you believe might be involved in the issue.
    2. Think about how often the problem occurs. Include details about recent problem occurrences, including timestamps.
  2. Environment Description: Gather information about your environment and topology. For example, from the bin directory of each Business Monitor installation, run the versionInfo command with the maintenancePackages flag to check whether the Business Monitor fixpack versions in all cluster members are same: versionInfo –maintenancePackages
  3. Server logs: Check log information for each of the involved servers:
    1. State the exact error message received.
    2. Gather the logs and FFDC files from each server that is involved in the issue to check for the possible error messages with the associated timestamps.
  4. Traces: If the problem is reproducible, set the appropriate trace string in the appropriate section prior to reproducing the problem. If you can not understand the trace, you can request help from IBM technical support.
    1. For event processing problems for a model using queue based routing, set the trace string on each CEI target server or cluster to: *=info: com.ibm.events.distribution.*=all

      *=info: com.ibm.wbimonitor.router.distribution.<mmID>.<mmVersion>=all on a CEI target lets you limit the trace to routing information about events in and events out.

      For event processing problems on V6.2 or V7 for a model using queue bypass routing, set the trace string on each CEI target server or cluster and on the monitor model moderator to: *=info: com.ibm.wbimonitor.router.*=all.

      In addition, for any model regardless of routing method, set the trace specified above under the section for monitor model runtime problems. For more information, refer to MustGather for WebSphere Business Monitor.

    2. You may also be able to set a trace for the model version to see that events are being filtered out. The following trace string is an example how to enable trace for a model: <mmID>.<mmVersion>=all. For example, *=info: clipsbpm_2011.02.14T15.25.04Z=all.

    To enable or disable tracing, select Troubleshooting => Logs and Trace =>server_name => Change Log Detail Levels and set both the Configuration and Runtime to *=all=disabled to disable tracing or to the expected trace specifications if enabling tracing.

    Changes made on the Runtime tab take effect immediately. Changes made on the Configuration tab require a server restart to take effect.


General CEI configuration issues

If you cannot view data or events in your business space or dashboards after deploying a monitor model and emitting events, the problem may be an error in event processing. To resolve this problem, you should correct the configuration settings that relate to event processing. This section introduces some basic steps to identify and troubleshoot some common CEI related errors in the corresponding server configuration.

For more information on tuning the CEI for improved performance, see Tuning the CEI.

Verify that the CEI service is correctly configured

To determine whether CEI has been properly configured, do the following:

  1. Sign in to the WebSphere administrative console.
  2. Select Service Integration. If Common Event Infrastructure is listed below it, then CEI has been deployed.
  3. If you have run the deployEventService wsadmin task but have not restarted the deployment manager, CEI will not appear on the WebSphere administrative console. (If in doubt, you can simply restart your deployment manager to be sure).
  4. Deploying and configuring CEI is a manual task that consists of running several wsadmin commands. These commands are documented in the Information Center. At a high level, the sequence of commands is:
    1. deployEventService
    2. configEventServiceDB2DB
    3. enableEventService
    4. setEventServiceJmsAuthAlias

Verify that the CEI service is enabled

To determine whether CEI has been enabled, do the following:

  1. Log in to the WebSphere administrative console.
  2. For each server or cluster member:
    • Select Servers => Application servers and then click on the name of the server or cluster member.
    • Under Container Settings, expand Container Services.
    • Select Common Event Infrastructure Service.
    • Check Enable service at server startup, if it's not already checked.
    • Click Apply.
    • Click Container Services in the breadcrumb trail near the top of the page.
    • Select Startup beans service.
    • Check Enable service at server startup, if it's not already checked.
    • Click Apply.
  3. Click Save to save the configuration changes.
  4. In a standalone environment, restart the server. In a network deployment environment, synchronize the nodes and then restart the cluster.

After restarting, you should see a message similar to the following in the SystemOut.log file on the server (standalone environment) or at least one member of the cluster where the model is deployed (network deployment environment):

ConsumerDaemo I com.ibm.wbimonitor.mm.<model_name>_<version>.moderator.
ConsumerDaemonHandlerImpl startDaemon() CWMRT3005I: The Monitor Model 
"<model_name>_<version>" is starting consumption on this server or 
cluster member...

This message indicates that the monitor model has completed its initialization, and the model should be consuming and processing new inbound events from the appropriate source.


Verifying the CEI bus configuration

When your CEI bus fails to start, you should first check SystemOut.log for errors. If you find the following error message:
SWSIS1524E: Data source, jdbc/com.ibm.ws.sib/monSuppCluster-CommonEventInfrastructure_Bus, not found.
you need to create a JDBC data source and run the database scripts that create the CEI messaging engine data store.

If you find the following error message:
CWSIT0073W: No intra-bus messaging engine authentication alias is configured.
you need to run the setEventServiceJmsAuthAlias command, using the following parameters for a clustered environment:

$AdminTask setEventServiceJmsAuthAlias { -clusterName monSupportCluster 
–userName monadmin –password monadmin }
$AdminConfig save

Verifying monitor model CEI configuration

This section describes some of the problems you may encounter when installing a monitor model, and how to resolve them.

Cannot create RMI connector

In the monitor life cycle, the step Select Monitor Model CEI options deployment fails with the error ADMC0017E: Could not create an RMI connector to connect to host <remote_host_name> at port <port> due to insufficient or empty credentials.

There is also a message in SystemOut saying that authentication failed when using LTPA keys. Sometimes, in a cross-cell configuration, the LTPA keys must be exchanged as follows:

  1. Export the LTPA keys from cell 1.
  2. Import the LTPA keys from cell 1 into cell 2.
  3. Export the LTPA keys from cell 2.
  4. Import the LTPA keys from cell 2 into cell 1.
  5. In a standalone environment, restart both servers. In a network deployment environment, restart both deployment managers.

For more information, refer to Sharing LTPA keys and RMI connection issue caused by LTPA key mismatch.

Problem retrieving list of event group profile names

An error occurs after you click Refresh List to retrieve a list of event group profile names from the remote CEI. This error is caused by a mismatch of security settings between the Business Monitor server and the remote CEI.

This problem occurs because the RMI/IIOP security settings are not the same for the Business Monitor server and the remote CEI. The RMI/IIOP security settings must be set in a way that allows credentials to be transferred.

To resolve this problem, check the security settings in two places as follows:

  1. In the WebSphere Application Server Administrative Console for the Business Monitor server, select Security => Secure administration, applications and infrastructure => RMI/IIOP security => CSIv2 outbound authentication.
  2. In the Administrative Console for the remote CEI, select Security => Secure administration, applications and infrastructure => RMI/IIOP security => CSIv2 inbound authentication.

You can use either the Basic authentication or the Client certificate authentication to allow credentials to be sent to the remote CEI.

If you are using Basic authentication, you must select a value of at least Supported (do not select Never) in the CSIv2 outbound authentication settings for the Business Monitor server and in the CSIv2 inbound authentication settings for the remote CEI.

If you are using Client certificate authentication, you must select a value of at least Supported (do not select Never) in the CSIv2 outbound authentication settings for the Business Monitor server and in the CSIv2 inbound authentication settings for the remote CEI.


Monitor model deployment issues

When a new version of an existing monitor model is installed on a production mode server, all active monitoring context (MC) instances from the previous version must be moved to the new version. Then the CEI distribution mode of the new version can be set to "Active" if any previous versions have a CEI distribution mode set to "Inactive (event queue recoverable)".

You can check the number of active MC instances for the previous version on the Version Details page for the previous version in the WebSphere Application Server administrative console. If the number is greater than 0, then the LifecycleServices MBean method must be invoked before the CEI distribution mode of the new version can be set to "Active" by typing the following (as one line):

LifecycleResultsBean moveMCInstances( String modelID, long versionDate, 
long toVersionDate, boolean activeInstancesOnly )

You can also invoke this method using the wsadmin utility (this should be typed as two lines):

set ls [$AdminControl completeObjectName type=LifecycleServices,*] 

$AdminControl invoke $ls moveMCInstances { "modelID", versionDate, 
toVersionDate, true }

where model_ID is the ID of the model, versionDate is the previous version with a CEI distribution mode set to "Inactive (event queue recoverable)" and toVersionDate is the new version.

Once this command has successfully completed for each previous version with active MC instances, you will be able to change the CEI distribution mode of the new version to Active using the Change CEI Distribution Mode link on the Version Details page for the new version.

If the moveMCInstances command fails and you are able to manually move the active MC instances using other means, or you decide to ignore the active MC instances, you can invoke the following LifecycleServices MBean method (this should be typed as one line):

LifecycleResultsBean confirmMoveMCInstances( String modelID, 
long versionDate, long toVersionDate )

You will then be able to change the CEI distribution mode of the new version to "Active" as described.

Unable to change CEI configuration on installed monitor model

In general, if active monitoring contexts (MCs) or scheduled services for an installed monitor model exist they will prevent the CEI configuration from being modified. To make this work, you need to ensure the following conditions are met:

  1. There are no active monitoring contexts (MCs) for that model.
  2. The monitor model is stopped.
  3. All scheduled services for the model are suspended.

You will also get an LTPA authentication exception when changing the CEI configuration on a model with multiple version under the following conditions:

  • Multiple versions of a monitor model are installed.
  • The CEI target is remote.
  • The CEI distribution mode of at least one version is not Inactive.
  • The credentials (user name and password) for the administrative user on the cell or the server hosting the remote CEI instance have changed since the last version of the model was installed.

If any version of the model has a CEI distribution mode other than Inactive, the only way to change the CEI user ID or password (for all versions of the model) is to use the applyCEICredentials() method of the LifecycleServices MBean. Refer to the technote Multiple versions model to change CEI distribution mode got LTPA authentication exception after CEI password changed for detailed instructions.

Queue bypass configuration issue with remote CEI server

This issue occurs in a cross-cell configuration. When you are using the wbmConfigureQueueBypassDatasource command on the remote deployment manager to create the data source for Business Monitor, it is likely that no jdbcProvider definition exists on the remote CEI server, so you must create the required jdbcProvider definition before running the command.

To create a jdbcProvider definition on your remote CEI server, create a definition on the cell scope that matches the MonitorDBProvider jdbcProvider definition on your Business Monitor server.


CEI event processing issues

This section describes some Business Monitor related event processing issues and steps to resolve them.

Locked messages

In a network deployment environment, remember that the start-up and shut-down order of your servers is important. This will avoid the locked events situation or the locked or in-doubt state. You should always use the following order to stop the monitoring environment:

  1. Stop the cluster hosting the monitor model applications.
  2. Stop the cluster hosting the CEI server.
  3. Stop the cluster hosting the messaging engine.

And the following order to start the environment:

  1. Start the cluster hosting the messaging engine.
  2. Start the cluster hosting the CEI server.
  3. Start the cluster hosting the monitor model applications.

If events processing stops due to "database locked" error messages in the logs, you have to delete the locked message. Messages get into a locked state because they are on a queue. CEI attempts to deliver a message to an application over the SIB. CEI waits for the application to send an acknowledgement back that says "We now have the message". If CEI gets that acknowledgement, it unlocks the message and it disappears from the queue. If CEI does not get an acknowledgement it will keep the message locked until it is received.

When a message is in a locked state on a queue you can't delete it, because it is in the middle of an internal transaction. Deleting it would mean having to break the transaction, which is an unsafe practice that is not recommended. You can use the SIB Destination Handler to help you move locked messages off the queue.

If locked messages can't be removed using either the administrative console or the SIB Destination Handler, you may have to manually delete them from the database. Please ask IBM Support for assistance in deleting locked messages from database.

Empty CEI event filter condition causes unrecoverable events

An inbound event in a monitor model that is defined with an empty filter condition can lead to a large number of unexpected results, such as unrecoverable events, at monitor model runtime.

When a monitor model is created in the Monitor Model editor, the following warning is displayed if an inbound event does not have a filter condition defined:
CWMMV0705W: A filter expression or extension name should be specified, or this definition will match all events.

If this warning message is observed while creating a monitor model, you should add a filter condition for the corresponding inbound event before deploying the monitor model.

If the monitor model has already been deployed and there are many unrecoverable events that become difficult to manage, consider revising the monitor model to include specific filter conditions for inbound events.

See the Inbound events section of the Information Center for information about filter conditions.

CEI server fails to distribute an event notification

When using Business Monitor, the CEI server failed to distribute an event notification. The following error appears in the Business Monitor server SystemOut.log:

EventDistribu E com.ibm.events.distribution.impl.EventDistribution 
publishEventNotifications CEIES0011E The event server failed to 
distribute an event notification.
Exception message: CEIES0004E No event notifications were sent 
because the event server could not connect to the Java Message 
The event group name is all events.
JMS connection factory Java Naming and Directory Interface 
(JNDI) name: jms/cei/notification/AllEventsTopicConnectionFactory
JMS destination JNDI name: jms/cei/notification/AllEventsTopic

Security may not be configured for the following factories: QueueConnection Factory, Activation Specifications, and Topic Connection Factories. To fix this error, configure security for the factories by doing the following:

  1. In the administrative console, select Resources => JMS => Queue connection factories.
  2. Click CommonEventInfrastructure_QueueCF.
  3. Scroll down to the Advanced Administrative section and specify CommonEventInfrastructureJMSAuthAlias for the component-managed authentication alias.
  4. Select Resources => JMS => Activation Specifications.
  5. Select CommonEventInfrastructure_ActivationSpec.
  6. Scroll down to the Additional section and specify CommonEventInfrastructureJMSAuthAlias for the authentication alias.
  7. Select Resources => JMS => Topic Connection Factories.
  8. Select CommonEventInfrastructure_AllEventsTopicCF.
  9. Scroll down to the Advanced Administrative section and specify CommonEventInfrastructureJMSAuthAlias for the Component-managed authentication alias.

Understanding the Business Monitor event flow

Figure 1 illustrates the Business Monitor event flow.

Figure 1. Business Monitor event flow
Event flow

The following sections describe tips for troubleshooting the event flow. For more information on verifying that event processing is working correctly, refer to the CEI and monitor model queue information in the following Information Center topics:

Verify that Business Monitor is installed on the nodes

Verify that Business Monitor is installed on the nodes by doing the following:

  1. In the administrative console, select System Administration => Nodes, as shown in Figure 2.
    Figure 2. Node configuration
    Node configuration
  2. Check the version column for the node to verify that Business Monitor is listed, as shown in Figure 3.
    Figure 3. Monitor version
    Monitor version

Verify that CEI logging been enabled on the WebSphere Process Server server or cluster

If CEI logging has not been enabled, then Business Process Choreographer events will not be emitted from Process Server. Please note that SCA events will be emitted without the CEI logging settings for the Business Process Choreographer being enabled. If only SCA events are being received on a model queue and Business Process Choreographer events are expected, checking the CEI logging settings is a good initial troubleshooting step. If you have multiple environments with the same model and many more events reach a model queue per process instance in one environment, you should check the CEI logging settings for the environment where fewer events are reaching a model queue. To verify the settings, do the following:

  1. In the administrative console, select either Servers => Clusters or Servers => Servers, depending on your topology.
  2. Select the cluster or server where Business Process Choreographer and the emitting applications are running.
  3. Under Container Settings, expand Business Process Choreographer Container Settings and select Business Process Choreographer Containers.
  4. Scroll down and under State Observers ensure that Common Event Infrastructure Logging is enabled for both Business Flow Manager and Human Task Manager, as shown in Figure 4. This ensures that Business Process Choreographer logs or emits CBE events to CEI for these items.
    Figure 4. CEI logging
    CEI logging enabled

Verify the service integration bus link

If this is a cross-cell configuration, you should also verify the status of the service integration bus link. For information on how to do this, refer to Verifying the remote Business Monitor bus and service integration link in the Business Monitor Information Center.

Verify that the model CEI configuration is correct

Verify that the model CEI configuration is correct by doing the following:

  1. In the administrative console, select Applications => Monitor Models.
  2. Click on the model ID in the Model column.
  3. Under Model Properties, select Change CEI configuration, as shown in Figure 5.
    Figure 5. Monitor model properties
    Monitor model properties
  4. Verify that the settings are correct as follows (refer to Figure 7):
    • Local should be selected if you're monitoring events from the same cell (in a CEI where events are emitted to in the same cell). Remote should be selected for cross-cell monitoring (using a SIB link to get events emitted to CEI in another cell).
    • Make sure that the proper host and port are specified.
    • Ensure that security is enabled or disabled as appropriate in the cell where the CEI is located and provide the proper credentials.
    • Make sure the Scope column contains information that matches where you are trying to connect to.
  5. If you need to make any changes, you must first set the CEI Distribution mode for the model to Inactive (see the next step for information verifying that the monitor model is active). After making any changes to the Location or Security sections, click Refresh List and select the appropriate Event group profile list before clicking Apply.
    Figure 6. Change CEI configuration
    hange CEI configuration

Verify that the monitor model is active

Verify that the monitor model is active by doing the following:

  1. In the administrative console, select Applications => Monitor Models.
  2. Click the timestamp in the Version column, as shown in Figure 7.
    Figure 7. Monitor Models
    Monitor Models
  3. Under General Properties, check that the CEI Distribution mode field is listed as Active so that this model can receive events. If it is listed as Inactive, you need to set it to Active. To do this, under Version Properties select Change CEI distribution mode, as shown in Figure 8.
    Figure 8. General properties for specific monitor model version
    General properties for specific monitor model version
  4. Under Target, select Active or the appropriate mode that you would like to switch to from the drop-down menu, as shown in Figure 9, then click Apply.
    Figure 9. Change CEI distribution mode
    Change CEI distribution mode
  5. You will see a message like Inactive to Active while it's attempting to switch. This may take a few minutes to update. After it completes, you should see that status listed as Active (monitor model queue by pass) in the menu in Figure 7.

Verify that there is an event group for the monitor model version

If the model is listed as Active, complete the following steps to verify that there is an event group for the monitor model version:

  1. To check this, you will be checking the cell in which events are being emitted to CEI. For a cross-cell configuration, this would be the separate remote WebSphere Process Server cell.
  2. In the administrative console, select Service Integration => Common Event Infrastructure => Event Service.
  3. Under Additional Properties, select Event Services.
  4. In the Name column, select the event service to which events are being emitted, as shown in Figure 10.
    Figure 10. CEI Event services
    CEI Event services
  5. Under Additional Properties, select Event Groups, as shown in Figure 12.
    Figure 11. CEI Event services properties
    CEI Event services properties
  6. You should see an event group that contains your monitor model name and version timestamp, similar to Figure 12.
    Figure 12. Event group
    Event group

    Verify that the Event Selector String is correct for each monitor model. If the event selector string is not correct, the CEI server will filter out incoming events and those events would not be distributed to the event consumer.

Verify that an INCOMING_EVENTS table exists

If you are using a table-based configuration(known as queue bypass in V7) for Business Monitor V6.2 or higher, make sure that the INCOMING_EVENTS table has been created in your Business Monitor database. You should be able to see the table under the schema with the same name as your deployed monitor model, as shown in Figure 13.

Figure 13. INCOMING_EVENTS table
INCOMING_EVENTS table

Tuning the CEI

The CEI allows service components to emit events that can be captured by Business Monitor for real-time monitoring of business processes. Tuning the CEI is therefore an important factor in improving Business Monitor performance. By default, events are delivered from CEI to the MONITOR database using the table-based method (known as queue bypass in V7), bypassing an intermediate queue. We recommend using this default delivery style for better performance, as it avoids an additional persistence step in the flow and, for V7.5 or later, the monitor model applications can take advantage of scalability enhancements to scale with the number of cluster members in the cluster. The following sections describe additional recommended CEI performance tuning.

Disable the event data store

To improve performance in a production environment, you should disable the event data store and event persistence. When CEI is configured in a production environment, the event data store is disabled by default because enabling event data store may cause performance problems. To make sure the data store is disabled, do the following:

  1. Sign in to the administrative console.
  2. Select Service Integration => Common Event Infrastructure => Event Services.
  3. Under Additional properties, click Event Services.
  4. Click the link in the Name column to select the appropriate CEI event service.
  5. Uncheck Enable event data store, as shown in Figure 14.
  6. Click OK, then save your changes to the master configuration.
    Figure 14. Disable the event data store
    Disable the event data store

Disable event persistence for all applications

Your events are first routed to the common event infrastructure, where they may be stored in the event database (depending on your settings) for use by the Common Base Event browser. Next events are distributed to your monitor model application deployed in Business Monitor, where events are processed and the resulting metrics are stored in the Business Monitor database for use by dashboards.

To disable event persistence for all applications, do the following:

  1. Sign in to the administrative console.
  2. Select Service Integration => Common Event Infrastructure => Event Service.
  3. Under Additional properties, click Event Services.
  4. Click the link in the Name column to select the appropriate CEI event service.
  5. Under Additional properties, click Event groups.
  6. Click the link in the Event Group Name column to select the All events event group.
  7. Uncheck Persist events to event data store.
  8. Click OK, then save and synchronize your changes and restart the server or cluster.

In addition, you should disable the event datastore and event persistence.


Conclusion

The Common Event Infrastructure (CEI) provides users with the ability to create and manage business and system events so that users can correlate and integrate information across systems using the CEI. The monitor model running on IBM Business Monitor receives events from the Common Event Infrastructure (CEI) and calculates the business measures. This article described how to identify and troubleshoot some common CEI related errors in a Business Monitor application and the corresponding server configuration if users are unable to view data in the dashboards. It also gave some suggestions on how to validate and correct for Business Monitor related event processing issues and how to tune CEI for performance improvements.

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Business process management on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Business process management, WebSphere
ArticleID=848602
ArticleTitle=Troubleshooting common CEI-related issues with IBM Business Monitor
publish-date=09202012