Tib Af Webservices(1)

7/29/2019 Tib Af Webservices(1)

1/142

TIBCO

Fulfillment OrderManagement Web Services

Software Release 2.0

November 2012


2/142


3/142

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 LIMITEDADD-ON FUNCTIONALITY) OF THE LICENSED TIBCO SOFTWARE. THE EMBEDDED OR BUNDLEDSOFTWARE IS NOT LICENSED TO BE USED OR ACCESSED BY ANY OTHER TIBCO SOFTWARE OR FORANY OTHER PURPOSE.

USE OF TIBCO SOFTWARE AND THIS DOCUMENT IS SUBJECT TO THE TERMS AND CONDITIONS OF ALICENSE AGREEMENT FOUND IN EITHER A SEPARATELY EXECUTED SOFTWARE LICENSE AGREEMENT,OR, IF THERE IS NO SUCH SEPARATE AGREEMENT, THE CLICKWRAP END USER LICENSE AGREEMENTWHICH IS DISPLAYED DURING DOWNLOAD OR INSTALLATION OF THE SOFTWARE (AND WHICH ISDUPLICATED IN LICENSE.PDF) OR IF THERE IS NO SUCH SOFTWARE LICENSE AGREEMENT ORCLICKWRAP END USER LICENSE AGREEMENT, THE LICENSE(S) LOCATED IN THE LICENSE FILE(S) OFTHE SOFTWARE. USE OF THIS DOCUMENT IS SUBJECT TO THOSE TERMS AND CONDITIONS, AND YOURUSE 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 SoftwareInc.

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 ofTIBCO 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 SunMicrosystems, 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 respectiveowners and are mentioned for identification purposes only.

This software may be available on multiple operating systems. However, not all operating system platforms for aspecific software version are released at the same time. Please see the readme.txt file for the availability of thissoftware version on a specific operating system platform.

THIS DOCUMENT IS PROVIDED AS IS WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS ORIMPLIED, 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. CHANGESARE PERIODICALLYADDED TO THE INFORMATION HEREIN; THESE CHANGES WILL BE INCORPORATEDIN NEW EDITIONS OF THIS DOCUMENT. TIBCO SOFTWARE INC. MAY MAKE IMPROVEMENTS AND/ORCHANGES IN THE PRODUCT(S) AND/OR THE PROGRAM(S) DESCRIBED IN THIS DOCUMENT AT ANYTIME.

THE CONTENTS OF THIS DOCUMENT MAY BE MODIFIED AND/OR QUALIFIED, DIRECTLY OR INDIRECTLY,

BY OTHER DOCUMENTATION WHICH ACCOMPANIES THIS SOFTWARE, INCLUDING BUT NOT LIMITEDTO ANY RELEASE NOTES AND "READ ME" FILES.

Copyright 2010-2012 TIBCO Software Inc. ALL RIGHTS RESERVED.

TIBCO Software Inc. Confidential Information

TIBCOFulfillment Order Management Web Services


4/142


5/142

Contents

Preface.....................................................................................................................7

Changes from the Previous Release of this Guide..................................................................8

Related Documentation............................................................................................................9

Typographical Conventions....................................................................................................10

Connecting with TIBCO Resources........................................................................................11

Part I: Architecture.............................................................................13

Chapter 1 Fulfillment Orchestration Overview......................19

Fulfillment Orchestration Components........................................................................20

Services and Operations........................................................................................................14

Integration Channels..............................................................................................................16

SOAP Over HTTP........................................................................................................16

SOAP Over JMS..........................................................................................................16

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

Security Header......................................................................................................................22

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

Customer Service........................................................................................................23Inventory Service.........................................................................................................26

Offer Service................................................................................................................51

Product Service...........................................................................................................62

Subscriber Service......................................................................................................69

Disabling SOAP_HTTP and SOAP_JMS Services......................................................72

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

Order Service..............................................................................................................75

Purge Order Service....................................................................................................87

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

ResultStatus...........................................................................................................................92

ResultFault.............................................................................................................................93

Customer................................................................................................................................94

Notification..............................................................................................................................97

Order Notification...................................................................................................................98


TOC | 5


6/142

CustomerHierarchy.................................................................................................................99

Plan Notification...................................................................................................................101

Subscriber............................................................................................................................102

Segment...............................................................................................................................105

Role......................................................................................................................................106

Order....................................................................................................................................107

OrderHeader........................................................................................................................109OrderLine.............................................................................................................................113

Product.................................................................................................................................116

Characteristic.......................................................................................................................117

Execution Plan.....................................................................................................................119

PlanFragment.......................................................................................................................123

InventoryItem........................................................................................................................124

InventoryItem Order.............................................................................................................127

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

Error Code Format...............................................................................................................130

Error Codes..........................................................................................................................131

Customers............................................................................................................................132

Inventory...............................................................................................................................133

Offers....................................................................................................................................134

OfferValidation......................................................................................................................135

Products...............................................................................................................................137

Subscr ibers..........................................................................................................................138

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

Orchestrator Pre-processors and Rules...............................................................................141


6 | TOC


7/142

Preface

The preface contains information about documentation related to the current document, typographicalconventions, and information on how to contact TIBCO support.



8/142

Changes from the Previous Release of this Guide

This section itemizes the major changes from the previous release of this guide.

Endpoint URLs

The AFS is deployed as part of OMS server, the endpoint URLs for SOAP over HTTP have changed. Security

All calls to the web service are authenticated using Username token based approach.

Logging

The logging is done using the AFFLogger APIs. Based on configured appender, the logs are created inthe corresponding location.


8 | Preface


9/142

Related Documentation

TIBCO Fulfillment Order Management Installation and Configuration Read this manual for instructions on sitepreparation, installation, and configuration.

TIBCO Fulfillment Order Management Administration Read this manual for instructions on administration tasks.

TIBCO Fulfillment Order Management Web Services Read this manual for information about Web services. TIBCO Fulfillment Order Management Release Notes Read the release notes for a list of features. This document

also contains the list of known issues for this release.

TIBCO Fulfillment Order Management User's Guide Read this manual for Fulfillment Order Management featuresand functionality as well as all the screens.

TIBCO Fulfillment Order Management Concepts and Architecture Read this manual for terminology and conceptsof TIBCO Fulfillment Order Management.


Preface | 9


10/142

Typographical Conventions

The following typographical conventions are used in this manual:

Table 1: General Typographical Conventions

UseConvention

Many TIBCO products are installed within the same home directory. This directory isreferenced in documentation as TIBCO_HOME. The value ofTIBCO_HOME depends onthe operating system. For example, on Unix systems the default value is $ HOME/ t i b c o .

TIBCO_HOME

TRA_HOME

AF_HOMETIBCO Runtime Agent installs into a directory inside ENV_HOME. This directory isreferenced in documentation as TRA_HOME. The value ofTRA_HOME depends on theoperating system. For example, on Unix systems the default value is $ T I B CO_ HOME / t r a .

