Tib Af Webservices

TIBCO Fulfillment Order Management Web Services
Software Release 2.0 November 2012
Important Information
SOME TIBCO SOFTWARE EMBEDS OR BUNDLES OTHER TIBCO SOFTWARE. USE OF SUCH EMBEDDED OR BUNDLED TIBCO SOFTWARE IS SOLELY TO ENABLE THE FUNCTIONALITY (OR PROVIDE LIMITED ADD-ON FUNCTIONALITY) OF THE LICENSED TIBCO SOFTWARE. THE EMBEDDED OR BUNDLED SOFTWARE IS NOT LICENSED TO BE USED OR ACCESSED BY ANY OTHER TIBCO SOFTWARE OR FOR ANY OTHER PURPOSE. USE OF TIBCO SOFTWARE AND THIS DOCUMENT IS SUBJECT TO THE TERMS AND CONDITIONS OF A LICENSE AGREEMENT FOUND IN EITHER A SEPARATELY EXECUTED SOFTWARE LICENSE AGREEMENT, OR, IF THERE IS NO SUCH SEPARATE AGREEMENT, THE CLICKWRAP END USER LICENSE AGREEMENT WHICH IS DISPLAYED DURING DOWNLOAD OR INSTALLATION OF THE SOFTWARE (AND WHICH IS DUPLICATED IN LICENSE.PDF) OR IF THERE IS NO SUCH SOFTWARE LICENSE AGREEMENT OR CLICKWRAP END USER LICENSE AGREEMENT, THE LICENSE(S) LOCATED IN THE LICENSE FILE(S) OF THE SOFTWARE. USE OF THIS DOCUMENT IS SUBJECT TO THOSE TERMS AND CONDITIONS, AND YOUR USE HEREOF SHALL CONSTITUTE ACCEPTANCE OF AND AN AGREEMENT TO BE BOUND BY THE SAME. This document contains confidential information that is subject to U.S. and international copyright laws and treaties. No part of this document may be reproduced in any form without the written authorization of TIBCO Software Inc. TIBCO, The Power of Now, TIBCO ActiveMatrix BusinessWorks, TIBCO Runtime Agent, TIBCO Administrator, TIBCO Enterprise Message Service, and TIBCO BusinessEvents are either registered trademarks or trademarks of TIBCO Software Inc. in the United States and/or other countries. EJB, Java EE, J2EE, and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries. All other product and company names and marks mentioned in this document are the property of their respective owners and are mentioned for identification purposes only. This software may be available on multiple operating systems. However, not all operating system platforms for a specific software version are released at the same time. Please see the readme.txt file for the availability of this software version on a specific operating system platform. THIS DOCUMENT IS PROVIDED AS IS WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. THIS DOCUMENT COULD INCLUDE TECHNICAL INACCURACIES OR TYPOGRAPHICAL ERRORS. CHANGES ARE PERIODICALLYADDED TO THE INFORMATION HEREIN; THESE CHANGES WILL BE INCORPORATED IN NEW EDITIONS OF THIS DOCUMENT. TIBCO SOFTWARE INC. MAY MAKE IMPROVEMENTS AND/OR CHANGES IN THE PRODUCT(S) AND/OR THE PROGRAM(S) DESCRIBED IN THIS DOCUMENT AT ANY TIME. THE CONTENTS OF THIS DOCUMENT MAY BE MODIFIED AND/OR QUALIFIED, DIRECTLY OR INDIRECTLY, BY OTHER DOCUMENTATION WHICH ACCOMPANIES THIS SOFTWARE, INCLUDING BUT NOT LIMITED TO ANY RELEASE NOTES AND "READ ME" FILES. Copyright 2010-2012 TIBCO Software Inc. ALL RIGHTS RESERVED. TIBCO Software Inc. Confidential Information
TOC | 5
Contents
Preface.....................................................................................................................7
Changes from the Previous Release of this Guide..................................................................8 Related Documentation............................................................................................................9 Typographical Conventions....................................................................................................10 Connecting with TIBCO Resources........................................................................................11
Part I: Architecture.............................................................................13 Chapter 1 Fulfillment Orchestration Overview......................19

Fulfillment Orchestration Components........................................................................20 Services and Operations........................................................................................................14 Integration Channels..............................................................................................................16 SOAP Over HTTP........................................................................................................16 SOAP Over JMS..........................................................................................................16
Part II: Fulfillment Order Management Services.............................21

Security Header......................................................................................................................22
Chapter 2 Fulfillment Management Services.........................23

Customer Service........................................................................................................23 Inventory Service.........................................................................................................26 Offer Service................................................................................................................51 Product Service...........................................................................................................62 Subscriber Service......................................................................................................69 Disabling SOAP_HTTP and SOAP_JMS Services......................................................72
Chapter 3 Order Management Services.................................75

Order Service..............................................................................................................75 Purge Order Service....................................................................................................87
Appendix A Common Data Format Specifications.......................91

ResultStatus...........................................................................................................................92 ResultFault.............................................................................................................................93 Customer................................................................................................................................94 Notification..............................................................................................................................97 Order Notification...................................................................................................................98
6 | TOC
CustomerHierarchy.................................................................................................................99 Plan Notification...................................................................................................................101 Subscriber............................................................................................................................102 Segment...............................................................................................................................105 Role......................................................................................................................................106 Order....................................................................................................................................107 OrderHeader........................................................................................................................109 OrderLine.............................................................................................................................113 Product.................................................................................................................................116 Characteristic.......................................................................................................................117 Execution Plan.....................................................................................................................119 PlanFragment.......................................................................................................................123 InventoryItem........................................................................................................................124 InventoryItem Order.............................................................................................................127
Appendix B Error Codes and Messages......................................129

Error Code Format...............................................................................................................130 Error Codes..........................................................................................................................131 Customers............................................................................................................................132 Inventory...............................................................................................................................133 Offers....................................................................................................................................134 OfferValidation......................................................................................................................135 Products...............................................................................................................................137 Subscribers..........................................................................................................................138
Appendix C Component Classes and Methods..........................139

OMS Classes and Methods..................................................................................................140 Orchestrator Pre-processors and Rules...............................................................................141
Preface
The preface contains information about documentation related to the current document, typographical conventions, and information on how to contact TIBCO support.
8 | Preface
Changes from the Previous Release of this Guide

This section itemizes the major changes from the previous release of this guide. Endpoint URLs The AFS is deployed as part of OMS server, the endpoint URLs for SOAP over HTTP have changed. Security All calls to the web service are authenticated using Username token based approach. Logging The logging is done using the AFFLogger APIs. Based on configured appender, the logs are created in the corresponding location.
Preface | 9
Related Documentation
TIBCO Fulfillment Order Management Installation and Configuration Read this manual for instructions on site preparation, installation, and configuration. TIBCO Fulfillment Order Management Administration Read this manual for instructions on administration tasks. TIBCO Fulfillment Order Management Web Services Read this manual for information about Web services. TIBCO Fulfillment Order Management Release Notes Read the release notes for a list of features. This document also contains the list of known issues for this release. TIBCO Fulfillment Order Management User's Guide Read this manual for Fulfillment Order Management features and functionality as well as all the screens. TIBCO Fulfillment Order Management Concepts and Architecture Read this manual for terminology and concepts of TIBCO Fulfillment Order Management.
10 | Preface
Typographical Conventions
The following typographical conventions are used in this manual: Table 1: General Typographical Conventions Convention
TIBCO_HOME TRA_HOME AF_HOME
Use Many TIBCO products are installed within the same home directory. This directory is referenced in documentation as TIBCO_HOME. The value of TIBCO_HOME depends on the operating system. For example, on Unix systems the default value is $HOME/tibco. TIBCO Runtime Agent installs into a directory inside ENV_HOME. This directory is referenced in documentation as TRA_HOME. The value of TRA_HOME depends on the operating system. For example, on Unix systems the default value is $TIBCO_HOME/tra. TIBCO Fulfillment Order Management installs into a directory inside ENV_HOME. This directory is referenced in documentation as AF_HOME. The value of AF_HOME depends on the operating system. For example, on Unix systems the default value is $TIBCO_HOME/af/2.0.
code font
Code font identifies commands, code examples, filenames, pathnames, and output displayed in a command window. For example: Use MyCommand to start the foo process.
bold code font
Bold code font is used in the following ways: In procedures, to indicate what a user types. For example: Type admin. In large code samples, to indicate the parts of the sample that are of particular interest. In command syntax, to indicate the default parameter for a command. For example, if no parameter is specified, MyCommand is enabled:
MyCommand [enable | disable]
italic font
Italic font is used in the following ways: To indicate a document title. For example: See TIBCO Fulfillment Order Management Web Services. To introduce new terms For example: A portal page may contain several portlets. Portlets are mini-applications that run in a portal. To indicate a variable in a command or code syntax that you must replace. For example: MyCommand pathname The note icon indicates information that is of special interest or importance, for example, an additional action required only in certain circumstances. The tip icon indicates an idea that could be useful, for example, a way to apply the information provided in the current section to achieve a specific result. The warning icon indicates the potential for a damaging situation, for example, data loss or corruption if certain steps are taken or not taken.
Preface | 11
Connecting with TIBCO Resources

How to Join TIBCOmmunity TIBCOmmunity is an online destination for TIBCO customers, partners, and resident expertsa place to share and access the collective experience of the TIBCO community. TIBCOmmunity offers forums, blogs, and access to a variety of resources. To register, go to http://www.tibcommunity.com. How to Access All TIBCO Documentation After you join TIBCOmmunity, you can access the documentation for all supported product versions here: http://docs.tibco.com. How to Contact TIBCO Support For comments or problems with this manual or the software it addresses, please contact TIBCO Support as follows: For an overview of TIBCO Support, and information about getting started with TIBCO Support, visit this site: http://www.tibco.com/services/support If you already have a valid maintenance or support contract, visit this site: https://support.tibco.com Entry to this site requires a username and password. If you do not have a username, you can request one.
Part
I
Architecture
TIBCO Fulfillment Order Management is a meta data driven order management and fulfillment system which allows development of fulfillment plans based on meta-data specified in product catalogs. Order fulfillment and service provisioning is no longer a simple single-service or product workflow. The dynamic bundled offerings along with the explosion of devices, applications, real time inventory management and third-party content providers requires a complex order fulfillment system which can adapt to the changes in processes, meta data and inventory. Traditional OSS/BSS 1 approach with their data silos fail to provide a dynamic and agile solution. An end-to-end order management system based on product and service catalogs is a key differentiator of Fulfillment Order Management. TIBCO Fulfillment Order Management is a comprehensive software solution to design, deploy and maintain high-performance scalable enterprise-level business processes for advanced and dynamic order fulfillment. TIBCO Fulfillment Order Management enables companies to quickly introduce new product offerings and in most cases requiring little or no change to fulfillment processes. The product bundles are decomposed into existing products to automatically generate a plan specific to the order. TIBCO Fulfillment Order Management also enables companies to efficiently manage changes to the existing business process to meet a rapidly changing business environment. Product model can be defined following SID 9 guidelines using TIBCO Fulfillment Catalog or any other catalog management system and imported into Fulfillment Order Management.
Topics Fulfillment Orchestration Overview Services and Operations Integration Channels
Operational/Operations Support System (OSS) Software applications support back-office activities operating a company network, provision and maintain customer services. OSS is traditionally used by network planners, service designers, operations, architects, support, and engineering teams in the service provider. Software applications that support customer-facing activities. Billing, order management, customer relationship management, call center automation, are all Business Support Systems (BSS) applications.
14 | Architecture
Services and Operations

The interfaces are organized into services that include related operations. The following interfaces are exposed for any client to invoke the services related to the framework. These services can be invoked over two different channels: SOAP over HTTP and SOAP over JMS. All Web Services support HTTP and JMS. Web Services endpoint URL and SOAP action is based on module name, service name, and operation name.
http://<<Machine IP>>:<<Port>>/omsServer/api/<<serviceName>>ServiceHTTP.
The Service name has the first letter in lowercase once. For example, http://10.0.2.192:18090/omsServer/api/InventoryServiceHTTP. The naming convention for SOAP action is /omsServer/api/<<serviceName>>ServiceHTTP. The naming convention for JMS destination is tibco.aff.<shortnameformodule>.services.<servicenamelowercase>. For example, tibco.aff.om.services.order. The operations specified in the table follow the naming conventions. Table 2: Services and Operations Summary Module Service JMS Destination tibco.aff.ocv.services.customer Operation GetCustomerHierarchy GetCustomerImage ForCustomer Inventory tibco.aff.ocv.services.inventory AssignInventoryItem AssignInventoryItems GetInventoryItem GetInventoryItems GetUserStatus ReassignInventoryItem ReassignInventoryItems RemoveInventoryItem RemoveInventoryItems RollbackInventoryItem RollbackInventoryItems SetUserStatus UpdateInventoryItem UpdateInventoryItems Offer tibco.aff.ocv.services.offer GetOfferDetails
Offer Configuration and Customer Validation (OCV)
Architecture | 15
Module
Service
JMS Destination
Operation GetOffers RemoveOffer SaveOffer ValidateOffer
Product
tibco.aff.ocv.services.product
GetEligibleProducts GetIneligibleSubscribers GetProductInformation GetSegments
Subscriber
tibco.aff.ocv.services.subscriber CreateSubscriber GetCustomerImage ForSubscriber RemoveSubscriber UpdateSubscriber
Order Management (OM)
Order
tibco.aff.om.services.order
CancelOrder GetOrderDetails GetOrders GetOrderExecutionPlan SubmitOrder AmendOrder SyncSubmitOrder WithdrawOrder PerformBulkOrderAction
Purge
NA
purgeOrders getPurgeStatus
OfflineCatalog
NA
RequestOfflineCatalog
For all the web services to work correctly, the data models should be available to Offer Configuration and Validation (OCV) and Automatic Order Plan Development (AOPD) components.
16 | Architecture
Integration Channels
To provide maximum flexibility for exposing services to the enterprise, service implementation is separated from the interface. This allows services to be invoked from different transport mechanisms. The following transports are supported: SOAP over HTTP SOAP over JMS
SOAP Over HTTP

