tib af concept

8/3/2019 Tib Af Concept

1/60


2/60


3/60

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-ONFUNCTIONALITY) 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 confdential 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 identifcation purposes only.

This software may be available on multiple operating systems. However, not all operating system platforms for a specifc

software version are released at the same time. Please see the readme.txt fle for the availability of this software version on a

specifc 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-2011 TIBCO Software Inc. ALL RIGHTS RESERVED.TIBCO Software Inc. Confdential Information

TIBCO ActiveFulfllment Concepts and Architecture


4/60


5/60

Contents

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

Related Documentation............................................................................................................8

Typographical Conventions......................................................................................................9

Connecting with TIBCO Resources........................................................................................10

Chapter 1 Introduction....................................................................11

About TIBCOActiveFulfillment.............................................................................................12

Architecture Overview............................................................................................................13

Order Manager GUI.....................................................................................................14

Order Manager Server.................................................................................................15

Orchestrator.................................................................................................................15

Router..........................................................................................................................16

Transient Data Store....................................................................................................16

Key Functionality....................................................................................................................17

Included Products...................................................................................................................18

TIBCO BusinessEvents (BE).......................................................................................18

TIBCO BusinessWorks (BW).......................................................................................18

TIBCO Enterprise Message Service (EMS)................................................................18

Chapter 2 Definitions and Concepts..............................................19Characteristics........................................................................................................................20Order Header.........................................................................................................................21

Order Line..............................................................................................................................22

Order Submission...................................................................................................................23

Synchronous Order Submission..................................................................................23

Execution Plan.......................................................................................................................24

Plan Tasks with Associated Process Components......................................................24

Actions.........................................................................................................................24

Dependencies..............................................................................................................24

Plan Fragment........................................................................................................................25

Plan, Plan Item and User Defined Field.................................................................................26

Time Dependency..................................................................................................................27

Cease (Rollback) and Update................................................................................................28

Cancellation............................................................................................................................29

Chapter 3 Fulfillment Process.......................................................31

Overview................................................................................................................................32


TOC | 5


6/60

Plan Development Process....................................................................................................33

Orchestration..........................................................................................................................35

Chapter 4 Automated Order Plan Development............................37

Automated Plan Development - Basic Concepts....................................................................38

Autoprovision..........................................................................................................................39Dynamic Bundles.........................................................................................................39

Static Bundles..............................................................................................................39

Product Specification Field Decomposition............................................................................40

Delta Provisioning..................................................................................................................41

Single Use...................................................................................................................41

Sequencing............................................................................................................................42

Product Affinity (Plan Item Level)...........................................................................................46

Inlink............................................................................................................................46

Crosslink......................................................................................................................46

Affinity Sequencing......................................................................................................48

Dependent and Sibling Products............................................................................................51

Shared Attributes....................................................................................................................53

Intermediate Milestones Dependencies.................................................................................54

Milestone to START Dependency................................................................................54

END to Milestone Dependency ..................................................................................54

Milestone to Milestone Dependency............................................................................55

Milestone without Dependency....................................................................................55

Understanding Orders............................................................................................................56

Order Amendment.......................................................................................................56


6 | TOC


7/60

Preface

The preface contains information about documentation related to the current document, typographical conventions, and

information on how to contact TIBCO support.



8/60

Related Documentation

This section lists documentation resources you may fnd useful.

TIBCO ActiveFulfillment Installation and Configuration Read this manual for instructions on

installation, and confguration.

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 This manual describes the features and functionality as well as all

the screens.

TIBCO ActiveFulfillment Concepts and Architecture This manual describes terminology and concepts

of TIBCO ActiveFulfllment.


8 | Preface


9/60

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 is referenced

in documentation as TIBCO_HOME. The value ofTIBCO_HOMEdepends on the operating system.

For example, on Unix systems the default value is $HOME/tibco.

TIBCO_HOME

TRA_HOME

AF_HOMETIBCO Runtime Agent installs into a directory inside ENV_HOME. This directory is referenced

in documentation as TRA_HOME. The value ofTRA_HOMEdepends on the operating system. For

example, on Unix systems the default value is $TIBCO_HOME/tra.

TIBCO ActiveFulfllment installs into a directory inside ENV_HOME. This directory is referenced

in documentation as AF_HOME. The value ofAF_HOMEdepends on the operating system. For

example, on Unix systems the default value is $TIBCO_HOME/af/1.2.

Code font identifes commands, code examples, flenames, pathnames, and output displayed in

a command window. For example:

code font

Use MyCommand to start the foo process.

Bold code font is used in the following ways:bold code font

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 specifed, MyCommand is enabled:

MyCommand [enable | disable]

Italic font is used in the following ways:italic font

To indicate a document title. For example: See TIBCO 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:

MyCommandpathname

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 informationprovided in the current section to achieve a specifc result.

The warning icon indicates the potential for a damaging situation, for example, data loss or

corruption if certain steps are taken or not taken.


Preface | 9


10/60

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.


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


11/60

Chapter

1Introduction

This chapter gives an overview of TIBCO ActiveFulfllment and its infrastructure software.

Topics

About TIBCOActiveFulfillment

Architecture Overview

Key Functionality

Included Products



12/60

About TIBCO

ActiveFulfillment

TIBCO

ActiveFulfllment is a meta data driven order management and fulfllment system which allows development

of fulfllment plans based on meta-data specifed in product catalogs. Order fulfllment and service provisioning is no

longer a simple single-service or product workow. The dynamic bundled offerings along with the explosion of devices,

applications, real time inventory management and third-party content providers requires a complex order fulfllmentsystem 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 ActiveFulfllment.

TIBCO ActiveFulfllment is a comprehensive software solution to design, deploy and maintain high-performance scalable

enterprise level business processes for advanced and dynamic order fulfllment. TIBCO ActiveFulfllment enables

companies to quickly introduce new product offerings and in most cases requiring little or no change to fulfllment

processes. The product bundles are decomposed into existing products to automatically generate a plan specifc to the

order.

TIBCO ActiveFulfllment also enables companies to effciently manage changes to the existing business process to meet

rapidly changing business environment.

Product model can be def

ned following SID 9 guidelines using TIBCO ActiveCatalog or any other catalog managementsystem and imported into ActiveFulfllment.


12 | Introduction


13/60

Architecture Overview

The major components of the TIBCO ActiveFulfllment 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 Confguration 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 ActiveFulfllment to determine the validity

of a customer's "shopping cart". OCV provides both validation and confguration 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 workow process is then generated based

on those basic building blocks to ensure that the order is fulflled accurately and as effciently as possible. Optimization

can take into account both product rules, as well as customer inventory and other data to arrive at the fnal order

