Jump to: navigation, search

Working with the IWD Business Process (IWDBP)

These topics describe how to work with and adapt the default iWD Business Process (IWDBP) that is supplied out-of-box with intelligent Workload Distribution.


Within this Business Process, from within a routing strategy, External Service Protocol (ESP) blocks are used to invoke methods of the Business Context Management Service (BCMS) and Genesys Rules Engine (GRE). This approach is used to apply classification and prioritization rules to the interaction. When a user goes to the Global Task List view in iWD Manager, to monitor the interactions that are in various states, this component communicates with Interaction Server to retrieve the list of interactions and their attributes.

This out-of-the-box Genesys iWD Business Process maps to the iWD state model, allowing you to use iWD-based reporting for other interaction types (for example, you might want to track Genesys emails along with other task types, under the same Department or Process).

This Genesys iWD Business Process is completely optional for iWD customers who are using Genesys E-mail, Genesys Chat, Genesys SMS, or even third-party email, SMS, or chat. If the Genesys iWD Business Process is not used, iWD Data Mart and iWD Global Task List functionality may be limited.

For Genesys eServices customers, the Genesys iWD Business Process can be left unchanged if you want to use business rules only. In this scenario, what would change would be the routing strategies. The strategies would use the BCMS and ESP block to invoke the Genesys Rules Engine. This means that existing Genesys E-mail, Chat or SMS/MMS customers can use the business rules within iWD without having to change their Genesys Business Processes; or, to access some additional functionality, changes can be made to the Business Processes.


Overview

These pages describe the default iWD business process (IWDBP) that is supplied in the iWD Setup Utility component.

Software Requirements

  • The IWD Business Process that is described in this appendix requires Interaction Routing Designer 8.1.2 or higher.

Other Information Resources

The Universal Routing 8.1 Interaction Routing Designer Help Zip describes how to create, save, import and export a business process, and how to load the strategies that comprise the business process.  

Important
When Interaction Routing Designer (IRD) starts up, it checks for an eServices solution installed by the eServices Configuration Wizard. If none is found, the IRD main window does not contain an Interaction Design shortcut bar. You cannot navigate to the Business Processes list pane or open the Interaction Design window. To change the default, use the Views tab in Routing Design Options, which opens from the Tools menu. Clear the default check box and click OK.

Configuration of List Objects

The iWD Business Process (IWDBP) uses two Configuration Server List Objects.

  • The first List Object, Iwd_Esp_List, has three lists.
    • The first is used to map the iWD Solution ID (IWD_SolutionId) to the name of the Business Context Management Service application configured in Configuration Server that will be used to invoke the Genesys Rules Engine.
    • The second maps the iWD Solution ID to the name of the Genesys Rules Engine application.
    • The third list (from release 8.1.1 onwards) maps the iWD Solution Runtime ID to the name of the Universal Contact Server (USCS) application. This is optional, and is used to allow the business logic in IWDBP to update the interaction record in the UCS database to mark the interaction as done (that is, the value of the Status column in the Interaction table will be set to 3) when it enters the iWD_Completed, iWD_Rejected, or iWD_Canceled queues.
  • The second List Object, Iwd_Package_List, maps the iWD Solution ID to the rules package that will be evaluated when the Genesys Rules Engine is invoked from the IWDBP business process.

Both of these List Objects must be correctly configured for IWDBP to work.

One business process can serve several solutions under the same tenant. The iWD Setup Utility automatically creates these two List Objects for the Solution you indicate in the Setup Utility. In environments with only one solution, no further configuration needs to be done on the List Objects. If you have multiple solutions (or add one at a later time) these two List Objects need to be updated.

Iwd_Esp_List

BCMSServiceList

In the Iwd_Esp_List List Object, the BCMSServiceList list looks like a list of pairs:

Solution_1

ESPService_1

Solution_2

ESPService_2

Solution_i

ESPService_i

Where the Solution ID is the key, and the name of the Business Context Management Service Application is the value.

GREServerList

The GREServerList list looks like a list of pairs:

Solution_1

GREApplication_1

Solution_2

GREApplication_2

Solution_3

GREApplication_3

Where the Solution ID is the key, and the name of the Genesys Rules Engine Application is the value.

