Temenos Lifecycle Management Suite - Recovery Product Guide
Event Processing
| Administrator Guide > Event Processing |
Event Processing provides an institution the ability to pair predefined events with corresponding actions. An event is a predefined occurrence within the Lifecycle Management Suite. When paired with an action, the event triggers the completion of the action. An action is a dependent business operation that only executes if an event is met. When a defined event occurs, the corresponding action automatically fires, or is queued until the configured time-delay expires.
For example, an institution can configure an event pair that executes rules action to set the value of Metro 2 credit reporting fields when the charge off process completes.
The Event Processing page in System Management (System Management > Collections > Event Processing) enables administrators to maintain and customize event processes for their institution. This page displays a list of all system-defined and custom event/action pairings configured in the Lifecycle Management Suite, and provides administrators with the functionality to configure event processes to meet their institution's business needs.
This page is organized into the following two tabs:
The Event Processing topic includes the following information to assist administrators with creating and managing event/action pairs:
The Event Processing tab displays a list of all event/action pairings configured in the Lifecycle Management Suite, and provides administrators with the functionality to create and maintain the event processes available at their institution.
The grid within this tab displays the following columns of information for each even/action pair:
| Column | Description | ||||
| Name | Displays the name of the event/action pair. | ||||
| Events | Displays the event(s) configured to initiate the process. | ||||
| Actions | Displays the action(s) to be performed during the event(s). | ||||
| Active |
Displays a |
||||
| Delayed |
Displays a
|
||||
| System |
Displays a
|
||||
| Last Modified | Displays the date of the most recent modification to the event pair. | ||||
| Modified By | Displays the name of the user who made the last modification. | ||||
| Date Created | Displays the date and time the event pair was created. | ||||
| Created By | Displays the name of the user who created the event pair. |
Each event/action pair contains attributes that are organized into a series of tabs. The defined attributes determine the functionality of each pair.
The General tab allows administrators to define basic information for the event/action pair, as well as set any time delay configurations for the event process.
The following fields are available within the top section of the General tab:
| Field | Description |
| Name | Enter a name for the event/action pair. |
| Description | Enter a description for the event/action pair. |
| Active | Select the check box to enable the event/action pair in the Lifecycle Management Suite. |
The Delay Settings section enables administrators to set the event/action pair on a time-delay. When set on a time delay, the assigned actions are not immediately performed when the event occurs, but execute according to the delay type and duration set for the pairing. This section includes the following fields:
 |
This section is disabled for system-defined event/action pairs. |
| Field | Description | ||||
| Delay Action(s) |
Select the check box to enable a time delay for the event/action pair. By default, this field is disabled.
|
||||
| Delay Type |
Select one of the following options to identify the amount of time the pair is to be delayed:
|
||||
| Duration |
Enter a whole number to identify the duration of the delay type. For example, if configuring an event/action pair to include a time delay of three days, select a Delay Type of Days and enter a value of 3 for the Duration.
|
|
For more information on time delay settings, please see the Time Delay Process section in this topic. |
The Events tab provides administrators with the ability to identify the event(s) that must occur in order for the defined actions(s) to execute.
A toolbar appears at the top of the tab to enable administrators to perform the following actions:
|
The following buttons are disabled within the Events tab for system-defined event/action pairs. |
| Button | Description | ||
 |
Enables the ability to add an event to the Event Processing pair. When clicked, a window appears to allow administrators to select the Event Type to be added. | ||
 |
Enables the ability to edit an event assigned to the Event Processing pair. This button is only enabled for those events that require additional information, such as Field Changed.
|
||
 |
Enables the ability to remove an event from the Event Processing pair. |
When an event type is added, the following information populates in the grid:
| Field | Description | ||
| Event | Displays the name of the event. | ||
| Synchronous |
Displays a
|
 |