plan.

Order Manager Server - exposes SOAP Web services to ActiveFulfllment.

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 totake place in a variety of back-end systems (for instance, billing system(s), network systems, scheduling systems).

ActiveFulfllment Orchestrators keeps track of status and manages exceptions.

Router - Orders from OMS may optionally be routed to an alternate Orchestration engine. In this case,

ActiveFulfllment's Router can read inbound orders and, based on rules, may route to an external orchestration engine.

Common Logging - All ActiveFulfllment'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 ActiveFulfllment is shown below.


Introduction | 13


14/60

Figure 1: Architecture

Order Manager GUI

Order Manager GUIor is an application that provides you visual interface to view order details and order execution

plans, search orders, orders that were fulflled or failed during the fulflment process, and facilitates end-to-end tracking,

storing and monitoring capability for orders that are part of the order fulf

lment system. OMS also equips you with thecapability to perform actions on the orders being executed in the system. For details, see TIBCOActiveFulfllment

User's Guide.

The following actions can be performed using OMS:

DescriptionOMS Actions

Viewing Dashboard: You can view the OMS Dashboard for summarized

information under the following sections:

Dashboard-specifc actions

Order Summary

Orders in Execution

Backlog Orders

Amended Orders

OMS allows you to do the following order-specifc actions:Order-specifc actions

View orders

Search orders

Edit orders

Save orders

View order execution plan

View plan progress


14 | Introduction


15/60

DescriptionOMS Actions

You can perform the following plan-specifc actions in the OMS.Plan-specifc actions

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 ActiveFulfllment to accept predefned request.

OMS hosts the following Web services:

Submit Order

Amend Order

Cancel Order

Get Order Details

Get Orders

Get Order Execution Plan

Orchestrator

Orchestratorexecutes a series of tasks in a defned 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 fulfllment.

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 fulfll the order. Orchestrator then uses this plan to reach the goal by invoking the process

component associated with each plan item in the defned sequence to fulfll an order. For details, see TIBCO

ActiveFulfllment Administration Guide.

The following diagram shows the relationship between different objects:

Figure 2: Object Relationship


Introduction | 15


16/60

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

specifed 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 aboutwhere an order should be routed for fulfllment, content-based routing provides a high degree ofexibility to confgure

multiple type of Orchestration engine. For details, see TIBCOActiveFulfllment Administration Guide.

Transient Data Store

Transient Data Store is a BE engine designed for storing the intermittent data during the order life cycle. ActiveFulfllment

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 TIBCOActiveFulfllment Administration Guide.


16 | Introduction


17/60

Key Functionality

ActiveFulfllment provides the following functionalities:

ActiveFulfllment Confgurator Graphical User Interface (GUI) - confgures the various settings for

ActiveFulfllment using GUI mode.

Attribute-based Decomposition - flters execution plan depending on the orderline attributes of the products ordered.

Affnity - allows different plan fragment types to be grouped together on the same order.

Order Amendments - Order Amendment now handled via new Order Management Server and ActiveFulfllment

Orchestration engine.

Ofine Catalog - enables the ActiveFulfllment application to fulfll the orders and reduces the dependency on the

ActiveCatalog to be Online.

Centralized Logging - provides the logging and reporting capability for analyzing the data and generate meaningful

reports.

Inventory Integration - services the inventory related requests. This feature is implemented in ActiveFulfllment

Service to service the inventory related details.

Dependent and Sibling Product - enables grouping products on requests thereby allowing for sibling products andtheir children products to be sent to a dependent product. The ability is built in the Product Model to indicate that a

product is dependent on its peer or peers hierarchy.

Shared Attributes - used when two Products (parent to child and sibling) share the same attribute and its corresponding

value, and an update in the value of one needs to be reected in the other.


Introduction | 17


18/60

Included Products

TIBCO ActiveFulfllment is architected using generally available products supplied by TIBCO. ActiveFulfllment

bundles the below software together for exclusive use with ActiveFulfllment. See licensing terms for more details.

TIBCO BusinessEvents (BE)

OCV, AOPD and Orchestrator components are designed using Business Events Engine.

BE is a powerful, high performance complex event processing engine. It can be scaled via it's built in shared memory

layer allowing state to be distributed across multiple machines. This allows events to be stored in the shared memory

layer, which can then be accessed by multiple engines, each one taking the next available event for processing.

TIBCO BusinessWorks (BW)

TIBCO BW provides the SOA framework for the offering. BW is a distributed ESB that allows for parallelism to be

achieved via standard distributed service bus techniques. It provides an integration framework that allows services to

be created and hosted. BW supports a variety of transports and data formats. It can also map between different formats

to provide support for bespoke data formats that may already exist in the different operators.

TIBCO Enterprise Message Service (EMS)

TIBCO EMS provided the messaging backbone for the system. It provides a reliable and persistent messaging to distribute

the load, decouple components and to support high available and fault tolerance.


18 | Introduction


19/60

Chapter

2Definitions and Concepts

This chapter provides an overview of the basic defnitions and concepts of TIBCO ActiveFulfllment and order plan development.

Topics

Characteristics

Order Header

Order Line

Order Submission

Execution Plan Plan Fragment

Plan, Plan Item and User Defined Field

Time Dependency

Cease (Rollback) and Update

Cancellation



20/60

Characteristics

Characteristics may be of the following common pre-defned types:

FeatureA distinct feature or capability of a product. In general, features distinguish a product from other products

of the same class. For example features of a mobile device might include: SMS, Voice, MMS, 4G, Stereo Wireless

Headset, Keyboard, etc. Features could also be chargeable or non-chargeable, e.g. For billing purposes a device thatprovides SMS capability could mean it may need a SMS capable billing plan.

Instance Instance characteristics are similar to Features, the feature in question has measurable quantity that is

defned for each related product. An example would be a discrete Free 500 SMS Package product could have an

Instance characteristic called Free SMS. This characteristic would have a relationship value = 500. Another

similar product could be created called Free 1000 SMS Package. It would have the same Free SMS characteristic

associated with it but have a relationship value = 1000.

Input These characteristics represent information values that need to be captured and associated with the product

at time of order/order fulfllment. they generally represent information that needs to be propagated to other systems

OR will impact the fulfllment process. Input characterstics generally have no values until the order is placed/fulflled.

An example of an Input characteristic could be an MSISDN (phone number) allocated to a mobile device, or a

Contact Address captured for a business internet product at time of order.

Shared - Indicates that the attribute is shared.


20 | Defnitions and Concepts


21/60

Order Header

The table below lists the information contained in an order header:

DescriptionType

A unique identifer supplied by the system that submits the order. The Order Reference

