| Oracle® Communications ASAP Service Request Translator User's Guide Release 7.2 E18882-01 |
|
 Previous |
 Next |
| Oracle® Communications ASAP Service Request Translator User's Guide Release 7.2 E18882-01 |
|
Previous |
Next |
This chapter describes the end-to-end translation process, with particular emphasis on the components of the translation that you must configure.
An example of a typical translation process follows:
A customer service representative (CSR) receives a request to add a new subscriber with Global System for Mobile communications (GSM) bearer service, several basic supplementary services such as call forwarding (CFD) and call waiting (CWT) and voicemail service.
The CSR creates a service order and enters it into the customer relationship management system (CRM). The service order includes information about the subscriber and the services they have selected.
The CRM submits the service order to the Enterprise Application Integration (EAI).
Other Operations Support Systems (OSS)/ Business Support Systems (BSS) interact with the EAI to process the order and contribute additional provisioning information to the order. For example, an order may include the following information before it is submitted to ASAP:
MSISDN
IMSI (SIM details)
GSM bearer service details
Supplementary services list (CFD, CWT)
KI (SIM details)
Algorithm (SIM details)
Carrier Code
Profile
OIC
Welcome Message
The EAI publishes a message (XML document) containing the following information:
The parameters listed above
Service bundle name or Service action name
Action (for example, ADD)
Provisioning parameters (label, value)
System ID
Work order properties such as due date and time, priority etc.
When an incoming message is published by the upstream system, it is received by the SRT.MessageQueue and a service request order is created that will serve as the source of the translation.
The following is an example of an incoming message.
<?xml version="1.0" encoding="UTF-8"?>
<UPSTREAM_Order_Value xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<OrderLevelInfo>
<ApplicationClientId>Upstream</ApplicationClientId>
<ServiceOrderId>ADDFEAT</ServiceOrderId>
<ScheduleActivationDate>2005-01-13T12:00:00</ScheduleActivationDate>
<OrderType>ChangeSubscriberService</OrderType>
<PayMethod>Pre-Paid</PayMethod>
<SIM>
<!--The first 5 character of region (55555)-->
<IMSI>5555510007</IMSI>
<KI>0</KI>
<Algorithm>None</Algorithm>
</SIM>
<Old_SIM>
<Old_IMSI>5555510009</Old_IMSI>
<Old_KI>0</Old_KI>
<Old_Algorithm>String</Old_Algorithm>
</Old_SIM>
<OrderPriority>5</OrderPriority>
<ParentKey/>
<ExternalSystemId>ExternalSysId-Upstream</ExternalSystemId>
</OrderLevelInfo>
<Products>
<ProductCode>CW</ProductCode>
<ProductDescription>Add subscriber features</ProductDescription>
<Action>NEW</Action>
<MSISDN>6425259999</MSISDN>
<ServiceAttributes>
<AttributeName>3WC</AttributeName>
<AttributeValue>1</AttributeValue>
</ServiceAttributes>
<ServiceAttributes>
<AttributeName>CLI</AttributeName>
<AttributeValue>1</AttributeValue>
</ServiceAttributes>
<ServiceAttributes>
<AttributeName>CWT</AttributeName>
<AttributeValue>0</AttributeValue>
</ServiceAttributes>
<Old_MSISDN>0</Old_MSISDN>
<Profile>None</Profile>
<NetworkID>None</NetworkID>
</Products>
</UPSTREAM_Order_Value>
...
Based on a value in the service request order (UPSTREAM_Order_Value in the example), the SrtTranslation.xsd file is called to perform a translation. At this point, the translation includes the work order's header portion.
Work order headers are also mapped based on the mapping defined in the message type. For example, if the incoming order contains a priority, purchase order number, and due date, these values will be included in the translation, provided they are incorporated in the SrtServiceModel.xsd file as lookups or are provided by means of a translation. For more information on work order headers, refer to the ASAP work order header and work order properties section of ASAP System Administrator's Guide.
The headers that are populated are independent of the service actions selected to appear on the work order.
In addition to work order headers, the SRT allows for any combination of service bundle parameters to be used to compose ASAP work order header parameters (for example, allowing for the upstream work order ID and external system ID to be used to generate a work order ID).
Oracle Professional Services or other qualified personnel are responsible for translations. Translations are defined in SrtTranslation.xsd. For more information, see "SRT Translation".
Parameter mappings can be achieved by means of XSLT conversions or lookups.
Lookups are performed by external instance adaptors. See "External Adapters" for more information.
After the Automation Transformation Framework produces the interim work order, the order is passed to the SRT to perform additional mappings, data lookups, and transformations. The interim work order is validated against the SRTServiceActivation.xsd file. For more information on this schema, refer to SRT Online Reference installed with the SRT software.
If the inbound work order contains a parameter that identifies a service bundle such as bundle ID, order type, or product code, as in the previous example, the SRT generates the service bundles and associated CSDLs (service actions) on the ASAP work order.
Inbound work orders can also contain service actions with parameter mappings and lookup definitions, without the need to model these as a service bundle. This allows the support of service actions directly during the translation of service orders from upstream.
The basic format of the XML that is validated against the schema appears as follows:
<?xml version="1.0" encoding="UTF-8"?>
<srtServiceModel xmlns="http://www.metasolv.com/ServiceActivation/2004/ ServiceBundle" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.metasolv.com/ServiceActivation/2004/ ServiceBundle
C:\ASAP\srt\srtServiceModel.xsd">
<serviceBundle>
<serviceBundleActionName>String</serviceBundleActionName>
<serviceBundleSpawning>
<parameterName>Text</parameterName>
<parameterValue>Text</parameterValue>
</serviceBundleSpawning>
<description>String</description>
<serviceAction>
<serviceActionName>String</serviceActionName>
<serviceActionSpawningLogic>
<alwaysCondition>1</alwaysCondition>
<expression>Text</expression>
</serviceActionSpawningLogic>
<serviceActionParameterMapping>
<parameterName>String</parameterName>
<parameterValue>String</parameterValue>
</serviceActionParameterMapping>
<includeOrderDataInResponse>true</includeOrderDataInResponse>
<description>String</description>
</serviceAction>
</serviceBundle>
<serviceAction>
<serviceActionName>C_CALLFWD_BUSY_ADD_POTS-OPTIONS</serviceActionName>
<serviceActionSpawning>
<parameterName>ServiceName</parameterName>
<parameterValue>CallForwardBusy</parameterValue>
</serviceActionSpawning>
<description/>
<serviceActionParameterMapping>
<parameterName>LINE</parameterName>
<externalParameter>
<parameterName>LINE</parameterName>
</externalParameter>
</serviceActionParameterMapping>
<serviceActionParameterMapping>
<parameterName>NE_ID</parameterName>
<externalParameter>
<parameterName>NEID</parameterName>
</externalParameter>
</serviceActionParameterMapping>
<serviceActionParameterMapping>
<parameterName>NPA</parameterName>
<externalParameter>
<parameterName>NPA</parameterName>
</externalParameter>
</serviceActionParameterMapping>
<serviceActionParameterMapping>
<parameterName>NXX</parameterName>
<externalParameter>
<parameterName>NXX</parameterName>
</externalParameter>
</serviceActionParameterMapping>
</serviceAction>
<querySpawningLogic>
<northBoundMapping>
<parameterName>String</parameterName>
</northBoundMapping>
<returnDataOnParameter>
<regularExpression>String</regularExpression>
<evaluateCondition>true</evaluateCondition>
</returnDataOnParameter>
</querySpawningLogic>
</srtServiceModel>
A more detailed sample of the XML appears in "Sample srt.xml". See also "Configuring srtServiceModel.xsd".
For detailed information on the schema, refer to SRT Online Reference.
For each service request on the service request order, the mapping definition is queried for the ordered set of possible service actions. The SRT then evaluates the spawning logic of each service action for input parameters (contained on the service request source). All true evaluations become service actions on the work order. All false actions are not added to the order. The service request must conform to srtServiceModel.xsd schema.
After the SRT has determined all work order service actions, the SRT performs parameter mapping. The SRT obtains all required and optional parameters from the service request source and adds them to the work order. If a parameter has no value, but a default is defined in srtServiceModel.xsd, the default is used. If there is no default for a missing required parameter, this is considered a translation error.
Once the mapping has completed, an orderValueRequest is created and is posted to the JSRP RequestQueue.
You need to ensure that the services (CSDLs and ASDLs) contained in the work order conform to the content and structure set out in the ServiceModel.xsd schema. ServiceModel.xsd defines the content and structure of one or more ServiceModel.xml files. This file ensures that the element hierarchy and document structure of ServiceModel.xml are correct and ensures element and attribute content adheres to the defined datatype.
ServiceModel.xsd contains the elements and structure to define:
Network actions (ASDLs) and their associated rollback conditions, parameters, and associated devices/software loads.
Device mappings (atomicDeviceMap), which provide a type definition to map ASDLs to network element types.
CSDLs and their associated rollback conditions, priorities, provisioning events, and mappings to ASDLs.
ServiceModel.xsd is fully annotated. Online documentation related to this schema is located in ASAP Online Reference. Detailed instructions on constructing a valid service model are contained in ASAP System Administrator's Guide. The ASAP_Home/samples/sadt directory contains sample service models.
The XML files you create that contain the service models can have any name, provided the <ServiceModel> element in the activation model deployment descriptor (activation-model.xml) correctly references it.
|
Note: SRT orders the service bundles (that is, CSDLs) according to the order of service request, rather than the configuration in the SRT. If CSDL level/priority is specified for an individual CSDL, the SARM still adjusts the CSDL execution order. Therefore, in order to ensure the execution of service bundles, CSDL level should not be used when modelling CSDLs. |
The processing of messages to and from the SRT and SRP involves the message queues illustrated in Figure 3-2.
The SRT and SRP process messages as follows:
The upstream XML is received in the SRT.MessageQueue (1). If the message is flawed, an error message is sent to the MessageErrorQueue (10).
SRT creates a CreateOrderByValueRequest, which is sent to the SRP (2).
The SRP sends the request to the SARM (3), which acknowledges the request.
The SRP sends a CreateOrderByValueResponse to the SRT.JSRPResponse queue (4).
The response is processed by the SRT (5) and is passed to the SRT.ResponseQueue (6).
All I/O events from the SARM that are sent to the SRP's XVTEventTopic (7). These events include soft error events, rollback events, timeout events, failure events, and complete events, among others.
These events are sent to the SRT (8). Event errors are sent to the EventErrorQueue (9).
Message logging in ASAP and the SRT is performed through log4j. For details on how to manage logging settings, refer to ASAP System Administrator's Guide.
Extended information such as work order properties, information parameters, global work order parameters, and CSDL return parameters can be returned on an ASAP event. The details returned are controlled by template entries.
For more information refer to the descriptions of the tbl_event_dataset, tbl_event_template, and srt_header_mapping tables in ASAP Developer's Guide.
Templates and parameters that are defined in the tbl_event_dataset and tbl_event_template tables are referenced as XPaths in the srt_header_mapping table. The SRT iterates through the table entries and runs the configured XPaths. The returned name/value pairs are added to the JMS header properties.
To configure the event templates to be applied to events and actions from the SRT, specify XPaths as in the examples below.
Examples
To return a specific information parameter on all event types, create a record with values similar to the following:
Name: 'IMSI'
Value: /*[name()=mslv-sa:completeEvent]//extendedWoProperties/extendedWoProperty[name='IMSI']/value
To return all extendedWoProperties on a completed event, create a record with values similar to the following:
Name: /*[name()=mslv-sa:completeEvent]//extendedWoProperties//name
Value: /*[name()=mslv-sa:completeEvent]//extendedWoProperties//value
SrtTranslation.xsd enables Oracle Professional Services personnel or other users to specify the mapping logic between the parameters contained in upstream XML files and those required for srtServiceModel.xsd. The parameters included in SrtTranslation.xsd must match those referenced in the XML service activation schema.
The translation takes the form of an XSLT transformation (identified in <translationScript>translation.xslt</translationScript> below). This translation produces an interim XML that is then passed to the SRT. This interim XML contains work order header information. The SRT initializes an ASAP work order and populates the ASAP work order header information using the SRT work order header and, in some cases, the SRT work order parameters that are pertinent to the provisioning process. In the previous example, work order header parameters are represented in the <OrderLevelInfo> element. As well, the <translationScript> element references the XSLT conversion, and the <lookup> elements identify the external adaptors. For more information, see "External Adapters".
<?xml version="1.0" encoding="UTF-8"?>
<northBoundIntegration xmlns="http://www.metasolv.com/ServiceActivation/2004/Translation" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.metasolv.com/ServiceActivation/2004/Translation
C:\ASAP\srt\SrtTranslation.xsd">
<translation>
<translationName>Text</translationName>
<translationScript>translation.xslt</translationScript>
<translationDispatch>
<xpath>
<xpath>//cm:ApplicationClientID</xpath>Foot 1
<xpathReturn>Upstream</xpathReturn>
</xpath>
</JMSHeader>
</translationDispatch>
</translation>
<externalMethodLibrary>
<fileName>Text</fileName>
<libraryName>Text</libraryName>
<type enabled="true" id="String">
<sql>Text</sql>
</type>
</externalMethodLibrary>
<lookup>
<lookupName>Text</lookupName>
<lookupType>Text</lookupType>
<inputParameter>
<parameterName>Text</parameterName>
<parameterValue>Text</parameterValue>
</inputParameter>
<outputParameter>
<parameterName>Text</parameterName>
<xpath>Text</xpath>
</outputParameter>
<cache id="String">
<scope>NODE</scope>
<timeout>60000</timeout>
<maxSize>100</maxSize>
</cache>
</lookup>
</northBoundIntegration>
XSLT conversions enable XML transformations by means of an XSLT stylesheet. The XSLT stylesheet takes the input XML document and converts it into an output XML document.
The XSLT conversion produces a document that conforms to the SRTServiceActivation.xsd schema.
The XSLT stylesheet identifies the following:
translationName – A unique name given to the translation script as an identifier.
translationScript – The XSLT file that implements the translation. This file must be included in the SAR file under SRT/Translations.
translationDispatch – The condition under which this translation is applied to the XML upstream document. It can either be based on a JMSHeader or be based on an XPath in the upstream document.
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="http://java.sun.com/products/oss/xml/ServiceActivation" xmlns:sa="http://java.sun.com/products/oss/xml/ServiceActivation" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:mslv-sa="http://www.metasolv.com/oss/ServiceActivation/2003" xmlns:co="http://java.sun.com/products/oss/xml/Common" xmlns:fo="http://www.w3.org/1999/XSL/Format"> <xsl:output method="xml" indent="yes" standalone="yes" media-type="xml"/> <xsl:template match="UPSTREAM_Order_Value">Foot 2 <createOrderByValueRequestFoot 3 xmlns="http://java.sun.com/products/oss/xml/ServiceActivation" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:mslv-sa="http://www.metasolv.com/oss/ServiceActivation/2003" xmlns:co="http://java.sun.com/products/oss/xml/Common"> <orderValue xsi:type="mslv-sa:ASAPOrderValue"> <apiClientId>SRT</apiClientId> <orderKey> <co:applicationContext> <co:factoryClass/> <co:url/> <co:systemProperties/> </co:applicationContext> <co:applicationDN>System/ENV_ID/ApplicationType/ServiceActivation/Application/1-0;4-7;ASAP/Comp/</co:applicationDN> <co:type>javax.oss.order.CreateOrderValue</co:type> <primaryKey> <xsl:value-of select="//@serviceOrderId"/>Foot 4 </primaryKey> </orderKey> <priority>3</priority> <requestedCompletionDate>2003-06-11T12:00:00</requestedCompletionDate>Foot 5 <services> <parameter> <name>NE_ID</name>Foot 6 <value>TOR_REM2</value> </parameter> <parameter> <name>DN</name>Foot 7 <value> <xsl:value-of select="//number"/> </value> </parameter> <parameter> <name>LDATA</name> <value>236</value> </parameter> <parameter> <name>LCC</name> <value>1</value> </parameter> <parameter> <name>LTG</name> <value>1</value> </parameter> <parameter> <name>LEN</name> <value> <mslv-sa:value> <xsl:value-of select="//len"/> </mslv-sa:value> </value> </parameter> </services> ...
The complete sample XSLT is located on "Sample translation.xslt".
If the incoming XML does not contain the required parameters, you can include lookups in SrtTranslation.xsd. For example, if the incoming work order does not include the parameter NE_ID, a lookup can determine the NE_ID based on another value on the work order, such as the IMSI.
lookupName – A unique lookup name.
lookupType – The lookup type. Can be SQL or Javascript or any other fully qualified Java class name.
inputParameter – Defines the name a parameter will be given when passed to the lookup and its value. These parameters can either be statically defined or dynamically derived from other lookups or the upstream order.
outputParameter – The parameter that is the result of the lookup and the XPath to use on the output of the lookup.
cache – Identifies the scope, timeout, and maximum size (in MB) of the lookup results.
Three levels of cache are supported and set using the scope child element
NONE: External instances are not cached.
NODE: (default) Lookup results are cached at the order level. This means the same lookup will be performed only once regardless of how many times it is called in the order. This setting is useful if it is moderately expensive to retrieve the external instance and the field referencing the external instance is a multi-instance node. Cached instances are only reused across multi-instance nodes if the actual resolved values of all parameters are identical and the lookup adapter class is the same.
SYSTEM: External instances are cached and reused system wide. This is useful if retrieving the external instance is expensive and it is performed frequently. Cached instances results are only reused if the actual resolved values of all parameters are identical and the lookup adapter class is the same.
If <scope> is set to SYSTEM, two additional elements are supported. <timeout> is the number of milliseconds for which a cached external instance is valid. <maxSize> is the maximum number of actual entries in the cache that will be maintained at any one time for this defined external instance. The default value for <timeout> is 15000 (15 seconds). The default value for <maxSize> is 50.
The SRT supports the splitting and concatenation of upstream parameters. Each lookup input parameter has an attribute sourceDocument, which indicates to the SRT which XML document source to use when resolving the input parameter value. If multiple lookups are chained together, the SRT ensures they are executed in correct sequence. The sourceDocument attribute defaults to ASAP_SRT_ORDER.
The <lookupParameterName> element indicates where to perform the lookup. This element can contain the value ASAP_SRT_ORDER or a lookup instance name.
The InputParameterType as defined in SrtTranslation.xsd appears as follows:
<xs:complexType name="InputParameterType">
<xs:sequence>
<xs:element name="parameterName">
<xs:annotation>
<xs:documentation>The name used to pass this parameter to the lookup implementation</xs:documentation>
</xs:annotation>
</xs:element>
<xs:choice>
<xs:element name="parameterValue">
<xs:annotation>
<xs:documentation>A static value for the parameter.</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="lookupParameterName">
<xs:annotation>
<xs:documentation>The name of a output parameter from either another lookup or the order.</xs:documentation>
</xs:annotation>
<xs:attribute name="sourceDocument" type="xs:string"/>
</xs:element>
</xs:choice>
</xs:sequence>
</xs:complexType>
The following is an example of SrtTranslation.xsd with multiple lookups chained together.
HOST_CLLI_LOOKUP is an SQL type lookup that takes one input parameter, NPANXX_CLLI, for its select SQL statement.
NPANXX_CLLI is the lookup result from NPANXX_CLLI_LOOKUP, which will concatenate the two input parameters NPANXX and CLLI.
NPANXX is the result from NPANXX_LOOKUP, and the CLLI is coming from order data parameter NE_ID.
NPANXX_LOOKUP takes the NPA and NXX from NPA_LOOKUP and NXX_LOOKUP and concatenates them as one single value. The NPA is the lookup result from NPA_LOOKUP and NXX is the lookup result from NXX_LOOKUP. Both of these are substrings from the order data parameter PHONE. At the end of lookup execution, the value will be populated back the order data parameter name HOST_CLLI.
<northBoundIntegration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.metasolv.com/ServiceActivation/2004/Translation"
xsi:noNamespaceSchemaLocation="C:\parameterMap.xsd">
<translation>
<translationName>POTSTranslation</translationName>
<translationScript>POTSTranslation.xslt</translationScript>
<translationDispatch>
<xpath>
<xpath>//@name</xpath>
<xpathReturn>POTS-Sample</xpathReturn>
</xpath>
</translationDispatch>
</translation>
<lookup>
<lookupName>NPA_LOOKUP</lookupName>
<lookupType>XPATH</lookupType>
<inputParameter>
<parameterName>xpath:function</parameterName>
<parameterValue>substring-before</parameterValue>
</inputParameter>
<inputParameter>
<parameterName>in:1</parameterName>
<lookupParameterName sourceDocument="ASAP_SRT_ORDER">TELEPHONE</lookupParameterName>
</inputParameter>
<inputParameter>
<parameterName>in:2</parameterName>
<parameterValue>3</parameterValue>
</inputParameter>
<outputParameter>
<parameterName>NPA</parameterName>
<xpath>/result/text()</xpath>
</outputParameter>
<cache id="NPA_LOOKUP_cache">
<scope>NODE</scope>
<timeout></timeout>
<maxSize></maxSize>
</cache>
</lookup>
<lookup>
<lookupName>NXX_LOOKUP</lookupName>
<lookupType>XPATH</lookupType>
<inputParameter>
<parameterName>xpath:function</parameterName>
<parameterValue>substring</parameterValue>
</inputParameter>
<inputParameter>
<parameterName>in:1</parameterName>
<lookupParameterName sourceDocument="ASAP_SRT_ORDER">TELEPHONE</lookupParameterName>
</inputParameter>
<inputParameter>
<parameterName>in:2</parameterName>
<parameterValue>3</parameterValue>
</inputParameter>
<inputParameter>
<parameterName>in:3</parameterName>
<parameterValue>3</parameterValue>
</inputParameter>
<outputParameter>
<parameterName>NXX</parameterName>
<xpath>/result/text()</xpath>
</outputParameter>
<cache id="NXX_LOOKUP_cache">
<scope>NODE</scope>
<timeout></timeout>
<maxSize></maxSize>
</cache>
</lookup>
<lookup>
<lookupName>NPANXX_LOOKUP</lookupName>
<lookupType>XPATH</lookupType>
<inputParameter>
<parameterName>xpath:function</parameterName>
<parameterValue>concat</parameterValue>
</inputParameter>
<inputParameter>
<parameterName>in:1</parameterName>
<lookupParameterName sourceDocument="NPA_LOOKUP">NPA</lookupParameterName>
</inputParameter>
<inputParameter>
<parameterName>in:2</parameterName>
<lookupParameterName source-document="NXX_LOOKUP">NXX</lookupParameterName>
</inputParameter>
<outputParameter>
<parameterName>NPANXX</parameterName>
<xpath>/result/text()</xpath>
</outputParameter>
<cache id="NPANXX_LOOKUP_cache">
<scope>NODE</scope>
<timeout></timeout>
<maxSize></maxSize>
</cache>
</lookup>
<lookup>
<lookupName>NPANXX_CLLI_LOOKUP</lookupName>
<lookupType>XPATH</lookupType>
<inputParameter>
<parameterName>xpath:function</parameterName>
<parameterValue>concat</parameterValue>
</inputParameter>
<inputParameter>
<parameterName>in:1</parameterName>
<lookupParameterName sourceDocument="NPANXX_LOOKUP">NPANXX</lookupParameterName>
</inputParameter>
<inputParameter>
<parameterName>in:2</parameterName>
<lookupParameterName sourceDocument="ASAP_SRT_ORDER">NE_ID</lookupParameterName>
</inputParameter>
<outputParameter>
<parameterName>NPANXX_CLLI</parameterName>
<xpath>/result/text()</xpath>
</outputParameter>
<cache id="NPA_LOOKUP_cache">
<scope>NODE</scope>
<timeout></timeout>
<maxSize></maxSize>
</cache>
</lookup>
<lookup>
<lookupName>HOST_CLLI_LOOKUP</lookupName>
<lookupType>SQL</lookupType>
<inputParameter>
<parameterName>jdbc:sqlStatement</parameterName>
<parameterValue>SELECT HOST_CLLI FROM tbl_clli_route WHERE NPANXX_CLLI = ?</parameterValue>
</inputParameter>
<inputParameter>
<parameterName>jdbc:dataSource</parameterName>
<parameterValue>System.en08.ApplicationType.ServiceActivation.Application.1-0;5-0;ASAP.Comp.SARMDataSource</parameterValue>
</inputParameter>
<inputParameter>
<parameterName>in:1</parameterName>
<lookupParameterName sourceDocument="NPANXX_CLLI_LOOKUP">NPANXX_CLLI</lookupParameterName>
</inputParameter>
<outputParameter>
<parameterName>HOST_CLLI</parameterName>
<xpath>/sql/row-set/row/col</xpath>
</outputParameter>
<cache id="HOST_CLLI_LOOKUP_cache">
<scope>NODE</scope>
<timeout></timeout>
<maxSize></maxSize>
</cache>
</lookup>
</northBoundIntegration>
The srtServiceModel.xsd schema identifies the service bundles, service actions (CSDLs), and spawning logic.
The <serviceBundle> element is described as follows:
serviceBundleName – The name of the service bundle.
serviceBundleSpawning – Identifies the condition under which this service bundle will be added to the work order. The condition is identified by the following:
parameterName
parameterValue
description – A description of the service bundle.
serviceAction – One or more service actions (CSDLs) that are included in the service bundle.
serviceActionName – The name of the service action (CSDL).
serviceActionSpawningLogic – For each CSDL associated with a service bundle, the SRT verifies whether the CSDL should be spawned.
When the SRT receives a service bundle and its associated service actions, the SRT refers to the following conditional logic:
Always generate the service action – The SRT always generates the service action for this service action.
Generate service action if parameter defined – The SRT generates a particular service action only if the stated parameter is defined.
Generate service action if parameter not defined – The SRT generates a particular service action only if the stated parameter is not defined.
Generate service action if parameter defined and equal – The SRT generates a particular service action only if the stated parameter is defined and has a particular parameter value.
serviceActionParameterMapping – Maps the parameter name on the interim order to the parameter name on the service action.
includeOrderDataInResponse – If TRUE, order data is included in SRT responses.
The <serviceAction> element is used to support service actions (CSDLs) directly during the translation of service orders from upstream.
serviceActionName – The name of the service action.
serviceActionSpawning – Identifies the condition under which this service action will be added to the work order. The condition is identified by the following:
parameterName
parameterValue
description – A description of the service action.
serviceActionParameterMapping – Maps the parameter name on the interim order to the parameter name on the service action.
includeOrderDataInResponse – If TRUE, order data is included in SRT responses.
The <querySpawningLogic> element is described as follows:
northBoundMapping – Enables the querying of completed orders for additional work order information.
parameterName – A parameter on the work order that identifies whether work order data is returned to an upstream system on completion.
returnDataOnParameter – Enables the querying of completed orders for additional work order information provided the evaluate condition is met.
regularExpression – The condition that must be met in order for the data on the work order to be returned to an upstream system.
evaluateCondition – The regularExpression must evaluate to this condition for the data on the work order to be returned to an upstream system.
A sample service model appears as follows:
<?xml version="1.0" encoding="UTF-8"?>
<srtServiceModel xmlns="http://www.metasolv.com/ServiceActivation/2004/ServiceBundle" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.metasolv.com/ServiceActivation/2004/ServiceBundle
C:\ASAP\srt\srtServiceModel.xsd">
<serviceBundle>
<serviceBundleActionName>String</serviceBundleActionName>
<serviceBundleSpawning>
<parameterName>Text</parameterName>
<parameterValue>Text</parameterValue>
</serviceBundleSpawning>
<description>String</description>
<serviceAction>
<serviceActionName>String</serviceActionName>
<serviceActionSpawningLogic>
<alwaysCondition>1</alwaysCondition>
<expression>Text</expression>
</serviceActionSpawningLogic>
<serviceActionParameterMapping>
<parameterName>String</parameterName>
<parameterValue>String</parameterValue>
</serviceActionParameterMapping>
<includeOrderDataInResponse>true</includeOrderDataInResponse>
<description>String</description>
</serviceAction>
</serviceBundle>
<querySpawningLogic>
<northBoundMapping>
<parameterName>String</parameterName>
</northBoundMapping>
<returnDataOnParameter>
<regularExpression>String</regularExpression>
<evaluateCondition>true</evaluateCondition>
</returnDataOnParameter>
</querySpawningLogic>
</srtServiceModel>
This section describes how to deploy data that includes SRT configuration information.
The deployment manager manually creates the directory structure on a UNIX machine and places relevant SRT configuration files within the directory structure as follows:
/META-INF/activation-model.xml // contains references to the location of files /SRT/srt.xml // populate core SRT tables and order translation bindings /SRT/SQL/Deploy/ // SQL scripts for table creation and insertion of custom data /SRT/SQL/Undeploy/ // SQL scripts for custom table/data deletion /SRT/Scripts/ // custom scripts /SRT/Translations/ // contains all xslt translations /SRT/java/lib/ // custom java lookups (jar files) /SRT/java/src/ // source code for custom java lookups /SRT/translation.xml
The activation_model.xml file identifies the components contained in the service activation archive to be deployed by the SADT. These components include, at a minimum, one or more service models, and the required State Tables or JInterpreter provisioning classes.
The SRT.xml file is an XML document that conforms to srtServiceModel.xsd.
The translation.xml file conforms to SrtTranslation.xsd.
When the directory structure has been created, the deployment manager runs the createSAR script, providing a path to the directory structure as a command-line argument.
The command is:
CreateSar [-help] sar_file_dir
The current directory must be the base from which the SAR file is made and it is the parent directory of the vendor directory. sar_file_dir specifies where you want to put the SAR file you have created. The SAR file name is generated based on the name in activationmodel.xml.
The createSAR script first checks for the existence of the /META-INF/activation-model.xml file to determine whether it references a specific path. If no path is found, the /SRT directory is assumed to be in the root directory of the specified path. A SAR file containing this optional path and directory structure are created. The /META-INF/activation-model.xml file is always placed in the SAR file off the root directory.
After the SAR file has been created, the deployment manager deploys the SAR file to ASAP using the SADT by providing the path to the SAR file and the SAR file name.
The SADT extracts configuration data from the SAR file by first checking for the existence of /META-INF/activation-model.xml inside the SAR file to see if it references a specific path. If no path is found, the /SRT directory is assumed to be in the root of the SAR.
The SADT takes the following subsequent actions:
Populates core SRT database tables and load translation bindings using the srt.xml file
Runs any custom sql scripts
Loads custom java scripts
Loads translations
Loads custom Java lookups
The SRT cache is automatically updated when it receives a new work order and a dirty cache is detected.
For more information on the SADT, refer to ASAP System Administrator's Guide.
This section provides details on the external adapters provided with SRT.
This adapter lets you integrate an external system with SRT to perform lookups against the database. This adapter runs SQL and uses the results in a translation.
jdbc:sqlStatement
The SQL statement to execute. Parameter placeholders can be indicated using a question mark (?). For example: SELECT NE_ID FROM NE_LOOKUP WHERE REGION = '?'. Each parameter can be passed with the name in:x, where x is the position of the parameter, starting from 1.
jdbc:dataSource
The JNDI name of the JDBC datasource in Oracle WebLogic Server.
in:x
The xth input parameter. Parameter numbering starts at 1.
<LookupType>
<lookupName>NE ID Lookup</lookupName>
<lookupType>SQL</lookupType>
<inputParameter>
<parameterName>jdbc:sqlStatement</parameterName>
<parameterValue>SELECT NE_ID FROM NE_ID_LOOKUP WHERE REGION = ? AND NE_TYPE = ?</parameterValue>
</inputParameter>
<inputParameter>
<parameterName>jdbc:dataSource</parameterName>
<parameterValue>com/sample/jdbc/CustomDataJDBC</parameterValue>
</inputParameter>
<inputParameter>
<parameterName>in:1</parameterName>
<lookupParameterName>REGION</lookupParameterName>
</inputParameter>
<inputParameter>
<parameterName>in:2</parameterName>
<lookupParameterName>HLR</lookupParameterName>
</inputParameter>
<outputParameter>
<parameterName>NE_ID</parameterName>
<xpath>NE_ID_LOOKUP/sql/row-set/row/NE_ID</xpath>
</outputParameter>
</LookupType>
This adapter lets you integrate the SRT with JavaScript to perform lookups, calculations, or validations against information that is located in the service request. This adapter runs an SRT server extension and uses the results as an external instance.
bsf:scriptEngine
The name of script engine.
bsf:script
The file name of the script.
bsf:expression
The expression for the script (optional).
bsf:line
The line number of the script to start (optional).
bsf:column
The column number of the script to start (optional).
bsf:typeEnabled
The boolean value for BSF enable types.
bsf:nodeName
The node name to return.
bsf_return
The Boolean value to enable a return.
in:x
The xth input parameter. Parameters are for the JavaScript function and parameter numbering starts at 1.
All other parameters are parameters for the JavaScript function.
Footnote Legend
Footnote 1: Ensure that the XPath contains a namespace prefix for use with the incoming schema (represented here by cm:).
|
 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|