SOAP over HTTP service calls use the standard synchronous web services message format. The integration pattern is as follows:
Figure 3: SOAP over HTTP Integration Pattern In the SOAP over HTTP pattern, a service client makes a synchronous service call to the Order Management Services component. The service calls the appropriate operation and performs the required operation before sending a reply back to the calling application. Since AFS is now deployed as part of the OMS Server, the endpoint URLs for SOAP over HTTP have changed. The new endpoint URLs for respective components are as follows: InventoryService : http://<<host>>:<<port>>/omsServer/api/InventoryServiceHTTP CustomerService : http://<<host>>:<<port>>/omsServer/api/CustomerServiceHTTP SubscriberService : http://<<host>>:<<port>>/omsServer/api/SubscriberServiceHTTP OfferService : http://<<host>>:<<port>>/omsServer/api/OfferServiceHTTP ProductService: http://<<host>>:<<port>>/omsServer/api/ProductServiceHTTP Offline Catalog Request: http://<host>:<port>/omsServer/api/offlineCatalogueWS. The Offline Catalog request service can be used to send the request to AFI to load the Offline models.
SOAP Over JMS

SOAP works over a variety of transports and is not restricted to HTTP web services. JMS provides a highly available transport that delivers messages over and above what HTTP provides. SOAP over JMS service calls use the TIBCO proposed specification extension for sending SOAP messages over JMS. TIBCO ActiveMatrix BusinessWorks supports calling SOAP over JMS synchronously using the standard SOAP Request/Reply activity. Non-TIBCO ActiveMatrix BusinessWorks application should be able to call SOAP over JMS services both synchronously and asynchronously using standard JMS messaging techniques that implement the required elements of the specification extension. The synchronous integration pattern is as follows:
Architecture | 17
Figure 4: SOAP over JMS Synchronous Integration Pattern The asynchronous integration pattern is as follows:
Figure 5: SOAP over JMS Asynchronous Integration Pattern In the SOAP over JMS pattern, a service client makes a synchronous or asynchronous service call to the Order Management Services component. The service calls the appropriate operation and performs the required operation before sending a reply back to the calling application. The JMS destinations where the SOAP message should be send is specified in the respective web services WSDL document.
Chapter
1
Fulfillment Orchestration Overview
New technologies and network architectures enable communications service provider (CSP) to create innovative converged products and services offerings which are introduced faster and have shorter life cycles than previous service offerings to address a very changing and competitive market. In view of the rapid pace of change in the technology, the industry is evolving to become a contributor and not remain a mere consumer of technology. In this environment, communications service providers face the challenge of defining, managing and delivering numerous complex products and variations to the market in most effective way to differentiate themselves. TIBCO has concentrated and structured its services around the following points: New product offering are designed and rolled out in a few weeks including implementation in all fulfillment chain. Customer orders are instantly fulfilled and provisioned in the network to maximize customer experience. Customer orders come from large variety of order entries such as customer self-care portals, customer sales representative desk or even network elements detecting service access to leverage fulfillment chain investment and support hardware rationalization. TIBCO providing CSPs with a comprehensive and integrated solution ready for complete end-to-end fulfillment automation. The TIBCO Fulfillment Orchestration Suite defines new product and service offering, associated fulfillment rules and processes, and automate the delivery from order capture down to the service activation in the network.
Figure 1: Fulfillment Orchestration Architecture
Topics
20 |
Fulfillment Orchestration Components
Fulfillment Orchestration Components