ContactServerList

In release 8.1.1, an additional list, ContactServerList is included. The ContacServerList list looks like a list of pairs:

iWD Solution Runtime_1

ContactServer_1

iWD Solution Runtime_2

ContactServer_2

iWD Solution Runtime_3

ContactServer_3

Where iWD Solution Runtime ID is the key and the name of a Universal Contact Server associated with Interaction Server is the value.

Important
It is very important that the pairs are set up correctly. If, for example, Solution_1 is mapped to ESPService_2 instead of to ESPService_1, business rules for Solution_2 will be applied to all interactions which were submitted by Capture Points from Solution_1. Similar issues will occur if the Genesys Rules Engine application or the Universal Contact Server application are incorrectly mapped.

These key-value pairs in a List Object need to be set up only once per tenant, and can be configured in Interaction Routing Designer (IRD) or Genesys Administrator.


ListObjects IRD.png

List Objects in IRD


ListObjectsDetail.png

List Object Details


Iwd_Package_List

The Iwd_Package_List List Object is used to correlate the IWD Solution ID (IWD_SolutionId) to the name of the rule package that will be evaluated when requests are made to the Genesys Rules Engine from the IWDBP business process.

The Iwd_Package_List List Object contains a single list, RulePackageList. Create a new key/value pair for each iWD Solution that you have configured under your Configuration Server tenant, where the key or option is the IWD Solution ID and the value is the Package Name of the rules package.

  Iwd Package List.png

iWD Package List

Contents

iWD Business Process

The iWD business process (IWDBP) contains the following strategies:

  • Classification
  • Prioritization
  • Distribution
  • Mark Interaction as Done
  • Removal

The iWD business process contains the following subroutines:

  • DetermineESPServerName
  • DetermineRulePackageName

The iWD business process contains the following queues:

  • iWD_New
  • iWD_Captured
  • iWD_Queued
  • iWD_Canceled
  • iWD_Rejected
  • iWD_Completed
  • iWD_ErrorHeld

The Interaction Queues that are included in the out of the box IWDBP business process must be present, and the names should not be changed. The Global Task List looks for specific Interaction Queue names, as they appear in the business process (such as iWD_New and iWD_Queued ). If you modify the business process to add additional queues or rename existing queues, the interactions display in the Global Task List with the status Queued.


BPMain.PNG

IWDBP Main Process

The above screenshot shows the entire business process as it appears in the Interaction Design window of Interaction Routing Designer.

The group of objects on the left-hand side are part of the “Main Flow” of the business process. The group of objects on the right-hand side represent the “Archiving” section of the business process.

Classification Strategy

The purpose of this strategy is to invoke corresponding classification rules, analyze the result of the rules application and place the interaction into the appropriate queue, depending on the result.

This strategy processes interactions from the following queues:

  • iWD_New—Interactions have to satisfy the following conditions:
    • There are no conditions here.
    • Interactions are taken in order they were submitted.

Iwd dep-105.gif

Important
ESP stands for External Service Protocol. In this document it is the Business Context Management Service.


Classification Strategy—Section 1

