Jump to: navigation, search

Interaction Process Diagrams

What is an IPD?

An interaction process diagram (IPD) provides a high level view of how multimedia interactions flow through various components like media servers, interaction queues, workbins, and workflows. An IPD is somewhat similar to a Business Process in Interaction Routing Designer, but is SCXML-based, contains additional functionality and works with Orchestration Server.

Starting SCXML Page

In addition, an IPD functions as the starting SCML page for both voice and multimedia interactions and results in using the same session across the entire interaction process. It also updates objects in Configuration Server and activates the linkages specified in the IPD.

IPDExampleMM.gif An IPD used for multimedia interactions:

  • Visually presents and directs the flow of interactions through various processing blocks (media servers, queues, and workflows).
  • Defines what happens to customer multimedia interactions from the point of arrival at your contact center to the point of completion.
  • Can implement the procedures used by agents, supervisors, quality assurance, and other personnel in your company to accomplish your company's business objectives related to incoming multimedia interactions.

An IPD also enables visual configuration of the associated Configuration Server objects.  When connected to Configuration Server, you trigger the actual Configuration Database update by using Composer's Publish operation. Publishing causes Composer to push out  relevant subsets of the configuration information to Configuration Server. Here platform components can query for the information and use it for processing interactions.

SCXML File Creation

Composer expects IPDs (*.ixnprocess files) to be present in the Interaction Processes  folder. This folder is accessible from the Project Explorer. The code generation step creates SCXML files for the following types of diagrams:

  • Interaction process diagram: One SCXML file is created for:
  • Each Interaction Queue block present in the diagram with the name IPD_<Diagram Name>_<Interaction Queue Block name>.scxml (Multimedia interaction scenarios).
  • Each Workflow block present in the diagram, that is not connected to an Interaction Queue block with the name IPD_<Diagram Name>_<Workflow Block name>.scxml (voice or interaction-less scenarios). Each of these files represents an entry point into this application and can be specified in the EnhancedRoutingScript object. This Script object should never point directly to a workflow or sub-workflow SCXML file.
  • Workflow diagram, sub-workflow diagram: Both types of files have the .workflow extension. Code generation creates an SCXML file for each diagram with the same name as the diagram name.

The IPD SCXML file includes one or more workflow SCXML files which, in turn, can contain a hierarchy of sub-routine SCXML files. Orchestration Server combines all these related files into a single document and then executes the resulting combined SCXML document. Due to this reason, the line numbers mentioned in Orchestration Server logs may not match the line numbers in individual Composer SCXML files. See the Orchestration Server documentation for information on how to obtain access to this merged document.

Starting a New IPD

See Starting a New IPD when creating a routing application.

Executing an IPD

The following Genesys servers work together to execute an interaction processing diagram:

  • For multimedia interactions, handles queue processing, delivery of interactions to selected resources, and invoking multimedia services. For information on Interaction Server, start with the eServices/Multimedia 8.1 Deployment Guide.
  • (ORS) interprets the top-level SCXML document created as a result of the interaction processing diagram. For information on ORS, start with Orchestration Server 8.1 Deployment Guide.
  • ORS provides the Genesys Functional Modules (Queue, Interaction, Voice Interaction, Dialog, Resource), which are described in the Orchestration Server 8.1.3+ Developer's Guide.

ORS sends requests to Universal Routing Server, invoking actions from these modules based on its SCXML interpretation. URS then determines available resources (which may be another queue or the final target, such as an agent) where interactions can be delivered to and returns responses back to ORS with the resultant action information.

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