Designer 10.7 | webMethods Service Development Help | Subscribing to Events | Subscribing to Events | Creating Event Filters
 
Creating Event Filters
Event filters allow you to be very selective about the events to which you subscribe. Event filters limit the events for an event type that invoke an event handler. By using event filters, you can subscribe an event handler to only those events generated by a particular service, package, user, or port. For example, you might want an event handler to be invoked only when a specific service generates an audit event. Or, you might want an event handler to be invoked only when a specific user logs on to the Integration Server.
The following table identifies the information that you can filter on for each event type. Notice that you cannot create a filter for some event types. For these event types, every generated event invokes the event handlers subscribed to it.
Important:
The asterisk (*) is the only wildcard character allowed in an event filter. All other characters in the pattern string are treated as literals. Pattern strings are case sensitive.
For this event type...
You create a filter for...
Alarm Event
The message generated by the alarm event. Create a filter that specifies some of the text of the message. The event handler with this filter will process all alarm events containing the specified text.
The following filter specifies that any alarm events that generate a message containing the word “port” will invoke the event handler:
*port*
Audit Event
The fully qualified name of the service that generates the audit event. Create a filter to specify the services whose audit events you want to invoke the event handler.
The following filter specifies that the service sgxorders.Authorization:creditAuth will invoke the event handler:
sgxorders.Authorization:creditAuth
Audit Error Event
The concatenated value of the destination and errorCode fields of the audit error event. If the audit error event value matches the filter, the event will be passed to the event handler. You can use the asterisk (*) as a wildcard character in the filter.
You can use filters to limit the events that your event handler will receive as follows:
*If you set the filter to YourSearchTerm, the event handler will receive events whose values contain only YourSearchTerm.
*If you set the filter to YourSearchTerm*, the event handler will receive events whose values begin with YourSearchTerm.
*If you set the filter to *YourSearchTerm, the event handler will receive events whose values end with YourSearchTerm.
*If you set the filter to *YourSearchTerm*, the event handler will receive events whose values contain YourSearchTerm anywhere in the value.
Error Event
The error message text. The following filter specifies that any error event with a message that contains the word "missing" will invoke the event handler.
*missing*
Exception Event
The fully qualified name of the service that generates the exception event. Create a filter to specify the services whose exception events you want to invoke the event handler.
The following filter specifies that all services that start with the word “credit” and belong to any folder will invoke the event handler:
*:credit*
GD End Event
N/A
The filter for all GD End events is the following:
*
GD Start Event
The fully qualified name of the service that is being invoked using guaranteed delivery. Create a filter to specify the services that, when invoked using guaranteed delivery, will invoke the event handler.
The following pattern string specifies that all services that start with the word “sendPO” and belong to any folder will invoke the event handler:
*:sendPO*
JMS Delivery Failure Event
The name of the JMS connection alias used to send the message to the JMS provider.
The following filter specifies that a JMS delivery failure event involving a JMS connection alias with “XA” in the JMS connection alias name will invoke the event handler:
*XA*
JMS Retrieval Failure Event
The fully qualified name of the JMS trigger that called the trigger service for which the error occurred.
The following filter specifies that a JMS retrieval failure event involving a JMS trigger named “ordering:processTransaction” will invoke the event handler:
*ordering:processTransaction*
Journal Event
The major code and minor code of the generated event. The format of the filter is <majorCode>.<minorCode>. For example, the following filter specifies that any journal event with major code of 28 followed by a minor code of 34 will invoke the event handler:
*28.34*
Port Status Event
N/A
The filter for all port status events is the following:
*
Replication Event
The name of the package being replicated. Create a filter to specify the packages that, when replicated, will invoke the event handler.
The following filter specifies that a replication event involving the package named “AcmePartnerPkg” will invoke the event handler:
AcmePartnerPkg
Security Event
N/A
The filter for all security events is the following:
*
Session End Event
N/A
The filter for all session end events is the following:
*
Session Expire Event
N/A
The filter for all session expire events is the following:
*
Session Start Event
The user name for the user starting the session on the Integration Server or the groups to which the user belongs. Create a filter to specify which users or which user groups invoke an event handler when they start a session on the server.
The following filter specifies that a session start event generated by a user in the “Administrators” group will invoke the event handler.
*Administrators*
Stat Event
N/A
The filter for all stat events is the following:
*
Tx End Event
N/A
The filter for all Tx End events is the following:
*
Tx Start Event
N/A
The filter for all Tx Start events is the following:
*