More than one event may be added to an event/ action pairing. If more than one event is added, the event pairing is treated as an “Or Statement” meaning that if either event occurs, the action triggers. |
Reference the Events table below for an overview of the system-defined event types available in the Recovery module:
|
Additional events may be available within the Select Event Type window when certain third party connectors are active at the institution. For information on the events that are available for a connector, please see the applicable Connector Guide. |
| Event Type | Description | Synchronous | ||
| Case Created | Is raised whenever a new case is created. | |||
| Collection Added |
Is raised whenever a collection is added.
|
|||
| Collection Removed |
Is raised whenever a collection member is removed.
|
|||
| Custom Event |
Is raised at a time determined by a custom event code.
|
|
||
| Field Changed |
Is raised whenever a field changes.
|
|||
| Post Charge Off |
Is raised when the charge off process completes at the end of the Charge Off Account workflow step.
|
X |
||
| Pre Charge Off |
Is raised at the beginning of the Recommend Account for Charge Off workflow step.
|
X |
While most events are straightforward, events such as Collection Added, Collection Removed, and Field Changed require additional input.
Collection Added or Collection Removed
A Collection is a group of like entities such as Cases.
|
Only Case level fields are available to be assigned to the Collection Added or Collection Removed event type. |
When the Collection Added or Collection Removed event is selected, the Select Collections window appears to assign the desired collection(s) to the event. This window displays a list of all collections that are available in the Lifecycle Management Suite’s Recovery module.
|
Multiple collection types may be added to an event; however, the event name is only displayed as Collection Added or Collection Removed in the Events tab. It is recommended that the Name and/or Description entered for the pairing in the General tab identifies the collection(s) that are being used for the event. |
When the Field Changed event is selected, the Select Fields window opened to assign the desired fields to the event. This window displays a list of all fields in the Lifecycle Management Suite’s Recovery module.
|
Only Case level fields are available to be assigned to the Field Changed event type. |
|
Multiple fields may be added to an event; however, the Event is displayed as Field Changed. It is recommended that the pairing’s Name and/or Description indicates the field(s) that are being used in this pairing. |
 |
