Section I – SCXML > SCXML Extensions > Session Parameterization Bottom of Page
| Genesys 8.0 SCXML Technical Reference
SCXML Element Extensions >

## Session Parameterization

#### Session Initiation Parameters

Session parameterization provides the ability to allow an orchestration application to define a set of parameters that are to be provided to the session when it is started.

Those parameters needed by the application will be defined in the SCXML document using the SCXML `<data>` element and Genesys-specific extension attributes. These parameter elements are used to define the following:

- The name of the parameter to be used by the application.
- Where to get the value for this parameter from at session initiation.
- Details on the characteristics of the parameter. This information is primarily used by other components to help provide the correct value for this parameter when the application session is started. For example, to help define (Genesys Adminstrator) and execute (Orchestration platform) the provisioning of the parameter value from the appropriate source for the application.

For details on these SCXML extensions to the `<data>` element, see the <data> section.

The actual values of these defined parameters come from various sources, depending on how the session is initiated. These parameter values are provide once when the session is initated and if updated during the execution of the session (for example, the use of `<assign>`) will not be synchronized with their data sources unless the session takes an explicit action (for example, `<fetch>`).

The following describe the different methods of supplying the parameters to an initated session. They can be used in combination to pass the necessary parameters to the initated session:

- Parameters Passed Explicitly by the Initiating Entity — These parameters are passed explicitly from the initiating source to the initated session.

- `<invoke>`- or `<session:start>`-initiated session — Parameters are passed via these actions and the parameters defined by the child `<param>` elements. The initated session document must have the appropriate `<data>` elements (that is, the `<param>` name attribute value must equal the `<data>` id attribute value) defined to represent the parameters being passed by the intitiating session. These parameter `<data>` elements should not have a "src" attribute. For example, if the initiating session has a `<param name="param1" ...>` element, the initiated session must have a `<data id="param1">` element. If the "name" and "id" attributes are the same, then the `<param>` data will be copied to the location defined in the `<data>` element and will overwrite any initialization done by the session application. If the `<param>` "name" attribute does not match any of the `<data>` id attributes, the parameter value passed will simply be dropped.
- Web services-initated session — Parameters are passed as part of the web service (SessionStart) message and passed as message attributes or fields. The initated session's document must have the appropriate `<data>` elements (that is, the web service attribute or field name value must equal the `<data>` "id" attribute value) defined to represent the parameters being passed by the initiating web service. These parameter `<data>` elements should not have a "src" attribute. If the web service attribute or field name and `<data>` "id" attribute are the same, then the web service attribute or field value will be copied to the location defined in the `<data>` element and will overwrite any initialization done by the session application. If the web service attribute name does not match the `<data>` element's "id" attribute, the parameter value passed will simply be dropped.
- Trigger-initated session — trigger definition elements are passed as parameters. The trigger-initated session's document must have the appropriate `<data>` elements (that is, the trigger definition element attribute or field name value must equal the `<data>` "id" attribute value) defined to represent the parameters being passed by the functional module triggering the session initiation. These parameter `<data>` elements should not have a "src" attribute. If the trigger definition element attribute or field name and `<data>` "id" attribute are the same, then the trigger definition element attribute or field value will be copied to the location defined in the `<data>` element and will overwrite any initialization done by the session application. If the trigger definition element attribute name does not match any of the `<data>` "id" attributes, the parameter value passed will simply be dropped. The following is the list of attribute types that are available as part of a trigger-initiated session:

- The trigger event and its properties (`_genesys.ixn.interactions[].xdata`)
- The trigger entity itself (`_data._dest`)
- Provisioned parameters (`_data._statserver`)

- Parameters to be Retrieved From Explicit Sources — These parameters will be collected from the sources defined by the `<data>` "src" attribute values when the session is initiated. The following sources are supported:

- Application Server and File Data — The src attribute must have a value that uses the HTTP/HTTPS/file URI schema, for example, `<data id="xserver" src="www.someurl.com/location1">`.