is used to determine whether the order is a new request or an amendment. OMS does

Order Ref ID

this by checking if an order with the same Order Reference is already stored in the

database. If the order already exists, the order is an amendment. If there is not, then it

is a new order request.

If the orderRefId is not supplied by external system , then ActiveFulfllment generates

the reference ID and sends in response.

ID of an order.Order ID

Current status of an order. For instance, COMPLETE.Status

Execution Plan ID.Execution Plan

Indicates the date and time when the order must start fulfllment.Required By Date

Notes about the order. Basically this is any additional text that may be supplied by the

summiteer or submitting system.

Notes

Reference ID of the subscriber.Subscriber ID

Used to retrieve the current customer profle and to identify the customer to other

systems interested in the order.

Customer ID

Date when the order is changed.Changed Date

Execution status of an order. For instance, COMPLETE.Execution Status

Currently not supported.Required On Date

The address to invoice for the order, if different from the customer address.Invoice Address

The address to deliver the order, if different from the customer address.Delivery Address

This is a list of the identifers of any service level agreement that applies to a particular

order.

Service Level Agreements

(SLA)


Defnitions and Concepts | 21


22/60

Order Line

An Order contains order lines. Each order line has the following information:

DescriptionType

Line no. of an order.Line No

The identifer of the specifcation of the product to be provided.Product ID

Inventory ID.Inventory ID

The action required for the specifc product referred to in the order line. You can enter

one of the following actions:

Action

Provide: The customer has requested a new service.

Cease: The customer has requested that an existing service should cease.

Update: The customer has requested that an existing service be updated in some

way.

Cancel: the customer has cancelled the requested product.

Indicates the date and time when the order line must start fulfllment.Required By Date

The number of the product required.Quantity

Currently not supported.Required On Date

Reference ID of the subscriber.Subscriber ID

Version of a particular product.Product Version

Link reference ID.Link ID

The current status of the order. This is automatically flled in and you cannot amend

it. The status changes with the order items lifecycle.

Status

The date and time that the order line status last changed. This is automatically flled

in and you cannot amend it. It initially shows the date and time the order line was

created, and is updated to reect later status changes.

Status Changed

The unit of measure of the product required.UOM (Unit of Measurement)

The address to deliver the order, if different from the customer address.Delivery Address

A list of product characteristics that are supplied as input parameters to the order to

provide additional information to the product specifcation. For instance, this may be

the color of a mobile telephone.

Characteristics




23/60

Order Submission

A customer order is received from an external order capture or request injection system, for example a CRM system or

a Business-to-Business (B2B) gateway, and Web services. The order must be in the XML format, must conform to the

order schema, and is received via a Java Message Service (JMS) message.

Synchronous Order Submission

This feature allows you to synchronously submit the order and receive response on completion of order fulfllment. This

feature is useful when order fulfllment is a short-running process.

The basic function of synchronous submit order web service is to accept a new order request, and returns back the

response to the calling application after the order has been completed through Orchestrator. The order is stored in OMS

and then sent to orchestrator, which on completion (or failure) of order responds back. This response is then shown to

the calling application. This is different from the Submit Order Service, which accepts the new order request, stores the

order in OMS, sends the order to orchestrator, and returns the response back to the calling application with the order

status as submittedwithout waiting for Orchestrator to respond back.




24/60

Execution Plan

Execution Plan is a process model which is developed for a concrete order and can also be termed as a collection of the

activities that need to be completed to fulfll a customer order. Execution plans usually specify how the process components

should be arranged to fulfll the order.

An execution plan consists of the following:

Plan Tasks with Associated Process Components

Actions

Dependencies

Plan Tasks with Associated Process Components

Each plan task is associated with a process component. When you create an execution plan, you add the plan tasks that

are required to fulfll the customer order by selecting from the available process components confgured in the system.

You can also group plan tasks into groups. This allows exibility in creating the execution plan. For example, you can

create dependencies on groups of tasks that all must be completed before the next task is started.

Actions

Each plan task has an action associated with it. These are the possible actions you can select for each plan task:

Provide

Cease

Update

Cancel

A plan task manages a particular item. Each action defnes what needs to be done for a particular item. An action serves

as an annotation to make the execution plan more understandable.

DependenciesWhen adding your plan tasks, you need to add any dependencies that exist between the plan tasks. Dependencies are

set up between milestones in a task.

Dependency can be defned as a relationship between milestones in an execution plan. For example, Milestone B cannot

start until Milestone A completes.

For details, see Intermediate Milestones Dependencies on page 54.




25/60

Plan Fragment

A Plan Fragmentcan be termed as an abstraction of a process component containing confguration information.

Orchestrator requires this confguration information in order to handle errors and Service Level Agreement (SLA)

notifcations.

Plan fragments are optional. If no plan fragment is defned for a particular process component, then Orchestrator uses

engine defaults to handle errors and no SLA notifcations occurs.

Plan Fragments can be versioned to deploy multiple versions of a process component simultaneously. The following

diagram shows the relationship between plan fragments, versions, and process components.

Figure 3: Plan Fragment and Process Component Logical Components

Plan fragment PC_1 depicts process component PC_1. This process component can be invoked by a plan item using

different versions. Therefore plan fragment PC_1 has Version 1, which maps the process component of the same version.

The base plan fragment always defnes the currently active process component version.




26/60

Plan, Plan Item and User Defined Field

Aplan is the task to be completed to fulfll an order. The plan defnes how to go about reaching the required goal as a

series of tasks, or plan items.

Plan Item is a set of task that must be performed to fulfl an order. A plan consists of plan items, like an order consists

of order lines.

Order lines can map onto plan items, but this is not necessary. One order line may require multiple plan items to be

fulflled, and in a similar manner, multiple order lines may be fulflled by a single plan item. An order line not requiring

the completion of any physical tasks is classifed as non-executing, and does not require a plan item.

User Defned Field, or UDFis a list of name value pairs that you can supply as additional input parameters to the order.




27/60

Time Dependency

The decomposition component has the ability to provision an execution plan for a given order based upon the time

constraints, if any, placed on the products within that order e.g. it determines when a particular product execution should

be started. This time constraint could apply to an individual plan item within an execution plan or to the entire execution

plan. Time dependency will be added in each plan item if the requiredByDate specifed in order is in future.




28/60

Cease (Rollback) and Update

If an ordered product is no longer required it is stopped/ceased and the order plan is returned to the previous state (to

the state before the particular product was ordered).

The AOPD component removes all the products, along with any sub-products from the customer's installed base and

furthermore, the execution plan is updated to remove the surplus execution plan fragments as well as any dependencies.

This can only be done under the assumption that the order execution is in the complete phase.

