Tib Af Webservices

TIBCO ActiveFulfillment Web Services
Software Release 1.2.0 September 2011
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 PERIODICALLY ADDED 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 TIBCO Software Inc. ALL RIGHTS RESERVED. TIBCO Software Inc. Confidential Information
TOC | 5
Contents
Preface.....................................................................................................................7
Related Documentation............................................................................................................8 Typographical Conventions......................................................................................................9 Connecting with TIBCO Resources........................................................................................10
Part I: Architecture.............................................................................11
Architecture Overview............................................................................................................12 Order Manager GUI.....................................................................................................13 Order Manager Server.................................................................................................14 Orchestrator.................................................................................................................14 Router..........................................................................................................................15 Transient Data Store....................................................................................................15 Services and Operations........................................................................................................16 Integration Channels..............................................................................................................18 SOAP Over HTTP........................................................................................................18 SOAP Over JMS..........................................................................................................18
Part II: ActiveFulfillment Services....................................................21

Security Header......................................................................................................................22
Chapter 1 ActiveFulfillment Services.....................................23

Customer Service........................................................................................................23 Inventory Service.........................................................................................................26 Offer Service................................................................................................................49 Product Service...........................................................................................................60 Subscriber Service......................................................................................................67
Chapter 2 Order Management Services.................................71

Order Service..............................................................................................................71
Appendix A Common Data Format Specifications.......................83

ResultStatus...........................................................................................................................84 ResultFault.............................................................................................................................85 Components...........................................................................................................................86 Operations..............................................................................................................................87 Customer................................................................................................................................90 Notification..............................................................................................................................93
6 | TOC Order Notification...................................................................................................................94 CustomerHierarchy.................................................................................................................95 Plan Notification.....................................................................................................................97 Subscriber..............................................................................................................................98 Segment...............................................................................................................................101 Role......................................................................................................................................102 Order....................................................................................................................................103 OrderHeader........................................................................................................................105 OrderLine.............................................................................................................................108 Product.................................................................................................................................111 Characteristic.......................................................................................................................112 Execution Plan.....................................................................................................................114 PlanFragment.......................................................................................................................118 InventoryItem........................................................................................................................119 InventoryItem Order.............................................................................................................122
Appendix B Error Codes and Messages......................................123

Error Code Format...............................................................................................................124 Error Codes..........................................................................................................................125
Preface
The preface contains information about documentation related to the current document, typographical conventions, and information on how to contact TIBCO support.
8 | Preface
Related Documentation

TIBCO ActiveFulfillment Installation and Configuration Read this manual for instructions on site
preparation, installation, and configuration.

TIBCO ActiveFulfillment Administration Read this manual for instructions on administration tasks. TIBCO ActiveFulfillment Web Services Read this manual for information about the web services. TIBCO ActiveFulfillment Release Notes Read the release notes for a list of features. This document also
contains the list of known issues for this release.

TIBCO ActiveFulfillment User's Guide Read this manual for ActiveFulfillment features and functionality
as well as all the screens.

TIBCO ActiveFulfillment Concepts and Architecture Read this manual for terminology and concepts
of TIBCO ActiveFulfillment.
Preface | 9
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 ActiveFulfillment 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/1.2.
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 ActiveMatrix BusinessWorks Concepts. 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.
10 | Preface
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/TibcoDoc. 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 ActiveFulfillment 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 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 ActiveFulfillment. TIBCO ActiveFulfillment is a comprehensive software solution to design, deploy and maintain high-performance scalable enterprise level business processes for advanced and dynamic order fulfillment. TIBCO ActiveFulfillment 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 ActiveFulfillment also enables companies to efficiently manage changes to the existing business process to meet rapidly changing business environment. Product model can be defined following SID 9 guidelines using TIBCO ActiveCatalog or any other catalog management system and imported into ActiveFulfillment.
Topics Architecture Overview Services and Operations Integration Channels
12 | Architecture
Architecture Overview
The major components of the TIBCO ActiveFulfillment include: Order Manager GUI - Provides operators a GUI to manage and track orders. Order Management System (OMS) persists order data and allows operators to search, view, track and trace orders, as well as allows users to take actions on order/order lines. Offer Configuration and Validation Engine (OCV) - receives the order and validates it. Validated order is submitted for processing. Provides front end systems with an API to query ActiveFulfillment to determine the validity of a customer's "shopping cart". OCV provides both validation and configuration options that the customer may take for the products in their shopping cart. Automatic Order Plan Development (AOPD) - Valid orders accepted by the OMS system are decomposed into their individual products, services and resources. An optimized order plan workflow process is then generated based on those basic building blocks to ensure that the order is fulfilled accurately and as efficiently as possible. Optimization can take into account both product rules, as well as customer inventory and other data to arrive at the final order plan. Order Manager Server - exposes SOAP Web services to ActiveFulfillment. Orchestrator - Takes the order plan from AOPD and executes those tasks till completion. It invokes micro-level process plan fragments to initiate tasks within the operator's operations ecosystem, enabling appropriate actions to take place in a variety of back-end systems (for instance, billing system(s), network systems, scheduling systems). ActiveFulfillment Orchestrators keeps track of status and manages exceptions. Router - Orders from OMS may optionally be routed to an alternate Orchestration engine. In this case, ActiveFulfillment's Router can read inbound orders and, based on rules, may route to an external orchestration engine. Common Logging - All ActiveFulfillment's components report to a common logging component to allow for ease of maintenance and operations management of the system. The diagrammatic representation of the TIBCO ActiveFulfillment is shown below.
Architecture | 13
Figure 1: Architecture
Order Manager GUI

