Configuration
Contents
Use Event Log Filtering
You can configure which events will be stored in the Interaction Server Event Log database. Doing so can reduce the number of rows in that database for active tasks (tasks that have not yet expired and therefore, have not been purged by the iWD ETL Prune job). The events that are necessary for iWD Data Mart and the task's Event History to work properly are shown in the table called Interaction Server Events Required for Proper Functioning of iWD.
|
Event identifier |
Event name |
|---|---|
|
104 |
EventPropertiesChanged |
|
132 |
EventPartyAdded |
|
133 |
EventPartyRemoved |
|
161 |
EventProcessingStopped |
|
162 |
EventPlacedInQueue |
|
163 |
EventPlacedInWorkbin |
|
193 |
EventExternalServiceRequested |
|
194 |
EventExternalServiceResponded |
|
200 |
EventHeld |
|
201 |
EventResume |
You can filter out all other events by configuring the Interaction Server Event Log Database Access Point application option event-filter-by-id. This option is configured in the event-filtering section. The value of the event-filter-by-id option will be a comma-separated list of the events you want to be logged. All other events will not be logged.
The list of events shown in the table above is appropriate if you are using the out-of-the-box iWD business process (IWDBP). The best way to analyze this is to turn off the event-filter-by-id option temporarily and to put one task through the entire business process, including reprioritization, handling at an end-user desktop, any re-queuing, and so on. Then, you can review the full list of events that have been captured by doing a query on the Event Log Database table, for a particular Interaction ID. If you do not require any custom reporting and have no need for the events other than those listed in the table above, you can apply the filter, as described.
Align Business Structure and Business Requirements
In some businesses, the way you define Departments and Processes in iWD will directly align with how the business views distribution and reporting. In other cases, consider aligning Departments and Processes with your reporting requirements and use Genesys skills to align with distribution. This is the recommended approach because the Departments and Processes can then be used as input in the Data Mart plug-ins—that is, the pre-defined attributes of Department and Process can be used to support the reporting metrics and dimensions. This makes it easier to provide statistics from a business point of view.
Consider Using Multiple iWD Tenants
Consider configuring more than one iWD managed tenant, where each tenant aligns to a different business unit. This allows you to configure dedicated custom attributes in iWD Data Mart for each business unit. It also reduces the amount of data iWD Data Mart has to process from the Interaction Server Event Log database. This means you will need to set up multiple iWD Data Mart instances, but this configuration is more scalable.
Load Balance BCMS and GRE in High Volume Deployments
If your iWD solution has particularly high volumes or uses frequent reprioritization, it might be useful to set up multiple Business Context Management Services (BCMS) and multiple Genesys Rules Engines (GRE) in a load-balanced configuration. Consider updating the out-of-the-box IWDBP business process to add a subroutine that can handle BCMS load balancing and retries, with multiple runtime nodes within the solution. You can make the number of retry attempts configurable as a strategy variable or within a List Object so the value can be modified without changing the strategy itself.
Multiple Application Server Instances
It might be beneficial to set up the iWD Manager, iWD Runtime Node, and iWD Data Mart web applications on dedicated application server instances. In fact, Genesys recommends that you always use a dedicated application server instance for iWD Data Mart. However, having the other applications on dedicated instances can also improve scalability and availability.