The TIBCO Fulfillment Orchestration Suite solution is capable of supporting end-to-end order fulfillment with Order Management, Provisioning and Catalog capabilities. The following are the constituents of the TIBCO Fulfillment Orchestration Suite: Fulfillment Catalog: A Catalog function that defines and manages life cycles of commercial and technical offering. Fulfillment Order Management: TIBCO Fulfillment Order Management TIBCO Fulfillment Order Management is a meta data driven order management and fulfillment system which allows development of fulfillment plans based on meta-data specified in product catalogs. Order fulfillment and service provisioning is no longer a simple single-service or product workflow. The dynamic bundled offerings along with the explosion of devices, applications, real time inventory management and third-party content providers requires a complex order fulfillment system which can adapt to the changes in processes, meta data and inventory. Traditional OSS/BSS 2 approach with their data silos fail to provide a dynamic and agile solution. An end-to-end order management system based on product and service catalogs is a key differentiator of Fulfillment Order Management. Fulfillment Provisioning: A Provisioning function that automates the activation of the underlying network services and allocation of all the network resources. The Fulfillment Orchestration Suite has a Provisioning element that implements Service Order Management & Resource Order Management TAM applications and aligns to Service & Resource Activator OSS/J Order Management components and eTOM Service Configuration & Activation and Resource Provisioning processes and functions.
Figure 2: Provisioning in the Orchestration Suite To enable the TIBCO Fulfillment Orchestration Suite to provide a truly unified and cohesive solution suite, different components of the suite have been integrated. For instance, the Suite provides pre-defined inter-connectivity between Fulfillment Provisioning (FP, formerly KPSA) and Fulfillment Order Management/Fulfillment Catalog, catalog concept alignment between Fulfillment Catalog and Fulfillment Provisioning through data synchronization process, and a GUI integration for a similar look-and-feel. See TIBCO Fulfillment Order Management Concepts and Architecture for details.
2
Operational/Operations Support System (OSS) Software applications support back-office activities operating a company network, provision and maintain customer services. OSS is traditionally used by network planners, service designers, operations, architects, support, and engineering teams in the service provider. Software applications that support customer-facing activities. Billing, order management, customer relationship management, call center automation, are all Business Support Systems (BSS) applications.
Part
II
Fulfillment Order Management Services
The services are logically divided into the following: Customer Service Inventory Service Offer Service Product Service Subscriber Service You can access these services through SOAP/HTTP channel, or SOAP/JMS channel.
Topics Security Header Fulfillment Management Services Order Management Services
22 | Fulfillment Order Management Services
Security Header
Fulfillment Order Management supports both HTTP and JMS as transport protocols for invoking SOAP based Web services. AFS supports various Web services, and each Web service request requires the WS-Security UserName Token mechanism. It uses TIBCO Administrator credentials in a standards-compliant manner. OMS By default, OMS provides a set of user id and password for the operations on OMS through Web service request. Order services in OMS can be secured by enabling username token-based security. OMS supports the WS-Security UserName Token mechanism, which allows for the sending and receiving of user credentials in a standards-compliant manner. For more details, refer to TIBCO Fulfillment Order Management Administration Guide.
Chapter
2
Fulfillment Management Services
Fulfillment Management Services are the set of services, which are related to entities associated with Order. These entities can be customer, subscriber, offer, product, or inventory. These services allows you to get information about these entities and perform other operations. The location of all the WebService WSDLs 3 is $AF_HOME/schemas/wsdl.
Topics Customer Service Inventory Service Offer Service Product Service Subscriber Service Disabling SOAP_HTTP and SOAP_JMS Services
Customer Service
This service contains operations that retrieve customer information from the order management system. Get Customer Hierarchy This operation retrieves the hierarchy for customers, subscribers, and subscribed products. It either retrieves the hierarchy for all customers and subscribers, or only for a specific customer and subscriber. This operation only returns the customers and subscribers configured in the cache, and then only a limited subset of information about each. To get the full snapshot of a customer, invoke GetCustomerImageForCustomer. To view the full snapshot of a subscriber, invoke GetCustomerImageForSubscriber. To view the full snapshot of a subscribed product, invoke GetInventoryItem. As the customer or subscriber information does not exist in the cache, use the GetInventoryItems operation to retrieve the subscribed products for customers or subscribers not stored in the cache. This interface supports the top five levels of customers:
WSDL or Web Services Description Language is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information. The operations and messages are described abstractly, and then bound to a concrete network protocol and message format to define an endpoint. Related concrete endpoints are combined into abstract endpoints (services). WSDL is extensible to allow description of endpoints and their messages regardless of what message formats or network protocols are used to communicate.
24 |
Figure 6: Customer Hierarchy Returned by GetCustomerHierarchy Entities below Level 4 Customers are not returned. The request message format is:
The valid request criteria is one of the following combinations: CustomerID and IncludeProducts - Returns the hierarchy for a single customer, including all subsidiary customers and subscribers that are stored in the cache. SubscriberID and IncludeProducts - Returns a single subscriber stored in the cache. Table 3: Get Customer Hierarchy Request Data Model Element Name CustomerID Element Type String (Choice, Optional) SubscriberID String (Choice, Optional) IncludeProducts Boolean (Mandatory) Default = true Description The ID of the customer to retrieve the hierarchy. The ID of the subscriber to retrieve the hierarchy. Flag to indicate if subscriber products should also be returned. If set to true, then all subscriber products are returned in the hierarchy. If set to false, then no products are included.
The reply message format is:
| 25
The reply format depends on what criteria is specified in the request: CustomerID - Customer is returned if stored in cache. SubscriberID - Subscriber is returned if stored in cache. Neither CustomerID nor SubscriberID - CustomerHierarchy is returned for all subscribers and customers stored in cache. Table 4: Get Customer Hierarchy Reply Data Model Element Name ResultStatus Element Type ResultStatus (Mandatory) Customer Customer (Choice) Description Data model for ResultStatus is defined in XSD (refer section Common Data Format Specifications on page 91). CustomerHierarchy/Customer data structure. Data model for CustomerHierarchy/Customer is defined in XSD (refer section Common Data Format Specifications on page 91). If the Customer was not found for the given CustomerID this element is omitted. CustomerHierarchy/Subscriber data structure. Data model for CustomerHierarchy/Subscriber is defined in XSD (refer section Common Data Format Specifications on page 91). If the Subscriber was not found for the given SubscriberID this element is omitted. CustomerHierarchy data structure. Data model for CustomerHierarchy is defined in XSD (refer section Common Data Format Specifications on page 91).
Subscriber
Subscriber (Choice)
CustomerHierarchy
CustomerHierarchy (Choice)
Get Customer Image For Customer This operation retrieves the full snapshot of currently configured customer image for a given customer ID and returns to the calling application. The request message format is:
26 |
Table 5: Get Customer Image For Customer Request Data Model Element Name CustomerID Element Type String (Mandatory) The reply message format is: Description The ID of the customer to retrieve the full details.
Table 6: Get Customer Image For Customer Reply Data Model Element Name Customer Element Type Customer (Optional) Description Customer data structure. Data model for Customer is defined in XSD (refer section Common Data Format Specifications on page 91). If the customer was not found for the given CustomerID this element is omitted. Example
ResultStatus
ResultStatus (Mandatory)
Inventory Service
Inventory Service exposes operations related to inventory in order management. The inventory is associated with order and can be at customer or subscriber level. The operations can be assigning inventory, updating inventory , removing inventory and so on. Assign Inventory Item This operation assigns a new inventory item for a specific customer or subscriber. The request message format is:
| 27
Table 7: Assign Inventory Item Request Data Model Element Name Element Type Description CustomerID: The ID of the customer to assign the inventory. SubscriberID: The ID of the subscriber to assign the inventory. ParentCustomerID String (Optional, Choice) ProductID String (Mandatory) Status String (Mandatory) Initial status to assign to the inventory item. Valid status are: DRAFT ACTIVE WITHDRAWN The ID of the parent customer that the subscriber is assigned. Product unique identifier.
CustomerID/SubscriberID String (either one of them is provided)
28 |
Element Name StartDate
Element Type DateTime (Mandatory)
Description The planned start date that the product will go to ACTIVE status. This may be a provisional start date at this point and can be updated later using UpdateInventoryItem operation. Order type
Order
Type (Mandatory)
Order/OrderID
String (Mandatory)
Order identifier the product is ordered on.
Order/OrderLineNumber String (Mandatory) Order/OrderLineAction String (Mandatory) Order/OrderDate DateTime (Mandatory) Order/Comments String (Optional) Order/CurrentOwnerCustomerID String (Optional, Choice) Order/CurrentOwnerSubscriberID String (Optional, Choice) UDFs Type (Optional) UDFs/UDF UDFs/UDF/Name Type (*) String (Mandatory) UDFs/UDF/Value String (Mandatory) The reply message format is:
Order line number the product is ordered on.
Order line action the product is ordered with.
Order date and time the product is ordered.
Comments for this order.
Current customer owner of this item. This does not need to be populated on this operation. Current subscriber owner of this item. This does not need to be populated on this operation. User Defined Field (UDF) type
User defined fields associated with the product User defined field name.
User defined field value.
| 29
Table 8: Assign Inventory Item Reply Data Model Element Name ResultStatus Element Type ResultStatus (Mandatory) Description Data model for ResultStatus is defined in XSD 4 (refer section Common Data Format Specifications on page 91). Inventory identifier for the newly created inventory item. If the item is not created successfully, this is omitted.
InventoryID
String (Optional)
Assign Inventory Items This operation assigns multiple new inventory items to the given customer or subscriber. This is a bulk operation version of Assign Inventory Item. The request message format is:
Table 9: Assign Inventory Items Request Data Model Element Name Item Element Type Type (+) Description Inventory item to assign.
XML Schema Definition (XSD) is also referred to as XML schema language. It describes the structure of an XML document.
30 |
Element Name CustomerID/SubscriberID
Element Type String (Choice)
Description CustomerID: The ID of the customer to assign the inventory. SubscriberID: The ID of the subscriber to assign the inventory.
Item/ParentCustomerID
String (Optional, Choice)
The ID of the parent customer that the subscriber is assigned. Product unique identifier.
Item/ProductID
String (Mandatory)
Item/Status
String (Mandatory)
Initial status to assign to the inventory item. The valid statuses are: DRAFT ACTIVE WITHDRAWN
Item/StartDate
DateTime (Mandatory)
The planned start date that the product will go to ACTIVE status. This may be a provisional start date at this point and can be updated later using UpdateInventoryItem operation. Order type
Item/Order
Type (Mandatory)
Item/Order/OrderID
String (Mandatory)
Order identifier the product is ordered on. Order line number the product is ordered on. Order line action the product is ordered with. Order date and time the product is ordered. Comments for this order.
Item/Order/OrderLineNumber
String (Mandatory)
Item/Order/OrderLineAction
String (Mandatory)
Item/Order/OrderDate
Item/Order/Comments
String (Optional)
Item/Order/CurrentOwnerCustomerID String (Optional, Choice) Item/Order/CurrentOwnerSubscriberID String (Optional, Choice)
Current customer owner of this item. This does not need to be populated on this operation. Current subscriber owner of this item. This does not need to be populated on this operation.
| 31
Element Name Item/UDFs
Element Type Type (Optional)
Description UDF type
Item/UDFs/UDF Item/UDFs/UDF/Name
Type (*) String (Mandatory)
User defined fields associated with the product. User defined field name.
Item/UDFs/UDF/Value
String (Mandatory)
Table 10: Assign Inventory Items Reply Data Model Element Name ResultStatus Element Type ResultStatus (Mandatory) Description Data model for ResultStatus is defined in XSD (refer section Common Data Format Specifications on page 91). Inventory item assigned. Data model for ResultStatus is defined in XSD (refer section Common Data Format Specifications on page 91). Inventory identifier for the newly created inventory item. If the item is not created successfully, this is omitted.
Item Item/ResultStatus
Type (+) ResultStatus (Mandatory)
Item/InventoryID
String (Optional)
Get Inventory Item This operation retrieves a specific inventory item. The request message format is:
32 |
Table 11: Get Inventory Item Request Data Model Element Name InventoryID Element Type String (Mandatory) The reply message format is: Description Inventory ID to retrieve.
Table 12: Get Inventory Item Reply Data Model Element Name ResultStatus Element Type ResultStatus (Mandatory) Description Data model for ResultStatus is defined in XSD (refer section Common Data Format Specifications on page 91). Inventory Item data structure. Data model for Inventory Item is defined in XSD (refer section Common Data Format Specifications on page 91).
InventoryItem
InventoryItem (Optional)
Get Inventory Items This operation retrieves the list of inventory items for an input criteria. The request message format is:
| 33
The request criteria filters the list of inventory items returned and criteria are additive using the AND operator. None of the request criteria is required. It is strongly recommended to not send a request without applying the filtering criteria, otherwise a large result set may be generated and returned. The results are sorted by start date in a descending order. Table 13: Get Inventory Items Request Data Model Element Name CustomerID Element Type String (Optional, Choice) GetSubscribersItems Boolean (Optional, Choice) Description Customer ID to retrieve inventory items. Flag to indicate if the call should return the list of items associated with dependent subscribers for this customer. Subscriber ID to retrieve inventory items. Product ID to retrieve inventory items. Product type for inventory items to retrieve. This field supports wildcard searches using * or % at
SubscriberID
ProductID
String (Optional)
ProductType
String (Optional)
34 |
Element Name
Element Type
Description the start or end of the string. This is a case-insensitive search parameter.
ProductSubType
String (Optional)
Product sub-type for inventory items to retrieve. This field supports wildcard searches using * or % at the start or end of the string. This is a case-insensitive search parameter. Product description for inventory items to retrieve. This field supports wildcard searches using * or % at the start or end of the string. This is a case-insensitive search parameter. List of item UDFs to retrieve inventory items. Name of the UDF to search Value of the UDF to search. This is a case-insensitive search parameter. The maximum number of items to return. Items are always sorted by ascending Status and ProductType. If a large number of items are found that match the criteria, then only items up to the Count are returned. Pagination element. Items are always sorted by ascending Status and ProductType. Start record index to return items. This index is inclusive. End record index to return items. This index is inclusive. Flag to indicate if the operation should return item information without UDFs. If this element is set to true, then UDFs are omitted. Otherwise the full item is returned.
ProductDescription
String (Optional)
ItemUDF ItemUDF/Name ItemUDF/Value Count
Type (*) String (Mandatory) String (Mandatory) Long (Optional, Choice)
Pagination
Type (Optional, Choice)
Pagination/StartRecord
Long (Mandatory)
Pagination/EndRecord
Long (Mandatory)
ItemSummary
Boolean (Optional)
| 35
Table 14: Get Inventory Items Reply Data Model Element Name ResultStatus Element Type ResultStatus (Mandatory) Description Data model for ResultStatus is defined in XSD (refer section Common Data Format Specifications on page 91). List of inventory items. If inventory items are not found, this element is omitted. Inventory Item data structure. Data model for Inventory item is defined in XSD (refer section Common Data Format Specifications on page 91). Pagination details. This element is included only if pagination is included in the request. Start record index of returned items. This index is inclusive. End record index of returned items. This index is inclusive. Total count of item records that matched the input criteria. This value is used to compose subsequent pagination calls.
InventoryItems
Type (Optional)
InventoryItems/InventoryItem
InventoryItem (*)
Pagination
Type (Optional)
Long (Mandatory)
Long (Mandatory)
Pagination/TotalRecords
Long (Mandatory)
Get User Status This operation retrieves a list of user status from the inventory for the given input criteria. The request message format is:
The following conditions determine the result set returned by the Get User Status operation:
36 |
Status of all customers for which CustomerID is passed in the request is always returned. If a single CustomerID is passed in the request, the operation returns a list of all the subscribers of this particular customer and their status from inventory. If a single customerID and a list of subscriberIDs are passed in the request, the operation returns the status for the subset of subscribers specified by the supplied subscriberIDs for this particular customer from inventory. If no CustomerID or more than one CustomerID and a list of subscriberIDs are passed in the request, the operation returns status for all subscribers specified in the list without taking into consideration their relationship to the customers passed in the request. Table 15: Get User Status Request Data Model Element Name CustomerID SubscriberID Element Type String (*) String (*) (Optional, Choice) The reply message format is: Description Customer ID to retrieve user status. Subscriber ID to retrieve user status.
Table 16: Get User Status Reply Data Model Element Name ResultStatus Element Type ResultStatus (Mandatory) Description Data model for ResultStatus is defined in XSD (refer section Common Data Format Specifications on page 91). Customer user data structure. Customer ID for user status.
Customer Customer/CustomerID
Customer/UserStatus
String (Mandatory)
User status for the customer.
Subscriber
Type (*)
Subscriber user data structure.
| 37
Element Name Subscriber/SubscriberID
Element Type String (Mandatory)
Description Subscriber ID for user status.
Subscriber/ParentCustomerID
String (Optional)
Parent customer ID for the subscriber, if one exists. User status for the subscriber. The valid values are: LOCKED UNLOCKED
Subscriber/UserStatus
String (Mandatory)
Reassign Inventory Item This operation reassigns an existing assigned inventory item from a customer or subscriber to another customer or subscriber. The request message format is:
Table 17: Reassign Inventory Item Request Data Model Element Name InventoryID Element Type String (Mandatory) Description The ID of the inventory item to reassign.
38 |
Element Name EnableRollback
Element Type Boolean (Optional)
Description Flag to indicate a rollback snapshot should be made for the current update. This flag is not being used in this release.
CustomerID
String (Mandatory, Choice)
The ID of the customer to reassign the inventory item. The ID of the subscriber to reassign the inventory item. The ID of the parent customer that the subscriber is reassigned. Inventory item status to be set. The valid statuses are: DRAFT ACTIVE WITHDRAWN
SubscriberID
ParentCustomerID
Status
String (Optional)
Order
Type (Optional)
Order type to add to the order history. Order identifier the product is ordered on. Order line number the product is ordered on. Order line action the product is ordered with. Order date and time the product is ordered. Comments for this order.
Order/OrderID
String (Mandatory)
Order/OrderLineNumber
String (Mandatory)
Order/OrderLineAction
String (Mandatory)
Order/OrderDate
Order/Comments
String (Optional)
Order/CurrentOwnerCustomerID String (Optional, Choice) Order/CurrentOwnerSubscriberID String (Optional, Choice) The reply message format is:
| 39
Table 18: Reassign Inventory Item Reply Data Model Element Name ResultStatus Element Type ResultStatus (Mandatory) Description Example
Data model for ResultStatus ResultStatus is defined in XSD (refer section Common Data Format Specifications on page 91).
Reassign Inventory Items This operation reassigns existing assigned inventory items from a customer or subscriber to another customer or subscriber. The request message format is:
Table 19: Reassign Inventory Items Request Data Model Element Name Item Item/InventoryID Element Type Type (+) String (Mandatory) Description Inventory item reassigned. The ID of the inventory item to be reassigned.
40 |
Element Name Item/EnableRollback
Element Type Boolean (Optional)
Description Flag to indicate a rollback snapshot to be made for the current update. This flag is not being used in this release.
Item/CustomerID
The ID of the customer to reassign the inventory item. The ID of the subscriber to reassign the inventory item. The ID of the parent customer that the subscriber item is reassigned to. Inventory item status to be set. The valid statuses are: DRAFT ACTIVE WITHDRAWN Order type to add to the order history. Order identifier the product is ordered on. Order line number the product is ordered on. Order line action the product is ordered with. Order date and time the product is ordered. Comments for this order.
Item/SubscriberID
Item/ParentCustomerID
Item/Status
String (Optional)
Item/Order
Type (Optional)
Item/Order/OrderID
String (Mandatory)
String (Mandatory)
String (Mandatory)
Item/Order/Comments
String (Optional)
Item/Order/CurrentOwnerCustomerID String (Optional, Choice) Item/Order/CurrentOwnerSubscriberID String (Optional, Choice) The reply message format is:
| 41
Table 20: Reassign Inventory Items Reply Data Model Element Name ResultStatus Element Type ResultStatus (Mandatory) Description Example
Data model for ResultStatus ResultStatus is defined in XSD (refer section Common Data Format Specifications on page 91). Inventory item reassigned Data model for ResultStatus is defined in XSD (refer section Common Data Format Specifications on page 91). InventoryId that was reassigned
Item/InventoryId
String (Mandatory)
Remove Inventory Item This operation removes an inventory item from a customer or subscriber. The request message format is:
Table 21: Remove Inventory Item Request Data Model Element Name InventoryID Element Type String (Mandatory) The reply message format is: Description The ID of the inventory item to be removed.
42 |
Table 22: Remove Inventory Item Reply Data Model Element Name ResultStatus Element Type ResultStatus (Mandatory) Description Example
Remove Inventory Items This operation removes inventory items from a customer or subscriber. This is a bulk interface version of Remove Inventory Item. The request message format is:
Table 23: Remove Inventory Items Request Data Model Element Name InventoryID Element Type String (+) Description The ID of the inventory item to be removed.
Table 24: Remove Inventory Items Reply Data Model Element Name ResultStatus Element Type ResultStatus (Mandatory) Description Data model for ResultStatus is defined in XSD (refer section Common Data Format Specifications on page 91).
| 43
Element Name Item Item/ResultStatus
Element Type Type (+) ResultStatus (Mandatory)
Description Inventory item removed Data model for ResultStatus is defined in XSD (refer section Common Data Format Specifications on page 91). InventoryId that was removed.
Item/InventoryId
String (Mandatory)
Rollback Inventory Item This operation rolls back the previous update to an inventory item. The request message format is:
Table 25: Rollback Inventory Item Request Data Model Element Name InventoryID Element Type String (Mandatory) The reply message format is: Description The ID of the inventory item to rollback.
Table 26: Rollback Inventory Item Reply Data Model Element Name ResultStatus Element Type ResultStatus (Mandatory) Description Example
Rollback Inventory Items This operation rolls back the previous update to inventory items. This is a bulk interface version of Rollback Inventory Item. The request message format is:
44 |
Table 27: Rollback Inventory Items Request Data Model Element Name InventoryID Element Type String (+) Description The ID of the inventory item to rollback.
Table 28: Rollback Inventory Items Reply Data Model Element Name ResultStatus Element Type ResultStatus (Mandatory) Description Data model for ResultStatus is defined in XSD (refer section Common Data Format Specifications on page 91). Inventory item rolled back Data model for ResultStatus is defined in XSD (refer section Common Data Format Specifications on page 91). Inventory item ID that was rolled back.
Type (*) ResultStatus (Mandatory)
Item/InventoryID
String (Mandatory)
Set User Status This operation sets the status of the specified users in the inventory. If the users are not present in the hierarchy, an appropriate error code is returned. All users have the same status as specified in the request. The request message format is:
| 45
Table 29: Set User Status Request Data Model Element Name CustomerID Subscriber Subscriber/SubscriberID Element Type String (*) Type (*) String (Mandatory) Description Customer ID of the user to set the status. Subscriber type Subscriber ID of the user to set the status. This is required for both non-corporate and corporate subscribers. Parent Customer ID of the subscriber user to set the status. This is required for corporate subscribers. The status to assign to the users. The valid values are: LOCKED UNLOCKED
Subscriber/ParentCustomerID
String (Optional)
UserStatus
String (Mandatory)
Table 30: Set User Status Reply Data Model Element Name ResultStatus Element Type ResultStatus (Mandatory) Description Example
Update Inventory Item This operation updates the details of an inventory item. The update operation allows updating the following parameters. The effect on each parameter is as follows: Parameter Status StartDate EndDate Order UDF Description Inventory item status is updated to the specified value. Inventory item start date is updated to the specified value. Inventory item end date is updated to the specified value. Specified order is added to the order history for the inventory item. Existing order history entries are not changed. The set of UDFs is replaced. The effect of this is:
46 |
Parameter
Description New UDF entries are added. Changed UDF entries are modified UDF entries currently present in the inventory item but not in the input UDF list are removed. If the UDFs node is present with no UDF elements, all UDFs are removed.
The request message format is:
Table 31: Update Inventory Item Request Data Model Element Name InventoryID Element Type String (Mandatory) EnableRollback Boolean (Optional) Status String (Optional) Description The ID of the inventory item to update. Flag to indicate a rollback snapshot should be made for the current update. Inventory item status to be set. The valid statuses are: DRAFT ACTIVE WITHDRAWN
| 47
Element Name StartDate
Element Type DateTime (Optional)
Description The date that the product went to ACTIVE status. The date that the product went to WITHDRAWN status. Order type to add to the order history. Order identifier the product is ordered on. Order line number the product is ordered on. Order line action the product is ordered with. Order date and time the product is ordered. Comments for this order.
EndDate
DateTime (Optional)
Order
Type (Optional)
Order/OrderID
String (Mandatory)
Order/OrderLineNumber
String (Mandatory)
Order/OrderLineAction
String (Mandatory)
Order/OrderDate
Order/Comments
String (Optional)
Order/CurrentOwnerCustomerID String (Optional, Choice) Order/CurrentOwnerSubscriberID String (Optional, Choice) UDFs Type (Optional)
Current customer owner of this item. This does not need to be populated on this operation. Current subscriber owner of this item. This does not need to be populated on this operation. UDF type. Note that if this element is present with no UDF nodes beneath it, then all UDFs are removed from the cache. User defined fields associated with the product. User defined field name.
UDFs/UDF UDFs/UDF/Name
UDFs/UDF/Value
String (Mandatory)
48 |
Table 32: Update Inventory Item Reply Data Model Element Name ResultStatus Element Type ResultStatus (Mandatory) Description Example
Update Inventory Items This operation updates the details of inventory items. This is a bulk interface version of Update Inventory Item. Refer to the Update Inventory Item operation for additional information about update parameters. The request message format is:
Table 33: Update Inventory Items Request Data Model Element Name Item Item/InventoryID Element Type Type (+) String (Mandatory) Item/EnableRollback Boolean (Optional) Item/Status String (Optional)
Description Inventory item updated. The ID of the inventory item to update. Flag to indicate a rollback snapshot should be made for the item to update. Inventory item status to be set.
| 49
Element Name
Element Type
Description The valid status are: DRAFT ACTIVE WITHDRAWN
Item/StartDate
DateTime (Optional)
The date that the product went to ACTIVE status. The date that the product went to WITHDRAWN status. Order type to add to the order history.
Item/EndDate
DateTime (Optional)
Item/Order
Type (Optional)
Item/Order/OrderID
String (Mandatory)
Order identifier the product is ordered on. Order line number the product is ordered on. Order line action the product is ordered with. Order date and time the product is ordered. Comments for this order.
String (Mandatory)
String (Mandatory)
Item/Order/Comments
String (Optional)
Item/Order/CurrentOwnerCustomerID String (Optional, Choice) Item/Order/CurrentOwnerSubscriberID String (Optional, Choice) Item/UDFs Type (Optional)
Current customer owner of this item. This does not need to be populated on this operation. Current subscriber owner of this item. This does not need to be populated on this operation. UDF type. Note that if this element is present with no UDF nodes beneath it, then all UDFs are removed from the cache. User defined fields associated with the product. User defined field name.
Item/UDFs/UDF Item/UDFs/UDF/Name
Item/UDFs/UDF/Value
String (Mandatory)
50 |
The following tables describes the rules for updating UDFs in the Inventory: GLB_StoreInpCharUDFsOnly ProductInput Characteristics PERSIST_VALUE GLB_IgnoreUDF (defined in the PersistFlag product charactertistic) FALSE FALSE TRUE x x FALSE (default) TRUE x x x UDF persisted
TRUE (default value) TRUE (default value) TRUE (default value) FALSE TRUE Where: x : Any value.
TRUE TRUE TRUE x x
FALSE TRUE TRUE TRUE FALSE
1. With the default values of the global variables GLB_StoreInpCharUDFsOnly and GLB_IgnoreUDFPersistFlag, the UDFs can be persisted only if the PERSIST flag in the product model is true. 2. To persist the UDFs associated with the inventory, irrespective of the product model, set the GLB_StoreInpCharUDFsOnly to false. The reply message format is:
Table 34: Update Inventory Items Reply Data Model Element Name ResultStatus Element Type ResultStatus (Mandatory) Description Data model for ResultStatus is defined in XSD (refer section Common Data Format Specifications on page 91). Inventory item updated. Data model for ResultStatus is defined in XSD (refer section Common Data Format Specifications on page 91).
| 51
Element Name Item/InventoryID
Description Inventory item ID that was updated.
Offer Service
This service contains operations for saving and validating offers. Get Offer Details This operation retrieves the offer details for an order reference and returns to the calling application. This is only for offers saved using the Save Offer function. The submitted orders are not returned. The request message format is:
Table 35: Get Offer Details Request Data Model Element Name OrderRef Element Type String (Mandatory) Version Long (Optional) Description The order reference ID. This must be an exact match. The offer version to retrieve. If this is omitted, the offer with the highest version number for the OrderRef is returned.
Table 36: Get Offer Details Reply Data Model Element Name ResultStatus Element Type ResultStatus (Mandatory) Description Example
Data model for ResultStatus ResultStatus is defined in XSD (refer section Common Data Format Specifications on page 91). Order data structure. Data model for Order is defined in XSD (refer section Common Data
Order
Order (Optional)
52 |
Element Name
Element Type
Description Format Specifications on page 91). If the offer is not found, this element is omitted.
Example
Get Offers This operation retrieves the offers for the specified criteria and returns to the calling application. This is only for offers saved using the Save Offer function. The submitted orders are not returned. The request message format is:
The request criteria is used to filter the list of offers returned and criteria using the AND operator. The request criteria is not required, but it is strongly recommended not to send it in a request without applying the filter criteria. Otherwise, a large resultset may be returned. The returned offers are sorted by submission date in a descending order.
| 53
Table 37: Get Offers Request Data Model Element Name OrderRef Element Type String (Optional) Description The order reference to retrieve orders. This field supports wildcard searches using * or % at the start or end of the string. This is a case-insensitive search parameter. Flag to indicate if the operation should only return the latest version of each offer. If this field is not present, it is assumed to be false. The version number for the offer to retrieve. The ID for the customer to retrieve offers. This field supports wildcard searches using * or % at the start or end of the string. This is a case-insensitive search parameter. The ID of the subscriber to retrieve offers. This field supports wildcard searches using * or % at the start or end of the string. This is a case-insensitive search parameter. Specifying SubscriberID returns all offers that include the subscriber, including multiple-subscriber offers. DateRange Type (Optional) DateRange/StartDate Date (Optional) The earliest order date to return offers. This date is inclusive. This is based on the Order Submission Date on the original offer. Order Submission Dates before this date is excluded. The latest date to return offers. This date is inclusive. This is based on the Order Submission Date on the original offer. Order Submission Dates after this date is excluded. The order status to return offers. This is a case-insensitive search parameter. List of order header UDFs to return offers. Order date range type.
LatestVersion
Boolean (Choice, Optional)
Version
Long (Choice, Optional)
CustomerID
String (Optional)
SubscriberID
String (Optional)
DateRange/EndDate
Date (Optional)
OrderStatus
String (Optional)
HeaderUDF
Type (*)
54 |
Element Name HeaderUDF/Name HeaderUDF/Value OrderLineUDF
Element Type String (Mandatory) String (Mandatory) Type (*)
Description Name of the UDF to search Value of the UDF to search. This is a case-insensitive search parameter. List of order line UDFs to return offers. If any order line contains a UDF match then the entire offer is returned. Name of the UDF to search Value of the UDF to search. This is a case-insensitive search parameter. The maximum number of offers to return. Offers are always sorted by descending Order Date, Order Ref, and Version. If a large number of orders are found that match other criteria, then only the orders up to the Count is returned. Pagination element. Offers are always sorted by descending Order Date, Order Ref, and Version. Start record index to return offers. This index is inclusive. End record index to return offers. This index is inclusive. Flag to indicate if the operation should only return order header information. If this element is set to true, only order headers are returned. Otherwise the full offer is returned.
OrderLineUDF/Name OrderLineUDF/Value Count
String (Mandatory) String (Mandatory) Long (Optional, Choice)
Pagination
Long (Mandatory)
Long (Mandatory)
OrderSummary
Boolean (Optional)
| 55
Table 38: Get Offers Reply Data Model Element Name ResultStatus Element Type ResultStatus (Mandatory) Description Example
Data model for ResultStatus ResultStatus is defined in XSD (refer section Common Data Format Specifications on page 91). List of Offers. If no offers are found this element is omitted. Order data structure. Data model for Order is defined in XSD (refer section Common Data Format Specifications on page 91). Pagination details. This element is included only if pagination was included in the request. Start record index of returned offers. This index is inclusive. End record index of returned offers. This index is inclusive. Total count of offer records that matched the input criteria. This value is used to compose subsequent pagination calls.
Offers
Type (Optional)
Offers/Order
Order (*)
Pagination
Type (Optional)
Long (Mandatory)
Long (Mandatory)
Pagination/TotalRecords Long (Mandatory)
Remove Offer This operation removes the offer details from the offer configuration and validation engine for the given order reference and version.
OrderRef must be specified. If details are not provided then the latest version of the offer is removed. If a Version is specified, then the particular version is removed. If the AllVersions flag is set to true, then all versions of the
offer are removed. The request message format is:
56 |
Table 39: Remove Offer Request Data Model Element Name OrderRef Element Type String (Mandatory) Version Long (Optional) AllVersions Boolean (Optional) The reply message format is: Flag to indicate that all versions of the offer should be removed. The specific version to be removed. Description The order reference ID.
Table 40: Remove Offer Reply Data Model Element Name ResultStatus Element Type ResultStatus (Mandatory) Description Data model for ResultStatus is defined in XSD (refer section Common Data Format Specifications on page 91).
Save Offer This operation accepts an offer and stores it in the offer configuration and validation engine for retrieval. Do not specify the OrderID in the input Order document as it is ignored. If OrderRef is not specified, a value is generated and returned to the calling application. If the offer could not be saved, the OrderRef is not returned. The order is not validated. If OrderRef is specified and an offer already exists in the cache, that offer is updated and version number is increased to the next higher version. Otherwise, a new offer is created in the cache. The request message format is:
| 57
Table 41: Save Offer Request Data Model Element Name Order Element Type Order (Mandatory) Description Order data structure. Data model for Order is defined in XSD (refer section Common Data Format Specifications on page 91).
Table 42: Save Offer Reply Data Model Element Name ResultStatus Element Type ResultStatus (Mandatory) Description Data model for ResultStatus is defined in XSD (refer section Common Data Format Specifications on page 91). Order reference number. If the offer could not be saved then this element is omitted. Version of the saved offer. If the offer could not be saved then this element is omitted.
OrderRef
String (Optional)
Version
Long (Optional)
Validate Offer This operation accepts an offer for validation and returns either a pass or fail. If the validation fails, a list of error messages are returned. Validation takes the form of rules configured in the offer configuration and validation engine. These rules evaluate all aspects of the offer and return all invalid items rather than stopping on the first validation failure. Validations are categorized into Warning or Error. A warning is a validation failure but not serious enough to reject an offer. An error is a validation failure that is serious enough to reject an offer. The Validation Pass parameter is based on the resultant validation message types. The rules are as follows: No Messages Warnings Only Warnings and Errors Errors Only The request message format is: Validation Pass = true Validation Pass = true Validation Pass = false
58 |
Table 43: Validate Offer Request Data Model Element Name Order Element Type Order (Mandatory) Description Order data structure. Data model for Order is defined in XSD (refer section Common Data Format Specifications on page 91).
Table 44: Validate Offer Reply Data Model Element Name ResultStatus Element Type ResultStatus (Mandatory) Description Data model for ResultStatus is defined in XSD (refer section Common Data Format Specifications on page 91). Returns true for a valid order, or false for an invalid order. This returns false if there are any error messages returned. If warning messages are returned or no messages are returned, this returns true. Validation messages for the order. The validation service validates all elements in the order and returns multiple validation messages. Line number in the order that the validation message relates to. If this is omitted then the message is general for the entire order.
ValidationPass
Boolean (Mandatory)
Message
Type (*)
Message/LineNumber
String (Optional)
| 59
Element Name Message/Type
Description Validation message type. The valid values are: WARNING ERROR
Message/Code
String (Mandatory)
Unique validation message code.
Message/Description
String (Mandatory)
Validation message description and possibly remedial action required.
Get Offer Price This public interface is provided by Offering Management to allow pricing of a particular Offer based on the configuration in the Product Catalog. The request message format is:
Figure 7: Get Offer Price Request Field OrderRef Version Order Type String Long Order Cardinality Mandatory Optional Mandatory Description Unique identifier for the Offer to price. Version of the Offer to price. If this is omitted then the latest version is priced. Order data structure. Data model for Order is defined in XSD (refer Order (Optional) Order section Common Data Format Specifications). Transaction ID.
BusinessTransactionID String The reply message format is:
Optional
60 |
Figure 8: Get Offer Price Reply Field Type Cardinality Optional Mandatory Optional Optional Optional Description
BusinessTransactionID String ResultStatus OrderLines TotalPrice OverallPrice Long OrderLine Total Price Overall Price
Product prices are stored in the Product Catalog, and assigned to individual Products. When applied to an Offer, these Product prices are computed on an order line basis by using the Product ID for that order line. Each order line has a computed summary price and an overall summary price for the Offer, and total price for the Offer is computed by summing the individual order line prices. Various price entities and types are supported: Entity Customer Price Subscriber Price Price Type One Time Price Recurring Price Description A price that is charged to a Customer-level entity A price that is charged to a Subscriber-level entity Description A price that is charged only once A price that is charged multiple times over a defined term with a given periodic frequency. For example, Monthly, Daily, Yearly, etc.
Price types and price entities combine together to create the following pricing matrix: Price Entities Customer Price Types One Time Price Recurring Price Yes - Single Yes - Multiple Subscriber Yes - Single Yes - Multiple
| 61
In addition to the catalog prices, the pricing rules support the following order line price types that apply only to One Time prices: Order Line Price Type Supplement Price Override Price Description A price that is added to the one-time price for the given order line A price that is used instead of the one-time price for the given order line
Computing the order line catalog price is based on the pricing matrix and the following rules: Price Matrix Node Customer One Time Price Computation Sum of all prices for the order line Product ID where: Price Type is One Time Order has a CustomerID and Order Line doesn't have a SubscriberID Sum of all prices for the order line Product ID where: Price Type is One Time Order has a SubscriberID or Order Line has a SubscriberID Sum of all prices for the order line Product ID grouped by Price Period where: Price Type is Recurring Order has a CustomerID and Order Line doesn't have a SubscriberID Sum of all prices for the order line Product ID grouped by Price Period where: Price Type is Recurring Order has a SubscriberID or Order Line has a SubscriberID
Subscriber One Time Price
Customer Recurring Price
Subscriber Recurring Price
The recurring prices are always grouped by Price Period. This is required so that only prices of the same price period are summed together. Therefore only Monthly Price Period prices are summed with other Monthly Price Period prices, and not with Yearly or Daily Price Period prices. Prices can also be configured by price band. Each Price Entity on the offer may have its own price band. Price bands may be used for One Time or Recurring price types. The price band for a particular Price Entity is determined by assigning a CompatibleSegment Price Band segment to a product that Price Entity has ordered. If multiple products for that Price Entity have CompatibleSegment Price Band relationships then only the first one found is used. This price band is then used to choose the correct price for other products for that Price Entity on the offer that are configured using price bands. Price banded products have multiple prices associated with it, but not all prices are used. Each product has a ProductPricedBy relationship to the price. Each price in turn has a PriceRequiresSegment relationship to the relevant Price Band segment. There may also be a default price band associated with the product that does not have a PriceRequiresSegment relationship to any segment. If a price with a matching price band for the Price Entity is found then that price will be used in the computation. If no matching price band was found, then the default price is used in the computation instead. If no default price is set and no matching price band is found, then no price is included in the computation. The over all Offer price is computed by summing all the prices within the same Price Matrix Node over all the order lines, thereby giving an overall price total for an Offer. The following table shows the Overall Offer Price Computation Rules:
62 |
Price Matrix Node Customer One Time Price Subscriber One Time Price Customer Recurring Price Subscriber Recurring Price
Computation Sum of all order line prices of type Customer One Time Price Sum of all order line prices of type Subscriber One Time Price grouped by Subscriber ID Sum of all order line prices of type Customer Recurring Price grouped by Price Period Sum of all order line prices of type Subscriber Recurring Price grouped by Subscriber ID and Price Period
The Subscriber prices are always grouped by Subscriber ID. This is required so that only prices that are for the same Subscriber are summed together. The total Offer price is computed by summing all the one-time prices and all the recurring prices grouped by price period alone. This differs from the overall Offer price in that it doesn't distinguish between Customer and Subscriber, or within individual Subscribers.
Product Service
This service contains operations that retrieve information about products. Get Eligible Products This operation retrieves a list of products by applying eligibility rules to the product catalogue and returns details to the calling application. The list of products returned is determined by the filtering criteria passed into the operation. These criteria are additive. The product information returned is limited. To get full product information, invoke the Get Product Information operation for each product passing the ProductID returned from this call. For a product list associated with a particular customer ID, the product list is filtered based on the request for the criteria such as Segment, productName, productCharacteristic, etc. The product list is then returned. If a customer associated with any CustomerID is not found, or if a customer is found but no products are associated with that customer, then: The Segment list is used to search for a list of products matching the segments on the following criteria for a product to match. The product must have CompatibleSegment relationships to ALL the segments specified on a request. If a product has additional CompatibleSegment relationships to segments not in the request, then the list is returned. If a product is missing any CompatibleSegment relationships to segments in the request, then the list is not returned. The list is filtered by the criteria (productName, productCharacteristic, etc) on request. The filtered list is returned. The request message format is:
| 63
Table 45: Get Eligible Products Request Data Model Element Name SubscriberID Element Type String (Optional) ParentCustomerID String (Optional) Description The ID of the subscriber to retrieve eligible products. The subscriber must exist within the cache. The ID of the parent customer for a subscriber to retrieve eligible products. The customer must exist within the cache. The ID of the role that a subscriber has within the parent customer organization. The ID of the customer to retrieve eligible products. The customer must exist within the cache.
RoleID
String (*)
CustomerID
String (Mandatory)
64 |
Element Name Segment
Element Type Type (*)
Description List of segments used to filter the list of returned eligible products. Only products that match all elements in the list of segments is returned. Name of the segment
Segment/Name
String (Mandatory)
Segment/Type
String (Mandatory)
Type of the segment.
ParentProductID
String (Optional)
Parent product ID for the products to retrieve. Products that are children of the specified product using ProductComprisedOf relationship is returned. Product name for the products to retrieve. This field supports wildcard searches using * or % at the start or end of the string. This is a case-insensitive search parameter. Product type for the products to retrieve. This field supports wildcard searches using * or % at the start or end of the string. This is a case-insensitive search parameter. Product sub type for the products to retrieve. This field supports wildcard searches using * or % at the start or end of the string. This is a case-insensitive search parameter. Product description for the products to retrieve. This field supports wildcard searches using * or % at the start or end of the string. This is a case-insensitive search parameter. List of characteristics used to filter the list of returned eligible products. Only products that have the specified characteristics is returned.
ProductName
String (Optional)
ProductType
String (Optional)
ProductSubType
String (Optional)
ProductDescription
String (Optional)
ProductCharacteristic
Type (*)
| 65
Element Name ProductCharacteristic/Name
Description Characteristic name. Valid for Instance, Feature, or Input characteristics. Characteristic discrete value. Valid only for Instance characteristics. Order date to use for filtering the returned list of products. Only products where the order date lies between the start date and end date is returned. Product status for products to retrieve. The maximum number of products to return. Products are always sorted by ascending ProductID. If a large number of products are found that match the criteria then only the products up to the Count are returned. Pagination element. Products are always sorted by ascending ProductID. Start record index to return products. This index is inclusive. End record index to return products. This index is inclusive.
ProductCharacteristic/Value
String (Optional)
OrderDate
DateTime (YYYY-MM-DDThh:mm:ss) (Optional)
Status
String (Optional)
Count
Long (Optional, Choice)
Pagination
Long (Mandatory)
Long (Mandatory)
66 |
Table 46: Get Eligible Products Reply Data Model Element Name ResultStatus Element Type ResultStatus (Mandatory) Description Example
Data model for ResultStatus ResultStatus is defined in XSD (refer section Common Data Format Specifications on page 91). List of products that a customer is eligible to order. If no products are found this element is omitted. Product model data structure. Data model for Product is defined in XSD (refer section Common Data Format Specifications on page 91). Pagination details. This element is included only if pagination was included in the request. Start record index of returned products. This index is inclusive. End record index of returned products. This index is inclusive. Total count of product records that matched the input criteria. This value is used to compose subsequent pagination calls.
Products
Type (Optional)
Products/Product
Product (*)
Pagination
Type (Optional)
Long (Mandatory)
Long (Mandatory)
Pagination/TotalRecords Long (Mandatory)
Get Ineligible Subscribers This operation returns a list of ineligible subscribers for the specified input criteria. A subscriber is ineligible if the specified ProductID is configured to have ConcurrentOrder set to false and the subscriber user is locked in the inventory. The request message format is:
| 67
Table 47: Get Ineligible Subscribers Request Data Model Element Name ParentCustomerID Element Type String (Mandatory) ProductID String (Mandatory) The reply message format is: Description Customer ID for the parent customer for the subscribers to return. The ID of the product to check for ConcurrentOrder flag.
Table 48: Get Ineligible Subscribers Reply Data Model Element Name ResultStatus Element Type ResultStatus (Mandatory) Description Example
Data model for ResultStatus ResultStatus is defined in XSD (refer section Common Data Format Specifications on page 91). Subscriber ID for subscribers that are ineligible to order the specified product.
IneligibleSubscriberID
String (*)
Get Product Information This operation retrieves the details for a given product and returns to the calling application. The request message format is:
Table 49: Get Product Information Request Data Model Element Name ProductID Element Type String (+) Description The ID of the product. This must be an exact match.
68 |
Table 50: Get Product Information Reply Data Model Element Name ResultStatus Element Type ResultStatus (Mandatory) Description Example
Data model for ResultStatus is ResultStatus defined in XSD (refer section Common Data Format Specifications on page 91). Information on the product. If the product is not found this element is omitted. Product data structure. Data model for product is defined in XSD (refer section Common Data Format Specifications on page 91). List of characteristics for the product Characteristic data structure. Data model for characteristic is defined in XSD (refer section Common Data Format Specifications on page 91).
ProductInformation
Type (*)
ProductInformation/Product
Product (Mandatory)
ProductInformation/Characteristics
Type (Mandatory)
ProductInformation/Characteristics/Characteristic Characteristic (*)
Get Segments This operation retrieves the list of segments stored in the product cache. The request message format is:
Table 51: Get Segments Request Data Model Element Name SegmentType Element Type String (Optional) The reply message format is: Description The type of segment to filter the result set.
| 69
Table 52: Get Segments Reply Data Model Element Name ResultStatus Element Type ResultStatus (Mandatory) Description Example
Data model for ResultStatus ResultStatus is defined in XSD (refer section Common Data Format Specifications on page 91). List of segments.
Segments
Type (Optional)
Segments/Segment
Segment (*)
Segment data structure. Data model for Segment is defined in XSD (refer section Common Data Format Specifications on page 91). If no segments were found for the given SegmentType this element is omitted.
Subscriber Service
This service contains operations that create, update, remove, and retrieve subscribers from the order management system. There is also an operation that validates subscriber orders. Create Subscriber This operation creates a subscriber in the order management system. The request message format is:
Table 53: Create Subscriber Request Data Model Element Name Subscriber Element Type Subscriber (Mandatory) Description Subscriber data structure. Data model for Subscriber is defined in XSD (refer section Common Data Format Specifications on page 91). In this structure, the following optional fields are ignored if populated:
70 |
Element Name
Element Type
Description Subscriber ID is returned in the reply.
Table 54: Create Subscriber Reply Data Model Element Name ResultStatus Element Type ResultStatus (Mandatory) Description Data model for ResultStatus is defined in XSD (refer section Common Data Format Specifications on page 91). Unique identifier for the newly created subscriber. If the operation call fails this element is omitted.
SubscriberID
String (Optional)
Get Customer Image For Subscriber This operation retrieves the configured customer image for a given subscriber ID and returns to the calling application. In addition to the subscriber, the list of currently subscribed products is also returned. This operation only returns subscribers stored in the cache. To retrieve inventory for subscribers not stored in the cache, use the GetInventoryItems operation. The request message format is:
Table 55: Get Customer Image For Subscriber Request Data Model Element Name SubscriberID Element Type String (Mandatory) The reply message format is: Description The ID of the subscriber to retrieve.
| 71
Table 56: Get Customer Image For Subscriber Reply Data Model Element Name ResultStatus Element Type ResultStatus (Mandatory) Description Data model for ResultStatus is defined in XSD (refer section Common Data Format Specifications on page 91). Subscriber data structure. Data model for subscriber is defined in XSD (refer section Common Data Format Specifications on page 91). If the subscriber was not found for the given SubscriberID, this element is omitted. List of products this subscriber has in the inventory. If the subscriber was not found for the given SubscriberID, or if the subscriber has no current inventory, this element is omitted. InventoryItem data structure. Data model for InventoryItem is defined in XSD (refer section Common Data Format Specifications on page 91). If the subscriber was not found for the given SubscriberID, this element is omitted.
Subscriber
Subscriber (Optional)
SubscribedInventory
Type (Optional)
SubscribedInventory/InventoryItem InventoryItem (*)
Remove Subscriber This operation removes the specified subscriber from the order management cache. This operation does not cascade-remove any related inventory items that the subscriber owns in the subscriber inventory. The request message format is:
Table 57: Remove Subscriber Request Data Model Element Name SubscriberID Element Type String (Mandatory) The reply message format is: Description The ID of the subscriber to be removed.
72 |
Table 58: Remove Subscriber Reply Data Model Element Name ResultStatus Element Type ResultStatus (Mandatory) Description Data model for ResultStatus is defined in XSD (refer section Common Data Format Specifications on page 91).
Update Subscriber This operation updates a subscriber in the order management system. All fields in the subscriber class are updated so the calling application must pass in values for all fields whether they have changed or not. A subscriber update can include changes to subscriber attributes or reclassification to a different parent customer. The request message format is:
Table 59: Update Subscriber Request Data Model Element Name Subscriber Element Type Subscriber (Mandatory) Description Subscriber data structure. Data model for Subscriber is defined in XSD (refer section Common Data Format Specifications on page 91). Subscriber ID is required to update the appropriate record. All other fields are updated, so fields that have not changed must be populated with the previous value. The reply message format is:
Table 60: Update Subscriber Reply Data Model Element Name ResultStatus Element Type ResultStatus (Mandatory) Description Data model for ResultStatus is defined in XSD (refer section Common Data Format Specifications on page 91).
Disabling SOAP_HTTP and SOAP_JMS Services