TIBCO Fulfillment Order Management installs into a directory inside ENV_HOME. Thisdirectory is referenced in documentation asAF_HOME. The value ofAF_HOME dependson the operating system. For example, on Unix systems the default value is$ T I BCO_ HOME/ a f / 2 . 0 .

Code font identifies commands, code examples, filenames, pathnames, and outputdisplayed in a command window. For example:

c o de f o nt

Use My Comma n d to start the foo process.

Bold code font is used in the following ways:b ol d c od e f o nt

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 particularinterest.

In command syntax, to indicate the default parameter for a command. For example,

if no parameter is specified, MyCommand is enabled:

My Comma n d [ e na bl e | d i s ab l e ]

Italic font is used in the following ways:italic font

To indicate a document title. For example: See TIBCO Fulfillment Order ManagementWeb Services.

To introduce new terms For example: A portal page may contain severalportlets.Portlets are mini-applications that run in a portal.

To indicate a variable in a command or code syntax that you must replace. Forexample: My Comma n d 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 theinformation provided in the current section to achieve a specific result.

The warning icon indicates the potential for a damaging situation, for example, dataloss or corruption if certain steps are taken or not taken.


10 | Preface


11/142

Connecting with TIBCO Resources

How to Join TIBCOmmunity

TIBCOmmunity is an online destination for TIBCO customers, partners, and resident expertsa place to

share and access the collective experience of the TIBCO community. TIBCOmmunity offers forums, blogs,and access to a variety of resources. To register, go to http://www.tibcommunity.com.

How to Access All TIBCO Documentation

After you join TIBCOmmunity, you can access the documentation for all supported product versions here:

http://docs.tibco.com.

How to Contact TIBCO Support

For comments or problems with this manual or the software it addresses, please contact TIBCO Support asfollows:

For an overview of TIBCO Support, and information about getting started with TIBCO Support, visit thissite:

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.


Preface | 11
http://www.tibcommunity.com/http://docs.tibco.com/http://www.tibco.com/services/supporthttps://support.tibco.com/https://support.tibco.com/http://www.tibco.com/services/supporthttp://docs.tibco.com/http://www.tibcommunity.com/


12/142


13/142

Part

IArchitecture

TIBCO

Fulfillment Order Management is a meta data driven order management and fulfillment system whichallows development of fulfillment plans based on meta-data specified in product catalogs. Order fulfillment andservice provisioning is no longer a simple single-service or product workflow. The dynamic bundled offeringsalong with the explosion of devices, applications, real time inventory management and third-party content providersrequires a complex order fulfillment system which can adapt to the changes in processes, meta data and inventory.Traditional OSS/BSS 1 approach with their data silos fail to provide a dynamic and agile solution. An end-to-endorder management system based on product and service catalogs is a key differentiator of Fulfillment OrderManagement.

TIBCO Fulfillment Order Management is a comprehensive software solution to design, deploy and maintainhigh-performance scalable enterprise-level business processes for advanced and dynamic order fulfillment. TIBCOFulfillment Order Management enables companies to quickly introduce new product offerings and in most casesrequiring little or no change to fulfillment processes. The product bundles are decomposed into existing productsto automatically generate a plan specific to the order.

TIBCO Fulfillment Order Management also enables companies to efficiently manage changes to the existing businessprocess to meet a rapidly changing business environment.

Product model can be defined following SID 9 guidelines using TIBCO Fulfillment Catalog or any other catalogmanagement system and imported into Fulfillment Order Management.

Topics

Fulfillment Orchestration Overview Services and Operations

Integration Channels

1 Operational/Operations Support System (OSS) Software applications support back-office activities operatinga company network, provision and maintain customer services. OSS is traditionally used by network planners,service designers, operations, architects, support, and engineering teams in the service provider. Softwareapplications that support customer-facing activities. Billing, order management, customer relationshipmanagement, call center automation, are all Business Support Systems (BSS) applications.



14/142

Services and Operations

The interfaces are organized into services that include related operations. The following interfaces are exposedfor any client to invoke the services related to the framework. These services can be invoked over two differentchannels: SOAP over HTTP and SOAP over JMS.

All Web Services support HTTP and JMS. Web Services endpoint URL and SOAP action is based on modulename, service name, and operation name.

h t t p : / / < >: < >/ o ms Se r v e r / a p i / < > Se r v i c e HTTP.

The Service name has the first letter in lowercase once.

For example, h t t p : / / 1 0. 0 . 2 . 1 92 : 1 80 90 / o ms Se r v e r / a pi / I n ve nt o r y Se r v i c eHTTP.

The naming convention for SOAP action is / o ms Se r v e r / a p i / Se r v i c e HTTP .

The naming convention for JMS destination is t i b c o . a f f . . s er v i c es . .

For example, t i b c o. a f f . o m. s er v i c es . o r d er .

The operations specified in the table follow the naming conventions.

Table 2: Services and Operations Summary

OperationJMS DestinationServiceModule

GetCustomerHierarchytibco.aff.ocv.services.customerCustomerOffer Configuration andValidation (OCV)

GetCustomerImage

ForCustomer

AssignInventoryItemtibco.aff.ocv.services.inventoryInventory

AssignInventoryItems

GetInventoryItem

GetInventoryItems

GetUserStatus

ReassignInventoryItem

ReassignInventoryItems

RemoveInventoryItem

RemoveInventoryItems

RollbackInventoryItem

RollbackInventoryItems

SetUserStatus

UpdateInventoryItem

UpdateInventoryItems

GetOfferDetailstibco.aff.ocv.services.offerOffer


14 | Architecture


15/142

OperationJMS DestinationServiceModule

GetOffers

RemoveOffer

SaveOffer

ValidateOffer

GetEligibleProductstibco.aff.ocv.services.productProduct

GetIneligibleSubscribers

GetProductInformation

GetSegments

CreateSubscribertibco.aff.ocv.services.subscriberSubscriber

GetCustomerImage

ForSubscriber

RemoveSubscriberUpdateSubscriber

CancelOrdertibco.aff.om.services.orderOrderOrder Management(OM)

GetOrderDetails

GetOrders

GetOrderExecutionPlan

SubmitOrder

AmendOrder

SyncSubmitOrder

WithdrawOrder

PerformBulkOrderAction

purgeOrdersNAPurge

getPurgeStatus

RequestOfflineCatalogNAOfflineCatalog

For all the web services to work correctly, the data models should be available to Offer Configurationand Validation (OCV) and Automatic Order Plan Development (AOPD) components.


Architecture | 15


16/142

Integration Channels

To provide maximum flexibility for exposing services to the enterprise, service implementation is separatedfrom the interface. This allows services to be invoked from different transport mechanisms. The followingtransports 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 integrationpattern 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 ManagementServices component. The service calls the appropriate operation and performs the required operation beforesending a reply back to the calling application.

