|
Genesys 8.1 SCXML Technical Reference |
||
SCXML application processing is actually comprised of several parts (that is, more than just SCXML), as shown in Figure 1. Some parts are delivered as part of the orchestration platform and are utilized by the developer when creating the orchestration application (salmon color), while other parts are created by the developer (grey color) for their specific orchestration application and this is then deployed on the orchestration platform. The following describes the details associated with each part.
Orchestration Platform Overview
The orchestration platform components are really the framework for building an orchestration application and controlling it during run time.
This is the component of the orchestration platform that manages the execution of the orchestration applications. This component manages the application through an SCXML session and its object model, which represents an instance of the application. This object is called a session. It contains all of the data and objects needed for the orchestration application and its logic. The following is the set of objects and data maintained with each session:
<datamodel>
elements. These properties and objects can have different levels of scope based on where they are defined in the SCXML document. The scoping will follow the rules outlined in the SCXML specification. The SCXML engine also has an ECMAScript engine imbedded. This provides the orchestration application with a data model and a way to provide low-level scripting functionality for the orchestration application.
This engine provides an interface that gives orchestration applications access to the functional modules and their functions.
An orchestration application is broken down into parts so as to create the appropriate separation between the part of the application that does the orchestration-related logic and the part that does the business-specific logic. This separation provides the developer with greater access to other business systems and functionality without having to change the orchestration logic itself. The orchestration-related logic is executed on the orchestration platform and the business-specific logic is executed on the application server, as shown in Figure 2. As a result, the following are the parts of an orchestration application that need to be created by a developer using the Composer IDE or by hand using other IDE tools.
Orchestration Application
SCXML Document (Orchestration Logic) — This part defines the orchestration-related processing of the application. This orchestration logic processing and the associated session state are managed by the SCXML engine. The SCXML document created by the developer is the main representation of the orchestration logic. The developer uses the SCXML elements along with the functional module interfaces to define the business-specific orchestration application. The logic definition can be as complex and business-specific as the developer likes. The SCXML elements can be used to define any type of orchestration logic or any combination of orchestration logic in one document. The SCXML document can be retrieved using the following URI types: File; HTTP; and HTTPS. For details on the SCXML functionality, see the
Business Content — The content could be generated by actual "business logic" running on the application server — or it could just be a static content file on the application server, which could be updated (even manually) as required to allow things to be dynamic. The business content and associated logic itself will be created based on the programming technology of the application server it is going to run on. So the application server-specific development tools will be used to create this content and associated logic. The business content is accessed within SCXML executable content elements (<onentry>
) using the session functional module interfaces. This business content and associated logic will be deployed and executed on an application server. The orchestration platform will support both (.NET and J2EE) application servers.
The orchestration platform must be the integration hub for orchestration-related services from media channels (new or supplied) to back end services (recommendation systems, marketing systems, optimization systems (WFO, pacing, business policies, and so on)). This part of the orchestration platform is the functional module framework. This framework provides a common integration model and framework which will allow a developer to create a functional module for any media channel or back end service so that it can be used directly in orchestration logic.
A functional module for a given functional domain has the following types of interfaces, which will be available to orchestration logic through the functional module:
Object Model — Functional module objects and their properties that are created at runtime by the functional module for a given SCXML session will be exposed by a set of ECMAScript objects which can be used from expression attributes and SCXML executable content places.
Functions — This defines the set of ECMAScript functions that can be used on the object model for this functional module. These functions can be used from expression attributes and SCXML executable content places.
Parameter Elements — In some cases, a functional module may have action elements that require complex parameters. These parameter elements will be defined by the orchestration logic developer using the functional module's defined XML form for that entity and will be children of the associated action element.
Action Elements — The actions for a functional module will be exposed by a defined XML namespace and elements which can be used in SCXML executable content places.
Events — The events of a functional module will be exposed by an SCXML-based event model with a unique event naming convention and corresponding event properties via the _event.data
system variable and a defined ECMAScript object (datamodel).
For details on functional module functionality and interfaces see the Functional Modules section.
A functional module will interface with platform components using the functional module framework and the platform component interfaces. The following interfaces that will be available to a functional module:
Session Integration Service — This allows the functional module to integration with the SCXML engine in order to process and manage any of the above functional module interfaces that may be part of the orchestration application.
Platform Service — This allows the functional module to integrate with the platform functions to help manage in the platform.
Figure 3 shows the relationships between the different parts:
Functional Module Framework
The following services can be used by the other platform components (for example, functional modules, SCXML engine, and so on) to help manage their functionality:
Configuration Services — Allows the platform components to access configuration data (for example, trigger definitions, and so on).
Logging Services — Allows the platform components to log the appropriate functional module-specific events on the condition of the given part (for example, error information, debug information).
Persistence Services — Allows the platform components to persist critical information that can be used to recover the components after a platform failure. Also includes the ability to request that the platform persist session at a given point and then restore it.
This interface is provided by the orchestration platform and is used to control and monitor the execution of orchestration logic by external systems. It has two different forms:
The interface has two parts.
Actions — The action interfaces are SOA and HTTP based for external systems. There are also an XML-based element schema and standard SCXML elements for other orchestration logic sessions.
Events — The set of events that are generated by the orchestration platform on behalf of the orchestration logic for external systems, as well as other orchestration logic sessions.
|
Genesys 8.1 SCXML Technical Reference |
||