XX/1 Server SDK: Message Creation

XX/1 Business Functions are document oriented, which means that the Root element of the client request XML designates the Business Function (work flow script) to be invoked on the XX/1 Server.

To implement a new Business Function / Message perform the following steps:

Provider adapters are configured in the <provider> section of main configuration file.

<provider>
    <adapter name="AmadeusWS" lib="xxghost" config="ghostcfg.xml"/>
    <adapter name="GalileoWS" lib="xxproxy" config="proxycfg.xml"/>
    <adapter name="SabreWS" lib="metapool" config="sabrewsmpcfg.xml"/>    
    <adapter name="Dummy" lib="xxnull"/>
</provider>

Note the logical name for the provider. All provider references in your transaction configuration and/or script have to match this name.

For most development purposes you will want to use the Ghost or Proxy adapter.

If you have access to a server running the real provider adapter, you should create sample provider data files using the XXTest tool with the native (-n) option.

You use transformation services to transform the provider XML message or parts of the message into the standardized messages you want to implement. Transformation services are configured in the <transformations> section of main configuration file.

<transformations default="MS">
    <service name="MS" lib="xxtMS" config=""/>
    <service name="Xalan" lib="xxtXalan" config=""/>
    <service name="Oracle" lib="xxtOracle" config=""/>
    <service name="AXSLT" lib="xxtAXSL" config=""/>
</transformations>

Note the logical name for the service. All service references in your transaction configuration and/or script have to match this name. If you do not specify a specific service on transaction script level, "default" is used.

A Transformation Service typically is an implementation of a W3C compliant XSLT processor. You may also code transformations or parts of those in C/C++ and provide your own transformation service library. Lastly you may code transformations entirely using JavaScript and/or Java within the transaction script.

The recommended default service for Win32 configurations is xxtMS (MS XML 4.0/6.0).

The recommended default service for UNIX configurations is xxtApache (Apache Xalan/Xerces combination).

The recommended default service for Linux configurations is xxtGnome (libxslt).

The recommended service for extreme load or large size transactions is xxtAXSL (AXSLT (Accelerated XSL)) for all platforms.

Transaction Script Engines are configured in the <scripting> section of main configuration file.

<scripting>
    <engine name="JavaScript" lib="xxjse" config="xxjsecfg.xml" files=".js"/>
    <engine name="eXMLTS" lib="exmlts" config=""/>
    <engine name="MultiCast" lib="xxmulticastse"/>
    <engine name="XBatch" lib="xbatch" config=""/>
    <engine name="COMScript" lib="xxcomse" config=""/>
</scripting>

Note the logical name for the engine. All engine references in your transaction configuration have to match this name. You can alternatively associate file extensions to a script engine.

The recommended script engine for most of your scripts is the JavaScript engine. It is available for all platforms.

Create your Java script using any text editor and use ".js" as preferred file extension.

For detailed information on writing Java scripts refer to the Server SDK JavaScript Reference.

Once you have created the script file, you have to add it to the message map. A script is associated to a provider and the request message root node. Each provider/request message transaction entry must be unique on a server configuration.
Transaction maps are configured in the <transactions> section of main configuration file.

<transactions>
    <tmap>
        <t name="DOMTestRQ" provider="Amadeus" engine="JavaScript" script="test.js"/>
    </tmap>
    <link xlink:type="simple" xlink:href="Amadeus/AmadeusTransactionMap.xml"/>
    <link xlink:type="simple" xlink:href="Galileo/GalileoTransactionMap.xml"/>
</transactions>

Transaction map tables (tmap) can be inline or external files referenced by a XLink statement. There can be any number of <tmap> entries in a configuration. Each tmap contains any number of transaction map entries <t>. The name attribute of the <t> entry must match the root node of the client request XML. The provider attribute must contain a valid provider name.