Order Manager GUI or is an application that provides you visual interface to view order details and order execution plans, search orders, orders that were fulfilled or failed during the fulfilment process, and facilitates end-to-end tracking, storing and monitoring capability for orders that are part of the order fulfilment system. OMS also equips you with the capability to perform actions on the orders being executed in the system. For details, see TIBCO ActiveFulfillment User's Guide. The following actions can be performed using OMS: OMS Actions Dashboard-specific actions Description Viewing Dashboard: You can view the OMS Dashboard for summarized information under the following sections: Order Summary Orders in Execution Backlog Orders Amended Orders OMS allows you to do the following order-specific actions: View orders Search orders Edit orders Save orders View order execution plan View plan progress
Order-specific actions
14 | Architecture OMS Actions Plan-specific actions Description You can perform the following plan-specific actions in the OMS. Search plan OMS provides you with the facility of the Activity Log to view the status and revision history of an object (order or a plan).
Activity Log
Order Manager Server

Order manager server (OMS) exposes Web service to ActiveFulfillment to accept predefined request. OMS hosts the following Web services: Submit Order Amend Order Cancel Order Get Order Details Get Orders Get Order Execution Plan
Orchestrator
Orchestrator executes a series of tasks in a defined order. For each ordered product, a series of plan items must be completed sequentially for that product to be provided. The Product Catalog maintains the link between product and plan item. Orchestrator receives the requests for order fulfillment. Orchestrator component in turn sends the order to BE AOPD to analyze the order and the Product Catalogue, and determines the plan of action to fulfill the order. Orchestrator then uses this plan to reach the goal by invoking the process component associated with each plan item in the defined sequence to fulfill an order. For details, see TIBCO ActiveFulfillment Administration Guide. The following diagram shows the relationship between different objects:
Figure 2: Object Relationship
Architecture | 15
Router
The Content-based router in OMS allows to route the order to the correct destination based on the contents of the order message. Content-based routing routes messages are based on the actual content of the message itself, rather than by a destination specified by the message. Content-based routing works by opening a message and applying a set of rules to its content to determine the destination of a message . By freeing the sending application from the need to know anything about where an order should be routed for fulfillment, content-based routing provides a high degree of flexibility to configure multiple type of Orchestration engine. For details, see TIBCO ActiveFulfillment Administration Guide.
Transient Data Store

Transient Data Store is a BE engine designed for storing the intermittent data during the order life cycle. ActiveFulfillment Orchestrator stores only the minimal order and plan data that is required for actual order orchestration. The primary functionalities of Transient Data Store are as follows: Storing the order and plan data in a transient, fault-tolerant data store Returning the order and plan information to the requesting process components through standard JMS interfaces Providing the create, update and delete operations for the data through standard JMS interfaces For details, see TIBCO ActiveFulfillment Administration Guide.
16 | Architecture
Services and Operations

The interfaces are organized into services that includes 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. The naming convention for endpoint URL is http://<MachineName>:<port>/<ModuleName>/
Interfaces/Inbound/<TRANSPORT>/<ServiceName>Service<TRANSPORT>.serviceagent /<serviceName>ServiceEndpoint.
The Service name has the first letter in lowercase once. For example, http://localhost:25400/OfferConfigurationAndValidation/
Interfaces/Inbound/HTTP/CustomerServiceHTTP.serviceagent/customerServiceEndpoint.
The naming convention for SOAP action is /<ModuleName>/Interfaces/

Inbound/<TRANSPORT>/<ServiceName><TRANSPORT>.serviceagent/ <serviceName>Endpoint/<OperationName>.
For example, for GetCustomerHierarchy with HTTP:

/OfferConfigurationAndValidation/Interfaces/Inbound/HTTP/ CustomerServiceHTTP.serviceagent/customerServiceEndpoint/GetCustomerHierarchy
For example, for GetCustomerHierarchy with JMS:

/OfferConfigurationAndValidation/Interfaces/Inbound/JMS/ CustomerServiceJMS.serviceagent/customerServiceEndpoint/GetCustomerHierarchy
The naming convention for JMS destination is

