Skip Headers
Oracle® Communications Order and Service Management Developer's Guide
Release 7.2.2

E35419-02
Go to Documentation Home
Home
Go to Table of Contents
Contents
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

4 Using OSM Web Services

This chapter describes Oracle Communications Order and Service Management (OSM) Web Services, which provides the primary interface for in-bound order operations such as creating or canceling an order.

About Web Services

Web services support interoperable machine-to-machine interaction over a network. Web services are Web APIs that can be accessed over a network, such as the Internet, and run on a remote system hosting the requested services, as is the case with OSM. Web service interfaces are described by the Web service definition language (WSDL).

WSDL is an XML-based language that is used in combination with simple object access protocol (SOAP) and XML Schema to provide Web services over the Internet. A client program connecting to a Web service can read the WSDL to determine what operations are available on the server. Any special data types used are embedded in the WSDL file in the form of XML Schema. The client can then use SOAP to actually call one of the operations defined in the WSDL.

About OSM Web Services

The OSM Web Services provide the primary interface for in-bound order operations such as creating, updating, or canceling an order. Web Services are typically initiated from Customer Relationship Management (CRM) systems and other order sources that need to create and manage orders in OSM. OSM Web Services use the SOAP standard.

The OSM Web Service operations are defined in WSDL files. The operations are listed below, and grouped by WSDL file.

OrderManagement.wsdl

OrderManagementDiag.wsdl

These services can be accessed using HTTP, HTTPS, or JMS as the transport protocol. JMS is a reliable, asynchronous messaging transport with guaranteed delivery while HTTP is synchronous and less reliable.

Request Validations

All Web Service requests are validated by the server based on the rules defined in the schema files. If a validation error is encountered, the server returns a fault message detailing the validation error so it can be resolved.

Accessing the WSDL Files

OSM Web Services are part of the OSM installation. The OSM WSDL files and supporting schema files (XSD files) are located in the OSM_home/SDK/WebService/wsdl directory.

Alternatively, you can access the OSM WSDL by entering the following in your Web browser after you have installed, configured, and deployed the OSM server:

http://server:port/OrderManagement/webservice?WSDL

where server is the specific server on which the application is deployed and port is the port on which the application listens. Users who access the WSDL this way must be configured in the WebLogic console with usernames and passwords and must belong to the group OMS_ws_api.

Using the SOAP Standard Message Format

OSM Web Services use the SOAP standard message format, which includes a header and a body.

Message Header

OSM Web Services require that security related information be provided in the message header. The user name and password for the Web Service authorized user must be included in each request using the elements <wsse:UserName> and <wsse:PasswordText>, as shown in Example 4-1.

Example 4-1 Message Header

<soapenv:Header>
    <wsse:Security soapenv:mustUnderstand="1" xmlns:wsse="http://docs.oasis-
     open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
        <wsse:UsernameToken wsu:Id="UsernameToken-4799946" xmlns:wsu="http://docs. 
         oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
            <wsse:Username>administrator</wsse:Username>
            <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-
             200401-wss-username-token-profile-1.0 
             #PasswordText">administrator</wsse:Password>
        </wsse:UsernameToken>
    </wsse:Security>
</soapenv:Header>

Message Body

The message body contains the data payload. The data payload varies depending on the specific request, as shown in Example 4-2.

Example 4-2 Message Body

<soapenv:Body>
    <createOrderBySpecification>
        <specification>
            .
            .
            .
        </specification>
    </createOrderBySpecification>
</soapenv:Body>
 

Response messages include a data payload containing the result of the method call.

Testing

Test OSM Web Services with software such as SoapUI or HermesJMS. Information on such open source test software is available on the internet.

Note:

With OSM 7.2, the context-root for OSM applications changed to /OrderManagement. OSM redirects requests specifying the old URIs to the current ones. However, soapUI 2.5.1 does not correctly handle redirects. soapUI3.x or above correctly handles redirects.

Note:

If you are using soapUI for testing in a clustered WebLogic environment, enable preemptive authentication in soapUI by selecting Preferences, then HTTP Settings, then Authenticate Preemptively.

Without this, soapUI sends requests without authentication. The request is rejected and then resent with authentication. Because of OSM's load balancing approach in a clustered WebLogic environment, the second request is sent to a different managed server, distorting load balancing. For example, if a cluster has only two managed servers and you employ round-robin load balancing, all authenticated requests will be sent to the same managed server.