The SOAP/HTTP and SOAP/JMS service can be disabled on per OMS server instance basis. This may be needed if these is requirement to configure two separate oms instances exclusively for SOAP/HTTP and SOAP/JMS.
| 73
Perform the following steps to achieve this: 1. Disable SOAP/HTTP a. Deploy the omsServer instance. b. Once deployed, open the file
${CATALINA_HOME}\webapps\omsServer\WEB-INF\classes\spring\application-context.xml. c. Search for the jaxws:endpoint element with attribute id and value inventoryServiceHttpEndpoint. d. Add/Modify the publish attribute and set the value to false. e. Perform steps c and d for customerServiceHttpEndpoint, subscriberServiceHttpEndpoint, productServiceHttpEndpoint, and offerServiceHttpEndpointt. f. The example of how the configuration looks like after the attribute is modified: <jaxws:endpoint id="inventoryServiceHttpEndpoint" implementor="#inventoryServiceHTTP" wsdlLocation="classpath:AF_AFS/InventoryServiceHTTP.wsdl" address="/InventoryServiceHTTP" xmlns:s="http://www.tibco.com/AFF/OCV/services/wsdl/HTTP/inventory" serviceName="s:InventoryServiceHTTP" publish="false">
2. Disable SOAP/JMS a. Deploy the omsServer instance. b. Once deployed, open the file
${CATALINA_HOME}\webapps\omsServer\WEB-INF\classes\spring\application-context.xml. c. Search for the jaxws:endpoint element with attribute id and value inventoryServiceJMSEndpoint. d. Add/Modify the publish attribute and set the value to false. e. Perform steps c and d for customerServiceJMSEndpoint, subscriberServiceJMSEndpoint, productServiceJMSEndpoint, and offerServiceJMSEndpoint. f. The example of how the configuration looks like after the attribute is modified: <jaxws:endpoint id="inventoryServiceJMSEndpoint" address="jms://" implementor="#inventoryServiceJMS" serviceName="c:InventoryServiceJMS" wsdlLocation="classpath:AF_AFS/InventoryServiceJMS.wsdl" publish="false" xmlns:c="http://www.tibco.com/AFF/OCV/services/wsdl/JMS/inventory">
Chapter
3
Order Management Services
The location of all the OMS WebService WSDLs is $AF_HOME/schemas/wsdl.
Topics Order Service Purge Order Service
Order Service
This service contains operations regarding submitting and retrieving orders. Cancel Order This operation cancels the specified order in the orchestration engine. The order must be previously submitted successfully and exist in the orchestration engine database. This function extracts the original order and resubmits it as an amendment with all order line actions set to CANCEL. The request message format is:
Table 61: Cancel Order Request Data Model Element Name ExternalBusinessTransactionID orderID Element Type String String (Mandatory, Choice) orderRef String (Mandatory, Choice) Description Transaction ID sent by client. The ID of the Order generated by OMS. This must be an exact match. The client order reference ID. This must be an exact match.
76 |
Element Name rollback The reply message format is:
Element Type anyType
Description
Table 62: Cancel Order Response Data Model Element Name orderID Element Type String (Mandatory, Choice) orderRef String (Mandatory, Choice) message ExternalBusinessTransactionID BusinessTransactionID String String String Description The ID of the Order generated by OMS. This must be an exact match. The client order reference ID. This must be an exact match. Interactive message sent to client confirming request processing. Transaction ID sent by client. Transaction ID generated by OMS, and used internally by OMS and Orchestrator.
Get Order Details This operation retrieves the order details for a given order ID or order reference, and returns to the calling application. The request message format is:
| 77
Table 63: GetOrderDetailsRequest Data Model Element Name OrderID Element Type String (Mandatory, Choice) OrderRef String (Mandatory, Choice) ExternalBusinessTransactionID includeOrderRequest String boolean Description The ID of the Order generated by OMS. This must be an exact match. The client order reference ID. This must be an exact match. Transaction ID sent by client. This flag determines whether or not to include the original request in the response. This flag determines whether or not to include all the amendments for the order in the response.
includeAmendments
boolean
Table 64: GetOrderDetailsResponse Data Model Element Name orderType Element Type orderType (Optional) Description Order data structure. Data model for Order is defined in XSD (refer section Common Data Format Specifications on page 91). If the order is not found this element is omitted. Example
Get Orders This operation retrieves the orders for the specified subscriber or customer and returns to the calling application. The request message format is:
78 |
The request criteria is used to filter the resulting list of orders returned and criteria are additive using the AND operator. The request criteria is not required, but it is recommended to pass in a request after applying the filtering criteria. Otherwise, a very large resultset may be generated and returned. The results are limited to a maximum of 1000 orders. The returned orders are sorted by submission date in a descending order. Table 65: Get Orders Request Data Model Element Name ExternalBusinessTransactionID orderID Element Type String String (Optional) Description Transaction ID sent by client. The ID for the order to retrieve orders. This field supports wildcard searches using * or % at the start or end of the string. This is a case-insensitive search parameter. The order reference to retrieve orders. This field supports wildcard searches using * or % at the start or end of the string. This is a case-insensitive search parameter.
orderRef
String (Optional)
| 79
Element Name customerID
Element Type String (Optional)
Description The ID for the customer to retrieve orders. This field supports wildcard searches using * or % at the start or end of the string. This is a case-insensitive search parameter. The ID of the subscriber to retrieve orders. This field supports wildcard searches using * or % at the start or end of the string. Specifying subscriberID returns all orders that include the subscriber, including multiple-subscriber orders.
subscriberID
String (Optional)
dateRange/startDate
Date (YYYY-MM-DD)
The earliest order date to return orders. This date is inclusive. This is based on the OrderSubmission Date on the order. Order submission dates before this date are excluded. The latest date to return orders. This date is inclusive. This is based on the Order Submission Date on the order. Order submission dates after this date are excluded. Order status. Name of UDF. Value of UDF. Name of UDF. Value of UDF. Inclusive start record index. Inclusive end record index. Flag to indicate if the operation should only return order header information.
dateRange/endDate
Date (YYYY-MM-DD)
status headerUDF/name headerUDF/value orderLineUDF/name orderLineUDF/value pagination/startRecord pagination/endRecord orderSummary
String String String String String long long boolean
80 |
Table 66: Get Orders Response Data Model Element Name Orders Element Type Type (Optional) pagination/startRecord long (Mandatory) pagination/endRecord long (Mandatory) ExternalBusinessTransactionID String Description List of Orders. If no orders are found this element is omitted. Start record index of returned orders. This index is inclusive. End record index of returned orders. This index is inclusive. Transaction ID sent by client.
Get Order Execution Plan This operation retrieves the order execution plans for a given order and returns to the calling application. The request message format is:
Table 67: Get Order Execution Plan Request Data Model Element Name Element Type Description Transaction ID sent by client. The ID of the Order. This must be an exact match.
ExternalBusinessT ransactionID String orderID String (Mandatory, Choice) orderRef String (Mandatory, Choice) The reply message format is:
The order reference ID. This must be an exact match.
| 81
Table 68: Get Order Execution Plan Reply Data Model Element Name Element Type Description Transaction ID sent by client. Execution Plan data structure. Data model for Execution Plan is defined in XSD (refer section Common Data Format Specifications on page 91). If no Execution Plan was found this element is omitted.
ExternalBusinessTransactionID String Plan Type (Optional)
Submit Order This operation accepts an order for submission to the order management system and returns the order ID and order reference to the calling application. If the order is being submitted for the first time, do not specify the Order ID in the input. A value is generated internally. If the order is an amendment to a previously submitted order, orderRef must be specified. If orderRef is not specified, a value is generated and returned to the calling application. This value is always generated whether the order passed validation or not. For SOAP over JMS Web services, the length of orderRef should be less than or equal to 100 characters. If the Router Configuration is selected as filteringRouter, then submitOrder must have a UDF with UDF Name as "Orchestrator" in the order header. This information is required to evaluate the Orchestrator engine type in the filteringRouter. For example:
<ns0:header xmlns:ns0="http://www.tibco.com/aff/order"> <ns0:customerID>CUSTOMERID</ns0:customerID> <ord1:udf> <ord1:name>Orchestrator</ord1:name> <ord1:value>IPC</ord1:value> </ord1:udf> </ns0:header>
An optional validate on submit function is available. If this function is enabled, prior to handing the order to the Order Management component, this service performs a validation on the order to determine if it is valid. The results of this validation are returned. If the order fails validation, it is not submitted to Order Management. If the function is enabled by a flag, a copy of the order is saved in the offer cache to indicate it has been submitted. The request message format is:
82 |
Table 69: Submit Order Request Data Model Element Name orderRequest Element Type orderRequestType (Mandatory) Description Order data structure. Data model for Order is defined in XSD (refer section Common Data Format Specifications on page 91). Transaction ID sent by client.
ExternalBusinessTransactionID The reply message format is:
String
Table 70: Submit Order Response Data Model Element Name ExternalBusinessTransactionID BusinessTransactionID Element Type String String Description Transaction ID sent by client. Transaction ID generated by OMS, and used internally by OMS and Orchestrator. Order ID generated by the order manager (OMS). If the order fails validation, this is omitted. Client order reference.
orderID
String (Optional)
orderRef
String (Optional)
If submitOrder request does not contain either orderID or orderRef element, then OMS generates the orderRef and return the same in the submitOrder response.
Synchronous Submit Order This operation accepts an order for submission to the order management system and returns the order ID, order reference and the plan to the calling application after the order has been completed through the Orchestrator engine. If the order is being submitted for the first time, do not specify the Order ID in the input. A value is generated internally. If orderRef is not specified, a value is generated and returned to the calling application. This value is always generated whether the order passed validation or not. For SOAP over JMS Web services, the length of orderRef should be less than or equal to 100 characters.
| 83
If the Router Configuration is selected as filteringRouter, then submitOrder must have a UDF with UDF Name as "Orchestrator" in the order header. This information is required to evaluate the Orchestrator engine type in the filteringRouter. For example:
<ns0:header xmlns:ns0="http://www.tibco.com/aff/order"> <ns0:customerID>CUSTOMERID</ns0:customerID> <ord1:udf> <ord1:name>Orchestrator</ord1:name> <ord1:value>IPC</ord1:value> </ord1:udf> </ns0:header>
An optional validate on submit function is available. If this function is enabled, prior to handing the order to the Order Management component, this service performs a validation on the order to determine if it is valid. The results of this validation are returned. If the order fails validation, it is not submitted to Order Management. If the function is enabled by a flag, a copy of the order is saved in the offer cache to indicate it has been submitted. The request message format is:
Figure 9: Synchronous Submit Order Request Data Model Table 71: Synchronous Submit Order Request Data Model Element Name orderRequest Element Type orderRequestType (Mandatory) Description Order data structure. Data model for Order is defined in XSD (refer section Common Data Format Specifications on page 91). Transaction ID sent by client.
ExternalBusinessTransactionID The reply message format is:
String
84 |
Figure 10: Synchronous Submit Order Response Data Model Table 72: Synchronous Submit Order Response Data Model Table Element Name resultStatus OrderId OrderRef planID status Element Type Description ResultStatus String String String String The result status of the operation. OrderID generated by OMS. Client order reference. Plan Id of the plan generated for the order. Status of the order. E.g. Completed, failure etc. Transaction ID sent by client. Transaction ID generated by OMS, and used internally by OMS and Orchestrator.
ExternalBusinessTransactionID String BusinessTransactionID String
If Synchronous submitOrder request does not contain either orderID or orderRef element, then OMS generates the orderRef and return the same in the submitOrder response.
Amend Order Existing order can be modified using amend order web service. If order reference already exists in OMS, then it accepts amend order request. The request message format is:
| 85
The following table explains elements defined in request schema. Table 73: Amend Order Request Data Model Element Name orderRequest Element Type orderRequestType (Mandatory) Description Order data structure. Data model for Order is defined in XSD (refer section Common Data Format Specifications on page 91). Transaction ID sent by client.
ExternalBusinessTransactionID The response message format is:
String
The following table explains elements defined in response schema. Table 74: Amend Order Response Data Model Element Name ExternalBusinessTransactionID BusinessTransactionID Element Type String String Description Transaction ID sent by client. Transaction ID generated by OMS, and used internally by OMS and Orchestrator. Order ID generated by the order manager (OMS). If the order fails validation, this is omitted. Client order reference.
orderID
String (Optional)
orderRef
String (Optional)
Perform Bulk Order Action This service can be used to perform the following operations on multiple orders (Order IDs, orderRef): CANCEL SUSPEND RESUME WITHDRAW Only one type of bulk action can be performed on multiple orders in a single request.
86 |
The request message format is:
Table 75: Perform Bulk Order Action Request Data Model Element Name businessTransactionID action Element Type String String Description Transaction ID sent by client. Name of the bulk actions to perform: CANCEL SUSPEND RESUME WITHDRAW List of order IDs on which bulk operations are to be performed. List of order references on which bulk operations are to be performed.
orderID
String (Optional)
orderRef
String (Optional)
A response in the form of an acknowledgment is returned asynchronously indicating the successful submission of request. The status of the bulk process can be tracked through OMS UI, OMS server and Orchestrator logs. The response message format is:
Table 76: Perform Bulk Order Action Response Data Model Element Name businessTransactionID timestamp message Element Type String dateTime String (Optional) request Description Transaction ID sent by client. Date and time when OMS receives a bulk order request. Message indicating successful request submission.
| 87
Element Name noOfOrders
Element Type Integer (Optional)
Description Number of orders in the request.
Purge Order Service