Since AFS is now deployed as part of the OMS Server, the endpoint URLs for SOAP over HTTP have changed.The new endpoint URLs for respective components are as follows:

InventoryService : h t t p : / / :

/ o ms Se r v e r / a pi / I n ve nt o r y Se r v i c eHTTP

CustomerService : h t t p : / / < >: <

>/ o ms Se r v e r / a pi / Cu s t o me r Se r v i c e HTTP

SubscriberService : h t t p : / / :

/ o ms Se r v e r / a pi / Su b sc r i b er Se r v i c eHTTP

OfferService : h t t p : / / :

/ o ms Se r v e r / a pi / Of f e r Se r v i c eHTTP

ProductService: h t t p : / / :

/ o ms Se r v e r / a pi / Pr o du c t Se r v i c eHTTP

Offline Catalog Request: h t t p : / / :

/ o ms Se r v er / a p i / o f f l i n e Ca t a l o g u e WS.

The Offline Catalog request service can be used to send the request to AFI to load the Offline models.

SOAP Over JMS

SOAP works over a variety of transports and is not restricted to HTTP web services. JMS provides a highlyavailable transport that delivers messages over and above what HTTP provides. SOAP over JMS service callsuse the TIBCO proposed specification extension for sending SOAP messages over JMS. TIBCO ActiveMatrixBusinessWorks supports calling SOAP over JMS synchronously using the standard SOAP Request/Replyactivity. Non-TIBCO ActiveMatrix BusinessWorks application should be able to call SOAP over JMS servicesboth synchronously and asynchronously using standard JMS messaging techniques that implement therequired elements of the specification extension.

The synchronous integration pattern is as follows:


16 | Architecture


17/142

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 OrderManagement Services component. The service calls the appropriate operation and performs the required

operation before sending a reply back to the calling application.The JMS destinations where the SOAP message should be send is specified in the respective web servicesWSDL document.


Architecture | 17


18/142


19/142

Chapter

1Fulfillment Orchestration Overview

New technologies and network architectures enable communications service provider (CSP) to create innovativeconverged products and services offerings which are introduced faster and have shorter life cycles than previousservice offerings to address a very changing and competitive market.

In view of the rapid pace of change in the technology, the industry is evolving to become a contributor and notremain a mere consumer of technology. In this environment, communications service providers face the challengeof defining, managing and delivering numerous complex products and variations to the market in most effectiveway to differentiate themselves. TIBCO has concentrated and structured its services around the following points:

New product offering are designed and rolled out in a few weeks including implementation in all fulfillmentchain.

Customer orders are instantly fulfilled and provisioned in the network to maximize customer experience.

Customer orders come from large variety of order entries such as customer self-care portals, customer salesrepresentative desk or even network elements detecting service access to leverage fulfillment chain investmentand support hardware rationalization.

TIBCO providing CSPs with a comprehensive and integrated solution ready for complete end-to-end fulfillmentautomation. The TIBCO Fulfillment Orchestration Suite defines new product and service offering, associatedfulfillment rules and processes, and automate the delivery from order capture down to the service activation inthe network.

Figure 1: Fulfillment Orchestration Architecture

Topics



20/142

Fulfillment Orchestration Components

Fulfillment Orchestration Components

The TIBCO Fulfillment Orchestration Suite solution is capable of supporting end-to-end order fulfillmentwith Order Management, Provisioning and Catalog capabilities.

The following are the constituents of the TIBCO Fulfillment Orchestration Suite: Fulfillment Catalog: A Catalog function that defines and manages life cycles of commercial and technical

offering.

Fulfillment Order Management: TIBCO Fulfillment Order Management TIBCO Fulfillment OrderManagement is a meta data driven order management and fulfillment system which allows developmentof fulfillment plans based on meta-data specified in product catalogs. Order fulfillment and serviceprovisioning is no longer a simple single-service or product workflow. The dynamic bundled offeringsalong with the explosion of devices, applications, real time inventory management and third-party contentproviders requires a complex order fulfillment system which can adapt to the changes in processes, metadata and inventory. Traditional OSS/BSS 2 approach with their data silos fail to provide a dynamic andagile solution. An end-to-end order management system based on product and service catalogs is a keydifferentiator of Fulfillment Order Management.

Fulfillment Provisioning: A Provisioning function that automates the activation of the underlying networkservices and allocation of all the network resources. The Fulfillment Orchestration Suite has a Provisioningelement that implements Service Order Management & Resource Order Management TAM applicationsand aligns to Service & Resource Activator OSS/J Order Management components and eTOM ServiceConfiguration & Activation and Resource Provisioning processes and functions.

Figure 2: Provisioning in the Orchestration Suite

To enable the TIBCO Fulfillment Orchestration Suite to provide a truly unified and cohesive solution suite,different components of the suite have been integrated. For instance, the Suite provides pre-defined

inter-connectivity between Fulfillment Provisioning (FP, formerly KPSA) and Fulfillment OrderManagement/Fulfillment Catalog, catalog concept alignment between Fulfillment Catalog and FulfillmentProvisioning through data synchronization process, and a GUI integration for a similar look-and-feel. SeeTIBCO Fulfillment Order Management Concepts and Architecture for details.

2 Operational/Operations Support System (OSS) Software applications support back-office activities operatinga company network, provision and maintain customer services. OSS is traditionally used by network planners,service designers, operations, architects, support, and engineering teams in the service provider. Softwareapplications that support customer-facing activities. Billing, order management, customer relationshipmanagement, call center automation, are all Business Support Systems (BSS) applications.


20 |


21/142

Part

IIFulfillment Order Management Services

The services are logically divided into the following:

Customer Service

Inventory Service

Offer Service

Product Service

Subscriber Service

You can access these services through SOAP/ HTTP channel, or SOAP/ J MS channel.

Topics

Security Header

Fulfillment Management Services

Order Management Services



22/142

Security Header

Fulfillment Order Management supports both HTTP and JMS as transport protocols for invoking SOAPbased Web services.

AFS supports various Web services, and each Web service request requires the WS-Security UserName

Token mechanism. It uses TIBCO Administrator credentials in a standards-compliant manner. OMS By default, OMS provides a set of user id and password for the operations on OMS through Web

service request. Order services in OMS can be secured by enabling username token-based security. OMSsupports the WS-Security UserName Token mechanism, which allows for the sending and receiving ofuser credentials in a standards-compliant manner. For more details, refer to TIBCO Fulfillment Order

Management Administration Guide.


22 | Fulfillment Order Management Services


23/142

Chapter

2Fulfillment Management Services

Fulfillment Management Services are the set of services, which are related to entities associated with Order. Theseentities can be customer, subscriber, offer, product, or inventory. These services allows you to get informationabout these entities and perform other operations.