tibco.aff.<shortnameformodule>.services.<servicenamelowercase>.
For example, tibco.aff.om.services.order. The operations specified in the following table follows the naming conventions. Table 2: Services and Operations Summary Module Offer Configuration and Validation (OCV) Service Customer JMS Destination tibco.aff.ocv.services.customer Operation GetCustomerHierarchy GetCustomerImageForCustomer Inventory tibco.aff.ocv.services.inventory AssignInventoryItem AssignInventoryItems GetInventoryItem GetInventoryItems GetUserStatus ReassignInventoryItem TIBCO ActiveFulfillment Web Services
Architecture | 17 Module Service JMS Destination Operation ReassignInventoryItems RemoveInventoryItem RemoveInventoryItems RollbackInventoryItem RollbackInventoryItems SetUserStatus UpdateInventoryItem UpdateInventoryItems Offer tibco.aff.ocv.services.offer GetOfferDetails GetOffers RemoveOffer SaveOffer ValidateOffer Product tibco.aff.ocv.services.product GetEligibleProducts GetIneligibleSubscribers GetProductInformation GetSegments Subscriber tibco.aff.ocv.services.subscriber CreateSubscriber GetCustomerImageForSubscriber RemoveSubscriber UpdateSubscriber Order Management (OM) Order tibco.aff.om.services.order CancelOrder GetOrderDetails GetOrders GetOrderTasks SubmitOrder For all web services to work correctly, the data models should be available to Offer Configuration and Validation (OCV) and Automatic Order Plan Development (AOPD) components.
18 | 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 implemented in TIBCO ActiveMatrix BusinessWorks. The service calls the appropriate operation and performs the required operation before sending a reply back to the calling application.
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 message 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 | 19
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 implemented in TIBCO ActiveMatrix BusinessWorks. The service calls the appropriate operation and performs the required operation before sending a reply back to the calling application.
Part
II
ActiveFulfillment Services
Topics Security Header ActiveFulfillment Services Order Management Services
22 | ActiveFulfillment Services
Security Header
ActiveFulfillment supports both HTTP and JMS as transport protocol 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 provides by default 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 ActiveFulfillment Administration Guide.
Chapter
1
ActiveFulfillment Services
The location of all the WebService WSDLs is $AF_HOME/schemas/wsdl. Some of the XML schema [.xsd] files available under $AF_HOME/schemas/schema location imports other schemas located under same location. The location of the imported schemas may be incorrect in some cases and need to be modified. For instance, in the orchestrator/notification/notification.xsd file, change as follows: 1. Change ../../../../orchestrator/sharedResources/schemas/classes/aopd.xsd to ../aopd.xsd. 2. Change plan.xsd to ../plan.xsd. Similarly resolve other imports as needed.
Topics Customer Service Inventory Service Offer Service Product Service Subscriber Service
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:
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 is returned in the hierarchy. If set to false, then no products are included. This flag is not being used in this release.
| 25 The reply message format is:
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 83). CustomerHierarchy/Customer data structure. Data model for CustomerHierarchy/Customer is defined in XSD (refer section Common Data Format Specifications on page 83). 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 83). 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 83).
Subscriber
Subscriber (Choice)
CustomerHierarchy
CustomerHierarchy (Choice)
Get Customer Image For Customer This operation retrieves the 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 image.
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 83). If the customer was not found for the given CustomerID this element is omitted. Example
Inventory Service
This service contains operations that store inventory items for the customers and subscribers. 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 CustomerID Element Type String (Mandatory, Choice) SubscriberID String (Mandatory, Choice) ParentCustomerID String (Optional, Choice) ProductID String (Mandatory) Status String (Mandatory) Initial status to assign to the inventory item. Valid status are: DRAFT ACTIVE WITHDRAWN Description The ID of the customer to assign the inventory. The ID of the subscriber to assign the inventory. The ID of the parent customer that the subscriber is assigned. Product unique identifier.
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 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/OrderLineNumber
String (Mandatory)
Order/OrderLineAction
String (Mandatory)
Order/OrderDate
DateTime (Mandatory)
Order/Comments
String (Optional)
Order/CurrentOwnerCustomerID
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. UDF type
Order/CurrentOwnerSubscriberID
UDFs
Type (Optional)
UDFs/UDF UDFs/UDF/Name
Type (*) String (Mandatory)
User defined fields associated with the product User defined field name.
UDFs/UDF/Value
String (Mandatory)
User defined field value.
The reply message format is:
| 29 Table 8: Assign Inventory Item Reply Data Model Element Name ResultStatus Element Type ResultStatus (Mandatory) InventoryID String (Optional) Description Data model for ResultStatus is defined in XSD (refer section Common Data Format Specifications on page 83). Inventory identifier for the newly created inventory item. If the item is not created successfully, this is omitted.
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 Item/CustomerID Element Type Type (+) String (Choice) Item/SubscriberID String (Choice) Description Inventory item to assign. The ID of the customer to assign the inventory. The ID of the subscriber to assign the inventory.
30 | Element Name Item/ParentCustomerID Element Type String (Optional, Choice) Item/ProductID String (Mandatory) Item/Status String (Mandatory) Initial status to assign to the inventory item. The valid status are: Item/StartDate DateTime (Mandatory) DRAFT ACTIVE WITHDRAWN Description The ID of the parent customer that the subscriber is assigned. Product unique identifier.
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
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
Item/Order/CurrentOwnerSubscriberID
Item/UDFs
Type (Optional)
Item/UDFs/UDF
Type (*)
User defined fields associated with the product.
| 31 Element Name Item/UDFs/UDF/Name Element Type String (Mandatory) Item/UDFs/UDF/Value String (Mandatory) The reply message format is: User defined field value. Description User defined field name.
Table 10: Assign Inventory Items Reply Data Model Element Name ResultStatus Element Type ResultStatus (Mandatory) Item Item/ResultStatus Type (+) ResultStatus (Mandatory) Item/InventoryID String (Optional) Description Data model for ResultStatus is defined in XSD (refer section Common Data Format Specifications on page 83). Inventory item assigned. Data model for ResultStatus is defined in XSD (refer section Common Data Format Specifications on page 83). Inventory identifier for the newly created inventory item. If the item is not created successfully, this is omitted.
Get Inventory Item This operation retrieves a specific inventory item. The request message format is:
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.
32 |
Table 12: Get Inventory Item Reply Data Model Element Name ResultStatus Element Type ResultStatus (Mandatory) InventoryItem InventoryItem (Optional) Description Data model for ResultStatus is defined in XSD (refer section Common Data Format Specifications on page 83). Inventory Item data structure. Data model for Inventory Item is defined in XSD (refer section Common Data Format Specifications on page 83).
Get Inventory Items This operation retrieves the list of inventory items for an input criteria. The request message format is:
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.
| 33 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.
SubscriberID
ProductID
String (Optional)
ProductType
String (Optional)
Product 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 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 is returned. Pagination element. Items are always sorted by ascending Status and ProductType.
ProductSubType
String (Optional)
ProductDescription
String (Optional)
ItemUDF ItemUDF/Name ItemUDF/Value Count
Type (*) String (Mandatory) String (Mandatory) Long (Optional, Choice)
Pagination
Type (Optional, Choice)
34 | Element Name Pagination/StartRecord Element Type Long (Mandatory) Pagination/EndRecord Long (Mandatory) ItemSummary Boolean (Optional) Description 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.
Table 14: Get Inventory Items Reply Data Model Element Name ResultStatus Element Type ResultStatus (Mandatory) InventoryItems Type (Optional) InventoryItems/InventoryItem InventoryItem (*) Description Data model for ResultStatus is defined in XSD (refer section Common Data Format Specifications on page 83). 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 83). 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.
Pagination
Type (Optional)
Pagination/StartRecord
Long (Mandatory)
Pagination/EndRecord
Long (Mandatory)
| 35 Element Name Pagination/TotalRecords Element Type Long (Mandatory) Description Total count of item records that matched the input criteria. This value is used to compose subsequent pagination calls.
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: 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.
36 | Table 16: Get User Status Reply Data Model Element Name ResultStatus Element Type ResultStatus (Mandatory) Customer Customer/CustomerID Type (*) String (Mandatory) Customer/UserStatus String (Mandatory) Subscriber Subscriber/SubscriberID Type (*) String (Mandatory) Subscriber/ParentCustomerID String (Optional) Subscriber/UserStatus String (Mandatory) Parent customer ID for the subscriber, if one exists. User status for the subscriber. The valid values are: LOCKED UNLOCKED Subscriber user data structure. Subscriber ID for user status. User status for the customer. Description Data model for ResultStatus is defined in XSD (refer section Common Data Format Specifications on page 83). Customer user data structure. Customer ID for user status.
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:
| 37
Table 17: Reassign Inventory Item Request Data Model Element Name InventoryID Element Type String (Mandatory) EnableRollback Boolean (Optional) Description The ID of the inventory item to reassign. 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) SubscriberID String (Mandatory, Choice) ParentCustomerID String (Optional, Choice) Status String (Optional) 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 status are: DRAFT ACTIVE WITHDRAWN
38 | Element Name Order Element Type Type (Optional) Order/OrderID String (Mandatory) 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) The reply message format is: 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. 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. Description Order type to add to the order history.
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 83).
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:
| 39
Table 19: Reassign Inventory Items Request Data Model Element Name Item Item/InventoryID Element Type Type (+) String (Mandatory) Item/EnableRollback Boolean (Optional) Description Inventory item reassigned. The ID of the inventory item to be reassigned. Flag to indicate a rollback snapshot to be made for the current update. This flag is not being used in this release. Item/CustomerID String (Mandatory, Choice) Item/SubscriberID String (Mandatory, Choice) Item/ParentCustomerID String (Optional, Choice) Item/Status String (Optional) 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 status are: DRAFT ACTIVE WITHDRAWN
40 | Element Name Item/Order Element Type Type (Optional) Item/Order/OrderID String (Mandatory) Item/Order/OrderLineNumber String (Mandatory) Item/Order/OrderLineAction String (Mandatory) Item/Order/OrderDate DateTime (Mandatory) Item/Order/Comments String (Optional) Item/Order/CurrentOwnerCustomerID String (Optional, Choice) Item/Order/CurrentOwnerSubscriberID String (Optional, Choice) The reply message format is: 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. 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. Description Order type to add to the order history.
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 83). Inventory item reassigned Data model for ResultStatus is defined in XSD (refer section Common Data Format Specifications on page 83).
Item Item/ResultStatus
Type (+) ResultStatus (Mandatory)
| 41
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.
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.
42 | Table 24: Remove Inventory Items Reply Data Model Element Name ResultStatus Element Type ResultStatus (Mandatory) Item Item/ResultStatus Type (+) ResultStatus (Mandatory) Description Data model for ResultStatus is defined in XSD (refer section Common Data Format Specifications on page 83). Inventory item removed Data model for ResultStatus is defined in XSD (refer section Common Data Format Specifications on page 83).
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:
| 43 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) Item Item/ResultStatus Type (*) ResultStatus (Mandatory) Item/InventoryID String (Mandatory) Description Data model for ResultStatus is defined in XSD (refer section Common Data Format Specifications on page 83). Inventory item rolled back Data model for ResultStatus is defined in XSD (refer section Common Data Format Specifications on page 83). Inventory item ID that was rolled back.
Set User Status This operation sets the status of the specified users in the inventory. If the users are not present in the hierarchy, then they are created. All users have the same status as specified in the request. The request message format is:
Table 29: Set User Status Request Data Model Element Name CustomerID Element Type String (*) Description Customer ID of the user to set the status.
44 | Element Name Subscriber Subscriber/SubscriberID Element Type Type (*) String (Mandatory) Description 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: 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.
| 45 The request message format is:
Table 31: Update Inventory Item Request Data Model Element Name InventoryID Element Type String (Mandatory) EnableRollback Boolean (Optional) Flag to indicate a rollback snapshot should be made for the current update. This flag is not being used in this release. Status String (Optional) Description The ID of the inventory item to update.
Inventory item status to be set. The valid status are: DRAFT ACTIVE WITHDRAWN
StartDate
DateTime (Optional)
The date that the product went to ACTIVE status. The date that the product went to WITHDRAWN status.
EndDate
DateTime (Optional)
46 | Element Name Order Element Type Type (Optional) Order/OrderID String (Mandatory) 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) 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. 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. Description Order type to add to the order history.
UDFs/UDF/Value
String (Mandatory)
Table 32: Update 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
| 47 Element Name Element Type Description Format Specifications on page 83). 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) Flag to indicate a rollback snapshot should be made for the item to update. This flag is not being used in this release. Item/Status String (Optional) Description Inventory item updated. The ID of the inventory item to update.
Inventory item status to be set. The valid status are: DRAFT ACTIVE TIBCO ActiveFulfillment Web Services
48 | Element Name Element Type Description Item/StartDate DateTime (Optional) Item/EndDate DateTime (Optional) Item/Order Type (Optional) Item/Order/OrderID String (Mandatory) Item/Order/OrderLineNumber String (Mandatory) Item/Order/OrderLineAction String (Mandatory) Item/Order/OrderDate DateTime (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. Comments for this order. Order line number the product is ordered on. Order line action the product is ordered with. Order date and time the product is ordered. Order identifier the product is ordered on. WITHDRAWN
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/UDFs/UDF Item/UDFs/UDF/Name
Item/UDFs/UDF/Value
String (Mandatory)
| 49
Table 34: Update Inventory Items Reply Data Model Element Name ResultStatus Element Type ResultStatus (Mandatory) Item Item/ResultStatus Type (+) ResultStatus (Mandatory) Item/InventoryID String (Mandatory) Description Data model for ResultStatus is defined in XSD (refer section Common Data Format Specifications on page 83). Inventory item updated. Data model for ResultStatus is defined in XSD (refer section Common Data Format Specifications on page 83). 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.
50 |
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 83). Order data structure. Data model for Order is defined in XSD (refer section Common Data Format Specifications on page 83). If the offer is not found, this element is omitted.
Order
Order (Optional)
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:
| 51
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 to not to send it in a request without applying the filter criteria, otherwise large resultset may be returned. The returned offers are sorted by submission date in a descending order. 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.
LatestVersion
Boolean (Choice, Optional)
52 | Element Name Version Element Type Long (Choice, Optional) CustomerID String (Optional) Description 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. 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 Order date range type.
SubscriberID
String (Optional)
DateRange/EndDate
Date (Optional)
OrderStatus
String (Optional)
HeaderUDF HeaderUDF/Name HeaderUDF/Value OrderLineUDF
Type (*) String (Mandatory) String (Mandatory) Type (*)
OrderLineUDF/Name OrderLineUDF/Value Count
String (Mandatory) String (Mandatory) Long (Optional, Choice)
| 53 Element Name Element Type Description Version. If a large number of orders are found that match other criteria, then only the orders up to the Count is returned. Pagination Type (Optional, Choice) Pagination/StartRecord Long (Mandatory) Pagination/EndRecord Long (Mandatory) OrderSummary Boolean (Optional) 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.
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 83). 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 83).
Offers
Type (Optional)
Offers/Order
Order (*)
54 | Element Name Pagination Element Type Type (Optional) Description 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. Example
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:
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.
| 55
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 83).
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, then that offer is updated. Otherwise, a new offer is created in the cache. The request message format is:
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 83).
Table 42: Save Offer Reply Data Model Element Name ResultStatus Element Type ResultStatus (Mandatory) OrderRef String (Optional) Description Data model for ResultStatus is defined in XSD (refer section Common Data Format Specifications on page 83). Order reference number. If the offer could not be saved then this element is omitted.
56 | Element Name Version Element Type Long (Optional) Description Version of the saved offer. If the offer could not be saved then this element is omitted.
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 forms 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
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 83).
| 57 Table 44: Validate Offer Reply Data Model Element Name ResultStatus Element Type ResultStatus (Mandatory) ValidationPass Boolean (Mandatory) Description Data model for ResultStatus is defined in XSD (refer section Common Data Format Specifications on page 83). 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 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. Validation message type. The valid values are: Message/Code String (Mandatory) Message/Description String (Mandatory) Validation message description and possibly remedial action required. WARNING ERROR
Message
Type (*)
Message/LineNumber
String (Optional)
Message/Type
String (Mandatory)
Unique validation message code.
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 Catalogue. The request message format is:
58 |
Figure 7: Get Offer Price Request Field OderRef 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
Figure 8: Get Offer Price Reply Field BusinessTransactionID ResultStatus OrderLines TotalPrice OverallPrice Type String Long OrderLine Total Price Overall Price Cardinality Optional Mandatory Optional Optional Optional Description
| 59 Product prices are stored in the Product Catalogue, 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 are 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
In addition to the catalogue 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 catalogue 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
60 | 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: Price Matrix Node Computation
Customer One Time Price Sum of all order line prices of type Customer One Time Price Subscriber One Time Price Sum of all order line prices of type Subscriber One Time Price grouped by Subscriber ID
Customer Recurring Price Sum of all order line prices of type Customer Recurring Price grouped by Price Period Subscriber Recurring Price 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.
| 61 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:
62 | 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. 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
RoleID
String (*)
CustomerID
String (Mandatory)
Segment
Type (*)
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.
ProductName
String (Optional)
ProductType
String (Optional)
ProductSubType
String (Optional)
| 63 Element Name ProductDescription Element Type String (Optional) Description 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. Characteristic name. Valid for Instance, Feature, or Input characteristics.
ProductCharacteristic
Type (*)
ProductCharacteristic/Name
String (Mandatory)
ProductCharacteristic/Value
String (Optional)
Characteristic discrete value. Valid only for Instance characteristics.
OrderDate
DateTime (YYYY-MM-DDThh:mm:ss) (Optional)
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.
Status
String (Optional)
Count
Long (Optional, Choice)
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.
Pagination
Type (Optional, Choice)
Long (Mandatory)
Long (Mandatory)
End record index to return products. This index is inclusive.
64 |
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 83). 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 83). 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. TIBCO ActiveFulfillment Web Services
| 65 The request message format is:
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 83). 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.
The reply message format is: TIBCO ActiveFulfillment Web Services
66 |
Table 50: Get Product Information 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 83). 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 83). 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 83). Example ResultStatus
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.
| 67 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 83). 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 83). 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 83). In this structure, the following optional fields are ignored if populated: Subscriber ID is returned in the reply.
68 | Table 54: Create Subscriber Reply Data Model Element Name ResultStatus Element Type ResultStatus (Mandatory) SubscriberID String (Optional) Description Data model for ResultStatus is defined in XSD (refer section Common Data Format Specifications on page 83). Unique identifier for the newly created subscriber. If the operation call fails this element is omitted.
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.
Table 56: Get Customer Image For Subscriber Reply Data Model Element Name ResultStatus Element Type ResultStatus (Mandatory) Subscriber Subscriber (Optional) Description Data model for ResultStatus is defined in XSD (refer section Common Data Format Specifications on page 83). Subscriber data structure. Data model for subscriber is defined in XSD (refer section Common Data Format Specifications on page 83). 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
SubscribedInventory
Type (Optional)
| 69 Element Name Element Type Description found for the given SubscriberID, or if the subscriber has no current inventory, this element is omitted. SubscribedInventory/InventoryItem InventoryItem (*) InventoryItem data structure. Data model for InventoryItem is defined in XSD (refer section Common Data Format Specifications on page 83). If the subscriber was not found for the given SubscriberID, this element is omitted.
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.
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 83).
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:
70 | 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 83). 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 83).
Chapter
2
Order Management Services
The location of all the OMS WebService WSDLs is $AF_HOME/schemas/wsdl.
Topics Order Service
Order Service
This service contains operations that relate to 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) rollback anyType 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.
72 | The reply message format is:
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:
Table 63: GetOrderDetailsRequest Data Model Element Name OrderID Element Type String (Mandatory, Choice) Description The ID of the Order generated by OMS. This must be an exact match.
| 73 Element Name OrderRef Element Type String (Mandatory, Choice) ExternalBusinessTransactionID includeOrderRequest String boolean Description 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 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 83). 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:
74 |
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)
| 75 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. 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. OrderSubmission Dates before this date is 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 is 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.
subscriberID
String (Optional)
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
76 | 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.
ExternalBusinessTransactionID String orderID String (Mandatory, Choice) orderRef String (Mandatory, Choice) The reply message format is:
The order reference ID. This must be an exact match.
| 77
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 83). 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. Action field in the submitOrder Web service can take one value from the following possible values: PROVIDE UPDATE CANCEL CEASE The request message format is:
78 | 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 83). 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 have either of orderID and orderRef elements, then OMS will generate the orderRef and return it 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.
| 79 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. Action field in the submitOrder Web service can take one value from the following possible values: PROVIDE UPDATE CANCEL CEASE 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 83). Transaction ID sent by client.
ExternalBusinessTransactionID The reply message format is:
String
80 |
Figure 10: Synchronous Submit Order Response Data Model Table 72: Synchronous Submit Order Response Data Model 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 have either of orderID and orderRef elements, then OMS will generate the orderRef and return it 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:
| 81
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 83). Transaction ID sent by client.
ExternalBusinessTransactionID The response message format is:
String
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)
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 Components Operations Customer Notification Order Notification CustomerHierarchy Plan Notification Subscriber Segment Role Order OrderHeader OrderLine Product Characteristic Execution Plan PlanFragment InventoryItem InventoryItem Order
84 | 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 75: ResultStatus Element Details Element name Component Description Name of the component that detected the error. For the ActiveFulfillment implementation, this field is set to the Deployment variable of the TIBCO ActiveMatrix BusinessWorks or TIBCO BusinessEvents that the error occurred in. 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 AcitveFulfillment component that produced the error. This code is also visible inside component log and audit files. Refer to Error Codes and Messages on page 123 for details of this format. Message A descriptive text string associated with code.
Common Data Format Specifications | 85
ResultFault
The XML schema structure for the ResultFault is:
Table 76: ResultFault Element Details Element name code Description The error code, a string that identifies the error and the TIBCO AcitveFulfillment component that produced the error. This code is also visible inside component log and audit files. Refer to Error Codes and Messages on page 123 for details of this format. message A descriptive text string associated with code.
Components
Component Description
ActiveFulfillmentInterface TIBCO ActiveMatrix BusinessWorks engine ActiveFulfillmentRulesEngine TIBCO BusinessEvents engine OMS Web-based graphical user interface for order management. It persists order data, search, view orders, view track and trace and to take actions on order/order lines. It also provides track and trace view for orders fulfilled or being fulfilled.
Operations
Operation AssignInventoryItems Component Resource
ActiveFulfillmentInterface /OfferConfigurationAndValidation/BusinessServices/ Inventory/AssignInventoryItems.process
ReassignInventoryItems
ActiveFulfillmentInterface /OfferConfigurationAndValidation/BusinessServices/ Inventory/ReassignInventoryItems.process
RemoveInventoryItems
ActiveFulfillmentInterface /OfferConfigurationAndValidation/BusinessServices/ Inventory/RemoveInventoryItems.process
UpdateInventoryItems
ActiveFulfillmentInterface /OfferConfigurationAndValidation/BusinessServices/ Inventory/UpdateInventoryItems.process
AssignInventoryItem-BE
ActiveFulfillmentRulesEngine /OfferConfigurationAndValidation/Events/Inventory/ Rules/InventoryRuleSet.ruleset
GetInventoryItem-BE
GetInventoryItems-BE
RemoveInventoryItem-BE
UpdateInventoryItem-BE
ReassignInventoryItem-BE
GetCustomer-BE
ActiveFulfillmentRulesEngine /OfferConfigurationAndValidation/Events/ OfferingManagement/Rules/CustomerRuleSet.ruleset
SetCustomer-BE
GetCustomerHierarchy-BE
GetEligibleProductsCustomer-BE ActiveFulfillmentRulesEngine /OfferConfigurationAndValidation/Events/ OfferingManagement/Rules/CustomerRuleSet.ruleset SetOffer-BE ActiveFulfillmentRulesEngine /OfferConfigurationAndValidation/Events/ OfferingManagement/Rules/OfferRuleSet.ruleset TIBCO ActiveFulfillment Web Services
88 | Common Data Format Specifications Operation GetOffer-BE Component Resource
ActiveFulfillmentRulesEngine /OfferConfigurationAndValidation/Events/ OfferingManagement/Rules/OfferRuleSet.ruleset
GetOfferList-BE
GetOfferPrice-BE
GetSubscriber-BE
ActiveFulfillmentRulesEngine /OfferConfigurationAndValidation/Events/ OfferingManagement/Rules/SubscriberRuleSet.ruleset
SetSubscriber-BE
ActiveFulfillmentRulesEngine /OfferConfigurationAndValidation/Events/ OfferingManagement/Rules/SubscriberRuleSet.ruleset
GetEligibleProductsSubscriber-BE ActiveFulfillmentRulesEngine /OfferConfigurationAndValidation/Events/ OfferingManagement/Rules/SubscriberRuleSet.ruleset OfferValidation-BE ActiveFulfillmentRulesEngine /OfferConfigurationAndValidation/Events/ OfferValidation/Rules/ValidationControl.ruleset LoadProductCatalogue-BE ActiveFulfillmentRulesEngine /OfferConfigurationAndValidation/Events/ ProductManagement/Rules/ProductCatalogueRuleSet.ruleset GetProductInformation-BE ActiveFulfillmentRulesEngine /OfferConfigurationAndValidation/Events/ ProductManagement/Rules/ProductCatalogueRuleSet.ruleset SetSegments-BE ActiveFulfillmentRulesEngine /OfferConfigurationAndValidation/Events/ ProductManagement/Rules/SegmentRuleSet.ruleset GetSegments-BE ActiveFulfillmentRulesEngine /OfferConfigurationAndValidation/Events/ ProductManagement/Rules/SegmentRuleSet.ruleset GetOrderDetails GetOrders ActiveFulfillmentInterface /OrderManagement/BusinessServices/Order/GetOrderDetails.process ActiveFulfillmentInterface /OrderManagement/BusinessServices/Order/ GetOrders.process GetOrderTasks ActiveFulfillmentInterface /OrderManagement/BusinessServices/Order/ GetOrderTasks.process SubmitOrder ActiveFulfillmentInterface /OrderManagement/BusinessServices/Order/ SubmitOrder.process DevelopAmendedOrderPlan ActiveFulfillmentInterface /OrderManagement/BusinessServices/OrderPlan/ DevelopAmendedOrderPlan.process DevelopOrderPlan ActiveFulfillmentInterface /OrderManagement/BusinessServices/OrderPlan/DevelopOrderPlan.process
Common Data Format Specifications | 89 Operation CallIntegrationService GetAmendedOrderPlan GetOrderPlan Component Resource
ActiveFulfillmentInterface /OrderManagement/BusinessServices/Integration/CallIntegrationService.process ActiveFulfillmentInterface /OrderManagement/Interfaces/Outbound/Event/GetAmendedOrderPlan.process ActiveFulfillmentInterface /OrderManagement/Interfaces/Outbound/Event/ GetOrderPlan.process
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 77: Customer Element Details Element Name CustomerID Element Type String (Mandatory) ParentCustomerID String (Optional) CustomerRef String (Optional) CustomerType 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. Customer type classification as configured for the Party in the Product Catalogue.
Common Data Format Specifications | 91 Element Name FirstName Element Type String (Choice, Mandatory) LastName String (Choice, Mandatory) CompanyName String (Choice, Mandatory) Address Type (Optional) Address/AddressLine1 String (Mandatory) Address/AddressLine2 String (Optional) Address/Locality String (Mandatory) Address/Region String (Optional) Address/PostCode String (Mandatory) Address/Country String (Mandatory) Segments Type (Optional) Segments/Channel Segments/Market String (*) String (Optional) Segments/Rating String (Optional) Segments/Risk String (Optional) Override Boolean (Optional) 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. 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 segments. Customer address country. Customer address post code. Customer address region. Customer address locality. Customer address line 2. Customer address line 1. Description 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.
92 | Common Data Format Specifications Element Name Type Element Type String (Optional) Status String (Optional) Notes String (Optional) Roles Type (Optional) Roles/Role Type (*) 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 section Common Data Format Specifications on page 83). List of UDFs as configured on the Party Extension in the Product Catalogue. UDF type. Name of the attribute. Customer notes. Description Customer configuration type as configured on the Party in the Product Catalogue. Customer status.
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 78: 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.
96 | Common Data Format Specifications Element Name Customers/Customer/Status Element Type String (Optional) Customers/Customer/Subscribers Type (Optional) 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 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. Description Customer status
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 83). 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 79: Subscriber Element Details Element Name SubscriberID Element Type String (Optional) CustomerID String (Optional) SubscriberRef 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. Subscriber reference identifier for external systems.
Common Data Format Specifications | 99 Element Name FirstName Element Type String (Mandatory) LastName String (Mandatory) Address Type (Optional) Address/AddressLine1 String (Mandatory) Address/AddressLine2 String (Optional) Address/Locality String (Mandatory) Address/Region String (Optional) Address/PostCode String (Mandatory) Address/Country String (Mandatory) Segments Type (Optional) Segments/Channel Segments/Market String (*) String (Optional) Segments/Rating String (Optional) Segments/Risk String (Optional) Status String (Optional) Notes String (Optional) Subscriber notes. Subscriber status. Subscriber risk rating. Subscriber value rating. Subscriber channels. Subscriber market. Subscriber segments. Subscriber address country. Subscriber address post code. Subscriber address region. Subscriber address locality. Subscriber address line 2. Subscriber address line 1. Subscriber address information. Subscriber last name. Description Subscriber first name.
100 | Common Data Format Specifications Element Name Roles Element Type Type (Optional) Roles/Role Type (*) Description 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 83). List of UDFs.
UDFs
Type (Optional)
UDF type. Name of the attribute.
UDFs/UDF/Value
String (Mandatory)
Value of the attribute.
Segment
This class is the data model for the Segment object. It may be used across services and ID defined in XSD format.
Table 80: 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 81: 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 82: 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 send as an empty element in the SubmitOrder request, then OMS generates the orderRef element. If the orderRef element is not send, then schema validation fails. Order Header data structure.
header
headerType (Mandatory)
104 | Common Data Format Specifications Element Name line Element Type lineType Description 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.
106 | Common Data Format Specifications Table 83: 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. Expiration date for the offer. Not relevant for orders. Date order is expected to be completed.
ExpirationDate
Date (Optional)
ExpectedCompletionDate
DateTime (Optional)
InvoiceAddress
Type (Optional)
Invoice address.
InvoiceAddress/AddressLine1
String (Mandatory)
Invoice address line 1.
InvoiceAddress/AddressLine2
String (Optional)
Invoice address line 2.
InvoiceAddress/Locality
String (Mandatory)
Invoice address locality.
InvoiceAddress/Region
String (Optional)
Invoice address region.
InvoiceAddress/PostCode
String (Mandatory)
Invoice address post code.
Common Data Format Specifications | 107 Element Name InvoiceAddress/Country Element Type String (Mandatory) DeliveryAddress Type (Optional) DeliveryAddress/AddressLine1 String (Mandatory) DeliveryAddress/AddressLine2 String (Optional) DeliveryAddress/Locality String (Mandatory) DeliveryAddress/Region String (Optional) DeliveryAddress/PostCode String (Mandatory) DeliveryAddress/Country String (Mandatory) Notes String (Optional) SLAs Type (Optional) SLAs/SLA SLAs/SLA/SLAID Type (*) String (Mandatory) UDF UDF/Name Type (*) String (Mandatory) UDF/Value String (Mandatory) Value of the attribute. UDF type Name of the attribute. List of SLAs passed through to back-end systems. These SLAs do not apply within the order management. SLA type. SLA ID. Order notes. Delivery address country. Delivery address post code. Delivery address region. Delivery address locality. Delivery address line 2. Delivery address line 1. Delivery address. Description Invoice address country.
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.
Common Data Format Specifications | 109 Table 84: 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.)
110 | Common Data Format Specifications Element Name udf Element Type String (Mandatory) characteristic Type (Optional) customerItemID String (Optional) status statusChanged extension String (Optional) Current order status. Customer item ID. Description Value of the attribute. This must be minimum of one character in length. List of characteristics.
Product
This class is the data model for the Product object. It may be used across services and ID defined in XSD format.
Table 85: 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 86: 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) Values/value/value String (Optional) Characteristic value. 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.
Common Data Format Specifications | 113 Element Name Values/value/valueFrom Element Type String (Optional) Values/value/valueTo String (Optional) Characteristic value range to. Description Characteristic value range from.
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 87: 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.
116 | Common Data Format Specifications Element Name planCreationDate Element Type DateTime (Mandatory) status String (Mandatory) statusChanged dateTime (Mandatory) description String (Mandatory) planStartDate dateTime (Mandatory) planStartMillis isAmendment planItem udf long boolean planItemType udfSetType Timestamp when the plan started executing. Flag identifying if the plan is 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. Start date and time for the plan. Date Time when the last status was changed. Description of the plan. Status of the overall plan. Description Date and time the plan was created.
planItemID planItemName planFragmentUniqueID planFragment orderLine action startMilestone milestone parentID childID siblingID dependentID
String String String
List String
List of order lines for the corresponding plan item. Action for the plan Item.
Plan Item Ids on which this plan item depends. String String String Plan Item Ids which are dependent on this plan item Plan Item Ids of sibling products for this plan item. Plan Item Ids of dependent products for this plan item.
Common Data Format Specifications | 117 Element Name startTimeStamp endTimeStamp cancelled isNonExecuting Element Type long long boolean boolean Description 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 88: Inventory Item Element Details Element Name InventoryID Element Type String (Mandatory) CustomerID String (Mandatory, Choice) SubscriberID String (Mandatory, Choice) Customer ID that this inventory item is associated with. Subscriber ID that this inventory item is associated with. Description Inventory identifier.
120 | Common Data Format Specifications Element Name ParentCustomerID Element Type String (Optional, Choice) UserStatus String (Optional) Description Parent Customer ID that this inventory is indirectly linked to through the Subscriber ID.
Current user status in the inventory for the SubscriberID or CustomerID. The valid values are: LOCKED UNLOCKED
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 status 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 UDFs
Type (*) Type (Optional)
Order type. Refer to the InventoryItemOrder type for details. UDF type.
UDFs/UDF TIBCO ActiveFulfillment Web Services
Type (*)
User defined fields associated with the product.
Common Data Format Specifications | 121 Element Name UDFs/UDF/Name UDFs/UDF/Value Element Type String (Mandatory) String (Mandatory) Description 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 89: 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
124 | Error Codes and Messages
Error Code Format