ClassStrat1.jpg


  1. A variable is initialized: _delay_ms specifies the delay (in milliseconds) between attempts to invoke rules.
  2. A command is sent to URS to use interaction age while sorting interactions in internal queues.
  3. The DetermineESPServerName subroutine is invoked to determine the correct ESP server name to use. The subroutine uses the List Object list BCMSServerList. This subroutine also sets up cases when there is reason to retry to invoke the ESP server.
  4. The subroutine fails an error is extracted.
  5. This error is attached to user data as a key-value pair with the key IWD_BCMS_Determination_Error.
  6. If the subroutine was successful, a check is done to ensure the existence of the ESP server name that was returned by the subroutine. If the ESP server name was found, the flow goes to Step 22.
  7. If the ESP server name was not found, this error is attached to user data as a key-value pair with the key IWD_BCMS_Determination_Error.
  8. The interaction is placed in the iWD_ErrorHeld queue.
  9. The DetermineESPServerName subroutine is invoked to determine the correct ESP server name to use. The subroutine uses the List Object list called ContactServerList. This subroutine also sets up cases when there is reason to retry to invoke the ESP server.
  10. If the subroutine fails an error is extracted.
  11. This error is attached to user data as a key-value pair with the key IWD_UCS_Determination_Error.
  12. The interaction is placed in the iWD_ErrorHeld queue.
  13. If the subroutine was successful, a check is done to ensure the existence of the ESP server name that was returned by the subroutine. If the ESP server name was not found, the flow goes to Step 15.
  14. The value of the user data key IWD_isContactServer is set to 0 (zero). The flow continues to Step 22.
  15. The value of the user data key IWD_isContactServer is set to 1.
  16. URS checks to see if the value of the user data key 'IWD_isAddedToContactServer is equal to 1, indicating that the task is already written into the interaction history in the UCS database. If the check evaluates as true, the flow continues to See A request is made to the ESP server, to prepare the interaction data before the Genesys Rules Engine can be called to invoke the classification rules.
  17. A new interaction is created in the UCS database, for this iWD task. If that function is successful, flow goes to See The user data key IWD_isAddedToContactServer is updated to 1 to indicate that the task was successfully added to the interaction history in UCS. The result returned from the ESP call to UCS (from 17) is written to the variable IWD_UCS_Result.
  18. If the creation of the interaction in UCS was unsuccessful, an error is extracted from user data.
  19. This error is attached to user data as a key-value pair with the key IWD_UCS_Error.
  20. The interaction is placed in the iWD_ErrorHeld queue.
  21. The user data key IWD_isAddedToContactServer is updated to 1 to indicate that the task was successfully added to the interaction history in UCS. The result returned from the ESP call to UCS (from See A new interaction is created in the UCS database, for this iWD task. If that function is successful, flow goes to 21.) is written to the variable IWD_UCS_Result.    

    Classification Strategy—Section 2

    ClassStrat2.jpg

  22. A request is made to the ESP server, to prepare the interaction data before the Genesys Rules Engine can be called to invoke the classification rules.
  23. If the communication with the ESP server was successful, the ESP result is attached to user data as a key-value pair with the key IWD_BCMS_Result. If not, the flow goes to Step 30.
  24. The DetermineESPServerName subroutine is invoked to determine the name of the Genesys Rules Engine Application. The subroutine uses the List Object list GREServerList.
  25. If the subroutine fails an error is extracted.
  26. This error is attached to user data as a key-value pair with the key IWD_GRE_Determination_Error.
  27. If the subroutine was successful, a check is done to ensure the existence of the ESP server name that was returned by the subroutine. If the ESP server name was found, the flow goes to See The DetermineRulePackageName subroutine is invoked to determine the name of the rule package that the Genesys Rules Engine will be invoking to evaluate the classification rules.
  28. If the ESP server name was not found, this error is attached to user data as a key-value pair with the key IWD_GRE_Determination_Error.
  29. The interaction is placed in the iWD_ErrorHeld queue.
  30. The last Interaction Server-related error is extracted from a variable.
  31. A check is done to see if the error code is related to the ESP server communication.
  32. The last error is attached to user data as a key-value pair with the key IWD_BCMS_Error.
  33. A check is done to see if the error code is related to the iWD Department or Process not being available (for example, if the current date is outside of the Start and End Dates of the Department or Process).
  34. If the Department or Process is not active yet, the interaction is placed in the iWD_Rejected queue.
  35. The last error is attached to user data as a key-value pair with the key IWD_BCMS_Error.If not, the value of the _counter variable is incremented by 1.
  36. A delay is introduced, based on the value of the variable _delay_ms. The flow goes back to Step 22 to retry the connection to the ESP server.
  37. The interaction is placed in the iWD_ErrorHeld queue.
  38. The DetermineRulePackageName subroutine is invoked to determine the name of the rule package that the Genesys Rules Engine will be invoking to evaluate the classification rules.
  39. If the subroutine fails an error is extracted.
  40. This error is attached to user data as a key-value pair with the key IWD_Rule_Package_Determination_Error.
  41. If the subroutine was successful, a check is done to ensure the existence of the rule package name that was returned by the subroutine. If the rule package name was found, the flow goes to Step 44.
  42. If the rule package name was not found, this error is attached to user data as a key-value pair with the key IWD_Rule_Package_Determination_Error.
  43. The interaction is placed in the iWD_ErrorHeld queue.
  44. An ESP request is sent to the Genesys Rules Engine to evaluate the classification rules.
  45. The last Interaction Server-related error is extracted from a variable.
  46. A check is done to see if the error code is related to the ESP server communication.
  47. The last error is attached to user data as a key-value pair with the key IWD_GRE_Error.
  48. The interaction is placed in the iWD_ErrorHeld queue.
  49. The last error is attached to user data as a key-value pair with the key IWD_GRE_Error. If not, the value of the _counter variable is incremented by 1.
  50. A delay is introduced, based on the value of the _delay_ms variable. The flow goes back to 44 to retry the connection to the ESP server. The result from the ESP call to the Genesys Rules Engine is attached to the interaction as user data, with the key IWD_GRE_Result. This key-value pair will have the following format: 
    <tt>