The location of all the WebService WSDLs 3 is $AF_HOME/ sc hemas / wsd l .

Topics

Customer Service

Inventory Service Offer Service

Product Service

Subscriber Service

Disabling SOAP_HTTP and SOAP_JMS Services

Customer Service

This service contains operations that retrieve customer information from the order management system.

Get Customer Hierarchy

This operation retrieves the hierarchy for customers, subscribers, and subscribed products. It either retrievesthe 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 limitedsubset of information about each. To get the full snapshot of a customer, invokeGe t Cu s t o me r I ma g e Fo r Cu s t o me r . To view the full snapshot of a subscriber, invokeGe t Cu s t o me r I ma g eF or Su b s c r i b e r . To view the full snapshot of a subscribed product, invokeGe t I n v en t o r y I t e m.

As the customer or subscriber information does not exist in the cache, use the Ge t I n ve nt o r y I t e ms operationto retrieve the subscribed products for customers or subscribers not stored in the cache.

This interface supports the top five levels of customers:

3 WSDL or Web Services Description Language is an XML format for describing network services as a set ofendpoints operating on messages containing either document-oriented or procedure-oriented information.The operations and messages are described abstractly, and then bound to a concrete network protocol andmessage format to define an endpoint. Related concrete endpoints are combined into abstract endpoints(services). WSDL is extensible to allow description of endpoints and their messages regardless of what messageformats or network protocols are used to communicate.



24/142

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 subsidiarycustomers 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

DescriptionElement TypeElement Name

The ID of the customer to retrievethe hierarchy.

String

(Choice, Optional)

CustomerID

The ID of the subscriber to retrievethe hierarchy.

String

(Choice, Optional)

SubscriberID

Flag to indicate if subscriberproducts should also be returned.

Boolean

(Mandatory)

IncludeProducts

If set to true, then all subscriberproducts are returned in the

Default = truehierarchy. If set to false, then noproducts are included.

The reply message format is:


24 |


25/142

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 customersstored in cache.

Table 4: Get Customer Hierarchy Reply Data Model


Data model for ResultStatus is defined

in XSD (refer section Common DataFormat Specifications on page 91).

ResultStatus

(Mandatory)

ResultStatus

CustomerHierarchy/Customer datastructure. Data model for

Customer

(Choice)

Customer

CustomerHierarchy/Customer isdefined in XSD (refer section CommonData Format Specifications on page91). If the Customer was not foundfor the given CustomerID this elementis omitted.

CustomerHierarchy/Subscriber data

structure. Data model for

Subscriber

(Choice)

Subscriber

CustomerHierarchy/Subscriber isdefined in XSD (refer section CommonData Format Specifications on page91). If the Subscriber was not foundfor the given SubscriberID thiselement is omitted.

CustomerHierarchy data structure.Data model for CustomerHierarchy is

CustomerHierarchy

(Choice)

CustomerHierarchy

defined in XSD (refer section CommonData Format Specifications on page91).

Get Customer Image For Customer

This operation retrieves the full snapshot of currently configured customer image for a given customer IDand returns to the calling application.



| 25


26/142

Table 5: Get Customer Image For Customer Request Data Model


The ID of the customer to retrievethe full details.

String

(Mandatory)

CustomerID


Table 6: Get Customer Image For Customer Reply Data Model

ExampleDescriptionElement TypeElement Name

Customer data structure.Data model for Customer is

Customer

(Optional)

Customer

defined in XSD (refersection Common DataFormat Specifications onpage 91). If the customerwas not found for the givenCustomerID this element isomitted.

ResultStatus (Mandatory)ResultStatus

Inventory Service

Inventory Service exposes operations related to inventory in order management. The inventory is associatedwith order and can be at customer or subscriber level.

The operations can be assigning inventory, updating inventory , removing inventory and so on.

Assign Inventory Item

This operation assigns a new inventory item for a specific customer or subscriber.



26 |


27/142

Table 7: Assign Inventory Item Request Data Model


CustomerID: The ID of the customer to assign theinventory.

StringCustomerID/SubscriberID(either one of them isprovided)

SubscriberID: The ID of the subscriber to assignthe inventory.

The ID of the parent customer that the subscriberis assigned.

String

(Optional, Choice)

ParentCustomerID

Product unique identifier.String

(Mandatory)

ProductID

Initial status to assign to the inventory item.String

(Mandatory)

Status

Valid status are:

DRAFT

ACTIVE

WITHDRAWN


| 27


28/142


The planned start date that the product will go toACTIVE status. This may be a provisional start date

DateTime

(Mandatory)

StartDate

at this point and can be updated later usingUpdateInventoryItem operation.

Order typeType

(Mandatory)

Order

Order identifier the product is ordered on.String

(Mandatory)

Order/OrderID

Order line number the product is ordered on.String

(Mandatory)

Order/OrderLineNumber

Order line action the product is ordered with.String

(Mandatory)

Order/OrderLineAction

Order date and time the product is ordered.DateTime(Mandatory)

Order/OrderDate

Comments for this order.String

(Optional)

Order/Comments

Current customer owner of this item. This does notneed to be populated on this operation.

String

(Optional, Choice)

Order/CurrentOwnerCustomerID

Current subscriber owner of this item. This doesnot need to be populated on this operation.

String

(Optional, Choice)

Order/CurrentOwnerSubscriberID

User Defined Field (UDF) typeType

(Optional)

UDFs

User defined fields associated with the productType (*)UDFs/UDF

User defined field name.String

(Mandatory)

UDFs/UDF/Name

User defined field value.String

(Mandatory)

UDFs/UDF/Value



28 |


29/142

Table 8: Assign Inventory Item Reply Data Model


Data model for ResultStatus isdefined in XSD 4 (refer section

ResultStatus

(Mandatory)

ResultStatus

Common Data FormatSpecifications on page 91).

Inventory identifier for the newlycreated inventory item. If the item

String

(Optional)

InventoryID

is not created successfully, this isomitted.

Assign Inventory Items

This operation assigns multiple new inventory items to the given customer or subscriber. This is a bulkoperation version of Assign Inventory Item.


Table 9: Assign Inventory Items Request Data Model


Inventory item to assign.Type (+)Item

4 XML Schema Definition (XSD) is also referred to as XML schema language. It describes the structure of anXML document.


| 29


30/142


CustomerID: The ID of thecustomer to assign the inventory.

String

(Choice)

CustomerID/SubscriberID

SubscriberID: The ID of thesubscriber to assign the inventory.

The ID of the parent customer thatthe subscriber is assigned.String(Optional, Choice)

Item/ParentCustomerID

Product unique identifier.String

(Mandatory)

Item/ProductID

Initial status to assign to theinventory item.

String

(Mandatory)

Item/Status

The valid statuses are:

DRAFT