Error codes are formatted as follows: Table 90: AFF-<component>-<subcomponent>-<code> Element
<component>
Description
Valid Values
TIBCO ActiveFulfillment component OCV - Offer Configuration and that contains the error. Validation OMS - Order Management PC - Product Catalogue
<subcomponent>
TIBCO ActiveFulfillment OCV: 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 | 125
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.
Index | 127
Index
C
customer support 10
S
services 16
G
GetCustomerHierarchy 23
T
TIBCO ActiveFulfillment 11
128 | Index

Tib Af Webservices

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Tib Af Webservices

Загружено:

Авторское право:

Доступные форматы

TIBCO ActiveFulfillment Web Services

Software Release 1.2.0 September 2011

TIBCO ActiveFulfillment Web Services

Part II: ActiveFulfillment Services....................................................21

Chapter 1 ActiveFulfillment Services.....................................23

Chapter 2 Order Management Services.................................71

Appendix A Common Data Format Specifications.......................83

TIBCO ActiveFulfillment Web Services

Appendix B Error Codes and Messages......................................123

TIBCO ActiveFulfillment Web Services

TIBCO ActiveFulfillment Web Services

preparation, installation, and configuration.

contains the list of known issues for this release.

as well as all the screens.

TIBCO ActiveFulfillment Web Services