This service contains operations regarding purging of orders and retrieving purge request status. Purge Order service can be invoked only through SOAP over HTTP protocol.
Purge Orders The purgeOrders operation accepts a criteria comprising start date, end date, and order status. The orders fulfilling the criteria qualify to be purged upon invocation of the web service. For each invocation, a unique ID is returned, which serves as an acknowledgment or a token of a successful submission of your request. For example, you can initiate a request to delete all the order data from the OMS database and Orchestrator between 01/10/2010 and 10/10/2011 and order status as COMPLETE. This ID is also termed as purge ID. In case of a malformed request or error in the processing, a fault message is sent back as a web service response. End-point URL: http://<HOST>:<PORT>/omsServer/api/purgeOrderService The request message format is:
Table 77: Purge Order Request Data Model Element Name dateRange orderType Element Type Date String (Mandatory, Choice) Description Comprises start date and end date. Order type. Valid values for order type are: COMPLETE CANCELLED The start date specified in the purge criterion. Eg '2012-03-08'. The end date specified in purge criterion. Eg '2012-03-08'.
startDate
TIMESTAMP (Mandatory, Choice)
endDate
TIMESTAMP
88 |
Table 78: Purge Order Response Data Model Element Name purgeId Element Type String (Mandatory) Description The unique id associated with purge. Eg 07e02e7e-29e1-4e08-bc4f-1c2e05025595.
Get Purge Order Status The getPurgeStatus operation allows you to track the status of an ongoing purge process by using the purge ID. End-point URL: http://<HOST>:<PORT>/omsServer/api/getPurgeStatus This method queries the purge status data store against the purge ID to return the purge status. The request message format is:
Table 79: Get Purge Order Request Data Model Element Name purgeId Element Type String (Mandatory) The reply message format is: Description The unique id associated with purge. Eg 07e02e7e-29e1-4e08-bc4f-1c2e05025595
| 89
Table 80: Get Purge Order Response Data Model Element Name purgeStatus Element Type String (Mandatory) ordersPurged ordersLinesPurged totalOrders totalOrderLines NUMBER NUMBER NUMBER NUMBER Description The unique id associated with purge. Eg 07e02e7e-29e1-4e08-bc4f-1c2e05025595. The number of orders purged at any given time. The number of order lines purged at any given time. Total orders to be purged. Total order lines to be purged.
Appendix
A
Common Data Format Specifications
This appendix describes generic object classes used as input and output objects in the operations and services.
Topics ResultStatus ResultFault Customer Notification Order Notification CustomerHierarchy Plan Notification Subscriber Segment Role Order OrderHeader OrderLine Product Characteristic Execution Plan PlanFragment InventoryItem InventoryItem Order
92 | Common Data Format Specifications
ResultStatus
This class is a result structure common for all operations. For any operation, the reply schema contains this mandatory object. It specifies if the service execution succeeded or failed. Any client of an operation must first check the value of the "severity" field to identify if the execution was successful or not. The XML schema structure is:
This class contains the following elements: Table 81: ResultStatus Element Details Element name Component Description Name of the component that detected the error. For the Fulfillment Order Management component implementation, this field is set to the Deployment variable of the TIBCO BusinessEvents in which the error occurred. Operation This text field identifies the operation in progress at the point of failure. This is helpful when a request consists of a number of operations and the same code may be returned in more than one operation. This field displays the name of the operation where the error occurred. Errors that occur within TIBCO BusinessEvents are identified by the same operation name with '-BE' appended to the name. Severity A single character {F E W I S}. F- Fatal, E - Error, W - Warning, I - Information, and S - Success. Code The error code, a string that identifies the error and the TIBCO FOM component that produced the error. This code is also visible inside component log and audit files. Refer to Error Codes and Messages on page 129 for details of this format. Message A descriptive text string associated with code.
Common Data Format Specifications | 93
ResultFault
The XML schema structure for the ResultFault is:
Table 82: ResultFault Element Details Element name code Description The error code, a string that identifies the error and the TIBCO FOM component that produced the error. This code is also visible inside component log and audit files. Refer to Error Codes and Messages on page 129 for details of this format. message A descriptive text string associated with code.
Customer
This class is the data model for the Customer object. It may be used across services and ID defined in XSD format.
This class contains the following elements: Table 83: Customer Element Details Element Name CustomerID Element Type String (Mandatory) ParentCustomerID String (Optional) Description Customer identifier. The value must be unique. Customer identifier for the parent customer. If this customer is a top-level customer then this is omitted. Customer reference identifier for external systems.
CustomerRef
String (Optional)
Element Name CustomerType
Description Customer type classification as configured for the Party in the Product Catalogue. Customer first name for individual customer. Customer last name for individual customer. Customer company name for corporate customer as configured for the Party in the Product Catalogue. Customer address information.
FirstName
String (Choice, Mandatory)
LastName
CompanyName
Address
Type (Optional)
Address/AddressLine1
String (Mandatory)
Customer address line 1.
String (Optional)
Customer address line 2.
Address/Locality
String (Mandatory)
Customer address locality.
Address/Region
String (Optional)
Customer address region.
Address/PostCode
String (Mandatory)
Customer address post code.
Address/Country
String (Mandatory)
Customer address country.
Segments
Type (Optional)
Customer segments.
Segments/Channel
String (*)
Customer channels as configured on the Party in the Product Catalogue. Customer market as configured on the Party in the Product Catalogue. Customer value rating as configured on the Party in the Product Catalogue.
Segments/Market
String (Optional)
Segments/Rating
String (Optional)
Element Name Segments/Risk
Description Customer risk rating as configured on the Party in the Product Catalogue. Customer override flag as configured on the Party in the Product Catalogue. Customer configuration type as configured on the Party in the Product Catalogue. Customer status.
Override
Boolean (Optional)
Type
String (Optional)
Status
String (Optional)
Notes
String (Optional)
Customer notes.
Roles
Type (Optional)
List of roles associated with this customer as configured on the Party in the Product Catalogue. Role data structure. Data model for Role is defined in XSD (refer to the section Common Data Format Specifications on page 91). List of UDFs as configured on the Party Extension in the Product Catalogue. UDF type. Name of the attribute.
Roles/Role
Type (*)
UDFs
Type (Optional)
UDFs/UDF/Value
String (Mandatory)
Value of the attribute.
Notification
This class is the data model for the Notification object.
Order Notification
This class is the data model for the Order Notification object.
CustomerHierarchy
This class is the data model for the CustomerHierarchy object. It may be used across services and ID defined in XSD format.
This class contains the following elements: Table 84: CustomerInstallbase Element Details Element Name Customers Element Type Type (Optional) Customers/Customer Customers/Customer/CustomerID Type (*) String (Mandatory) Customers/Customer/CustomerRef String (Optional) Customers/Customer/CustomerType String (Optional) Customers/Customer/FirstName String (Choice, Mandatory) Customers/Customer/LastName String (Choice, Mandatory) Customers/Customer/CompanyName String (Choice, Mandatory) Description List of customers. If there are no customers, this element is omitted. Customer type Customer identifier. This value must be unique. Customer reference identifier for external systems. Customer type classification as configured for the Party in the Product Catalogue. Customer first name for individual customer. Customer last name for individual customer. Customer company name for corporate customer.
Element Name Customers/Customer/Status
Description Customer status
Customers/Customer/Subscribers
Type (Optional)
List of subscribers for this customer. If there are no subscribers, this element is omitted. Subscriber type Subscriber identifier. This value must be unique. Subscriber reference identifier for external systems. Subscriber first name.
Customers/Customer/Subscribers/Subscriber Type (*) Customers/Customer/Subscribers/Subscriber/ String SubscriberID (Mandatory) Customers/Customer/Subscribers/Subscriber/ String SubscriberRef (Optional) Customers/Customer/Subscribers/Subscriber/ Type FirstName (Mandatory) Customers/Customer/Subscribers/Subscriber/ Type LastName (Mandatory) Customers/Customer/Subscribers/Subscriber/ Type Status (Optional) Customers/Customer/Subscribers/Subscriber/ Type SubscribedProducts (Optional) Customers/Customer/Subscribers/Subscriber/ Product (*) SubscribedProducts/Product
Subscriber last name.
Subscriber status
List of products. If the subscriber has no products, this element is omitted. Product data structure. Data model for Product is defined in XSD (refer section Common Data Format Specifications on page 91). List of subsidiary customers. If there are no subsidiary customers, this element is omitted. Customer type as defined in this XSD. This is a recursive structure. List of subscribers not associated with a customer. If there are no subscribers, this element is omitted. Subscriber type. This element has the same structure as Customers/Customer/Subscribers/ Subscriber.
Customers/Customer/SubsidiaryCustomers Type (Optional) Customers/Customer/SubsidiaryCustomers/ Type (*) Customer Subscribers Type (Optional) Subscribers/Subscriber Type (*)
Plan Notification
This class is the data model for the Plan Notification object.
Subscriber
This class is the data model for the Subscriber object. It may be used across services and ID defined in XSD format.
This class contains the following elements: Table 85: Subscriber Element Details Element Name SubscriberID Element Type String (Optional) CustomerID String (Optional) Description Subscriber identifier. This value must be unique. Customer unique identifier that this subscriber is associated with. This is blank for non-corporate customers.
Element Name SubscriberRef
Description Subscriber reference identifier for external systems. Subscriber first name.
FirstName
String (Mandatory)
LastName
String (Mandatory)
Subscriber last name.
Address
Type (Optional)
Subscriber address information.
String (Mandatory)
Subscriber address line 1.
String (Optional)
Subscriber address line 2.
Address/Locality
String (Mandatory)
Subscriber address locality.
Address/Region
String (Optional)
Subscriber address region.
Address/PostCode
String (Mandatory)
Subscriber address post code.
Address/Country
String (Mandatory)
Subscriber address country.
Segments
Type (Optional)
Subscriber segments.
Segments/Channel Segments/Market
String (*) String (Optional)
Subscriber channels. Subscriber market.
Segments/Rating
String (Optional)
Subscriber value rating.
Segments/Risk
String (Optional)
Subscriber risk rating.
Status
String (Optional)
Subscriber status.
Element Name Notes
Description Subscriber notes.
Roles
Type (Optional)
List of roles associated with this subscriber. Role data structure. Data model for Role is defined in XSD (refer section Common Data Format Specifications on page 91). List of UDFs.
Roles/Role
Type (*)
UDFs
Type (Optional)
UDF type. Name of the attribute.
UDFs/UDF/Value
String (Mandatory)
Segment
This class is the data model for the Segment object. It may be used across services and ID defined in XSD format.
Table 86: Segment Details Element Name Name Element Type String (Mandatory) Type String (Mandatory) Segment type. Valid values are: Channel Market Rating Risk Description Segment name.
Role
This class is the data model for the Role object. It may be used across services and ID defined in XSD format.
Table 87: Role Details Element Name RoleID Element Type String (Mandatory) RoleName String (Mandatory) Role name Description Role identifier
Order
This class is the data model for the Order object. It may be used across services and ID defined in XSD format.
Table 88: Order Element Details Element Name orderID Element Type String (Optional) orderRef String Description Order ID. Not required during Submit Order but is returned by Get Order Details and Get Orders. Order reference ID. If the orderRef element is sent as an empty element in the SubmitOrder request, then OMS generates the orderRef element. If the orderRef element is not sent, then schema validation fails.
Element Name header
Element Type headerType (Mandatory)
Description Order Header data structure.
line
lineType
Order Line data structure.
OrderHeader
This class is the data model for the header object. It may be used across services and ID defined in XSD format.
Table 89: OrderHeader Element Details Element Name OrderDescription Element Type String (Optional) OrderStatus String (Optional) CustomerID String (Optional) Customer unique identifier. Omit for non-corporate orders. Either CustomerID or SubscriberID is necessary. Subscriber unique identifier. Omit for corporate orders. Either CustomerID or SubscriberID is necessary. Date order was submitted. Current order status. Description Order description.
SubscriberID
String (Optional)
SubmittedDate
Date (Optional)
SubmittedTime
Time (Optional)
Time order was submitted.
RequiredByDate
DateTime (Optional)
Date and time that a particular order is required to start on. The priority value assigned to order. The value ranges from 0-9. To use orderPriority, schemas under
$AF_HOME/schemas\schema\oms
orderPriority
Integer(Optional)
should only be used. ExpirationDate Date (Optional) ExpectedCompletionDate DateTime (Optional) InvoiceAddress Type (Optional) InvoiceAddress/AddressLine1 String (Mandatory) InvoiceAddress/AddressLine2 String (Optional) Invoice address line 2. Invoice address line 1. Expiration date for the offer. Not relevant for orders. Date order is expected to be completed. Invoice address.
Element Name InvoiceAddress/Locality
Description Invoice address locality.
InvoiceAddress/Region
String (Optional)
Invoice address region.
InvoiceAddress/PostCode
String (Mandatory)
Invoice address post code.
InvoiceAddress/Country
String (Mandatory)
Invoice address country.
DeliveryAddress
Type (Optional)
Delivery address.
DeliveryAddress/AddressLine1
String (Mandatory)
Delivery address line 1.
DeliveryAddress/AddressLine2
String (Optional)
Delivery address line 2.
DeliveryAddress/Locality
String (Mandatory)
Delivery address locality.
DeliveryAddress/Region
String (Optional)
Delivery address region.
DeliveryAddress/PostCode
String (Mandatory)
Delivery address post code.
DeliveryAddress/Country
String (Mandatory)
Delivery address country.
Notes
String (Optional)
Order notes.
SLAs
Type (Optional)
List of SLAs passed through to back-end systems. These SLAs do not apply within the order management. SLA type. SLA ID.
SLAs/SLA SLAs/SLA/SLAID
UDF
Type (*)
UDF type
Element Name UDF/Name
Description Name of the attribute.
UDF/Value
String (Mandatory)
OrderLine
This class is the data model for the OrderLine object. It may be used across services and ID defined in XSD format.
The following order line actions are supported: Provide Update Cease Cancel Install a new product or service. Update an existing product or service. Terminate an existing product or service. Cancel an outstanding order currently in-flight.
Table 90: Line Element Details Element Name lineNumber Element Type String (Mandatory) subscriberID String (Optional) productID String (Mandatory) productVersion quantity String String (Mandatory) uom String (Mandatory) deliveryAddress action addressType (Mandatory) String (Mandatory) Delivery address. Action required. Valid values are: PROVIDE UPDATE CEASE CANCEL Version ID of the product being ordered. Number of items required for each product in this line. Unit of measure. Subscriber ID for this order line. Omit for orders for corporate customers not linked to an individual subscriber. ID of the product being ordered. Description Order line number.
actionMode
String (Optional)
Action mode. This is optional supplemental information to go with OrderLineAction. Valid value is: MOVE
requiredByDate
Date and time that a particular order is required to start on. Correlation ID used by order management to group order lines together for provisioning. Inventory ID for this product.
linkID
String (Optional)
inventoryID
String (Optional)
notes
String (Optional)
Order line notes.
slaID
String (Mandatory)
SLA ID. (SLAs passed through to back-end systems. These SLAs do not apply within order management itself.)
Element Name udf
Description Value of the attribute. This must be minimum of one character in length. List of characteristics.
characteristic
Type (Optional)
customerItemID
String (Optional)
Customer item ID.
status statusChanged extension
String (Optional)
Current order status.
Product
This class is the data model for the Product object. It may be used across services and ID defined in XSD format.
Table 91: Product Element Details Element Name ProductID Element Type String (Mandatory) ProductName String (Mandatory) ProductType String (Mandatory) ProductSubType String (Optional) Description String (Mandatory) Description Product identifier. This value must be unique. Product name as configured in the Product Catalogue. Product type as configured in the Product Catalogue. Product sub-type as configured in the Product Catalogue. Product description as configured in the Product Catalogue.
Characteristic
This class is the data model for the Characteristic object. It may be used across services and is defined in XSD format.
Table 92: Characteristic Element Details Element Name name Element Type String (Mandatory) description String (Mandatory) Values Type (Mandatory) Values/value Values/value/name Type (*) String (Mandatory) Values/value/type String (Mandatory) Characteristic value data type. Description Characteristic name as configured in the Product Catalogue. Characteristic description as configured in the Product Catalogue. List of characteristic values as configured in the Product Catalogue. Characteristic value. Characteristic value name.
Element Name Values/value/value
Description Characteristic value.
Values/value/valueFrom
String (Optional)
Characteristic value range from.
Values/value/valueTo
String (Optional)
Characteristic value range to.
Execution Plan
This class is the data model for the plan object. It may be used across services and ID defined in XSD format.
Here is the data model for the planItem object.
Table 93: Plan and PlanItem Element Details Element Name planID Element Type String (Mandatory) orderID String (Mandatory) orderRef Originator String String Order ID for the order this plan is related. Order reference ID. Originator of the AOPD request that created this plan. Description Unique identifier for the plan.
Element Name planCreationDate
Element Type DateTime (Mandatory)
Description Date and time the plan was created.
status
String (Mandatory)
Status of the overall plan.
statusChanged
dateTime (Mandatory)
Date Time when the last status was changed. Description of the plan.
description
String (Mandatory)
planStartDate
dateTime (Mandatory)
Start date and time for the plan.
planStartMillis isAmendment planItem udf
long boolean planItemType udfSetType
Timestamp when the plan started executing. Flag identifying if the plan is an amendment plan. Composite object with information on plan. Composite object with information related to UDF which is user-defined data. Unique Id identifying the plan Item. Name of the plan item. The id of the process component to invoke when executing the plan item.
planItemID planItemName planFragmentUniqueID
String String String
planFragment orderLine action startMilestone milestone parentID childID siblingID String String Plan Item Ids on which this plan item depends. Plan Item Ids which are dependent on this plan item Plan Item Ids of sibling products for this plan item. List String List of order lines for the corresponding plan item. Action for the plan Item.
Element Name dependentID startTimeStamp endTimeStamp cancelled isNonExecuting
Element Type String long long boolean boolean
Description Plan Item Ids of dependent products for this plan item. Timestamp that indicates when the plan item started execution. Timestamp that indicates when the plan item completed execution. Flag indicating if the plan was cancelled. Flag indicating if the plan is non-executing i.e no plan item will be generated for this plan.
isNoResiprocalAction
boolean
PlanFragment
This class is the data model for the planFragment object. It may be used across services and ID defined in XSD format.
InventoryItem
This class is the data model for the InventoryItem object. It may be used across services and ID defined in XSD format.
This class contains the following elements: Table 94: Inventory Item Element Details Element Name InventoryID Element Type String (Mandatory) CustomerID String (Mandatory, Choice) Customer ID with which this inventory item is associated. Description Inventory identifier.
Element Name SubscriberID
Element Type String (Mandatory, Choice)
Description Subscriber ID with which this inventory item is associated. Parent Customer ID to which this inventory is indirectly linked. Current user status in the inventory for the SubscriberID or CustomerID. The valid values are: LOCKED UNLOCKED
ParentCustomerID
UserStatus
String (Optional)
ProductID
String (Mandatory)
Product identifier.
ProductName
String (Mandatory)
Product name.
ProductType
String (Mandatory)
Product type.
ProductSubType
String (Optional)
Product sub type.
ProductDescription
String (Mandatory)
Product description.
Status
String (Mandatory)
Inventory item status The valid statuses are: DRAFT ACTIVE WITHDRAWN UPDATEPENDING CEASEPENDING The date that the product went to ACTIVE status. The date that the product went to WITHDRAWN status. Order history for this inventory item.
StartDate
EndDate
DateTime (Optional)
OrderHistory
Type (Optional)
OrderHistory/Order
Type (*)
Order type. Refer to the InventoryItemOrder type for details.
Element Name UDFs
Element Type Type (Optional)
Description UDF type.
UDFs/UDF UDFs/UDF/Name UDFs/UDF/Value
Type (*) String (Mandatory) String (Mandatory)
User defined fields associated with the product. User defined field name. User defined field value.
InventoryItem Order
This class is the data model for the InventoryItem Order object. It may be used across services and ID defined in XSD format.
This class contains the following elements: Table 95: InventoryItem Order Element Details Element Name OrderID Element Type String (Mandatory) OrderLineNumber String (Mandatory) OrderLineAction String (Mandatory) OrderDate DateTime (Mandatory) Comments String (Optional) CurrentOwnerCustomerID String (Optional) CurrentOwnerSubscriberID String (Optional) Current owner Subscriber ID. Current owner Customer ID. Description Order identifier the product is ordered on. Order line number the product is ordered on. Order line action the product is ordered with. Order date and time the product is ordered. Comments for this order.
Appendix
B
Error Codes and Messages
This appendix lists the error codes and message details.
Topics Error Code Format Error Codes Customers Inventory Offers OfferValidation Products Subscribers
130 | Error Codes and Messages
Error Code Format

