Working with Event Processing Details

This topic describes how to use the options on the Event Processing Details dialog box in the Business Rules Framework.

To access the Event Processing Details dialog box:

Open an event in the Business Rules Framework.
Click the Event Processing Details link.

Selecting the Run Type

Application-triggered business rules can run either synchronously or asynchronously. How a business rule runs is determined by the Run Type value set for an event on the Event Processing Details dialog box.

You can improve the performance of data-intensive and longer-running event processes by offloading them to be run through Enterprise Scheduler Service (ESS) to run asynchronously. With ESS handling the Business Rules Framework processing, the application transaction sending the request to the Business Rules Framework can continue with its typical process flow without waiting for the processing to be completed by the Business Rules Framework. This can reduce the lag time for agency users and end users as they aren't waiting for the system response.

The following table describes the behavior of the event run types.

Run Type	Behavior
Synchronous Note: Synchronous is the default run type.	Application calls Business Rules Framework. Business Rules Framework assumes control of the processing thread. Business Rules Framework: Evaluates the criteria. Performs actions. Returns a response to the calling application. Business Rules Framework returns processing thread control to the calling application.
ESS Immediate (asynchronous)	Application calls Business Rules Framework. Business Rules Framework schedules an ad hoc job through ESS. Business Rules Framework returns a response indicating the request was received. Calling application continues its typical flow without waiting for the event rule to finish processing. ESS processes the event and associated rules. Note: Any elements that are a result of the rule processed through ESS, such as fees, conditions, and so on, may be delayed in appearing in the system until the ESS process has finished.

Run Type

Behavior

Synchronous

Note:

Synchronous is the default run type.

Application calls Business Rules Framework.
Business Rules Framework assumes control of the processing thread.
Business Rules Framework:
1. Evaluates the criteria.
2. Performs actions.
3. Returns a response to the calling application.
Business Rules Framework returns processing thread control to the calling application.

ESS Immediate (asynchronous)

Application calls Business Rules Framework.
Business Rules Framework schedules an ad hoc job through ESS.
Business Rules Framework returns a response indicating the request was received.
Calling application continues its typical flow without waiting for the event rule to finish processing.
ESS processes the event and associated rules.

Note:
Any elements that are a result of the rule processed through ESS, such as fees, conditions, and so on, may be delayed in appearing in the system until the ESS process has finished.

These event types don't support ESS immediate (asynchronous) processing:

Pre-save and pre-submit events, such as Before Permit Inspection Saved, Before Permit Application Submitted, Before Business License Inspection Saved, and so on. Typically, these events are configured to trigger a Stop Process action.
Scheduled rule events.

Note:

For the events where ESS immediate isn't supported, the Run Type drop-down list is disabled, showing only Synchronous as the run type.

While an ESS immediate (asynchronous) event is processing, the log file will display a status of "unprocessed" and indicate that ESS will run the job soon. When the job completes the log file will display the typical results of success, fail, and so on.

Identifying Events for Asynchronous Processing

While every agency processes different data and has unique processing requirements, some events can be identified as candidates for asynchronous processing.

Depending on your processing requirements, you can review the timing information in the logs and identify the longer-running events, such as those taking more than 5 seconds to complete, for example. Then you can test those events with ESS immediate selected to see if it improves the user experience.

For example, in a sample environment, these events were identified as candidates for offloading to asynchronous processing.

Permit Contact Added to Application (LNP-CONTACT-ADD-TO-APP)
Permit Application Updated (LNP-PERMIT-UPDATE)
After Permit Application Submitted (LNP-AFTER-SUBMIT)
Permit Inspection Scheduled (LNP-INSPSCH-001)
After Business License Application Submitted (LIC-AFTER-SUBMIT)

Enabling an Event

Whether you have a business rule defined for a business rule event or not, if the event is enabled, when the conditions arise for that business rule event to run, it will run. By default, all business rule events are enabled. You can choose to disable an event if you know you aren't using it and you want to reduce any possible overhead associated with that event running.

Note:

In general, it's not recommended to disable an event. It's recommended to disable any rules associated with an event that you don’t want to run, rather than disable the event itself. In some situations, however, implementation teams may need to use this option in during development, testing, or when troubleshooting.

Note:

Before disabling, confirm the event isn't needed to generate rule-based communications. If an event has a default rule associated with a communication event, disabling the Business Rule Framework event will prevent the communication from being generated by that event.