The order can be updated using the OMS Graphical User Interface, or order API. The order update can be adding,

removing or modifying the order line and date shift. For details, see Understanding Orders on page 56.




29/60

Cancellation

The cancellation of an order line results in the cancel action being performed.

You cannot cancel an order line that is in its complete order phase.

Cancellations for order lines with items in the completion phase are handled manually by adding new process componentsto reverse the completed items.




30/60


31/60

Chapter

3Fulfillment Process

Topics

Overview

Plan Development Process

Orchestration



32/60

Overview

In TIBCO ActiveFulfllment context, an order and the corresponding execution plan respectively represent the following:

What (goal) to fulfll/achieve, and

How to fulfll/achieve that particular goal.

Automated Order Plan Development (AOPD) is the core component of TIBCO ActiveFulfllment, which transforms

the Whatpart, i.e. Order intoHow - the execution plan.

Various products and services that are to be fulflled are modeled in the Product Catalogue in the form of either ofine

fles or in TIBCO ActiveCatalog. Modeling of the products involves, but not limited to the following.

Creating the product bundles comprising of other products and services.

Assigning the specifc plan fragments to the individual products against a specifc fulfllment action, such as PROVIDE,

CANCEL, CEASE, and UPDATE.

Specifying other characteristics for the products to support the features, such as Affnity, SingleUse, Attribute Based

Decomposition, etc.

The actual fulfllment of the product happens by invoking the process component - typically implemented as KPSA

cartridges or BPM workow processes - described by the plan fragment assigned to the product in the Product Catalogue.

The invocation of the process components in a specifc sequence and at specifc time is known as the order orchestration,

which is done by the Orchestrator component of TIBCO ActiveFulfllment.


32 | Fulfllment Process


33/60

Plan Development Process

An incoming order to TIBCO ActiveFulfllment consists of one to many order lines, with each line requesting a Telecom

product or service to be fulflled. ActiveFulfllment Orchestrator sends the order received from the Order Management

Server component to AOPD for the execution plan generation. AOPD component has the active reference of the product

and the customer catalogue.

AOPD generates the execution plan by applying various rules on the incoming order against the product, customer

catalogues and the optional inventory for the customer coming along with the order in execution plan generation request.

See fgure Figure 4: Plan Generation by AOPD Inputs and Outputs on page 33

1. Plan development performance is related to the size of the catalogue and order being decomposed. Where

possible, the size of both should be reduced to improve performance.

2. Plan Fragments should not be modeled that do not do anything at execution time. Only plan items that do

useful work should go into the plan.

3. Milestones and overlapping sequencing should be used instead of empty plan items for dependencies.

For a product requested in an order line, AOPD creates a plan item and assigns the plan fragment corresponding to the

action specifed in the order line from the Product Catalogue. All such plan items are added into the execution plan. The

plan is further optimized by applying rules for features such as Affnity, Single Use, and so on. On completion, the

generated execution plan is sent back to the ActiveFulfllment Orchestrator for the order orchestration process.

Figure 4: Plan Generation by AOPD Inputs and Outputs

The typical order fulfllment ow in TIBCO ActiveFulfllment is represented by the following sequence diagram:


Fulfllment Process | 33


34/60

Figure 5: Plan Generation and Execution Sequence




35/60

Orchestration

ActiveFulfllment Orchestrator receives AOPD-generated execution plan for order orchestration. It has one to many

inter-dependent plan items, which typically maps to the order lines in the order. See fgure Figure 6: Order and Execution

Plan on page 35.

Figure 6: Order and Execution Plan

There can be one-to-one, one-to-many, or many-to-one relationships between the order lines and the plan items based

on the Product Catalogue modeling.

In case of Affnity between two products, the two order lines requesting these two products have a single plan item

in the execution plan, to fulfll the product products simultaneously.

In case of a bundled product comprising of sub-products and services, the order line requesting this product have

multiple plan items in the execution plan, one corresponding to each sub-product or service.

A plan item contains the process component which has to be invoked for the fulfllment of a particular product. AF

Orchestrator invokes the process components and starts executing the plan contained in the plan items according to thedependencies between them. The execution plan, and hence the order is considered to be COMPLETE or FULFILLED

once all the process components corresponding to the plan items are executed successfully.

The high level relationships between the order and plan entities are shown in the following fgure:

Figure 7: Order, Plan, Plan Fragment and Process Component


Fulfllment Process | 35


36/60

Plan item, Plan fragment, and Process Component are inter-related concepts.

Here is the brief description of each of these concepts:

Plan Item is one of the steps in a plan that must be executed to reach the goal of fulflling an order line, and eventually

the order. The plan item is confgured with the name of the Process Component, which must be invoked to fulfl a

product. The name of the Process Component is provided by ActiveFulfllment AOPD during plan development,

and gathered from the Product Catalogue using the name of the product.

Plan Fragmentis the model defnition of a Process Component, which fulflls a particular product. Products are

linked to plan fragments in the Product Catalogue. The name of a plan fragment is the same as the name of the

Process Component that it describes.

Process Componentis the physical implementation of the tasks required to fulfll a product. It is described by a plan

fragment and invoked as a plan item step in a plan.




37/60

Chapter

4Automated Order Plan Development

Topics

Automated Plan Development - Basic Concepts

Autoprovision

Product Specification Field Decomposition

Delta Provisioning

Sequencing

Product Affinity (Plan Item Level) Dependent and Sibling Products

Shared Attributes

Intermediate Milestones Dependencies

Understanding Orders



38/60

Automated Plan Development - Basic Concepts

BasicAutomated Order Plan Developmentis the capability to create custom order plans that fulfll an order, taking into

account the specifcations of the required products and the products currently provided to a customer.

A Product Model contains Bundles and Products Services. A Product model also contains concepts such as sequencing

and dependencies.

When an order is received, order lines are decomposed using a Product model. The product specifcation for each order

line is extracted from a product catalog by the decomposition component.

The product specifcation is required to create execution plan fragments. These execution plan fragments defne services,

products, and resources required. For example, an order line may contain a bundle, which may be comprised of several

products and services. Taking into consideration factors such as sequencing and dependencies, these execution plan

fragments are then combined to create a single execution plan.


38 | Automated Order Plan Development


39/60

Autoprovision

Autoprovision is a condition that determines the relationship between a parent product and a child product. The relationship

can be either be Static orDynamic. Autoprovision ag determines whether the product is mandatory or not. For instance,

consider a product A having a child product B, which has AutoProvision set as TRUE.

Static: If Autoprovision is set to TRUE, then the product is considered to be a static bundle and the child is automatically

be assumed to be a part of the order. This indicates that the child product is implicitly assumed to be on the order no