Error codes are formatted as follows: Table 96: AFF-<component>-<subcomponent>-<code> Element
<component>
Description TIBCO Fulfillment Order Management component that contains the error.
Valid Values OCV - Offer Configuration and Validation OMS - Order Management PC - Product Catalogue
<subcomponent>
TIBCO Fulfillment Order OCV: Management sub-component that contains the error. CUST - Customer Model IM - Inventory Management OFF - Offering Management PROD - Product Model SUB - Subscriber Model VAL - Validation OMS : OPD - Order Plan Development ORD - Order Management PROD: CUST - Customer Model PROD - Product Model
<code>
Unique 4 digit numeric code to identify the error.
Error Codes and Messages | 131
Error Codes
The following error codes are currently implemented. Code Message
TIBCO-AFF-OMS-100001 The input is invalid. TIBCO-AFF-OMS-100003 Order reference already used. Order reference can not be reused. TIBCO-AFF-OMS-100004 Order reference not found. Invalid amendment request. TIBCO-AFF-OMS-100005 No record exists. TIBCO-AFF-OMS-100006 Order not found. Invalid cancellation request. TIBCO-AFF-OMS-100007 Invalid request. Provide either Order Reference or Order ID. TIBCO-AFF-OMS-100008 NO_EXECUTION_PLAN . TIBCO-AFF-OMS-100009 OCV check failed. Order cannot be processed. TIBCO-AFF-OMS-100010 OCV timed out. Order cannot be processed. TIBCO-AFF-OMS-100011 No plan with Plan ID {0} found for updating status. TIBCO-AFF-OMS-100012 Search criteria is invalid. TIBCO-AFF-OMS-100013 No amended plan for order {0} was received TIBCO-AFF-OMS-100014 Plan Item {0} not found. TIBCO-AFF-OMS-100015 Invalid token. TIBCO-AFF-OMS-100016 The order cannot be amended. Amendment already in progress. TIBCO-AFF-OMS-100017 The token expired. TIBCO-AFF-OMS-100018 The lock on specified order could not be obtained. TIBCO-AFF-OMS-100019 The lock on specified order could not be released. TIBCO-AFF-OMS-100020 Order not found. TIBCO-AFF-USER-100022 User [{0}] already exists. TIBCO-AFF-USER-100025 Invalid role {1} for user {0}. Valid roles are {2}. TIBCO-AFF-USER-100026 Mandatory attributes for user creation not specified. {0}, {1}, {2}. TIBCO-AFF-USER-100027 User name not specified. TIBCO-AFF-USER-100028 User {0} not found. TIBCO-AFF-USER-100029 Password for user {0} not specified. TIBCO-AFF-USER-100030 New password for user {0} not specified. TIBCO-AFF-USER-100031 User object cannot be null. TIBCO-AFF-USER-100032 User {0} not authenticated. TIBCO-AFF-USER-100034 OrderLine {0} not found.
Customers
Name Value Description Error result status for customer not found AFF-OCV-CUST-0100 CustomerID <customerID> was not found
AFF-OCV-CUST-0101 CustomerID <customerID> already exists so Error result status for customer already cannot be created exists so cannot be created AFF-OCV-CUST-0102 CustomerID <customerID> was not found so Error result status for customer not found cannot be updated so cannot be updated AFF-OCV-CUST-0104 SubscriberID <subscriberID> was not found Error result status for subscriber not found
Inventory
Name Value Description Error result status for assign inventory item failures during multiple assign call Error result status for reassign inventory item failures during multiple reassign call Error result status for remove inventory item failures during multiple remove call Error result status for update inventory item failures during multiple update call AFF-OCV-IM-0100 One or more inventory item assignments failed AFF-OCV-IM-0110 One or more inventory item reassignments failed AFF-OCV-IM-0120 One or more inventory item removes failed AFF-OCV-IM-0130 One or more inventory item updates failed
AFF-OCV-IM-0135 One or more inventory item rollbacks Error result status for assign inventory item failed failures during multiple rollback call AFF-OCV-IM-0140 InventoryID <inventoryID> was not found Error result status for inventory item was not found
AFF-OCV-IM-0150 Inventory for <inventoryID> does not Error result status for Inventory for customer or exist subscriber does not exist AFF-OCV-IM-0160 Attempt to reassign item to the same inventory AFF-OCV-IM-0170 Input data missing AFF-OCV-IM-0180 CustomerID <customerID> was not found in the inventory Error when source and target inventories are the same Error when both customerID and sunscriberID are null Error result status for retrieving user status for a customer that doesn't exist
AFF-OCV-IM-0190 SubscriberID <subscriberID> was not Error result status for retrieving user status for found in the inventory a subscriber that doesn't exist AFF-OCV-IM-0200 Duplicate InventoryID <inventoryID> Error result status for submitting duplicate submitted to bulk interface inventory ID to a bulk interface operation AFF-OCV-IM-0210 Cannot reassign subscriber from one customer to another AFF-OCV-IM-0220 ProductID <productID> was not found Error result status for reassigning a subscriber from one customer to another
Offers
Name Value Description AFF-OCV-OFF-0100 OrderRef <orderRef> and Version <version> was Error result status for retrieve offer not found where the specified offer and version was not found AFF-OCV-OFF-0101 OrderRef <orderRef> was not found Error result status for returning multiple offer records for an OrderRef and maximum Version
AFF-OCV-OFF-0102 Found <numberOfRecords> matching records for Error result status for returning OrderRef <orderRef> and Version <version> but multiple offer records for an expected 1 OrderRef and Version AFF-OCV-OFF-0103 Found <numberOfRecords> matching records for Error result status for returning OrderRef <orderRef> and maximum Version but multiple offer records for an expected 1 OrderRef and maximum Version AFF-OCV-OFF-0110 Offer has override price for product <productID> on order line <orderLineNumber> that does not permit overrides
OfferValidation
Name AFF-OCV-VAL-0100 AFF-OCV-VAL-0101 AFF-OCV-VAL-0102 AFF-OCV-VAL-0103 AFF-OCV-VAL-0104 Value Product exists in install base Product does not exist in install base Compatible products were not found Incompatible product was found Record type in order does not match catalogue value Concurrent order not allowed for locked user Incompatible UDF was found Mandatory UDF is missing UDF length exceeded UDF value does not conform to datatype Description Code for warning when product exists in current install base Error code when Product does not exist in the current install base Error code when Compatible products were not found Error code when Incompatible product was found Error code when Record type in order does not match catalogue value Error code when user is locked and concurrent order not allowed Error code when Incompatible UDF was found Error code when Mandatory UDF is missing Error code when UDF length exceeded Error code when UDF value does not conform to datatype
AFF-OCV-VAL-0105 AFF-OCV-VAL-0200 AFF-OCV-VAL-0201 AFF-OCV-VAL-0202 AFF-OCV-VAL-0203 AFF-OCV-VAL-0204 AFF-OCV-VAL-0205 AFF-OCV-VAL-0206 AFF-OCV-VAL-0300 AFF-OCV-VAL-0301 AFF-OCV-VAL-0400 AFF-OCV-VAL-0401
UDF value not from the choicelist Error code when UDF value not from the choicelist InventoryID missing in the order line Error code when order line does not contain InventoryID
Update mode missing in the order Error code when order line does line not contain Update mode Product is not eligible Internal Validation error Required product not found Error code when Product is not eligible Error code when an error message is returned by validation code Error code when Required product not found
Count of products from the group Error code when Count of products is less than minimum from the group is less than minimum Count of products from the group Error code when Count of products is greater than maximum from the group is greater than maximum
AFF-OCV-VAL-0402
Name AFF-OCV-VAL-0403 AFF-OCV-VAL-0404 AFF-OCV-VAL-0405 AFF-OCV-VAL-0500 AFF-OCV-VAL-0501 AFF-OCV-VAL-0502
Value Mandatory product not found
Description Error code when Mandatory product not found
Product count less than minimum Error code when product count is less than Rec Min Product count greater than maximum Product is not defined in the product catalogue InventoryID not supplied for UPDATE OrderLIneActionMode not supplied for UPDATE InventoryID not supplied for CEASE InventoryID not supplied for MOVE action mode No order line present in ValidateOfferRequest Error code when product count is greater than Rec Max Error code when product is not defined Order line action is UPDATE, but no InventoryID is provided Order line action is UPDATE, but no OrderLineActionMode is provided Order line action is CEASE, but no InventoryID is provided Order line action mode is MOVE, but no inventoryID is supplied Order line is not present in ValidateOfferRequest
AFF-OCV-VAL-0503 AFF-OCV-VAL-0504 AFF-OCV-VAL-0505
Products
Name AFF-OCV-PROD-0100 AFF-OCV-PROD-0101 AFF-OCV-PROD-0102 AFF-OCV-PROD-0103 Value There are no products ProductID <productID> was not found Multiple products for ProductID <productID> were found No compatible products found Description Error result status for no products stored in the cache Error result status for product not found Error result status for multiple products found No compatible products found
Subscribers
Name Value Description Error result status for subscriber not found Error result status for parent customer not found Error result status for subscriber already exists so cannot be created Error result status for subscriber not found so cannot be updated AFF-OCV-SUB-0100 SubscriberID <subscriberID> was not found AFF-OCV-SUB-0101 CustomerID <customerID> for SubscriberID <subscriberID> was not found AFF-OCV-SUB-0102 SubscriberID <subscriberID> was not found so cannot be updated AFF-OCV-SUB-0103 SubscriberID <subscriberID> already exists so cannot be created
Appendix
C
Component Classes and Methods
Topics OMS Classes and Methods Orchestrator Pre-processors and Rules
140 | Component Classes and Methods
OMS Classes and Methods