ACTIVE

WITHDRAWN

The planned start date that theproduct will go to ACTIVE status.

DateTime

(Mandatory)

Item/StartDate

This may be a provisional startdate at this point and can beupdated later usingUpdateInventoryItem operation.

Order typeType

(Mandatory)

Item/Order

Order identifier the product isordered on.String(Mandatory)

Item/Order/OrderID

Order line number the product isordered on.

String

(Mandatory)

Item/Order/OrderLineNumber

Order line action the product isordered with.

String

(Mandatory)

Item/Order/OrderLineAction

Order date and time the productis ordered.

DateTime

(Mandatory)

Item/Order/OrderDate


(Optional)

Item/Order/Comments

Current customer owner of thisitem. This does not need to bepopulated on this operation.

String

(Optional, Choice)

Item/Order/CurrentOwnerCustomerID

Current subscriber owner of thisitem. This does not need to bepopulated on this operation.

String

(Optional, Choice)

Item/Order/CurrentOwnerSubscriberID


30 |


31/142


UDF typeType

(Optional)

Item/UDFs

User defined fields associatedwith the product.

Type (*)Item/UDFs/UDF


(Mandatory)

Item/UDFs/UDF/Name


(Mandatory)

Item/UDFs/UDF/Value


Table 10: Assign Inventory Items Reply Data Model


