IWDBP Strategies & Subroutines

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.

Flow Summary

Click to enlarge.

Flow Detail

1. Entry to the Classification strategy.
2. A command is sent to URS to use the interaction age while sorting interactions in internal queues.
3. The InvokeUCS subroutine is invoked to create a new interaction in the UCS database.
4. The InvokeGRE subroutine is invoked.
5. Exit Classification strategy.

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.

 

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).

For reprioritization

Flow Summary

Flow Detail

1. Entry to the Prioritization strategy.
2. The InvokeGRE subroutine is invoked.
3. Exit Prioritization strategy.

Distribution Strategy

This strategy routes interactions to a requested Agent, requested Agent Group, requested Skill, or to the default iWD Agent Group, and can now process an IWD_Segment attribute from the segmentation settings.

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)

Flow Summary

Flow Detail

1. Entry to the Distribution strategy.
2. Extract information about requested agent, agent group, or skill and initialize internal variables.

   

3. A calculation is done to determine the timeout—how long the interaction should wait for a target to become available.
4. 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.
5. 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).
6. Analysis is done to determine whether an agent was requested.
7. If an agent was requested, the URS variable is prepared (.a is added).
8. Update the IWD_segment attribute to '_requested_agent'.

   

9. Try to route the interaction to the requested agent without waiting.

   

10. Update the IWD_segment attribute to '_requested_skill'.
11. Try to route the interaction to an agent with the requested skill without waiting.

    

12. Analysis is done to determine whether an Agent Group was requested.
13. If an Agent Group was requested, the URS variable is prepared (.ga is added).
14. Update the IWD_segment attribute to '_requested_agent_group'.
15. Try to route the interaction to the requested Agent Group with wait time set to _waitTargetTimeout.
    

    

16. Update IWD_segment attribute to '_default'.
17. Try to route the interaction to the iWD agent group with a a wait time to _waitTargetTimeout.
    

    

18. Get the last error.
19. Verification is done as to why the target was not found.
20. 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.)

    

    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.

21. Exit from the Distribution strategy.

MarkInteractionAsDone 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)

 

MarkInteractionAsDone View

This strategy processes interactions from the following queues:

• iWD_Completed
• iWD_Canceled
• iWD_Rejected

Flow Summary

Flow Detail

1. Entry to MarkInteractionAsDone strategy.
2. The InvokeUCS subroutine is invoked to complete interaction in the UCS database.
3. Reads _last_error_str_ from InvokeUCS.
4. The last error is attached to user data as a key-value pair with the key IWD_UCS_Error.
5. Exit MarkInteractionAsDone strategy.

Removal Strategy

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

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

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 not set, or this property must have a time stamp which is in the past.
• If UCS is available, interactions must be marked as done in UCS
• Interactions are taken in the order they were submitted.

 

The ‘Expired only’ Interaction Queue View Properties  

Flow Summary

Flow Detail

1. Start.
2. 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.

Invoke UCS Strategy

Flow Summary

Part 1

Click to enlarge.

Part 2

Click to enlarge.

Flow Detail

1. Entry to InvokeUCS strategy.
2. Check if in_method_name = 'Create' | in_method_name = 'OMInteractions'.
3. Initialize variables:
   • _tenant_id—Read from task attribute TenantId.
   • _interaction_id—Read from task attribute InteractionId.
   • delay_ms—Specifies the delay (in milliseconds) between attempts to invoke UCS.
4. Check if in_method_name = 'Create'.
5. 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.
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.
7. The value of the user data key IWD_isContactServer is set to 1.
8. The value of the user data key IWD_isContactServer is set to 0.
9. 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.
10. A new interaction is created in the UCS database for this iWD task. If that function is successful, flow goes to 11. 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 is written to the variable IWD_UCS_Result.
11. 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 is written to the variable IWD_UCS_Result.
12. If the subroutine fails an error is extracted.
13. If the creation of the interaction in UCS was unsuccessful, an error is extracted from user data.
14. A check is done to see if the error code is related to the ESP server communication.
15. This error is attached to user data as a key-value pair with the key IWD_UCS_Error.
16. The interaction is placed in the iWD_ErrorHeld queue.
17. This error is attached to user data as a key-value pair with the key IWD_UCS_Error.
18. A delay is introduced, based on the value of the _delay_ms variable. The flow goes back to 5 to retry the connection to the ESP server.
19. Exit InvokeUCS strategy
20. 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.
21. If the subroutine was successful, a check is done to ensure the existence of the ESPserver name that was returned by the subroutine.
22. An error is extracted from user data.
23. An error is extracted from user data.
24. The value of the user data key IWD_isDone is set to 0.
25. 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.
26. The value of the user data key IWD_isDone is set to 1.
27. The interaction is returned to its previous queue.
28. If the invocation of the method on the UCS fails, an error is extracted.
29. If it makes sense to retry updating the interaction record in UCS.
30. The last error code is attached to the interaction with the user data key IWD_UCS_Error.
31. A delay is introduced into the processing. Flow returns to step 20.
32. The last error is attached to user data as a key-value pair with the key IWD_UCS_Error when in_method_name is not set to 'Create' or in_method_name = 'OMInteractions'.
33. The last error code is attached to the interaction with the user data key IWD_UCS_Error.
34. The interaction is placed in the iWD_ErrorHeld queue.
35. Exit InvokeUCS strategy.

Invoke GRE Strategy

Part 1

Click to enlarge.

Part 2

Click to enlarge.

Flow Detail