return:ok| NumberOfRulesApplied:<number of applied rules>|RulesApplied:<rule 1 id> <rule1 name>, <rule2 id> <rule2
name>, ...

    The following example shows what the result might look like: 

    AttributeUserData [list, size (unpacked)=168] = 'ESP_Result' [str] =
"return:ok|NumberOfRulesApplied:12|RulesApplied:McrSlt1GlbClsf1
McrSlt1GlbClassification1, McrSlt1GlbClsf2
McrSlt1GlbClassification2"

    The flow continues with step 52.

    Classification Strategy—Section 3

    ClassStrat3.jpg

  51. A request is made to the ESP server, to ensure the integrity of the interaction data that was returned after the rules were invoked by the Genesys Rules Engine.
  52. A request is made to the ESP server, to ensure the integrity of the interaction data that was returned after the rules were invoked by the Genesys Rules Engine.
  53. The last Interaction Server-related error is extracted from a variable.
  54. A check is done to see if the error code is related to the ESP server communication.
  55. The last error is attached to user data as a key-value pair with the key IWD_BCMS_Error.
  56. The interaction is placed in the iWD_ErrorHeld queue.
  57. If the error check in Step 54 determined that the last error was potentially communication-related, the last error is attached to user data as a key-value pair with the key IWD_BCMS_Error.
  58. A delay is introduced, based on the value of the _delay_ms variable. The flow goes back to Step 52 to retry the connection to the ESP server.
  59. The ESP result is attached to user data as a key-value pair with the key IWD_BCMS_Result.
  60. Verification is done to check if a business process was assigned by a classification rule.
  61. If no business process was assigned, the interaction is placed into the iWD_ErrorHeld queue.
  62. If a business process was assigned, then the interaction is placed in the iWD_Captured queue.

Prioritization Strategy

The purpose of this strategy is to invoke the corresponding prioritization rules, analyze the result of the rules application and place the interaction into the appropriate queue, depending on the result.