matter there is an order line with that product.

Example: Consider bundle B comprised of products P1 and P2.

AUTOPROVISION ag is TRUE between B and P1.

AUTOPROVISION ag is FALSE between B and P2.

When bundle B is ordered, P1 will be provisioned automatically though it is not in the order line.

This process of order fulfllment is known asImplicit Fulfllment.

Dynamic: Auto Provision is set to FALSE. This indicates that the child product must be explicitly included in the order.

The product diagram shows the mandatory products with solid lines (Autoprovision TRUE, Static bundle) and are

included in the order automatically. Otherwise, the products need to be ordered separately, which is a Dynamic bundle

feature.

The instanceOptional feld is not used during plan generation in AOPD.

Dynamic Bundles

Dynamic Bundles allows for a bundle to be modeled using a product hierarchy in a product catalogue and items are

selected by the user and then submitted for order plan development. An example would be where a bundle is modeled

to have mandatory items and optional items and the customer needs to select the options.

The optional products are specifed as specifc order lines within the order. The bundle is also specifed as an orderline

but the decomposition component recognizes the options belonging to the parent bundle.

The mandatory products are automatically added for order planning.

Any requiredproducts will be validated as part of validation to ensure the basket or the customer image has the required

product before any decomposition occurs.

Static Bundles

This allows for a bundle to be modeled using a product hierarchy in the catalogue, with the bundle only containing

mandatory options. An example of this would be a bundle with mandatory products and when a customer orders this

bundle all the dependent products are provisioned without the customer needing to selecting any more products.


Automated Order Plan Development | 39


40/60

Product Specification Field Decomposition

Each product has a modeled set of characteristics within a product catalogue. When a product is decomposed to a plan

item, the default and the instance characteristics are copied over into the User Defned Fields (UDFs) of every plan item.

This allows the information to be reused later when the plan item is executed.

For example, consider a product "Line Access 5MB" has characteristics modeled such as Speed=5, QOS=4,

IPAccess=false. These are all modeled as instance variables. When an order is submitted for Line Access or is part of

a bundle, the plan item uses the same instance characteristics copied as UDFs into the plan item. When the plan item is

executed, the UDFs can be passed to the service call.

When an order, is made the characteristics are visible as UDFs for each order line. When you submit the order, the UDFs

are converted into UDFs for the new plan items and if the order line is a bundle then those items can have UDFs as well

which are copied to the execution plan. All theses UDFs can be used later through the service call.




41/60

Delta Provisioning

Delta Provisioning ensures that products which have been defned for 'single use' are not provisioned more than once

for a given order. The combination of the order line action of the products is used to determine how the products are

provisioned.

Single Use

Single Use ensures that if the products have same product ID and have been defned for single use with the order line

actions as PROVIDE then those products are not provisioned more than once. It deletes one of the instances and ensures

that the dependencies point to the single instance, which still remains in the plan. This is done for products with the

same parent only.

Product Model description in relation to the Single Use:

The Product Model diagram shows the Single Use feature. If the Order is a 'BUNDLE in a single Order line', the UserID

is generated only once, although it has been ordered twice by the products Broadband and VOIP respectively.

If the product exists more than once on the order, then it is only included once in the fnal plan. If the product exists on

the order and in the inventory, it is not included in the plan.Cease Single Use

This functionality ensures that if the products have same product ID and have been defned for single use with their

order line actions as PROVIDE and CEASE then those products are not provisioned more than once. It deletes instance

which has its order line action as CEASE, mark the action as UPDATE and also ensure that the dependencies point to

the PROVIDE instance which still remains in the plan. This is done for products with the same parent only. Single Use

is modeled in product model by setting record attribute single use as true.

Update Single Use

This functionality ensures that if the products have same product ID and have been defned for single use with their

order line actions as PROVIDE and UPDATE then those products are not provisioned more than once. It deletes instance

which has its order line action as PROVIDE and also ensure that the dependencies point to the UPDATE instance which

still remains in the plan. This is done for products with the same parent only.

Inventory Single Use

This functionality ensures that if the inventory for the products which were already provisioned for a customer/subscriber

is ordered again with order line action as PROVIDE then those products are not provisioned again. It deletes instance

which has its order line action as PROVIDE and also ensure that the dependencies point to the parent instance, which

still remains in the plan.

The assign inventory service exposed by the AFS component allows the external users assign inventory for customers

against orders. These inventories are stored in the OCV engine. When an order for the same customer and product is

made again, then the AOPD engine synchronizes the inventories for the customer from OCV and generates the plan

accordingly.




42/60

Sequencing

The product catalog defnes the sequencing requirements between the fulfllment steps for various products in a product

offering.

When the order plan is being developed, the information in the product catalog is used such that the instance sequence

defned for each sub-product and products which contain these sub-products translates to a dependencies between Plan

Fragments associated with each product/sub-product and the fulfllment happens in the correct sequence.

Sequencing is governed by certain rules on the Plan Fragments.

ActiveFulfllment supports the action-based sequencing. This use case based sequence of back-end systems is utilized

in the decomposition to ensure back-end (process component) are called in the correct order. Based on the order line

action, the following types of sequencing are used:

PROVIDE

CEASE

UPDATE

PROVIDE Sequencing: This scenario occurs when the order line action is PROVIDE and all the sub products use the

provide instance sequence number.

CEASE Sequencing: This scenario occurs when the order line action is CEASE and all the sub products use the cease

instance sequence number.

UPDATE Sequencing: This scenario occurs when the order line action is UPDATE and all the sub products use the

update instance sequence number.

The following fgure shows the sequencing for the products A, B and C.

Figure 8: Sequencing for the products A, B and C.

Sequence number is the relationship attribute value based on the action, viz, PROVIDE, CEASE, UPDATE.

For example, a bundle is comprised of Product A, Product B and Product C, with PROVIDE sequencing set to 2, 1 and

3 respectively. When an order plan is developed, Product B is executed frst, followed by Product A and then Product

C.




43/60

Figure 9: Order Plan Execution Sequence

Similarly, a CEASE sequencing order can also be defned for the same Product Bundle with a sequencing of 3, 1, and

2 for products A, B, and C respectively. In this manner, the order may be fulflled in the correct sequence taking into

account what action needs to be performed.

The Order lines are converted into plan items during the plan development using the information in the product catalogue.

The diagram explains the sample product model and its components (Product Offerings). This diagram is used to briey

explain the different Plan Development Concepts (for details, see Automated Order Plan Development on page 37).

Figure 10: Sample Product Model

The table describes the diagram elements of the Product Model Hierarchy.

DescriptionDiagram Element

Product entity.

BUNDLE