Regardless of the software used to test OSM Web Services, you must ensure the clocks are synchronized between the test client and the server hosting the Web services. The synchronization can be done manually, or by using Network Time Protocol (NTP). The following errors are encountered if the clocks are not synchronized:

  • Failing to submit order to server_name server from my local system.

  • Security token failed to validate. weblogic.xml.crypto.wss. SecurityTokenValidateResult@11f081b[status false][msg UNT Error:Message Created time past the current time even accounting for set clock skew.

Note:

Starting with OSM 7.2, order IDs are allocated in blocks. For OSM running on a standalone database, there is no visible impact. However, if OSM is running on an Oracle RAC database, Order IDs are assigned from different blocks, one for each Oracle RAC instance. This means that when orders are submitted, the Order IDs may not be sequential.

Order States and Transitions

Several of the OSM Web Service operations initiate a transition from one order state to another. For example, CancelOrder initiates a transition from either an in progress or suspended order state to the cancelling order state. Any transition that occurs within a Web Service operation is described in the Expected Outcome section for that particular operation as described in "About OSM Web Service Operations". To learn more about order states and their transitions, see OSM Concepts.

Web Services Sample

Your OSM installation provides a Web Service sample that demonstrates how OSM web services are called. The sample is available in the OSM_home/SDK/Samples/Web Services directory. The sample includes both HTTP and JMS clients, and demonstrates the use of the web service operations:

  • CreateOrderBySpecification

  • GetOrder

  • UpdateOrder

The GetOrder and UpdateOrder operations depend on the order ID that is provided in the CreateOrderBySpecification response. Before you can run the sample, you must configure it to reflect your environment. See the ReadMe.txt file for detailed instructions on configuring, building, and running the sample.

About OSM Web Service Operations

The remaining sections of this chapter describes each Web Service operation, and includes the following information per operation:

Parameters

The parameters defined by each Web Service are not provided in this documentation because the information is available in the XSD files provided with your OSM installation. For information on determining the input and output parameters for any given Web Service, see "Navigating WSDL and XSD Files".

Fault Types

The possible fault types that each Web Service may throw is not provided in this documentation because the information is available in the WSDL files provided with your OSM installation. For information on determining the fault types that any given Web Service may throw, see "Navigating WSDL and XSD Files".

Request and Response Examples

Request and response examples for each Web Service is not provided in this documentation. However, several request and response examples are provided, which you can parlay to other Web Services. See "Request and Response Examples", which also provides information on how to generate XML examples for any given Web Service operation.


Web Service Operations Used for Order Management

This section describes Web service operations used for order management. This includes creating, retrieving, updating and cancelling an order. Order management operations are defined in the OrderManagementWS.wsdl file.

Each operation lists preconditions that must exist for a successful invocation of the Web Service operation. However, the following preconditions are common to all operations, so they are listed here rather than repeated for each operation:


CreateOrderBySpecification

This operation creates a service order.

Preconditions

Expected Outcome

The order is created and processing begins. If the newly created order is matched against an existing order (based on the key defined on the order's specification), then this new order is an amendment to an existing order, and information regarding the amended order and status of the amendment is returned.

If the newly created order is not an amendment, the order is transitioned to the open.running.in_progress state by specifying StartOrder=true.

Alternate Outcome with Start Order Set to False

The order is created but processing does not begin. The order is in the open.not_running.not_started state. The order can be further updated and started through the UpdateOrder operation.

Attachments

You can add attachments through the createOrderBySpecification operation. Attachments are added by populating the Remark element, which provides a place to define a text remark as well as an attachment. The attachment is added by populating the Attachment element, which is a child element of Remark. Within the Attachment element, you can define a sequence of file names and their corresponding file types. For additional information, see the OrderManagementWS.xsd file, which defines these elements.

Reference Nodes

Reference nodes are pointers to values contained in different data nodes, and they enable you to create information once and reuse it in multiple locations in your data model. You set up reference nodes at order creation time.

To set up reference nodes in an order, when creating the order, you must explicitly give the referred-to field an index, and then refer to it with {#} in the reference. For an example that demonstrates how to set up reference nodes at order creation time as part of coding the automation plug-ins that call the CreateOrderBySpecification Web service operation, see "Request Example - Setting Up Reference Nodes".


CreateOrder

This operation creates a new order.

Preconditions

Expected Outcome

The order is created and processing begins. The order is transitioned to the open.running.in_progress state by specifying StartOrder=true.


FindOrder

This operation finds a set of orders that match all the conditions defined in the select clause. The Select element specifies the information returned in the results. Results can contain a combination of flexible headers and task data. The calling user must belong to a role with permissions to view the order. If the user does not have the permission, no data is returned.

Note:

Flexible Headers are user defined columns which are displayed while viewing order details. Flexible headers are set by OSM administrators. See OSM XML API Developer's Guide for more details on Queries and Flexible Headers.

Generally the path of a flexible header is /<WebService>/<ElementGroup>/<FlexibleHeader>. Note that /<WebService> is preceded by a single slash (/). A double slash (//) or no slash will yield different results. See OSM XML API Developer's Guide for details on how to query and retrieve orders that include available flexible headers using the XML API.

Preconditions

Expected Outcome

Order data that meets specified selection criteria is returned in the specified sequence and is viewed through the specified filter.


GetOrder

This operation retrieves an order. A summary of the order is returned, along with the detailed order data based on a specified order view template. See also"GetOrder Examples".

Parameters

OrderId

The identification of the order to be retrieved.

View

The name of the view (query task) used to determine the order data that is returned. You must associate the task data you want to return to a role in the Oracle Communications Design Studio Order editor Permissions Query Task sub tab and set a query task with the data to be returned as the Default query task.

The following parameters are optional:

RemarkFilter

Controls how remarks and attachments are returned.

RetrieveRemarks

Set to true if remarks and associated attachments should be returned.

AttachmentFilter

If RetrieveRemarks is set to true, zero or more filters (FileNameMatch, MinSize, MaxSize, Format) may control how attachments are returned. Attachment filters are processed in the order they are provided. If no filters are provided, then no attachments are returned.

Preconditions

Expected Outcome

The order summary and detail are returned. If the order contains any remarks or attachments, they are returned based on the filters set on the request.


UpdateOrder

This operation allows order data to be updated, and allows orders that have been created but not started (in the open.not_running.not_started state) to be started.

The updateOrder operation defines different ways to update the order:

For samples of updateOrder, see OSM_home/SDK/Samples/WebService. You must use the OSM installer to install the SDK sample files.

Preconditions

Note:

These preconditions apply if the order is in the not_started state. You can update the order data when the order is running, if the order life-cycle policy permissions allow it for the task you want to update.

You must associate the task data you want to update to a role in the Design Studio Order editor Permissions Query Task sub tab and set a query task with the required data as the Default query task. You can associate only one role per task in the Order editor. The user specified in the UpdateOrder header must be a member of this role.

Expected Outcome

The order's data is updated successfully but remains in the open.not_running.not_started state. The order can be further updated or started by additional calls to the UpdateOrder operation.

Attachments

You can add attachments through the updateOrder operation. Attachments are added by populating the Remark element, which provides a place to define a text remark as well as an attachment. The attachment is added by populating the Attachment element, which is a child element of Remark. Within the Attachment element, you can define a sequence of file names and their corresponding file types. For additional information, see the OrderManagementWS.xsd file, which defines these elements.


SuspendOrder

This operation suspends an order thereby preventing work items associated with the order from being processed. A suspended order must be resumed before its associated work items can once again be processed.

Preconditions

Expected Outcome

The order is successfully transitioned to the open.not_running.suspended state. Users are restricted from processing work items associated with the suspended order.

Alternate Outcome with Grace Period

The order enters into a grace period that allows all work items that are currently accepted to be processed. During the grace period, the current order state remains open.running.in_progress and the target state is set to open.not_running.suspended. The order will complete the transition to the open.not_running.suspended state when all accepted work items for the order are completed or the grace period expires, whichever comes first. New work items cannot be accepted during the grace period.

The grace period may be configured on the order state policy and/or specified on this call.


ResumeOrder

This operation resumes an order that is currently suspended or cancelled so that work items associated with the order are allowed to be processed.

Preconditions

Expected Outcome

The order is successfully transitioned to the open.running.in_progress or open.not_running.not_started state. Authorized users may process work items associated with the specified order.


CancelOrder

This operation cancels an order. All outstanding work items associated with the order are deleted, and all complete work items associated with the order are compensated (undone).

Preconditions

Expected Outcome

The order is successfully transitioned to the open.running.compensating.cancelling state. Incomplete work items associated with the order are deleted. Completed work items associated with the specified order are compensated. Once compensation completes, the order is transitioned to open.not_running.cancelled.

Alternate Outcome with Grace Period

The order enters into a grace period that allows all work items that are currently accepted to be processed. During the grace period, the current order state remains at its current value (open.running.in_progress or open.not_running.suspended) and the target order state is set to open.running.compensating.cancelling. The order will complete the transition to the open.running.compensating.cancelling state when all accepted work items for the order are completed or the grace period expires, whichever comes first. New work items cannot be accepted during the grace period. The grace period may be configured on the order life-cycle policy and/or specified on this call.


AbortOrder

This operation aborts an order, and aborts all work items associated with the order. Authorization for this transaction is controlled by the order life-cycle policy associated with the order's specification. See the ABORT_ORDER transaction in orderStatePolicy.xsd.

Preconditions

Expected Outcome

The order is successfully transitioned to the closed.aborted state. Users are restricted from processing the aborted order.


FailOrder

This operation fails an order. A failure must be resolved before the order can proceed any further. Authorization for this transaction is controlled by the order life-cycle policy associated with the order's specification. See the FAIL_ORDER transaction in orderStatePolicy.xsd.

Preconditions

Expected Outcome

The order is successfully transitioned to the open.not_running.failed state. Users are restricted from processing work items associated with the failed order.

Alternate Outcome With Grace Period

The order enters into a grace period that allows all work items that are currently accepted to be processed. During the grace period, the current order state remains open.running.in_progress and the target state is set to open.not_running.failed. The order will complete the transition to the open.not_running.failed state when all accepted work items for the order are completed or the grace period expires, whichever comes first. New work items cannot be accepted during the grace period. The grace period may be configured on the order state policy or specified on this call.


ResolveFailure

This operation transits an order that is currently failed back to its state prior to entering the current failed state. Authorization for this transaction is controlled by the order life-cycle policy associated with the order's specification. See the MANAGE_ORDER_FALLOUT transaction in orderStatePolicy.xsd.

Preconditions

Expected Outcome

The order is successfully transitioned to its previous state.


Web Service Operations Used for Problem Order Diagnosis

This section describes Web service operations used for diagnosing problem orders. This includes getting order process history, compensation history and compensation details. Order diagnoses operations are defined in the OrderManagementDiag.wsdl.wsdl file


GetOrderProcessHistory

This operation returns process history perspective of an order. The different kinds of process history perspectives are:

Use the GetOrderCompensations operation to retrieve information about order compensations, including their IDs. See "GetOrderCompensations".

Preconditions

Expected Outcome

The process history perspective for the order is returned.


GetOrderCompensations

This operation retrieves the history of all compensations for an order. For each compensation, the data returned includes the type of compensation, submission date, start date (optional), and completion date (optional).

Preconditions

Expected Outcome

The order compensation plan information is returned as a set of compensation tasks, along with the compensation dependencies between them.


GetCompensationPlan

This operation retrieves compensation plan details for an order. For each compensation plan, the data returned includes the type of compensation, active compensation task information, pending compensation task information , and the state transition history for compensation tasks.

Preconditions

Expected Outcome

The order compensation plan information is returned.


Navigating WSDL and XSD Files

This section describes how to navigate the WSDL and XSD files to determine the input parameters, responses, and fault types that a given Web Service operation defines. The information is presented through an example that is applicable to all operations.


WSDL File

Example 4-3 is an excerpt from the OrderManagementWS.wsdl file that shows how a typical Web Service operation is defined.

Example 4-3 WSDL Operation Definition

<wsdl:operation name="CreateOrderBySpecification">              
                          <wsdl:input message="prov:CreateOrderBySpecificationRequest">
                          </wsdl:input>
                          <wsdl:output message="prov:CreateOrderBySpecificationResponse">
                          </wsdl:output>
                          <wsdl:fault name="InvalidOrderSpecificationFault" 
    message="prov:CreateOrder_faultMsg">
                          </wsdl:fault>
                          <wsdl:fault name="TransactionNotAllowedFault" 
    message="prov:CreateOrder_faultMsg1">
  </wsdl:fault>
                          <wsdl:fault name="InvalidOrderDataFault" 
    message="prov:CreateOrder_faultMsg3">
                          </wsdl:fault>
                </wsdl:operation>
 

The WSDL file defines each operation in the same manner, which provides the following information:

The WSDL file tells you what request goes with what response, and what exceptions the request may throw. Each Web Service operation defines a request and a response, which are the input and output parameters. The request and response structures are defined in the corresponding XSD file. For example, the CreateOrderBySpecification operation is defined in the OrderManagmentWS.wsdl file, and the corresponding XSD file is OrderManagementWS.xsd.


XSD File

This section describes how to navigate the XSD files. The request and response structures defined in the XSD are used by the Web Service operations as input and output parameters. This section provides graphics of the XSD in various states of expansion. You can view the XSD using any XML application, such as XMLSpy.

XMLSpy offers several ways to view XML files. XSD files containing large structures can be very difficult to read. The examples provided in this section show how to view XSD files using the Schema/WSDL Design view, which allows you to view the top level structures and then expand and collapse them as needed. Viewing the XML structure in this manner automatically pulls in any referenced structures, removing the need to scroll around to locate them.

Note:

If you are using an application other than XMLSpy to view XML files, your views of the XSD may differ from the examples used in this section.

Determining Input Parameters (Request)

Figure 4-1 shows a portion of the OrderManagmentWS.xsd file in the Schema/WSDL Design view, as it appears when first opened. This is the top level of the view, which lists all simpleType, complexType, and elements that are defined in the file.

Figure 4-1 Schema/WSDL Design View

Shows a portion of the OrderManagementWS.xsd file in the Schema/WSDL Design view, as it appears when first opened.

From the top level, clicking the grey box located to the left of any element or complexType expands the structure. Continuing with the example, Figure 4-2 shows the result of clicking the grey box located to the left of CreateOrderBySpecification.

Figure 4-2 Expanded Structure

Shows the expanded structure.

From this level, you can see that CreateOrderBySpecification defines CreateOrderBySpecificationRequestType, but you cannot see what CreateOrderBySpecificationRequestType actually defines. Clicking the "+" located within the CreateOrderBySpecificationRequestType structure box expands the structure. Figure 4-3 and Figure 4-4 show the result of this action.

Figure 4-3 Further Expanded Structure

Shows the further expanded structure.

Figure 4-4 Further Expanded Structure (continued)

Shows the remainder of the further expanded structure.

From this level, you can see that CreateOrderBySpecificationRequestType defines:

However, you cannot see what the Specification, Data, or Remark structures define. As with the previous level, you can expand any of these structures by clicking the "+" located to the right of the structure name. Clicking the "+" located within the Data and Remark structure box expands the structures. Figure 4-5 shows the result of this action.

Figure 4-5 Further Expansion of Data and Remark Elements

Shows the further expansion of Data and Remark elements.

Expanding the Specification, Data, and Remark structures shows additional defined structures and fields. In this example, note that the structure defined under the Data structure (OrderDataType any) is a structure that is defined in Design Studio. For example, you may define five different order templates, so the structure under the Data structure varies depending on the order type. The order-specific data in the request is validated by the server through the creation task view.

Note:

To collapse any of the structures at any level, click "-" located near the structure name. You can also collapse all structures and return to the top level by clicking the collapse button, located in the upper left corner as shown in Figure 4-3, "Further Expanded Structure". The collapse button is only visible in the upper left corner, so you must scroll all the way up and all the way to the left to see it.

Determining Output Parameters (Response)

You can expand the response structure defined for an operation. Figure 4-6 shows the top level of the OrderManagementWS.xsd file in Schema/WSDL Design view. Continuing with our example, expand CreateOrderBySpecificationResponse to determine the expected response.

Figure 4-6 Schema/WSDL Design View

Shows the top level of the OrderManagementWS.xsd file in Schema/WSDL Design view.

Figure 4-7 shows the expected response defined by CreateOrderBySpecificationResponse, which can be expanded even further.

Figure 4-7 Expanded Structure

Shows the expected response defined by CreateOrderBySpecificationResponse, which can be expanded even further.

Determining Fault Types

You can expand the fault names defined for the operation. Continuing with the CreateOrderBySpecification example, InvalidOrderSpecificationFault, TransactionNotAllowedFault, and InvalidOrderDataFault are all defined as top level structures in the OrderManagementWS.xsd file.


Request and Response Examples

This section provides sample XML requests and sample XML responses. Sample XML for any Web Service operation can be generated from the XSD using any XML application such as XMLSpy.

To generate a sample XML file using XMLSpy:

  1. Open an XSD file in XMLSpy.

  2. From the menu, select DTD/Schema, then select Generate Sample XML File.

    The Select a Root Element dialogue box opens, which lists all root elements defined in the XSD, such as CreateOrder, CreateOrderResponse, FindOrder, FindOrderResponse, and so on.

  3. Select a root element and click OK.

    The Generate Sample XML File dialogue box appears, which provides a few selection options such as generating non-mandatory elements and attributes, the number of structures to generate for structures that are defined as a sequence, and whether or not to populate the XML with data.

  4. Choose the appropriate options and click OK.

    The generated XML displays within a new file, Untitled.xml.

Generating XML in this manner does not generate the SOAP header and body. However, the SOAP header and body can be manually inserted into the generated XML.


CreateOrderBySpecification Examples

This section provides a request example and a response example for the CreateOrderBySpecification operation.

Request Example

Example 4-4 CreateOrderBySpecificationRequest

<?xml version = '1.0' encoding = 'UTF-8'?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:ws="http://xmlns.oracle.com/communications/ordermanagement">
<soapenv:Header>
<wsse:Security soapenv:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<wsse:UsernameToken wsu:Id="UsernameToken-4799946" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<wsse:Username>administrator</wsse:Username>
<wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">administrator</wsse:Password>
</wsse:UsernameToken>
      </wsse:Security>
   </soapenv:Header>
<soapenv:Body>
      <ws:CreateOrderBySpecification>
         <ws:Specification>
            <ws:Cartridge>
               <ws:Name>view_framework_demo</ws:Name>
               <!--Optional:-->
               <ws:Version>1.0</ws:Version>
            </ws:Cartridge>
            <ws:Type>vf_demo</ws:Type>
            <ws:Source>web</ws:Source>
         </ws:Specification>
         <!--Optional:-->
         <ws:Reference>test message</ws:Reference>
         <!--Optional:-->
         <ws:Priority>5</ws:Priority>
         <!--Optional:-->
         <ws:AutoAddMandatoryData>true</ws:AutoAddMandatoryData>
         <!--Optional:-->
         <ws:StartOrder>true</ws:StartOrder>
         <!--Optional:-->
         <ws:Data>
<_root>
             <account_information>
               <amount_owing>553</amount_owing>
             </account_information>
           </_root>
         </ws:Data>
<!--Zero or more repetitions:-->
<ws:Remark>
            <!--Optional:-->
            <ws:Text>Test Remark</ws:Text>
            <!--Zero or more repetitions:-->
            <ws:Attachment>
               <!--Optional:-->
               <ws:Name>readme.txt</ws:Name>
               <!--You have a CHOICE of the next 3 items at this level-->
               <ws:swaRefMimeContent>cid:first</ws:swaRefMimeContent>
               <!--ws:base64BinaryContent>?</ws:base64BinaryContent>
               <ws:hexBinaryContent>?</ws:hexBinaryContent-->
     </ws:Attachment>
 </ws:Remark>
<ws:Remark>
            <!--Optional:-->
            <ws:Text>Test Remark</ws:Text>
            <!--Zero or more repetitions:-->
            <ws:Attachment>
               <!--Optional:-->
               <ws:Name>test2.txt</ws:Name>
               <!--You have a CHOICE of the next 3 items at this level-->
               <ws:swaRefMimeContent>cid:second</ws:swaRefMimeContent>
               <!--ws:base64BinaryContent>?</ws:base64BinaryContent>
               <ws:hexBinaryContent>?</ws:hexBinaryContent-->
     </ws:Attachment>
 </ws:Remark>
         </ws:CreateOrderBySpecification>
   </soapenv:Body>
</soapenv:Envelope>

Response Example

Example 4-5 CreateOrderBySpecificationResponse

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header/>
<soapenv:Body>
<ws:CreateOrderBySpecificationResponse xmlns:ws="http://xmlns.oracle.com/communications/ordermanagement">
<ws:OrderSummary>
<ws:Id>202</ws:Id>
<ws:Specification>
<ws:Cartridge>
<ws:Name>view_framework_demo</ws:Name>
<ws:Version>1.0</ws:Version>
</ws:Cartridge>
<ws:Type>vf_demo</ws:Type>
<ws:Source>web</ws:Source>
</ws:Specification>
<ws:State>open.not_running.not_started</ws:State>
<ws:Reference>test message</ws:Reference>
<ws:Priority>5</ws:Priority>
</ws:OrderSummary>
</ws:CreateOrderBySpecificationResponse>
</soapenv:Body>

Request Example - Setting Up Reference Nodes

This example demonstrates how to set up reference nodes in the task data of the creation task when you code the CreateOrderBySpecification call in your XQuery or XSLT or Java automation plug-ins.

Note:

A creation task is selected for an order in the Order Editor Details tab of Design Studio. In this example, the name of the creation task (for which the CreateOrderBySpecification call requires the order data) is in the parameter <ord:View>ReferenceDebugCreationTask</ord:View> .

When creating the order you must explicitly give the referred-to field an index, and then refer to it with {#} in the reference. You assign the index and code it when you write your automation plug-in code (XQuery/XSLT/Java code).

In this example, <LineItem index="1"> is the index value you defined to this LineItem instance in your automation plug-in code. The index value must be unique within this CreateOrderBySpecification order data; this allows you to refer to this instance later as <LineItem_refNode>{1}</LineItem_refNode> to point to a single data node location in the order template at order creation time.

Example 4-6 CreateOrderBySpecificationRequest - Setting Up Reference Nodes

<ord:CreateOrderBySpecification>
  <ord:Specification>
    <ord:Cartridge>
      <ord:Name>ReferenceDebug</ord:Name>
      <ord:Version>1.0.0</ord:Version>
    </ord:Cartridge>
    <ord:Type>ReferenceDebugOrder</ord:Type>
    <ord:Source>ReferenceDebugOrder</ord:Source>
    <ord:View>ReferenceDebugCreationTask</ord:View>
  </ord:Specification>
  <ord:Reference>created from SoapUI</ord:Reference>
  <ord:Priority>5</ord:Priority>
  <ord:AutoAddMandatoryData>false</ord:AutoAddMandatoryData>
  <ord:StartOrder>false</ord:StartOrder>
  <!--Optional:-->
  <ord:Data>
    <_root>
      <Data>
        <LineItem index="1">
           <ID>1</ID>
        </LineItem>
        <LineItem index="2">
          <ID>2</ID>
        </LineItem>
      </Data>
      <References>
        <LineItem_refNode>{1}</LineItem_refNode>
      </References>
    </_root>
  </ord:Data>
 </ord:CreateOrderBySpecification>

GetOrder Examples

This section provides a request example and a response example for the GetOrder operation.

Request Example

Example 4-7 GetOrderRequest

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:ws="http://xmlns.oracle.com/communications/ordermanagement">
<soapenv:Header>
      <wsse:Security soapenv:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
         <wsse:UsernameToken wsu:Id="UsernameToken-4799946" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
            <wsse:Username>administrator</wsse:Username>
            <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">administrator</wsse:Password>
         </wsse:UsernameToken>
      </wsse:Security>
   </soapenv:Header>
   <soapenv:Body>
      <ws:GetOrder>
         <ws:OrderId>70</ws:OrderId>
         <ws:View>creation_view</ws:View>
      </ws:GetOrder>
   </soapenv:Body>
</soapenv:Envelope>

Response Example

Example 4-8 GetOrderReponse

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header/>
<soapenv:Body>
<ws:GetOrderResponse xmlns:ws="http://xmlns.oracle.com/communications/ordermanagement">
<ws:OrderSummary>
<ws:Id>70</ws:Id>
<ws:Specification>
<ws:Cartridge>
<ws:Name>view_framework_demo</ws:Name>
<ws:Version>1.0</ws:Version>
</ws:Cartridge>
<ws:Type>vf_demo</ws:Type
><ws:Source>web</ws:Source>
</ws:Specification>
<ws:State>closed.completed</ws:State>
<ws:Reference>test message</ws:Reference>
<ws:ExpectedOrderCompletionDate>2009-03-10T00:00:00Z</ws:ExpectedOrderCompletionDate>
<ws:Priority>5</ws:Priority>
</ws:OrderSummary>
<ws:Data>
<pc:_root xmlns:pc="urn:oracle:names:provisioning:cartridge:view_frame
work_demo:1.0:view:enter_payment_details" index="0">
<pc:account_information index="1">
<pc:amount_owing index="2">345</pc:amount_owing>
</pc:account_information>
</pc:_root>
</ws:Data>
<ws:Remarks>
            <ws:Remark>
               <ws:Id>1605</ws:Id>
               <ws:Text>Test Remark</ws:Text>
               <ws:Timestamp>2007-05-16T08:43:55.000-04:00</ws:Timestamp>
               <ws:UserName>oms</ws:UserName>
               <ws:TaskName>creation10005</ws:TaskName>
               <ws:WorkItemId>4143</ws:WorkItemId>
               <ws:State>accepted</ws:State>
               <ws:ReadOnly>true</ws:ReadOnly>
            </ws:Remark>
            <ws:Remark>
               <ws:Id>1604</ws:Id>
               <ws:Text>Test Remark</ws:Text>
               <ws:Timestamp>2007-05-16T08:43:55.000-04:00</ws:Timestamp>
               <ws:UserName>oms</ws:UserName>
               <ws:TaskName>creation10005</ws:TaskName>
               <ws:WorkItemId>4143</ws:WorkItemId>
               <ws:State>accepted</ws:State>
               <ws:ReadOnly>true</ws:ReadOnly>
            </ws:Remark>
         </ws:Remarks>
</ws:GetOrderResponse>
</soapenv:Body>
</soapenv:Envelope>

UpdateOrder Examples

This section provides request examples and a response example for the UpdateOrder operation.

Request Examples

Example 4-9 UpdateOrderRequest

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:ws="http://xmlns.oracle.com/communications/ordermanagement">
<soapenv:Header>
      <wsse:Security soapenv:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
         <wsse:UsernameToken wsu:Id="UsernameToken-4799946" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
            <wsse:Username>administrator</wsse:Username>
            <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">administrator</wsse:Password>
         </wsse:UsernameToken>
      </wsse:Security>
   </soapenv:Header>
<soapenv:Body>
<ws:UpdateOrder>
<ws:OrderId>4</ws:OrderId>
<ws:UpdatedOrder>
<_root>
<account_information>
<amount_owing>222</amount_owing>
</account_information>
</_root>
</ws:UpdatedOrder>
<ws:View>enter_payment_details</ws:View>
</ws:UpdateOrder>
</soapenv:Body>
</soapenv:Envelope>

Example 4-10 UpdateOrderRequest: Update nodes

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:ws="http://xmlns.oracle.com/communications/ordermanagement">
<soapenv:Header>
      <wsse:Security soapenv:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
         <wsse:UsernameToken wsu:Id="UsernameToken-4799946" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
            <wsse:Username>administrator</wsse:Username>
            <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">administrator</wsse:Password>
         </wsse:UsernameToken>
      </wsse:Security>
   </soapenv:Header>
<soapenv:Body>
<ws:UpdateOrder>
<ws:OrderId>4</ws:OrderId>
<ws:UpdatedNodes>
<_root>
<payment_information>
<payment_method>credit_card</payment_method>
<pay_entire_balance>Yes</pay_entire_balance>
</payment_information>
</_root>
</ws:UpdatedNodes>
<ws:View>enter_payment_details</ws:View>
</ws:UpdateOrder>
</soapenv:Body>
</soapenv:Envelope>

Example 4-11 UpdateOrderRequest: Data change

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:ws="http://xmlns.oracle.com/communications/ordermanagement">
<soapenv:Header>
      <wsse:Security soapenv:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
         <wsse:UsernameToken wsu:Id="UsernameToken-4799946" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
            <wsse:Username>administrator</wsse:Username>
            <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">administrator</wsse:Password>
         </wsse:UsernameToken>
      </wsse:Security>
   </soapenv:Header>
<soapenv:Body>
<ws:UpdateOrder>
<ws:OrderId>41</ws:OrderId>
<ws:DataChange>
<ws:Update Path="/account_information/amount_owing">
444
</ws:Update>
</ws:DataChange>
<ws:StartOrder>false</ws:StartOrder>
<ws:View>enter_payment_details</ws:View>
</ws:UpdateOrder>
</soapenv:Body>
</soapenv:Envelope>

Response Example

Example 4-12 UpdateOrderResponse

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
   <soapenv:Header/>
   <soapenv:Body>
<ws:UpdateOrderResponse xmlns:ws="http://xmlns.oracle.com/communications/ordermanagement">
<ws:OrderId>2180</ws:OrderId>
<ws:State>open.running.in_progress</ws:State>
</ws:UpdateOrderResponse>
</soapenv:Body>
</soapenv:Envelope>

SuspendOrder Examples

This section provides a request example and a response example for the SuspendOrder operation.

Request Example

Example 4-13 SuspendOrderRequest

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:ws="http://xmlns.oracle.com/communications/ordermanagement">
<soapenv:Header>
      <wsse:Security soapenv:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
         <wsse:UsernameToken wsu:Id="UsernameToken-4799946" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
            <wsse:Username>administrator</wsse:Username>
            <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">administrator</wsse:Password>
         </wsse:UsernameToken>
      </wsse:Security>
   </soapenv:Header>
<soapenv:Body>
      <ws:SuspendOrder>
         <ws:OrderId>145</ws:OrderId>
         <!--Optional:-->
         <ws:Reason>test</ws:Reason>
<!--You have a CHOICE of the next 2 items at this level-->
         <!--Optional:-->
         <ws:GracePeriodExpiryDate>?</ws:GracePeriodExpiryDate>
         <!--Optional:-->
         <ws:GracePeriodExpiry>?</ws:GracePeriodExpiry>
         <!--Optional:-->
         <ws:EventInterval>?</ws:EventInterval>
</ws:SuspendOrder>
</soapenv:Body>
</soapenv:Envelope>

Response Example

Example 4-14 SuspendOrderResponse

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
   <soapenv:Header/>
   <soapenv:Body>
      <ws:SuspendOrderResponse xmlns:ws="http://xmlns.oracle.com/communications/ordermanagement">
         <ws:OrderId>145</ws:OrderId>
      </ws:SuspendOrderResponse>
   </soapenv:Body>
</soapenv:Envelope>

ResumeOrder Examples

This section provides a request example and a response example for the ResumeOrder operation.

Request Example

Example 4-15 ResumeOrderRequest

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:ws="http://xmlns.oracle.com/communications/ordermanagement">
<soapenv:Header>
      <wsse:Security soapenv:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
         <wsse:UsernameToken wsu:Id="UsernameToken-4799946" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
            <wsse:Username>administrator</wsse:Username>
            <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">administrator</wsse:Password>
         </wsse:UsernameToken>
      </wsse:Security>
   </soapenv:Header>
<soapenv:Body>
      <ws:ResumeOrder>
         <ws:OrderId>1176</ws:OrderId>
      </ws:ResumeOrder>
   </soapenv:Body>
</soapenv:Envelope>

Response Example

Example 4-16 ResumeOrderResponse

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
   <soapenv:Header/>
   <soapenv:Body>
      <ws:ResumeOrderResponse xmlns:ws="http://xmlns.oracle.com/communications/ordermanagement">
         <ws:OrderId>1176</ws:OrderId>
      </ws:ResumeOrderResponse>
   </soapenv:Body>
</soapenv:Envelope>

CancelOrder Examples

This section provides a request example and a response example for the CancelOrder operation.

Request Example

Example 4-17 CancelOrderRequest

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:ws="http://xmlns.oracle.com/communications/ordermanagement">
<soapenv:Header>
      <wsse:Security soapenv:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
         <wsse:UsernameToken wsu:Id="UsernameToken-4799946" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
            <wsse:Username>administrator</wsse:Username>
            <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">administrator</wsse:Password>
         </wsse:UsernameToken>
      </wsse:Security>
   </soapenv:Header>
<soapenv:Body>
      <ws:CancelOrder>
         <ws:OrderId>1316</ws:OrderId>
         <!--Optional:-->
      </ws:CancelOrder>
   </soapenv:Body>
</soapenv:Envelope>

Response Example

Example 4-18 CancelOrderResponse

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
   <soapenv:Header/>
   <soapenv:Body>
      <ws:CancelOrderResponse xmlns:ws="http://xmlns.oracle.com/communications/ordermanagement">
         <ws:OrderId>1316</ws:OrderId>
      </ws:CancelOrderResponse>
   </soapenv:Body>
</soapenv:Envelope>