8/3/2019 Tib Af Concept
1/60
8/3/2019 Tib Af Concept
2/60
8/3/2019 Tib Af Concept
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
8/3/2019 Tib Af Concept
4/60
8/3/2019 Tib Af Concept
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
TIBCO ActiveFulfllment Concepts and Architecture
TOC | 5
8/3/2019 Tib Af Concept
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
TIBCO ActiveFulfllment Concepts and Architecture
6 | TOC
8/3/2019 Tib Af Concept
7/60
Preface
The preface contains information about documentation related to the current document, typographical conventions, and
information on how to contact TIBCO support.
TIBCO ActiveFulfllment Concepts and Architecture
8/3/2019 Tib Af Concept
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.
TIBCO ActiveFulfllment Concepts and Architecture
8 | Preface
8/3/2019 Tib Af Concept
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.
TIBCO ActiveFulfllment Concepts and Architecture
Preface | 9
8/3/2019 Tib Af Concept
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.
TIBCO ActiveFulfllment Concepts and Architecture
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/8/3/2019 Tib Af Concept
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
TIBCO ActiveFulfllment Concepts and Architecture
8/3/2019 Tib Af Concept
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.
TIBCO ActiveFulfllment Concepts and Architecture
12 | Introduction
8/3/2019 Tib Af Concept
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.
TIBCO ActiveFulfllment Concepts and Architecture
Introduction | 13
8/3/2019 Tib Af Concept
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
TIBCO ActiveFulfllment Concepts and Architecture
14 | Introduction
8/3/2019 Tib Af Concept
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
TIBCO ActiveFulfllment Concepts and Architecture
Introduction | 15
8/3/2019 Tib Af Concept
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.
TIBCO ActiveFulfllment Concepts and Architecture
16 | Introduction
8/3/2019 Tib Af Concept
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.
TIBCO ActiveFulfllment Concepts and Architecture
Introduction | 17
8/3/2019 Tib Af Concept
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.
TIBCO ActiveFulfllment Concepts and Architecture
18 | Introduction
8/3/2019 Tib Af Concept
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
TIBCO ActiveFulfllment Concepts and Architecture
8/3/2019 Tib Af Concept
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.
TIBCO ActiveFulfllment Concepts and Architecture
20 | Defnitions and Concepts
8/3/2019 Tib Af Concept
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)
TIBCO ActiveFulfllment Concepts and Architecture
Defnitions and Concepts | 21
8/3/2019 Tib Af Concept
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
TIBCO ActiveFulfllment Concepts and Architecture
22 | Defnitions and Concepts
8/3/2019 Tib Af Concept
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.
TIBCO ActiveFulfllment Concepts and Architecture
Defnitions and Concepts | 23
8/3/2019 Tib Af Concept
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.
TIBCO ActiveFulfllment Concepts and Architecture
24 | Defnitions and Concepts
8/3/2019 Tib Af Concept
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.
TIBCO ActiveFulfllment Concepts and Architecture
Defnitions and Concepts | 25
8/3/2019 Tib Af Concept
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.
TIBCO ActiveFulfllment Concepts and Architecture
26 | Defnitions and Concepts
8/3/2019 Tib Af Concept
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.
TIBCO ActiveFulfllment Concepts and Architecture
Defnitions and Concepts | 27
8/3/2019 Tib Af Concept
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.
TIBCO ActiveFulfllment Concepts and Architecture
28 | Defnitions and Concepts
8/3/2019 Tib Af Concept
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.
TIBCO ActiveFulfllment Concepts and Architecture
Defnitions and Concepts | 29
8/3/2019 Tib Af Concept
30/60
8/3/2019 Tib Af Concept
31/60
Chapter
3Fulfillment Process
Topics
Overview
Plan Development Process
Orchestration
TIBCO ActiveFulfllment Concepts and Architecture
8/3/2019 Tib Af Concept
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.
TIBCO ActiveFulfllment Concepts and Architecture
32 | Fulfllment Process
8/3/2019 Tib Af Concept
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:
TIBCO ActiveFulfllment Concepts and Architecture
Fulfllment Process | 33
8/3/2019 Tib Af Concept
34/60
Figure 5: Plan Generation and Execution Sequence
TIBCO ActiveFulfllment Concepts and Architecture
34 | Fulfllment Process
8/3/2019 Tib Af Concept
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
TIBCO ActiveFulfllment Concepts and Architecture
Fulfllment Process | 35
8/3/2019 Tib Af Concept
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.
TIBCO ActiveFulfllment Concepts and Architecture
36 | Fulfllment Process
8/3/2019 Tib Af Concept
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
TIBCO ActiveFulfllment Concepts and Architecture
8/3/2019 Tib Af Concept
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.
TIBCO ActiveFulfllment Concepts and Architecture
38 | Automated Order Plan Development
8/3/2019 Tib Af Concept
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.
TIBCO ActiveFulfllment Concepts and Architecture
Automated Order Plan Development | 39
8/3/2019 Tib Af Concept
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.
TIBCO ActiveFulfllment Concepts and Architecture
40 | Automated Order Plan Development
8/3/2019 Tib Af Concept
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.
TIBCO ActiveFulfllment Concepts and Architecture
Automated Order Plan Development | 41
8/3/2019 Tib Af Concept
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.
TIBCO ActiveFulfllment Concepts and Architecture
42 | Automated Order Plan Development
8/3/2019 Tib Af Concept
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.
TIBCO ActiveFulfllment Concepts and Architecture
Automated Order Plan Development | 43
8/3/2019 Tib Af Concept
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
TIBCO ActiveFulfllment Concepts and Architecture
44 | Automated Order Plan Development
8/3/2019 Tib Af Concept
45/60
Modem Installation (optional)BUNDLE
VOIPBUNDLE
BUNDLE Order completeBUNDLE
TIBCO ActiveFulfllment Concepts and Architecture
Automated Order Plan Development | 45
8/3/2019 Tib Af Concept
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.
TIBCO ActiveFulfllment Concepts and Architecture
46 | Automated Order Plan Development
8/3/2019 Tib Af Concept
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
TIBCO ActiveFulfllment Concepts and Architecture
Automated Order Plan Development | 47
8/3/2019 Tib Af Concept
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
fragment to execute when
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
fragment to execute when
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
TIBCO ActiveFulfllment Concepts and Architecture
48 | Automated Order Plan Development
8/3/2019 Tib Af Concept
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
TIBCO ActiveFulfllment Concepts and Architecture
Automated Order Plan Development | 49
8/3/2019 Tib Af Concept
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).
TIBCO ActiveFulfllment Concepts and Architecture
50 | Automated Order Plan Development
8/3/2019 Tib Af Concept
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
TIBCO ActiveFulfllment Concepts and Architecture
Automated Order Plan Development | 51
8/3/2019 Tib Af Concept
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".
TIBCO ActiveFulfllment Concepts and Architecture
52 | Automated Order Plan Development
8/3/2019 Tib Af Concept
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).
TIBCO ActiveFulfllment Concepts and Architecture
Automated Order Plan Development | 53
8/3/2019 Tib Af Concept
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:
TIBCO ActiveFulfllment Concepts and Architecture
54 | Automated Order Plan Development
8/3/2019 Tib Af Concept
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.
TIBCO ActiveFulfllment Concepts and Architecture
Automated Order Plan Development | 55
8/3/2019 Tib Af Concept
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.
TIBCO ActiveFulfllment Concepts and Architecture
56 | Automated Order Plan Development
8/3/2019 Tib Af Concept
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