The arrows represent theProductComprisedOfrelationship in the

product catalogue between BUNDLE and

a group of products. Thus, the diagrams

states that:

BUNDLE is comprised of the product

Broadband.

BUNDLE is comprised of the product

VOIP.




44/60

DescriptionDiagram Element

The Broadband Product Offering (PO)

contains the following mandatory

products:

Telephone

UserID

Line ActivationThe dotted line indicates that the Modem

is an optional product.

The VOIP Product Offering (PO) contains

the following mandatory products:

VOIPTV

COMBOX

UserID

The UserID products has two parents.

Product Model Description:

The product BUNDLE is comprised of the two Product Offerings (PO):

Broadband.

VOIP.

The Broadband product offering contains the products as the Telephone, UserID, and Line Activation as the mandatory

product. Modem is an optional product.

VOIP has the COMBOX, UserID, and VOIPTV as part of its technical products.

The product UserID, here has two parents - Broadband and VOIP. The product UserID has single use record attribute

set to true with both its parents.

Using (relationship) sequencing, all the child products of the BUNDLE would be fulflled or processed in parallel, and

all must complete before the entire BUNDLE can be fulf

lled. Often, additional sequencing is required within elementsat the same hierarchy level in the model. This can be accomplished by providing sequence numbers on the

ProductComprisedOfrelationship.

Product Model Description in Relation to the Sequencing Feature:

The correct fulfllment sequencing of the product plan execution as per the diagram is:

1. The UserID is created.

2. The order on the Telephone and COMBOX is processed. The Telephone and COMBOX is installed.

3. The Line Activation is completed.

4. Modem is installed.

5. Broadband Product Order is fulflled.

6. VOIPTV is installed.

7. VOIP Order is completed.8. The entire BUNDLE order (Broadband and VOIP) is completed.

Taking the product as an example, the table shows the sequencing of the products:

Product OfferingParent Product

UserIDBUNDLE

Telephone/COMBOXBUNDLE

Line ActivationBUNDLE




45/60

Modem Installation (optional)BUNDLE

VOIPBUNDLE

BUNDLE Order completeBUNDLE




46/60

Product Affinity (Plan Item Level)

Product Affnity between different products on the same order allows those products to be grouped and fulflled together

through the execution of a single plan item. It can be viewed as an optimization from order fulfllment's point of view.

In general, there is a plan item corresponding to an order line specifying a product to be fulflled in the order. If affnity

is specifed between the products that are either being fulflled implicitly as mandatory children or ordered explicitly as

separate order lines, the individual plan items will be grouped together into a single affnity plan item during plan

optimization in AOPD. Thus, the corresponding products will be fulflled through the execution of this single plan item.

Product affnity is specifed in the product catalogue in one of the two different ways:

By specifying the affnity type and action specifc plan fragments attributes in the AffnityGroup tab in PRODUCT

repository.

By assigning the plan fragments using ProductHasXXPlanFragment relationships and specifying the affnity specifc

relationship attributes.

XX in relationship name above refers to actions such as Provide, Cease, Update and Cancel.

AOPD recognizes the affnity and combine the plan items corresponding to order lines on the basis of the following two

main conditions:

If the plan fragments defned in the product catalogue for the ordered products are same.

If the affnity type defned in the product catalogue for the ordered products is same (InLink or CrossLink).

TIBCO ActiveFulfllment supports following types of product affnity:

Inlink

Inlink Affnity can be defned between the products at the same level in a bundle.

Figure 11: Inlink Affinity

As shown in the above fgure, InLink affnity can be defned between Product B and Product C for PROVIDE action

by specifying the affnity type as InLink and same PROVIDE plan fragment as PC_PROVIDE_BC.

For InLink affnity, a UDF namely LinkID having exactly same value should be passed in the order lines corresponding

to the products to be affnity grouped.

In addition to the two conditions mentioned above, AOPD also checks two more conditions for InLink affnity:

1. If the value ofLinkID UDF in the plan items (propagated from order lines) to be merged is exactly the same.