bold code font

TIBCO ActiveFulfillment Web Services

Connecting with TIBCO Resources

TIBCO ActiveFulfillment Web Services

Topics Architecture Overview Services and Operations Integration Channels

TIBCO ActiveFulfillment Web Services

TIBCO ActiveFulfillment Web Services

Order Manager GUI

TIBCO ActiveFulfillment Web Services

Order Manager Server

Figure 2: Object Relationship

TIBCO ActiveFulfillment Web Services

Transient Data Store

TIBCO ActiveFulfillment Web Services

Services and Operations

The naming convention for SOAP action is /<ModuleName>/Interfaces/

For example, for GetCustomerHierarchy with HTTP:

For example, for GetCustomerHierarchy with JMS:

The naming convention for JMS destination is

TIBCO ActiveFulfillment Web Services

SOAP Over HTTP

SOAP Over JMS

TIBCO ActiveFulfillment Web Services

TIBCO ActiveFulfillment Web Services

TIBCO ActiveFulfillment Web Services

TIBCO ActiveFulfillment Web Services

TIBCO ActiveFulfillment Web Services

TIBCO ActiveFulfillment Web Services

| 25 The reply message format is:

TIBCO ActiveFulfillment Web Services

TIBCO ActiveFulfillment Web Services

TIBCO ActiveFulfillment Web Services

String (Optional, Choice)

String (Optional, Choice)

Type (*) String (Mandatory)

User defined field value.

The reply message format is:

TIBCO ActiveFulfillment Web Services

TIBCO ActiveFulfillment Web Services

String (Optional, Choice)

String (Optional, Choice)

User defined fields associated with the product.

TIBCO ActiveFulfillment Web Services

TIBCO ActiveFulfillment Web Services

TIBCO ActiveFulfillment Web Services

String (Optional, Choice)

ItemUDF ItemUDF/Name ItemUDF/Value Count

Type () String (Mandatory) String (Mandatory) Type ()