About Translations

To enable SRT to place orders received from upstream systems into a recognizable format, you must write an XSL translation (XSLT) that accepts an XML document from an upstream system and outputs an XML document, consisting of name value pairs, that is used by the second layer of translation.

These XSLT scripts enable an XML document to be transformed into another XML document of a different structure. For example, an XML document arriving at the SRT from an upstream system must be transformed into an XML document that conforms to the SRT service activation schema.

Alternatively, an XML document arriving at the SRT from ASAP (for example a work order failure notification) must be transformed into an XML document format that is expected by an upstream system.

Save the XSLT in a Oracle Communications Design Studio library where it can be deployed by Design Studio to an ASAP environment (and possibly source controlled).

Note:

Developers may need to create and configure lookups to obtain any additional data that is required to activate the service but that is unavailable from upstream systems. Developers may also use lookups to convert specific data elements into a format that is expected by the configuration further downstream.

Using the Translation editor, you can identify one or more XSLT scripts to be used by the SRT component of ASAP at run time.

Translations can be implemented to:

Translate incoming requests from an upstream system.
Translate ASAP responses to ASAP events (such as FAILURE, COMPLETE) for return to the upstream system.
Translate outgoing ASAP events (such as FAILURE, COMPLETE) to the upstream system.

Translations can be contained in a single file. For organizational purposes, however, you can create additional files for different upstream systems.