In the Audit History screen, Field Changed events do appear as auditable actions under the Add a New Application item, but this information does not reflect updates made per the triggering of an event/action pairing. While these events do occur as part of the application initialization process, the Field Changed events configured in Event Processing are only triggered AFTER an application is already created. |
The Actions tab provides administrators with the ability to assign the action(s) to occur as a result of the defined event(s). When an event occurs, the action assigned within tab automatically fires or is queued until the configured time-delay expires.
A toolbar appears at the top of the tab to enable administrators to perform the following actions:
|
The following buttons are disabled within the Actions tab for system-defined event/action pairs. |
| Button | Description | ||
|
Enables the ability to add an action to the Event Processing pair. When clicked, a window appears to allow administrators to select the Action Type to be added. | ||
|
Enables the ability to edit an action assigned to the Event Processing pair. This button is only enabled for those actions that require additional information, such as Execute Rules and Execute Code.
|
||
|
Enables the ability to remove an action from the Event Processing pair. |
When an action type is added, the name of the action populates within the grid.
|
More than one action may be added to an event/action pair. If action priority is a concern, it is recommended to pair multiple actions to an event as opposed to creating two separate event pairings. When more than one action is added, the pairing is treated as an “And Statement,” and are triggered simultaneously. If an event occurs, all actions trigger. If multiple events and multiple actions are paired, all actions trigger when one event occurs. If actions are not contained in the same Event pair, the actions may not fire in the intended order. Pairing Actions within one Event ensures that priority is handled as intended, as long as Actions are ordered properly within the Event. |
Reference the table below for an overview of the system-defined action types available in the Recovery module:
|
Additional actions may be available within the Select Action Type window when certain third party connectors are active at the institution. For information on the events that are available for a connector, please see the applicable Connector Guide. |
| Actions | Description |
| Execute Code | Execute system-defined or custom code to perform certain actions. |
| Execute Rules | Executes the configured rules that are assigned to the action. |
While most actions are straightforward, actions such as Execute Code and Execute Rules require additional input.
|
The Execute Code action is for development purposes only. |
When the Execute Code action type is selected, the Edit Action – Execute Code window appears to enter the class name and assembly path required to assign the custom code to execute for the action.
When the Execute Rules action type is selected, the Edit Action – Execute Rules window appears to assign the Event Processing rules that execute for the action.
|
Only rules written in the Event Processing category in Rules Management are able to be assigned to the Execute Rules action type. |
The Rules tab allows the administrator to set qualifiers for the Event Processing pair. Rules can be assigned to each event/ action pair to add clarification and control over the application of actions. These rules can be created under the “Event Processing” category in Rules Management to indicate if the action(s) should be executed.
This tab includes the following attributes to assign Events Processing rules to an event/action pair:
|
The arrows are disabled within the Rules tab for system-defined event/action pairs. |
| Attribute | Description | ||
| Available |
Displays a list of all Event Processing rules configured in System Management > Collection > Rules Management. Assign rules by selecting the desired rule(s) from the list and moving them to the Assigned box.
|
||
| Assigned | Displays a list of all the rules that have been assigned to the event pair. Once the event fires, the assigned rules are executed. |
The Create function allows administrators to define and structure a new event/action pair.
To create a new pairing:
.To add an event:
- Click
- The Select Event Type window appears. Click the
to display the available Event Types, and select the desired event from the drop-down list.
For an overview of each system-defined event type, please see the Events section in this topic.
- Once the desired event has been selected, click
to close the Select Event Type window and assign the event to the Event Processing pair.
- If the event requires additional configuration, a window appears upon clicking
to present the options available to assign to the event. For example, the Collection Added event requires a Collection to be identified; therefore, a Select Collection window appears when the event is added to allow a field collection to be assigned to the event. Once the desired option is assigned to the event, click
within the Select window to return to the Events tab.
For more information on the events that require additional configurations, please see the Events section in this topic.
- Upon clicking
The
- Collection Added
- Collection Removed
- Custom Event
- Field Changed
To modify an event that allows editing:
- Double-click the desired event within the Events tab or highlight the event and click
- Within the window that appears, make the necessary modifications.
- Click
To delete an event:
- Highlight the desired event within the Events tab and click
- The event is removed from the Events tab.
To add an action:
- Click
- The Select Action Type window appears. Click the
For an overview of each system-defined action type, please see the Actions section in this topic.
- Once the desired action has been selected, click
- Similar to events, if the action requires additional configuration, a window appears upon clicking
For more information on the actions that require additional configurations, please see the Actions section in this topic.
- Upon clicking
If more than one action is added, the order the actions are executed can be rearranged by clicking the action and dragging it to the desired location in the grid.
The
- Execute Code
- Execute Rules
To modify an action that allows editing:
- Double-click the desired action within the Actions tab or highlight the action and click
- Within the window that appears, make the necessary modifications.
- Click
To delete an action:
- Highlight the desired action within the Actions tab and click
- The action is removed from the Actions tab.
to create the event/action pair. The pairing is added to the grid in the Event Processing tab.
|
Synchronous events cannot be set on a time delay; therefore, an error message is received upon clicking |
The Edit function enables administrators to modify an existing event/action pair.
|
When editing an event/action pair that is set on a time delay, any modifications made to the General, Events, and Rules tabs are applied to future executions of the pair. Modifications made to the Actions tab effect both queued actions and future executions of the pair. For more information, please see the Time Delay Process section in this topic. |
To edit an event pair:
. to retain the updated settings and return to the Event Processing page.The Delete function enables administrators to remove custom event/action pairs from the Lifecycle Management Suite.
|
System-defined event/action pairs cannot be deleted; therefore, the  button is disabled within the Event Processing tab when a system-defined pair is selected in the grid. |
. |
If the event/action pair has been set on a time delay, a message appears to inform that the pair is configured for delayed actions, and confirm that the pair should be deleted from Event Processing.
|
The Delayed Actions Report tab provides a detailed overview of each delayed event/action pair that has executed in the Lifecycle Management Suite.
|
Please see the Time Delay Process section in this topic for a complete overview of this functionality. |
This tab displays a read-only grid that can be used to view information about each delayed pairing, such as the status and the execution date and time.
|
When more than one event is configured for a pairing, and the events are not triggered simultaneously, a record for each instance of the event process is added to the Delayed Actions Report. When the events occur simultaneously, the items are de-duped and only one record of the event process appears in the Delayed Actions grid. For example, if the Application Approved and Field Changed (Application.StatusId) events are assigned to a delayed pairing, only one record is added to the Delayed Actions grid since the events occur at the same time during the application process. |
Within this tab, administrators can quickly and easily access the following information for each delayed event/action pair executed in the Lifecycle Management Suite:
| Column | Description | ||||||||
| Type | Displays the object type on which the event process was run, such as Account,or Person. | ||||||||
| ID |
Displays the ID of the object on which the event process was run, such as the Account Number. Reference the table below for an overview of the value that is displayed for each object type:
|
||||||||
| Event/action pair name | Displays the name of the event/action pair. | ||||||||
| Execution date/time | Displays the date and time that the delayed action is set to execute. | ||||||||
| Event/action pair status |
Displays the status of the event/action pair. One of the following values populates within this column to identify the status of the delayed actions:
|
By default, the Delayed Actions Report displays information for all delayed event/action pairs that have executed over the past 30 days; however, the toolbar in the top of the tab provides the following options to filter the data that appears within the grid:
| Filter Option | Description | ||
 |