This strategy processes interactions from the following queues:

  • iWD_Captured—Interactions have to satisfy the following conditions:
    • Active interactions only, (interactions which do not have the property IWD_activationDateTime set, or this property has a time stamp which is in the past.
    • Interactions are taken in the order they were submitted.

  PriorStrat1.jpg

Active Interactions only

  • iWD_Queued—Interactions have to satisfy the following conditions:
    • Interactions that are subject for immediate reprioritization (interactions that have the property IWD_reprioritizeDateTime set to a time stamp which is in the past)
    • Interactions are taken in order of IWD_reprioritizationDateTime (oldest first).

PriorStrat2.jpg

For reprioritization

Prioritization Strategy—Section 1

PriorStrat3.jpg

Prioritization Strategy - 1

  1. Variables are initialized:
    • _source_queue is the queue from which the interactions came. It will be used to determine if the prioritization service is being requested for initial prioritization or reprioritization.
    • _error_timeout_ms specifies the delay (in milliseconds) between attempts to invoke rules.
    • _default_priority specifies the priority which will be assigned if a priority is not specified by the customer (as part of the task capture) or by rules.
  2. The DetermineESPServerName subroutine is invoked to determine the correct ESP server name to use. The subroutine uses the List Object list BCMSServerList. This subroutine also sets up cases when there is reason to retry to invoke the ESP server.
  3. If the subroutine fails an error is extracted.
  4. This error is attached to user data as a key-value pair with the key IWD_BCMS_Determination_Error.
  5. If the subroutine was successful, a check is done to ensure the existence of the ESP server name that was returned by the subroutine.
  6. If the ESP server name was not found, this error is attached to user data as a key-value pair with the key IWD_BCMS_Determination_Error.
  7. The interaction is placed in the iWD_ErrorHeld queue.
  8. A request is made to the ESP server, to prepare the interaction data before the Genesys Rules Engine can be called to invoke the prioritization rules.
  9. The last Interaction Server-related error is extracted from a variable.
  10. The last error is attached to user data as a key-value pair with the key IWD_BCMS_Error.
  11. A delay is introduced, based on the value of the _error_timeout_ms variable. The flow goes back to Step 8 to retry the connection to the ESP server.
  12. The ESP result is attached to user data as a key-value pair with the key IWD_BCMS_Result.

    Prioritization Strategy—Section 2

    PriorStrat4.jpg

    Prioritization Strategy - 2

  13. The DetermineESPServerName subroutine is invoked to determine the name of the Genesys Rules Engine application. The subroutine uses the List Object list GREServerList.
  14. If the subroutine fails an error is extracted.
  15. This error is attached to user data as a key-value pair with the key IWD_GRE_Determination_Error.
  16. The interaction is placed in the iWD_ErrorHeld queue.
  17. If the subroutine was successful, a check is done to ensure the existence of the ESP server name that was returned by the subroutine. If the ESP server name was found, flow goes to Step 20.
  18. If the ESP server name was not found, this error is attached to user data as a key-value pair with the key IWD_GRE_Determination_Error.
  19. The interaction is placed in the iWD_ErrorHeld queue.
  20. The DetermineRulePackageName subroutine is invoked to determine the name of the rule package that the Genesys Rules Engine will be invoking to evaluate the prioritization rules.
  21. If the subroutine fails an error is extracted.
  22. This error is attached to user data as a key-value pair with the key IWD_Rule_Package_Determination_Error.
  23. The interaction is placed in the iWD_ErrorHeld queue.
  24. If the subroutine was successful, a check is done to ensure the existence of the rule package name that was returned by the subroutine. If the rule package name was found, flow goes to 27.
  25. If the rule package name was not found, this error is attached to user data as a key-value pair with the key IWD_Rule_Package_Determination_Error.
  26. The interaction is placed in the iWD_ErrorHeld queue.  

    Prioritization Strategy—Section 3

    PriorStrat5.jpg

    Prioritization Strategy - 3

  27. An ESP request is sent to the Genesys Rules Engine to evaluate the prioritization rules. If the request to the ESP server was successful, flow goes to Step 31.
  28. The last Interaction Server-related error is extracted from a variable.
  29. The last error is attached to user data as a key-value pair with the key IWD_GRE_Error.
  30. A delay is introduced, based on the value of the _error_timeout_ms variable. The flow goes back to Step 27 to retry the connection to the ESP server.
  31. If the ESP server reports that the operation was completed successfully, the results are attached to user data as a key-value pair with the key IWD_GRE_Result. This key-value pair will have the following format: 
    "return:ok| NumberOfRulesApplied:<number of applied rules>|RulesApplied:<rule 1 id> <rule1 name>, <rule2 id> <rule2 name>, "

    The following is an example of what the result might look like: 

    AttributeUserData [list, size (unpacked)=168] = 'ESP_Result' [str] =
"return:ok|NumberOfRulesApplied:2|RulesApplied:McrSlt1GlbPrior1
McrSlt1GlbPrioritization1, McrSlt1GlbClsf2
McrSlt1GlbPrioritization2"
  32. A request is made to the ESP server, to ensure the integrity of the interaction data that was returned after the rules were invoked by the Genesys Rules Engine. If the request was successful, flow goes to 36.
  33. If the request to the ESP server was not successful, the last Interaction Server-related error is extracted from a variable.
  34. The last error is attached to user data as a key-value pair with the key IWD_BCMS_Error.
  35. A delay is introduced, based on the value of the _error_timeout_ms variable. The flow goes back to 32 to retry the connection to the ESP server.
  36. The ESP result is attached to user data as a key-value pair with the key IWD_BCMS_Result.
  37. A check is made to see if this is the first time that prioritization rules are being evaluated for the interaction, and the priority was not set up by any rules. If this check is false, flow goes to 40.
  38. The error message Priority is not set up by rules is attached to interaction server data as a key-value pair with the key IWD_Prioritization_Error.
  39. The interaction is placed in the iWD_ErrorHeld queue.
  40. The interaction is placed in the iWD_Queued queue.

Distribution Strategy

This strategy routes interactions to a requested Agent, requested Agent Group, requested Skill, or to the default iWD Agent Group. This strategy processes interactions from the following queues:

  • iWD_Queued—Interactions have to satisfy the following conditions:
    • Interactions that are not subject for immediate reprioritization (interactions that do not have the property IWD_reprioritizeDateTime set, or that have this property set to a time stamp that is in the future).
    • Interactions are taken in order of priority (highest priority first)

Summary of Flow

DistStrat0.jpg

Distribution Strategy

  1. Extract information about requested agent, agent group, or skill and initialize internal variables. DistStrat1.jpg   Multi-Assign - Requested Agent and Skill
  2. A calculation is done to determine the timeout—how long the interaction should wait for a target to become available.
  3. If the reprioritize time was set up and the calculated timeout is less than or equal to the default timeout (1 hour, see Step 1), then the timeout remains as it is.
  4. If the reprioritize time was not set, or the calculated timeout is greater than the default timeout, then the waiting timeout is set to the default (1 hour).
  5. Analysis is done to determine whether an agent was requested.
  6. If an agent was requested, the URS variable is prepared (.a is added).
  7. Try to route the interaction to the requested agent without waiting. DistStrat2.jpg Route to agent
  8. Try to route the interaction to an agent with the requested skill without waiting. DistStrat3.jpg Route to Skill
  9. Analysis is done to determine whether an Agent Group was requested.
  10. If an Agent Group was requested, the URS variable is prepared (.ga is added).
  11. Try to route the interaction to the requested Agent Group without waiting.


    12. DistStrat4.jpg

    Route to Requested Agent Group

  12. Try to route the interaction to the iWD agent group with a wait time of 60 seconds.


    13. DistStrat5.jpg

    Route to Agent Group


  13. Get the last error.
  14. Verification is done as to why the target was not found.
  15. An error code is attached in case of any error other than a timeout. If more than one target is available, URS uses the StatAgentsLoading statistic to select the Agent who has the minimum load (this applies to routing to Skills and routing to Groups only; routing to a requested Agent does not use statistics). For more information about this statistic, see the Universal Routing 8.1 Reference Manual. The Route Interaction object also has an Interaction Queue tab. (This applies to all three Route Interaction objects in this strategy.)

    16. DistStrat6.jpg

    Route Interaction Properties—Interaction Queue


    The optional Interaction Queue tab enables you to specify two types of queues:

  • Queues for existing interactions (the queue in which the interaction should be placed after the agent is done working with it).
  • Queues for new interactions (the queue in which new interactions created by the agent should be placed).

A Description (optional) appears as a hint on the agent desktop as to where to place the interaction.

Mark Interaction as Done Strategy

The purpose of this strategy is to update the Universal Contact Server (UCS) database to mark the interaction as done. This equates to setting the value in the Status column of the Interactions table to 3. UCS clients, such as Interaction Workspace, will then display the status of this interaction as done when the user looks at interactions they have previously processed.

Interactions have to satisfy the following conditions:

  • The value of the attached data key IWD_isContactServer is 1
  • The value of the attached data key IWD_isDone is either null or 0 (zero)

  DoneStrat1.jpg

Mark Interaction as Done View

This strategy processes interactions from the following queues:

  • iWD_Completed
  • iWD_Canceled
  • iWD_Rejected

Summary of Flow

DoneStrat2.jpg

Mark Interaction as Done Strategy

  1. Variables are initialized:
    • _tenant_id is the Configuration Server Tenant ID associated with the interaction being processed by this strategy.
    • _interaction_id is the ID of the interaction being processed by this strategy.
    • _delay_ms specifies the delay (in milliseconds) between attempts to communicate with the Universal Contact Server.
    • The DetermineESPServerName subroutine is invoked to determine the correct ESP server name to use. The subroutine uses the List Object list called ContactServerList. This subroutine also sets up cases when there is reason to retry to invoke the ESP server.
    • If the subroutine is successful, the flow continues to Step 7.
  2. If the subroutine fails an error is extracted.
  3. This error is attached to user data as a key-value pair with the key IWD_UCS_Determination_Error.
  4. The value of the user data key IWD_isDone is set to 0 (zero).
  5. The interaction is returned to its previous queue.
  6. If the subroutine was successful, a check is done to ensure the existence of the ESP server name that was returned by the subroutine. If the ESP server name was found, the flow goes to Step 9.
  7. If the ESP server name was not found, this error is attached to user data as a key-value pair with the key IWD_UCS_Determination_Error. Flow goes to step 5.
  8. The strategy calls a method on the Universal Contact Server to set the status of the interaction to 3, indicating that the interaction is done.
  9. If the invocation of the method on the Universal Contact Server fails, an error is extracted.
  10. A check is done to evaluate the error code extracted in step 10.
  11. If it makes sense to retry updating the interaction record in UCS, the last error code is attached to the interaction with the user data key IWD_UCS_Error.
  12. A delay is introduced into the processing. Flow returns to step 9.
  13. If it does not make sense to retry updating the interaction record in UCS, the last error is attached to the interaction with the user data key IWD_UCS_Error. Flow goes to step 5.
  14. If the UCS update in step 9 was successful, the result from UCS is attached to the interaction with user data key IWD_UCS_Result.
  15. The value of the user data key IWD_isDone is set to 1. Flow goes to step 6.

Removal Strategy

The purpose of this strategy is to delete expired interactions from the Interaction Server database.

Important
This routing strategy has changed significantly from iWD 8.0 and 8.1.0, where it was called the Archive strategy. Please see Task Archiving.

A key-value pair in user data with the key IWD_expirationDateTime contains information about when an interaction has to be deleted.

Important
In release 8.1.1, the meaning of parameter IWD_expirationDateTime has changed from previous releases. IWD_expirationDateTime in 8.1.1 defines the amount of time for which a task is going to be kept in the Interaction Server database.

This strategy processes interactions from the following queues:

  • iWD_Completed
  • iWD_Canceled
  • iWD_Rejected

Interactions have to satisfy the following conditions:

  • Interactions must either have the property IWD_expirationDateTime set, or this property must have a time stamp which is in the past.
  • Interactions are taken in the order they were submitted.

  RemoveStrat1.jpg

The ‘Expired only’ Interaction Queue View Properties  

Removal Strategy (Entire Flow)

RemoveStrat2.jpg

Summary of Flow

When interactions enter the Removal strategy, the processing of the interaction is stopped. This means that the interaction is deleted from the Interaction Server database.

Modifying the iWD Business Process

For most environments, the only modification that will need to be made to the iWD Business Process is to the Distribution strategy. The recommended approach to doing this is:

  1. Add a new strategy into the iWD Business Process
  2. Replace the connection from iWD_Queued/All view to the Distribution routing strategy with a connection from iWD_Queued to your own routing strategy where distribution logic is described.
  3. Link your new distribution strategy to the out of the box iWD_Completed queue.

By modifying the business process in this way, rather than simply updating the provided Distribution strategy, you can easily import any new versions of the iWD Business Process that might be available in the future (the links will have to be reestablished to your own distribution strategy).

You can also add additional interaction queues into the IWDBP business process, based on your business requirements. However, keep the following points in mind:

  • The iWD_Queued queue must be present for Data Mart to properly count interactions/tasks. You can add other queues to the business process, but only after interactions have passed through the iWD_Queued queue.
  • Data Mart can properly determine when to consider a task as complete, only if the final queue in the business process is one of the following:
    • iWD_Rejected,
    • iWD_Canceled,
    • iWD_Completed

 

This page was last edited on October 30, 2018, at 14:59.
Comments or questions about this documentation? Contact us for support!