> Configuring and Managing Advanced Registration Flows > Configuring the ALER Event Manager

Configuring and Managing Advanced Registration Flows

     Previous  Next    Open TOC in new window    View as PDF - New Window  Get Adobe Reader - New Window
Content starts here

Configuring the ALER Event Manager

This section discusses the Event Manager configuration that needs to be completed before using the Advanced Registration Flows. It contains information on the following subjects:

 

What Is the ALER Event Manager

The Event Manager is a component embedded within ALER that manages event subscriptions, event persistence, event filtering, and event delivery. Web Service endpoints can subscribe to the Event Manager's Subscription Manager and the asset registration events that are generated within ALER are delivered to the Web Service endpoints.

The following diagram shows the different components that are involved.

Figure 3-1 Advanced Registration Flow Components

Advanced Registration Flow Components

Figure 3-2 Advanced Registration Flow Components

The Event Manager uses an embedded version of Apache ActiveMQ JMS Server that is enabled by default. The embedded JMS server is configured to run out-of-the-box without any additional configuration. However, you can also configure the Event Manager to use an external JMS server, such as Weblogic Server JMS or IBM WebSphere.

This section discusses the Event Manager configuration that needs to be completed before using the Advanced Registration Flows. For information on configuring the Advanced Registration Flows, see Configuring Advanced Registration Flows.

 

Configuring the Event Manager's System Settings

ALER's System Settings section allows administrators to configure the basic ALER operation and to enable/disable specific features. The Event Manager-related settings are under the "Eventing" group under the main "External Integrations" category. For more information about System Settings, see the ALER Administration Guide.

Additional "Eventing" properties are available for configuring an external JMS server, such WebLogic Server and IMB WebSphere, and are described in Configuring JMS Servers for ALER.

Enabling the Event Manager

The Event Manager needs to be enabled in ALER to allow the Event Manager to send events to external Web Service endpoints.

  1. Click System Settings in the sidebar on the ALER Admin screen.
  2. Enter Event in the System Settings Search box to view all the Event Manager related settings.
  3. Click True next to the Enable Event Manager property.
  4. Click Save.
  5. Restart ALER for the configuration changes to take effect.

Configuring Optional Event Manager Settings

There are some optional "Eventing" properties that you can use to tune the Event Manager performance.

Note: You must restart ALER after changing any Eventing property in order for the changes to take effect.

Eventing Manager Notifier Thread Sleep (seconds)

If an endpoint is not unavailable when one or more events should be delivered to that endpoint, the Event Manager notifier will retry delivering the event until the endpoint is available. The cmee.eventframework.notifier.sleep property configures in seconds how long the notifier should wait before trying to redeliver an event.

Eventing Manager Store Thread Sleep (seconds)

As soon as an event is triggered, the Event Manager stores the event in memory before pushing it to the JMS server so that the ALER thread is not blocked. The cmee.eventframework.store.sleep property specifies how long the Event Manager's Store Manager thread should sleep before polling for the next event stored in memory. The default polling delay is 60 seconds.

Eventing Manager Store Delivery Sleep (seconds)

By default, the Event Manager delivers events in batches. The cmee.eventframework.delivery.sleep property specifies how long the Event Manager's Delivery Manager thread should sleep before selecting the next available batch of events from the JMS server. The default delay between each batch is 7200 seconds (two hours).

Tip: The default cmee.eventframework.store.sleep and cmee.eventframework.delivery.sleep property values can be tuned to control the overall performance of ALER and the Web Service endpoints. These properties directly impact the number of events that get triggered per second by the Event Manager. For example, If a faster response is required for testing purposes, the default cmee.eventframework.delivery.sleep value of 7200 seconds should be changed to a reasonable testing amount.

Batch Size for Event Manager Deliveries

When the Event Manager delivers events in batches, the delivered batch size can be configured using the cmee.eventframework.delivery.batch.size property. The default batch size is 100 events. If the Event Manager finds less number of events to deliver, it will deliver the available events and then sleep for the time configured in the cmee.eventframework.delivery.sleep property.

 

Configuring the Subscription Manager

The Subscription Manager is responsible for managing the event subscriptions by the Web Service endpoints where the matched events will be delivered.

The Subscription Manager configuration file is located in <aler webapp name>\WEB-INF\classes\EndPointEventSubscription.xml.

Configuring Web Service Endpoints

The Event Manager uses the EndPointEventSubscription.xml file to load information about the Web Service endpoints where events need to be delivered. The host, port, URI, user and password of the predefined ALPBM endpoint, or user-defined Web Service endpoint, need to be configured, as shown in this example snippet: 