1. Entry to InvokeGRE strategy.
2. Check if in_method_name is set to SetBusinessContext or Prioritize.
3. A variable is initialized—_delay_ms specifies the delay (in milliseconds) between attempts to invoke rules.
4. The DetermineESPServerName subroutine is invoked to determine the name of the Genesys Rules Engine Application. The subroutine uses the List Object list GREServerList.
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. If the ESP server name was found, the flow goes to 10. 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.
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_GRE_Determination_Error.
7. The interaction is placed in the iWD_ErrorHeld queue.
8. If the subroutine fails an error is extracted.
9. This error is attached to user data as a key-value pair with the key IWD_GRE_Determination_Error.
10. Check if in_custom_package_name was published to this subroutine. If it is set then in_custom_package_name will be run. Otherwise package name needs to be found in Iwd_Package_List.
11. Assign in_custom_package_name to _gre_package_name and set _return_code to 0.
    11a. 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. If the rule package name was found, the flow goes to Step 16.
12. If the rule package name was found, the flow goes to Step 16.
13. 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.
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_Rule_Package_Determination_Error.
16. Set the value for RulePhase and IWD_GRE_Result to empty string.
17. Check if in_method_name = SetBusinessContext.
    • If in_method_name is set to SetBusinessContext then the process calls classification rules in GRE.
    • If in_method_name is set to Prioritize then the process calls prioritization rules in GRE.
18. An ESP request is sent to the Genesys Rules Engine to evaluate the classification rules.
19. The ESP result is attached to user data as a key-value pair with the key IWD_GRE_Result.
20. Check if IWD_reprioritizeDateTime was changed by rules.
21. Delete IWD_reprioritizeDateTime from interactin if it was not changed by rules.
22. Invoke CheckBusinessValueAndPriority subroutine to verify if IWD_businessValue and Priority have correct values.
23. Check if in_method_name = Prioritize.
24. Check if Priority was changed by rules in Prioritization.
25. Attach IWD_Prioritization_Error to interaction with message Priority is not set up by rules.
26. The interaction is placed in the iWD_Queued queue.
27. An ESP request is sent to the Genesys Rules Engine to evaluate the prioritization rules.
28. The last Interaction Server-related error is extracted from a variable.
29. A check is done to see if the error code is related to the ESP server communication.
30. The last error is attached to user data as a key-value pair with the key IWD_GRE_Error.
31. Check if Department/Process is active.
32. Check if business process was assigned.
33. The interaction is placed in the iWD_Captured queue.
34. 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.
35. A delay is introduced, based on the value of the _delay_ms variable. The flow goes back to 18 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:
    
    

    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:McrSlt1GlbClsf1McrSlt1GlbClassification1, McrSlt1GlbClsf2McrSlt1GlbClassification2"
    
    

36. The interaction is placed in the iWD_Captured queue.
37. Exit InvokeGRE subroutine.
38. The last error is attached to user data as a key-value pair with the key IWD_GRE_Error when in_method_name is not set to SetBusinessContext or Prioritize.
39. The interaction is placed in the iWD_ErrorHeld queue.
40. Exit InvokeGRE subroutine.

CheckBusinessValueAndPriority Subroutine

Flow Summary

Click to enlarge.

Flow Detail

1. Entry to the CheckBusinessValueAndPriority subroutine.
2. Variables are initialized:

• out_return_code—Return code returned by this subroutine at the exit.
• _min_business_value—Minimum available business value.
• _max_business_value—Maximum available business value.
• _min_priority—Minimum available priority.
• _max_priority—Maximum available priority.

1. Check if task has set IWD_businessValue attribute.
2. If IWD_businessValue attribute was not set then it will be set to _min_business_value.
3. IWD_businessValue attribute is attached to the task.
4. Check if task has set Priority attribute.
5. If Priority attribute was not set then it will be set to _min_priority.
6. Priority attribute is attached to the task.
7. Read IWD_businessValue attribute from the task and put it in _iwd_business_value variable.
8. Check if _iwd_business_value is leass than _min_business_value. If true then flow goes to 4.
9. Check if _iwd_business_value is greater than _max_business_value.
10. If _iwd_business_value is greater than _max_business_value then set _iwd_business_value to _max_business_value.
11. Read Priority attribute from the task and put it in _iwd_priority variable.
12. Check if _iwd_priority is less than _min_priority. If true then flow goes to 7.
13. Check if _iwd_priority is geater than _max_priority.
14. If _iwd_priority is reater than _max_priority then set _iwd_priority to _max_priority.
15. Check if _iwd_business_value and _iwd_priority are in range of allowed values.
16. If _iwd_business_value and _iwd_priority are out of scope then out_return_code will be set to 1.
17. Exit CheckBusinessValueAndPriority subroutine.

FindListObjectItem Subroutine

This subroutine amalgamates two subroutines that were previously separate in release 8.5.104:

• DetermineESPServerName
• DetermineRulePackageName

Flow Summary

Click to enlarge.

Flow Detail

1. Entry to FindListObjectItem subroutine.
2. Initialize variables:

• _key_to_find_in_list_object—Assign task IWD_SolutionId.
• out_item_name—Set its value to empty string.

1. Check if _key_to_find_in_list_object is not empty.
2. Search _key_to_find_in_list_object in in_list_name. Result will be assigned to out_item_name.
3. Check if out_esp_name is empty.
4. Set out_return_code to 0.
5. Set out_return_code to 1.
6. Exit FindListObjectItem subroutine