Class PurgeOrderService.java Description This interface is the SEI of the purge web service. This class implements the interface PurgeOrderService. A runnable which initiates the purge processrun This interface is modified to include a new method purgeOrders to start the purge process. This class implements the interface OrderService. A runnable which invokes the actual purge run operation in OrdersDAO. This class acts as DAO layer for reading data savePurgeRequest to and from the purge data store. updatePurgeRequest run purgeOrders Method/Interface purgeOrders getPurgeStatus
PurgeOrderServiceEndPoint.java ProcessPurgeTask.java OrderService.java
OrderServiceImpl.java DeleteOrderTask.java PurgeStatusDAO.java
OrderPurgeNotificationListener.java This class is used to update the delete request status sent to Orchestrator in purge data store. ModelPurgeStatus.java This is a domain class to represent the Purge Status.
Component Classes and Methods | 141
Orchestrator Pre-processors and Rules

Pre-processors Pre-processors deleteOrderRequestPreProcessor Description This pre-processor is modified to instantiate a deleteplantrigger alongwith deleteordertrigger, which contains order and plan concepts respectively to be deleted.
Rules deleteOrder (DeleteRuleSet) The rule condition is changed to instantiate deleteplantrigger also. The rule is modified to delete plans along with the orders.

Tib Af Webservices

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Tib Af Webservices

