Revision as of 17:01, June 13, 2017 by Bonniem (talk | contribs) (Architecture Diagram for Workflows)
Jump to: navigation, search

Architecture Diagram for Workflows

To give the "Big Picture" and show the various Genesys components used for SCXML-based workflows, below is a high-level diagram of the Universal Routing 8.x architecture.

XMLArch3.gif

The SCXML-based strategy creation and processing steps above are keyed to the numbers below.

  1. The developer specifies Configuration Server objects as routing targets prior to creating the routing application in Composer. For example, a routing target could be an agent (Person object) or Agent Group or an interaction can be sent to a queue. The developer may also create workflows that route based on the value of a Stat Server statistic or a statistic that you defined in Composer's Statistics Builder.
  2. The developer (or other persona) creates and tests the routing application and manually deploys it on a web application server. Once this is done, the runtime life cycle of the routing logic can begin with a routing request.
  3. URS gets an EventRouteRequest message from T-Server or another media server such as an eServices media server.  
  4. The request goes to the Routing Point. URS gets the URL of the application server to be contacted about SCXML strategy to be provided, which is a property of the Routing Point. After the URL is obtained, ORS issues the HTTP GET ( or POST) request to the application server.
  5. The application server executes the request and returns the SCXML document back to ORS.
  6. Upon getting the response, ORS passes the received SCXML document to the SCXML engine. The SCXML engine runs the SCXML application, invoking ORS/URS services as needed.
  7. ORS or URS issues a RequestRouteCall message to the media server.
Comments or questions about this documentation? Contact us for support!