Enables the ability to filter by Event/Action Pair Status. By default, the View drop-down is set to All to display information for all event/action pairs regardless of status. To filter by status, click the drop-down arrow and select one of the following statuses:
|
||
 |
Enables the ability to display information for a specific time period. By default, this tab displays status information for a time period of 30 days from the current date. To modify the date range, perform one of the following actions:
|
||
 |
Enables the ability to refresh the information that appears in the screen.
|
The time delay functionality provides administrators with the ability to post-pone the execution of actions for an event process by determining the number of days, hours, minutes, or seconds that must pass before the actions assigned to the event/action pair are executed.
|
Delayed pairings may execute while a user has an account or person in context in the workspace; therefore, it is recommended that this functionality is used as a method of communication, rather than to alter account or person data. |
For example, when a vehicle is repossessed, the owner has a specific number of days to reclaim the vehicle. This functionality can be used to move the account to the Ready for Auction Queue 15 days after the value of the Date Repossessed field is modified.
When an event for a delayed pairing occurs in the Lifecycle Management Suite, the assigned actions are queued in the database until the delay settings configured within the General tab expire.
|
To learn more about the Delay Settings for a pairing, please see the General section under Event Processing in this topic. |
Upon execution of the event, a record of the pairing is added to the Delayed Actions Report tab with a status of Pending. When the delay settings for the pairing expire, the actions are executed in the Lifecycle Management Suite. If all actions execute successfully, the status of the pairing is updated to Completed.
|
If one or more of the actions assigned to a delayed event/action pair fail, the status for the pair is set to Failed. For assistance identifying the specific action that failed to execute, please contact a Temenos Customer Care or Professional Services Representative. |
The EVENTS_QUEUE_CLEANUP process allows institutions to determine the number of months that history for each delayed event/action pair is maintained in the database. When active, this process runs each night to review the records in the database for each event/action pair, and remove any records that exceed the number of months set for the EVENTS_QUEUE_DURATION parameter.
|
The EVENTS_QUEUE_CLEANUP process is not automatically activated for each institution. If this process is not enabled, records for each delayed event/action pair remain in the database indefinitely. Please contact a Temenos Customer Care or Professional Services Representative for assistance with enabling the EVENTS_QUEUE_CLEANUP process. |
By default, history for each delayed event/action pair is stored in the database for a time period of six months when the EVENTS_QUEUE_CLEANUP process is enabled; however, this value can be changed with the assistance of a Temenos Customer Care or Professional Services Representative.
When an event/action pair is set on a time delay, modifications made to certain attributes are applied to future executions of the pairing, but may also update any queued actions as well. Reference the table below for an overview of the behavior that occurs when specific attributes are updated for a delayed event/action pair:
| Attribute | Effect on Behavior of Event/Action Pair | ||
| General |
Modifications made to any of the General attributes only apply to future executions of the event/action pair. For example, it the duration of the time delay is updated from one day to two days, any queued actions are still performed after the one day expires, but all actions that are queued after the modification are not executed until two days have passed.
|
||
| Events | Modifications made to the assigned events are only applied to future executions of the event/action pair. | ||
| Actions | Modifications made to the assigned actions are applied to future executions of the event/action pair, as well as all queued actions for the pairing that are in a Pending status. For example, if a rule is added to the Execute Rules action, all of the queued Execute Rule actions for the pairing are updated to execute the new rule when the action is performed. | ||
| Rules | Modifications made to any of the Rule attributes are only applied to future executions of the event/action pair. |
|
This section is intended for an institution's IT department. |
In order for the time delay functionality to occur in the Lifecycle Management Suite, the following services must be enabled for the financial institution:
The LMS.Core.Process windows service enables the ability to use the time delay functionality in the Lifecycle Management Suite by listening for responses from the Service Broker queue, and, when a response comes in, calling the service that executes the delayed event/action pair. This windows service is automatically installed and enabled on the server for the Lifecycle Management Suite.
|
The LMS.Core.Process windows service can be load-balanced across multiple servers; however, if it is desired to run the service on multiple servers, the LMS.Core.Process windows service must be manually installed on each additional server. |
Service Broker is a SQL-based messaging system that sends a response to the LMS.Core.Process windows service when a delayed event/action pair executes in the Lifecycle Management Suite. This service is automatically enabled in the database for each institution; however, when a back-up and restore of the Lifecycle Management Suite database is performed, SQL Service Broker is automatically disabled in the new location. To reactivate Service Broker on the SQL server for the institution, the following script must be run:
|
The person running the following script must have ALTER permissions for the database. |
IF (SELECT is_broker_enabled FROM sys.databases WHERE name = DB_NAME()) = 0
BEGIN
DECLARE @BrokerGUID as UNIQUEIDENTIFIER = (SELECT service_broker_guid FROM sys.databases WHERE name = DB_NAME())
DECLARE @DBName NVARCHAR(50) = DB_NAME()
DECLARE @SetSingle NVARCHAR(100) = 'ALTER DATABASE [' + @DBName + '] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;'
DECLARE @SetMulti NVARCHAR(100) = 'ALTER DATABASE [' + @DBName + '] SET MULTI_USER;'
DECLARE @BrokerSQL NVARCHAR(200)
SET @BrokerSQL = 'ALTER DATABASE [' + @DBName + ']'
IF (SELECT COUNT(service_broker_guid) FROM sys.databases WHERE service_broker_guid = @BrokerGUID) > 1
BEGIN
--if db is a back up and restore the broker guid could match the original so we need to create a new broker
SELECT @BrokerSQL = @BrokerSQL +' SET NEW_BROKER'
END
ELSE
BEGIN
SELECT @BrokerSQL = @BrokerSQL +' SET ENABLE_BROKER'
END
--broker needs exclusive locks to create without setting to single could cause the broker creation to han
EXEC sp_executesql @SetSingle
EXEC sp_executesql @BrokerSQL
EXEC sp_executesql @SetMulti
END
to identify the pair as active in the Lifecycle Management Suite.
next to each box to select the desired date.