| Oracle® Communications ASAP Cartridge Development Guide Release 7.2 E22486-01 |
|
 Previous |
 Next |
| Oracle® Communications ASAP Cartridge Development Guide Release 7.2 E22486-01 |
|
Previous |
Next |
This chapter describes how to create sample work orders for Oracle Communications ASAP cartridges.
At a high level, the process of configuring the interaction between provisioning and activation includes the following steps.
Familiarize yourself with the order data definition that is associated with an automated task in the predefined provisioning model (the ASAP cartridge). In this case, refer to the Provisioning system's order schema.
If you are using an XML editor like Oracle Communications Design Studio to view the schema, you can generate sample XML order data (see "About JSRP Sample OSS/J Work Orders").
Based on the automated task in the provisioning system, determine the service actions and atomic actions that are required to activate the service on the network elements (NEs). Table 15-1, "C_ADD_LINE mappings" shows the C-ADD_LINE mappings table and displays a sample service action with associated atomic actions.
Review the Activation schema ServiceModel.xsd file to review the components of a service model. For more information, see "About Cartridge XML Schemas".
To handle the order data from the Provisioning system, define one or more atomic actions and associated parameters of XML type (see "XML Parameters") so that the upstream order data is available to the network implementation (provisioning method) at run time. For an example of an atomic action parameter configuration, see Table 15-2, "A_ADD_CODES" and Table 15-3, "A_ADD_CODES Parameters".
You can define additional atomic action parameter labels of XPath type (see "XPath Parameters") using an XPath expression to control the spawning of ASDLs based on data of the XML document, provided that the evaluation of XPath expression resulted in a scalar value (see "About Atomic Action Spawning Logic"). You can also define atomic action parameter labels of XPath type to pass information of the XML so that the system integrators at the network element processor (NEP) level do not have to manipulate the XML document. Regardless of whether the you define atomic action parameter labels of XPath type, system integrators can retrieve information of the XML at the NEP level.
If you want to directly manipulate the XML at the NEP level, you can retrieve the raw XML as a Document Object Model (DOM) object through Java-enabled NEP's public Java APIs. Refer to the ASAP Online Reference.
You can use XPath technology to retrieve certain information of the XML document and then marshal the information to activate the NE.
Save the changes made to the service actions and atomic actions and then package the service model so that it can be deployed to the Activation system later through the SADT command line interface.
A work order that has been submitted for provisioning is processed as follows:
A work order enters the service request processor (SRP) or Java SRP (JSRP) server, where it is initialized. Information such as the due date, order number, and priority of the work order is fed into ASAP.
The SRP converts work order information such as universal service order codes (USOCs) and service offerings (SOFFs) into service requests appropriate for the Service Activation Request Manager (SARM). During this process, the SRP translates work order components to their corresponding Common Service Description Layer (CSDL) commands and parameters that are sent to the SARM.
After the work order enters the SARM, CSDL commands are mapped into a set of corresponding Atomic Service Description Layer (ASDL) commands.
ASDL commands and parameters are translated to switch-specific commands for execution on the network element (NE).
ASDL commands with their corresponding parameters are directed to the appropriate switch (network) elements.
Execution on the NE results in various responses that are communicated back to the SARM.
ASAP has the ability for structured XML order data to be passed from an upstream system through the Activation system and to be flowed back to Provisioning or another upstream system. Using this mechanism, the upstream system can include structured XML data on an Activation order. The process is as follows:
The user enters multi-instance data in the Provisioning application or using the XML API as part of a process flow.
The upstream system sends some or all of the order data. The upstream system performs the following actions:
Creates an OSS/J XML or Web service order request containing the order data information. Instead of marshalling the multi-instance order data into name/value pairs, the multi-instance XML order data is included as a parameter of the provisioning work order. See "Sample OSS/J Work Order with Conditional Logic Using XML Parameters" and "Sample OSS/J Work Order with Conditional Logic using XPath Parameters" for a sample activation work order with multi-instance XML order data.
Submits the OSS/J order request to the JSRP of the Activation system for provisioning.
When the incoming order request comes into the JSRP, the JSRP determines whether XML data is present as part of the request. The JSRP sends a commit acknowledgement to the Provisioning system if the work order is accepted in the Activation system.
|
Note: If a work order already exists in the Activation system with the same work order ID, the new work order is rejected.Any work order data that exceeds allowed data sizes will cause the work order to be rejected. |
The JSRP saves the XML order data to the SARM database and updates the order request with a reference ID that is returned by the database.
The SARM periodically picks up work orders and starts provisioning the work order.
When the work order is provisioned, the SARM loads the XML data from the database table by using the reference ID. The work order can contain the following types of XML parameters:
XML – If passing complex structured data downstream.
XPath – The SARM runs an XPath expression against the XML data in the following cases:
An XPath parameter is included in the CSDL spawning logic to determine whether an ASDL should be spawned or not.
An XPath parameter is used to spawn multiple instances of the same ASDLs depending on how many instances of XML elements are present in the work order.
If an XPath parameter is used as part of spawning logic, the evaluation of the XPath expression must result in a scalar value. The XPath parameter can also be used to conditionally run ASDLs multiple times depending on how many instances of XML elements present in the XML document. See "Sample OSS/J Work Order with Conditional Logic using XPath Parameters".
The SARM examines each ASDL and evaluates its corresponding spawning expression based on the work order parameters and CSDL parameters. This examination encompasses the data within the multi-instance XML order data from the Provisioning system by referring to the CSDL label of an XPath type parameter. In the case of an ASDL, if the spawning expression is evaluated to be true, the ASDL is scheduled for provisioning with its mapped ASDL parameters. For indexed ASDL parameters, the ASDL may be provisioned multiple times for multi-instance order data (see "Indexed Parameters" for more information). If the ASDL spawning expression evaluates to false, the ASDL is omitted from provisioning. See "About Atomic Action Spawning Logic".
Spawning can fail under the following circumstances:
The XML parameter that the XPath evaluates on is missing from the work order
The XML document that the XPath evaluates on is not well structured
The work order contains an invalid XPath expression
The evaluation of XPath expression results fails
The evaluation of an XPath expression results in a non-scalar value
The SARM provisions the ASDL to the NEP.
The NEP sends all ASDL parameters to the Java-enabled NEP.
If the ASDL contains an XML parameter, the Java-enabled NEP loads the XML data from the SARM database table and makes the raw XML available as the value of the XML parameter.
If the ASDL contains an XPath parameter, the Java-enabled NEP evaluates the associated XPath expression when the value of the XPath parameter is requested.
For more information on the XML and XPath parameter types, refer to the ServiceModel schema reference material, accessible through the ASAP Online Reference, "XML Parameters", and "XPath Parameters".
After the MML command is sent to the NE, custom provisioning code may optionally update the XML data with the NE's response by calling the Java-enabled NEP API (for example, returnXMLCSDLParm(name, value)) so that subsequent ASDLs may make use of this information. For more information, refer to the ASAP Online Reference.
If there is an update to the XML parameter, the Java-enabled NEP saves the modified XML data to a SARM database table and updates the parameter value with a new reference ID before returning the exit status of ASDL along with return parameters. These parameters include updated global, CSDL, and information parameters that are returned to the NEP (see "Return Parameter Types" for more information).
The NEP sends the ASDL's exit value and all returned parameter values for each returned parameter (see "Configuring Base Exit and User Exit Types").
The SARM continues to provision the next ASDL until the work order completes successfully or fails.
After the work order is finished provisioning, SARM publishes the work order event to various SRP servers (such as the JSRP) to indicate whether the work order has completed.
Upon receiving the work order event from the SARM server, the JSRP server publishes appropriate events (such as orderCompleteEvent, orderFailEvent) so that the automated task in the Provisioning system can update the state of the task and transition to the next task in the process flow (see "Configuring Service Action Fail and Complete Events").
Developer unit testing should occur as the cartridge is created so that all service actions, atomic actions, and code are fully tested. When unit testing is complete, execute all of the sample work orders that have been created against the cartridge to ensure that the desired outcome is achieved.
There are two ways to test a cartridge: using the SRP Emulator or the JSRP. Both of these components are available with the ASAP installation.
The SRP Emulator is an ASAP application server that fully emulates the complete behavior of any SRP application. It is used to create and transmit work orders to the SARM generally in the development and service modeling phases of project implementation. The SRP Emulator has no external system interface. Instead of externally generated work orders, the SRP Emulator employs user-defined test suites of work order definitions created in the SRP Emulator database for execution by the emulator. Orders in such test suites are created in Service Action format together with the appropriate parameters.
The file format is described using the following symbols and is detailed below.
WO <WO_ID> [WO Description] [ORG_UNIT <WorkGroup>] [ORIGIN <Originator>] [SRP_STAT <SRP Status>] [PRIORITY <Priority>] [SRQ_TYPE <Service Request Type>] [USERID <Security Userid on WO>] [PASSWORD <Security Password on WO>] [ASDL_TIMEOUT <atomic action Timeout Value>] [PARENT_WO <Parent WO (Related Order)>] [WO_TIMEOUT <WO Timeout Value>] [ASDL_RETRY_NUM <Number of atomic action Retries on WO>] [ASDL_RETRY_INT <Interval between atomic action Retries>] [WO_RBACK <Rollback WO upon Failure>] [ASDL_DELAY_FAIL <Treat Failures as Delayed Failures>] [DELAY_THRESHOLD <Delayed Failure Threshold>] [BATCH_GROUP <Batch group to which order belongs>]
[WO_PARM <ParmLbl> <ParmVlu>]... [WO_PARM <ParmLbl> <ParmVlu>]
[BATCH_WO_PARM <BatchNum> <ParmLbl> <ParmVlu>]... [BATCH_WO_PARM <BatchNum> <ParmLbl> <ParmVlu>]
[[Service Action <Service Action Command>] [PARM <ParmLbl> <ParmVlu>]... [PARM <ParmLbl> <ParmVlu>] [BATCH_PARM <BatchNum> <ParmLbl> <ParmVlu>]... [BATCH_PARM <BatchNum> <ParmLbl> <ParmVlu>]]... [[Service Action <Service Action Command>] [PARM <ParmLbl> <ParmVlu>]... [PARM <ParmLbl> <ParmVlu>] [BATCH_PARM <ParmLbl> <ParmVlu>]... [BATCH_PARM <ParmLbl> <ParmVlu>]][SUITE <Suite Name> [Suite description] [[WO_ID <WO_ID> [WO Delay] [WO Operation] [WO Due Date Offset] [Parent WO]
[WO Batch Group]]... [[WO_ID <WO_ID> [WO Delay] [WO Operation] [WO Due Date Offset] [Parent WO]
[WO Batch Group]]]
\
where:
<>: indicates a mandatory parameter
[]: indicated an optional parameter
...: indicates multiple occurrences of a parameter
SRP Emulator sample orders are created under a project test folder (Package Explorer view). As the tokens from the test file are positional parsed during loading, a very strict format is imposed (assuming space separation between tokens). To avoid mistakes, it is easier to build a sample test file from an old template, replacing the tokens and values with the new ones.
For more information about running a work order through the SRP Emulator, see ASAP Installation Guide.
The ASAP Java SRP (JSRP) component supports upstream requests in XML format bound by OSS/J standards. Using Design Studio, you can create activation OSS/J test cases, which generate work orders targeting the JSRP. These sample work orders can be sent from Design Studio, after connecting to an ASAP environment where the cartridge to be tested has been deployed. For details on how to create and run test cases from the Activation Test Cases editor, see the Oracle Communications Design Studio for Activation Help.
This section describes the structure of a work order that contains XML data.
Table 15-1 shows a CSDL (C-ADD_LINE) mapped to three ASDLs.
Table 15-1 C_ADD_LINE mappings
| Seq | ASDL | Condition | Condition Label | Condition Value | Expression |
|---|---|---|---|---|---|
|
1 |
A-ADD_POTS_LINE |
Always |
- |
- |
- |
|
2 |
A-ADD_CODES |
Equals |
A1141 |
BD/U2B |
- |
|
3 |
A-ADD_OPTIONS |
Equals |
A1141 |
BD/U2B |
- |
ASDLs 2 and 3 have spawning logic associated with them. A-ADD_CODES and A-ADD_OPTIONS are spawned only if A1141 is present in the upstream order with the value of BD/U2B.
For A-ADD_CODES (see Table 15-2), in addition to the standard parameters (NE_ID and DN), this ASDL expects the CSDL to contain parameters MY_OMS_DATA and MY_XML_DATA. These two parameters are of XML type.
Table 15-2 A_ADD_CODES
| CSDL Label | ASDL Label | DefaultFoot 1 | Parameter Type | Required |
|---|---|---|---|---|
|
NE_ID |
MCLI |
NA |
Scalar |
Yes |
|
MY_OMS_DATA |
OMS_DATA |
NA |
XML |
Yes |
|
MY_XML_DATA |
XML_DATA |
NA |
XML |
No |
|
DN |
DN |
NA |
Scalar |
Yes |
Footnote 1 The default is not applicable to XML and XPath
The CSDL parameter MY_OMS_DATA maps to the OMS_DATA ASDL parameter.
The following is a sample OSS/J XML work order createOrderByValueRequest that shows the configuration described in Table 15-1 and Table 15-3:
<?xml version="1.0" encoding="UTF-8"?>
<createOrderByValueRequest 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" xsi:schemaLocation="http://java.sun.com/products/oss/xml/ServiceActivation ../../xsd/XmlServiceActivationSchema.xsd http://www.metasolv.com/oss/ServiceActivation/2003 ../../xsd/ASAPServiceActivation.xsd">
<orderValue xsi:type="mslv-sa:ASAPOrderValue">
<apiClientId>SRL</apiClientId>
<orderKey>
<co:applicationContext>
<co:factoryClass/>
<co:url/>
<co:systemProperties/>
</co:applicationContext>
<co:type/>
<primaryKey>POTS-60</primaryKey>
</orderKey>
<priority>3</priority>
<requestedCompletionDate>2005-12-01T12:00:00</requestedCompletionDate>
<services>
<item xsi:type="mslv-sa:ASAPService">
<serviceKey xsi:type="mslv-sa:ASAPServiceKey">
<co:applicationContext>
<co:factoryClass/>
<co:url/>
<co:systemProperties/>
</co:applicationContext>
<co:applicationDN>System/DEV1/ApplicationType/ServiceActivation/Application/1-0;5-0;ASAP/Comp/</co:applicationDN>
<co:type/>
<primaryKey>C-ADD_LINE</primaryKey>
</serviceKey>
<mslv-sa:asdlRoute>TO_BE_DETERMINED</mslv-sa:asdlRoute>
<mslv-sa:serviceValues>
<mslv-sa:serviceValue xsi:type="mslv-sa:ASAPServiceValue">
<mslv-sa:name>NE_ID</mslv-sa:name>
<mslv-sa:value>TOR_REM1</mslv-sa:value>
</mslv-sa:serviceValue>
<mslv-sa:serviceValue>
<!-Xpath type parameter with CSDL parameter name "A1141"
and value "/exchange/a1141" '
<mslv-sa:name>A1141</mslv-sa:name>
<mslv-sa:xpathValue>/exchange/a1141</mslv-sa:xpathValue>Foot 1
</mslv-sa:serviceValue>
<mslv-sa:serviceValue>
<!-Xml type parameter with CSDL parameter name "MY_OMS_DATA" and value of order data from Provisioning '
<mslv-sa:name>MY_OMS_DATA</mslv-sa:name>Foot 2
<mslv-sa:xmlValue>
<exchange>Foot 3
<a1141>BD/U2B</a1141>
<codes>
<code>Foot 4
<poe>984</poe>
<decode>01246811</decode>
<pds_list>
<pds>2134</pds>
<pds>3265</pds>
<pds>1234</pds>
<pds>2345</pds>
<pds>4321</pds>
</pds_list>
</code>
<code>
<poe>984</poe>
<decode>01246812</decode>
<pds_list>
<pds>6789</pds>
<pds>9876</pds>
<pds>5432</pds>
<pds>2345</pds>
<pds>2354</pds>
</pds_list>
</code>
<code>
<poe>984</poe>
<decode>01246813</decode>
<pds_list>
<pds>3421</pds>
<pds>5632</pds>
<pds>1020</pds>
</pds_list>
</code>
…
</codes>
<errors>
<error>
<error_priority>1</error_priority>
<error_name>BROKEN PIPE</error_name>
<error_description>Lost switch connection</error_description>
</error>
…
</errors>
</exchange>
</mslv-sa:xmlValue>
</mslv-sa:serviceValue>
<mslv-sa:serviceValue xsi:type="mslv-sa:ASAPServiceValue">
<mslv-sa:name>DN</mslv-sa:name>
<mslv-sa:value>6742727</mslv-sa:value>
</mslv-sa:serviceValue>
<mslv-sa:serviceValue xsi:type="mslv-sa:ASAPServiceValue">
<mslv-sa:name>LATA</mslv-sa:name>
<mslv-sa:value>236</mslv-sa:value>
</mslv-sa:serviceValue>
<mslv-sa:serviceValue xsi:type="mslv-sa:ASAPServiceValue">
<mslv-sa:name>LCC</mslv-sa:name>
<mslv-sa:value>1</mslv-sa:value>
</mslv-sa:serviceValue>
<mslv-sa:serviceValue xsi:type="mslv-sa:ASAPServiceValue">
<mslv-sa:name>LTG</mslv-sa:name>
<mslv-sa:value>1</mslv-sa:value>
</mslv-sa:serviceValue>
<mslv-sa:serviceValue xsi:type="mslv-sa:ASAPServiceValue">
<mslv-sa:name>LEN</mslv-sa:name>
<mslv-sa:value>1010101</mslv-sa:value>
</mslv-sa:serviceValue>
</mslv-sa:serviceValues>
</item>
</services>
<mslv-sa:parentKey>
<co:applicationContext>
<co:factoryClass/>
<co:url/>
<co:systemProperties/>
</co:applicationContext>
<co:applicationDN/><co:applicationDN/>
<co:type/>
<primaryKey/>
</mslv-sa:parentKey>
<mslv-sa:origin>ASC Test Orders</mslv-sa:origin>
<mslv-sa:organizationUnit>POTS</mslv-sa:organizationUnit>
<mslv-sa:timeout>-1</mslv-sa:timeout><!-- Use Default -->
<mslv-sa:secureData>true</mslv-sa:secureData>
<mslv-sa:maximumDelayFail>0</mslv-sa:maximumDelayFail>
<mslv-sa:rollbackIfFail>false</mslv-sa:rollbackIfFail>
<mslv-sa:batchGroup/>
<mslv-sa:asdlTimeout>-1</mslv-sa:asdlTimeout> <!-- Use Default -->
<mslv-sa:asdlRetry>5</mslv-sa:asdlRetry>
<mslv-sa:asdlRetryInterval>120</mslv-sa:asdlRetryInterval>
<mslv-sa:asdlDelayFail>false</mslv-sa:asdlDelayFail>
<mslv-sa:externalSystemId/>
<mslv-sa:srqAction>ADD</mslv-sa:srqAction>
<mslv-sa:command>UPDATE</mslv-sa:command>
<mslv-sa:orderParameters>
<mslv-sa:orderParameter>
<mslv-sa:name>ACCT</mslv-sa:name>
<mslv-sa:value>1764571</mslv-sa:value>
</mslv-sa:orderParameter>
</mslv-sa:orderParameters>
<mslv-sa:infoParms/>
<mslv-sa:extendedWoProperties/>
</orderValue>
</createOrderByValueRequest>
After the MML command is sent to the NE, a system integrator can persist the response from the NE in the Activation system so that the upstream system can retrieve information from the NE's response. The response from the NE may also update the XML order data as part of Activation work order. The response from the NE can be used by:
Subsequent ASDLs
To send information between ASDLs, system integrators can call JNEP's API (such as returnXMLCSDLParm(name, value), returnGlobalParam(name, value)) to return CSDL parameters or global work order parameters.
Consider the sample work order: A-ADD_CODES can pass an XML document to subsequent ASDL A-ADD_OPTION by calling returnXMLCSDLParm() function with the MY_XML_DATA parameter, where the value of parameter is the XML document. For example:
<switch> <a1141>BD/U2B</a1141> <options> <feature>1100</feature> <feature>3232</feature> <feature>2000</feature> </options> </switch>
The Provisioning system to update the order in Provisioning
Any upstream system to update the NEs status
This section describes the structure of a work order that contains XPath parameters.
Table 15-3 describes the same ASDL using XPath parameters.
Table 15-3 A_ADD_CODES Parameters
| CSDL Label | ASDL Label | DefaultFoot 1 | Parameter Type | Required | Dependent ASDL LabelFoot 2 |
|---|---|---|---|---|---|
|
NE_ID |
MCLI |
NA |
Scalar |
Yes |
- |
|
MY_OMS_DATA |
OMS_DATA |
NA |
XML |
Yes |
- |
|
MY_XML_DATA |
XML_DATA |
NA |
XML |
No |
- |
|
A1141 |
A1141 |
NA |
XPath |
Yes |
OMS_DATA |
|
CODE++ |
CODE |
NA |
XPath |
No |
OMS_DATA |
|
DN |
DN |
NA |
Scalar |
Yes |
- |
Footnote 1 The default is not applicable to XML and XPath
Footnote 2 Applies only to the XPath type
The following sample code illustrates how the service model for this ASDL may appear. Note the parameter types.
<?xml version="1.0" encoding="UTF-8"?> <serviceModel xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:sam="http://www.metasolv.com/ServiceActivation/2003/ServiceModel" xmlns="http://www.metasolv.com/ServiceActivation/2003/ServiceModel" xmlns:fo="http://www.w3.org/1999/XSL/Format"> <description>Adds a line.</description>
<atomicService name="A_ADD_CODES" xsi:type="AtomicServiceType">
<description>Adds codes.</description> <rollbackService enable="false"> </rollbackService> <sendParameterCount>false</sendParameterCount> <parameter name="MCLI" xsi:type="SimpleParameterType">
<description>Host NE identifier.</description> <required>true</required> <default/> <parameterValueMap>NE_ID</parameterValueMap>
</parameter> <parameter name="OMS_DATA" xsi:type="XMLParameterType">
<description>OMS data.</description> <required>true</required> <default/> <parameterValueMap>MY_OMS_DATA</parameterValueMap>
</parameter> <parameter name="XML_DATA" xsi:type="XMLParameterType">
<description>XMLDATA.</description> <required>false</required> <default/> <parameterValueMap>MY_XML_DATA</parameterValueMap>
</parameter> <parameter name="A1141" xsi:type="XPathParameterType">
<description>Description.</description> <required>true</required> <default/> <parameterValueMap>A1141</parameterValueMap> <dependentXMLParameter>OMS_DATA</dependentXMLParameter>
</parameter> <parameter name="CODE" xsi:type="XPathParameterType">
<description>Code.</description> <required>false</required> <default/> <parameterValueMap>CODE#</parameterValueMap>
</parameter> <parameter name="DN" xsi:type="SimpleParameterType">
<description>DN.</description> <required>true</required> <default/> <parameterValueMap>DN</parameterValueMap>
</parameter>
In A_ADD_CODES Parameters table, OMS_DATA is an ASDL parameter that is associated with two network action labels that invoke the evaluation of an XPath expression. As a result, if the CSDL contains a parameter A1141, the SARM attempts to locate a set of data in the order designated by <a1141>. The incoming XML must identify that specific CSDL parameter name and its XPath value, an example of which follows:
<mslv-sa:serviceValue>
<!-Xpath type parameter with CSDL parameter name "A1141" and value "/exchange/a1141" ' <mslv-sa:name>A1141</mslv-sa:name> <mslv-sa:xpathValue>/exchange/a1141</mslv-sa:xpathValue>
The XML should have an XPath name and value declaration for each CSDL parameter that is subject to an XPath expression.
If the A1141 parameter exists on the order, ASAP will apply the data at the specified location in the file, in the <a1141> element:
<exchange>
<a1141>
...
</a1141>
The spawning logic for A-ADD_CODES (described in C-ADD_LINE mappings table) requires that a condition value of BD/U2B be defined for parameter a1141 for that ASDL to be spawned. For this ASDL to be spawned, the incoming XML must contain data formulated as follows:
<exchange>
<a1141>BD/U2B</a1141> <codes>
<code>
...
</code>
...
</codes>
For parameter CODE, the ++ at the end of service action label CODE++ indicates that at run time, the current network action may be spawned multiple times depending on how many instances of "exchange/codes/code" are present in the work order. In addition, the network action label CODE for each A-ADD_CODE, execution will have a different value.
In the following example, the ASDL is spawned based on the evaluation of the XPath expression, and the order data contained in the exchange/codes/code location is passed to the NE.
<exchange>
<a1141>BD/U2B</a1141> <codes>
<code>
<poe>984</poe> <decode>01246811</decode> <pds_list> <pds>2134</pds> <pds>3265</pds> <pds>1234</pds> <pds>2345</pds> <pds>4321</pds> </pds_list>
</code> <code>
…
You can create Web service work orders by taking the OSS/J work order information generated using Design Studio and placing it within this Web Service sample wrapper:
<?xml version="1.0" encoding="UTF-8"?>
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<env:Header>
<wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" env:mustUnderstand="1">
<wsse:UsernameToken xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="unt_AF6po7ocfkMUDzde">
<wsse:Username>username</wsse:Username>
<wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">password</wsse:Password>
</wsse:UsernameToken>
</wsse:Security>
</env:Header>
<env:Body>
<m:order_type xmlns:m="http://xmlns.oracle.com/communications/activation/asap/webservices">
OSS/J_work_order
</m:order_type>
</env:Body>
</env:Envelope>
where:
username is the user name for the Web service user-defined in the ASAP WebLogic server instance.
password is the password for the Web service user-defined in the ASAP WebLogic server instance.
order_type is the type of work order sent.
OSS/J_work_order is the OSS/J work order information. When you add the work order information, do not include the XML header information (<?xml version="1.0" encoding="UTF-8"?>) because this has already been provided in the sample. Ensure that there are no namespace conflicts.
Always create sample work orders that test all of the service action and atomic action commands in the cartridge. This includes work orders that test for sunny day as well as rainy day scenarios. Though it may not be possible to exercise all of the method logic (for example, all NE response combinations), mainstream paths (both common success and failure paths) should be invoked by the test suite.
Use consistent values for the parameters when creating sample work orders. This is useful when using the OCA GUI to query on orders by the field names and distinguish other orders from the sample cartridge orders.
ORG_UNIT MetaSolv ORIGIN TEST
The value of the SRQ_TYPE variable should be appropriately set depending on the context of the work order (A – add, R – remove, C – change/update, Q - query).
SRQ_TYPE = A/R/C/Q
Each atomic action-command has associated parameters that are sent to the NEP by the SARM when the ASAP is selected to provision.
|
Note: An atomic action parameter value must be specified at the time of provisioning. If the parameter is not supplied at the time of provisioning, a SARM translation error results. |
The following errors can occur during atomic-action-to-service-action translation:
No service action configuration in database – The SARM receives a service action whose configuration is unknown and rejects the work order.
No service action To atomic action translation in database – The service action is skipped because there is no work order to be done.
No atomic action configuration in database – The SARM shuts down upon finding that an atomic action configuration is missing while loading the atomic action configurations associated with each service action. If all atomic action configurations are not defined, the work order being provisioned is failed.
Atomic action parameters not specified – The SARM treats mandatory and optional parameters differently. If a mandatory atomic action parameter is not translated successfully with a name-value pair in the work order (empty string for the value is allowed), and no default value is available in the database, the work order is failed. The reason can be the label is missing in the work order. If the parameter is optional, order provisioning continues.
No atomic action to State Table translation in database – If an entry for an atomic action is missing in the atomic-action-to State-Table translation table, the NEP cannot determine the State Table associated with the atomic action and fails the atomic action.
No State Table for atomic action defined in database – If the entries for a State Table are missing in the atomic-action-To-State-Table translation table, the NEP cannot execute the State Table associated with the atomic action and fails the atomic action.
On startup, the SARM ensures that the following tables exist and have been populated:
Service action configuration table
Service-action-to-atomic-action translation table
Atomic action configuration table
Atomic action parameter table
If any of these tables is empty, the SARM shuts down.
The following errors can occur during atomic action to service action translation:
No Service Action configuration in database – The SARM receives a service action whose configuration is unknown and rejects the work order.
No Service Action To Atomic Action translation in database – The service action is skipped because there is no work order to be done.
No Atomic Action configuration in database – The SARM shuts down upon finding that an atomic action configuration is missing while loading the atomic action configurations associated with each service action. If all atomic action configurations are not defined, the work order being provisioned is failed.
Atomic Action parameters not specified – The SARM treats mandatory and optional parameters differently. If a mandatory atomic action parameter is not translated successfully with a label-value pair in the work order (empty string for the value is allowed), and no default value is available in the database, the work order is failed. The reason can be the label is missing in the work order. If the parameter is optional, order provisioning continues.
No Atomic Action to State Table translation in database – If an entry for an atomic action is missing in the atomic action to State Table Translation table, the NEP cannot determine the State Table associated with the atomic action and fails the atomic action.
No State Table for Atomic Action defined in database – If the entries for a State Table are missing in the atomic action To State Table Translation table, the NEP cannot execute the State Table associated with the atomic action and fails the atomic action.
Footnote Legend
Footnote 1: Identifies an XPATH, where the associated ASDL is spawned only if A1141 is present in the XML order data with the value of BD/U2B.
|
 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|