Data model for ResultStatus isdefined in XSD (refer section

ResultStatus

(Mandatory)

ResultStatus


Inventory item assigned.Type (+)Item


ResultStatus

(Mandatory)

Item/ResultStatus


Inventory identifier for the newlycreated inventory item. If the item

String

(Optional)

Item/InventoryID

is not created successfully, this isomitted.

Get Inventory ItemThis operation retrieves a specific inventory item.



| 31


32/142

Table 11: Get Inventory Item Request Data Model


Inventory ID to retrieve.String

(Mandatory)

InventoryID


Table 12: Get Inventory Item Reply Data Model



ResultStatus

(Mandatory)

ResultStatus


Inventory Item data structure. Datamodel for Inventory Item is defined

InventoryItem

(Optional)

InventoryItem


Get Inventory Items

This operation retrieves the list of inventory items for an input criteria.



32 |


33/142

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 applyingthe filtering criteria, otherwise a large result set may be generated and returned.

The results are sorted by start date in a descending order.

Table 13: Get Inventory Items Request Data Model


Customer ID to retrieve inventoryitems.

String

(Optional, Choice)

CustomerID

Flag to indicate if the call shouldreturn the list of items associated

Boolean

(Optional, Choice)

GetSubscribersItems

with dependent subscribers for thiscustomer.

Subscriber ID to retrieve inventoryitems.

String

(Optional, Choice)

SubscriberID

Product ID to retrieve inventoryitems.

String

(Optional)

ProductID

Product type for inventory items toretrieve. This field supports

String

(Optional)

ProductType

wildcard searches using * or % at


| 33


34/142


the start or end of the string. Thisis a case-insensitive searchparameter.

Product sub-type for inventoryitems to retrieve. This field

String

(Optional)

ProductSubType

supports wildcard searches using* or % at the start or end of thestring. This is a case-insensitivesearch parameter.

Product description for inventoryitems to retrieve. This field

String

(Optional)

ProductDescription

supports wildcard searches using* or % at the start or end of thestring. This is a case-insensitivesearch parameter.

List of item UDFs to retrieve

inventory items.

Type (*)ItemUDF

Name of the UDF to searchString (Mandatory)ItemUDF/Name

Value of the UDF to search. This isa case-insensitive search parameter.

String (Mandatory)ItemUDF/Value

The maximum number of items toreturn. Items are always sorted by

Long

(Optional, Choice)

Count

ascending Status and ProductType.If a large number of items arefound that match the criteria, thenonly items up to the Count arereturned.

Pagination element. Items arealways sorted by ascending Statusand ProductType.

Type

(Optional, Choice)

Pagination

Start record index to return items.This index is inclusive.

Long

(Mandatory)

Pagination/StartRecord

End record index to return items.This index is inclusive.

Long

(Mandatory)

Pagination/EndRecord

Flag to indicate if the operationshould return item information

Boolean

(Optional)

ItemSummary

without UDFs. If this element is setto true, then UDFs are omitted.Otherwise the full item is returned.



34 |


35/142

Table 14: Get Inventory Items Reply Data Model



ResultStatus

(Mandatory)

ResultStatus


List of inventory items. If inventoryitems are not found, this element isomitted.

Type

(Optional)

InventoryItems

Inventory Item data structure. Datamodel for Inventory item is defined

InventoryItem (*)InventoryItems/InventoryItem


Pagination details. This element isincluded only if pagination isincluded in the request.

Type

(Optional)

Pagination

Start record index of returned

items. This index is inclusive.

Long

(Mandatory)


End record index of returned items.This index is inclusive.

Long

(Mandatory)


Total count of item records thatmatched the input criteria. This

Long

(Mandatory)

Pagination/TotalRecords

value is used to composesubsequent pagination calls.

Get User Status

This operation retrieves a list of user status from the inventory for the given input criteria.


The following conditions determine the result set returned by the Get User Status operation:


| 35


36/142

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 thisparticular customer and their status from inventory.

If a single customerID and a list of subscriberIDs are passed in the request, the operation returns the statusfor the subset of subscribers specified by the supplied subscriberIDs for this particular customer frominventory.

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 theirrelationship to the customers passed in the request.

Table 15: Get User Status Request Data Model


Customer ID to retrieve user status.String (*)CustomerID

Subscriber ID to retrieve userstatus.

String (*)

(Optional, Choice)

SubscriberID


Table 16: Get User Status Reply Data Model



ResultStatus

(Mandatory)

ResultStatus


Customer user data structure.Type (*)Customer

Customer ID for user status.String

(Mandatory)

Customer/CustomerID

User status for the customer.String

(Mandatory)

Customer/UserStatus

Subscriber user data structure.Type (*)Subscriber


36 |


37/142


Subscriber ID for user status.String

(Mandatory)

Subscriber/SubscriberID

Parent customer ID for thesubscriber, if one exists.

String

(Optional)

Subscriber/ParentCustomerID

User status for the subscriber.

The valid values are:

String

(Mandatory)

Subscriber/UserStatus

LOCKED

UNLOCKED

Reassign Inventory Item

This operation reassigns an existing assigned inventory item from a customer or subscriber to another customeror subscriber.


Table 17: Reassign Inventory Item Request Data Model


The ID of the inventory item toreassign.

String

(Mandatory)

InventoryID


| 37


38/142


Flag to indicate a rollback snapshotshould be made for the currentupdate.

Boolean

(Optional)

EnableRollback

This flag is not being usedin this release.

The ID of the customer to reassignthe inventory item.

String

(Mandatory, Choice)

CustomerID

The ID of the subscriber to reassignthe inventory item.

String

(Mandatory, Choice)

SubscriberID

The ID of the parent customer thatthe subscriber is reassigned.

String

(Optional, Choice)

ParentCustomerID

Inventory item status to be set.

The valid statuses are:

String

(Optional)

Status

DRAFT

ACTIVE

WITHDRAWN

Order type to add to the orderhistory.

Type

(Optional)

Order

Order identifier the product isordered on.

String

(Mandatory)

Order/OrderID


String

(Mandatory)



String

(Mandatory)


Order date and time the product isordered.

DateTime

(Mandatory)

Order/OrderDate


(Optional)

Order/Comments


String

(Optional, Choice)



String

(Optional, Choice)




38 |


39/142

Table 18: Reassign Inventory Item Reply Data Model


ResultStatusData model forResultStatus is defined in

ResultStatus(Mandatory)

ResultStatus

XSD (refer sectionCommon Data FormatSpecifications on page91).

Reassign Inventory Items

This operation reassigns existing assigned inventory items from a customer or subscriber to another customeror subscriber.


Table 19: Reassign Inventory Items Request Data Model


Inventory item reassigned.Type (+)Item

The ID of the inventory item to bereassigned.

String

(Mandatory)

Item/InventoryID


| 39


40/142


Flag to indicate a rollback snapshotto be made for the current update.

Boolean

(Optional)

Item/EnableRollback

This flag is not being used inthis release.

The ID of the customer to reassignthe inventory item.

String

(Mandatory, Choice)

Item/CustomerID

The ID of the subscriber to reassignthe inventory item.

String

(Mandatory, Choice)

Item/SubscriberID

The ID of the parent customer thatthe subscriber item is reassigned to.

String

(Optional, Choice)

Item/ParentCustomerID

Inventory item status to be set.String

(Optional)

Item/Status

The valid statuses are: DRAFT

ACTIVE

WITHDRAWN


Type

(Optional)

Item/Order


String

(Mandatory)

Item/Order/OrderID

Order line number the product is

ordered on.

String

(Mandatory)



String

(Mandatory)



DateTime

(Mandatory)



(Optional)

Item/Order/Comments

Current customer owner of this item.This does not need to be populatedon this operation.

String

(Optional, Choice)



String

(Optional, Choice)




40 |


41/142

Table 20: Reassign Inventory Items Reply Data Model



ResultStatus

(Mandatory)

ResultStatus


Inventory item reassignedType (+)Item

Data model forResultStatus is defined in

ResultStatus

(Mandatory)

Item/ResultStatus


InventoryId that wasreassigned

String

(Mandatory)

Item/InventoryId

Remove Inventory Item

This operation removes an inventory item from a customer or subscriber.


Table 21: Remove Inventory Item Request Data Model


The ID of the inventory item to beremoved.

String

(Mandatory)

InventoryID



| 41


42/142

Table 22: Remove Inventory Item Reply Data Model



ResultStatus(Mandatory)

ResultStatus


Remove Inventory Items

This operation removes inventory items from a customer or subscriber. This is a bulk interface version ofRemove Inventory Item.


Table 23: Remove Inventory Items Request Data Model


The ID of the inventory item to beremoved.

String (+)InventoryID


Table 24: Remove Inventory Items Reply Data Model



ResultStatus

(Mandatory)

ResultStatus



42 |


43/142


Inventory item removedType (+)Item


ResultStatus

(Mandatory)

Item/ResultStatus


InventoryId that was removed.String

(Mandatory)

Item/InventoryId

Rollback Inventory Item

This operation rolls back the previous update to an inventory item.


Table 25: Rollback Inventory Item Request Data Model


The ID of the inventory item torollback.

String

(Mandatory)

InventoryID


Table 26: Rollback Inventory Item Reply Data Model



ResultStatus

(Mandatory)

ResultStatus


Rollback Inventory Items

This operation rolls back the previous update to inventory items. This is a bulk interface version of RollbackInventory Item.



| 43


44/142

Table 27: Rollback Inventory Items Request Data Model


The ID of the inventory item torollback.

String (+)InventoryID


Table 28: Rollback Inventory Items Reply Data Model



ResultStatus

(Mandatory)

ResultStatus


Inventory item rolled backType (*)Item


ResultStatus

(Mandatory)

Item/ResultStatus


Inventory item ID that was rolledback.

String

(Mandatory)

Item/InventoryID

Set User Status

This operation sets the status of the specified users in the inventory. If the users are not present in the hierarchy,an appropriate error code is returned. All users have the same status as specified in the request.



44 |


45/142

Table 29: Set User Status Request Data Model


Customer ID of the user to set thestatus.

String (*)CustomerID

Subscriber typeType (*)Subscriber

Subscriber ID of the user to set thestatus. This is required for both

String (Mandatory)Subscriber/SubscriberID

non-corporate and corporatesubscribers.

Parent Customer ID of thesubscriber user to set the status.

String

(Optional)

Subscriber/ParentCustomerID

This is required for corporatesubscribers.

The status to assign to the users.The valid values are:

String

(Mandatory)

UserStatus

LOCKED

UNLOCKED


Table 30: Set User Status Reply Data Model



ResultStatus

(Mandatory)

ResultStatus


Update Inventory Item

This operation updates the details of an inventory item. The update operation allows updating the followingparameters. The effect on each parameter is as follows:

DescriptionParameter

Inventory item status is updated to the specified value.Status

Inventory item start date is updated to the specified value.StartDate

Inventory item end date is updated to the specified value.EndDate

Specified order is added to the order history for the inventory item. Existing orderhistory entries are not changed.

Order

The set of UDFs is replaced. The effect of this is:UDF


| 45


46/142

DescriptionParameter

New UDF entries are added.

Changed UDF entries are modified

UDF entries currently present in the inventory item but not in the input UDFlist are removed.

If the UDFs node is present with no UDF elements, all UDFs are removed.


Table 31: Update Inventory Item Request Data Model


The ID of the inventory item toupdate.

String

(Mandatory)

InventoryID

Flag to indicate a rollback snapshotshould be made for the currentupdate.

Boolean(Optional)

EnableRollback

Inventory item status to be set. Thevalid statuses are:

String

(Optional)

Status

DRAFT

ACTIVE

WITHDRAWN


46 |


47/142


The date that the product went toACTIVE status.

DateTime

(Optional)

StartDate

The date that the product went toWITHDRAWN status.

DateTime

(Optional)

EndDate


Type

(Optional)

Order


String

(Mandatory)

Order/OrderID


String

(Mandatory)


Order line action the product is

ordered with.

String

(Mandatory)



DateTime

(Mandatory)

Order/OrderDate


(Optional)

Order/Comments


String

(Optional, Choice)



String(Optional, Choice)


UDF type. Note that if this elementis present with no UDF nodes

Type

(Optional)

UDFs

beneath it, then all UDFs areremoved from the cache.

User defined fields associated withthe product.

Type (*)UDFs/UDF


(Mandatory)

UDFs/UDF/Name


(Mandatory)

UDFs/UDF/Value



| 47


48/142

Table 32: Update Inventory Item Reply Data Model



ResultStatus

(Mandatory)

ResultStatus

XSD (refer sectionCommon Data Format

Specifications on page91).

Update Inventory Items

This operation updates the details of inventory items. This is a bulk interface version of Update InventoryItem. Refer to the Update Inventory Item operation for additional information about update parameters.


Table 33: Update Inventory Items Request Data Model


Inventory item updated.Type (+)Item

The ID of the inventory item toupdate.

String

(Mandatory)

Item/InventoryID

Flag to indicate a rollback snapshotshould be made for the item to update.

Boolean

(Optional)

Item/EnableRollback

Inventory item status to be set.String

(Optional)

Item/Status


48 |


49/142


The valid status are:

DRAFT

ACTIVE

WITHDRAWN

The date that the product went toACTIVE status.

DateTime

(Optional)

Item/StartDate

The date that the product went toWITHDRAWN status.

DateTime

(Optional)

Item/EndDate

Order type to add to the order history.Type

(Optional)

Item/Order

Order identifier the product is orderedon.

String

(Mandatory)

Item/Order/OrderID


String

(Mandatory)



String

(Mandatory)



DateTime

(Mandatory)



(Optional)

Item/Order/Comments

Current customer owner of this item.This does not need to be populated onthis operation.

String

(Optional, Choice)


Current subscriber owner of this item.This does not need to be populated onthis operation.

String

(Optional, Choice)


UDF type. Note that if this element ispresent with no UDF nodes beneath

Type

(Optional)

Item/UDFs

it, then all UDFs are removed from thecache.

User defined fields associated with theproduct.

Type (*)Item/UDFs/UDF


(Mandatory)

Item/UDFs/UDF/Name


(Mandatory)

Item/UDFs/UDF/Value


| 49


50/142

The following tables describes the rules for updating UDFs in the Inventory:

UDF persistedGLB_IgnoreUDF

PersistFlag

PERSIST_VALUE(defined in the

productcharactertistic)

ProductInput

Characteristics

GLB_StoreInpCharUDFsOnly

FALSEFALSE (default)FALSETRUETRUE (default value)

TRUETRUEFALSETRUETRUE (default value)

TRUExTRUETRUETRUE (default value)

TRUExxxFALSE

FALSExxxTRUE

Where:

x : Any value.

1. With the default values of the global variables GLB_StoreInpCharUDFsOnly and

GLB_IgnoreUDFPersistFlag, the UDFs can be persisted only if the PERSIST flag in the product model istrue.

2. To persist the UDFs associated with the inventory, irrespective of the product model, set theGLB_StoreInpCharUDFsOnly to false.


Table 34: Update Inventory Items Reply Data Model



ResultStatus

(Mandatory)

ResultStatus


Inventory item updated.Type (+)Item


ResultStatus

(Mandatory)

Item/ResultStatus



50 |


51/142


Inventory item ID that wasupdated.

String

(Mandatory)

Item/InventoryID

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 isonly for offers saved using the Save Offer function. The submitted orders are not returned.


Table 35: Get Offer Details Request Data Model


The order reference ID. This mustbe an exact match.

String

(Mandatory)

OrderRef

The offer version to retrieve. If thisis omitted, the offer with the

Long

(Optional)

Version

highest version number for theOrderRef is returned.


Table 36: Get Offer Details Reply Data Model



ResultStatus

(Mandatory)

ResultStatus


Order data structure. Datamodel for Order is

Order

(Optional)

Order

defined in XSD (refersection Common Data


| 51


52/142


Format Specifications onpage 91). If the offer is notfound, this element isomitted.

Get Offers

This operation retrieves the offers for the specified criteria and returns to the calling application. This is onlyfor offers saved using the Save Offer function. The submitted orders are not returned.


The request criteria is used to filter the list of offers returned and criteria using the AND operator. The requestcriteria is not required, but it is strongly recommended not to send it in a request without applying the filtercriteria. Otherwise, a large resultset may be returned.

The returned offers are sorted by submission date in a descending order.


52 |


53/142

Table 37: Get Offers Request Data Model


The order reference to retrieveorders. This field supports wildcard

String

(Optional)

OrderRef

searches using * or % at the start orend of the string. This is a

case-insensitive search parameter.

Flag to indicate if the operationshould only return the latest

Boolean

(Choice, Optional)

LatestVersion

version of each offer. If this field isnot present, it is assumed to befalse.

The version number for the offer toretrieve.

Long

(Choice, Optional)

Version

The ID for the customer to retrieveoffers. This field supports wildcard

String

(Optional)

CustomerID

searches using * or % at the start orend of the string. This is acase-insensitive search parameter.

The ID of the subscriber to retrieveoffers. This field supports wildcard

String

(Optional)

SubscriberID

searches using * or % at the start orend of the string. This is acase-insensitive search parameter.

Specifying SubscriberID returns alloffers that include the subscriber,including multiple-subscriberoffers.

Order date range type.Type

(Optional)

DateRange

The earliest order date to returnoffers. This date is inclusive. This

Date

(Optional)

DateRange/StartDate

is based on the Order SubmissionDate on the original offer. OrderSubmission Dates before this dateis excluded.

The latest date to return offers. This

date is inclusive. This is based on

Date

(Optional)

DateRange/EndDate

the Order Submission Date on theoriginal offer. Order SubmissionDates after this date is excluded.

The order status to return offers.This is a case-insensitive searchparameter.

String

(Optional)

OrderStatus

List of order header UDFs to returnoffers.

Type (*)HeaderUDF


| 53


54/142


Name of the UDF to searchString (Mandatory)HeaderUDF/Name


String (Mandatory)HeaderUDF/Value

List of order line UDFs to return

offers. If any order line contains a

Type (*)OrderLineUDF

UDF match then the entire offer isreturned.

Name of the UDF to searchString (Mandatory)OrderLineUDF/Name


String (Mandatory)OrderLineUDF/Value

The maximum number of offers toreturn. Offers are always sorted by

Long

(Optional, Choice)

Count

descending Order Date, Order Ref,and Version. If a large number oforders are found that match other

criteria, then only the orders up tothe Count is returned.

Pagination element. Offers arealways sorted by descending OrderDate, Order Ref, and Version.

Type

(Optional, Choice)

Pagination

Start record index to return offers.This index is inclusive.

Long

(Mandatory)


End record index to return offers.This index is inclusive.

Long

(Mandatory)


Flag to indicate if the operationshould only return order header

Boolean

(Optional)

OrderSummary

information. If this element is setto true, only order headers arereturned. Otherwise the full offeris returned.



54 |


55/142

Table 38: Get Offers Reply Data Model



ResultStatus

(Mandatory)

ResultStatus

XSD (refer sectionCommon Data Format

Specifications on page91).

List of Offers. If no offersare found this element isomitted.

Type

(Optional)

Offers

Order data structure. Datamodel for Order is

Order (*)Offers/Order

defined in XSD (refersection Common DataFormat Specifications onpage 91).

Pagination details. Thiselement is included only

Type

(Optional)

Pagination

if pagination wasincluded in the request.

Start record index ofreturned offers. This indexis inclusive.

Long

(Mandatory)


End record index ofreturned offers. This indexis inclusive.

Long

(Mandatory)


Total count of offerrecords that matched the

Long

(Mandatory)

Pagination/TotalRecords

input criteria. This valueis used to composesubsequent paginationcalls.

Remove Offer

This operation removes the offer details from the offer configuration and validation engine for the givenorder reference and version.

OrderRefmust 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 theAllVersions flag is set to true, then all versions of theoffer are removed.



| 55


56/142

Table 39: Remove Offer Request Data Model


The order reference ID.String

(Mandatory)

OrderRef

The specific version to be removed.Long

(Optional)

Version

Flag to indicate that all versions ofthe offer should be removed.

Boolean

(Optional)

AllVersions


Table 40: Remove Offer Reply Data Model



ResultStatus

(Mandatory)

ResultStatus


Save Offer

This operation accepts an offer and stores it in the offer configuration and validation engine for retrieval. Donot specify the OrderID in the input Order document as it is ignored. IfOrderRefis not specified, a value isgenerated and returned to the calling application. If the offer could not be saved, the OrderRefis not returned.The order is not validated.

IfOrderRefis specified and an offer already exists in the cache, that offer is updated and version number isincreased to the next higher version. Otherwise, a new offer is created in the cache.



56 |


57/142

Table 41: Save Offer Request Data Model


Order data structure. Data modelfor Order is defined in XSD (refer

Order

(Mandatory)

Order

section Common Data FormatSpecifications on page 91).


Table 42: Save Offer Reply Data Model



ResultStatus

(Mandatory)

ResultStatus


Order reference number. If the offercould not be saved then thiselement is omitted.

String

(Optional)

OrderRef

Version of the saved offer. If theoffer could not be saved then thiselement is omitted.

Long

(Optional)

Version

Validate Offer

This operation accepts an offer for validation and returns either a pass or fail. If the validation fails, a list oferror messages are returned.

Validation takes the form of rules configured in the offer configuration and validation engine. These rulesevaluate 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 enoughto 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:

Validation Pass = trueNo Messages

Validation Pass = trueWarnings Only

Validation Pass = falseWarnings and Errors

Errors Only



| 57


58/142

Table 43: Validate Offer Request Data Model


Order data structure. Data modelfor Order is defined in XSD (refer

Order(Mandatory)

Order

section Common Data FormatSpecifications on page 91).


Table 44: Validate Offer Reply Data Model



ResultStatus

(Mandatory)

ResultStatus


Returns true for a valid order, orfalse for an invalid order. This

Boolean

(Mandatory)

ValidationPass

returns false if there are any errormessages returned. If warningmessages are returned or nomessages are returned, this returnstrue.

Validation messages for the order.

The validation service validates all

Type (*)Message

elements in the order and returnsmultiple validation messages.

Line number in the order that thevalidation message relates to. If this

String

(Optional)

Message/LineNumber

is omitted then the message isgeneral for the entire order.


58 |


59/142


Validation message type. The validvalues are:

String

(Mandatory)

Message/Type

WARNING

ERROR

Unique validation message code.String

(Mandatory)

Message/Code

Validation message description andpossibly remedial action required.

String

(Mandatory)

Message/Description

Get Offer Price

This public interface is provided by Offering Management to allow pricing of a particular Offer based on theconfiguration in the Product Catalog.


Figure 7: Get Offer Price Request

DescriptionCardinalityTypeField

Unique identifier for the Offer to price.MandatoryStringOrderRef

Version of the Offer to price. If this is omitted then thelatest version is priced.

OptionalLongVersion

Order data structure. Data model for Order is definedin XSD (refer Order (Optional) Order section Common

Data Format Specifications).

MandatoryOrderOrder

Transaction ID.OptionalStringBusinessTransactionID



| 59


60/142

Figure 8: Get Offer Price Reply

DescriptionCardinalityTypeField

OptionalStringBusinessTransactionID

MandatoryLongResultStatus

OptionalOrderLineOrderLines

OptionalTotal PriceTotalPrice

OptionalOverall PriceOverallPrice

Product prices are stored in the Product Catalog, and assigned to individual Products. When applied to anOffer, 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 pricefor the Offer is computed by summing the individual order line prices.

Various price entities and types are supported:

DescriptionEntity

A price that is charged to a Customer-level entityCustomer Price

A price that is charged to a Subscriber-level entitySubscriber Price

DescriptionPrice Type

A price that is charged only onceOne Time Price

A price that is charged multiple times over a defined term with a given periodicfrequency. For example, Monthly, Daily, Yearly, etc.

Recurring Price

Price types and price entities combine together to create the following pricing matrix:

Price Entities

SubscriberCustomer

Yes - Single Yes - SingleOne Time PricePrice Types

Yes - MultipleYes - MultipleRecurring Price


60 |


61/142

In addition to the catalog prices, the pricing rules support the following order line price types that apply onlyto One Time prices:

DescriptionOrder Line Price Type

A price that is added to the one-time price for the given order lineSupplement Price

A price that is used instead of the one-time price for the given order lineOverride Price

Computing the order line catalog price is based on the pricing matrix and the following rules:

ComputationPrice Matrix Node

Sum of all prices for the order line Product ID where:Customer One Time Price

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:Subscriber One Time Price

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:Customer Recurring Price 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:Subscriber Recurring Price

Price Type is Recurring

Order has a SubscriberID or Order Line has a SubscriberID

The recurring prices are always grouped by Price Period. This is required so that only prices of thesame price period are summed together. Therefore only Monthly Price Period prices are summedwith 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. Pricebands 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 Bandsegment to a product that Price Entity has ordered. If multiple products for that Price Entity haveCompatibleSegment Price Band relationships then only the first one found is used. This price band is thenused to choose the correct price for other products for that Price Entity on the offer that are configured usingprice bands.

Price banded products have multiple prices associated with it, but not all prices are used. Each product hasa ProductPricedBy relationship to the price. Each price in turn has a PriceRequiresSegment relationship tothe relevant Price Band segment. There may also be a default price band associated with the product thatdoes 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 th

Tib Af Webservices(1)

Documents

Transcript of Tib Af Webservices(1)