2. If the dependentOn (parent product's) plan item for the plan items to be merged is exactly the same.

If these additional conditions are met, then only the plan items are combined into a single affnity plan item containing

the plan fragment from any of the merging plan items' since it is the same for all of them.

Crosslink

The Crosslink Affnity can be defned between the products at any levels across the bundles.




47/60

In Product Model diagram, the products Telephone and COMBOX can have CrossLink affnity between them. While

order fulfllment process, both these technical products would be installed and confgured in one go through the affnity

grouped single plan item.

AOPD does not check any additional conditions for CrossLink affnity.

Affnity applies to the order plan development and this element is used to determine what plan fragments are executed

for the product when affnity grouping is active. Affnity Plan Fragments XSD is illustrated as:

Figure 12: Affinity Plan Fragments XSD

The following table explains the Affnity Plan Fragements Data Model.

ExampleDescriptionElement TypeElement Name

Plan fragment cancel type.String (Optional)planFragmentUniqueId_CANCEL

EP_BUNDLE_CANCEL

NO_RECIPROCAL_ACTION

Name of the plan fragment

to execute when cancelling

this product.

String (Optional)planFragmentUniqueId_CANCEL/

name

Product 1 CancelDescription of the plan

fragment to execute whencancelling this product.

String (Optional)planFragmentUniqueId_CANCEL/

description

Plan fragment provide type.String (Optional)planFragmentUniqueId_PROVIDE

EP_BUNDLE_PROVIDEName of the plan fragment

to execute when providing

this product.

String (Optional)planFragmentUniqueId_PROVIDE

/ name




48/60

Product 1 ProvideDescription of the plan

fragment to execute when

providing this product.

String (Optional)planFragmentUniqueId_PROVIDE

/ description

Plan fragment cease type.String (Optional)planFragmentUniqueId_CEASE

EP_BUNDLE_CEASEName of the plan fragment

to execute when ceasing this

product.

String (Optional)planFragmentUniqueId_CEASE/

name

Product 1 CeaseDescription of the plan


ceasing this product.

String (Optional)planFragmentUniqueId_CEASE /

description

Plan fragment update type.String (Optional)planFragmentUniqueId_UPDATE

EP_BUNDLE_UPDATEName of the plan fragment

to execute when updating

this product.

String (Optional)planFragmentUniqueId_UPDATE/

name

Product 1 UpdateDescription of the plan


updating this product.

String (Optional)planFragmentUniqueId_UPDATE/

description

As above information is coming along with Plan Fragment/Plan schema in the product model, affnity group

element node in itemspecs has been deprecated in ActiveFulfllment 1.2.0 product model. However, for backward

compatibility (for example, product model published from ActiveCatalog 1.1.0 or created manually according

to ActiveCatalog 1.1.0 product model schema),the element node is present in the schema fle.

Affinity Sequencing

Affnity Sequencing is used to support the scenario for maintaining sequencing during affnity grouping. Affnity

Sequencing was introduced since during affnity RulesEngine (BusinessEvents) selects plan items at random which are

then merged into a single plan item. Since items are selected at random during this process sequencing is not maintained

for plan items that should be in sequence.

To make products available for affnity sequencing:

Affnity TYPE value for all products where sequence should be respected should be set to "SequencedAffnity" in

the affnity type

All order lines where affnity components are known to exist should have a UDF defned as AffnitySequence and

the value should be an integer

Depending on the AffnitySequence values being compared, the following actions are possible:

1. itemA.AffnitySequence = itemB.AffnitySequnce

If both items have dependent children the children from itemB will be copied to itemA

itemB parent will be updated with the plan item ID from itemA thus making itemA dependent to its own parent

and the itemB parent

UDF values from itemB will be merged into itemA

Any item which has a reference to itemB will have that reference replaced with a reference to itemA

The instance of itemB will be deleted from the plan




49/60

Figure 13: Parallel Scenario

The fgure depicts the scenario where the items to be affnity grouped are running in parallel. One of the items in

this case itemB will be deleted from the plan. The dependent items to itemB which are childB1 and childB2 are made

dependent to itemA. Then itemA is made dependent to parentB which is the parent to itemB.2. itemA.AffnitySequence < itemB.AffnitySequnce

itemB will be merged into itemA

UDF values from itemB will be merged into itemA

Any item which has a dependency to itemB will have that reference removed

all the children from itemB will be made dependant to itemB parent(s)

itemB will be deleted from the plan

Figure 14: Sequenced Scenario

The fgure depicts an offering which has items that are in parallel as well as in sequence that need to be affnity

grouped. For items that are in parallel they are handled similar to the fgure 1. For the item that is in sequence itemC.

It is dependent item offerB is made dependent to CommercialA which is the parent to itemC.

3. itemA.AffnitySequence > itemB.AffnitySequnce

itemA will be merged into itemB

UDF's from itemA will merged into itemB




50/60

if itemA has dependent children those children will be copied into itemB and the parent item of itemA

Any item which has a reference to itemA will have that reference erased

itemA will be deleted from the plan

Figure 15: Items in Sequence

For all the above actions the following occurs in all of them:

EOL, Plan description and Line ID values will all be merged into comma separated values from itemA and itemB

The planID will be updated with the affnity plan ID

When an order is submitted, the order lines for items which have Affnity should have the AffnitySequnce

defned and updated.

To not merge certain udfs during Affnity Sequencing, those udfs should be added as a comma separated valuesin the global variable CharacteristicsWithoutAffnityPostfx in the rules engine (AOPD).




51/60

Dependent and Sibling Products

TIBCO ActiveFulfllment provides the ability in the product catalog to indicate that a product is dependent on its peer

[DEPENDENT_PRODUCT] or peer's hierarchy [SIBLING_PRODUCT].

The only difference between dependent products and sibling products is that the dependent product would not add the

peer product's children to be included in the subsequent southbound service calls while sibling product adds the peer's

children on the southbound service calls.

The diagram shows the product model.

Figure 16: Data Model

P8 has a dependent product link to P7 and P6. This means that the process component corresponding to P8 can use the

output UDFs of P7 and P6 during the execution provided P7 and P6 have been ordered directly or indirectly in the order

and corresponding process components have been executed.

P3 has a sibling product link to P2. This means that the process component corresponding to P3 can use the output UDFs

of P2, P4, P5, P6, P7, P8 and P9 during the execution provided P2 has been ordered directly or indirectly in the order

and corresponding process components have been executed.

The 6 product characteristics as explained in the table below should be added in the product model defned in TIBCO

ActiveCatalog or ofine model xml. The dependent or sibling link can be defned for a product by creating the

Characteristic relationship with one of the above relevant products [as per the scenario] with the value of

RelationshipValue attribute as the comma separated IDs of the dependent or sibling products.

DescriptionName

Dependent product characteristic for PROVIDE scenarioDEPENDENT_PRODUCT

Dependent product characteristic for CEASE scenarioDEPENDENT_PRODUCT_CEASE

Dependent product characteristic for UPDATE scenarioDEPENDENT_PRODUCT_UPDATE

Sibling product characteristic for PROVIDE scenarioSIBLING_PRODUCT




52/60

Sibling product characteristic for CEASE scenarioSIBLING_PRODUCT_CEASE

Sibling t product characteristic for UPDATE scenarioSIBLING_PRODUCT_UPDATE

For example, Dependent link for P8 in case of PROVIDE scenario can be specifed by creating a Characteristic relationship

between P8 and DEPENDENT_PRODUCT with the value of RelationshipValue as "P6, P7".




53/60

Shared Attributes

Shared Attributes are used when two Products (parent to child and sibling) share the same attribute and its corresponding

value and an update in the value of one needs to be reected in the other. If an attribute is deemed as a shared attribute

and the value was passed in on the order then during decomposition value is copied to the other products based on the

EvaluationPriority set on the other products.

EvaluationPriority

Multiple products can have same shared attribute. Hence, if value for a shared attribute needs to be merged with same

shared attribute in other products, user needs to defne the EvaluationPriority, which indicates the priority of merging

the specifed characteristic from the target Product.

During plan development process, AOPD checks if characteristic (i.e. attribute) is of type 'Shared'; if yes then it checks

the EvaluationPriority for the characteristic. If products mentioned on the EvaluationPriority have the same shared

attribute, then the value for the characteristic is taken from the product. If none of the products mentioned on the

EvaluationPriority have the same shared attribute OR EvaluationPriority is not defned, then the value is taken from

order line (if passed in order line) or product model.

Second part of the Shared attribute defnition mentions that update in the value of shared attribute in one product needs

to be reected in other products having same shared attribute.

During execution, the Process Component may need to update the attribute (UDF) values. To update the value of a UDF,

the Process Component calls setPlanItem on TDS mentioning the UDFs to be updated. Process Component sends the

following details for the UDF:

1. name - name of the UDF to update

2. value - updated value

3. avor - 'output' (this indicates that Process Component has updated the value from set/get methods), Input (this

indicates that Process Component has updated the value from order line), Confg (this indicates that Process Component

has updated the value from Product model)

4. type - Shared (if UDF is of type Shared)

On the subsequent calls to getPlanItems on TDS (Process Component may make this call to get details such as UDFs

for plan items from TDS), TDS checks if requested plan items have any UDF (i.e. attributes) with type as 'Shared'. IfShared UDFs are present then TDS checks the EvaluationPiority for that UDF.

For the products mentioned on the EvaluationPriority, for each product (in the order of priority) TDS checks if it contains

the UDF with same name and avor = output. If TDS fnds such UDF then value from this UDF is returned. If

EvaluationPriority is not defned OR products mentioned on the EvaluationPriority don't contain the UDF with same

name and "output" avor then value from order line/product model is returned (i.e. merging is not done).




54/60

Intermediate Milestones Dependencies

The actual fulfllment of a product is done by orchestrating the back-end process components. By default, any process

component has two milestones:

1. START

2. END

These milestones represent the starting and the end parts of it. ActiveFulfllment 1.1.0 supports the direct dependency

between the process components due to sequencing of the products in the catalogue. This dependency is of type

END-to-START, or once a process component is completely executed, then only the dependent process component can

start its execution as shown in the following fgure:

Figure 17: END-to-START dependency

The process component EP_DEVICE_PROV can start only when EP_SERVICE_PROV is completed and

EP_TARIFF_PROV can start only when EP_DEVICE_PROV is completed.

ActiveFulfllment 1.2.0 supports the following complex types of dependencies between the executing process components:

Milestone to START Dependency

END to Milestone Dependency

Milestone to Milestone Dependency

Milestone without Dependency

These dependencies are supported with the implementation of Intermediate Milestones within the process componentin addition to the START and END.

Milestone to START Dependency

START milestones of a process components has a dependency on the completion of an intermediate milestone(s) in

another process component(s).

The following fgure shows the Milestone to START dependency:

Figure 18: Milestone to START Dependency

END to Milestone Dependency

Intermediate milestone(s) in a process component has a dependency on the completion of the END milestone(s) in

another process component(s).

The following fgure shows the END to Milestone dependency:




55/60

Figure 19: END to Milestone Dependency

Milestone to Milestone Dependency

Intermediate milestones in a process component has a dependency on the completion of the intermediate milestones in

another process components.

The following fgure shows the Milestone to Milestone dependency:

Figure 20: Milestone to Milestone Dependency

Milestone without Dependency

There can be intermediate milestones defned in a process component which does not have any dependencies. However,

milestones in another process component may depend on any of these milestones.

The following fgure shows the Milestone without any dependency:

Figure 21: Milestone without Dependency

These types of dependencies help manage the complex order fulflment process. For instance, start activating the

broadband service once the broadband device fulflment reaches a certain status, say, INSTALLED.

The product model schema has been updated to support the milestones and dependency defnitions. See TIBCO

ActiveCatalog ProductCatalog Guide for newly added repository and relationships to support the intermediate

milestones dependencies.




56/60

Understanding Orders

An order is a request to fulfll a particular set of goals and received from an external system. Orders must be in line to

the Order Schema, otherwise the order can be rejected. The order schema can be extendible.

In order to change an order, you can submit an amendment, which is sent as a separate order request. An order is managed

by processing order requests and order amendments. Order requests and amendments are submitted in the form of an

XML document.

Order requests and amendments consist of an order header and one or more order items.

When an order request is submitted, it creates the order and stores it in the database. It also maintains a working view

of the order. This is a view of the order request and any order amendments that have been applied to an order.

Order Amendment

An Order Amendmentallows you to modify the original order. This feature depends mainly on the phase in which the

order is currently being processed. In other words, an order amendment is the process of making changes to a previously

submitted order.

Any order which has not been started or completed can be amended.

An order can only be amended when it is in the fulfllment stage or in the processing stage. In other words, you cannot

amend an order after the order is complete.

Orders may only be amended in certain life-cycle states.

Not AmendableAmendable

CompleteSubmitted

CanceledFeasibility

WithdrawnPlan Development

Pre-Qualifcation Failed

Execution

An order amendment has the same structure as an order request. OMS uses the Order Reference to determine whether

the order is an order request or an order amendment. It does this by checking to see if it already has an order with the

same Order Reference stored in the database. If there is an order with that reference already in the database then it is an

order amendment. If there is not, then it is an order request.

When amending orders, you can:

Add new order lines

Change existing order lines

You cannot do the following:

delete order lines

blankfeld names in the order. For example, if there are any felds in the amendment order header that are empty,

this does not cause the equivalent felds in the order view to be cleared.

Amendments prior to the creation of a plan take the form of updating the order in the database and then restarting the

order life-cycle from the Submitted state. At this point, a plan has not been generated and does not need to be modifed.

When the fulfllment process reaches the Plan Development step, the updated order as it exists from the amendment is

used to generate the plan. This applies to order status ofSubmitted, Feasibility, Plan Development, and Pre-Qualifcation

Failed.




57/60

Amendments that occur after the plan creation

For amendments that occur after a plan has been created, but while the plan is still in the Pending state, then the order

is updated in Transient Data Store. The existing plan is discarded and the order starts from the Submitted state. This

applies to order status of Execution, but with a plan status of Pending.

Amendments that occur after the plan start

For amendments that occur after a plan has started executing, only certain aspects of an order may be amended. Any

other aspects of an order not explicitly detailed here are not amendable. This applies to order and plan status of Execution.

There is no limitation on the number of amendments that are possible for any given order, but only one amendment

is be active at any one time. Once the amendment has completed, and the order resumes execution, then it is

possible to amend the order again.

Date Shift

The Date Shiftis changing the date that a particular order line is required on. Required by date may be changed at any

point during the order life-cycle, but subject to the following plan item status restrictions:

Plan item dependency time will be updated so the plan item triggers at the amended required by date.Pending

Not permitted. Any required by date changes are ignored. As the plan item is already started, it is not

possible to change the start date.

Execution

Not permitted. Any required by date changes are ignored. As the plan item is already completed, it is not

possible to change the start date.

Complete

When the order is requested to be shifted or delivered either after or before the stipulated date, then this scenario describes

the situation where there is a change in 'Date Shift' or 'Required by Date' of the entire order or a particular order line.

Change Order Line Operation

This type of Order Amendment describes the situation where one or more order lines have been either:

added

deleted modifed

Remove Order Line

Remove Order Line indicates cancelling only certain lines on an order. The cancelled order lines are processes according

to the Cancel Order scenario, but the non-cancelled order lines continue to process as before. Plan items with dependencies

on cancelled order lines are satisfed.

Cancel Order

Cancel order is a special case of the Order Amendment where the entire order is cancelled. Cancellations prior to

execution update the state of the order in the database. As a cancellation of the entire order, no plan can be developed.

In the event of cancellations during execution, each individual order line are cancelled, based on the status of the

associated plan items. The following table explains the individual status handling.

The plan item status is s

tib af concept

Documents