After configuring an event processor (EP), it must be enabled before it can run on schedule or be invoked manually. EPs run in optimistic mode, meaning that save-points will not be created, thus decreasing execution time and increasing performance.
The status of an EP is very important. This section addresses the different EP status options and how to enable, invoke, or disable an EP.
Event Processor Status Options
An event processor (EP) can be in one of these statuses: Stopped, Running, Failed (retrying), and Failed. Each EP status is described in the table below.
| Icon | Enabled | Processor Status | Description |
|---|---|---|---|
|
|
No | Stopped | The EP has not yet been enabled or has been disabled by a user. |
|
|
Yes | Running | The EP is running. |
|
|
Yes | Failed (retrying) | The EP is running and is attempting to recover from a connection or concurrency error. The background process (BGP) for an EP in this state is in a Waiting state when the wait time begins before the next attempt to retry processing. When the wait time expires, the BGP state changes to running and processing is reattempted. For more information, refer to the Fail and Retry Exception section below. |
|
Yes | Failed | The EP has stopped because of a failure. |
In the following example, a list of EPs is displayed within the Workbench on System Setup in the Event Processors Root node. Using the EP status icons makes it easy to decipher the status of each of the EPs.
The EP status information is also displayed in text on the Event Processor tab of the editor. For more information refer to the EP - Event Processor Tab documentation here.
When configuring and managing EPs, it is important to monitor their status, because an EP only functions when it is enabled.
Enable Event Processor
When an EP is created, it is in a stopped or disabled status, and must be enabled to be used. The steps below describe how to enable an EP when it has been disabled or stopped because of failure.
-
Go to System Setup, expand the Setup Group created for event processors, and select the Event Processor you want to enable.
-
Right-click the EP and click Enable Event Processor.
-
Confirm the EP is now enabled by viewing the:
-
Enabled icon
next to the specific EP. -
Enabled parameter is set to 'Yes' within the EP editor.
-
Processor Status parameter is set to 'Running', and highlighted green within the EP editor.
-
Important: If you are ready for the processor to apply the actions based on the event triggers, ensure the Queue Status parameter is also set to Read Events, otherwise the enabled EP will not queue events. For more information refer to the Queue Status section of the EP - Event Processor Tab topic here.
Invoke Event Processor
An EP can only be invoked if its status is Enabled. The steps to invoke an EP are below.
-
On the System Setup tab, select the EP to be invoked.
-
Right-click to display and select the Invoke Event Processor option.
-
If successful, the Current Background Process Log will display the following 'Poll invoked by [user name] (Date and Time Stamp)'.
Disable Event Processor
If an EP is no longer necessary or needs to be stopped, a user can disable it, and if necessary, enable it later. The option to disable an EP is only available when an EP is in the enabled status. If the EP is no longer necessary, the Queue Status should also be set to Discard Events to prevent excessive events that can affect system performance.
The steps below describe how to disable an EP in an enabled status.
-
Go to System Setup, expand the Setup Group created for Event processors, and select the Event Processor you want to enable.
-
Right-click the EP and click Disable Event Processor.
-
Confirm the EP is now disabled by viewing the:
-
Disabled icon
next to the specific EP. -
Enabled parameter within the EP editor is set to 'No.'
-
Processor Status parameter within the EP editor is set to 'Stopped,' and highlighted yellow.
-
Generating Events from Main
By default, an approval action triggers an event for workspace revisable objects, meaning that saving an edit (but not approving it) from the Main workspace does not generate an event.
For a limited set of event processors, you can set the triggering workspace to include Main, as defined in each EP type topic linked from the Processing Plugins topic in the System Setup documentation here.
Derived event functionality is available for triggering events prior to approval, as defined in the Derived Event topic of the System Setup documentation here.
Fail and Retry Exception
The EP has a built-in retry logic when getting the FailAndRetryException. It enters the 'Failed (retrying)' state and retries sing a function that increases wait times between retries and will retry for a default of 30 days (maximum) before failing. If a shorter duration is more suitable for your use case, the Retry Duration of 30 days can be changed on the 'Error Handling and Reporting' step of the Event Processor Wizard (here). When the operation eventually succeeds and the entire batch has completed, the EP returns to its normal ‘Running’ state.
Business actions used in an EP can have exception handling for certain connectivity exceptions and throw the FailAndRetryException to use the retry logic. This allows the EP to self-recover when the problem is solved. The following is an example of this exception handling using a bind to an existing Gateway Integration Endpoint:
var request = gateway.post().path('/service/v1').urlEncodedBody(body);
try {
var response = request.invoke();
} catch (e) {
if (e.javaException instanceof com.stibo.gateway.rest.exception.RESTGatewayStatusCodeWithBodyException) {
var statusCode = e.javaException.getHttpStatusCode();
if (statusCode >= 502 && statusCode <= 504) {
throw new com.stibo.core.domain.integration.faulttolerance.FailAndRetryException("Response status " + statusCode + " (will retry failed operation after some time): " + e.javaException.toString(), e.javaException);
}
} else if (e.javaException instanceof com.stibo.gateway.rest.RESTGatewayIOException) {
throw new com.stibo.core.domain.integration.faulttolerance.FailAndRetryException("Connection issue (will retry failed operation after some time): " + e.javaException.toString(), e.javaException);
}
throw(e); // All other exceptions MUST be re-thrown
} The EP will stop and go to the 'Failed' state when getting any other exception including the EventProcessorInterruptedException.
For more information on the FailAndRetryException and the EventProcessorInterruptedException, refer to the Javadoc in the Scripting API section of the Technical Documentation.