#### Known Session Parameters

The following parameters are defined and known parameters that can be defined and used by the orchestration application.

##### Server Parameters

The following is the definition of the parameters that are available from provisioning on the server addresses used by this application. It is the responsibility of the developer to add the following global `<datamodel>` in order to access these parameters. If they are not defined, then they will not be available to the session.

    <datamodel>
    	<data id="_statserver"/>
    	<data id="_outbserver"/>
    	<data id="_outbserver_s"/>
    	<data id="_tserver"/>
    	<data id="_ixnserver"/>
    	<data id="_classserver"/>
    	<data id="_cvserver"/>
    </datamodel>

Name | Access | Type | Default Value | Valid Values | Description
--- | --- | --- | --- | --- | ---
`_data._statserver` `<data id="_statserver"/>` | read only | URI | None | Any valid HTTP or HTTPS URI schema which has the host and port for the server. | This is the statserver that can be used by the application. The value is provided by the provisioning system. Note: this statserver address could also be pulled from the location of the `<data>` "src" attribute using a valid HTTP or HTTPS URI scheme. For example, `<data id="_statserver" src= http://somehost/someappl />`
`_data._outbserver` `<data id="_outbserver"/>` | read only | URI | None | Any valid HTTP or HTTPS URI schema which has the host and port for the server. | This is the primary outbound server that can be used by the application. The value is provided by the provisioning system. Note: this outbound server address could also be pulled from the location of the `<data>` "src" attribute using a valid HTTP or HTTPS URI scheme. For example, `<data id="_outbserver" src= http://somehost/someappl />`
_data._outbserver_s `<data id="_outbserver_s"/>` | read only | URI | None | Any valid HTTP or HTTPS URI schema which has the host and port for the server. | This is the secondary or backup outbound server that can be used by the application. The value is provided by the provisioning system. Note: this outbound server address could also be pulled from the location of the `<data>` "src" attribute using a valid HTTP or HTTPS URI scheme. For example, `<data id="_outbserver_s" src= http://somehost/someappl />`
_data._tserver `<data id="_tserver"/>` | read only | URI | None | Any valid HTTP or HTTPS URI schema which has the host and port for the server. | This is the telephony server that can be used by the application for voice and chat interactions. The value is provided by the provisioning system. Note: this telephony server address could also be pulled from the location of the `<data>` "src" attribute using a valid HTTP or HTTPS URI scheme. For example, `<data id="_t-bserver" src= http://somehost/someappl />`
_data._ixnserver `<data id="_ixnserver"/>` | read only | URI | none | Any valid HTTP or HTTPS URI schema which has the host and port for the server. | This is the message-based media (interaction) server that can be used by the application. The value is provided by the provisioning system. Note: this message-based media (interaction) server address could also be pulled from the location of the `<data>` "src" attribute using a valid HTTP or HTTPS URI scheme. For example, `<data id="_ixnserver" src= http://somehost/someappl />`
_data._classserver `<data id="_classserver"/>` | read only | URI | none | Any valid HTTP or HTTPS URI schema which has the host and port for the server. | This is the classification server that can be used by the application. The value is provided by the provisioning system. Note: this classification server address could also be pulled from the location of the `<data>` "src" attribute using a valid HTTP or HTTPS URI scheme. For example, `<data id="_classserver" src= http://somehost/someappl />`
_data._cvserver `<data id="_cvserver"/>` | read only | URI | none | Any valid HTTP or HTTPS URI schema which has the host and port for the server. | This is the customer view server that can be used by the application. The value is provided by the provisioning system. Note: this customer view server address could also be pulled from the location of the `<data>` "src" attribute using a valid HTTP or HTTPS URI scheme. For example, `<data id="_cvserver" src= http://somehost/someappl />`

Section I – SCXML > SCXML Extensions > Session Parameterization Top of Page
| Genesys 8.0 SCXML Technical Reference
SCXML Element Extensions >