Uploaded by

Copyright:

Available Formats

TIBCO Fulfillment Order Management Web Services

Software Release 2.0 November 2012

TIBCO Fulfillment Order Management Web Services

Part I: Architecture.............................................................................13 Chapter 1 Fulfillment Orchestration Overview......................19

Part II: Fulfillment Order Management Services.............................21

Chapter 2 Fulfillment Management Services.........................23

Chapter 3 Order Management Services.................................75

Appendix A Common Data Format Specifications.......................91

TIBCO Fulfillment Order Management Web Services

Appendix B Error Codes and Messages......................................129

Appendix C Component Classes and Methods..........................139

TIBCO Fulfillment Order Management Web Services

TIBCO Fulfillment Order Management Web Services

Changes from the Previous Release of this Guide

TIBCO Fulfillment Order Management Web Services

TIBCO Fulfillment Order Management Web Services

bold code font

TIBCO Fulfillment Order Management Web Services

Connecting with TIBCO Resources

TIBCO Fulfillment Order Management Web Services

Topics Fulfillment Orchestration Overview Services and Operations Integration Channels

Services and Operations

Offer Configuration and Customer Validation (OCV)

TIBCO Fulfillment Order Management Web Services

Operation GetOffers RemoveOffer SaveOffer ValidateOffer

GetEligibleProducts GetIneligibleSubscribers GetProductInformation GetSegments

tibco.aff.ocv.services.subscriber CreateSubscriber GetCustomerImage ForSubscriber RemoveSubscriber UpdateSubscriber

Order Management (OM)

CancelOrder GetOrderDetails GetOrders GetOrderExecutionPlan SubmitOrder AmendOrder SyncSubmitOrder WithdrawOrder PerformBulkOrderAction

TIBCO Fulfillment Order Management Web Services

SOAP Over HTTP

SOAP Over JMS

TIBCO Fulfillment Order Management Web Services

Figure 1: Fulfillment Orchestration Architecture

TIBCO Fulfillment Order Management Web Services

Fulfillment Orchestration Components

Fulfillment Orchestration Components

TIBCO Fulfillment Order Management Web Services

Topics Security Header Fulfillment Management Services Order Management Services

TIBCO Fulfillment Order Management Web Services

22 | Fulfillment Order Management Services

TIBCO Fulfillment Order Management Web Services

The reply message format is:

TIBCO Fulfillment Order Management Web Services

TIBCO Fulfillment Order Management Web Services

TIBCO Fulfillment Order Management Web Services

CustomerID/SubscriberID String (either one of them is provided)

TIBCO Fulfillment Order Management Web Services

Element Name StartDate

Element Type DateTime (Mandatory)

Order identifier the product is ordered on.

Order line number the product is ordered on.

Order line action the product is ordered with.

Order date and time the product is ordered.

Comments for this order.

User defined field value.

TIBCO Fulfillment Order Management Web Services

Element Name CustomerID/SubscriberID

Element Type String (Choice)

String (Optional, Choice)

Item/Order/CurrentOwnerCustomerID String (Optional, Choice) Item/Order/CurrentOwnerSubscriberID String (Optional, Choice)

TIBCO Fulfillment Order Management Web Services

Element Name Item/UDFs