<sub:EventSubscriptionData xmlns:sub="http://www.bea.com/infra/events/subscription" xmlns:xsi=???
  <sub:eventSubscription>
    <sub:endPoint name="ALBPMEndpoint">
      <sub:host>maplanis01.amer.bea.com</sub:host>
      <sub:port>9000</sub:port>
      <sub:uri>fuegoServices/ws/StatusChangeEnpointServiceListener</sub:uri>
      <sub:targetNamespace>StatusChangeEndpoint</sub:targetNamespace>
      <sub:operationName>newEvent</sub:operationName>
      <sub:authenticationData>
        <sub:basicAuthentication>
          <sub:username>aler_workflow_user</sub:username>
          <sub:username>aler_workflow_user</sub:username>
        </sub:basicAuthentication>
      </sub:authenticationData>
    </sub:endPoint>
    <sub:notifierClass>com.bea.infra.event.notifier.help.AlbpmHTTPEventNotifier    </sub:notifierClass>
    <sub:expression>id &gt; 500</sub:expression>
  </sub:eventSubscription>
</sub:EventSubscriptionData>

As many endpoints can be added as desired and the endpoints can be located in different hosts or ports and the events can be load balanced. The pre-defined Advanced Registration Flow has just one endpoint called "StatusChangeEndpoint".

Setting the Expression to Filter Events

Events can be filtered based on the value entered in the expression element.

Delivering all Events to an Endpoint

The default setting is to deliver all events to an endpoint. All the events that are triggered within ALER are delivered to the OOTB endpoint when the expression element is empty.

<sub:expression></sub:expression>

Delivering Events to an Endpoint Filtered by Event Type

The following XML snippet shows how to deliver an event of type AssetSubmission to an endpoint:

<sub:expression> eventdata_name ="urn:com:bea.aler:events:type:AssetSubmission"</sub:expression>

You can also use the "OR" operator to filter more than one event type:

eventdata_name ="urn:com:bea.aler:events:type:AssetSubmission" OR
eventdata_name ="urn:com:bea.aler:events:type:AssetAccepted"

These are the event types that are supported:

Delivering Events to an Endpoint Filtered Using a JMS Message Selector

Selectors are a way of attaching a filter to a subscription to perform content-based routing. Selectors are defined using SQL 92 syntax. The following is a complete list of fields that can be used to write a filter expression to filter the events. These fields are added to the JMS message as properties by the Event Manager and a JMS Message Selector that accesses the fields can be written to filter the events. 

submittedby_emailaddress = mrsmith@bea.com
asset_description = Test Asset
submittedby_name = aler_workflow_user
submittedby_id = 99
asset_community = Java
eventdata_description = new aler event
eventsource_componentname = Aqualogic ALER
asset_name = TestAsset
eventsource_componenttype = ALER3.0
asset_typeid = 154
eventdata_eventid = d0cdac55-c78f-4a29-8aec-6ea9ba8d31f1
eventdata_name = urn:com:bea:aler:events:type:MetaDataChange:name
asset_activestatus = ACTIVE
eventsource_location = ALERCore
asset_id = 50100
eventdata_version = ver1.0
asset_version = 1

For more information about JMS Message Selectors, refer to the following web sites:

JMS Message Selector Examples

Here are some sample usages of JMS message selectors:

Tip: Symbols, such as "< >" used for less than/greater than, are not valid XML content. This is because the expression is written in an XML file and parsed by the Event Manager, the XML unfriendly characters need to be mangled using the XML Rules. For example, you must use "id &gt; 500", which is equivalent to "asset_id > 500".

 

Configuring Logging of Event Manager Events

The Event Manager uses the same logging framework as ALER. By default, logging is enabled to go to a file, but you direct the debug statements to go to the console by appending the following categories to the log4fl.properties file in the <ALER Domain>\WEB-INF\classes directory. 

# eventing subsystem
log4j.category.com.bea.infra.event.core= debug,eventingLog,stdout
log4j.category.com.bea.infra.event.dm= debug,eventingLog,stdout
log4j.category.com.bea.infra.event.facade= debug,eventingLog,stdout
log4j.category.com.bea.infra.event.notifier= debug,eventingLog,stdout
log4j.category.com.bea.infra.event.store= debug,eventingLog,stdout
log4j.category.com.bea.infra.event.sub= debug,eventingLog,stdout

  Back to Top       Previous  Next