TIBCO Fulfillment Order Management User`s Guide

TIBCO Fulfillment Order Management User`s Guide
TIBCO® Fulfillment Order
Management User's Guide
Software Release 3.0.0
July 2015
Important Information
SOME TIBCO SOFTWARE EMBEDS OR BUNDLES OTHER TIBCO SOFTWARE. USE OF SUCH EMBEDDED
OR BUNDLED TIBCO SOFTWARE IS SOLELY TO ENABLE THE FUNCTIONALITY (OR PROVIDE LIMITED
ADD-ON FUNCTIONALITY) OF THE LICENSED TIBCO SOFTWARE. THE EMBEDDED OR BUNDLED
SOFTWARE IS NOT LICENSED TO BE USED OR ACCESSED BY ANY OTHER TIBCO SOFTWARE OR FOR
ANY OTHER PURPOSE.
USE OF TIBCO SOFTWARE AND THIS DOCUMENT IS SUBJECT TO THE TERMS AND CONDITIONS OF A
LICENSE AGREEMENT FOUND IN EITHER A SEPARATELY EXECUTED SOFTWARE LICENSE AGREEMENT,
OR, IF THERE IS NO SUCH SEPARATE AGREEMENT, THE CLICKWRAP END USER LICENSE AGREEMENT
WHICH IS DISPLAYED DURING DOWNLOAD OR INSTALLATION OF THE SOFTWARE (AND WHICH IS
DUPLICATED IN LICENSE.PDF) OR IF THERE IS NO SUCH SOFTWARE LICENSE AGREEMENT OR
CLICKWRAP END USER LICENSE AGREEMENT, THE LICENSE(S) LOCATED IN THE “LICENSE” FILE(S) OF
THE SOFTWARE. USE OF THIS DOCUMENT IS SUBJECT TO THOSE TERMS AND CONDITIONS, AND YOUR
USE HEREOF SHALL CONSTITUTE ACCEPTANCE OF AND AN AGREEMENT TO BE BOUND BY THE SAME.
This document contains confidential information that is subject to U.S. and international copyright laws and treaties.
No part of this document may be reproduced in any form without the written authorization of TIBCO Software
Inc.
TIBCO, Two-Second Advantage, TIBCO ActiveMatrix BusinessWorks, TIBCO Runtime Agent, TIBCO Administrator,
and TIBCO Enterprise Message Service, are either registered trademarks or trademarks of TIBCO Software Inc. in
the United States and/or other countries.
EJB, Java EE, J2EE, and all Java-based trademarks and logos are trademarks or registered trademarks of Sun
Microsystems, Inc. in the U.S. and other countries.
All other product and company names and marks mentioned in this document are the property of their respective
owners and are mentioned for identification purposes only.
THIS SOFTWARE MAY BE AVAILABLE ON MULTIPLE OPERATING SYSTEMS. HOWEVER, NOT ALL
OPERATING SYSTEM PLATFORMS FOR A SPECIFIC SOFTWARE VERSION ARE RELEASED AT THE SAME
TIME. SEE THE README FILE FOR THE AVAILABILITY OF THIS SOFTWARE VERSION ON A SPECIFIC
OPERATING SYSTEM PLATFORM.
THIS DOCUMENT IS PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR
IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT.
THIS DOCUMENT COULD INCLUDE TECHNICAL INACCURACIES OR TYPOGRAPHICAL ERRORS. CHANGES
ARE PERIODICALLYADDED TO THE INFORMATION HEREIN; THESE CHANGES WILL BE INCORPORATED
IN NEW EDITIONS OF THIS DOCUMENT. TIBCO SOFTWARE INC. MAY MAKE IMPROVEMENTS AND/OR
CHANGES IN THE PRODUCT(S) AND/OR THE PROGRAM(S) DESCRIBED IN THIS DOCUMENT AT ANY
TIME.
THE CONTENTS OF THIS DOCUMENT MAY BE MODIFIED AND/OR QUALIFIED, DIRECTLY OR INDIRECTLY,
BY OTHER DOCUMENTATION WHICH ACCOMPANIES THIS SOFTWARE, INCLUDING BUT NOT LIMITED
TO ANY RELEASE NOTES AND "READ ME" FILES.
Copyright © 2010-2015 TIBCO Software Inc. ALL RIGHTS RESERVED.
TIBCO Software Inc. Confidential Information.
TIBCO® Fulfillment Order Management User's Guide
TOC | 5
Contents
Preface................................................................................................11
Related Documentation..........................................................................................................12
Typographical Conventions....................................................................................................13
Connecting with TIBCO Resources........................................................................................14
Chapter 1 Orchestrator....................................................................15
Architecture............................................................................................................................16
Backing Store..............................................................................................................16
Deployment.................................................................................................................16
Resource Failure Handling..........................................................................................16
Batch Notification...................................................................................................................18
Sub-batching..........................................................................................................................19
Batch Event Processing.........................................................................................................20
Locking Strategy.....................................................................................................................21
Failover...................................................................................................................................22
Notification..............................................................................................................................24
Throttling................................................................................................................................26
Order Request Optimization...................................................................................................27
Dead Letter Queue.................................................................................................................28
External Dependency.............................................................................................................30
Steps To Enable Enrichment.......................................................................................30
Configuration...............................................................................................................31
Logging........................................................................................................................31
Time Dependency..................................................................................................................32
Non-Executing Plan Item........................................................................................................33
Process Component Destination............................................................................................34
Order Types............................................................................................................................35
Standard New Order Fulfillment..................................................................................35
Partially Completed Order Fulfillment..........................................................................35
Amend Order...............................................................................................................36
Suspend and Activate Order.......................................................................................37
Order Submission...................................................................................................................38
Synchronous Order Submission..................................................................................38
Execution Plan.......................................................................................................................39
Plan Tasks with Associated Process Components......................................................39
Actions.........................................................................................................................39
Dependencies..............................................................................................................39
Order Header.........................................................................................................................40
TIBCO® Fulfillment Order Management User's Guide
6 | TOC
Order Line..............................................................................................................................41
Orchestrator Interfaces...........................................................................................................42
Feasibility Providers.....................................................................................................42
Process Components..................................................................................................45
Pre-qualification Failed Handlers.................................................................................60
Plan Item External Error Handlers...............................................................................64
Chapter 2 Automated Order Plan Development............................71
Overview................................................................................................................................72
Architecture............................................................................................................................73
Deployment.................................................................................................................73
Model Deployment.................................................................................................................76
Configuration..........................................................................................................................77
Main Configuration......................................................................................................77
Logs.............................................................................................................................78
Integration with Orchestrator.......................................................................................78
Features.................................................................................................................................79
Autoprovision...............................................................................................................79
Time Dependency.......................................................................................................80
Product Specification Field Decomposition.................................................................81
Sequencing..................................................................................................................82
Delta Provisioning........................................................................................................86
Product Affinity (Plan Item Level)................................................................................89
Configurable Handling of CrossLink +PCO Conflicts And Single Use +PCO Conflicts.99
Sort Plan......................................................................................................................99
Attribute Based Decomposition.................................................................................100
ProductDependsOn and ProductRequiredFor Relationships....................................101
Dependent and Sibling Products...............................................................................104
Shared Attributes.......................................................................................................105
Intermediate Milestones Dependencies....................................................................106
Order Amendment.....................................................................................................110
Order Priority.............................................................................................................124
Custom Action...........................................................................................................125
Chapter 3 Manual Order Plan Development................................127
Searching Orders for Manual Order Plan Development.......................................................128
Modifying the Plan in Draft Mode through Grid View............................................................130
Create a New Plan Item............................................................................................130
Create a New Milestone............................................................................................132
Delete Plan Item........................................................................................................133
Delete Milestone........................................................................................................134
Modify Plan Item........................................................................................................134
Modify Milestones......................................................................................................134
TIBCO® Fulfillment Order Management User's Guide
TOC | 7
Creating New Dependencies.....................................................................................134
Deleting Dependencies.............................................................................................136
Validations.................................................................................................................136
Modifying the Plan in Draft Mode through Gantt View..........................................................138
Create a New Plan Item............................................................................................138
Create a New Milestone............................................................................................138
Delete Plan Item........................................................................................................138
Delete Milestone........................................................................................................138
Modify Plan Item........................................................................................................139
Modify Milestones......................................................................................................139
Creating New Dependencies.....................................................................................139
Validations.................................................................................................................139
Saving the Modified Plan......................................................................................................140
Saving and Executing the Modified Plan..............................................................................141
Discarding Changes.............................................................................................................142
Modifying Plan in EXECUTION State...................................................................................143
Chapter 4 Jeopardy Management System...................................145
Jeopardy Management System............................................................................................146
Jeopardy Management..............................................................................................146
Chapter 5 Router............................................................................153
Chapter 6 Internal Error Handler..................................................155
Internal Error Handler Data Flow Diagram...........................................................................156
Understanding Data Flow in Internal Error Handler.............................................................157
Internal Error Handler Sequence Diagram...........................................................................159
Searching for Plans with Plan Item in ERROR State...........................................................160
Modifying the Plan Item State....................................................................................160
Submit the Error Resolution.................................................................................................164
Chapter 7 State Machine Pagination............................................165
State Machine Pagination Sequence Diagram.....................................................................166
State Machine Pagination Flow Diagram.............................................................................167
Chapter 8 Order Capture System Overview................................169
Order Capture System User Interface Overview..................................................................171
Searching for Subscribers....................................................................................................172
Submitting an Order in OCS.................................................................................................173
Amending an Order in OCS.................................................................................................174
Canceling an Order in OCS..................................................................................................176
TIBCO® Fulfillment Order Management User's Guide
8 | TOC
Order Capture System Error Codes and Messages.............................................................177
Search Syntax......................................................................................................................179
Chapter 9 Offer and Price Engine................................................181
Offer and Price Engine Product Model.................................................................................182
Decomposition...........................................................................................................185
Product Integrity........................................................................................................185
Segment Eligibility.....................................................................................................186
Data Validations.........................................................................................................188
Get Offer Compatibilities...........................................................................................189
Validate Offer Compatibilities.....................................................................................190
Group and Record Constraints..................................................................................190
Offer and Price Engine Price Model.....................................................................................192
Integrating TIBCO Fulfillment Catalog Price Models Offline......................................195
Get Prices Determinations and Calculations.............................................................196
Offer and Price Engine Discount Model...............................................................................198
Integrating TIBCO Fulfillment Catalog Discount Model Offline..................................201
Offer and Price Engine Use Cases......................................................................................202
Testing Product Eligibility Scenarios..........................................................................202
Testing Product Validation Scenarios........................................................................205
Chapter 10 Fulfillment Order Management User Interface........211
Navigation............................................................................................................................214
Changing Password.............................................................................................................215
OMS User Interface Logging Notifications...........................................................................216
Alert and Confirmation Box.......................................................................................216
Growls for Information and Error Messages..............................................................217
Notification Logger.....................................................................................................217
Fulfillment Order Management Functionality........................................................................219
Dashboard.................................................................................................................219
Orders Page..............................................................................................................226
Plans Page................................................................................................................232
Jeopardy Rule Configuration.....................................................................................238
GANTT Chart............................................................................................................258
Activity Log................................................................................................................266
Catalog Tab................................................................................................................268
Fulfillment Provisioning Service Order Hierarchy.................................................................269
Fulfillment Provisioning Attributes and Parameters..............................................................270
Searaching for Fulfillment Provisioning Components...........................................................272
Third Party Access to Fulfillment Order Management User Interface..................................273
Implementing OMSUIClient.jar..................................................................................273
Single URI to Access OMSUI Component................................................................273
TIBCO® Fulfillment Order Management User's Guide
TOC | 9
Chapter 11 Data Access Interfaces..............................................275
Get Order.............................................................................................................................276
Get Order Request....................................................................................................276
Get Order Response.................................................................................................276
Get Order Messages and Message Codes...............................................................278
Get Plan...............................................................................................................................279
Get Plan Request......................................................................................................279
Get Plan Response...................................................................................................280
Get Plan Messages and Message Codes.................................................................282
Get Plan Items......................................................................................................................284
Get Plan Items Request............................................................................................284
Get Plan Items Response..........................................................................................286
Get Plan Items Messages and Message Codes.......................................................288
Set Plan................................................................................................................................290
Set Plan Request.......................................................................................................290
Set Plan Response....................................................................................................292
Set Plan Messages and Message Codes..................................................................293
Set Plan Item........................................................................................................................294
Set Plan Item Request...............................................................................................294
Set Plan Item Response............................................................................................296
Set Plan Item Messages and Message Codes..........................................................297
Chapter 12 Best Practices for Fulfillment Order Management...299
Process Component Design Guidelines...............................................................................300
Process Component Technology Selection...............................................................300
BusinessWorks - Asynchronous Process Component.........................................................302
BusinessWorks - Synchronous Process Component...........................................................309
BusinessEvents - Process Component................................................................................310
Exception Handling Guidelines............................................................................................313
General Approach.....................................................................................................313
Example Approach....................................................................................................314
Pre Qualification Failed Handler................................................................................315
Technical Exception Handling....................................................................................316
Appendix A Schema References..................................................321
Plan Item..............................................................................................................................322
ResultStatus.........................................................................................................................324
Message...............................................................................................................................325
Order Request......................................................................................................................326
Appendix B Samples.....................................................................327
TIBCO® Fulfillment Order Management User's Guide
10 | TOC
Sample Order XML...............................................................................................................328
Sample Plan Item XML.........................................................................................................329
Sample XPATHs...................................................................................................................330
Appendix C Global Variables........................................................331
AOPD Global Variables........................................................................................................332
Orchestrator Global Variables..............................................................................................336
Global Variables and Configurations....................................................................................357
Glossary..............................................................................................................375
TIBCO® Fulfillment Order Management User's Guide
Preface
The preface contains information about documentation related to the current document, typographical
conventions, and information on how to contact TIBCO support.
TIBCO® Fulfillment Order Management User's Guide
12 | Preface
Related Documentation
This section lists documentation resources you may find useful.
TIBCO Fulfillment Order Management Documentation
The following documents form the TIBCO Fulfillment Order Management documentation set:
• TIBCO Fulfillment Order Management Installation and Configuration Read this manual for instructions on installation
and configuration.
• TIBCO Fulfillment Order Management Administration Read this manual for instructions on administration tasks.
• TIBCO Fulfillment Order Management Web Services Read this manual for information about the web services.
• TIBCO Fulfillment Order Management Release Notes Read the release notes for a list of features. This document
also contains the list of known issues for this release.
• TIBCO Fulfillment Order Management User's Guide This manual describes the features as well as all the screens.
• TIBCO Fulfillment Order Management Concepts and Architecture This manual describes terminology and concepts
of TIBCO Fulfillment Order Management.
Other TIBCO Product Documentation
You may find it useful to read the documentation for the following TIBCO products:
• TIBCO Fulfillment Catalog User's Guide This manual explains the features of TIBCO Fulfillment Catalog. It
provides the details of the User and Administrator tasks.
TIBCO® Fulfillment Order Management User's Guide
Preface | 13
Typographical Conventions
The following typographical conventions are used in this manual:
Table 1: General Typographical Conventions
Convention
Use
TIBCO_HOME
Many TIBCO products are installed within the same home directory. This
directory is referenced in documentation as TIBCO_HOME. The value of
TIBCO_HOME depends on the operating system. For example, on Unix systems
the default value is $HOME/tibco.
AF_HOME
TIBCO Fulfillment Order Management installs into a directory inside
ENV_HOME. This directory is referenced in documentation as AF_HOME. The
value of AF_HOME depends on the operating system. For example, on Unix
systems the default value is $TIBCO_HOME/af/3.0.
code font
Code font identifies commands, code examples, filenames, pathnames, and
output displayed in a command window. For example:
Use MyCommand to start the foo process.
bold code font
Bold code font is used in the following ways:
• In procedures, to indicate what a user types. For example: Type admin.
• In large code samples, to indicate the parts of the sample that are of particular
interest.
• In command syntax, to indicate the default parameter for a command. For
example, if no parameter is specified, MyCommand is enabled:
MyCommand [enable | disable]
italic font
Italic font is used in the following ways:
• To indicate a document title. For example: See TIBCO BusinessWorks Concepts.
• To introduce new terms For example: A portal page may contain several
portlets. Portlets are mini-applications that run in a portal.
• To indicate a variable in a command or code syntax that you must replace.
For example: MyCommand pathname
The note icon indicates information that is of special interest or importance, for
example, an additional action required only in certain circumstances.
The tip icon indicates an idea that could be useful, for example, a way to apply
the information provided in the current section to achieve a specific result.
The warning icon indicates the potential for a damaging situation, for example,
data loss or corruption if certain steps are taken or not taken.
TIBCO® Fulfillment Order Management User's Guide
14 | Preface
Connecting with TIBCO Resources
How to Join TIBCOmmunity
TIBCOmmunity is an online destination for TIBCO customers, partners, and resident experts—a 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:
https://docs.tibco.com.
How to Contact TIBCO Support
For comments or problems with this manual or the software it addresses, please contact TIBCO Support as
follows:
• For an overview of TIBCO Support, and information about getting started with TIBCO Support, visit this
site:
http://www.tibco.com/services/support
• If you already have a valid maintenance or support contract, visit this site:
https://support.tibco.com
Entry to this site requires a username and password. If you do not have a username, you can request one.
TIBCO® Fulfillment Order Management User's Guide
Chapter
1
Orchestrator
®
This section describes the functions of TIBCO Fulfillment Order Management Orchestrator feature.
Topics
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Architecture
Batch Notification
Sub-batching
Batch Event Processing
Locking Strategy
Failover
Notification
Throttling
Order Request Optimization
Dead Letter Queue
External Dependency
Time Dependency
Non-Executing Plan Item
Process Component Destination
Order Types
Order Submission
Execution Plan
Order Header
Order Line
Orchestrator Interfaces
TIBCO® Fulfillment Order Management User's Guide
16 | Orchestrator
Architecture
Orchestrator is a Java based component. The Orchestrator component is, by default, collocated with OMS.
This simplifies the deployment and administration. The Java implementation of the Orchestrator is
multi-threaded, which improves the performance.
Orchestrator needs to communicate with components such as AOPD, Feasibility Providers, and Error Handlers.
The previous implementation used exclusively JMS for communicating across components. JMS communication
was identified as one of the bottleneck. Orchestrator can now invoke some of these components directly
instead of using JMS. Orchestrator can invoke the AOPD component interface directly (if AOPD is in colocated
mode as well) or use JMS (if AOPD is in standalone mode).
Backing Store
Orchestrator uses the OMS database to store the state changes for each entity (order, order line, plan, plan
item, order amendment). The data for supporting the other features such as clustering, member failover, and
recovery is also maintained in the OMS database.
Deployment
Orchestrator is automatically deployed, like OMS is. There is no additional operations to do in order to deploy
Orchestrator.
Resource Failure Handling
The Resource Failure Handling feature identifies the failure or unavailability of resources as soon as possible
and takes necessary actions. The Resource Failure Handling feature implements automatic reconnection
feature for the key resources (JMS or DB) after failure or unavailability of these resources.
The Resource Failure Handling feature assists in the completion of the processing of previously submitted
order without data loss, and in the suspending of the order processing after detecting resource failure.
Resource Failure Handling Architecture
The two timer threads, one for the database and one for the JMS, keeps running at a predefined interval and
checks for resource failure. If an exception is identified then status of the particular resource is updated to
the HealthCheckEngine repository. If an exception is thrown while sending a JMS message by orchestrator
then that exception is reported to the HealthCheck thread and the resources are verified for failure. If a failure
is detected then that failure is reported to the HealthCheckEngine repository. The HealthCheckEngine
repository is checked by the respective application to take the respective action on resource failure or recovery.
TIBCO® Fulfillment Order Management User's Guide
Orchestrator | 17
In case of a resource issue, the cluster processing will be stopped and the cluster status will be changed to
INIT. The advisory messages will be processed by the Orchestrator for the JMS and the database. The messages
will be processed by the respective resource that is available. The Orchestrator will not process any requests
in case of a resource failure. The SOAP requests over JMS or HTTP will return back with the response code
to signify resource issue. All JMS listeners of the Orchestrator will be running but will not process the messages.
The JMS messages will be delivered again to the mentioned listeners. Messages on the TDS interfaces will
return an error code signifying a resource issue.
In case of resource recovery, the processing of the advisory messages will be stopped and the processing of
normal heartbeat will resume. The cluster will be initilaized with all the available members in the cluster
using the hearteat mechanism. Once respective nodes are started, they will process the cleanup messgaes,
and the pending batches, before marking the cluster state to the STARTED status. After node status is marked
to STARTED, the normal processing will start and messgaes from JMS destinations will be processed.
For more details related to Resource Failure Handling, see the TIBCO® Fulfillment Order Management
Administration Guide.
TIBCO® Fulfillment Order Management User's Guide
18 | Orchestrator
Batch Notification
Following are the notifications sent by Orchestrator:
1. Orchestrator sends the JMS notification to the Process Component for executing, suspending, and activating
the plan items. Orchestrator also needs to notify the Milestone waiting in the Process components
2. Orchestrator also publishes notifications for the state changes of entities such as Order, Order Line, Order
Amendment, Plan, and Plan Item. Third party applications can listen to these notifications.
The Orchestrator needs to execute the actions triggered by the state change. The actions are configured
internally to dispatch the JMS Messages, process Database notifications and logging. These actions are executed
in batches using the batch processor.
Batch threads are configured to run in the Orchestrator. Batch Threads execute the actions with each thread
dedicated to a group of orders and batch worker queue. The user can configure the number of batch threads
(com.tibco.fom.orch.batchProcessorsCnt) and the maximum size (com.tibco.fom.orch.maxBatchSize)
of the batch to process per thread, depending on the load. Actions generated by order events are posted to
the Batch Queue and are processed in the sequence that was sent to Batch queue. Batch threads groups the
action execute requests and executes them in batch.
TIBCO® Fulfillment Order Management User's Guide
Orchestrator | 19
Sub-batching
If the batching is configured, database notifications will be batched, executed, and committed to the batch.
If the transaction fails, each notification from the batch is executed separately and committed to the database.
If it still fails, the order id that is related to the notification is marked as batch error, and the notification is
moved to the dead letter table in database. Any other notifications for the same order are moved to dead
letter table. Users can execute them manually using the JMX console. The following screenshot is of the
jconsole with available operations to process dead letter table entries:
Figure 1: jConsole UI for Operations to Process Dead Letter Table Entries
TIBCO® Fulfillment Order Management User's Guide
20 | Orchestrator
Batch Event Processing
Events are consumed by state machine and notifications generated by state machines are posted in the Batch
process. Following is the list of the events that are processed by Orchestrator:
1. JMS Events that are primarily coming from process components, OMS and clean-up. Clean up activity
include clean-up of checkpoints and cleaning the final state orders from local heap memory.
Below is the sequence of activities involved:
a. State Machine receives the events from JMS.
b. Events are consumed by the state machine.
c. State machine generates the actions to be executed. The actions are configured internally to dispatch
the JMS Messages, process Database notifications and logging
d. Action execute requests are posted to Batch Process.
2. Time Dependent Events are triggered using Timer.
Below is the sequence of activities involved:
a. State Machine receives the events from Timer Event.
b. State machine generates the actions to be executed. The actions are configured internally to dispatch
the JMS Messages, process Database notifications and logging.
c. Action execute requests are posted to Batch Process.
TIBCO® Fulfillment Order Management User's Guide
Orchestrator | 21
Locking Strategy
The share nothing architecture is used while processing the orders. Each order is mapped to one node and
any subsequent event to the order is processed by the same node. JMS message selector is used for routing
orders to the correct nodes. If the event message header does not have the routing information, messages are
intercepted and routed to an appropriate node by adding the appropriate message selector.
TIBCO® Fulfillment Order Management User's Guide
22 | Orchestrator
Failover
The Orchestrators can be deployed in a cluster domain. One of the members in the cluster can be Cluster
Manager (CM) and the others act as Workers (W). The Cluster Manager manages the workers in the clusters.
Also the Cluster Manager monitors the members in cluster, so that it can also process the pending events in
failed nodes.
1. The Cluster Manager uses the heartbeat generated by the Workers to add members to the cluster and also
to detect failures.
2. At given point of time, only one member acts as the Cluster Manager, other members acting as Workers.
When the node starts up, an unique sequence number is generated and assigned to each members. This
number is also included in the heartbeat published by the members. Eventually all members in the cluster
are aware of the sequence number assigned to the other members in cluster, based on the heartbeat. Each
member can identify the lowest sequence numbers and find the corresponding node mapped to it. Member
with lowest sequence number will start as the Cluster Manager and other nodes will start as Workers.
When the cluster Manager member fails, the member next in sequence starts acting as the Cluster Manager.
3. The unique sequence number is generated using Sequence (SEQ_CLUSTER_SEQ_NUMBER) from OMS
database.
4. The Cluster Domain Name and members of the cluster are configured in the OMS database. The tables
definitions are as follows:
Table 2: table DOMAIN
Column
Description
DOMAINID
Name for the Cluster Domain
DESCRIPTION
Short Description of the domain
BACKINGSTORE
Backing store (DB). DB will use SQL for updating the status of
the node.
HEARTBEATINTERVAL
Interval between Heart Beat in milliseconds
MANAGERACTIVATIONINTERVAL Interval between cycles in milliseconds to check if the node can
be cluster manager and start executing the cluster manager tasks.
FTTHRESHOLDINTERVAL
Cluster manager assumes the node is failed if does not receive
the heartbeat from failed node after this specified interval in
millisecond.
HANDLEFAILEDNODEEVENTS
Allowed values are 1 or 0. Default is 1. If set to 1, Orchestrator
will transfer the events from failed nodes and start processing it.
If 0, events from failed nodes will not be transfered.
Table 3: table DOMAINMEMBERS
Column
Description
MEMBERID
Name for the Cluster Member
DESCRIPTION
Short Description of the member
DOMAINID
Domain that the member belongs to.
CLUSTERID
Cluster ID is uniquely generated by the node on runtime.
TIBCO® Fulfillment Order Management User's Guide
Orchestrator | 23
Column
Description
ISCLUSTERMANAGER
Flag is true if the member is cluster manager or its false if this
worker.
SEQNUMBER
Sequence number generated by the member.
LASTUPDATETIMESTAMP
Last updated Timestamp.
STATUS
INIT or STARTED. INIT means the node is initializing. STARTED
means the node has started.
HEARTBEATTIMESTAMP
Heartbeat Time Stamp.
5. The Orchestrator restores the data during failure from the checkpoints. The Orchestrator supports database
check pointing.
6. On cluster failure, the Orchestrator's listeners and throttling are disabled. Node will join again in to the
cluster with a new sequence number.
TIBCO® Fulfillment Order Management User's Guide
24 | Orchestrator
Notification
External clients can listen to JMS notifications that are sent by the Orchestrator for state changes. User can
enable the JMS notifications and configure the JMS destination name. Also user can filter the state change
notification.
Type of
state
change
Property name to enable notification
Property name to filter notification
Order Status c.t.f.o.enableOrderStatusChange
Change
c.t.f.o.order.statusChange.filter
OrderLine
Status
Change
c.t.f.o.enableOrderLineStatusChange
c.t.f.o.orderLine.statusChange.filter
Plan Status
Change
c.t.f.o.enablePlanStatusChange
c.t.f.o.plan.statusChange.filter
PlanItem
Status
Change
c.t.f.o.enablePlanItemStatusChange
c.t.f.o.planItem.statusChange.filter
Order
c.t.f.o.enableOrderAmendmentStatusChange c.t.f.o.orderAmendment.filter
Amendment
Status
Change
For readability, the property names in the following table uses c.t.f.o as a short cut for com.tibco.fom.orch.
To enable these notifications, set value of respective property to true and define a filter if required. Filter
property can be configured as a comma separated value of more than one status.
E.g. for setting filter property for Plan Status change:
<ConfValue description="Flag to enable or disable the publishing of Order Status Change
notification message" name="Enable Order Status Change Notification"
propname="com.tibco.fom.orch.enableOrderStatusChange" sinceVersion="2.1"
visibility="Basic">
<ConfBool default="false" value="true"/>
</ConfValue>
<ConfValue description="Filter for Order status change
notification; * will publish all" name="Order status change filter"
propname="com.tibco.fom.orch.order.statusChange.filter" readonly="false" sinceVersion="2.1"
visibility="Basic">
<ConfString default="*" value="*"/>
</ConfValue>
<ConfValue description="Flag to enable or disable the
publishing of OrderLine Status Change notification message" name="Enable OrderLine Status
Change Notification" propname="com.tibco.fom.orch.enableOrderLineStatusChange"
sinceVersion="2.1" visibility="Basic">
<ConfBool default="false" value="true"/>
</ConfValue>
<ConfValue description="Filter for OrderLine status change
notification; * will publish all" name="OrderLine status change filter"
propname="com.tibco.fom.orch.orderLine.statusChange.filter" readonly="false"
sinceVersion="2.1" visibility="Basic">
<ConfString default="*" value="*"/>
</ConfValue>
<ConfValue description="Flag to enable or disable the
publishing of Plan Status Change notification message" name="Enable Plan Status Change
Notification" propname="com.tibco.fom.orch.enablePlanStatusChange" sinceVersion="2.1"
visibility="Basic">
<ConfBool default="false" value="true"/>
TIBCO® Fulfillment Order Management User's Guide
Orchestrator | 25
</ConfValue>
<ConfValue description="Filter for Plan status change
notification; * will publish all" name="Plan status change filter"
propname="com.tibco.fom.orch.plan.statusChange.filter" readonly="false" sinceVersion="2.1"
visibility="Basic">
<ConfString default="*" value="*"/>
</ConfValue>
<ConfValue description="Flag to enable or disable the
publishing of PlanItem Status Change notification message" name="Enable PlanItem Status
Change Notification" propname="com.tibco.fom.orch.enablePlanItemStatusChange"
sinceVersion="2.1" visibility="Basic">
<ConfBool default="false" value="true"/>
</ConfValue>
<ConfValue description="Filter for PlanItem status change
notification; * will publish all" name="PlanItem status change filter"
propname="com.tibco.fom.orch.planItem.statusChange.filter" readonly="false"
sinceVersion="2.1" visibility="Basic">
<ConfString default="*" value="*"/>
</ConfValue>
<ConfValue description="Flag to enable or disable the
publishing of OrderAmendment Status Change notification message" name="Enable Order
Amendment Status Change Notification"
propname="com.tibco.fom.orch.enableOrderAmendmentStatusChange" sinceVersion="2.1"
visibility="Basic">
<ConfBool default="false" value="true"/>
</ConfValue>
<ConfValue description="Filter for OrderAmendment status
change notification; * will publish all" name="Order Amendment status change filter"
propname="com.tibco.fom.orch.orderAmendment.filter" readonly="false" sinceVersion="2.1"
visibility="Basic">
<ConfString default="*" value="*"/>
</ConfValue>
<ConfValue description="Flag to enable or disable the
publishing of Plan development notification message" name="Enable Plan development
notification" propname="com.tibco.fom.orch.enablePlanDevelopmentNotification"
sinceVersion="2.1" visibility="Basic">
<ConfBool default="false" value="true"/>
</ConfValue>
TIBCO® Fulfillment Order Management User's Guide
26 | Orchestrator
Throttling
Throttling controls the number of messages that the Orchestrator can consume and that can be dispatched
to the process component. If the Orchestrator dispatches more messages than the process components load
capacity, then the process component becomes a bottleneck.
User controls the number of incoming messages the Orchestrator can consume at given point of time, by
configuring the number of receivers for order receivers and process component receivers. For the outgoing
messages sent to the process components, the user can configure the default load capacity of the process
component. The Orchestrator stops consuming new orders when the number of process component requests
that are not responded to exceeds the default load capacity.
Also the user can configure the load capacity for individual process components in the process
ProcessComponent.props located in the $AF_HOME\config directory. This property overrides the default
load capacity. The user can configure the activation threshold in Percentage of load capacity so that the node
can enable the listeners when the number of pending process component requests is less than this configured
value.
TIBCO® Fulfillment Order Management User's Guide
Orchestrator | 27
Order Request Optimization
The Router sends the order request to the Orchestrator with the payload. If the Orchestrator is throttled to
not pick more messages from the router, the message size will grow with the load. EMS Backing store will
grow when you have huge payload in the order request. User can enable a flag so the payload is truncated
from the message. The message contains only the order id in JMS Properties. The node that picks up this
message will query the database to get the corresponding payload, that needs to be processed.
<ConfValue description="Flag to control whether Orchestrator should receive only the
reference or complete xml payload in the submit order request message from omsServer"
isHotDeployable="true" name="Receive OrderRequest by Reference"
propname="com.tibco.fom.orch.receiveOrderRequestByReference" readonly="false"
sinceVersion="2.1" visibility="Basic">
<ConfBool default="true" value="true"/>
</ConfValue>
TIBCO® Fulfillment Order Management User's Guide
28 | Orchestrator
Dead Letter Queue
When a JMS message reaches the maximum retry defined; it is sent to a dead queue configured with the
respective route. In case of time dependencies if time dependency is not executed within the predefined retry
count it is saved into database and will not be picked by Orchestrator. This can be still triggered from JConsole
using JMX interface.
Following are the cases when the dead letter queue is used:
1. JMS Event fails after max retries: JMS messages are routed to Dead letter Queue in JMS. This can be viewed
using JMS Clients. The user can replay it by moving the dead letter queue messages back to source queue
events or by using JMX operations provided to move them to source queue.
2. Timer Events for Time dependent plan items fails after max retries: Time Events that fail after the max
number of retries will be moved to dead letter table in database.
3. Batching Errors: If the batching is configured, database Notifications are batched and executed and
committed in batch. If the transaction fails, each notification from the batch is executed separately and
committed in the database. If it still fails, order id that is related to the notification is marked as batch error
and notification is moved to dead letter table in database. Any other notifications for the same order are
moved to the dead letter table. User can execute them manually using JMX console.
4. Database table structure for dead letter queue:
Table 4: DEAD_LETTER table
Column
Description
SID
ID
DEADLETTERID
Dead Letter ID (Any reference based on the dead letter type) For Time
dependency and Batch, its order id.
DEADLETTERTYPE
Allowed Values are TIME_DEPENDENCY and BATCH.
VALUE
Data blob.
LASTSTATUSCHANGE
Timestamp when record was last updated.
5. Any JMS events on those orders before manually executing these requests are moved to JMS dead letter
queue.
6. Any Timer events on those orders before manually executing these requests are moved to DB dead letter
queue.
7. Following JMX operations are exposed to the user for viewing and executing the dead letter queue.
Operation
Arguments
Expected Results
getDLQDB
A string value indicates dead
letter type. Allowed values:
TIME_DEPENDENCY and
BATCH. It can be an empty string.
Displays list of all dead letters
according to the input parameter. If
input is empty string; it will list out
all the dead letters including batch
errors and time events.
getDLQJMS
A string value indicates dead
Displays list of messages pending on
queue name or it can be an empty respective dead queue provided as
string.
input. If input is empty string; it will
list out all the pending messages on
all Orchestrator related dead queues.
TIBCO® Fulfillment Order Management User's Guide
Orchestrator | 29
Operation
Arguments
Expected Results
runDLQTimeDependencyErrors Two input parameter as string
value.
1. orderID
2. dependencyID
Schedules the respective time event
for execution. If dependencyID is
empty string; schedules all time events
of orderID available in dead letter for
execution.
runDLQBatchErrors
A string value indicates orderID
or it can be an empty string.
Executes further processing of
respective orderID. If input is an
empty string, it will process all
orderIDs available in dead letter.
runOrchJMSDLQ
A string value indicates dead
Processes all messages pending on
queue name or it can be an empty respective dead queue. If input is an
string.
empty string, it will process messages
pending on all dead queues.
The following dead queues are supported by JMX operations to move back the messages to its source
destination:
Dead Queue Name
Description
tibco.aff.orchestrator.order.submit.dead
Submit Order Request dead queue
tibco.aff.orchestrator.planItem.execute.reply.dead
PlanItem execution response dead queue
tibco.aff.orchestrator.planItem.milestone.notify.request.dead MilestoneNotifyRequest from process components
to Orchestrator dead queue
tibco.aff.orchestrator.order.withdraw.dead
Withdraw Order dead queue
tibco.aff.orchestrator.order.activate.dead
Activate order request dead queue
tibco.aff.orchestrator.planItem.suspend.reply.dead
PlanItem suspend response dead queue
tibco.aff.orchestrator.order.suspend.dead
Suspend order request dead queue
tibco.aff.orchestrator.cache.cleanup.dead
Cache cleanup dead queue
tibco.aff.orchestrator.provider.order.feasibility.reply.dead External Feasibility reply dead queue
tibco.aff.orchestrator.provider.order.prequal.failed.reply.dead External PreQualificationFailed reply dead queue
tibco.aff.orchestrator.provider.planItem.failed.reply.dead PlanItem error handler response dead queue
tibco.aff.orchestrator.planItem.externalDependency PlanItem External Dependency Release
release.request.dead
Request dead queue
tibco.aff.orchestrator.cache.addEvent.dead
Time dependency add event dead queue
TIBCO® Fulfillment Order Management User's Guide
30 | Orchestrator
External Dependency
External dependency is a dependency type that waits for notification from an external system by an event
before it is satisfied. This dependency is specified by two attributes namely:
1. event name: Name of the event that satisfies this dependency.
2. event id: Unique identifier of the event name that satisfies this dependency.
The plan development/enrichment module which adds an external dependency to the milestone of a plan
item has to ensure that the combination of event name and event id is unique across all the orders. A unique
dependency id is generated according to the two attributes mentioned above and saved in OMS database.
In order to satisfy a particular dependency, an external dependency request has to be sent by the process
component to Orchestrator using the following schema on the queue
tibco.aff.orchestrator.planItem.externalDependency.release.request. The process component
may choose to add 'originator' as a JMS message property with value as 'NodeID' if known to indicate to
OMS the node from which this order is being processed.
Figure 2: External Dependency Release request parameters in an XML form
A hook has been provided to enrich the plan returned by OPD by adding external dependencies if needed.
This can be achieved by implementing an interface
com.tibco.aff.oms.server.jms.orch.custom.OrchestratorPlanEnricher present in omsCommon-1.0.jar
located in $AF_HOME/lib. The interface defines a single method enrichPlan() which needs to be implemented.
The implementation should be compiled with omsCommon-1.0.jar in the classpath. The compiled
implementation should then be added to the classpath of omsServer.war and the fully qualified name of the
implementer class should be added to the com.tibco.fom.orch.enrich.CustomOrchPlanEnricher property
in Configurator. In order to complete the process, omsServer.war should be re-deployed in Tomcat. .
Steps To Enable Enrichment
1. Create a new java project in IDE with omsCommon-1.0.jar in build path.
2. Implement an interface with name
com.tibco.aff.oms.server.jms.orch.custom.OrchestratorPlanEnricher.
3. Build the project and include the .class or jar file in WEB-INF/classes(.class) or WEB-INF/lib(jar)
folder of omsServer.war.
4. Configure the implemented class name through Configurator.
TIBCO® Fulfillment Order Management User's Guide
Orchestrator | 31
Figure 3: Enrichment
By default, a blank value is present in the Configurator which indicates no enrichment.
5. Redeploy OMS Server.
A sample do-nothing implementation is included with distribution in omsCommon-1.0.jar present
at $AF_HOME/lib with the name
com.tibco.aff.oms.server.jms.orch.custom.CustomOrchestratorPlanEnricher.
Configuration
There are various configurations that can be modified to change the defaults for external dependencies.
1. The queue on which external dependency release request should be sent.
2. The number of receivers on the external dependency release request queue.
3. PlanItem External Dependency Release Request dead queue.
Logging
1. Successful integration with enrichment class
INFO : Sending plan of ORDER with orderID {} for enrichment to custom class {}.
2. Class configured through Configurator found but invalid implementation
INFO : Custom class {} is not a valid implementation of OrchestratorPlanEnricher.
Skipping plan enrichment for orderID {}.
3. Class configured through Configurator not found.
INFO : Class with name [{}] supplied for custom plan enrichment not found in CLASSPATH.
Skipping plan enrichment for orderID {}.
TIBCO® Fulfillment Order Management User's Guide
32 | Orchestrator
Time Dependency
Time dependency in plan items is satisfied when a certain time period has elapsed, or a certain absolute date
and time has been reached. Time dependencies take the form of an absolute date time and once the time has
reached or passed, then the dependency is considered satisfied.
Time dependencies of a planItem are scheduled to be EXECUTED at the specified absolute time and only
executed once the time is reached. If execution fails then the Orchestrator tries to execute it until maximum
retries (com.tibco.fom.orch.timeDependency.maxRetryCount) is reached. If it fails during max retries then the
Orchestrator puts the order into DEAD LETTER for future reference and the time dependencies will not be
scheduled and not executed by the Orchestrator.
TIBCO® Fulfillment Order Management User's Guide
Orchestrator | 33
Non-Executing Plan Item
A Non-executing plan item does not need to be submitted to a Process Component.
A comma separated string of planFragment ID is defined with property name
com.tibco.fom.orch.nonexecuting.planfragmentID which indicates a planItem having these PlanFragments will
be treated as non-executing planItem.
<ConfValue description="Non Executing Planfragment ID" name="Non Executing Planfragment
ID" propname="com.tibco.fom.orch.nonexecuting.planfragmentID" sinceVersion="2.1"
visibility="Advanced">
<ConfString default="NON_EXECUTING" value="NON_EXECUTING"/>
<ConfValue>
The Orchestrator does not send any notification to process component and it completes the planItem along
with its milestone dependencies.
TIBCO® Fulfillment Order Management User's Guide
34 | Orchestrator
Process Component Destination
Currently, process component notifications are sent to a default destination if there is no owner defined in
the process component or to a destination with owner name if owner is defined in process component. This
destination can be overridden and a new destination can be used as destination for process component
notifications. This can be configured using property com.tibco.fom.orch.overridePlanfragmentDestination. If this
property is set to true then the destination will be picked from ProcessComponent.props file for respective
process component ID. Content of this property file will be loaded when file is modified and the updated
value will be used for sending notifications. This properties file will have destination defined for process
component as follows:
<Process Component ID>.destinationName=<Destination value>
The Destination value is a String.
If there is no destination defined for a process component in file ProcessComponent.props or property
com.tibco.fom.orch.overridePlanfragmentDestination is configured as false then default behavior will be used and
all the process component related notifications will be sent to a predefined queue. If the property is true and
the value is not configured, the default destination is used. The default value is false.
TIBCO® Fulfillment Order Management User's Guide
Orchestrator | 35
Order Types
Fulfillment Order Management supports the following order fulfillment modes:
• Standard New Order Fulfillment
• Partially Completed Order Fulfillment
• Amend Order
• Cancel Order
• Suspend Order
• Activate Order
Standard New Order Fulfillment
Standard new order fulfillment is the process of submitting an order for orchestration which will create a
new execution plan and orchestrate it to completion. This is the normal mode of operation for submitting
new orders to the system.
Partially Completed Order Fulfillment
Partially completed order fulfillment works in a similar manner, except as part of the plan development step
certain plan items are indicated as having previously been completed. The new orchestration is created based
on this information. This will allow migration of partially completed orders from other fulfillment systems
into Orchestrator.
In order for a partial order fulfillment to work, the previous fulfillment system must have suspended execution
of the plan at a location that allows for migration. This will mean pushing orders through to completion of
the currently in progress process component, and then suspending the order once all current in progress
tasks have been completed. A sample scenario is outlined below:
Figure 4: Partially Completed Order Submission - Existing Fulfillment System
TIBCO® Fulfillment Order Management User's Guide
36 | Orchestrator
In the existing fulfillment system a plan is in execution. The plan snapshot occurs while process component
PC_2 is in progress. This plan will be in an inconsistent state and cannot be migrated. Therefore the in progress
process component must be pushed through to completion before migrating the order. At this point PC_2
will be completed and at this point the order will be suspended before PC_3 begins.
Figure 5: Partially Completed Order Submission – Orchestrator Fulfillment System
The partially completed order is submitted to Orchestrator just as a new order. During the callout for plan
development a migration component will analyze the order and determine if it is partially completed or not.
If it’s a new order it will be processed normally. If it’s partially completed then a partial execution plan is
created and returned to Orchestrator. Orchestrator will then set the status of previously completed plan items
to complete so that they do not execute again. Orchestration will then continue at the next steps in the execution
plan when the plan is resumed.
Amend Order
An order amendment is the process of making changes to a previously submitted order. An order can be
amended by sending through the new order with the same orderID and orderRef as the previously submitted
order.
Orders may only be amended in certain lifecycle states.
Amendable
Not Amendable
• Submitted
• Complete
• Feasibility
• Cancelled
• Plan Development
• Withdrawn
• Pre-Qualification Failed
• Execution
• Suspended
• START
• Error-Handler
Amendments prior to creation of a plan take the form of updating the order in the database and then restarting
the order lifecycle back from Submitted. At this point a plan has not been generated and does not need to be
modified. When the fulfillment process reaches the Plan Development step, the updated order as it exists
from the amendment will be used to generate the plan. This applies to order status of Submitted, Feasibility,
Plan Development, and Pre-Qualification Failed.
For amendments that occur after a plan has been created, but while the plan is still Pending, then the order
is updated in the database, the existing plan is discarded and the order starts back from Submitted. This
applies to order status of Execution, but with a plan status of Pending. However, this is a very rare scenario
as the plan immediately goes into EXECUTION state.
TIBCO® Fulfillment Order Management User's Guide
Orchestrator | 37
For amendments that occur after a plan has started executing only certain aspects of an order may be amended.
These are outlined below. 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 may 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.
If the order goes to Pre-Qualification Failed state from OMS due to OPE validation failure, it cannot be
amended.
If an order is amended in Pre-Qualification Failed state, the action of order line in the amendment order
request cannot be CANCEL.
For more information, see Order Amendments.
Suspend and Activate Order
The order can be suspended at any point during the fulfillment process.
1. If the order is in any of the pre-EXECUTION states, it will be suspended immediately.
2. If the order is in EXECUTION state, Orchestrator sends the suspend requests to all the process components
associated to the plan items that are in execution state. These process components may either respond
with an execution suspend response, if they can suspend the processing or execution complete response,
if the can't. Based on the response, the executing plan items will either go into SUSPENDED or COMPLETE
state. Finally, order and plan state will be changed to SUSPENDED.
3. The orders that are in final states such as COMPLETE or CANCELLED or already in SUSPENDED state
cannot be suspended again.
The suspended orders can be activated back into the EXECUTION state so as to proceed ahead with the
fulfillment.
1. If the order was in any of the pre-EXECUTION states before suspension, it will be activated immediately
and processing will carry on further.
2. If the order was in EXECUTION state before suspension, Orchestrator will activate it by sending the
activation requests for all the process components associated with the plan items that were SUSPENDED.
Finally, order and plan state will be changed to EXECUTION.
TIBCO® Fulfillment Order Management User's Guide
38 | Orchestrator
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
fulfillment. This feature is useful when order fulfillment is a short-running process.
The basic function of synchronous submit order web service is to accept a new order request, and return 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 submitted without waiting for Orchestrator
to respond back.
TIBCO® Fulfillment Order Management User's Guide
Orchestrator | 39
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 fulfill a customer order. Execution plans usually specify
how the process components should be arranged to fulfill the order.
An execution plan consists of the following:
• Plan Tasks or Plan Items with an associated process component and action
• Actions
• Dependencies on the plan items
Plan Tasks with Associated Process Components
One or more plan tasks or items comprise an execution plan. Each plan item is created to fulfill a particular
product against a particular action. The process component specified in plan item will be invoked for the
fulfillment.
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
• Custom Actions
A plan task manages a particular item. Each action defines what needs to be done for a particular item. An
action serves as an annotation to make the execution plan more understandable.
Dependencies
Plans are automatically generated by the system based on the product model for a given order.
A dependency can be defined as a relationship between milestones in the plan items. For example, Milestone
B cannot start until Milestone A completes.
For details, see Intermediate Milestones Dependencies on page 106.
TIBCO® Fulfillment Order Management User's Guide
40 | Orchestrator
Order Header
The table below lists the information contained in an order header:
Type
Description
Order Ref ID
A unique identifier 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 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 Fulfillment Order
Management system generates the reference ID and sends in response.
Order ID
Internal ID of the order generated and assigned by OMS.
Status
Current status of an order. For instance, COMPLETE.
Execution Plan
Execution Plan ID.
Required By Date
Indicates the date and time when the order must start fulfillment.
Notes
Notes about the order. Basically this is any additional text that may be supplied
by the summiteer or submitting system.
Subscriber ID
Reference ID of the subscriber.
Customer ID
Used to retrieve the current customer profile and to identify the customer to
other systems interested in the order.
Changed Date
Date when the order is changed.
Execution Status
Execution status of an order. For instance, COMPLETE.
Required On Date
Currently not supported.
Invoice Address
The address to invoice for the order, if different from the customer address.
Delivery Address
The address to deliver the order, if different from the customer address.
Service Level Agreements
(SLA)
This is a list of the identifiers of any service level agreement that applies to a
particular order.
TIBCO® Fulfillment Order Management User's Guide
Orchestrator | 41
Order Line
An Order contains order lines. Each order line has the following information:
Type
Description
Line No
Line no. of an order.
Product ID
The identifier of the specification of the product to be provided.
Inventory ID
Inventory ID.
Action
The action required for the specific product referred to in the order line. You
can enter one of the following actions:
• 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.
• <Custom Action>: Any defined custom action.
Required By Date
Indicates the date and time when the order line must start fulfillment.
Quantity
The number of the product required.
Required On Date
Currently not supported.
Subscriber ID
Reference ID of the subscriber.
Product Version
Version of a particular product.
Link ID
Link reference ID.
Status
The current status of the order. This is automatically filled in and you cannot
amend it. The status changes with the order item’s lifecycle.
Status Changed
The date and time that the order line status last changed. This is automatically
filled in and you cannot amend it. It initially shows the date and time the order
line was created, and is updated to reflect later status changes.
UOM (Unit of
Measurement)
The unit of measure of the product required.
Delivery Address
The address to deliver the order, if different from the customer address.
Characteristics
A list of product characteristics that are supplied as input parameters to the
order to provide additional information to the product specification. For
instance, this may be the color of a mobile telephone.
TIBCO® Fulfillment Order Management User's Guide
42 | Orchestrator
Orchestrator Interfaces
Fulfillment Order Management Orchestrator is the primary fulfillment engine and implemented in a Java
component. Orchestrator requests Fulfillment Order Management AOPD to generate the execution plan for
the order submitted by OMS. On receiving the execution plan from AOPD, it executes the plan tasks for order
fulfillment.
This section provides the details of various interfaces exposed by Orchestrator for external integration.
For process component development, the following two project library files are shipped with the product
under the $AF_HOME/be/projectLibs directory:
1. AF_Orchestrator.projlib - This library is used in the TIBCO BusinessEvents studio projects for BE 5.x
based process component development. It contains the Orchestrator resources. For example, events,
channels/destinations, XML payload schema, JMS connections, JMS application properties, global variables,
and so on.
2.
- This library is used in the TIBCO Designer projects for the
TIBCO BusinessWorks-based process component development and contains simple resources. For example,
XML payload schema, JMS connections, JMS application properties, and global variables.
AF_Orchestrator_ForDesigner.projlib
This project library is used and imported in the AF_TestHarness project.
The XML schema for all the interfaces exposed by Orchestrator are available in the
$AF_HOME/schemas/schema/orchestrator directory.
Feasibility Providers
Overview
Feasibility Provider is a customer-specific implementation that checks whether an order is feasible for
fulfillment. Feasibility might involve network inventory capacity analysis, stock checks, order line validation,
or any other number of checks.
Fulfillment Order Management validation engine (OPE) may be used as part of feasibility checking to
determine if the order has the required order lines to constitute a valid order.
Feasibility checking is an optional step in the fulfillment process within Orchestrator. By disabling feasibility
checking, no Feasibility Provider is required. However, if feasibility is enabled, then a Feasibility Provider
must be available for orders to proceed. Feasibility Providers must conform to the following requirements
in order to be a valid implementation.
Specification
• Receive event messages on a JMS queue.
• Interpret the Feasibility Request event and determine if the order is feasible for fulfillment.
• Create and send a response event on a JMS queue.
• In the response event, specify whether the feasibility check has completed successfully by setting the
completed flag to TRUE if it was able to determine feasibility or FALSE if it was not able to conclude
feasibility.
• In the response event specify whether the order has passed feasibility by setting the passed flag to TRUE
if the order is feasible, or FALSE if it is not feasible.
• In the response event, optionally specify a list of warning or error messages whether the order has passed
feasibility or not.
TIBCO® Fulfillment Order Management User's Guide
Orchestrator | 43
Since the feasibility checking process is a customer-implemented component, the functional specification for
this process is out of scope of this document.
Feasibility Request
Feasibility Request is an event sent by Orchestrator to the Feasibility Provider to request order feasibility
checking. It is an asynchronous request/reply event to a JMS queue that returns a reply to the default reply
queue for Feasibility Response.
If an exception occurs during feasibility checking, then it should be logged to the Feasibility Provider log.
The details of the exception are returned in the response.
Event Type
Asynchronous request event
Queue or
Topic
Queue
Destination
tibco.aff.orchestrator.provider.order.feasibility.request
The event has the following property:
Property
Type
Cardinality Description
originator
String
Optional
The value of the NODE_ID Java property that is set in the
setenv script of the Apache Tomcat instance, which is
running the Orchestrator component. This property is sent
by the Orchestrator in all the outbound JMS messages and
is expected to be mapped back by the external systems
(process components, feasibility providers, pre-qualification
failure handlers, and error handlers) in the corresponding
response messages.
The event has the following payload:
Figure 6: Feasibility Request
The following table lists the details of the elements.
Element
Type
Cardinality Description
businessTransactionID String
Optional
Unique identifier for tracing purposes across function calls.
correlationID
String
Optional
Unique identifier to correlate the request message with a
response message.
orderID
String
Required
Order ID for the order to feasibility check.
orderRequest
Type
Required
Order Request type. See Appendix A for the specification
of this type.
TIBCO® Fulfillment Order Management User's Guide
44 | Orchestrator
Feasibility Response
Feasibility Response is an event sent by Feasibility Provider back to Orchestrator in response to a Feasibility
Request event. It is an asynchronous reply event to a JMS queue.
The response for feasibility has completed and passed flags. Orchestrator will route the order lifecycle based
on the returned value of these flags. The two flags can be used to distinguish between technical and business
exceptions. For example, a failure to complete would generally indicate a technical exception so complete
would be false. A validation failure would indicate a business exception where complete would be true, but
passed would be false.
Completed This flag indicates whether the feasibility call completed. If this is set to true, then the Passed
flag becomes relevant.
Passed
This flag indicates whether the order has passed feasibility.
Based on different scenarios, these flags should be set as follows:
Completed
Passed
Description
Technical Error False
False True
Orchestrator refers the order to the Pre-Qualification Failed
Handler if error handling is enabled for feasibility, or the error
is withdrawn if error handling is not enabled.
Business Error True
False
Orchestrator refers the order to the Pre-Qualification Failed
Handler if error handling is enabled for feasibility, or the error
is withdrawn if error handling is not enabled.
Success
True
True
Processing continues as normal.
Event Type
Asynchronous reply event
Queue or Topic Queue
Destination
tibco.aff.orchestrator.provider.order.feasibility.reply
The event has the following property:
Property
Type
Cardinality Description
originator
String
Optional
The event has the following payload:
TIBCO® Fulfillment Order Management User's Guide
The value of the originator property in the
FeasibilityRequest message, received from the Orchestrator,
which should be mapped and sent back in the response
message.
Orchestrator | 45
Figure 7: Feasibility Response
The following table lists the details of the elements.
Element
Type
Cardinality
Description
businessTransactionID String
Optional
Unique identifier for tracing purposes across function calls.
correlationID
String
Required
Unique identifier to correlate the request message with a
response message. Even though this field is marked as
optional in the response schema, it is required for
Orchestrator to be able to correlate the response with the
correct version of the submitted order. Populate this field
the same as correlationID in the request message.
resultStatus
Type
Required
orderID
String
Required
Order ID for the order that was feasibility checked.
orderRef
String
Required
Order ref for the order that was feasibility checked.
completed
Boolean
Required
Flag indicating whether the feasibility call completed.
passed
Boolean
Required
Flag indicating whether the order has passed feasibility.
message
Type
0-M
Message type. See Appendix A for the specification of this
type. This list of messages will be passed to the
Pre-Qualification Failed Handler if invoked.
Result status type. See Appendix A for the specification of
this type.
Process Components
Overview
A Process Component is the implementation of a series of steps that are required to fulfill a plan item. Process
components should be implemented using any JMS-enabled technology provided they meet the requirements
outlined here. Typically short-lived, automated processes will be implemented in TIBCO BusinessEvents or
TIBCO BusinessWorks, while long-lived and manual processes will be implemented using TIBCO BPM.
These are required components in the architecture.
TIBCO® Fulfillment Order Management User's Guide
46 | Orchestrator
Specification
Process Components must conform to the following requirements in order to be a valid implementation.
1. Receive event messages on a JMS queue.
2. Receive the following event types:
a. Plan Item Execute Request
b. Plan Item Suspend Request
c. Plan Item Activate Request
3. For plan item execute requests, perform a series of tasks that are required to fulfill the product and action
specified in the plan item. Once it has completed, send a plan item execute response.
4. When instructed to do so, halt execution at certain milestones until notified by Orchestrator it may continue.
5. For plan item suspend requests, halt execution of an in-progress process component. This may or may
not be possible so it is valid to send back a plan item execute response if execution completed, or plan
item suspend response if execution was suspended.
6. For plan item activate requests, resume execution of a previously suspended process component. This
resume takes the form of one of the following cases:
a. Resume execution from the point where it was previously suspended.
b. Cancel execution and rollback previously completed tasks.
c. Cancel execution and do not rollback previously completed tasks.
7. Create and send response events on a JMS queue.
8. Respond with the following event types:
a. Plan Item Execute Response
b. Plan Item Suspend Response
Plan Item Execute Request Event
Plan Item Execute Request Event is sent by Orchestrator to a Process Component to request the fulfillment
of a particular plan item. It is received by the Process Component and a series of tasks then executes. It is an
asynchronous event to a JMS queue. The response is another asynchronous event on a different JMS queue.
Event Type
Asynchronous event
Queue or Topic
Queue
Destination
tibco.aff.orchestrator.planItem.execute.request
The destination name tibco.aff.orchestrator.planItem.execute.request is valid only if owner
value is "". Otherwise, the destination would be as follows: (If owner value is defined), the destination
would be tibco.aff.orchestrator.planItem.<ownertype>.execute.request .
For example, if the owner value in the plan fragment model is BPM, the destination would be
tibco.aff.orchestrator.planItem.BPM.execute.request.
The event has the following properties:
Property
Type
Cardinality
Description
processComponentID String
Required
Unique identifier for the Process Component to be
executed.
processComponentName String
Required
Name of the Process Component to be executed. This
is the name as configured in the Process Component
Model for the specified processComponentID. If there
is no model specified then this field is null.
TIBCO® Fulfillment Order Management User's Guide
Orchestrator | 47
processComponentVersion String
Required
Version of the Process Component to be executed. This
is the version as configured in the Process Component
Model for the specified processComponentID. If there
is no model specified then this field is null.
processComponentType String
Required
Type of the Process Component to be executed. This is
the type as configured in the Process Component Model
for the specified processComponentID. If there is no
model specified then this field is null.
processComponentRecordType String
Required
JMSPriority
Integer
Required
It is the standard JMS message priority to be sent in the
outbound message to support order priority.
originator
String
Optional
The value of the NODE_ID Java property that is set in
the setenv script of the Apache Tomcat instance, which
is running the Orchestrator component. This property
is sent by the Orchestrator in all the outbound JMS
messages and is expected to be mapped back by the
external systems (process components, feasibility
providers, pre-qualification failure handlers, and error
handlers) in the corresponding response messages.
It is a class of processComponentType. This is the
processComponentRecordType as configured in the
Process Component Model. If there is no model
specified then this field is null.
The payload specification is as follows:
TIBCO® Fulfillment Order Management User's Guide
48 | Orchestrator
Figure 8: Plan Item Execute Request
The following table lists the details of the elements.
Element
Type
Cardinality Description
businessTransactionID
String
Optional
Unique identifier for tracing purposes across
function calls.
correlationID
String
Optional
Unique identifier to correlate the request message
with a response message.
orderID
String
Required
Internal unique identifier for the order associated
with the plan containing the plan item to execute.
orderRef
String
Required
External unique identifier for the order associated
with the plan containing the plan item to execute.
planID
String
Required
Internal unique identifier for the plan that contains
the plan item to execute.
planItem
Type
Required
Plan item type for the plan item to execute. See
Appendix A for the specification of this type.
sla
Type
Optional
Service level agreement type.
sla/typicalDuration
Long
Required
Typical duration in msec for this execution when
SLAs are implemented in the Process Component.
sla/maximumDuration
Long
Required
Maximum duration in msec for this execution when
SLAs are implemented in the Process Component.
TIBCO® Fulfillment Order Management User's Guide
Orchestrator | 49
waitAtMilestoneID
String
0-M
Milestone ID for a milestone within the Process
Component where execution must wait until notified
by Orchestrator that it should proceed.
notifyAtMilestoneID
String
0-M
MilestoneID for a milestone within the Process
Component where the Process Component must
notify Orchestrator that the milestone has been
passed during execution.
Plan Item Milestone Release Request Event
Plan Item Milestone Release Event is sent by Orchestrator to a Process Component to instruct it to continue
execution when stopped at a particular milestone. It may be possible that this notification will occur before
the Process Component has reached the milestone during execution. Therefore it is necessary for the Process
Component to maintain a state of the milestone at any time during execution. There is no response to this
interface.
Event Type
Asynchronous event
Queue or Topic
Queue
Destination
tibco.aff.orchestrator.planItem.milestone.release.request
The event has the following properties:
Property
Type
Cardinality
Description
processComponentID
String
Required
Unique identifier for the Process Component
to be executed.
processComponentName String
Required
Name of the Process Component to be
executed. This is the name as configured in the
Process Component Model for the specified
processComponentID. If there is no model
specified then this field is null.
processComponentVersion String
Required
Version of the Process Component to be
executed. This is the version as configured in
the Process Component Model for the specified
processComponentID. If there is no model
specified then this field is null.
processComponentType String
Required
Type of the Process Component to be executed.
This is the type as configured in the Process
Component Model for the specified
processComponentID. If there is no model
specified then this field is null.
planID
String
Required
Internal unique identifier for the plan that
contains the plan item with the milestone to be
released.
planItemID
String
Required
Unique identifier for the plan item that contains
the milestone to be released.
milestoneID
String
Required
Unique identifier for the milestone within the
plan item and plan to be released.
TIBCO® Fulfillment Order Management User's Guide
50 | Orchestrator
originator
String
Optional
The value of the NODE_ID Java property that is
set in the setenv script of the Apache Tomcat
instance, which is running the Orchestrator
component. This property is sent by the
Orchestrator in all the outbound JMS messages
and is expected to be mapped back by the
external systems (process components,
feasibility providers, pre-qualification failure
handlers, and error handlers) in the
corresponding response messages.
The payload specification is as follows:
Figure 9: Plan Item Milestone Release Request
Element
Type
Cardinality
Description
businessTransactionID
String
Optional
Unique identifier for
tracing purposes across
function calls.
correlationID
String
Optional
Unique identifier to
correlate the request
message with a response
message.
orderID
String
Required
Internal unique identifier
for the order associated
with the plan containing
the plan item with the
milestone to be released.
orderRef
String
Required
External unique identifier
for the order associated
with the plan containing
the plan item with the
milestone to be released.
planID
String
Required
Internal unique identifier
for the plan that contains
TIBCO® Fulfillment Order Management User's Guide
Orchestrator | 51
the plan item with the
milestone to be released.
planItem
Type
Required
Plan item type for the
plan item with the
milestone to be released.
See Appendix A for the
specification of this type.
milestoneID
String
Required
Unique identifier for the
milestone within the plan
item and plan to be
released.
Plan Item Milestone Notify Request Event
Plan Item Milestone Notify Event is sent by a Process Component to Orchestrator to notify the orchestration
engine that a particular milestone has been passed during execution. This event will enable the Orchestrator
to release the milestone which was waiting on the current milestone that was notified.
Event Type
Asynchronous event
Queue or Topic
Queue
Destination
tibco.aff.orchestrator.planItem.milestone.notify.request
The event has the following property:
Property
Type
Cardinality Description
originator
String
Optional
The value of the originator property in the
PlanItemExecuteRequest message, received from the
Orchestrator, which should be mapped and sent back in
this response message.
The payload specification is as follows:
Figure 10: Plan Item Milestone Notify Request Event
TIBCO® Fulfillment Order Management User's Guide
52 | Orchestrator
Element
Type
Cardinality
Description
businessTransactionID
String
Optional
Unique identifier for tracing
purposes across function calls.
correlationID
String
Optional
Unique identifier to correlate the
request message with a response
message.
orderID
String
Required
Internal unique identifier for the
order associated with the plan
containing the plan item with the
milestone to notify.
orderRef
String
Required
External unique identifier for the
order associated with the plan
containing the plan item with the
milestone to notify.
planID
String
Required
Internal unique identifier for the
plan that contains the plan item
with the milestone to notify.
planItemID
String
Required
Unique identifier for the plan
item within the plan with the
milestone to notify.
milestoneID
String
Required
Unique identifier for the
milestone within the plan item in
the plan to notify.
Plan Item Execute Response Event
Plan Item Execute Response Event is sent by a Process Component as a response to a Plan Item Execute
Request Event or a Plan Item Suspend Event. Orchestrator receives the result and interprets the result
accordingly. It is an asynchronous event to a JMS queue.
The response for Plan Item Execute has success, completed, and cancelled flags. Orchestrator does not take
any action in response to the cancelled flag. However it does route plan items to either Plan Item Internal
Error Handler or External Error Handler Component if either completed or success is set to false. Functionally,
Orchestrator handles both of these the same. Plan Item Failed Handlers may choose to handle the exception
differently depending on a completed or failure status.
The two flags can be used to distinguish between technical and business exceptions. For example, a failure
to complete would generally indicate a technical exception so completed would be false. A validation failure
would indicate a business exception where complete would be true, but success would be false.
Completed
This flag indicates that the Process Component completed. If this is set to true, then the Success
flag becomes relevant. If this is false then the Process Component did not complete and the
Success flag is automatically considered to be false as well.
Success
This flag indicates whether the Process Component was successful. This is only relevant if
the complete flag is set to true.
The possible response scenarios are:
Complete
Passed
TIBCO® Fulfillment Order Management User's Guide
Description
Orchestrator | 53
Technical Error
False
False True
Orchestrator will retry the Process Component call for the
defined number of retries with the defined retry interval. If
the Process Component call continues to fail, then it will refer
the plan item to the Plan Item Failed Handler.
Business Error
True
False
Orchestrator will refer the plan item to the Plan Item Failed
Handler.
Success
True
True
Processing continues as normal.
In addition to the completed and success values, the Plan Item Execute Response Event also allows returning
a cancelled flag. This is only valid if responding to a Plan Item Activate Request Event and it indicates whether
the cancellation was completed successfully whether or not a rollback was requested. The completed and
success values retain the same definitions in the event of an activation request as in an execution request.
The possible response scenarios are:
Execute Request
Cancelled
Description
False
No cancellation occurred.
Activate Request with Rollback True
Cancellation requested with rollback.
Activate Request without
Rollback
Cancellation requested with no rollback.
True
Event Type
Asynchronous event
Queue or Topic
Queue
Destination
tibco.aff.orchestrator.planItem.execute.reply
The event has the following property:
Property
Type
Cardinality Description
originator
String
Optional
The value of the originator property in the
PlanItemExecuteRequest message, received from the
Orchestrator, which should be mapped and sent back in
the response message.
The payload specification is as follows:
TIBCO® Fulfillment Order Management User's Guide
54 | Orchestrator
Figure 11: Plan Item Execute Response
The following table lists the details of the elements.
Element
Type
Cardinality
Description
businessTransactionID String
Optional
Unique identifier for tracing purposes across
function calls.
correlationID
String
Optional
Unique identifier to correlate the request message
with a response message.
resultStatus
Type
Required
Result status type. See Appendix A for the
specification of this type.
orderID
String
Required
Internal unique identifier for the order associated
with the plan containing the plan item to execute.
orderRef
String
Required
External unique identifier for the order associated
with the plan containing the plan item to execute.
planID
String
Required
Internal unique identifier for the plan that contains
the plan item to execute.
planItemID
String
Required
Unique identifier for the plan item within the plan
to be executed.
completed
Boolean
Required
Flag indicating if the Process Component completed
processing.
success
Boolean
Required
Flag indicating if the Process Component completed
successfully.
TIBCO® Fulfillment Order Management User's Guide
Orchestrator | 55
cancelled
Boolean
Required
Flag indicating that the Process Component
successfully cancelled previously completed tasks.
message
Type
0-M
Message type. See Appendix A for the specification
for this type.
typicalSLAViolated Type
Optional
Flag indicating that the execution time of the Process
Component violated the typical SLA duration.
maximumSLAViolated Type
Optional
Flag indicating that the execution time of the Process
Component violated the maximum SLA duration.
Plan Item Suspend Request Event
Plan Item Suspend Request Event is sent by Orchestrator to a Process Component to request suspension of
execution of a particular plan item. It is received by the Process Component which then either suspends
execution or completes execution. It is an asynchronous event to a JMS queue. The response is another
asynchronous event on a different JMS queue.
Event Type
Asynchronous event
Queue or Topic
Queue
Destination
tibco.aff.orchestrator.planItem.suspend.request
The destination name tibco.aff.orchestrator.planItem.suspend.request is valid only if owner
value is "". Otherwise, the destination would be as follows: (If owner value is defined), the destination
would be tibco.aff.orchestrator.planItem.<ownertype>.suspend.request .
For example, if the owner value in the plan fragment model is BPM, the destination would be
tibco.aff.orchestrator.planItem.BPM.suspend.request.
The event has the following properties:
Property
Type
Cardinality Description
processComponentID String
Required
Unique identifier for the Process Component to be executed.
processComponentName String
Required
Name of the Process Component to be executed. This is the
name as configured in the Process Component Model for the
specified processComponentID. If there is no model specified
then this field is null.
processComponentVersion String
Required
Version of the Process Component to be executed. This is the
version as configured in the Process Component Model for the
specified processComponentID. If there is no model specified
then this field is null.
processComponentType String
Required
Type of the Process Component to be executed. This is the type
as configured in the Process Component Model for the specified
processComponentID. If there is no model specified then this
field is null.
processComponentRecordType String
Required
It is a class of processComponentType. This is the
processComponentRecordType as configured in the Process
Component Model. If there is no model specified then this field
is null.
TIBCO® Fulfillment Order Management User's Guide
56 | Orchestrator
JMSPriority
Integer Required
It is the standard JMS message priority to be sent in the
outbound message to support order priority.
originator
String
The value of the NODE_ID Java property that is set in the setenv
script of the Apache Tomcat instance, which is running the
Orchestrator component. This property is sent by the
Orchestrator in all the outbound JMS messages and is expected
to be mapped back by the external systems (process
components, feasibility providers, pre-qualification failure
handlers, and error handlers) in the corresponding response
messages.
Optional
The payload specification is as follows:
Figure 12: Plan Item Suspend Request
The following table lists the details of the elements.
Element
Type
Cardinality Description
businessTransactionID
String
Optional
Unique identifier for tracing purposes across function
calls.
correlationID
String
Optional
Unique identifier to correlate the request message
with a response message.
orderID
String
Required Internal unique identifier for the order associated
with the plan containing the plan item to be
suspended.
orderRef
String
Required External unique identifier for the order associated
with the plan containing the plan item to be
suspended.
planID
String
Required Internal unique identifier for the plan that contains
the plan item to be suspended.
planItem
Type
Required Plan item type for the plan item to be suspended.
See Appendix A for the specification of this type.
TIBCO® Fulfillment Order Management User's Guide
Orchestrator | 57
Plan Item Suspend Response Event
Plan Item Suspend Response Event is sent by a Process Component as a response to a Plan Item Suspend
Request Event. Orchestrator receives the result and interprets the result accordingly. It is an asynchronous
event to a JMS queue.
Event Type
Asynchronous event
Queue or
Topic
Queue
Destination
tibco.aff.orchestrator.planItem.suspend.reply
The event has the following property:
Property
Type
Cardinality Description
originator
String
Optional
The value of the originator property in the
PlanItemSuspendRequest message, received from the
Orchestrator, which should be mapped and sent back in
the response message.
The payload specification is as follows:
Figure 13: Plan Item Suspend Response
The following table lists the details of the elements.
Element
Type
Cardinality
Description
businessTransactionID String
Optional
Unique identifier for tracing purposes across function calls.
correlationID
Optional
Unique identifier to correlate the request message with a
response message.
String
TIBCO® Fulfillment Order Management User's Guide
58 | Orchestrator
resultStatus
Type
Required
Result status type. See Appendix A for the specification of
this type.
orderID
String
Required
Internal unique identifier for the order associated with the
plan containing the plan item to suspend.
orderRef
String
Required
External unique identifier for the order associated with the
plan containing the plan item to suspend.
planID
String
Required
Internal unique identifier for the plan that contains the plan
item to suspend.
planItemID
String
Required
Unique identifier for the plan item within the plan to be
suspended.
completed
Boolean
Required
Flag indicating if the Process Component suspend
completed processing.
success
Boolean
Required
Flag indicating if the Process Component suspend
completed successfully.
Plan Item Activate Request Event
Plan Item Activate Request Event is sent by Orchestrator to a Process Component to request activation of a
previously suspended plan item. It is received by the Process Component which then resumes, cancels with
rollback, or cancels without rollback. It is an asynchronous event to a JMS queue. There is no specific response
to a Plan Item Activate Request Event, however the Process Component is expected to complete processing
and return a Plan Item Execute Response Event as usual.
Event Type
Asynchronous event
Queue or
Topic
Queue
Destination
tibco.aff.orchestrator.planItem.activate.request
The destination name tibco.aff.orchestrator.planItem.activate.request is valid only if owner
value is "". Otherwise, the destination would be as follows: (If owner value is defined), the destination
would be tibco.aff.orchestrator.planItem.<ownertype>.activate.request .
For example, if the owner value in the plan fragment model is BPM, the destination would be
tibco.aff.orchestrator.planItem.BPM.activate.request.
The event has the following properties:
Property
Type
Cardinality
Description
processComponentID
String
Required
Unique identifier for the Process Component to
be executed.
processComponentName
String
Required
Name of the Process Component to be executed.
This is the name as configured in the Process
Component Model for the specified
processComponentID. If there is no model
specified then this field is null.
processComponentVersion String
Required
Version of the Process Component to be executed.
This is the version as configured in the Process
Component Model for the specified
TIBCO® Fulfillment Order Management User's Guide
Orchestrator | 59
processComponentID. If there is no model
specified then this field is null.
processComponentType
String
Required
Type of the Process Component to be executed.
This is the type as configured in the Process
Component Model for the specified
processComponentID. If there is no model
specified then this field is null.
processComponentRecordType String
Required
JMSPriority
Integer
Required
It is the standard JMS message priority to be sent
in the outbound message to support order
priority.
originator
String
Optional
The value of the NODE_ID Java property that is set
in the setenv script of the Apache Tomcat
instance, which is running the Orchestrator
component. This property is sent by the
Orchestrator in all the outbound JMS messages
and is expected to be mapped back by the external
systems (process components, feasibility
providers, pre-qualification failure handlers, and
error handlers) in the corresponding response
messages.
It is a class of processComponentType. This is the
processComponentRecordType as configured in
the Process Component Model. If there is no
model specified then this field is null.
The payload specification is as follows:
Figure 14: Plan Item Activate Request
The following table lists the details of the elements.
TIBCO® Fulfillment Order Management User's Guide
60 | Orchestrator
Element
Type
Cardinality
Description
businessTransactionID
String
Optional
Unique identifier for tracing purposes across
function calls.
correlationID
String
Optional
Unique identifier to correlate the request
message with a response message.
orderID
String
Required
Internal unique identifier for the order
associated with the plan containing the plan
item to activate.
orderRef
String
Required
External unique identifier for the order
associated with the plan containing the plan
item to activate.
planID
String
Required
Internal unique identifier for the plan that
contains the plan item to activate.
planItem
Type
Required
Plan item type for the plan item to activate. See
Appendix A for the specification of this type.
resumeExecution
Type
Required,
Choice
Flag indicating that the Process Component
should resume execution from the point where
it was previously suspended.
cancelAndRollback
Type
Required,
Choice
Flag indicating that the Process Component
should cancel execution and roll back
previously completed tasks.
cancelWithNoRollback
Type
Required,
Choice
Flag indicating that the Process Component
should cancel execution and not roll back
previously completed tasks.
Pre-qualification Failed Handlers
Overview
A Pre-Qualification Failed Handler is a customer-implemented component used to manage failed feasibility
and plan development steps in Orchestrator. During the fulfillment process, Orchestrator would optionally
call out to a Feasibility Provider and always call out to a Plan Development Provider.
The Feasibility Provider analyzes the order to determine if it can be fulfilled. If it indicates that the order
cannot be fulfilled, then the fulfillment process cannot proceed. The order may be referred to the
Pre-Qualification Failed Handler for manual intervention if feasibility error handling is enabled.
The Plan Development Provider designs a plan from the order. If a plan cannot be designed then the fulfillment
process cannot proceed and the order may be referred to the Pre-Qualification Failed Handler for manual
intervention if OPD error handling is enabled.
Pre-Qualification Failed Handler is an optional component in the architecture. Customers may choose to
implement full error handling within the Feasibility Provider and the Plan Development Provider. In that
case it is not valid to return anything back to Orchestrator other than passed in the case of feasibility and
success in the case of plan development. If anything else is returned to Orchestrator there is no handler to
process the result and the plan remains either in feasibility or OPD state.
Specification
Pre-Qualification Failed Handlers must conform to the following requirements in order to be a valid
implementation.
TIBCO® Fulfillment Order Management User's Guide
Orchestrator | 61
1. Receive event messages on a JMS queue.
2. Interpret the Pre-Qualification Failed Request event and determine how best to route the failed order for
further processing.
3. If necessary, distinguish between feasibility and plan development failures and direct the order to the
correct handling component.
4. Create and send a response event on a JMS queue.
5. In the response event specify one of three possible actions that Orchestrator is to take in response to the
error: resubmit, retry, or withdraw.
The three actions that can be specified are as follows:
Resubmit
The Pre-Qualification Failed Handler sends back a new orderRequest that Orchestrator resubmits
automatically. This is handled as a pre-execution order amendment and execution begins from
Submitted state. An audit history of the original order is maintained in the Transient Data Store.
In order to resubmit, the orderID and orderRef in the new order must match that of the original
order.
Retry
Orchestrator resubmits the order to either the Feasibility Provider or the Plan Development
Provider as it was originally submitted. If this new call fails, the order is sent back to the
Pre-Qualification Failed Handler again.
Withdraw The order will be withdrawn from Orchestrator and not be fulfilled. It is deleted from the engine
and Transient Data Store.
The details of the Pre-Qualification Failed Handler is left as a customer-specific implementation. An example
of a handler could be the following:
1. Receive a Pre-Qualification Failed Handler Request event messages on a JMS queue by a BusinessWorks
process.
2. BusinessWorks starts a process instance in iProcess.
3. The iProcess process model creates a manual task and displays a form in a work queue for operations
support. The form displays the order as well as the details of the failure.
4. Operations support reviews the task and chooses one of the following options:
a. Make changes to the order that allows the order to pass feasibility and plan development. The order
should be resubmitted.
b. Update configurations in back-end systems or product catalogue that allows the order to pass feasibility
and plan development. The order may then be retried.
c. Determine the order is invalid and withdraw the order.
5. The task is completed.
6. iProcess then invokes a BusinessWorks service that creates the Pre-Qualification Failed Handler Response
event, and populates the event with the appropriate information and flags the response to resubmit, retry,
or withdraw as appropriate. This event is then sent on a JMS queue to Orchestrator. The iProcess procedure
then terminates.
7. Orchestrator receives the Pre-Qualification Failed Handler Response and processes it accordingly.
Pre-Qualification Failed Request Event
Pre-Qualification Failed Request Event is sent by Orchestrator in response to a failed feasibility or plan
development call. It is received by the Pre-Qualification Failed Handler for manual processing. It is an
asynchronous event to a JMS queue. The response is another asynchronous event on a different JMS queue.
Event Type
Asynchronous event
Queue or Topic Queue
Destination
tibco.aff.orchestrator.provider.order.prequal.failed.request
TIBCO® Fulfillment Order Management User's Guide
62 | Orchestrator
The event has the following property:
Property
Type
Cardinality Description
originator
String
Optional
The value of the NODE_ID Java property that is set in the
setenv script of the Apache Tomcat instance, which is
running the Orchestrator component. This property is sent
by the Orchestrator in all the outbound JMS messages and
is expected to be mapped back by the external systems
(process components, feasibility providers, pre-qualification
failure handlers, and error handlers) in the corresponding
response messages.
The event has the following payload:
Figure 15: Pre-Qualification Failed Request
The following table lists the details of the elements.
Element
Type
Cardinality
Description
businessTransactionID String
Optional
Unique identifier for tracing purposes across function
calls.
correlationID
String
Optional
Unique identifier to correlate the request message with
a response message.
orderID
String
Required
Order ID for the order that failed feasibility or plan
development.
orderRequest
Type
Required
Order Request type for the order that failed feasibility
or plan development. See Appendix A for the
specification of this type.
feasibilityFailed
Type
Required, Choice Flag indicating that this failure was due to a feasibility
failure.
opdFailed
Type
Required, Choice Flag indicating that this failure was due to a plan
development failure.
message
Type
0-M
TIBCO® Fulfillment Order Management User's Guide
Message type. See Appendix A for the specification of
this type. This will be any list of messages passed back
from the Feasibility Provider or the Plan Development
Provider.
Orchestrator | 63
Pre-qualification Failed Response Event
Pre-Qualification Failed Response Event is sent by Pre-Qualification Failed Handler as a response to the failed
feasibility or plan development step. Orchestrator receives the result and interprets the result accordingly.
It is an asynchronous event to a JMS queue.
Event Type
Asynchronous event
Queue or Topic Queue
Destination
tibco.aff.orchestrator.provider.order.prequal.failed.reply
The event has the following property:
Property
Type
Cardinality Description
originator
String
Optional
The value of the originator property in the
Pre-QualificationFailedRequest message, received from
the Orchestrator, which should be mapped and sent back
in the response message.
The event has the following payload:
Figure 16: Pre-qualification Failed Response
The following table lists the details of the elements.
Element
Type
Cardinality
Description
businessTransactionID String
Optional
Unique identifier for tracing purposes across
function calls.
correlationID
Required
Unique identifier to correlate the request message
with a response message. Even though this field
is marked as optional in the response schema, it
is required for Orchestrator to be able to correlate
the response with the correct version of the
String
TIBCO® Fulfillment Order Management User's Guide
64 | Orchestrator
submitted order. Populate this field the same as
correlationID in the request message.
orderID
String
Required
Internal unique identifier for the order that failed
feasibility or plan development.
orderRef
String
Required
External unique identifier for the order that failed
feasibility or plan development.
withdraw
Type
Required, Choice
Flag indicating that the order should be
withdrawn.
retryFeasibility
Type
Required, Choice
Flag indicating that the order should retry
feasibility without any changes. This response
may be made in cases where the request was for
either feasibility or plan development failure.
retryOPD
Type
Required, Choice
Flag indicating that the order should retry plan
development without any changes. This response
may be made in cases where the request was for
plan development failure. Technically there is no
restriction on doing so in the case of a feasibility
failure, but functionally it does not make sense
to do so.
orderRequest
Type
Required, Choice
Order request type. See Appendix A for the
specification of this type. This is provided in the
case of an order resubmit.
message
Type
0-M
Message type. See Appendix A for the
specification of this type. If populated, this list of
messages will be returned in any Submit Order
Response message occurring after the call to the
PreQualification Failed Handler occurred.
Plan Item External Error Handlers
Overview
Plan Item External Error Handler is a customer-implemented component used to manage failed plan items.
During fulfillment, the Orchestrator requests plan item execution from a Process Component. When execution
completes, the Process Component may specify one of three result conditions:
• Execution completed successfully
• Execution completed, but with error
• Execution did not complete
Successful execution results in the plan item being flagged as Complete and execution continuing with the
next items in the plan.
Error or incomplete execution means that the plan item has not been successfully completed and therefore
the next items in the plan should not begin execution until the conditions that caused the failure are rectified.
Orchestrator does not distinguish between an incomplete execution and an error response when determining
how to handle the failed plan item. Both are handled the same by invoking the Plan Item Error Handler and
indicating which failure mode returned. The semantics of how to determine whether a Process Component
is incomplete or in error is left to a customer-specific interpretation and implementation. The implementation
between Process Components and the Plan Item Error Handler should be consistent.
TIBCO® Fulfillment Order Management User's Guide
Orchestrator | 65
Plan Item Error Handler is an optional component in the architecture. Customers may choose to implement
full error handling within the Process Component. In that case it is not valid to return anything back to
Orchestrator other than success. If anything else is returned to Orchestrator, there would be no handler to
process the result and the plan remains in an execution state without progressing beyond the failed plan
item.
Specification
Plan Item Error Handlers must conform to the following requirements in order to be a valid implementation.
1. Receive event messages on a JMS queue.
2. Interpret the Plan Item Failed Request event and determine how best to route the failed plan item for
further processing.
3. If necessary, distinguish between incomplete execution and error response execution and interpret the
Error Handler field in the Plan Item Failed Request and direct the plan item to the correct handling
component.
4. Create and send a response event on a JMS queue.
5. In the response event, specify one of three possible actions that Orchestrator is to take in response to the
reply: retry, resume, or complete.
The three actions that can be specified are as follows:
Retry
The plan item is resubmitted to the Process Component to start over from the beginning. This
occurs immediately upon receipt of the Plan Item Failed Response event as all dependencies
have been previously satisfied. The Process Component is notified to re-execute the plan item
through a Plan Item Execute Request event. If Orchestrator has been automatically set up to retry
failed process components, and this retry fails as well, the retry count is not reset to zero. In other
words, if the retry from a Plan Item Failed Handler response fails, then that failure is immediately
redirected back to the Plan Item Failed Handler for processing again as a new failed plan item,
and not automatically retried further.
Resume
The plan item is resumed in the Process Component from the point of failure. The implementation
details of this are left for Process Component design. However it is conceivable that the Process
Component may choose to handle a resume the same as a full retry if it is not functionally possible
to resume execution from the point of failure. The Process Component is notified to resume the
plan item through a Plan Item Activate event.
Complete The plan item is considered to be completed and not resubmitted to the Process Component.
Orchestrator marks the plan item as Complete and processing continues. Any dependencies on
the newly Completed plan item is evaluated and further plan items triggered as in the normal
execution.
The details of the Plan Item Failed Handler is left as a customer-specific implementation. An example of a
handler could be the following:
1. Receive a Plan Item Failed Handler Request event message on a JMS queue by a BusinessWorks process.
2. BusinessWorks starts a process instance in iProcess.
3. The iProcess process model makes a service call out to Transient Data Store to retrieve the order.
4. The iProcess process model creates a manual task and displays a form in a work queue for operations
support. The form displays the order as well as the details of the failure.
5. Operations support reviews the task and chooses one of the following options:
a. Make changes to the order which allow the order to process successfully in the Process Component.
The changed order is then saved in TDS and the plan item may be retried or resumed.
b. Make changes to back-end systems that allow the order to process successfully in the Process
Component. The plan item may be retried or resumed.
c. Implement the required functionality for the plan item manually in the back-end systems. The plan
item may be completed.
TIBCO® Fulfillment Order Management User's Guide
66 | Orchestrator
6. iProcess then invokes a BusinessWorks service that creates the Plan Item Failed Handler Response event,
populates the event with the appropriate information, and flags the plan item to complete, retry, or resume.
This event is then sent on a JMS queue to Orchestrator.
7. Orchestrator receives the Plan Item Failed Handler Response and processes it accordingly.
Plan Item Failed Request Event
Plan Item Failed Request Event is sent by Orchestrator in response to a failed plan item. It is received by the
Plan Item Failed Handler for manual processing. It is an asynchronous event to a JMS queue. The response
is another asynchronous event on a different JMS queue.
Event Type
Asynchronous event
Queue or
Topic
Queue
Destination
tibco.aff.orchestrator.provider.planItem.failed.request
The event has the following property:
Property
Type
Cardinality Description
originator
String
Optional
The value of the NODE_ID Java property that is set in the
setenv script of the Apache Tomcat instance, which is
running the Orchestrator component. This property is sent
by the Orchestrator in all the outbound JMS messages and
is expected to be mapped back by the external systems
(process components, feasibility providers, pre-qualification
failure handlers, and error handlers) in the corresponding
response messages.
The event has the following payload:
Figure 17: Plan Item Failed Request
The following table lists the details of the elements.
TIBCO® Fulfillment Order Management User's Guide
Orchestrator | 67
Element
Type
Cardinality
Description
businessTransactionID String
Optional
Unique identifier for tracing purposes across
function calls.
correlationID
String
Optional
Unique identifier to correlate the request message
with a response message.
orderID
String
Required
Internal unique identifier for the order associated
with the plan containing the failed plan item.
orderRef
String
Required
External unique identifier for the order associated
with the plan containing the failed plan item.
planID
String
Required
Internal unique identifier for the plan that contains
the failed plan item.
planItem
Type
Required
Plan item type for the plan item that failed. See
Appendix A for the specification of this type.
errorHandler
String
Required
Name of the error handler to invoke for this failed
plan item. This value is either populated from the
Process Component Model for the Process
Component if it exists or with the default error
handler from the Orchestrator configuration.
message
Type
0-M
Message type. See Appendix A for the specification
of this type. This is the list of messages as returned
in the Plan Item Execute Response Event.
Plan Item Failed Response Event
Plan Item Failed Response Event is sent by Plan Item Failed Handler as a response to the failed plan item.
Orchestrator receives the result and interprets the result accordingly. It is an asynchronous event to a JMS
queue.
Event Type
Asynchronous event
Queue or Topic Queue
Destination
tibco.aff.orchestrator.provider.planItem.failed.reply
The event has the following property:
Property
Type
Cardinality Description
originator
String
Optional
The value of the originator property in the
PlanItemFailedRequest message, received from the
Orchestrator, which should be mapped and sent back in
the response message.
The event has the following payload:
TIBCO® Fulfillment Order Management User's Guide
68 | Orchestrator
Figure 18: Plan Item Failed Response
The following table lists the details of the elements.
Element
Type
Cardinality Description
businessTransactionID String
Optional
Unique identifier for tracing purposes across function calls.
correlationID
String
Required
Unique identifier to correlate the request message with a
response message. Even though this field is marked as optional
in the response schema, it is required for Orchestrator to be
able to correlate the response with the correct version of the
submitted order. Populate this field the same as correlationID
in the request message.
orderID
String
Required
Internal unique identifier for the order associated with the plan
containing the failed plan item.
orderRef
String
Required
External unique identifier for the order associated with the
plan containing the failed plan item.
planID
String
Required
Internal unique identifier for the plan that contains the failed
plan item.
planItemID
String
Required
Unique identifier for the plan item within the plan that failed.
retry
Type
Required,
Choice
Flag indicating that the plan item should be retried.
resume
Type
Required,
Choice
Flag indicating that the plan item should be resumed from the
point of failure.
complete
Type
Required,
Choice
Flag indicating that the plan item should be marked as
Complete and execution continue.
message
Type
0-M
Message type. See Appendix A for the specification of this
type. If populated, this list of messages will be returned in any
TIBCO® Fulfillment Order Management User's Guide
Orchestrator | 69
Submit Order Response message occurring after the call to the
Plan Item Failed Handler occurred.
TIBCO® Fulfillment Order Management User's Guide
Chapter
2
Automated Order Plan Development
®
This section describes the functions of TIBCO Fulfillment Order Management Automated Order Plan Development
feature.
Topics
•
•
•
•
•
Overview
Architecture
Model Deployment
Configuration
Features
TIBCO® Fulfillment Order Management User's Guide
72 | Automated Order Plan Development
Overview
Basic Automated Order Plan Development is the capability to create custom order plans that fulfill an order,
taking into account the specifications 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 specification for
each order line is extracted from a product catalog by the decomposition component.
The product specification is required to create execution plan fragments. These execution Plan Fragmentdefine
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® Fulfillment Order Management User's Guide
Automated Order Plan Development | 73
Architecture
Starting with FOM version 2.1.0, AOPD is a Java based component. The AOPD component is, by default,
colocated with OMS. This simplifies the deployment and administration. It also improves the performance.
Deployment
AOPD can be deployed in different ways:
• Colocated
• Standalone
• Custom
Colocated Mode
In colocated mode, the AOPD component is deployed on the same application server than OMS. This is the
default mode, and it does not require any separate deployment. The file omsServer.war in
$AF_HOME/apache-tomcat-[version]/webapps contains both the OMS component and the AOPD component.
Even though AOPD is colocated on the same application server, most of the communication are made through
EMS.
Figure 19: AOPD in Colocated Mode
To configure FOM to use AOPD in colocated mode, set:
com.tibco.fom.aopd.deployMode=AOPD_colocated
in the file $AF_HOME/config/profiles.properties. It tells FOM to use the AOPD implementation that is
in omsServer.war.
Standalone Mode
In standalone mode, AOPD is not running on the same application server than OMS. AOPD can run on another
application server, either on the same machine or a separate machine.
To configure FOM to use AOPD in standalone mode, set:
com.tibco.fom.aopd.deployMode=AOPD_standalone
in the file $AF_HOME/config/profiles.properties. It tells FOM to not use the AOPD implementation that
is in omsServer.war.
Using shipped AOPD implementation
The FOM installation provides the AOPD implementation in a war file, ready to be deployed in an application
server. It can be used to setup another application server, either on the same machine (vertical scaling), or a
different machine (horizontal scaling).
TIBCO® Fulfillment Order Management User's Guide
74 | Automated Order Plan Development
Figure 20: AOPD in Standalone Mode (Vertical Scaling)
Figure 21: AOPD in Standalone Mode (Horizontal Scaling)
The file is located $AF_HOME/oms/webapps/aopd.war. The file can be deployed in any application server.
The omsServer.war already contains an implementation of AOPD, so there is no need to deploy
aopd.war in the same application server. The file aopd.war is provided for convenience, if user wants
to scale horizontally or vertically.
Using custom AOPD implementation
It is also possible to create a custom AOPD component, as long as it fulfills the EMS interface with the other
components. In a same way, the custom AOPD can be deployed, either on the same machine, or a different
machine.
To configure FOM to use AOPD in custom mode, set:
com.tibco.fom.aopd.deployMode=AOPD_custom
in the file $AF_HOME/config/profiles.properties. It tells FOM to not use the AOPD implementation that
is in omsServer.war.
Figure 22: Custom AOPD in Standalone Mode (Vertical Scaling)
TIBCO® Fulfillment Order Management User's Guide
Automated Order Plan Development | 75
Figure 23: Custom AOPD in Standalone Mode (Horizontal Scaling)
TIBCO® Fulfillment Order Management User's Guide
76 | Automated Order Plan Development
Model Deployment
Two type of models, Product and Action, have to be loaded in AOPD. They are loaded in AOPD using EMS.
AOPD has two listeners, one for each model. The Action and Product model listeners are active whether
AOPD is deployed in standalone and colocated mode.
Additional listeners, Execution Plan and Amendment are active when AOPD is in standalone mode. In
colocated mode, there is direct API call from AFI to AOPD bypassing the queues and listeners
configuration for Execution plan and Amendment plan requests.
AOPD stores Action and Product models into the OMS database (data_model table) for both online and
offline loading. AOPD, on startup, loads Action and Product models directly from the OMS database.
If something gets published online, AOPD gets the latest updates on Action and Product model listeners. If
an existing product is loaded again then it is first updated in OMS database, deleted from local repository
and then the incoming product model is loaded in AOPD.
TIBCO® Fulfillment Order Management User's Guide
Automated Order Plan Development | 77
Configuration
AOPD configuration is stored in different files in the directory $AF_HOME/config. The files can be either
manually edited or accessed through the Web Configurator.
The AOPD configuration files are the following:
Main Configuration
The main AOPD configuration is stored in the file $AF_HOME/config/ConfigValues_AOPD.xml.
Parameter Name
Description
AffinityUDFNameMerge
Merges affinity UDF name (default: false)
CharacterisitcsWithoutAffinityPostfix To not merge certain UDFs during Affinity Sequencing, those UDFs
should be added as CSV in the variable (default: "")
SkipItemSequence
Within AOPD, if the sequence is -1, it will skip the product and all its
mandatory children in the Execution Plan (default: -1)
MergeAffinityItemDescription
Merges affinity item description (default: false)
HierarchySingleUse
Uses unconditional removal of child product (default: false)
EnableAffinityUDFParent
Enables affinity UDF parent (default: false)
UDFList
List of internal UDFs to be skipped for affinity merging (default:
"EPMR_ACTION_PROVIDE, EPMR_ACTION_UPDATE,
EPMR_ACTION_CEASE, EPMR_ACTION_WITHDRAW,
COMPENSATE_PROVIDE, COMPENSATE_UPDATE,
COMPENSATE_CEASE")
EnableBiDirectionalLinkID
Enables extended behavior for PDO/MDO and LinkID mapping
(default: false)
AllowMultipleRequiredProducts
Allows Multiple Required Products for the same link ID (default: false)
IgnorePDOFirstChildDependency Ignores First child dependency for source product in PDO relationship
(default: false)
HandleConflict
Configurable handling for PCO conflict (default: "Apply")
ABDProductOrderline
Include only the orderline for attribute based decomposition
(default:false)
ABDIncludeCharacteristics
Include plan item udfs for evaluating attribute based decomposition
(default:false)
CompensateRestartForNoEPMRChar Enables COMPENSATE and RESTART behavior in case of the required
EPMR characteristic that is not present in the product model.
EnableDateShiftCompRedo
Enables the backward compatibility for Date Shift amendment to
generate comp redo tasks (default: false)
EnableModificationIdentifyingAttribute Enables the backward compatibility for udf change amendment using
MODIFICATION_IDENTIFYING_ATTR (default: false)
NoDependencyInCOMPPlanItems Enables the backward compatibility of NO dependency in the
COMPENSATE plan item on the existing plan item being cancelled.
TIBCO® Fulfillment Order Management User's Guide
78 | Automated Order Plan Development
Logs
The AOPD logs are configured in the file $AF_HOME/config/AOPDLog4j.xml.
Integration with Orchestrator
The integration between AOPD and Orchestrator is configured in the file
$AF_HOME/config/ConfigValues_OMS.xml, in the category called Orchestrator-AOPD Integration Configuration.
This configuration can be accessed and modified using the Web Configurator.
Parameter Name
Description
OPDRequest from Orchestrator
receiver queue
Name of the OPDRequest from Orchestrator receiver queue (default:
tibco.aff.orchestrator.provider.order.opd.request)
OPDRequest from Orchestrator
receiver count
Number of the OPDRequest from Orchestrator receiver (default: 3)
ExecutionPlanNewRequest to
AOPD sender queue
Name of the ExecutionPlanNewRequest to AOPD sender queue (default:
tibco.aff.ocv.events.plan.new.request)
ExecutionPlanAmendRequest to
AOPD sender queue
Name of the ExecutionPlanAmendRequest to AOPD sender queue
(default: tibco.aff.ocv.events.plan.amend.request)
ExecutionPlanNewResponse from Name of the ExecutionPlanNewResponse from AOPD receiver queue
AOPD receiver queue
(default: tibco.aff.ocv.events.newplan.reply)
ExecutionPlanNewResponse from Number of the ExecutionPlanNewResponse from AOPD receiver
AOPD receiver count
(default: 3)
ExecutionPlanAmendResponse
from AOPD receiver queue
Name of the ExecutionPlanAmendResponse from AOPD receiver queue
(default: tibco.aff.ocv.events.amendplan.reply)
ExecutionPlanAmendResponse
from AOPD receiver count
Number of the ExecutionPlanAmendResponse from AOPD receiver
(default: 3)
OPDResponse to Orchestrator
sender queue
Name of the OPDResponse to Orchestrator sender queue (default:
tibco.aff.orchestrator.provider.order.opd.reply)
TIBCO® Fulfillment Order Management User's Guide
Automated Order Plan Development | 79
Features
Autoprovision
Autoprovision is a condition that determines the relationship between a parent product and a child product.
The relationship can be either be Static or Dynamic. Autoprovision flag 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 flag is TRUE between B and P1.
• AUTOPROVISION flag 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 fulfillment is known as Implicit Fulfillment.
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 field 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 specified as specific order lines within the order. The bundle is also specified 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 required products will be validated as part of validation to ensure the basket or the customer image has
the required product before any decomposition occurs.
It is possible to reuse the common products having Autoprovision=false using LinkParentID and
LinkedParentID UDFs in the orderline. The LinkParentID-LinkedParentID and LinkID UDFs are used to
define PCO-tree, although the LinkParentID-LinkedParentID UDF has the higher priority.
• Link child to parent based on LinkParentID-LinkedParentID if present. Else,
• Link child to parent based on LinkID if present. Else,
• Link child to parent randomly.
For example, consider the following product model:
T-COM Wireline --> (PCO) Additional Voice Service(autoproivision=false)
TIBCO® Fulfillment Order Management User's Guide
80 | Automated Order Plan Development
T-COM Wireline --> (PCO) Tarrif1(autoproivision=false)
Additional Voice Service --> (PCO) Tarrif1(autoproivision=false)
Therefore, the order can be:
Orderline Number
Product
LinkParentID
LinkedParentID
1
T-COM Wireline
T-COM Wireline
2
Additional Voice Service
Additional Voice
Service
T-Com Wireline
3
Tarrif1
Tarrif1
Additional Voice
Service
4
Tarrif1
Tarrif1
T-Com Wireline
The LinkParentID-LinkedParentID UDFs are added for orderline number 2 in the following format to add
dependency between OrderLine 2 and OrderLine 3:
<ord1:udf>
<ord1:name>LinkParentID</ord1:name>
<ord1:value>Tarrif1</ord1:value>
</ord1:udf>
<ord1:udf>
<ord1:name>LinkedParentID</ord1:name>
<ord1:value>Additional Voice Service</ord1:value>
</ord1:udf>
This change is backward-compatible. To use the LinkID functionality, do not add the
LinkParentID-LinkedParentID UDFs in the orderline.
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.
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 specified in order is in future.
Time dependency defines the absolute time when the particular plan fragment starts execution. It is calculated
on the basis of requiredByDate present in either the Orderheader or OrderLine. The expected behaviour for
the required by date is as follows
1. If requiredByDate is set on the order level, the start time dependency applies to all plan items with no
leading dependencies
2. If requiredByDate is set on the order line level only, the start time dependency applies to plan items for
that order line which have no leading dependency
3. If requiredByDate is set on the order header level and on the order line level, the following behaviour
applies:
a. If requiredByDate in Order Header is later than requiredByDate in line item, then the start time used
is the one at order level
b. If requiredByDate in Order Header is earlier than requiredByDate in line item, then the start time used
is the one at order line level.
TIBCO® Fulfillment Order Management User's Guide
Automated Order Plan Development | 81
RequiredOnDate is no longer used or supported.
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 Defined 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.
Custom Action Based Product Decomposition
The custom action provides flexible way to define products and product fulfillment by allowing product
decomposition and characteristic list inclusion. The ProductComprisedOf (henceforth, referred to as PCO)
relationship enables you to model complex product hierarchies. This allows a product modeler to model
specific product decomposition according to the specified action.
Irrespective of an action, all the PCO or Characteristic relationships are valid.
The following table describes the custom action for the PCO and Characteristic relationships:
ProductComprisedOf (PCO)
If
PCO.ActionID=null
If
PCO.ActionID=not
null
The child product is always a
part of the decomposition
during decomposition
Characteristic (C)
If C.ActionID=null The characteristic is always
included as planItem UDFs
The child product is only added If C.ActionID=not
if the following order action is null
specified during
decomposition:
The characteristic is included if
the following order action is
specified during
decomposition:
order Action = the ActionID
order Action = ActionID
Scenario for the Custom Action Based Product Decomposition
The following table describes how a custom action impacts the product decomposition:
This scenario is applicable for characteristic list inclusion based on custom action.
Data Model Configuration
Order
Action repository has record with ID OL=B(PROVIDE)
as HomeMove and recordtype as
PROVIDE. Product B has PCO
relationship with P1, P2, P3 with
autoprovision=true
P1.PCO.ActionID=null
Plan
There are three planItems:
• B
• P1
• P2
B depends on P1 & P2
TIBCO® Fulfillment Order Management User's Guide
82 | Automated Order Plan Development
Data Model Configuration
Order
Plan
P1.PCO.ActionID=PROVIDE
P1.PCO.ActionID=HomeMove
OL=B(UPDATE)
There are two planItems:
• B
• P1
B depends on P1
OL=B(HomeMove)
There are two planItems:
• B
• P3
B depends on P3
Sequencing
The product catalog defines the sequencing requirements between the fulfillment 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 defined 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 fulfillment happens
in the correct sequence.
Sequencing is governed by certain rules on the Plan Fragments.
Fulfillment Order Management 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 figure shows the sequencing for the products A, B and C.
TIBCO® Fulfillment Order Management User's Guide
Automated Order Plan Development | 83
Figure 24: 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 first, followed by Product
A and then Product C.
Figure 25: Order Plan Execution Sequence
Similarly, a CEASE sequencing order can also be defined 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 fulfilled 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 briefly explain the different Plan Development Concepts (for details, see Automated
Order Plan Development on page 71).
TIBCO® Fulfillment Order Management User's Guide
84 | Automated Order Plan Development
Figure 26: Sample Product Model
The table describes the diagram elements of the Product Model Hierarchy.
Diagram Element
Description
Product entity.
The arrows represent the ProductComprisedOf
relationship 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.
The Broadband Product Offering (PO) contains
the following mandatory products:
• Telephone
• UserID
• Line Activation
The dotted line indicates that the Modem is an
optional product.
TIBCO® Fulfillment Order Management User's Guide
Automated Order Plan Development | 85
Diagram Element
Description
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 fulfilled or processed in
parallel, and all must complete before the entire BUNDLE can be fulfilled. Often, additional sequencing is
required within elements at the same hierarchy level in the model. This can be accomplished by providing
sequence numbers on the ProductComprisedOf relationship.
Product Model Description in Relation to the Sequencing Feature:
The correct fulfillment 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. VOIPTV is installed.
6. Broadband Product Order and VOIP Order is completed.
7. The entire BUNDLE order (Broadband and VOIP) is completed.
Taking the product as an example, the table shows the sequencing of the products:
Parent Product
Product Offering
BUNDLE
UserID
BUNDLE
Telephone/COMBOX
BUNDLE
Line Activation
BUNDLE
Modem Installation (optional)
BUNDLE
VOIP
BUNDLE
BUNDLE Order complete
TIBCO® Fulfillment Order Management User's Guide
86 | Automated Order Plan Development
Delta Provisioning
Delta Provisioning ensures that products which have been defined 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 defined 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.
E.g. for a batch of phones typically we would only want to only send one shipment.
Product Model description in relation to 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 final plan. If the product
exists on the order and in the inventory, it is not included in the plan.
Provide Single Use
The product catalog contains 2 bundles BundleA and BundleB. BundleA contains 2 sub products A and B.
Both the sub products have sequence set to “1” and auto provision set to “True”. A has the attribute single
use set to “True” while B has the attribute set to “False”. BundleB contains 2 sub products A and C. Both the
sub products have sequence set to “1” and auto provision set to “True”. A has the attribute single use set to
“True” while C has the attribute set to “False”.
The order sent into AFF will contain 2 order lines. Order line 1 contains BundleA with order line action
Provide. Order line 2 contains BundleB with order line action Provide. Both the order lines will contain a
UDF with name SingleUseID and the value will be the same for both BundleA and BundleB.
The generated plan will contain only one instance of sub product A. BundleA which will contain a dependency
to sub product A and B. BundleB will contain a dependency to sub product A and C. The UDFs will not be
merged into the retained product.
Figure 27: Single use (Provide-Provide)
Cease Single Use
TIBCO® Fulfillment Order Management User's Guide
Automated Order Plan Development | 87
This functionality ensures that if the products have same product ID and have been defined 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.
In this scenario the Cease instance of the product will be removed from the plan. Bundle A will have a
dependency to both sub product A and B. BundleB will have a dependency to both sub product A and C.
The instance of A still left in the plan will have a new line action of UPDATE. The UDFs will not be merged
into the retained product.
The plan fragment as well as the plan description will be set to the Update fragments from the product
information.
In cases where the sub product A has dependent products all those dependent products will be made
dependent to the remaining instance of product A.
Figure 28: Single use (Provide-Cease)
Update Single Use
This functionality ensures that if the products have same product ID and have been defined 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.
In the following scenario the Update instance of sub product A will remain in the plan. Bundle A will have
a dependency to both sub product A and B. BundleB will have a dependency to both sub product A and C.
The instance of product A will retain the line action of UPDATE. The UDFs will not be merged into the
retained product.
The plan fragment as well as the plan description will be set to the Update fragments from the product
information
TIBCO® Fulfillment Order Management User's Guide
88 | Automated Order Plan Development
Figure 29: Single use (Provide-Update)
Sequenced Single Use
In this scenario OfferingA contains both BundleA and BundleB which have been sequenced 2 and 1
respectively. Since both bundles contain sub product A, this product will be merged into a single instance.
BundleB will be the only product to contain a dependency to sub product A since it is the 1st product to be
provisioned in the plan. BundleA will have the dependency to sub product A deleted.
The UDFS will be merged as mentioned in the above scenarios. The lineIDs and EOL attributes will merged
as well with a comma as a separator.
Figure 30: Single use (Sequenced)
Unconditional Removal of Child Products
The hierarchy single use flag in ConfigValues_AOPD.xml enables the unconditional removal of child products
from the Plan. To enable this functionality, set the following flags:
1. HierarchySingleUse = true (in AOPD).
TIBCO® Fulfillment Order Management User's Guide
Automated Order Plan Development | 89
2.
= true (in the OMS UI Configurator/ Member1/OMS AFI
Configuration/Orchestrator-AOPD Integration Configuration).
Merge inventory in AOPD request
The HierarchySingleUse flag needs to be set for the Inventory Single Use functionality to work irrespective
of Unconditional Removal of products. Unconditional removal of products removes all the child products
of a product deleted due to single use. The MergeInventory flag should be set to true even if products are
removed conditionally for inventory single use.
After implementing these settings, the HierarchySingleUse use case works for SingleUse as well as
InventorySingleUse cases.
The HierarchySingleUse global variable is disabled by default (HierarchySingleUse = false) to
continue with the default implementation. The HierarchySingleUse flag works for all Single Use
cases i.e. SingleUse, CeaseSingleUse,UpdateSingleUse and InventorySingleUse.
Product Affinity (Plan Item Level)
The Product Affinity between different products on the same order allows the products to be grouped and
fulfilled together through the execution of a single plan item. It can be termed as an order fulfillment
optimization.
Generally, a plan item corresponding to an order line specifies a product to be fulfilled in the order. If an
affinity is specified between the products that are either being fulfilled implicitly as mandatory children, or
ordered explicitly as separate order lines, the individual plan items are grouped together into a single affinity
plan item during plan optimization in AOPD. Thus, the corresponding products are fulfilled through the
execution of this single plan item.
The product affinity is specified in the product catalogue in one of the following two different ways:
• By specifying the affinity type and action specific plan fragments attributes in the AffinityGroup tab in
PRODUCT repository
• By assigning the plan fragments using ProductHasXXPlanFragment relationships and specifying the
affinity specific relationship attributes
The XX in relationship name refers to actions, such as PROVIDE, CEASE, UPDATE and CANCEL.
AOPD recognizes the affinity and combines the plan items corresponding to the order lines depending upon
the following two main conditions:
• If the plan fragments defined in the product catalogue for the ordered products are the same
• If the affinity type defined in the product catalogue for the ordered products is the same (InLink or
CrossLink)
UDF Data Handling
Affinity groups together plan items for different order lines into a single plan item. AOPD is also responsible
for populating the UDFs that are associated with these plan items. The potential exists for the same UDF to
be present on different order lines, all values must be available in the plan and the relevant order lines
identified.
The following data handling rules must be implemented:
The following table lists the Sample Order Line Data representing the order lines being affinity grouped.
The Sample Plan Item Data represents the output affinity grouped plan item for those order lines.
Sr
No
Rule
Outcome
Sample Order Line
Data
Sample Plan Item
Data
TIBCO® Fulfillment Order Management User's Guide
90 | Automated Order Plan Development
1
UDF exists on only one of the
UDF name is the
order lines being affinity grouped original UDF name
concatenated with the
order line number.
Value is the original
UDF value.
Order Line = 1 UDF UDF Name =
Name = ServiceID ServiceID:1 UDF
UDF Value = 1234
Value = 1234
Order Line = 2 Does
not contain ServiceID
UDF
2
UDF exists on more than one of
the order lines being affinity
grouped, but not all order lines.
UDF value is the same on all
order lines.
UDF name is the
original UDF name
concatenated with the
order line number as a
comma-separated list.
Value is the original
UDF value.
Order Line = 1 UDF UDF Name =
Name = ServiceID ServiceID:1,2 UDF
UDF Value = 1234
Value = 1234
Order Line = 2 UDF
Name = ServiceID
UDF Value = 1234
Order Line = 3 Does
not contain ServiceID
UDF
3
UDF exists on all order lines
being affinity grouped. UDF
value is the same on all order
lines.
UDF name is the
original UDF name.
Value is the original
UDF value.
Order Line = 1 UDF UDF Name =
Name = ServiceID ServiceID:1,2,3 UDF
UDF Value = 1234
Value = 1234
Order Line = 2 UDF
Name = ServiceID
UDF Value = 1234
Order Line = 3 UDF
Name = ServiceID
UDF Value = 1234
4
UDF exists on more than one
order line being affinity grouped.
UDF value is different on
different order lines.
UDF is created for
each unique UDF
value, with the
corresponding name
containing the original
UDF name
concatenated with the
order line numbers as
a comma-separated
list.
Order Line = 1 UDF
Name = ServiceID
UDF Value = 1234
Order Line = 2 UDF
Name = ServiceID
UDF Value = 1234
Order Line = 3 UDF
Name = ServiceID
UDF Value = 6789
UDF Name =
ServiceID:1,2 UDF
Value = 1234 UDF
Name = ServiceID:3
UDF Value = 6789
TIBCO Fulfillment Order Management supports the following types of product affinities:
Inlink
The Inlink Affinity can be defined between the products at the same level in a bundle.
Figure 31: Inlink Affinity
TIBCO® Fulfillment Order Management User's Guide
Automated Order Plan Development | 91
As shown in the figure, the InLink affinity can be defined between the Product B and Product C for PROVIDE
action by specifying the affinity type as InLink. The PROVIDE plan fragment is defined as PC_PROVIDE_BC.
For the InLink affinity, the LinkID UDF having exactly the same value must be passed in the order lines.
In addition to the two conditions, AOPD also checks the following conditions for the InLink affinity:
1. If a value of the LinkID UDF in the plan items, which is propagated from the order lines to be merged,
is exactly the same.
2. If the dependentOn (parent product) plan item for the plan items to be merged is exactly the same.
If these conditions are fulfilled, the plan items are combined into a single affinity 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 Affinity is defined between the products at any levels across the bundles.
In the Product Model diagram, the products Telephone and COMBOX can have CrossLink affinity between
them. While order fulfillment process, both these technical products would be installed and configured in
one go through the affinity grouped single plan item.
AOPD does not check any additional conditions for CrossLink affinity.
Affinity applies to the order plan development and this element is used to determine what plan fragments
are executed for the product when affinity grouping is active. Affinity Plan Fragments XSD is illustrated as:
Figure 32: Affinity Plan Fragments XSD
The following table explains the Affinity Plan Fragements Data Model.
Element Name
Element Type
Description
Example
TIBCO® Fulfillment Order Management User's Guide
92 | Automated Order Plan Development
planFragmentUniqueId_CANCEL String (Optional)
Plan fragment cancel
type.
planFragmentUniqueId_CANCEL/ String (Optional)
name
Name of the plan
EP_BUNDLE_CANCEL
fragment to execute when NO_RECIPROCAL_ACTION
cancelling this product.
planFragmentUniqueId_CANCEL/ String (Optional)
description
Description of the plan
Product 1 Cancel
fragment to execute when
cancelling this product.
planFragmentUniqueId_PROVIDE String (Optional)
Plan fragment provide
type.
planFragmentUniqueId_PROVIDE String (Optional)
/ name
Name of the plan
EP_BUNDLE_PROVIDE
fragment to execute when
providing this product.
planFragmentUniqueId_PROVIDE String (Optional)
/ description
Description of the plan
Product 1 Provide
fragment to execute when
providing this product.
planFragmentUniqueId_CEASE String (Optional)
Plan fragment cease type.
planFragmentUniqueId_CEASE/ String (Optional)
name
Name of the plan
EP_BUNDLE_CEASE
fragment to execute when
ceasing this product.
planFragmentUniqueId_CEASE String (Optional)
/ description
Description of the plan
Product 1 Cease
fragment to execute when
ceasing this product.
planFragmentUniqueId_UPDATE String (Optional)
Plan fragment update
type.
planFragmentUniqueId_UPDATE/ String (Optional)
name
Name of the plan
EP_BUNDLE_UPDATE
fragment to execute when
updating this product.
planFragmentUniqueId_UPDATE/ String (Optional)
description
Description of the plan
Product 1 Update
fragment to execute when
updating this product.
Affinity Sequencing
Affinity Sequencing is used to support the scenario for maintaining sequencing during affinity grouping.
Affinity Sequencing was introduced during affinity 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 must be in a sequence.
To make products available for affinity sequencing:
• Affinity TYPE value for all products where sequence should be respected should be set to
"SequencedAffinity" in the affinity type
• All order lines where affinity components are known to exist should have a UDF defined as
AffinitySequence and the value should be an integer
Depending on the AffinitySequence values being compared, the following actions are possible:
1. itemA.AffinitySequence = itemB.AffinitySequnce
– If both items have dependent children the children from itemB will be copied to itemA
TIBCO® Fulfillment Order Management User's Guide
Automated Order Plan Development | 93
– 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
Figure 33: Parallel Scenario
The figure depicts the scenario where the items to be affinity 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.AffinitySequence < itemB.AffinitySequnce
– 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 34: Sequenced Scenario
TIBCO® Fulfillment Order Management User's Guide
94 | Automated Order Plan Development
The figure depicts an offering which has items that are in parallel as well as in sequence that need to be
affinity grouped. For items that are in parallel they are handled similar to the figure 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.AffinitySequence > itemB.AffinitySequnce
•
•
•
•
•
itemA will be merged into itemB
UDF's from itemA will merged into itemB
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 35: 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 affinity plan ID
When an order is submitted, the order lines for items which have Affinity should have the
AffinitySequnce defined and updated.
To not merge certain udfs during Affinity Sequencing, those udfs should be added as a comma
separated values in the global variable CharacteristicsWithoutAffinityPostfix in the rules engine
(AOPD).
Conditional Affinity
Conditional Affinity combines InLink and CrossLink affinities in a single affinity type and provides additional
flexibility. Affinity grouping enables different plan items to be grouped together based on the evaluation of
the XPATH expression defined at the product catalog. The two affinity grouping types are:
TIBCO® Fulfillment Order Management User's Guide
Automated Order Plan Development | 95
Inlik Affinity
Crosslink Affinity
Affinity groups plan items having the same parent Affinity groups plan items having the same affinity
product share a common LinkID UDF value and have plan fragment name
the same affinity plan fragment name
The additional configuration fields and rules in conditional affinity are:
Field
Description
AffinityType
Determines the type of affinity implemented.
• InLink
• CrossLink
• Sequenced Affinity
• ConditionalAffinity
AffinityCondition
Valid for Conditional type only. A String field containing an XPATH expression
that evaluates to true or false based on data is in the order:
• If the expression is true, the product plan item is affinity-grouped
• If the expression is false, then the product plan item is not affinity-grouped
• If the field is blank, assume that the value is true
• If the XPATH expression evaluates to anything other than the true or false,
AOPD fails, and returns an exception
The XPATH expression evaluates against the following data fields on the order:
• Order Header UDF Name and Value
• Order Line ProductID
• Order Line Action and ActionMode
• Order Line UDF Name and Value
The XPATH expression can also be defined against the following plan data fields:
• planItem productID
• planItem UDF name value
• planItem Action
AffinityCorrelation
Valid for Conditional type only. The XPATH is evaluated on the Plan data and the
order data. A String field containing an xpath expression based on a data is in the
following order:
• All plan items that evaluate to the same AffinityCorrelation are grouped together
• The field is functionally similar to the LinkID method of correlating plan items
in the InLink affinity. However, it allows correlation based on complex
conditions without a restriction on the UDF names
• If the field is blank, a default LinkID value is shared by all other blank
configurations
• If the XPATH expression evaluates to an empty string, the XPATH expression
is blank, or assume a default LinkID
The XPATH expression evaluates against the following order data fields:
• Order Header UDF Name and Value
• Order Line ProductID
• Order Line Action and ActionMode
• Order Line UDF Name and Value
The XPATH expression can also be defined against the following plan data fields:
• planItem productID
TIBCO® Fulfillment Order Management User's Guide
96 | Automated Order Plan Development
Field
Description
• planItem UDF name value
• planItem Action
AffinityParentGroup
Valid for Conditional type only. A boolean field containing the value true or false:
• If set to true, the plan items with products sharing the same immediate parent
product are grouped together
• If set to false, the parent product is not considered for grouping
AffinityActionGroup
Valid for Conditional type only. A boolean field containing the value true or false:
• If set to true, then only plan items with products that share the same action are
grouped together
• If set to false, then action is not considered for grouping
AffinityActionValue
AffinityActionValue is considered for grouping when AffinityActionGroup is set
to true. This is valid for Conditional type only. String field containing an XPATH
expression that evaluates to a String based on data is in the following order: The
XPATH expression must evaluate to one of the following:
• PROVIDE
• UPDATE
• CEASE
• Empty String
If the XPATH expression evaluates to anything other than these actions, then AOPD
fails and returns an exception.
• If the field is blank, or the return value from the XPATH expression is an empty
string, the remaining action rules must be applied.
The XPATH expression is able to evaluate against the following data fields on the
order:
• Order Header UDF Name and Value
• Order Line Action and ActionMode
• Order Line UDF Name and Value
The XPATH expression can also be defined against the following plan data fields:
• planItem productID
• planItem UDF name value
• planItem Action
AffinityProvide
Provide plan fragment name for affinity grouped plan item. Only plan items with
the Provide action and the same value in this field are grouped together
AffinityUpdate
Update plan fragment name for affinity grouped plan item. Only plan items with
the Update action and the same value in this field are grouped together
AffinityCease
Cease plan fragment name for affinity grouped plan item. Only plan items with
the Cease action and the same value in this field are grouped together
AffinityCancel
Cancel plan fragment name for affinity grouped plan item. Only plan items with
the Cancel action and the same value in this field are grouped together
In the case where plan items with different actions are grouped together due to affinity, the following logic
is used to determine what action to apply to the plan item. The following rules apply:
1. If AffinityActionValue is specified, then the action of the plan item will be the result of evaluating this
xpath.
TIBCO® Fulfillment Order Management User's Guide
Automated Order Plan Development | 97
2. If AffinityActionValue is blank, or evaluates to an Empty String, then the remaining rules will apply:
a. If all order lines have the same action, then the plan item action is the same as the order lines.
b. If order lines have different actions, then:
a. If at least one order line has PROVIDE action, then the plan item will have PROVIDE action.
b. Otherwise if at least one order line has CEASE action, then the plan item will have CEASE action.
c. Otherwise, the plan item will have UPDATE action.
For details, see Fulfillment Catalog Product Catalog Guide.
Important 1) If XPath is defined against plan data, the format should be <Actual XPath> containing
string $var/PlanItem. For example, if you want to define the XPath for UDF name-value pair
MSISDN=123, the XPath can be
$var/PlanItem[productID='GSMLine']/udfs[name='MSISDN']/value/text().
XPath evaluates data from the planItem. Refer to the sample planItem xml.
2) If XPath is defined against the order data, the format should be <Actual
string $var/Order. Refer to Sample order XML
XPath> containing
3) Default order data is considered for evaluation if XPATH does not contain $var/PlanItem.
Refer to Sample XPATHs on page 330 for XPATH definitions.
When AOPD returns a plan it indicates the action of the plan item. Under normal circumstances this maps
directly to the action of the associated order line that caused the creation of the plan item. In the case where
plan items with different actions are grouped together, the following logic is applicable to determine what
action to apply to the plan item.
1. If AffinityActionValue is specified, then the action of the plan item will be the result of evaluating this
xpath.
– If AffinityActionValue is blank, or evaluates to an Empty String, then the remaining rules will apply
2. If all order lines have the same action, then the plan item action is the same as the order lines.
3. If order lines have different actions, then:
– If at least one order line has PROVIDE action, then the plan item will have PROVIDE action.
– Otherwise if at least one order line has CEASE action, then the plan item will have CEASE action.
– Otherwise the plan item will have UPDATE action.
Conditional Affinity Sample
A product model is having two parents:
• Parent_A
• Parent _B
Consider a product model where conditional affinity is defined at all the child products:
• Child_A1
• Child_B1
• Child_B2
TIBCO® Fulfillment Order Management User's Guide
98 | Automated Order Plan Development
Figure 36: Conditional Affinity
The XPATH defined in the product model is evaluated against the submitted order schema.
The following table describes the attribute-based conditional affinity scenarios:
Attribute
Sample XPATH Expressions
AffinityCondition
exists($var/Order/OrderHeaderUDF[name=UDFNAME
and value="UDFVALUE"])
AffintyCorrelation
Order Payload
<ord1:udf>
<ord1:name>UDFNAME</ord1:name>
<ord1:value>UDFVALUE</ord1:value>
</ord1:udf>
$var/Order/orderlines[productID=
'Child_A1']/ OrderlinesUDF[name=
<ord1:line>
'UDFNAME']/ value/text()
<ord1:lineNumber>1</ord1:lineNumber>
<ord1:productID>Child_A1</ord1:productID>
<ord1:quantity>1</ord1:quantity>
<ord1:uom>1</ord1:uom>
<ord1:action>PROVIDE</ord1:action>
<ord1:actionMode>New</ord1:actionMode>
<ord1:udf>
<ord1:name>UDFNAME</ord1:name>
<ord1:value>UDFVALUE</ord1:value>
</ord1:udf>
</ord1:line>
AffintyParentGroup Child_B1 and Child_B2 have immediate parent.
The two will be affinity grouped when:
AffintyParentGroup=true
TIBCO® Fulfillment Order Management User's Guide
Automated Order Plan Development | 99
Attribute
Sample XPATH Expressions
AffinityActionValue
$var/Order/orderlines[productID=
The
affinityAction
Group must be
true
Order Payload
'Child_A1']/OrderlinesUDF[name=
<ord1:line>
'UDFNAME']/value/text()
<ord1:lineNumber>1</ord1:lineNumber>
<ord1:productID>Child_A1</ord1:productID>
<ord1:quantity>1</ord1:quantity>
<ord1:uom>1</ord1:uom>
<ord1:action>PROVIDE</ord1:action>
<ord1:actionMode>New</ord1:actionMode>
<ord1:udf>
<ord1:name>UDFNAME</ord1:name>
<ord1:value>UDFVALUE</ord1:value>
</ord1:udf>
</ord1:line>
Configurable Handling of CrossLink +PCO Conflicts And Single Use +PCO Conflicts
Affinity can violate the product model PCO action-based sequencing when the provisioning of two or more
products must be grouped together through a single affinity plan item for execution but have different parents
which provisioning must be sequenced in a specific order. The affinity plan item is executed for all parents
irrespectively of the PCO action-based sequencing which breaks product model and could lead to circular
dependencies and missing dependencies.
System config parameters should be added to trigger the following behaviour:
• Error: If Affinity and PCO conflict, stop and report an error.
• Ignore: If Affinity and PCO conflict, ignore Affinity rule and apply only PCO.
• Apply: If Affinity and PCO conflict, process with both rules applied but add dependencies.
This applies to all other Affinity types.
SingleUseHandling: Error | Ignore | Apply
• Error: If single use and PCO conflict, stop and report an error.
• Ignore: If single use and PCO conflict, ignore singleuse rule and apply only PCO.
• Apply: If single use and PCO conflict, process with both rules applied but add dependencies.
The default is Apply.
Sort Plan
The sort plan functionality was implemented to sort the plan according to the subscriber for batch orders
with multiple subscribers contained within the plan.
The sort plan function is defined to sort the plan according to an attribute defined within the order. This
function will make sure that products that belong to similar grouping attributes will follow each other in the
GUI.
In scenarios where bulk orders for multiple subscribers are submitted into Fulfillment Order Management
the subscriber ID will be used as the grouping mechanism. All the order lines will have a UDF defined with
the name SubscriberID. Once the entire plan has been generated all the plan items will be sorted according
TIBCO® Fulfillment Order Management User's Guide
100 | Automated Order Plan Development
to the value for the subscriber ID UDF. This will ensure that all products for an individual subscriber will
follow one after the other. This will be followed by the next subscriber and so on.
Attribute Based Decomposition
This functionality provides the ability to define decomposition rules along the relationship path for products.
The decomposition rule is defined as XPATH logic which grants the ability to apply the defined logic anyway
along the order. E.g. We can define that Copper Access or Fibre Access process component should only be
in the plan if the Access Type in the order is Copper or Fibre.
In order for attribute based decomposition can be applied the following conditions need to be satisfied:
1. DECOMPOSITION attribute needs exists in the product where the XPATH logic can be defined.
2. The XPATH logic must contain an exists() this is due to the XPATH logic will be evaluated to either true
or false. The logic could either be for a check of the UDFS or an existence of a particular product within
the order.
A simple scenario for Attribute based decomposition is described below:
Figure 37: Attribute based decomposition product
A bundled offering (“A” in the above figure) will contain a characteristic for the type of access that the
subscriber can specify during order entry. In our figure above this will be the fulfillment of Product “E” or
Product “F”. The bundled offering will have an associated characteristic named “AccessType” where the
value can either be “E” or “F”. For the fulfillment of access type E or F a unique execution plan will be
generated. The “DECOMPOSITION” characteristic for “F” and “E” will contain a relationship value with
“AccessType” set to either “F” or “E”.
The Decomposition characteristic will be able to contain complex XPATH logic which can be used to determine
which branch of the tree should be included in the final execution plan for the offering.
Our design will take into account the new product catalog characteristic called “DECOMPOSITION”. The
decomposition engine will process this characteristic and determine which branch in the product hierarchy
is required for the final execution plan. If in our order access type “E” is specified then branch “F” will not
be included in the execution plan and “E” will be included. If access type “F” is specified then “E” will not
be included in the execution plan.
XPath for attribute based decomposition can be used against the UDFs. The UDFs can come from orderline
or from product model characteristics. AOPD configuration flag "includeproductmodelcharacteristics" is
TIBCO® Fulfillment Order Management User's Guide
Automated Order Plan Development | 101
used to include product model characteristics for xpath execution. By default product model characteristics
are not considered.
By default all the orderlines from the order will be considered to check against whom the Xpath should be
executed. Conditionally it can also be made to execute only against the orderline from which product is being
decomposed. AOPD configuration "includeonlyproductorderline" needs to be set to true in this case. By
default its false.
The xpath expression is relative to the element "Product". A sample xpath is
exists($var//Product[udf[name='AccessType' and value='copper']])
ProductDependsOn and ProductRequiredFor Relationships
ProductDependsOn relationship: The ProductDependsOn (PDO) is a product dependency relationship to
sequence the associated target and source plan items. The PDO relationship allows flexible product
decomposition. This establishes a relationship between two products and is evaluated during the decomposition
process.
ProductRequiredFor relationship: The ProductRequiredFor (PRF) relationship is a prerequisite relationship
for a product to add a target plan item.
The ProductDependsOn (PDO) and ProductRequiredFor (PRF) relationships enable you to create product
offers without defining sequencing for the products. You can create ProductDependsOn relationship to lower
level products instead of using ProductComprisedOf links.
The PDO functionality provides a base behavior that permits to sequence plan items corresponding to products
related by PDO when:
1. PDO source and PDO target product instances have no LINKID defined.
2. PDO source and PDO target product instances have LINKID defined and have same LINKID value.
The feature can extend the base behavior and sequence additionally plan items corresponding to products
related by PDO when:
1. PDO source product instance has LINKID defined and PDO target product instances have no LINKID
defined.
2. PDO source product instance has no LINKID and target product instances have a LINKID defined.
A PDO source product instance can relate to multiple PDO target product instances using base and extended
cases so that following use cases are possible:
• A PDO source product that has a LINKID defined and is related to a PDO target instances that has same
LINKID defined shall be also related to PDO target product instances that have no LINKID defined.
• A PDO source product that has no LINKID defined and is relate to a PDO target instance that has no
LINKID defined shall be also related to PDO target product instances that have a LINKID defined. By
default for PDO sequencing, the base behavior is enabled. To enable the extended behavior set the
"EnableBiDirectionalLinkID" to true,by default it is false.
By default only one instance of required product per LinkID is allowed in plan. If there is a need to override
this behavior to include multiple instances of required product with the same LinkID, then the AOPD flag
"AllowMultipleRequiredProducts" should be set to true. By default it is false.
The PRF adds the required plan item without dependency, if you create only PRF.
The PDO and PRF relationships have the following two relationship attributes:
• Source Action
• Target Action
The PRF relationship also has the third relationship attribute named ocvValidationReq. This is a boolean flag
for validation. Based on validation flag, AOPD adds product configured with the PRF relationship in the
plan.
TIBCO® Fulfillment Order Management User's Guide
102 | Automated Order Plan Development
The PDO relationship also has the third relationship attribute named 'sequenceDirection'. The valid values
of this attribute are either 'AFTER' or 'BEFORE'. This attribute will be paired with the provided values of
SourceAction and TargetAction. For each SourceAction and TargetAction, there will be a value defined for
the sequenceDirection attribute.
• A 'BEFORE' sequence direction will create a dependency of the target product on the source product.
• An 'AFTER' sequencing direction will create a dependency of the source product on the target product.
This is the default.
If no value is provided in the sequenceDirection attribute, the attribute defaults to 'AFTER," and the
functionality works as it did before the introduction of sequenceDirection relationship attribute. This allows
backward compatibility.
The value defined in the sequenceDirection attribute will create a dependency of the target product on the
source product or it will create a dependency of the source product on the target product.
If a PDO Source Product has a dependency on child products, then those child products will have a dependency
on the PDO target product by default. If there is a need to override this default behavior and set the dependency
of the source product directly on the target product, then value of the flag "IgnorePDOFirstChildDependency"
needs to be set to true in the AOPD configuration file. By default this value is false.
ProductDependsOn relationship can be made conditional using XPATH statement stored in optional
product characteristic DECOMPOSITION_REQUIRED_FOR.
ProductRequiredFor relationship can be made conditional using XPATH statement stored in optional
product characteristic DECOMPOSITION_DEPENDS_ON.
Source and Target Attribute Values
The following table describes the different possible combinations:
SourceAction TargetAction
PROVIDE
PROVIDE
PROVIDE
UPDATE
PROVIDE
CEASE
PROVIDE
CANCEL
UPDATE
PROVIDE
UPDATE
UPDATE
UPDATE
CEASE
UPDATE
CANCEL
CEASE
PROVIDE
CEASE
UPDATE
CEASE
CEASE
CEASE
CANCEL
CANCEL
PROVIDE
CANCEL
UPDATE
CANCEL
CEASE
CANCEL
CANCEL
TIBCO® Fulfillment Order Management User's Guide
Automated Order Plan Development | 103
You can also define source action and target action to match the following combination using uppercase,
comma separated values. For example:
SourceAction: PROVIDE,PROVIDE,UPDATE,CEASE,CANCEL,CEASE
TargetAction: UPDATE,CANCEL,PROVIDE,UPDATE,PROVIDE,UPDATE
You can also define sequenceDirection to match the following combination using uppercase, comma separated
values. For example:
SourceAction: PROVIDE,PROVIDE,UPDATE,CEASE,CANCEL,CEASE
TargetAction: UPDATE,CANCEL,PROVIDE,UPDATE,PROVIDE,UPDATE
SequnceDirection: AFTER,BEFORE,AFTER,BEFORE,BEFORE,AFTER
There cannot be any space between the commas and the values.
Dependency between planitems occurs when both the following occur:
• The sequenceDirection attribute has valid values, i.e. either 'AFTER' or 'BEFORE.'
• The number of sequenceDirection attributes match with the number of Source Actions and the number
of Target Actions.
There is only one target action for any given source action.
The following table explains the PDO and PRF relationships and their impact on orders and plans.
Product Configuration
Order
Product A has a PRF relationship with OL1=ProductA
Product B having source action and
target action PROVIDE and PROVIDE
Plan
Two plan item (A and B) do not
depend on each other
Product A has PRF and PDO
OL1=ProductA(Action=Provide) planItemA depends on planItemB
relationship with B and PRF and PDO OL2=ProductB(Action=Provide)
has source action and target action
PROVIDE and PROVIDE
Product A has PRF and PDO
OL1=ProductA
relationship with B and PRF and PDO
has source action and target action
PROVIDE and PROVIDE
planItemA depends on planItemB
Product A has PDO relationship with OL1=ProductA(Action=Provide) planItemA depends on planItemB
B having source action and target
OL2=ProductB(Action=Provide)
action PROVIDE and PROVIDE
The following table explains PDO with Sequence direction and their impact on orders and plans.
Product Configuration
Order
Plan
Product A has PDO relationship with OL1=ProductA(Action=Provide) Two planitem having planItemA
B having SA & TA as PROVIDE &
OL2=ProductB(Action=Provide) depends on planItemB
PROVIDE. SequenceDirection is
AFTER.
Product A has PDO relationship with OL1=ProductA(Action=Provide) Two planitem having planItemB
B having SA & TA as PROVIDE &
OL2=ProductB(Action=Provide) depends on planItemA
PROVIDE. SequenceDirection is
BEFORE.
TIBCO® Fulfillment Order Management User's Guide
104 | Automated Order Plan Development
Product Configuration
Order
Plan
Product A has PDO relationship with OL1=ProductA(Action=Provide) Three planitems having planItemA
B having SA & TA as PROVIDE &
OL2=ProductB(Action=Provide) depends on planItemB and planItemC
PROVIDE. SequenceDirection is
OL3=ProductC(Action=Provide) depends on planItemB
AFTER. Product B has PDO
relationship with C having SA & TA
as PROVIDE & PROVIDE and
SequenceDirection is BEFORE.
Product A has PDO relationship with OL1=ProductA(Action=Provide) Three planitems having planItemB
B having SA & TA as PROVIDE &
OL2=ProductB(Action=Provide) depends on planItemA and planItemB
PROVIDE. SequenceDirection is
OL3=ProductC(Action=Provide) depends on planItemC
BEFORE. Product B has PDO
relationship with C having SA & TA
as PROVIDE & PROVIDE and
SequenceDirection is AFTER.
Dependent and Sibling Products
TIBCO Fulfillment Order Management 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 38: 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.
TIBCO® Fulfillment Order Management User's Guide
Automated Order Plan Development | 105
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 defined
in TIBCO Fulfillment Catalog or offline model xml. The dependent or sibling link can be defined 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.
Name
Description
DEPENDENT_PRODUCT
Dependent product characteristic for PROVIDE scenario
DEPENDENT_PRODUCT_CEASE Dependent product characteristic for CEASE scenario
DEPENDENT_PRODUCT_UPDATE Dependent product characteristic for UPDATE scenario
SIBLING_PRODUCT
Sibling product characteristic for PROVIDE scenario
SIBLING_PRODUCT_CEASE
Sibling product characteristic for CEASE scenario
SIBLING_PRODUCT_UPDATE
Sibling t product characteristic for UPDATE scenario
For example, Dependent link for P8 in case of PROVIDE scenario can be specified by creating a Characteristic
relationship between P8 and DEPENDENT_PRODUCT with the value of RelationshipValue as "P6, P7".
Shared Attributes
This section describes about the Shared Attributes and its samples test scenarios.
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 reflected in the other. If an attribute is
deemed as a shared attribute and when the value was passed 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 define the EvaluationPriority, which indicates
the priority of merging the specified 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 defined,
then the value is taken from order line (if passed in order line) or product model.
Second part of the Shared attribute definition mentions that update in the value of shared attribute in one
product needs to be reflected 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. flavor - '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), Config (this indicates
that Process Component has updated the value from Product model)
4. type - Shared (if UDF is of type Shared)
TIBCO® Fulfillment Order Management User's Guide
106 | Automated Order Plan Development
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'. If Shared UDFs are present then TDS checks the EvaluationPriority 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 flavor = output. If TDS finds such UDF then value from this UDF
is returned. If EvaluationPriority is not defined OR products mentioned on the EvaluationPriority do not
contain the UDF with same name and "output" flavor then value from order line/product model is returned
(i.e. merging is not done).
Shared Attributes - Sample Test Scenarios
This section describes about the simple cases to test shared attributes in different scenarios.
1. Publish Product Model. The processes should be running in Test harness.
Here is an example for shared attributes with value of one reflecting in the other.
Scenario 1:
For the above product model structure, submit order for SharedAttribute_B and SharedAttribute_B1. Refer
to Order Submission Process for order submission process. Send new value for the shared attribute in the
UDF format and values for both the attributes.
The value of B should reflect in B1, which conforms with the explanation of the Shared Attributes.
Scenario 2:
Submit order and send new value for the shared attribute (in the UDF format). Through order submission,
send values for both the attributes, SharedAttribute_B and SharedAttribute_B1. Using SetPlanItemRequest
service, set Shared Attributes value of B.
In this case also, the value of B should reflect in B1. Using the GetPlanItemrequest service for B1 returns a
new value, which is reflected in B, thus corresponding value and an update in the value of one is reflected
in the other.
Intermediate Milestones Dependencies
The actual fulfillment 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. There is a 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 figure:
TIBCO® Fulfillment Order Management User's Guide
Automated Order Plan Development | 107
Figure 39: 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.
TIBCO Fulfillment Order Management also 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
• Conditional Milestones Dependency
These dependencies are supported with the implementation of Intermediate Milestones within the process
component in addition to the START and END.
The functionality provides a base behavior that permits plan items to be sequenced corresponding to products
related by MDO when:
1. MDO related product instances have no LINKID defined.
2. MDO related product instances have LINKID defined and have same LINKID value.
This feature can extend the base behavior and sequence additionally plan items corresponding to products
related by MDO when:
1. MDO related parent product instance has LINKID defined and child product instances have no LINKID
defined.
2. MDO related parent product instance has no LINKID and child product instances have a LINKID defined.
An MDO related parent product instance can relate to multiple child product instances using base and
extended cases so that following use cases are possible:
• An MDO related parent product that has a LINKID defined and is related to a child instances that has
same LINKID defined shall be also related to MDO related child product instances that have no LINKID
defined.
• An MDO related parent product that has no LINKID defined and is related to a child product instance
that has no LINKID defined shall be also related to MDO related child product instances that have a
LINKID defined.
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 figure shows the Milestone to START dependency:
Figure 40: Milestone to START Dependency
TIBCO® Fulfillment Order Management User's Guide
108 | Automated Order Plan Development
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 figure shows the END to Milestone dependency:
Figure 41: 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 figure shows the Milestone to Milestone dependency:
Figure 42: Milestone to Milestone Dependency
Milestone without Dependency
There can be intermediate milestones defined 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 figure shows the Milestone without any dependency:
Figure 43: Milestone without Dependency
These types of dependencies help manage the complex order fulfillment process. For instance, start activating
the broadband service once the broadband device fulfillment reaches a certain status, say, INSTALLED.
The product model schema has been updated to support the milestones and dependency definitions. See
TIBCO® Fulfillment Catalog Product Catalog Guide for newly added repository and relationships to support the
intermediate milestones dependencies.
Conditional Milestones Dependency
The dependency between intermediate milestones can be conditional. This is specified using the relationship
attribute called Condition in TIBCO Fulfillment Catalog. It is represented in the product model as illustrated
below:
TIBCO® Fulfillment Order Management User's Guide
Automated Order Plan Development | 109
Figure 44: Conditional Milestones Dependency
In this sample, the START milestone of EP_PROVIDE_11 is dependent on MILE1 of EP_PROVIDE_10, only
if the specified condition is satisfied.
The condition syntax can be one of following three types:
• Parent UDF Syntax
• Child UDF Syntax
• Match Parent-Child UDF Syntax
There is no provision to specify the XSLT statement in the condition as it is there for Attribute Based
Decomposition.
Note the following definitions:
• Parent: The plan fragment whose milestone has a dependency on another plan fragment. The parent UDF
will be referred to a UDF passed in the order line in the order for that product which will be propagated
into the plan item for that order line.
• Child: The plan fragment on whose milestone a milestone in another plan fragment depends. The child
UDF will be referred to a UDF passed in the order line in the order for that product which will be
propagated into the plan item for that order line.
In the plan illustrated above, EP_TEST_PROVIDE_11 [START] is dependent on EP_TEST_PROVIDE_10
[MILE1]. It is assigned to PROD11 as PROVIDE plan fragment. PROD11 is the parent and PROD10 is child.
Parent UDF Syntax
Value:Parent(ParentUDFName=ExpectedValue)
The condition is satisfied only if there is a UDF in the parent plan item with the same value as passed in the
condition as "ExpectedValue".
Child UDF Syntax
Value:Child(ChildUDFName=ExpectedValue)
The condition is satisfied only if there is a UDF in the child plan item with the same value as passed in the
condition as "ExpectedValue".
Match Parent-Child UDF Syntax
Match:ParentUDFName=ChildUDFName
The condition is satisfied only if the value of the UDF [ParentUDFName] in parent plan item is equal to the
value of the UDF [ChildUDFName] in child plan item.
TIBCO® Fulfillment Order Management User's Guide
110 | Automated Order Plan Development
Order Amendment
Order Amendment allows the order, that is currently being fulfilled, to be modified for different parameters
such as action, requiredByDate, and UDFs in the existing order lines. It also allows adding a new order line
in the request. The parameters and their reason for change are mentioned as follows:
• The parameter values passed in the original request was incorrect. The corrected values can be passed by
sending an amendment request.
• The parameter values require a modification as per the change request from the end user. For example,
the bandwidth of a product named Internet Bundle is passed as a UDF named Bandwidth in the order
line. The bandwidth in the original order was 1 Mbps. When the order was being fulfilled, the customer
requested the bandwidth to be updated to 2 Mbps. This is done by sending an amendment request by
changing the value of the UDF named Bandwidth to 2 Mbps.
• An additional product required fulfillment while the current one is being fulfilled.
An order can be amended when it is in one of the following states:
START
SUBMITTED
FEASIBILITY
If the order is amended in these states then it is called
a pre-plan development amendment, because the
execution plan has not yet been created. In this
scenario, the execution plan generated for the
amendment request will be considered and executed.
OPD
PREQUALIFICATIONFAILED
EXECUTION
SUSPENDED
ERROR_HANDLER
If the order is amended in these states it is post-plan
development amendment, because the execution plan
was already created and had begun execution. In this
scenario, the existing plan requires modification and
merging with the plan that has been generated as per
the amendment request. Post-plan development
amendment is the most frequently used amendment.
An order cannot be amended when it is in either of the FINAL states:
• COMPLETE
• CANCELLED
• WITHDRAWN
Amendment Workflow
Since an order amendment involves the modification of the current execution plan, a predefined process is
adopted. The predefined process is as follows:
1. Upon accepting an order amendment request, the Orchestrator first tries to suspend the current execution
plan by sending the suspend requests (PlanItemSuspendRequest message) to all the plan items that are
in EXECUTION state. Based on the implementation of the process components, and the point at which the
process component is executed, the process components may send a successful suspend response
(PlanItemSuspendResponse message) or a successful completion response (PlanItemExecuteResponse).
Any one of the responses is acceptable by the Orchestrator.
2. Once the execution plan (and order) reaches the SUSPENDED state, the Orchestrator sends a plan generation
request to AOPD to generate the execution plan as per the order lines in the amendment request.
3. The new execution plan generated by the core AOPD is merged with the existing plan to add, or to modify
the plan items as per the changes in the amendment request.
4. Based upon the modification rule characteristics defined in the product model, the compensatory plan
items are added in the new execution plan to allow the undoing of the tasks that were performed by the
TIBCO® Fulfillment Order Management User's Guide
Automated Order Plan Development | 111
earlier corresponding plan items. If required, the REDO plan items are also added in the new execution
plan to allow the redoing of the tasks that needs to be performed by a particular plan item.
5. Upon receiving the consolidated execution plan for the amendment request from AOPD, the Orchestrator
activates the SUSPENDED plan and starts orchestrating it as per the latest dependencies.
6. All SUSPNDED plan items will be activated, either for cancellation (cancelWithNoRollback or
cancelAndRollback) or resume execution (resumeExecution) by sending the PlanItemActivateRequest
messages.
7. Any compensatory and redo plan items, created during the amendment process, will be executed in the
same way as the regular plan items by sending the PlanItemExecuteRequest messages, so as to either
complete or cancel the order.
Modelling of the Required Characteristics in Fulfillment Catalog
As per the requirement of the amendment use case, some or all of the following characteristics are required
to be available in the product model published to FOM. The modelling of these characteristics and relating
them with the required products, needs to be done in TIBCO Fulfillment Catalog at the design time. Refer
the generic steps given below for modelling.
This section covers just the high level modelling steps specific to the characteristics required for
amendments. Refer TIBCO Fulfillment Catalog documentation for details.
1. Create the following records in CHARACTERISTIC repository:
– EPMR_ACTION_PROVIDE
– EPMR_ACTION_CEASE
– EPMR_ACTION_UPDATE
– EPMR_ACTION_WITHDRAW
– COMPENSATE_PROVIDE
– COMPENSATE_CEASE
– COMPENSATE_UPDATE
2. For more granular EPMR actions based on the plan item statuses, the user can add additional characteristics
mentioned below in generic format. Note that these characteristics are used only in case of the new and
improved UDF modification functionality. Refer the New Characteristics sub-section in OrderLine UDF
change.
– EPMR_ACTION_<<action>>_UDF_CHANGE_<<Plan Item Status>>. For example,
EPMR_ACTION_PROVIDE_UDF_CHANGE_SUSPENDED.
3. Create the Characteristic relationship between the records in PRODUCT repository and one or more
EPMR_ACTION_* records in the CHARACTERISTIC repository mentioned in point 1 and 2 above. The logically
valid value for the RelationshipValue attributes in all these Characteristic relationships can be one of the
four EPMR actions - COMPENSATE, RESTART, COMPENSATE_RESTART, or IGNORE. Refer the Execution Plan
Modification Rules (EPMR) on page 118 topic for the significance of these four actions. For example, the
technical product Router can have a Characteristic relationship with EPMR_ACTION_PROVIDE characteristic,
with the value of RelationshipValue attribute as COMPENSATE_RESTART.
4. Create the Characteristic relationship between the records in PRODUCT repository and one or more
COMPENSATE_* records in the CHARACTERISTIC repository mentioned in point 1 above. The logically valid
value for the RelationshipValue attributes in all these Characteristic relationships should be the ID of the
plan fragment record that is required to be executed as the compensation task for corresponding action.
For example, the technical product Router can have a Characteristic relationship with COMPENSATE_PROVIDE
characteristic, with the value of RelationshipValue attribute as the planFragmentID Router_Cancel.
Types of Amendment
At a high level, order amendments can be classified into the two heads and further into each sub-type as
described below:
1. Changes at order line level
TIBCO® Fulfillment Order Management User's Guide
112 | Automated Order Plan Development
a. Action Change - Changing the action in one or more order lines.
b. RequiredByDate Change - Changing the requiredByDate in one or more order lines.
c. UDF Change - Changing the UDF(s) in one or more order lines.
2. Changes at the order header level
a. RequiredByDate Change - Changing the requiredByDate at order header level.
b. OrderLine Addition - Adding a new order line in the order.
c. OrderPriority Change – Changing the orderPriority at the order header level.
The amendment types at the order line level are MUTUALLY EXCLUSIVE. Only one of the amendment types
is allowed for a particular order line in an amendment request. E.g. the action and UDFs cannot be
simultaneously updated in an order line. If multiple amendment types are tried simultaneously for an order
line in a single amendment request, an exception with the appropraite code and an appropriate message is
thrown. For example, if action and requireByDate both are changed in an order line in the amendment request,
an exception with error code "TIBCO-AFF-OMS-100064" and error message "Action and requiredByDate
cannot be modified simultaneously in an order line", is thrown.
However, different amendment types can be applied in different order lines as part of the same amendment
request. That is, action change in one order line and UDF or requiredByDate change in another one can be
done simultaneously.
OrderLine Action Change
In this amendment type, the fulfillment action in an order line can be changed as part of the amendment
request. E.g. action was PROVIDE in an order line in the original order request and changed to UPDATE in
the amendment request. Since CANCEL can also be passed as the action in one or all the order lines in the
amendment request, order line cancellation and entire order cancellation are the sub-types of this amendment
type.
OrderLine Cancellation
In order to cancel a particular order line, CANCEL must be passed as action in the amendment request. The
PENDING plan items associated to the order line are directly CANCELLED. Execution Plan Modification
Rules are applied on the plan items that were COMPLETE or SUSPENDED before the amendment so as to
compensate them, as per the EPMR action defined in the product model. Once all the associated plan items
are either cancelled or compensated, the order line is marked as cancelled by changing its status to
CANCELLED.
Entire Order Cancellation
In order to cancel the entire order, CANCEL must be passed as action in all the order lines in the amendment
request. All the PENDING plan items in the execution plan are directly CANCELLED. Execution Plan
Modification Rules are applied on the plan items that were COMPLETE and SUSPENDED before the
amendment to compensate them, as per the EPMR action defined in the product model. Once all the plan
items are either cancelled or compensated, all the order lines and also the order is marked as cancelled by
changing the statuses to CANCELLED. The Execution Plan Modification Rules are applied in case of order
line or entire order cancellation, based on the boolean value (true/false) of the rollback UDF passed in the
order header. The modification rules will be applied if the rollback UDF's value is true, otherwise it will not
be applied.
The default behavior is always to rollback, that is, if the rollback UDF is not passed in the order header,
it will be considered to be true.
An order can also be cancelled using the CancelOrderRequest SOAP service and from OMS UI.
Preconditions for Action change
Following are the preconditions for the order line action change amendment type.
1. The number of order lines in the amendment request must match with those in the original order request.
TIBCO® Fulfillment Order Management User's Guide
Automated Order Plan Development | 113
2. The lineID, productID, requiredByDate, and UDFs in all the order lines in the amendment request must
match with those in the original order request.
When the fulfillment action in an order line is changed, the plan items associated with that order line in the
existing plan are handled in different ways.
1. The action in the amendment request is set as the fulfillment action in all PENDING plan items.
2. Execution Plan Modification Rules (EPMR) are applied to all SUSPNEDED or COMPLETE plan items to
take the appropriate actions on these plan items such as compensating the earlier tasks and/or redoing
the tasks from beginning.
For any action change in the amendment request other than CANCEL, the EPMR characteristic corresponding
to the action in the original plan item, from the product being fulfilled by that plan item, is considered while
applying the modification rule.
OrderLine Action in Original
Request
OrderLine Action in Amendment EPMR Characteristic Considered
Request
PROVIDE
Any, except for CANCEL and
EPMR_ACTION_PROVIDE
PROVIDE
UPDATE
Any, except for CANCEL and UPDATE
EPMR_ACTION_UPDATE
CEASE
Any, except for CANCEL and CEASE
EPMR_ACTION_CEASE
On the other hand, if CANCEL is passed as the order line action in the amendment request, the
EPMR_ACTION_WITHDRAW characteristic from the product being fulfilled by the corresponding plan
item is considered always, regardless of the action in the original request.
Based on the value of the EPMR characteristic that was considered, the modification rules will be applied on
the required plan items. See topic Execution Plan Modification Rules (EPMR) on page 118 to understand the
effect of each action.
If the EPMR characteristic to be considered (e.g. EPMR_ACTION_PROVIDE) is not present in the
corresponding product model, COMPENSATE_RESTART will be considered as the default EPMR
action, only if the flag CompensateRestartForNoEPMRChar is set in AOPD configurations. See the
topic Amendment Configuration Flags on page 122 to understand the significance of each flag.
Once the EPMR action is applied on all the required plan items and the compensatory and/or redo plan
items are generated, the dependencies in the parent plan items will be updated appropriately. See topic
Impact on Dependencies on page 122 to understand how the dependencies are modified. The amendment
plan is sent out to Orchestrator so as to fulfil the order sent in the amendment request.
RequiredbyDate Change
RequiredByDate for an order defines the time at which the order plan should be executed. It can be mentioned
at both the order header level or/and the order line level. In terms of dependency in the order plan, it generates
a time dependency (with absolute time) for a plan item along with dependency on other executing plan items
(point dependency) if any. Once the absolute time is reached, time dependency is considered as satisfied.
Following are the preconditions for the order line requiredByDate change amendment type:
1. The number of order lines in the amendment request must match with those in the original order request.
2. The lineID, productID, action, and UDFs in all the order lines in the amendment request must match with
those in the original order request.
The method to determine the time dependency has changed from FOM 2.0.1 version in FOM 2.1.0 Following
is the process of calculating a time dependency with respect to requiredByDate.
• If requiredByDate is set on the order level only, the start time dependency applies to all plan items with
no leading dependencies
• If requiredByDate is set on the order line level only, the start time dependency applies to plan items for
that order line
TIBCO® Fulfillment Order Management User's Guide
114 | Automated Order Plan Development
• If requiredByDate is set on the order header level and on the order line level, the following behaviour
applies:
– If requiredByDate in Order Header is later than requiredByDate in order line, then the start time used
is the one at order level
– If requiredByDate in Order Header is earlier than requiredByDate in line item, then the start time used
is the one at order line level
RequiredBydate Amendment type allows for changing the required date for an order when it is not in its
FINAL stages as mentioned earlier. The following matrix defines the conditions to identify a RequiredByDate
change amendment type:
Original header
date
Original line date
New header date
New line date
IsAmendment
Past Dated
Past Dated
past dated but
past dated but
No
greater than
greater than
originalheader date originalheader date
Past Dated
Past Dated
Same as original
Future Dated
Yes, for that
particular Order
Line
Past Dated
Past Dated
Future Dated
Same as original
Yes, for all order
lines
Future Dated
Past Dated
Back Dated
Same as original
Yes, for all order
lines
Future Dated
Past Dated
Future date than
original
Same as original
Yes, for all order
lines
Past Dated
Future Dated
Same as original
Same as original
No
Past Dated
Past Dated
Futrure Dated
Future Dated
Yes, for all order
lines. The time
dependency will be
calculated as
explained earlier.
No Date
Past Date
Back dated
Same as original
No
No Date
Future Date
Back dated
Same as original
No
No Date
No Date
Future Dated
Fuutre Dated
Yes, for all order
lines. The time
dependency will be
calculated as
explained earlier.
The default behaviour in 2.1.1 for required by date change is not to create compensation or restart any plan
items. Below matrix defines the amendment behaviour based on plan item status
Plan Item Status Description
Pending
Plan item dependency time will be updated so the plan item triggers at the amended
required by date.
Suspended
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.
TIBCO® Fulfillment Order Management User's Guide
Automated Order Plan Development | 115
Plan Item Status Description
Complete
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.
The value of rollback UDF in order is ignored in this case as no compensation or restart plan items are created.
OrderLine UDF Change
OrderLine UDF change is an order amendment type where the amended order lines have changed only their
corresponding UDFs. All other attributes remain unchanged. FOM will be able to identify if the orders have
changed only with respect to UDFs by inspecting the orderlines to identify if the UDFs have been modified,
added or removed. This way of identifying the amended UDF is different from FOM 2.0.1 and prior, where
UDF only change was identified by checking value of special UDF (MODIFICATION_IDENTIFYING_ATTR)
passed in the order line. Starting from FOM 2.1.0, there is no need to pass MODIFICATION_IDENTIFYING_ATTR
UDF to tell FOM which UDF is being modified.
Here is the sample orderline showing the changes between FOM 2.1.0 and FOM 2.0.1 and prior:
Sample OrderLine in FOM 2.0.1
<ord1:line>
<ord1:lineNumber>1</ord1:lineNumber>
<ord1:productID>MODEM</ord1:productID>
<ord1:productVersion>1.0</ord1:productVersion>
<ord1:quantity>1</ord1:quantity>
<ord1:uom>UOM</ord1:uom>
<ord1:action>PROVIDE</ord1:action>
<ord1:actionMode>MOVE</ord1:actionMode>
<ord1:requiredByDate>2011-04-30T13:20:00-05:00</ord1:requiredByDate>
<ord1:inventoryID>1</ord1:inventoryID>
<ord1:notes>NOTES</ord1:notes>
<ord1:slaID>SLA_ID</ord1:slaID>
<ord1:udf>
<ord1:name>MODIFICATION_IDENTIFYING_ATTR</ord1:name>
<ord1:value>Region</ord1:value>
</ord1:udf>
<ord1:udf>
<ord1:name>Region</ord1:name>
<ord1:value>Antarctica</ord1:value>
</ord1:udf>
</ord1:line>
Sample Order Line in FOM 2.1.0
<ord1:line>
<ord1:lineNumber>1</ord1:lineNumber>
<ord1:productID>MODEM</ord1:productID>
<ord1:productVersion>1.0</ord1:productVersion>
<ord1:quantity>1</ord1:quantity>
<ord1:uom>UOM</ord1:uom>
<ord1:action>PROVIDE</ord1:action>
<ord1:actionMode>MOVE</ord1:actionMode>
<ord1:requiredByDate>2011-04-30T13:20:00-05:00</ord1:requiredByDate>
<ord1:udf>
<ord1:name>Region</ord1:name>
<ord1:value>Asia</ord1:value>
</ord1:udf>
</ord1:line>
Identifying UDF only Amendment
FOM checks the following conditions to identify UDF only change amendment scenario. All the following
conditions, which are mentioned, will hold true for UDF Only Change Amendment:
• Number of order lines in initial order must match number of order lines in amended order.
• The product Id in order line in Initial Order must match with the product Id in corresponding order line
of amended order.
• The Action in order line in Initial Order must match with the Action in corresponding order line of amended
order.
• The RequiredByDate in order line in Initial Order must match with the RequiredByDate in corresponding
order line of amended order.
TIBCO® Fulfillment Order Management User's Guide
116 | Automated Order Plan Development
New EPMR Characteristics
Starting with the version number 2.1.0, FOM provides more granular EPMR actions to be configured for UDF
modifications based on the status of the plan items, so as to have more control while generating the
COMPENSATE or REDO plan items.
The format of new EPMR characteristics are:
1. EPMR_ACTION_<<action>>_UDF_CHANGE: Using this format EPMR action can be configured on per
Amendment Type. The supported values of <<action>> are:
a. PROVIDE
b. CEASE
c. UPDATE
d. WITHDRAW
The following is an example of the characteristic, configured in product model with EPMR:
<ns0:characteristics>
<ns0:name>EPMR_ACTION_PROVIDE_UDF_CHANGE</ns0:name>
<ns0:description>Characteristic</ns0:description>
<ns0:instanceOptional/>
<ns0:instanceCeaseSequence/>
<ns0:instanceUpdateSequence/>
<ns0:instanceSequence/>
<ns0:instanceMin>0</ns0:instanceMin>
<ns0:instanceMax>0</ns0:instanceMax>
<ns0:evaluationPriority/>
<ns0:value>
<ns0:type>PROVIDE</ns0:type>
<ns0:discreteValue>COMPENSATE_RESTART</ns0:discreteValue>
<ns0:mandatoryValue>true</ns0:mandatoryValue>
</ns0:value>
<ns0:simpleRule>
<ns0:name>EPMR_ACTION_PROVIDE_UDF_CHANGE</ns0:name>
<ns0:ruleSetOutcome>Characteristic</ns0:ruleSetOutcome>
</ns0:simpleRule>
</ns0:characteristics>
2.
EPMR_ACTION_<<action>>_UDF_CHANGE_<<Plan Item Status>>:
Using this format, EPMR action can
be configured on per Amendment Type and Plan Item Status . The supported values of Plan Item Status
are:
a. COMPLETE
b. SUSPENDED
c. PENDING
d. EXECUTION
The following is an example of the characteristic, configured in product model with EPMR:
<ns0:characteristics>
<ns0:name>EPMR_ACTION_PROVIDE_UDF_CHANGE_SUSPENDED</ns0:name>
<ns0:description>Characteristic</ns0:description>
<ns0:instanceOptional/>
<ns0:instanceCeaseSequence/>
<ns0:instanceUpdateSequence/>
<ns0:instanceSequence/>
<ns0:instanceMin>0</ns0:instanceMin>
<ns0:instanceMax>0</ns0:instanceMax>
<ns0:evaluationPriority/>
<ns0:value>
<ns0:type>PROVIDE</ns0:type>
<ns0:discreteValue>COMPENSATE_RESTART</ns0:discreteValue>
<ns0:mandatoryValue>true</ns0:mandatoryValue>
</ns0:value>
<ns0:simpleRule>
<ns0:name>EPMR_ACTION_PROVIDE_UDF_CHANGE</ns0:name>
<ns0:ruleSetOutcome>Characteristic</ns0:ruleSetOutcome>
</ns0:simpleRule>
</ns0:characteristics>
TIBCO® Fulfillment Order Management User's Guide
Automated Order Plan Development | 117
Backward Compatibility with FOM 2.0.1
FOM 3.0.0 supports the use of MODIFICATION_IDNETIFYING_ATTR udf to denote the UDF being changed
through the use of a flag. This flag , called EnableModificationIdentifyingAttribute, can configured from
FOM Config UI is as shown in the following figure:
The default value of this flag is FALSE.
Predefined UDFs
Changes in following UDFs are ignored by FOM:
• ORDERLINE
• GLOBAL_PRODUCT_NAME
• EOL
• ACTION
• M_EPS_UDFS
The changes done only in the UDFs at the order header level in an amendment request doesn’t have
any impact on the existing plan in terms of the creation of compensatory and redo plan items. There
will be no changes in the dependencies between the plan items either. However, the amendment plan
will contain the updated value of the UDFs. The plan items which go into EXECUTION post
amendment will be able to get the updated value of the header level UDFs using GetPlan JMS data
interface or GetOrderExecutionPlan service.
OrderPriority Change
The orderPriority change in an amendment request doesn’t have any impact on the existing plan in terms of
the creation of compensatory and redo plan items. There will be no changes in the dependencies between
the plan items either. However, once the amendment plan is activated, the updated value of the orderPriority
is passed as JMSPriority in all further outbound JMS messages corresponding to that order so as prioritize
the fulfillment of the order.
OrderLine Addition
In this amendment type, one or more new order lines can be added as part of the amendment request to fulfil
the additional products. The plan items corresponding to the newly added order lines are added into the
execution plan and the dependencies are updated accordingly. At a high level, there are two main cases.
1. If an optional child product from a ProductComprisedOf relationship was ordered in the original request
and the parent product is then ordered in a new order line in the amendment request, the newly created
plan item for parent product will have a dependency on the existing plan item of the child product.
TIBCO® Fulfillment Order Management User's Guide
118 | Automated Order Plan Development
For example, if B is an optional child product of A, in case of the above mentioned scenario; the newly
added plan item for A will have a dependency on the plan item of B which was there in the original plan.
This is done regardless of the status of the plan item for child product B.
This is logical and would have been the case even when both products were ordered in the original request
itself. Once the amendment plan is activated, the plan item for the parent product goes into EXECUTION
after the plan item for child product is successfully completed. If the plan item for child product was
already COMPLETE, the plan item for parent product will go into EXECUTION immediately.
2. On the other hand, if a parent product from a ProductComprisedOf relationship was ordered in the
original request and the child product is then ordered in a new order line in the amendment request, the
dependency of the child plan item is added based on the status of the parent plan item, as explained in
the following points:
a. If the parent plan item was PENDING before the amendment, the dependency will be added into the
existing parent plan item.
b. If the parent plan item was SUSPENDED or COMPLETE before the amendment, a REDO plan item will be
generated against it. The original parent plan item will be cancelled if it was SUSPENDED. A REDO plan
item will be generated based on the EPMR action configurations as mentioned in the following points:
a. If the value configured in the EPMR characteristic for the corresponding order line action is either
RESTART or COMPENSATE_RESTART. E.g. In case of PROVIDE action, the value of EPMR_ACTION_PROVIDE
characteristic is referred.
b. Or the required EPMR characteristic is missing in the product model and the
CompensateRestartForNoEPMRChar flag is enabled in AOPD configurations.
See Execution Plan Modification Rules (EPMR) on page 118 for details about EPMR actions. The
dependency of the child plan item will be added into the newly created REDO plan item for the parent
product. Once the amendment plan is activated, the newly added plan item for the child product goes
into EXECUTION. After it is successfully completed, the REDO plan item for parent will go into
EXECUTION.
Preconditions for OrderLine Addition
Following is the only precondition for the order line addition amendment type.
The lineID, productID, requiredByDate, and UDFs in all the order lines in the amendment request must
match with those in the original order request.
Unlike addition, the deletion or removal of an existing order line is not allowed and supported in an
amendment request. For cancelling the fulfillment of the product in an order line, the order line action
should be changed to CANCEL instead.
Execution Plan Modification Rules (EPMR)
The execution plan, for the amendment types mentioned earlier, is modified based on the predefined rules
that are specified as values in the following characteristics in the product model:
1. EPMR_ACTION_PROVIDE
2. EPMR_ACTION_CEASE
3. EPMR_ACTION_UPDATE
4. EPMR_ACTION_WITHDRAW
Only one of the appropriate characteristics, based on the action passed in the original order, is referred to
while applying the modifications on the execution plan. For UDF change functionality, additional set of
characteristics can be defined to have a granular control based on the status of the plan item.
As mentioned in earlier, these rule actions are applied on the plan items that are either in SUSPENDED or
COMPLETE state. There are four standard EPMR actions which are explained in the following paragraphs.
Only one of the four actions can be specified as the value for a particular EPMR characteristic for a particular
product.
TIBCO® Fulfillment Order Management User's Guide
Automated Order Plan Development | 119
COMPENSATE_RESTART
This EPMR action is assigned as the value of an EPMR characteristic if a compensatory as well as a redo plan
item is to be created against an existing plan item as a part of the amendment processing.
Compensatory Plan Item
The purpose of a compensatory plan item is to compensate, or reverse, the tasks that were done by the existing
plan item before the amendment request was initiated. The important aspect of a compensatory plan item
are as follows:
1. The planItemId of the compensatory plan item is derived using the planItemId of the existing plan item
and has the following format: COMP-<amendment number>_<planItemId of the existing plan item>.
For example, if the planItemId of the existing plan item is 04ceddc8-60fc-4800-82b9-4f3382400000
and a compensatory plan item is created against it during the first amendment request, the planItemId
assigned to that compensatory plan item will be COMP-1_04ceddc8-60fc-4800-82b9-4f3382400000.
2. The action and planFragmentUniqueID (processComponentID) in the compensatory plan item is assigned
on the basis of the action in the existing plan item, which is described in the following table:
Action in Existing Plan Item
Action in Compensatory Plan
Item
processComponentID in
Compensatory Plan Item
PROVIDE
CEASE
Value of Characteristic
COMPENSATE_PROVIDE
UPDATE
UPDATE
Value of Characteristic
COMPENSATE_UPDATE
CEASE
PROVIDE
Value of Characteristic
COMPENSATE_CEASE
If the required COMPENSATE_<ACTION> characteristic (for example COMPENSATE_PROVIDE) is not
present in the product model, the regular plan fragment specified for CANCEL action will be assigned.
3. The compensatory plan item, by default, will have a simple END-START point dependency on the existing
plan item being cancelled, as shown in the following figure. This is to ensure that the compensatory task
should be started only after the existing task, being executed, is activated and cancelled.
Figure 45: Dependency between the compensatory plan item COMP-1_P1 and the existing plan
item P1 that will be cancelled
In order to enable the backward compatibility of having no dependency in the compensatory plan items
in FOM 2.0.x, the flag NoDependencyInCOMPPlanItems must be set in AOPD configurations. Refer topic
Amendment Configuration Flags on page 122 to understand the significance of each flag.
4. The action and the processComponentID in the existing plan item will be set to CANCEL and
NO_RECIPROCAL_ACTION respectively so as to cancel the existing plan item. Note that the Orchestrator
changes the processComponentID to NO_RECIPROCAL_ACTION only for the PENDING plan items
that are cancelled. The processComponentID for the SUSPENSED plan items remain the same.
TIBCO® Fulfillment Order Management User's Guide
120 | Automated Order Plan Development
A compensatory plan item, if requiring creation, is created always against a regular plan item in the
first amendment. However, in the subsequent amendment requests, it can be created against a regular
or a REDO plan item from the earlier amendment based on the execution plan at that point of time,
as shown in the following figure. A compensatory plan item is never created against another
compensatory plan item that was created during the last amendment.
Figure 46: Dependency between the compensatory plan item COMP-2_REDO-1_P1 created
during second amendment and the REDO plan item from the last amendment REDO_P1, which
will be cancelled.
Redo Plan Item
The sole purpose of a redo (restarting) plan item is to restart or redo the tasks that were supposed to be done
in the existing plan item before the amendment request was initiated. The important aspects of a redo plan
item are as follows:
1. The planItemId of the redo plan item is derived using the planItemId in the existing plan item and has
the following format: REDO-<amendment number>_<planItemId of the existing plan item>. For
example, if the planItemId of the existing plan item is 04ceddc8-60fc-4800-82b9-4f3382400000 and a
redo plan item is created against it during the first amendment request, the planItemId assigned to that
redo plan item will be REDO-1_04ceddc8-60fc-4800-82b9-4f3382400000.
2. The action in the redo plan item is the one that is passed in the corresponding order line in the amendment
request.
3. The planFragmentUniqueID (processComponentID) in the redo plan item is the same as the one in the
existing plan item, except in case of order line action change amendments. In such cases, the plan fragment
associated with the action in the amendment request is assigned in the redo plan item.
4. The redo plan item will always have a simple END-START point dependency on the compensatory plan
item that is created, as shown in the following figure. This ensures that the designated tasks is restarted
only after the compensatory tasks are finished.
Figure 47: Dependency between the REDO plan item REDO_P1 and the compensatory plan item
COMP-1_P1
A redo plan item, requiring creation, is always created against a regular plan item in the first
amendment. However, in the subsequent amendment requests, it can be created against a regular or
a REDO plan item from the earlier amendments based on the execution plan at that point of time, as
shown in the following figure. A redo plan item is never created against a compensatory plan item
that was created during the last amendment.
TIBCO® Fulfillment Order Management User's Guide
Automated Order Plan Development | 121
Figure 48: Dependency between the redo plan item REDO-2_REDO-1_P1 created during second
amendment and the REDO plan item from the last amendment REDO_P1, which will be cancelled
In case of OrderLine Cancellation or Entire Order Cancellation, even if the EPMR action is
COMPENSATE_RESTART, only compensatory plan item will be created. There is no need to create a redo
plan item as the order line, or the entire order will be cancelled.
RESTART is not a logical EPMR action in case of an order line or an entire order cancellation. If RESTART
action is encountered while processing the order line or the order cancellation, no action will be taken
on the corresponding plan item. A relevant message is logged, instead, to report the same.
COMPENSATE
This EPMR action is assigned as the value of an EPMR characteristic if only a compensatory plan item is to
be created against an existing plan item as a part of the amendment processing.
See Compensatory Plan Item for understanding all the aspects of a compensatory plan item.
RESTART
This EPMR action is assigned as the value of an EPMR characteristic if only a redo plan item is created against
an existing plan item as a part of the amendment processing.
See Redo Plan Item for understanding all the aspects of a redo plan item.
The redo plan item will always have a simple END-START point dependency directly on the existing plan item
that is going to be activated and cancelled, due to the non-existense of a compensatory plan item as shown
in the following figure. This is to ensure that the designated task should be restarted only after the cancellation
of the existing task
Figure 49: Dependency between the REDO plan item REDO_P1 and the existing plan item P1, which
will be cancelled
.
IGNORE
This EPMR action is assigned as the value of an EPMR characteristic, if no explicit action is required to be
taken against an existing plan item as part of the amendment processing. In case of OrderLine Cancellation
or Order Cancellation, the planFragmentUniqueID (processComponentID) of the plan item is set to
NO_RECIPROCAL_ACTION.
TIBCO® Fulfillment Order Management User's Guide
122 | Automated Order Plan Development
No EPMR Characteristic in Product
In case a product model does not contain the required EPMR characteristic, then behaviour of amendment
to generate redo or compensate plan item can be controlled using the flag,
CompensateRestartForNoEPMRChar, in AOPD configurations. See the topic Amendment Configuration
Flags on page 122 for this flag.
Amendment Configuration Flags
The following are the flags available in AOPD configurations to tweak some of the functionalities around
order amendments:
1. EnableModificationIdentifyingAttribute
This flag, if true, enables the OrderLine UDF modification functionality using the
MODIFICATION_IDENTIFYING_ATTR characteristic as it was in 2.0.x.
2. NoDependencyInCOMPPlanItems
This flag, if true, enables the backward compatibility to 2.0.x of having no dependency of the existing plan
item being cancelled, in the compensatory plan item. The compensatory plan item will immediately go
into execution along with the activation request of the existing plan item.
3. EnableDateShiftCompRedo
This flag, if true, enables the backward compatibility to 2.0.x version of creating compensatory and redo
plan items in case of requiredByDate change (Date Shift) type amendments. This value of rollback udf
controls the behaviour at runtime. The default value of rollback is true and the behavior is:
– Compensation and Restart plan items will be created as per the EPMR characteristics for suspended
and completed plan items.
– The original completed and suspended plan items will not have the new requiredByDate. New
requiredByDate (date shift) will be set for the corresponding “Redo” plan items.
– In case of pending items, the requiredByDate of that pending plan item will be changed to the new
requiredByDate. No Compensate or Redo Plan items will be generated.
If mentioned as false, then
– Compensation and restart plan items will not be created.
– Completed and suspended plan items will not contain the changed required by date. Only pending
plan items will have the new date.
The behaviour of requiredByDate amendments for compensation and restart plan items for EPMR
characteristics will be consistent with implementation of other amendment types configured for 2.0.x in
this release.
4. CompensateRestartForNoEPMRChar
This flag, if true, considers COMPENSATE_RESTART as the EPMR action in case of the required EPMR
characteristic not present in the product model. If this flag is false and the required EPMR characteristic
is also not present in the product model, no action will be taken on the plan items associated to that
product, that are in COMPLETE or SUSPENDED state.
Impact on Dependencies
If both compensatory plan items and redo plan items or either of them are created against one or more existing
plan items while processing an amendment request, the dependencies in the overall execution plan are
impacted. The dependency on the existing plan item being cancelled is implicitly added in the compensatory
and/or redo plan item when they are created. There can be some additional dependencies in the redo plan
items in certain cases. Also, the dependencies in other regular plan items are modified, if required. The
following points explain these modifications:
1. If a parent plan item in PENDING state, which is not being cancelled, has a dependency on such a child
plan item against which a COMP and REDO plan items have been created, the dependency on the existing
TIBCO® Fulfillment Order Management User's Guide
Automated Order Plan Development | 123
plan item is removed and a new dependency is added on the REDO plan item, as shown in the following
figures. The REDO plan item has higher priority over the COMP plan item while replacing the dependency
on the corresponding existing plan item. If the REDO plan item does not exist, the dependency on the
existing plan item will be replaced with a dependency on the COMP plan item. This keeps the dependency
structure in the amendment plan in-line with the earlier plan.
Figure 50: Dependency on plan item P1 in PENDING plan item P2 in the original plan
Figure 51: Dependency on the first level REDO plan item of P1 in PENDING plan item P2 in the
amendment plan
2. If REDO plan items have been created against an existing parent as well as child plan item, then the same
dependency is maintained between the corresponding REDO plan items. The parent REDO plan item will
have a dependency on the child REDO plan item, in addition to the dependency on the existing original
plan item being cancelled, as shown in the following figures:
Figure 52: Dependency on plan item P1 in plan item P2 in the original plan
Figure 53: Dependency on REDO plan item P1 in REDO plan item P2 in the amendment plan
TIBCO® Fulfillment Order Management User's Guide
124 | Automated Order Plan Development
3. If COMP plan items have been created against an existing parent plan item as well as child plan item, a
reverse dependency is maintained between the corresponding COMP plan items in the amendment plan.
The child COMP plan item has a dependency on the parent COMP plan item, as shown in the figure. It
is done to ensure that the exact compensation of the plan items, that is, the compensation of parent plan
item occurs first, followed by the compensation of child plan item.
Figure 54: Dependency on plan item P1 in plan item P2 in the original plan
Figure 55: Dependency on COMP plan item P2 in COMP plan item P1 in the amendment plan
Multiple Amendments
FOM allows multiple amendments of an order however not concurrently. This means that the order which
is currently being amended cannot be amended again at the same time. Once the existing amendment request
is successfully processed by FOM and the new plan is activated, the order can be very well amended again,
provided the amendment conditions are satisfied. Each amendment request for an order is processed in the
same way as explained in section Amendments Workflow.
The planItemId assigned to a compensatory or a redo plan item created during an amendment contains the
amendment number as one of the prefixes. Refer sections Compensatory Plan Item and Redo Plan Item for
the knowing the planItemId format.
Order Priority
This section describes about the order priority process.
Understanding Order Priority
The OrderPriority enables the user to set priority on submitted orders. This information is then used by JMS
broker to deliver the high priority orders to downstream components on priority. The order priority is also
propagated to downstream process components. The priority value ranged from 0 to 9. The priority information
or priority value to process any given order is set in the JMSHeader field of the JMS message which is sent to
the following Fulfillment Order Management components:
• Orchestrator engine
• AOPD engine
TIBCO® Fulfillment Order Management User's Guide
Automated Order Plan Development | 125
The JMS broker then delivers the order based on a priority.
The process of order prioritization works at a queue level and can be controlled by JMS broker.
The order priority process or order prioritization cannot be controlled once the message is delivered
to the Orchestrator engine or AOPD engine. The priority value can be changed before JMS broker
sends the order request to the engines.
Order Schema Changes
The order schema allows you to submit the orderPriority information with the order. The orderPriority
is at the orderHeader level and the same priority is applied to all the orderLines.
The schema snippet is as follows:
<xs:element name="orderPriority" minOccurs="0" default="4">
<xs:simpleType>
<xs:restriction base="xs:integer">
<xs:minInclusive value="0" />
<xs:maxInclusive value="9" />
</xs:restriction>
</xs:simpleType>
</xs:element>
The orderPriority can take values in range from 0 to 9 to make consistent and map with JMSPriority
message header values.
The default value of the orderPriority field is 4.
Lower Priority Orders
When any order is processed based on the given priority, it results in a situation where a lower priority orders
may never get a chance to be processed because of high priority orders.
The orders with the lower priority can be processed by a mechanism known as the Flow
Control mechanism.
The Enterprise Messaging Service (EMS) allows the user to control the flow of messages to a destination.
Each destination can specify a target maximum size for storing all the pending messages. When the target is
reached, EMS blocks message producers when new messages are sent. This effectively slows down message
producers until the message consumers can receive the pending messages.
Custom Action
In the Fulfillment Order Management 2.0.0 release, you can define the set of Actions to provide a way to
define any number of unique fulfillment actions. Until this release, only four set of actions were supported.
Custom actions are loaded into AOPD as Action Models and will be referred to at the time of plan generation.
Custom action enables you to submit an order for custom actions, depending on which AOPD assigns the
planfragment.
The planfragment is selected based on the PlanFragmenthasCustomAction relationship from the
product datamodel.
TIBCO® Fulfillment Order Management User's Guide
Chapter
3
Manual Order Plan Development
If MOPD is enabled and the order has the configured property for identifying the order for MOPD, then the plan
for that particular order can be manually modified in OPD state.
The orders for MOPD can be manually modified in regular fulfillment flow and the amendment flow as well.
The following operations can be performed in FOM user interface:
• Searching Orders for Manual Order Plan Development
• Modifying the Plan in Draft Mode through Grid View
• Modifying the Plan in Draft Mode through Gantt View
• Saving the Modified Plan
• Saving and Executing the Modified Plan
• Discarding Changes
• Modifying Plan in case of Amendments
Topics
•
•
•
•
•
•
•
Searching Orders for Manual Order Plan Development
Modifying the Plan in Draft Mode through Grid View
Modifying the Plan in Draft Mode through Gantt View
Saving the Modified Plan
Saving and Executing the Modified Plan
Discarding Changes
Modifying Plan in EXECUTION State
TIBCO® Fulfillment Order Management User's Guide
128 | Manual Order Plan Development
Searching Orders for Manual Order Plan Development
To search orders for MOPD perform the following steps:
1. Browse the Orders tab and click the Filter icon.
2. Select MOPD in the OPD Source and click Save. All the orders which are in OPD for manual changes,
and the orders which executed MOPD will be listed.
3. Click the order for which plan has to be manually modified. Order details for that particular order will
be populated and user will get an option Show Manual Plan on the top bar.
4. Click Show Manual Plan and the AOPD generated plan will be shown for modifications. Initially the
plan shown for editing will be in non-draft mode. The user needs to bring the plan in draft mode in order
to get the options for modifying the plan. All the plan and plan-items will be in START state and milestones
will be in PENDING state.
5. Click the Draft Plan icon and you will receive options for modifying the plan. There might be a possibility
that some other user is already accessing the plan and modifying it. In such cases you will be prompted
TIBCO® Fulfillment Order Management User's Guide
Manual Order Plan Development | 129
for confirmation on breaking the lock from the other user who is accessing it. If you choose to beak the
lock then the unsaved changes of the other user will be removed.
TIBCO® Fulfillment Order Management User's Guide
130 | Manual Order Plan Development
Modifying the Plan in Draft Mode through Grid View
Click Draft Plan in grid view. You will see the Add and Remove options on top of the tree in the grid.
You can perform the following actions:
1.
2.
3.
4.
5.
6.
7.
8.
9.
Create a new plan item
Create a new milestone
Delete plan item
Delete milestone
Modify plan item
Modify milestone
Creating new dependencies
Deleting dependencies
Validations
Create a New Plan Item
Click Plan in the tree and click Add. A new plan-item will be created. For each plan-item you can have option
of modifying or adding following values:
Plan Item Tab
In the Plan Item tab you can associate a product and action to the new plan item.
When you click inside the Product ID text box or the icon beside it', you will be given list of all the products
available in the OMS repository.
You can browse through the entire list of products by using pagination or can directly search for the desired
product by keying in the product ID in the search box. This search is case sensitive. When you get the desired
product in the list, select the product and click the OK button. The selected product will appear in the Product
ID text box and all the Action or Owner associated to the selected product will be fetched in the Action
drop-down box.
If you click on the cancel button in the Product ID popup window, no product will be selected. Either the
Product ID text box will appear blank or the earlier product will be retained in the text box.
TIBCO® Fulfillment Order Management User's Guide
Manual Order Plan Development | 131
As you associate the correct action or owner to the newly created plan-item, Process Info tab and the Sections
tab will be populated for the plan item.
If the originally submitted order consists of an Affinity Plan Item, the products will appear comma
separated in Product Textbox. If the user modifies the product by clicking on the textbox or the icon
beside it, the user will not be able to revert and get back the affinity products through MOPD.
Custom Headers Tab
When the user creates a new plan item, the default or system defined custom headers (UDFs) are already
created for the user and you are not allowed to modify these. Values for these UDFs will automatically be
populated as per the selections in different tabs of the plan item.
You can add, modify and delete non system defined UDFs.
Order Line Tab
Initially for the newly created plan item, no order line is associated to the plan-item by default. When you
select the Order Line tab, you will get two options Add and Delete.
For the newly created plan item you can associate at least one order line. When you click Add a new row
will be created with two dropdown boxes: Order Line and EOL.
TIBCO® Fulfillment Order Management User's Guide
132 | Manual Order Plan Development
Order Line dropdown box contains all the order line numbers in an order. You can select one of the order
lines to associate with the new plan item.
EOL (End Of Line) dropdown box will contain the boolean value to identify if the order line associated to
the plan item is EOL. A single plan item can be associated to more than one order lines.
Process Info Tab and Sections Tab
Both these tabs will be populated based on your inputs in the Plan Item tab.
Create a New Milestone
START and END milestones are created as default milestones for every newly created plan item. If you want
to add intermediate milestones to the plan item then first you need to have correct intermediate milestone
sections defined in the plan fragment model. Adding a new intermediate milestone is always dependent on
sections (sections of milestones) defined in the plan fragment model. This rule is used to add a new milestone.
Every plan item is associated to a product and an action or owner by this information we identify the plan
fragment which can be associated to the plan item and if this plan fragment has correct intermediate milestones
defined then you will be able to create new intermediate milestones. In case there is no intermediate milestone
section defined for this particular plan fragment associated to the plan item then you won’t be able to create
any new milestone.
You can confirm the sections which are defined for the plan fragment by clicking the plan item in the
tree and selecting Sections tab.
TIBCO® Fulfillment Order Management User's Guide
Manual Order Plan Development | 133
Considering that the plan fragment you have associated has correct intermediate milestones defined then,
select the milestone folder in the tree and click Add.
A new milestone is created with a Dummy<id> name in the tree and you have to select the milestone ID
from the available milestone ID list in the dropdown box.
For every intermediate milestone assigning a correct milestone ID from available milestone list and creating
at least one dependency to or from this intermediate milestone is mandatory. Any intermediate milestone
created should be part of the flow of the plan that is the intermediate milestone must have at least one
dependency on it, or from it.
While selecting the milestone ID from milestone ID list, you are expected to select the milestone ID whose
section with the existing milestone exists in the plan fragment model.
You have Mile-15-1, Mile-15-2, and Mile-15-3 in the milestone ID list and in the plan fragment model you
have defined following sections:
START – Mile-15-1, Mile-15-1 – Mile-15-2, Mile-15-2 – Mile-15-3, Mile-15-3 – END, Mile-15-1 – END, Mile-15-2
– END.
Now you are trying to create first intermediate milestone and you selected Miles-15-3 as the milestone ID.
You will get the error message showing all the sections that were not found in the plan fragment model while
creating the specified milestone, in this case message shows it didn’t find START – Mile-15-3 section so
Mile-15-3 won’t be accepted as a first milestone between START and END.
When you try to select Mile-15-1 as the new milestone-id, it won’t give any error as there is existing section
for START – Mile-15-1 and Mile-15-1 – END.
Delete Plan Item
Deleting any plan item would mean deleting all the associated milestones and dependencies on or from those
milestones.
Select the plan item you want to delete and click Remove.
TIBCO® Fulfillment Order Management User's Guide
134 | Manual Order Plan Development
Delete Milestone
You cannot delete START or END milestone. You can select any intermediate milestone and delete it. Deleting
any intermediate milestone will delete all the dependencies on or from that milestone.
Modify Plan Item
When the plan is in draft mode, you can click any plan item in the tree and modify the plan item.
Modify Milestones
When the plan is in draft mode, you can click any milestone in the tree and modify the milestone.
Creating New Dependencies
Manual OPD supports the creation of two type of dependencies: Point and Time.
Select any milestone other than END milestone in the plan tree and select the Dependencies tab. You will
see Add and Delete options in the dependencies tab. When you create a dependency you will be creating a
Dependent-On type of relationship between the milestones, which means when you select a milestone from
the tree, as shown in the example START milestone was selected in the tree and while creating the dependency
TIBCO® Fulfillment Order Management User's Guide
Manual Order Plan Development | 135
you are trying to define that this selected START milestone is Dependent-On which other milestone from
other plan-items.
You cannot create any new dependency from END milestone.
Select a valid milestone (other than END milestone) in the tree and click on “Add” in dependencies tab, an
empty dependency row will be created and you are expected to create a point or time dependency.
Creating Point Dependencies
Click the Add new point dependency
icon to create a new point dependency. A popup will appear with
all the plan-items containing milestones on which you can create the dependency.
Choose the appropriate milestone from the tree on which you want to create the dependency. In the
dependency-tree widget you will be able to select all the milestones other than the START milestone. You
cannot create dependency on START milestone.
Select the appropriate milestone from dependency-tree widget and click the OK button. A point dependency
is created in the empty row created earlier.
Creating Time Dependencies
Click on the Add new time dependency
will appear.
icon to create a new time dependency. A date time picker popup
Select the appropriate date and time to create the time dependency.
After selecting the appropriate date and time from the picker, click the OK button and a time dependency
is created in the empty dependency row you had created earlier.
TIBCO® Fulfillment Order Management User's Guide
136 | Manual Order Plan Development
If you want to create multiple point dependencies from the selected milestone in the tree then you should
create multiple rows in the dependency table. You can only create a single dependency (point or time) per
row created in dependency table. For example, if you created three point dependencies from a milestone,
then you need to create a row in dependency table per point dependency which would look like the
dependency table shown in the following screenshot:
You can add Time-Dependency only to START milestone and cannot add multiple Time-Dependencies on
the same milestone.
If you are to create more than one dependency on the selected milestone and you don’t have enough milestones
on which you can create dependency, then you will get the following warning message:
Deleting Dependencies
Any dependency can be deleted by selecting the checkbox of the row and clicking Remove.
Validations
There are different client side validations at different levels of user modifications. In case of any validation
failure an icon
icon.
is shown at plan item or milestone level, along with proper error message on hover of the
The following are the validations for plan item:
1. Products which were ordered in the order should always be part of the modified plan. For example, if
you had ordered BPO_DUO in order line 1, then during modification the plan should always contain a
plan-item with product BPO_DUO, here BPO_DUO can be associate to any available order line.
TIBCO® Fulfillment Order Management User's Guide
Manual Order Plan Development | 137
2. Order lines which were part of the original order should also be part of the modified plan. For example,
if there were 2 order lines in the order and as part of the modified plan, plan-items should be associated
to both the order lines.
3. Product Id cannot be not null, each plan item must be associated to one product.
4. Action Value cannot be null, each product of the plan item should be associated to an action.
5. When you create a new UDF in Custom Header tab, name and value must not be null.
6. At least one order line must be associate with each plan item.
Following are validations for milestone:
1. Milestone id cannot be null. Each milestone when created or modified should be associated to a milestone
id.
2. Dependency row when created should not be empty. Each dependency row when created should have a
point or time dependency associated to it.
3. Proper section should exist in the plan fragment model when creating a new milestone.
4. The intermediate milestone must have at least one dependency on it or from it.
TIBCO® Fulfillment Order Management User's Guide
138 | Manual Order Plan Development
Modifying the Plan in Draft Mode through Gantt View
You can modify a MOPD plan from Gantt view as well. Toggle to Gantt view by clicking the icon
in
the tool bar for the plan. Click Draft Plan in Gantt view and you will be get Add and Remove options on the
top bar of the Gantt chart.
You can perform all the modification options described in section using the Gantt chart option. We have tried
to keep the MOPD modifications similar in Grid and Gantt view. There are some differences in how to access
the edit widgets in Gantt.
Create a New Plan Item
Click planID to select it in the Plan Details column and click the Add icon
see a popup for filling the details of the new plan item.
on the top toolbar. You will
Create a New Milestone
Click the plan item to select the plan item in the Plan Details column and then click Add icon
top toolbar. You will see the popup for filling the new milestone details.
on the
Delete Plan Item
Select a plan item in Plan Details column and click the Remove icon on the top toolbar and the selected
plan item would be deleted. Deleting a plan-item will delete all the associated milestones and the dependencies
on, or from the milestones.
Delete Milestone
Select a milestone in Plan Details column and click the Remove icon on the top toolbar. The selected
milestone would be deleted. You cannot delete START or END milestone. You can select any intermediate
milestone and delete it. Deleting any intermediate milestone will delete all the dependencies on or from the
milestone.
TIBCO® Fulfillment Order Management User's Guide
Manual Order Plan Development | 139
Modify Plan Item
When the plan is in draft mode, you can click the
icon in the Actions column corresponding to the
plan-item you want to modify. It opens the popup with the plan item details.
Modify Milestones
When the plan is in draft mode, you can click the icon
in Actions column corresponding to the
milestone you want to modify. It opens the popup with the milestone details.
Creating New Dependencies
Since the dependency is created on the milestone, you can create the dependency (point or time) when creating
a new milestone, or by modifying existing milestone. In the first case the creation of dependency when creating
new milestone the milestone details pops up. Retrieve the details and visit the Dependencies tab. In the
second case you retrieve the milestone details from the popup and then visit the Dependencies tab.
Validations
If there is a validation error then the Validation Failure icon
chart.
is shown in the Status column of the Gantt
TIBCO® Fulfillment Order Management User's Guide
140 | Manual Order Plan Development
Saving the Modified Plan
You can save your plan modification for future editing purposes. Click Save Manual Plan icon
on the
plan toolbar
to save the modified plan’s copy for later use. In case
there are some client side validations then the plan won’t be saved and upon clicking the save icon you will
see an appropriate message. If the plan is saved succesfully then you will see the success message on the user
interface.
TIBCO® Fulfillment Order Management User's Guide
Manual Order Plan Development | 141
Saving and Executing the Modified Plan
After completing the plan modifications, you need to start the execution of the plan. Click Save and Execute
Manual Plan
icon to save the final copy of modified plan and start execution of the plan. Final copy of
the plan is saved only when there are no validation errors at the UI side in the plan. The plan is sent for
execution only when server side validations are passed. See TIBCO Fulfillment Order Management Concepts
and Architecture Guide for details on 'Server Side Validations'.
The plan being modified should always be the latest copy in order to either Save or Save and Execute.
For example, if user1 is in process of modifying the plan and user2 takes the lock, modifies and saves it, the
user1 will have a stale copy of the plan. Hence, when user1 tries to save the plan, a message will appear: New
copy of plan available in database, please update. Cannot Save the plan. The changes will
not be saved. user1 will have to reload the plan and make the modifications again.
TIBCO® Fulfillment Order Management User's Guide
142 | Manual Order Plan Development
Discarding Changes
To discard the modifications made on the plan, click the Discard Changes
icon on the plan toolbar
. The changes made by you will be discarded. You will be presented
with a confirmation box. Click OK and your changes will disappear and you will be presented with last
saved copy of the plan. Discarding changes is possible only when the plan is in OPD state in FOM user
interface.
TIBCO® Fulfillment Order Management User's Guide
Manual Order Plan Development | 143
Modifying Plan in EXECUTION State
In case you need to modify the plan which is already in EXECUTION state, you must submit an order
amendment with MOPD UDF as per the configurations. Order Amendment can be submitted either through
SOAP Service or through User Interface.
Once the order amendment is submitted with appropriate MOPD UDF, the order will remain in SUSPENDED
state and the corresponding plan in SUSPENDED state will be available for manual modifications.
Steps for modifying the plan in EXECUTION state are as follows:
1. Suspend the order you want to modify.
2. Initiate an order amendment with MOPD UDF and also with the changes you want to make to the order
(if any).
3. Order will be in SUSPENDED state and will be ready for plan modifications in the UI.
4. Search for the MOPD plan as described in the topic Searching Orders for Manual Order Plan Development
on page 128 and perform the plan modifications.
5. After completion of the modifications, click Save & Execute Manual Plan to resume the plan’s execution
after modifying the amended plan.
TIBCO® Fulfillment Order Management User's Guide
Chapter
4
Jeopardy Management System
®
This section describes the functions of TIBCO Fulfillment Order Management Jeopardy Management System
feature.
Topics
•
Jeopardy Management System
TIBCO® Fulfillment Order Management User's Guide
146 | Jeopardy Management System
Jeopardy Management System
Service level agreements(SLAs) are commonly used to ensure the quality of service (QoS). The conventional
way to manage a service is to measure the QoS and then determine whether the requirements have been met.
This means that problems are detected and then corrective action is taken. By contrast, the Jeopardy
Management module rely on predicting the result of QoS compliance of process components that are part of
order fulfillment eco system. Therefore, it is frequently possible to take corrective action before a problem
occurs, thus minimizing its impact.
Jeopardy Management
The jeopardy management process involve three main activities:
1. Monitoring the QoS
2. Reporting the QoS
3. Predicting the QoS
The objectives of Jeopardy Management are as follows:
1. Continuous collection of performance data and status information of all execution plan
2. Detect SLA violation
3. Predict Jeopardy Conditions for execution plan
4. Perform consequential actions
a. Send notification
b. Invoke web service
The Jeopardy Management System enables you to manage the risk associated with plan tasks falling behind
schedule, and to prevent them from jeopardizing the timely fulfillment of an order. The Jeopardy Management
System is a key component of Fulfillment Order Management (FOM). Jeopardy management is the process
of monitoring execution of a set of tasks in a plan to fulfill a customer order. In FOM, execution plans are
generated by decomposing orders based on the product model. Plans are orchestrated based on a schedule,
and when a plan goes or predicted to go outside the expected design of the schedule then the system notifies
the stakeholders as early as possible to take the corrective steps.
A plan is composed of a series of plan items. Each plan item has at least two milestones:
• START milestone
• END milestone
Plan items may also have intermediate milestones that represent points of interest during execution of that
plan item. Service-level agreement of service provider that executes plan items are specified through process
component model or Plan fragment model which stipulate among other things - the provided Services
performance. SLAs have a typical duration and a maximum allowed duration to fulfill a plan item.
To manage the risk associated with plan tasks falling behind schedule, the jeopardy manager performs the
following risk-management tasks:
1. Managing Critical Paths: Jeopardy management computes and keeps an account of critical paths through
an execution plan. Two of these critical paths correspond to the typical and maximum durations of process
components. The third type of critical path is based on the actual duration to date, once the execution plan
has started processing. The critical paths are used to predict the completion date and time of the execution
plan. By viewing the critical paths in the UI GANTT Chart, you can determine whether your execution
plan is progressing normally or if it is in danger of being in jeopardy. The OMS UI highlights each plan
item as per the following legend scheme:
a. Plan item instance is marked in the NORMAL region, if its execution is started on time and completed
within expected time lines.
TIBCO® Fulfillment Order Management User's Guide
Jeopardy Management System | 147
b. Plan item instance is marked in the HAZARD region, if its execution is started late and delayed than
expected time lines but it does not lie on critical path.
c. Plan item instance is marked in the CRITICAL region, if its execution is started late and delayed than
expected time lines and lies on the critical path. The UI also highlights risk regions of a plan with color
scheme.
Figure 56: Jeopardy Indications
2. Monitoring jeopardy conditions at each of the following levels:
a. Plan Task
b. Execution Plan
3. Perform consequential actions at each of the following levels:
a. Plan Task
b. Execution Plan
c. Milestone
The Fulfillment Order Management UI shows dashboard for jeopardy management containing the following
elements along with Orders Summary, Amended Orders, Backlog Orders, Orders in Execution:
1. Orders In Jeopardy.
2. Jeopardy Live Alerts.
3. Jeopardy Recorded Alerts.
Understanding Plan
A plan is constituted of a series of plan items. Each plan item has at least two milestones - START and END.
Plan items may also have intermediate milestones that represent points of interest during execution of that
plan item.
There are two types of milestone dependencies:
Point Dependency
Time Dependency
dependency on release of a given dependency on a given date and time being exceeded
milestone in another plan item in
the plan
Execution of a plan item stops at a milestone until that milestone has been released. A milestone with
no dependencies is released immediately. However, a milestone with attached dependencies is only
released once all the point and time dependencies are satisfied.
TIBCO® Fulfillment Order Management User's Guide
148 | Jeopardy Management System
Figure 57: Plan Dependency
For details on dependencies, see Understanding Dependencies on page 149.
Understanding Critical Path
. The critical path is the longest sequence of plan item sections that determines end time of a plan. The critical
paths are used to project the completion date and time of the execution plan.
Paths are computed using the dependencies between plan item sections.
Critical Path Calculation
Critical path is used for both SLA and predictive jeopardy for monitoring a plan. A simple plan consists of
a single execution path. For example:
Figure 58: Plan with Single Execution Path
Some plans have multiple execution paths as shown in the following figure:
TIBCO® Fulfillment Order Management User's Guide
Jeopardy Management System | 149
Figure 59: Plan with Multiple Execution Paths
Understanding Dependencies
Dependency can be defined as a relationship between milestones in an execution plan. For example, Milestone
B cannot start until Milestone A completes.
Milestone Dependencies
When a dependency on a milestone is determined, you can either depend on the milestone being started, or
finished.
This means that Milestone 2 cannot be finished until Milestone 1 is started.
End Milestones
In case of an end milestone:
• another milestone cannot depend on the finish of an end milestone because there is no Finish (Release)
on a Task Complete message
• the end milestone cannot be dependent on any other milestones
The following table lists the types of dependencies that can be set up between plan task milestones.
Dependency
Effect
Must Start On
The milestone must start on the date/time specified. If it cannot started for some
reason (for example, because a previous plan task is late), a jeopardy condition is
triggered.
Finish to Finish
One milestone is able to be released when the other milestone is released
Start to Finish One
One milestone can be released only when the other begins
Jeopardy Management for Execution Plans
If a given plan task or milestone is in jeopardy, it may or may not indicate that the overall execution plan is
in jeopardy. The jeopardy manager also provides facilities for monitoring whether the whole execution plan
is running on time, or taking longer to complete than expected. This is done by monitoring the forecast end
date and time of the plan and comparing it against several threshold dates.
If you use start date scheduling or end date scheduling for your execution plans, you can set a different set
of jeopardy conditions at plan level.
TIBCO® Fulfillment Order Management User's Guide
150 | Jeopardy Management System
Jeopardy Management for Plan Task
A simple process component that has only start and end milestones consists only of one section, but more
complex components will be made up of several sections. A section is the interval between two milestones.
At the level of process component sections, you can configure jeopardy conditions that enable you to detect
both if the task has taken longer to complete than it should have, and also to detect if a task that is under way
or has not yet started is predicted to take longer to complete than scheduled.
Jeopardy manager allows you to monitor the following durations:
• Typical Duration: you can specify this value when you create a process component, or when you define
the plan task that uses the component in an execution plan.
• Maximum Allowed Duration: the maximum amount of time the activity represented by the task can take
before it is considered to have overrun. You can specify this value when you create a process component,
or when you define the plan task that uses the component in an execution plan.
There are critical paths identified in execution plans, constructed using the typical and maximum durations
of the plan tasks included in those plans. If one of the process component sections being monitored has not
completed before its defined typical duration, a monitor event is triggered (consequential action is performed).
If the section has not completed before the end of its maximum allowed duration, another monitor event is
triggered. For Example, a plan has taken longer than expected/predicted. The plan task has exceeded its
typical duration, its maximum duration, and two subsequent monitoring intervals. A monitor event has been
fired at each stage to notify you of the following:
• After Typical Duration
• After Maximum Duration
Figure 60: Typical and Maximum Durations
Figure 61: Jeopardy Risk Region for Plan
TIBCO® Fulfillment Order Management User's Guide
Jeopardy Management System | 151
Must Start On Dependencies
The must start on dependency indicates that an activity must start at a specific point in time. You can apply
these dependencies to milestones that denote the start of such activities; in normal circumstances, when the
execution plan is running on schedule, these are used to schedule activities at the right time, by releasing the
relevant milestones. However, if it is predicted that it is not possible to release a milestone at the scheduled
time, or if that time is reached and the milestone still cannot be released, the Jeopardy Management System
recognizes the jeopardy condition.
Predictions are calculated during jeopardy detection cycle. Frequency of Jeopardy detection cycle is
configurable.
Consequential Actions
Jeopardy Manager raises the jeopardy event. If a plan item is in jeopardy, the PlanItemJeopardy event is
raised. If a Plan is in jeopardy, the PlanJeopardy event is raised.
To reduce the number of Jeopardy notifications sent out for a particular plan, jeopardy sends either a predictive
notification or the actual notification at the plan level. For example, if the jeopardy sends out a predictive
notification AFF-JM-PLAN-0200 for the Plan to possibly exceed the typical duration, then the jeopardy will
not send out the AFF-JM-PLAN-0100 notification if the plan actually exceeds typical duration, as they are
the notifications for the same risk region.
Jeopardy event message contains payload with information about the jeopardy condition. You can configure
the consequential that you want to perform when these events are raised by the system that configures the
Jeopardy Rules.
Jeopardy Rules can be configured through OMS UI rule configuration option.
For each of the listed jeopardy conditions, you can take any of the following possible consequential actions:
• Alert notification.
• Fulfillment Action.
Jeopardy Pre-release Order Processing
The earlier versions of FOM (FOM 2.1.0 and earlier) used to store the order and the plan information for
jeopardy in the active space data store. Now in FOM, jeopardy has been designed to work in cache (server
memory) mode. In the cache mode, jeopardy stores order and plan information in server cache (memory).
Because the implementation information of the earlier versions (FOM 2.1.0 and earlier) are not be available
in the server cache, jeopardy ignores orders that were placed prior to the FOM 2.1.1 implementation, and are
still in the execution status. Hence, it is recommended that all existing orders, placed prior to the FOM 2.1.1
implementation, should be in their logical end status, that is COMPLETED, CANCELLED, or WITHDRAWN.
Predictive Jeopardy
Predictive jeopardy is measured on several metrics:
Plan Item Start Date
Plan Duration
For plan item milestones with both point and time The overall duration of the plan can be calculated by
dependencies, it is possible that the specified time
performing a critical path analysis on the plan items
dependency is not feasible based on the durations of that compose the plan
the previously executed plan items that form the point
dependencies on the same milestone
Plan item start date predictive jeopardy determines
whether the plan item will later than the specified
start date due to the other dependencies
Plan duration predictive jeopardy determines whether
the execution duration of the plan will exceed the
design duration of the plan
TIBCO® Fulfillment Order Management User's Guide
152 | Jeopardy Management System
Jeopardy Events
The following are the types of jeopardy events:
Plan Item Jeopardy
The following table lists the jeopardy conditions for the plan item:
Plan Item Jeopardy Conditions Description
AFF-JM-PLANITEM-0100
Plan item has exceeded typical duration
AFF-JM-PLANITEM-0110
Plan item has exceeded maximum duration
AFF-JM-PLANITEM-0120
Plan item has exceeded required start
AFF-JM-PLANITEM-0200
Plan item start is predicted to exceed required start and is increasing
AFF-JM-PLANITEM-0210
Plan item start is predicted to exceed required start and is decreasing
AFF-JM-PLANITEM-0220
Plan item is no longer predicted to exceed required start
Plan Jeopardy
The following table lists the jeopardy conditions for plan:
Plan Jeopardy Conditions Description
AFF-JM-PLAN-0100
Plan has exceeded typical duration
AFF-JM-PLAN-0110
Plan has exceeded maximum duration
AFF-JM-PLAN-0120
Plan has exceeded out of scope threshold
AFF-JM-PLAN-0200
Plan is predicted to exceed typical duration and is increasing
AFF-JM-PLAN-0210
Plan is predicted to exceed typical duration and is decreasing
AFF-JM-PLAN-0220
Plan is no longer predicted to exceed typical duration
AFF-JM-PLAN-0230
Plan is predicted to exceed maximum duration and is increasing
AFF-JM-PLAN-0240
Plan is predicted to exceed maximum duration and is decreasing
AFF-JM-PLAN-0250
Plan is no longer predicted to exceed maximum duration
Order Selection for Jeopardy Management
Since Jeopardy Management System is designed to send an alert on the plan tasks that are falling behind
schedule, and to prevent the plan tasks from jeopardizing the SLA for the entire order fulfillment, JeOMS
makes some dynamic decisions when processing long and short running orders.
There are chances of orders missing SLA requirements. If such a scenraio occurs, then getting alerts on the
short running orders (orders expected to finish in 5 minutes or less) will not be helpful as sending alerts to
production support personnel, and the subsequent manual action on the alerts, will take more time than the
lifespan of the order.
Jeopardy, therefore, has a stronger focus on the long running orders (orders that are expected to run for an
hour or more). Jeopardy will process almost all the orders, but for short running orders, jeopardy may skip
some alerts that are not expected to be handled when the risk level for that alert changes to a severe one.
TIBCO® Fulfillment Order Management User's Guide
Chapter
5
Router
Here is the list of features of the Router:
1. Router redirects the order request to external Orchestrator based on routing parameter configured in the payload.
2. The routing parameter is extracted using XPATH expression.
3. Router invokes the Orchestrator services or using JMS.
4. Router also manages the table of order id of the order request and Orchestrator node that processed. Router
makes sure that any subsequent request on the order is routed to same node. For example, there are two OMS
instances deployed in the cluster.
5. Router can optionally send only the order id in the payload properties (i.e. the order request is removedfrom
the payload). The Orchestrator listener gets the payload with order Request from Activespaces hibernate second
level cache after consuming the order request.
Figure 62: Router Diagram
TIBCO® Fulfillment Order Management User's Guide
Chapter
6
Internal Error Handler
Internal Error Handler marks the failed plan items in ERROR state and gives you the control to select appropriate
action for the failed plan item.
Internal Error Handler is an optional component and you can choose to configure internal error handler. By default,
the external error handler is configured.
Internal Error Handler is designed to handle the failed plan-items. It will handle the failed plan-items in two step
process:
1. Mark the plan item state as ERROR for the plan item that failed.
2. Choose an appropriate action for the plan item in ERROR state from OMS UI. You will be able to choose
appropriate action from the following options:
a. Retry
b. Resume
c. Complete
d. MOPD
Topics
•
•
•
•
•
Internal Error Handler Data Flow Diagram
Understanding Data Flow in Internal Error Handler
Internal Error Handler Sequence Diagram
Searching for Plans with Plan Item in ERROR State
Submit the Error Resolution
TIBCO® Fulfillment Order Management User's Guide
156 | Internal Error Handler
Internal Error Handler Data Flow Diagram
The following is the data flow diagram for Internal Error Handler:
TIBCO® Fulfillment Order Management User's Guide
Internal Error Handler | 157
Understanding Data Flow in Internal Error Handler
The following steps will help you understand the data flow in the Internal Error Handler:
1. Orchestrtor sends the PlanItemExecuteRequest or PlanItemSuspend event to the process component for
each plan item.
2. In response, the process component sends PlanItemExecuteResponse event.
3. In PlanItemExecuteResponse event we have two flags: Completed and Success, and based on value of
these flags the orchestrator will take appropriate action. The following tables illustrates the same:
Complete Success Description
Technical False
Error
False/True Orchestrator will retry the process component call for the defined number
of retries with the defined retry interval. If the process component call
continues to fail, then it will refer the plan item to the Plan Item Failed
Handler.
Business
Error
True
False
Orchestrator will refer the plan item to the Plan Item Failed Handler.
Success
True
True
Processing continues as normal.
Steps 1 through 3 are part of existing implementation
4. The orchestrator will invoke the plan item Error Handler according to your configuration. Going forward
the system will consider that you have configured Internal Error Handler, and refer the Internal Error
Handler as Error Handler.
5. Plan item Error Handler will change the failed plan item state to ERROR.
6. Plan will remain in EXECUTION with one or more plan items in ERROR state.
7. You will be able to search for the plans with one or more plan items in ERROR state in OMS UI.
8. After searching for the plan with plan item in ERROR state, you can view the plan details.
9. The following image shows the plan item in Error state:
The plan item will have a tree icon with a pause on it which indicates that the plan item is paused and
needs manual intervention. The status icon is shown as
state.
which indicates that the plan item is in ERROR
10. You can access the plan item in ERROR state and take appropriate action on it. Action on the plan item
in ERROR state can be from one of the following options:
a. Retry
b. Resume
c. Complete
d. MOPD
TIBCO® Fulfillment Order Management User's Guide
158 | Internal Error Handler
11. You can take different actions on different failed plan items in the same plan. This would vary only if you
have chosen MOPD as your action for the plan item in ERROR, since MOPD as the error resolution would
act on the entire plan rather than the individual plan item.
12. You need to submit the action taken for each failed plan item.
13. After your submission, the orchestrator would initiate the action on the respective plan items.
TIBCO® Fulfillment Order Management User's Guide
Internal Error Handler | 159
Internal Error Handler Sequence Diagram
The following is the sequence diagram to show the actual sequence of the flow of data in Internal Error
Handler:
TIBCO® Fulfillment Order Management User's Guide
160 | Internal Error Handler
Searching for Plans with Plan Item in ERROR State
On the Plan tab you can search for the plans with any of its plan item in ERROR state. A new attribute has
been added named Plan Item Status with all the possible values of the plan item.
Modifying the Plan Item State
After you have searched the plans with plan item or plan items in ERROR state, you need to select the desired
plan and select the plan item in ERROR state.
In Grid view you can choose the appropriate action on the plan item and submit the chosen action. When a
plan item in ERROR state, it will be shown with an appropriate icon, the icon will represent the plan item in
ERROR state and needs user intervention.
TIBCO® Fulfillment Order Management User's Guide
Internal Error Handler | 161
Choosing Error Resolution for the Plan Item in Error State
After clicking the plan item you will get the details for the plan item. This plan item will have Status as ERROR
and will have option so that you can choose the appropriate Error Resolution and Comments for the specific
plan item.
Error Resolution is a dropdown box that contains actions that you need to perform to fix the plan item in
ERROR state. You will have following choices for the plan item’s Error Resolution:
• Retry
• Resume
• Complete
• MOPD
There can be more than one plan item in ERROR state and you need to choose error resolution for each plan
item in ERROR state. In case you dont choose the error resolution for some plan items and submit the choice
to the server, then the error resolution will be executed as per your choice for those few plan items and the
rest of the plan items will still remain in ERROR state.
Details of Each Resolution Choice
You can choose any appropriate action from the error resolution drop down box and the error resolution
chosen will be considered as a resolution choice for that particular plan item.
This changes only when you have chosen MOPD as the Error Resolution. When you choose MOPD as Error
Resolution this resolution choice would be applicable to the entire plan and not just the plan item.
The following diagram shows the State Machine diagram for different states of the plan item after user chooses
a resolution type for the plan item in ERROR state:
TIBCO® Fulfillment Order Management User's Guide
162 | Internal Error Handler
Error Resolution - RETRY
When you submit the error resolution with RETRY as the appropriate action, a new Plan Item Execute Request
will be sent for the plan item and the orchestrator will move the plan item state from ERROR to EXECUTION.
Error Resolution - RESUME
When you submit the Error Resolution with RESUME as the appropriate action, a new Plan Item Activate
Request will be sent for the plan item and the orchestrator will move the plan item state from ERROR to
EXECUTION.
Error Resolution - COMPLETE
When you submit the error resolution with COMPLETE as the appropriate action, the plan item will directly
be marked as COMPLETE by the orchestrator. The orchestrator will move the plan item state from ERROR
to COMPLETE.
Error Resolution - MOPD
You can select MOPD as the appropriate Error Resolution. MOPD action is treated at plan level which means
if you choose MOPD, then the plan will be considered for Manual modification.
And to consider the plan for MOPD we need to start by adding an Order-Header level UDF with MOPD
flag. This would be done in the background without any user intervention as soon as you submit MOPD as
the Error Resolution.
The following steps are performed after you choose to submit MOPD as the error resolution:
1. Order Header UDF is updated with MOPD flag.
2. Order amendment, with only UDF modification, is submitted.
TIBCO® Fulfillment Order Management User's Guide
Internal Error Handler | 163
3. Plan is moved to SUSPENDED state with plan items in (SUSPENDED, COMPLETE, PENDING, or ERROR)
state.
4. Plan is presented to the user for modifications.
5. After user modifications are complete, user will send the modified plan for further execution.
6. Plan item in ERROR state will be moved to EXECUTION and PlanItemExecute or PlanItemActivate
Request will be sent for this plan item depending upon the type of request that was send for this plan
item before it failed. All the other state transitions will remain intact.
TIBCO® Fulfillment Order Management User's Guide
164 | Internal Error Handler
Submit the Error Resolution
After taking the error resolution on the plan item in ERROR state, you can submit your changes. With error
resolution choice as Retry, Resume, or Complete, you can submit these error resolutions for the plan items
in ERROR state all in one go, or you can submit each error resolutions for the plan item in ERROR state
separately.
When you choose error resolution as MOPD for any of the plan item, it would impact the entire plan and not
the individual plan item in ERROR state. So once you choose the error resolution as MOPD for any of the
plan item in ERROR state, any other error resolution selection for other plan item in ERROR state will have
no impact. If there were three plan items in ERROR state and for one plan item you have chosen error
resolution as Retry, and for another plan item, which is in ERROR state, you have chosen as Resume, and
for the third plan item you chose MOPD as error resolution, then the resolution type for first two plan items
will have no impact and the MOPD process will be initiated.
If you have plan item or plan items in ERROR state, you will have an option to submit the Error Resolution.
TIBCO® Fulfillment Order Management User's Guide
Chapter
7
State Machine Pagination
A state machine is initiated for every order submitted. With large number of state machine in heap memory there
is possibility that the application may go out of memory. To control the memory usage of state machine, it is
necessary to evict the state machines from heap memory.
Eviction of state machine from heap memory will happen as follows:
1. Eviction will happen only if property "Max No of StateMachines in Heap Memory" is configured as a value
greater than 0.
2. Eviction cycle can be triggered in following two ways:
a. A Memory Cleanup thread will monitor the eviction process after every predefined interval configured as
com.tibco.fom.orch.intervalMonitoring. Within this interval before the eviction process starts it is
possible that number of state machines in memory exceeds the threshold configured depending upon the
order injection rate and other processing of the orders.
b. When there is any event coming to state machine for processing it invokes the eviction cycle to run and waits
until the number of state machine is less than or equal to the threshold configuration defined. Once the
eviction cycle completes and state machine counts is below the threshold defined further requests will be
processed.
3. As part of every eviction cycle, the application will try to find out the least used object. The application identifies
a timestamp that can be used as a threshold called the critical timesatmp and all the state machines with
timestamps smaller than this will be eligible for eviction. Memory Cleanup threads started at time of initialization
of orchestrator node runs at a predefined interval to identify the state machines which are eligible for eviction
looking at the timestamp of all the state machines. State machines which are idle for more than the configured
idle time out are selected for eviction till the count of state machines matches to the configured threshold number
which can live in memory. To identify state machine for eviction, first timestamp of all the state machines are
sorted in ascending order and then ignores the same no of state machines configured as threshold count having
highest timestamp value. Out of these timestamps which have the highest timestamp and count remains within
threshold is selected not to be evicted; the smallest timestamp is selected as critical timestamp. Any state machine
having timestamp smaller than the critical time stamp are eligible for eviction. To evict a state machine from
memory, an event is submitted to respective state machine or BatchProcessor to clear the state machine entry
from memory.
4. For any subsequent request, if state machine is not available in memory then state machine information will be
retrieved back from backing store using the data stored as state machine context checkpoint. Using this checkpoint
data, all the required data will be populated and a state machine entry will be created in memory for further
use.
5. A cleanup thread keeps running after some interval which removes the state machine context checkpoint data
along with resourceWhen order reaches to its final state then state machine entry is deleted from memory.
Topics
•
•
State Machine Pagination Sequence Diagram
State Machine Pagination Flow Diagram
TIBCO® Fulfillment Order Management User's Guide
166 | State Machine Pagination
State Machine Pagination Sequence Diagram
The following diagram represents the State Machine Pagination Sequence Diagram:
TIBCO® Fulfillment Order Management User's Guide
State Machine Pagination | 167
State Machine Pagination Flow Diagram
The following diagram represents the State Machine Pagination Flow Diagram:
TIBCO® Fulfillment Order Management User's Guide
Chapter
8
Order Capture System Overview
Order Capture System (OCS) is a new component in TIBCO Fulfillment Suite to create, manage, and submit TIBCO
Fulfillment Orchestration orders based on what a subscriber already has.
This component is a web application which you can use to do the following:
• Select subscribers
• Browse validated products, services, or bundles from TIBCO Fulfillment Catalog
• Create orders for selected subscribers and submit them to TIBCO Fulfillment Order Management
To construct an order, OCS requests information from the following systems:
• TIBCO Fulfillment Catalog, which provides product definitions for subscribers
• A subscriber inventory, which provides subscriber details (such as names, addresses, IDs, and segments)
• Offer and price engine (OPE), which provides the eligible products for a specific subscriber, validates the order,
and provides the price of what will be provisioned.
OCS then submits the orders to TIBCO Fulfillment Order Management.
The following figure illustrates the interconnection between OCS and the Fulfillment Orchestration sub-systems:
Figure 63: Order Capture System Architecture
OCS is an optional component that is a part of Fulfillment Orchestration and shipped within TIBCO Fulfillment
Order Management.
Topics
•
Order Capture System User Interface Overview
TIBCO® Fulfillment Order Management User's Guide
170 | Order Capture System Overview
•
•
•
•
•
•
Searching for Subscribers
Submitting an Order in OCS
Amending an Order in OCS
Canceling an Order in OCS
Order Capture System Error Codes and Messages
Search Syntax
TIBCO® Fulfillment Order Management User's Guide
Order Capture System Overview | 171
Order Capture System User Interface Overview
This is an example of how the products are displayed after selecting a subscriber.
Each product or bundle must be customized before you can place it in the shopping cart.
After clicking customize, the product or bundle box expands, and displays how many products are within
that bundle. To the top right of the expanded box, you can see the following three icons:
•
Add to cart
•
Full screen
•
Close
After adding a product or bundle to the cart, you can click the Display shopping cart icon
to view
the items in the cart. On the Order details page, you can hover over the item and see the Edit shopping cart
icon
and the Remove from cart
icon. Using the edit icon, you can change quantity of
products or bundles and characteristic values. Using the remove icon, you can remove products or bundles
from the cart.
After clicking CHECKOUT, you can see the Edit order option. Using the Edit order option, you can add
order priority number, delivery date, or any notes to the product. Also on the Check Out screen, you can
click the BACK TO CART button
or the PLACE ORDER
to submit the built order to TIBCO Fulfillment Order Management.
button
TIBCO® Fulfillment Order Management User's Guide
172 | Order Capture System Overview
Searching for Subscribers
Log in to Order Capture System and search for a subscriber to complete tasks such as submitting a new order,
amending an existing order, updating an order, or canceling an order.
About this task
Logging In
Log into OCS using your specific user name and password.
A timeout mechanism automatically closes the session after 15 minutes and returns to the login page.
After you are logged in, OCS reloads the previous shopping cart, if there is one. If there is not a
previous shopping cart, you must select a subscriber.
Searching for a Subscriber
Search for a subscriber based on the subscriber's first name, last name, or ID to submit, amend, update, or
cancel orders. For more information on the search syntax, see Search Syntax on page 179.
Enter the subscriber's first name, last name, or ID in the customer search box, and press Enter or click the
magnifying glass.
TIBCO® Fulfillment Order Management User's Guide
Order Capture System Overview | 173
Submitting an Order in OCS
Select a subscriber, browse TIBCO Fulfillment Catalog, customize an order for the selected subscriber, and
submit the order to TIBCO Fulfillment Order Management.
Procedure
1. Search for a subscriber. For instructions, see Searching for Subscribers on page 172.
2. From the Customer search page, click SELECT CUSTOMER.
3. Browse the product catalog in one or more of the following ways:
– Categories - Select a product from the categories list.
– Search bar - Search for products by typing specific keywords.
The search is case sensitive and supports complex searches. For more information, see Search
Syntax on page 179.
– Filters - Selected filters corresponds to a segmented list in TIBCO Fulfillment Catalog.
By default, selected filters correspond to filters set in the subscriber's profile. You can clear them
to see the impact on retrieved products.
For example, a subscriber is moving states. Clearing the local area filter can display or hide
certain products.
4. Click CUSTOMIZE for the product you would like to order. If a bundle contains more than one product,
multiple tabs are shown. Click each tab to customize each item.
5. After customizing, click SAVE TO CART or click the Add to cart icon. Repeat steps 3 and 4 to add more
items to the cart.
6. Optional: Click the shopping cart icon to review your order. From the Shopping Cart page, click the
product to view the details.
7. Click CHECKOUT. On the Checkout screen, you can complete the following tasks:
•
•
•
•
View order plan, which opens a window in the OMS UI with the corresponding order
Edit order, so you can edit details such as priority, delivery date, and notes
BACK TO CART, so you can go back to the shopping cart to add, edit, or delete products
PLACE ORDER, so you can submit your finalized order
8. Click PLACE ORDER.
After you click PLACE ORDER, you see the Confirmation screen. This screen is displayed to indicate that
OCS submitted the order to TIBCO Fulfillment Order Management.
From the Confirmation screen, you can start a new order for this customer or clear customer selection:
• NEW ORDER FOR THIS CUSTOMER - Using this feature, you can start a new order for the same
subscriber.
• CLEAR CUSTOMER SELECTION - Using this feature, you can submit an order for a different
subscriber.
If you need to make changes to a submitted order, see Amending an Order in OCS on page 174.
TIBCO® Fulfillment Order Management User's Guide
174 | Order Capture System Overview
Amending an Order in OCS
Amend an order by modifying a submitted order.
Procedure
1. Search for a subscriber. For information on how to complete this task, see Searching for Subscribers on
page 172.
2. From the Customer search page, click the subscriber's name.
3. Click View order history.
On the Order history screen, you can complete the following tasks:
• View order details.
• Modify an order.
• Cancel an order.
When order is in execution, you can view order details, modify, or cancel an order. When an order
is complete or cancelled, you can only view order details.
4. View order details, modify, or add a product.
– View order details
1. Click View order details to see all the details associated with that specific order on a read only
screen.
– Modify an order
1. Click Modify.
2. On the Shopping cart screen, click the product you would like to modify.
3. Click Edit.
4. Make any necessary changes and click FINISH EDITING.
– Add a product
1. Click Modify.
2. Click Add products.
3. Search for a product or bundle and customize.
4. Click SAVE TO CART.
5.
Optional: Click the Display Cart icon
to review the changes made.
. This must be clicked to compare orders. Click COMPARE
The "Compare orders" window does not show price details for the original order to avoid displaying
an incorrect price. Pricing models within OPE could have been changed and reloaded during the
amendment.
6.
Optional: Hover over the item, to see the edit
and remove
icons. If you click the
edit icon, you can change quantity of products or bundles and the characteristic values. If you click the
remove icon, you can remove products or bundles from the cart.
7. Click CHECKOUT.
TIBCO® Fulfillment Order Management User's Guide
Order Capture System Overview | 175
8.
Optional: Hover over the product or bundle, and click the edit icon
as priority, delivery date, and notes, and click Save.
9. Click PLACE ORDER.
to edit any order details such
After you click PLACE ORDER, you see the Confirmation screen. This screen is displayed to indicate that
OCS submitted the order to TIBCO Fulfillment Order Management.
From the Confirmation screen, you can start a new order for this customer or clear customer selection:
• NEW ORDER FOR THIS CUSTOMER - Using this feature, you can start a new order for the same
subscriber.
• CLEAR CUSTOMER SELECTION - Using this feature, you can submit an order for a different
subscriber.
TIBCO® Fulfillment Order Management User's Guide
176 | Order Capture System Overview
Canceling an Order in OCS
Cancel an order for subscribers through the Order history page.
Procedure
1. Search for a subscriber. For information on how to complete this task, see Searching for Subscribers on
page 172.
2. From the Customer search page, click the subscriber's name.
3. Click View order history.
4. Click Cancel in the ACTIONS column.
5. Click YES in the pop-up window to confirm the cancellation.
TIBCO® Fulfillment Order Management User's Guide
Order Capture System Overview | 177
Order Capture System Error Codes and Messages
Messages returned by the software consist of a code and an associated message.
The following table lists the error IDs and their descriptions.
Error Code
Error Message
Description
no server
The server is not responding.
The server is not responding to the
GUI. "no server" indicates that an
error code cannot be returned.
Please try again later.
1
The server is not responding.
Please try again later.
401
Your session has timed out.
Please sign in again.
10002
The username or password you
Every 15 minutes you are
automatically logged out of the
system. Log back in with your ID
and password.
Enter a valid email or password.
entered is invalid.
10003
The HTTP session is invalid. This
may happen if you are still on a
page when the session has expired.
Sign in to log back into the system.
Your session has expired.
Please sign in again.
10004
An HTTP request to the server is
invalid as per server authentication.
Sign in to log back into the system.
Your request is invalid.
Please sign in again.
20000
There's a problem accessing
the subscriber inventory.
Please try again later.
20100
This indicates failure to access the
Subscriber Inventory. Reasons
might be network problem,
configuration problem on the
current application, configuration
problem on the remote app, or
implementation problem (bug).
Retrying later might solve the
problem depending on the problem
nature.
There's a problem retrieving
the pricing info. Please try
again later.
20101
There's a problem retrieving
the eligible products. Please
try again later.
20102
There's a problem submitting
or modifying this order.
Please try again later.
20103
There's a problem retrieving
the plan preview details.
Please try again later.
TIBCO® Fulfillment Order Management User's Guide
178 | Order Capture System Overview
Error Code
Error Message
20104
There's a problem rebuilding
the product/bundle hierarchy.
Are the catalogs used in OCS
and in the order you want to
display the same?
20200
There's a problem accessing
the subscriber item
inventory. Please try again
later.
20201
There's a problem retrieving
the plan preview details.
Please try again later.
TIBCO® Fulfillment Order Management User's Guide
Description
Order Capture System Overview | 179
Search Syntax
The search input supports complex searches and is case sensitive. You can use this feature to search for
subscribers or products. The search input supports complex searches and is case sensitive.
Complex Searches
When you search for products or bundles, you will retrieve results with all letters in the query.
For example, if you search "co" you will retrieve results having "co" in the names, such as "computer".
If you type "sm on", you will retrieve results having both "sm" and "on" in the names, such as "smart phone".
If you type "double OR triple", you will retrieve results having either "double" or "triple" in the names, such
as "double bundle" and "triple bundle".
Case Sensitive Searches
When you search for products, the search is case sensitive.
For example, if you search 'experience', you will retrieve objects having "Experience" or "experience". If you
search for 'Experience', you will retrieve products only having "Experience".
The Search can have many tokens, that acts as an "OR":
For example, if you search 'xoom droid', you will retrieve objects having "xoom" or "droid" (and also any
combination of Xoom, XOom, DRoID).
Tokens can be protected by double quotation marks to search for a phrase:
For example, if you search '"first smart phone"' and 'first smart phone', you will not retrieve the same amount
of products.
Use a dash (-) in front of a token or phrase to exclude it from search.
For example, if you search '-droid', you will retrieve all objects that do not contain 'droid'.
TIBCO® Fulfillment Order Management User's Guide
Chapter
9
Offer and Price Engine
This chapter provides details about the Offer and Price Engine component of FOM.
Topics
•
•
•
•
Offer and Price Engine Product Model
Offer and Price Engine Price Model
Offer and Price Engine Discount Model
Offer and Price Engine Use Cases
TIBCO® Fulfillment Order Management User's Guide
182 | Offer and Price Engine
Offer and Price Engine Product Model
Offer and Price Engine (OPE) uses the same offline models schema currently being used by the TIBCO
Fulfillment Order Management engine. OPE uses the product models to get the offers configured in the
product catalog.
In terms of the OPE engine, the top level product has no autoprovisioned parents associated with it. All such
products are considered as a product offering. All such products are considered as a product offering. Using
the class and sub class feature of the product model, they can be classified into logical types.
These product models are picked up from the same offline directory as configured during the TIBCO
Fulfillment Order Management set up. The models can be made to load in the engine using the offline models
web service or the offline poller mechanism. Online integration with TIBCO Fulfillment Catalog is also
possible using the publish catalog method.
Relationships
OPE makes use of the following relationships for offer generation and validation, and price determination:
Relationship
Product Comprised Of
Characteristic
Compatible Product
Incompatible Product
Compatible Segment
Incompatible Segment
TIBCO® Fulfillment Order Management User's Guide
Description
This relationship is used to define the dependencies
between the products, which leads to decomposition
of a parent and child products.
This relationship is used to associate the characteristic
entities with a product. In addition to characteristics
that are fulfillment related, some internal
characteristics are used by the product for internal
logic. These are related to error handling. For example,
a characteristic called DECOMPOSITION is used to
filter out certain products when a condition is met,
which could be based on data from the incoming
order request.
This relationship defines that two products can exist
in an order or customer image.
This relationship defines that two products cannot
exist in an order or customer image.
This relationship defines that a product is compatible
with the segment. A product can either be compatible,
incompatible, or not related with the segment. If a
product is defined as both compatible and
incompatible in the model, it is considered as a
compatible product. Segments are grouped by
segment type.
This relationship defines that a product is
incompatible with the segment type and name.
Offer and Price Engine | 183
Relationship
Class and Subclass
Product Required For
Category
Description
This relationship can be used to classify products into
different logical types.
This relationship is used to define the prerequisite
between two products. This relationship allows you
to create offers without defining the sequence or
dependency between products. These products are
implicitly provisioned with the parent.
This relationship defines that a product belongs to a
category. A product can belong to no categories, one
category, or to many categories.
Record or Relationship Attributes
This engine uses the following record attributes and relationship attributes:
Attribute
RECORD_STATUS
Start Date
End Date
Link Definitions
Description
This record status characteristic indicates whether the
record is active or not.
This record level attribute indicates whether the
product is an eligible product for the requested order
date if it is after the start date.
This record level attribute indicates whether the
product is an eligible product for the requested order
date if it is before the end date.
This a type field in the characteristics that defines the
linking attributes, for example, subscriber ID or any
other characteristic between two products. The
LinkDefinitions are evaluated for the following
relationships:
• ProductComprisedOf
• ProductRequiredFor
• ProductRequiredFor
• IncompatibleProducts
If LinkDefinitions are provided for relationships then
these values must match with the values for UDFs
for the corresponding products in the offer and the
order request.
Filters
OPE uses the following filters to get the initial list of eligible products, which are then validated through the
normal process of eligible products evaluation:
TIBCO® Fulfillment Order Management User's Guide
184 | Offer and Price Engine
Filter
Focus
Promotions
Segment
Record Type
Record Sub Type
Category
Input Field
Order Date Filter
Description
The focus filter considers the products that are present
in the basket, or order to get the initial list of eligible
products. If the focus filter is present, the rest of the
filters are ignored. Because the product in focus is
already present with the customer, the optional
products for the selected focus is used as the initial
list of eligible products.
The products in promotions filters are directly used
to get the initial list of eligible products. If promotions
are present, all other filters except focus are ignored
to get the initial list of eligible products.
The segment filter provides a way to get a list of
products belonging to the same segment. The
products are related to segment name and segment
types. The initial list of eligible products contains
union of all the products, which include the same and
different segment types unless they have an
incompatible relationship defined. Any products that
do not have any compatible or incompatible
relationships defined are considered to be compatible
with that segment type.
This filter provides a way to get the initial list of all
the products belonging to the record type specified.
This filter provides a way to get the initial list of
products belonging to the sub record types specified.
This filter provides a way to get the initial list of
products belonging to the specified category.
This field sets linking relevant fields and returns
eligible products using those fields. This means that
it checks for the linkdefinitions from the relationships,
such as ProductComprisedOf, ProductRequiredFor,
and compatibleProducts. If those linkdefinitions are
present in the input filter list, the product is
considered as eligible.
This filter defines the order date for the request. If
this is not set, then the engine assumes the current
date as the order date.
Flags
The following flag names are for the get offer request and for the validate offer request:
Get Offer Request Flag Names
validateData
TIBCO® Fulfillment Order Management User's Guide
Offer and Price Engine | 185
Get Offer Request Flag Names
For more information, see Data Validations on page 188.
validateProductRequiredForGroups
validateProductComprisedOfGroups
validateProductCompatibility
validateSegmentCompatibility
ReturnBundleOfferings
ReturnPrices
decomposeProducts
basicValidationOnExistingOffer
Validate Offer Request Flag Names
validateData
For more information, see Data Validations on page 188.
validateProductRequiredForGroups
validateProductComprisedOfGroups
validateProductCompatibility
validateSegmentCompatibility
decomposeProducts
basicValidationOnExistingOffer
Decomposition
Eligible products are decomposed using the ProductComprisedOf and the ProductRequiredFor relationship
to get the auto provisioned products. The product is not valid if any of its auto provisioned products are
invalid due to the product integrity, segment compatibility, category compatibility, and product validity.
Product Integrity
The product integrity determines if the product is eligible for the basket and the offer.
The following checks are required for determining product integrity:
• The product status must be ACTIVE.
• The order date for the offer must fall between the start date and the end date of the product. If not, the
product is invalid.
TIBCO® Fulfillment Order Management User's Guide
186 | Offer and Price Engine
Segment Eligibility
The initial list of eligible products is checked for segment eligibility with the specified segments. All products
are considered to be compatible with the segment mentioned unless there is an incompatible relationship.
Scenario 1 - Same Segment Types with Different Segment Names
If the filter contains two segments: Segment Type = risk with Segment Name = Low and Segment Name =
High, the list of eligible products would be Product_E and Product_F.
TIBCO® Fulfillment Order Management User's Guide
Offer and Price Engine | 187
Scenario 2 - Same Segment Types with Different Segment Names and Incompatible Relationship
If the filter contains 2 segments: Segment type = risk with Segment Name = Low and Segment Name = High,
the list of eligible products would be Product_E and Product_F
TIBCO® Fulfillment Order Management User's Guide
188 | Offer and Price Engine
Scenario 3 - Different Segment Types
If the filter contains two segment types: Segment Type = Risk with Segment Name = Low and Segment Name
= High AND Segment Type = Income with Segment Name = High, the eligible product would be Product_D.
Scenario 4 - Segment Types without Products
If the filter contains a segment type without any products attached to it, all products are considered to be
compatible with the segment.
The product must be compatible with all segment types to be considered as an eligible product. Optionally,
only bundle products with dynamic products in offer can be made eligible, for example, if the customer order
does not consist of any dynamic products of any bundle in offer, that product is not eligible.
Data Validations
Data validations does all the data and UDF validations on the offer request and order request and validates
or invalidates the offer.
If the data is not validated within the request or input and active UDFs fail to their corresponding, length,
datatype, rangeValue or regularexpression, the product model gives an error message.
Property Name
Validation Flag
CheckRelevantOLUDFs
com.tibco.af.ope.flags.chkrelevantoludfs Validates UDFs attached to the
product that are defined as input
characteristics of the product. This
functionality can be switched on
using the configuration.
CheckValidOLUDFs
com.tibco.af.ope.flags.chkvalidoludfs Validates mandatory characteristics
attached to the product model that
are found in the corresponding
TIBCO® Fulfillment Order Management User's Guide
Description
Offer and Price Engine | 189
Property Name
Validation Flag
Description
product instance as UDFs in the
request. This functionality can be
switched on using the configuration.
CheckValidLinkUDFs
com.tibco.af.ope.flags.chkvalidlinkudfs Validates mandatory linking UDFs
that are attached as UDFs to the
product in the order request. This
functionality can be switched on
using the configuration.
ValidateOrderLineUDFsDatatype com.tibco.af.ope.flags.validateudfdatatype
Validates the UDFs datatype. The
datatype can be configured in the
product model. The following are
valid values: Currency, Digits, Date,
Time, and Boolean
ValidateOrderLineUDFRange
com.tibco.af.ope.flags.validateudfrange Validates the orderline UDFs are
within the range specified in the
corresponding product model. This
functionality can be switched on
using the configuration.
ValidateOrderLineUDFRegex
com.tibco.af.ope.flags.validateudfregex Validates the orderline UDFs have the
values per the regex. This
functionality can be switched on
using the configuration.
Get Offer Compatibilities
The products in the offer must be compatible with the category, input field, record type, record subtype, the
existing products in the offer, groups, and records to be eligible.
Category Compatibility
All the products in the offer must be compatible with all the categories specified.
Input Field Compatibility
This field allows to set linking relevant fields and returns and evaluates eligible products using those fields.
It checks for the link definitions from the following relationships: ProductComprisedOf, ProductRequiredFor,
and (In)compatibleProducts. If these link definitions are present in the input filter list, the product is considered
eligible. The attribute isFilter=true must be set.
Record Type and Record Sub Type Compatibility
All the products in the offer must be compatible with the record type and sub type specified. If there are
multiple record types or record sub types, the products must belong to at least one of the types and sub types
specified.
Product Compatibility
All the products in the offer must be compatible with all the products in the order. If there is no explicit
incompatibility defined, the product is compatible. Compatibility checks with all the autoprovisioned product
chains in the orderline product and the offer product. If there are no compatible products, then OPE checks
for migrations in the product, as well as consequential products. All the eligibility rules need to be applied
TIBCO® Fulfillment Order Management User's Guide
190 | Offer and Price Engine
in case of migrations. If after migration the eligibility fails, add the product to the list of ineligible products.
Each individual product is checked with only the products present in the order request for compatibility.
Eligible products are not checked with each other for compatibility.
Optionally, single use checks can be done so that the product exists only once for the customer in the order
and the product in offer (not all products in offer). The attribute SingleUSE is from the product model
characteristics that is used for this functionality.
Group and Record Evaluation
The group and record constraint of ProductComprisedOf and ProductRequiredFor are evaluated for all the
eligible products with the customer order to check if the eligible product for the customer order does not
violate the group constraints present in the product model. Eligible products are not checked with each other
for group and record violation. For more information on the group and record attributes, see Group and
Record Constraints on page 190.
Validate Offer Compatibilities
The products in the offer must be validated with segment compatibility, product compatibility, group level
compatibility, and record level compatibility.
Segment Compatibility
All the products in the offer must pass the segment compatibility validation. If any product does not pass
the validation the offer is considered invalid.
Product Compatibility
All the products in the offer must be compatible with all the products in the order. If there is no explicit
incompatibility defined, the product is compatible. Compatibility checks with all the autoprovisioned product
chains in the orderline product and the offer product. If there are no compatible products, then OPE checks
for migrations in the product, as well as consequential products. All the eligibility rules need to be applied
in case of migrations. If after migration the eligibility fails, add the product to the list of ineligible products.
Each individual product is checked with only the products present in the order request for compatibility.
Eligible products are not checked with each other for compatibility.
Optionally, single use checks can be done so that the product exists only once for the customer in the order
and the product in offer (not all products in offer). The attribute SingleUSE is from the product model
characteristics that is used for this functionality.
Group and Record Validations
The group and record constraint of ProductComprisedOf and ProductRequiredFor are evaluated for all the
eligible products with the customer order to check if the eligible product for the customer order does not
violate the group constraints present in the product model. For more information on the group and record
attributes, see Group and Record Constraints on page 190.
Group and Record Constraints
Group and record constraints check for minimum and maximum cardinality.
Group Attributes
If any product in group causes violation for groupMin or groupMax, the offer is returned as ineligible for
the get offer request and invalid for the validation request.
Following attributes are used for group evaluation:
• groupNumber specifies the unique identifier for the group. If there is no groupNumber specified the product
ID is considered as the group number so the product is in its own group.
TIBCO® Fulfillment Order Management User's Guide
Offer and Price Engine | 191
•
•
groupMin
groupMax
specifies the minimum number of products that must be ordered for a bundle.
specifies the maximum number of products that can be ordered in a bundle.
Record Attributes
If the any product in the offer causes a record violation, the offer is returned as ineligible for the get offer
request and invalid for the validation request
Following attributes are used for record evaluation:
• RecordMin specifies the minimum number of products that must be ordered for a bundle.
• RecordMax specifies the maximum number of products that can be ordered in a bundle.
TIBCO® Fulfillment Order Management User's Guide
192 | Offer and Price Engine
Offer and Price Engine Price Model
OPE uses the price models to get the prices configured in the price catalog and correlates these prices to a
given product based on relationship.
Price models can be loaded in the engine using the offline or the online integration, or both online and offline
integration with TIBCO Fulfillment Catalog. For more information on integrating the price models offline,
see Integrating TIBCO Fulfillment Catalog Price Models Offline on page 195. For more information on
integrating the price models online, see Integrating TIBCO Fulfillment Catalog Discount Model Offline on
page 201.
Pricing Fields
The following pricing fields are the basic fields applicable to all price types.
Pricing Field
RECORD_TYPE
Record Satus
Start Date/Start Time, End Date/End Time,
Duration/Duration UOM
Charge Value
Currency
Charge Priority
Min Amount
TIBCO® Fulfillment Order Management User's Guide
Description
This field defines the price type of the price. Valid
values are TARIFFUSAGE, USAGE, FIXED,
RECURRING, COMPOSITE, ONE_TIME, and
MIGRATION_FEE.
This characteristic defines if a price is valid. If it is set
to true the price is used for the calculation. If not, the
price is ignored.
These characteristics are used to define the validity
of a price in a certain time frame. None of these fields
are mandatory. If the End Date/End Time is not
present, it is calculated based on the Start Date/Start
Time and the Duration/Duration UOM if they are
present. Duration UOM can have Year, Month, Week
and Day as valid parameters. If only Start or End
parameters are defined, only that boundary is taken
into account to verify the validity of that price.
This characteristic is used to specify the amount in a
dot separated manner.
This characteristic is used to specify the type of
currency for the price.
This characteristic is used if a product provides
several prices, whereby the priority provides the
system a way to choose which charge to bill the
customer. Therefore the price with the higher Charge
Priority is taken. Lower the number the higher the
priority.
This field attributes the minimum amount a price can
have. If a price is reduced by multiple discounts, it is
possible to reduce the price to a negative amount. The
Offer and Price Engine | 193
Pricing Field
Description
MinAmount attribute prevents that as it sets the
amount to the specified value if the prices value falls
below that limit. In the end, all kinds of price and
discount selections are done and all discounts, which
are attached to the price, are returned even, if they
have not been applied due to the MinAmount.
Price Types
The following pricing types can be used in the OPE Price Model:
Price Type
ONE_TIME price
RECURRING Price
Description
This type specifies a non-recurring (one-off) charging
element defined as fixed monetary values. This is
modeled as a One-Time Price. One_Time prices are
created by setting the Class to 'ONE_TIME'.
CHARGE_PER, CHARGEMINBOUNDARY and
CHARGEMAXBOUNDARY are not used.
This type specifies recurring charging element defined
as monetary values. This is modeled in TIBCO
Fulfillment Catalog as a RECURRING price. Recurring
prices are created by setting the class to RECURRING.
Prices with Boundaries should not be attached
directly to a Product. The reason is that it is
nearly impossible to distinguish if the Prices
should coexist for a Product or if they rule
each other out. In order to accomplish this
coexistence use a composite price and attach
the according prices with boundaries as
children to that composite price.
Usage Price
This type specifies a usage based charging elements
defined as monetary values. This is modeled in TIBCO
Fulfillment Catalog as a usage price. Usage prices are
created by setting the class to USAGE.
Prices with Boundaries should not be attached
directly to a Product. The reason is that it is
supported to distinguish if the Prices should
coexist for a Product or if they rule each other
out. In order to accomplish this coexistence
use a composite price and attach the according
prices with boundaries as children to that
composite price.
COMPOSITE
The composite price is not calculated as a price itself
but is meant as a container for child prices. This
container can be used to reuse existing prices as
children and put one discount on all these children.
TIBCO® Fulfillment Order Management User's Guide
194 | Offer and Price Engine
Relationships
Restrictive relationships are used to make a price applicable only to certain compositions of products, segments
or characteristics in a request. The following table explains the different types of relationships used and their
behavior.
Relationship
ProductPricedBy
Description
Prices are attached to a product using the
ProductPricedBy relationship. This relationship has
an attribute ChargePriority, which specifies the
priority in which the charges should be applied in
case there are multiple prices associated. If the
ChargePriority attribute is equal for several prices, in
a case of multiple prices of the same type, prices are
chosen based on the restrictions it has. So if there are
2 valid prices configured for a product, the application
takes the price with more and higher valued
restrictions first.
Choosing a mechanism is only performed for
prices of the same class attached to the same
product. For example, ONE TIME prices will
not be compared to RECURRING prices.
PriceRequiresSegment
The PriceRequiresSegment relationship is used to
model prices, which should be offered only to
customers belonging to a certain segment. Prices can
have PriceRequiresSegment relationships to multiple
Segments. In that case, the price only is only taken if
all the segments are passed in the getPrices request.
PriceRequiresSegment relationship is
considered as the most important relationship
when choosing between different prices for a
product.
PriceRequiresProductGroup
The PriceRequiresProductGroup relationship is used
to model prices which should only be offered when
ordering a certain composition of products. The
PriceRequiresProductGroup relationship is considered
as the second highest after PriceRequiresSegment
relationship when choosing between different prices
for a product.
The PriceRequiresProductGroup repository has 3
flags in the Scope tab named CalculatedProducts,
RelatedProducts and LinkedOnly. The
CalculatedProducts and RelatedProducts flags define
if the RequiresProductGroup only 'searches' in
CalculatedProducts and in RelatedProducts passed
in with the request. The LinkedOnly parameter
defines if the search is only restricted to other
CalculatedProducts and RelatedProducts sharing the
same defined LinkDefinitions as the one the price
TIBCO® Fulfillment Order Management User's Guide
Offer and Price Engine | 195
Relationship
Description
needs to be applied to both products to have the same
Subscriber.
The default values for CalculatedProducts and
RelatedProducts is true and false for LinkedOnly, the
engine looks for all products specified in the request
unless it is specifically configured in a different
fashion in the RequiresProductGroup. If
LinkDefinitions is not configured, it is set to
SubscriberID by default.
PriceRequiresCharacteristic
The PriceRequiresCharacteristic relationship is used
to model different prices for a product based on their
characteristic value. Prices can have
PriceRequiresCharacteristic relationships to multiple
Characteristics.
The PriceRequiresCharacteristic relationship
is considered as the least important
relationship when choosing between different
prices for a product
PriceComprisedOf Relationship for Price and Product
Prices on a bundle level are either aggregated prices
of the underlying offerings or set directly on the
bundle level and ignore the prices of the underlying
offerings. Both product and price can have children,
which are aggregated towards the parent. The
SubClass attribute with value Override prevents this,
and the price acts as an override. PriceComprisedOf
relationship fulfills these requirements, but the
Price.PriceComprisedOf relationship can be used to
reuse multiple existing prices as children and attach
a discount on all children by using the
PriceAlteredByDiscount relationship on the parent
level of the containing price. The override behavior
of parent prices are transferred to all child prices. A
child price has to have the same class as the parent
otherwise it will be ignored on runtime. In order to
group multiple prices with different types, the
composite price has to be used.
Integrating TIBCO Fulfillment Catalog Price Models Offline
Price models can be loaded in to the engine using the offline online integration with TIBCO Fulfillment
Catalog. The offline format for price models must conform to the schema used by TIBCO Fulfillment Catalog
to generate the models.
Procedure
1. Set the following configurations for OPE to consume the price models offline using poller mechanism or
offline web service.
<Category description="Price Catalog Configuration" name="Price Catalog Configuration"
visibility="Advanced">
<ConfValue description="Use offline price" name="Use offline price"
TIBCO® Fulfillment Order Management User's Guide
196 | Offer and Price Engine
propname="com.tibco.fom.oms.afi.offline.price.use" sinceVersion="3.0"
visibility="Advanced">
<ConfBool default="false" value="true"/>
</ConfValue>
<ConfValue description="Price catalog poller and WS directory" name="Price catalog
poller and WS directory" propname="com.tibco.fom.oms.afi.offline.price.directory"
sinceVersion="3.0" visibility="Advanced">
<ConfString default="/usr/tibco/price" value="="/usr/tibco/price "/>
</ConfValue>
<ConfValue description="Price catalog import success poller and WS directory"
name="Price catalog import success poller and WS directory"
propname="com.tibco.fom.oms.afi.offline.price.importsuccess.directory"
sinceVersion="3.0" visibility="Advanced">
<ConfString default="/usr/tibco/price-success" value="="/usr/tibco/price-success
"/>
</ConfValue>
<ConfValue description="Price catalog import failure poller and WS directory"
name="Price catalog import failure poller and WS directory"
propname="com.tibco.fom.oms.afi.offline.price.importfailure.directory"
sinceVersion="3.0" visibility="Advanced">
<ConfString default="/usr/tibco/price-failure" value="="/usr/tibco/price-failure
"/>
</ConfValue>
</Category>
2. For the web service, set the following parameter to true in the service request:
<off:PriceOffline>true</off:PriceOffline>
3. Create the following topic:
tibco.aff.ope.events.price.publish
Get Prices Determinations and Calculations
All products in the get prices service are decomposed. Prices and discounts are determined in the offer; then
the price is calculated.
Product Decomposition
All products defined in CalculationProduct(s), OptionalProduct(s) are decomposed in their auto provisioned
child products. CalculationProducts are decomposed in their optional or non-auto provisioned children. In
order to identify optional children, the parent product and the child product need to share the same
LinkDefinitions, such as the same subscriber, or certain UDFs. The fields that are taken for the link are specified
in the ProductComprisedOf relationship. This enables the pricing part of OPE to detect child products. When
setting LinkedOnly in the ProductRequiredForPriceGroup and ProductRequiredForDiscountGroup, the
LinkDefinitions can differ from the LinkDefinitions that are used to decompose products.
Price Determination
The prices for each product are determined on their priority for the product. In case of the priority being
same the weight for the price is decided as per the relationships. The price is determined for the quantity
mentioned for the calculation product. This means if the quantity is specified >1 then the price is mapped
for each price type (CLASS) until all the quantities are exhausted for that price type. The price for the parent
price is calculated first. Then the child prices using the pricecomprisedof relationship are calculated for the
parent price quantity and are then aggregated towards the parent price. The quantity is reset for each new
price type.
Discount Determination
The discount for the price is determined as per the priority mentioned in the price model using the
PriceAlteredByDiscount relationship. In case the priority has the same weight for the discount, it is decided
as per the relationships. The engine determines discounts for each price quantity. Unit discounts are detected
for the complete quantity of the price. Discounts for child prices are applied before applying the parent price
discount. Parent Price discounts are applied to the child prices as well.
TIBCO® Fulfillment Order Management User's Guide
Offer and Price Engine | 197
Price Calculation
After price and discount determination, all prices are resolved by aggregating child price elements up the
respective price level. In the top level prices creation process, all attached discounts are applied accordingly,
and price amounts are adjusted accordingly. Discounts are applied in the following order or with the following
conditions:
• If a discount has child discounts, first the parent discount is applied and then the child discount. If a
discount has multiple direct children, the children are applied according to their order.
• The discount on a child price is applied first.
• If a parent price has a discount, the discount is applied both to the parent price and the child price.
TIBCO® Fulfillment Order Management User's Guide
198 | Offer and Price Engine
Offer and Price Engine Discount Model
OPE uses the discount models to get the discounts configured in the discount catalog and correlates these
discounts to a given price based on relationship.
Discount Fields
The following discount fields are the basic fields applicable to all discount types.
Pricing Field
RECORD_TYPE
Start Date/Start Time, End Date/End Time,
Duration/Duration UOM
Discount Value
Currency
Discount Priority
Description
This field defines the record type of the discount.
Valid values are DISCOUNT.
These characteristics are used to define the validity
of a price in a certain time frame. None of these fields
are mandatory. If the End Date/End Time is not
present, it is calculated based on the Start Date/Start
Time and the Duration/Duration UOM if they are
present. Duration UOM can have Year, Month, Week
and Day as valid parameters. If only Start or End
parameters are defined, only that boundary is taken
into account to verify the validity of that price.
The discount value for the discount model.
This characteristic is used to specify the type of
currency for the price.
This characteristic is used if a product provides
several prices, whereby the priority provides the
system a way to choose which charge to bill the
customer. Therefore the price with the higher Charge
Priority is taken. Lower the number, the higher the
priority.
This field is used if a price has multiple discounts,
whereby the priority provides the system a way to
choose which discount to attach. Therefore the
discount with the higher (lower number)
DiscountPriority will be taken.
If the DiscountPriority is equal for several discounts
in case of multiple discounts attached to a price, the
discount will be chosen based on the restrictions it
has. So if there are 2 valid discounts configured for a
price, the application takes the discount with more
or higher valued restrictions first. For example, for
Price A there are 3 discounts configured. Discount A
without any DiscountRequires restriction, Discount
B with a DiscountRequiresProduct restriction, and
Discount C with a DiscountRequiresSegment
restriction. For a getPricesRequest which fulfills the
TIBCO® Fulfillment Order Management User's Guide
Offer and Price Engine | 199
Pricing Field
Description
restrictions of all 3 discounts, then Discount C is taken
as it has the highest value restriction. For a
getPricesRequest which fulfills only the restrictions
of Discount A and B, then Discount B is taken as it
has the highest value restriction. Multiple restrictions
sum up whereby the summed value will be taken for
the determination of which discount to choose.
Discount Types
The following discount types can be used in the OPE Price Model:
Price Type
DISCOUNTUOM
Description
Percent or Flat is used to define if the discount is
altering a price in percent manner or in a total
reduction manner; valid values are percent or flat.
Relationships
Restrictive Relationships are used to make a discount applicable only to certain compositions of products,
segments or characteristics in a getPrices request.
Relationship
DiscountRequiresProduct
Description
The DiscountRequiresProduct relationship is used to
model discounts which should only be applied when
ordering a certain composition of products. The
ProductRequiredForDiscount is used since it follows
a different mechanism and offers more flexibility in
terms of modeling capabilities. Discounts can have
ProductRequiredForDiscount relationships to multiple
Products.
All groups need to be fulfilled in order to
make the discount applicable.
The ProductRequiredForDiscount relationship
is considered as the lower important type after
DiscountRequiresSegment relationship when
choosing between different prices for a
product.
ProductRequiredForDiscount
The RequiresProductGroup repository has 3 flags in
the Scope tab named CalculatedProducts,
RelatedProducts and LinkedOnly. The
CalculatedProducts and RelatedProducts flags define
if the RequiresProductGroup only 'searches' in
CalculatedProducts or in RelatedProducts passed in
with the request. The LinkedOnly parameter defines
if the search is only restricted to other
CalculatedProducts and RelatedProducts sharing the
same defined LinkDefinitions as the one the discount
TIBCO® Fulfillment Order Management User's Guide
200 | Offer and Price Engine
Relationship
Description
needs to be applied to, for example, if the
LinkDefinition is SubscriberID, both products have
to have the same Subscriber.
The default values for CalculatedProducts and
RelatedProducts is true and false for
LinkedOnly, so the engine will look for all
products specified in the request unless it is
specifically configured in a different fashion
in the RequiresProductGroup.
If LinkDefinitions is not configured, it will be
set to SubscriberID by default.
DiscountRequiresSegment
The DiscountRequiresSegment relationship is used
to model discounts which should be offered only to
customers belonging to a certain segment. Discounts
can have DiscountRequiresSegment relationships to
multiple segments. In that case, the discount will only
be taken if all the segments are passed in the getPrices
request.
The DiscountRequiresSegment relationship is
considered as the most important relationship
when choosing between different prices for a
product.
DiscountRequiresCharacteristic
The DiscountRequiresCharacteristic relationship is
used to model different discounts for a price based
on a characteristic value of the corresponding product.
Discounts can have DiscountsRequiresCharacteristic
relationships to multiple characteristics. In that case
all the restrictions need to be fulfilled in order to make
the discount applicable.
The DiscountRequiresCharacteristic
relationship is considered the least important
relationship when choosing between different
discounts for a price.
DiscountComprisedOf
This relationship is used to reuse existing discounts
as children and apply an aggregated discount based
on the discount amount of the children.
A child discount has to have the same discount
type (Percent or Flat) as the parent otherwise
it will be ignored
TIBCO® Fulfillment Order Management User's Guide
Offer and Price Engine | 201
Integrating TIBCO Fulfillment Catalog Discount Model Offline
Discount models can be loaded in the engine using the offline or online integration with TIBCO Fulfillment
Catalog. The offline format for discount models must conform to the schema used by TIBCO Fulfillment
Catalog to generate the models.
About this task
OPE uses the discount models to get the discounts configured in the discount catalog and correlates these
discounts to a given price based on the relationship.
Procedure
1. Set the following configurations for OPE to consume the price models offline using poller mechanism or
offline web service.
<Category description="Discount Catalog Configuration" name="Discount Catalog
Configuration" visibility="Advanced">
<ConfValue description="Use offline discount" name="Use offline
discount" propname="com.tibco.fom.oms.afi.offline.discount.use" sinceVersion="3.0"
visibility="Advanced">
<ConfBool default="false" value="true"/>
</ConfValue>
<ConfValue description="Discount catalog poller and WS
directory" name="Discount catalog poller and WS directory"
propname="com.tibco.fom.oms.afi.offline.discount.directory" sinceVersion="3.0"
visibility="Advanced">
<ConfString default="/usr/tibco/discount"
value="/usr/tibco/discount"/>
</ConfValue>
<ConfValue description="Discount catalog import success poller
and WS directory" name="Discount catalog import success poller and WS directory"
propname="com.tibco.fom.oms.afi.offline.discount.importsuccess.directory"
sinceVersion="3.0" visibility="Advanced">
<ConfString default="/usr/tibco/discount-success"
value="/usr/tibco/discount-success"/>
</ConfValue>
<ConfValue description="Discount catalog import failure poller
and WS directory" name="Discount catalog import failure poller and WS directory"
propname="com.tibco.fom.oms.afi.offline.discount.importfailure.directory"
sinceVersion="3.0" visibility="Advanced">
<ConfString default="/usr/tibco/discount-failure"
value="/usr/tibco/discount-failure"/>
</ConfValue>
</Category>
</Category>
2. For the web service, set the following parameter to true in the service request:
<off:DiscountOffline>true</off:DiscountOffline>
3. Create the following topic:
tibco.aff.ope.events.discount.publish
TIBCO® Fulfillment Order Management User's Guide
202 | Offer and Price Engine
Offer and Price Engine Use Cases
Review the different use cases to have a better understanding of the different scenarios OPE can be used for.
Testing Product Eligibility Scenarios
Test product eligibility with these five scenarios.
Scenario 1 - Testing with the SegmentsCompatibleWith Filter
Send an eligibility request using the SegmentCompatibleWith filter.
Procedure
1. Create three products: Phone1, Phone2, Phone3.
2. Set the following segment type and segment names for Phone1, Phone2, and Phone3:
• Phone1 is compatible with segmentType = country and segmentName = US.
• Phone2 is compatible with segmentType = country and segmentName = Canada.
• Phone3 is compatible with segmentType = country and segmentName = US.
3. Request eligible products with the segment filter as segmentType
= country
and segmentName
= US.
Results
Passing this specific segment filter in the eligibility request retrieves Phone1 and Phone3 as eligible products
for the order because they are compatible with the segment type.
Scenario 2 - Testing with the SegmentCompatibleWith RecordType Filter
Send an eligibility request using the SegmentCompatibleWith RecordType filter.
Procedure
1. Create three products: Phone1, Phone2, Phone3.
2. Set the following segment types and names for Phone1, Phone2, and Phone3:
• Phone1 as segmentType = country and SegmentName = US
• Phone2 as segmentType = country and SegmentName = Canada
• Phone3 as segmentType = country and SegmentName = US
3. Set the following RecordTypes types for Phone1, Phone2, and Phone3:
• Phone1 as RecordType = White
• Phone2 as RecordType = White
• Phone3 as RecordType = Black
4. Request eligible products for segmentType
= country, segmentName = US
and RecordType
= White.
Results
Passing this specific segment in the eligibility request and this specific RecordType retrieves only Phone1
because it is compatible with the segment and with the RecordType.
TIBCO® Fulfillment Order Management User's Guide
Offer and Price Engine | 203
Scenario 3 - Testing with the flag ReturnBundleOfferings Enabled
Send an eligibility request when the flag ReturnBundleOfferings is enabled.
Procedure
1.
2.
3.
4.
5.
6.
Create a group with Phone1 and SIM_Card as the parent products and Data_Plan as the child product.
Create another group with Phone2 as the parent product and Data_Plan as the child product.
Set autoprovision = true for Data_Plan.
Set the ReurnBundleOfferings = true.
Add Data_Plan to your order.
Send a request for all eligible products.
Results
Phone1, Phone2, and SIM_Card are returned as eligible products with Data_Plan in the order.
Scenario 4 - Testing with the Focus Filter with Different Product Types and autoprovision=true
Send an eligibility request using the focus filter for products with different types when some products have
autoprovision set to false and others set to true.
Procedure
1. Set a hierarchy of products with different ProductTypes.
2. Have some products with autoprovision = true and some with autoprovision
= false.
TIBCO® Fulfillment Order Management User's Guide
204 | Offer and Price Engine
3. Set the flag decompose products = false, so the eligible products are not decomposed for autoprovision
= true and for product and product type filter. The autoprovisioned products are still evaluated for
segment and product compatibility.
4. Request eligible products for ProductType = Family and ProductType = PO.
Results
Passing the specific ProductTypes in the eligibility request retrieves Product 1, Product 2, Product 3, Product
4, and Product 6 because they are compatible with the ProductType and with decomposeproducts = false.
Scenario 5 - Testing with Maximum Number of Products in a Group is Reached
Send an eligibility request when maximum number of products in a group is reached.
Procedure
1.
2.
3.
4.
Create a hierarchy of products within a group. Name the group Phone Bundle.
Set the maximum number of instances of the products in the group to two.
Add two products from the Phone Bundle group to the order.
Children from the Phone Bundle group are evaluated for eligibility.
Results
All the remaining children in the Phone Bundle group are not eligible because the group has a restriction of
maximum number of two, so only one Bundle Product can be eligible.
TIBCO® Fulfillment Order Management User's Guide
Offer and Price Engine | 205
Testing Product Validation Scenarios
Test product validation with these nine scenarios.
Scenario 1 - Testing with Maximum Number of Products in a Group is Reached
Send a validation request when maximum number of products in a group is reached.
Procedure
1.
2.
3.
4.
Create a hierarchy of products within a group. Name the group Charging Bundle.
Set the maximum number of instances of the products in the group to four.
Add five products from the Charging Bundle to the order.
Send a request of validation for the order.
Results
The validation triggers an error because the Charging Bundle only supports a maximum of four.
Scenario 2 - Testing with Minimum Number of Products in a Group is Not Reached
Send a validation request when the minimum number of products in a group is not reached.
Procedure
1.
2.
3.
4.
Create a hierarchy of products within a group. Create two products in that group: Phone1 and Phone2.
Set the restriction of a minimum number of one for products within the group.
Do not add Phone1 or Phone2 to the order.
Send a request of validation for the order.
Results
The validation triggers an error because the group is defined to have at least one element.
Scenario 3 - Testing with the Compatibility Relationship
Send a validation request with products that are incompatible.
Procedure
1. Create two products that are incompatible with each other.
2. Add both products to your basket.
3. Send a request of validation for the order.
Results
During validation, an error occurs due to the incompatibility rule set for both products.
Scenario 4 - Testing with Multiple Combinations
Procedure
1. Create a hierarchy of products called Offer_A. Make Offer_A ProductComprisedOf SIM. Make SIM
comprised of SIM_Group which is ProductComprisedOf Option1, Option2, and Option3.
2. Create a hierarchy of products called Offer_B. Make Offer_A ProductComprisedOf SIM. Make SIM
comprised of SIM_Group which is ProductComprisedOf Option1, Option2, and Option3.
TIBCO® Fulfillment Order Management User's Guide
206 | Offer and Price Engine
3. Set the following rules for the products:
• Offer_A incompatible with Offer_B
• Option1 incompatible with Option3
• Option2 incompatible with Option3
• Option3 incompatible with Option_C
4. Add to your order Offer_A with two Option1, one Option2, and one Option3.
5. Add to your order Offer_B with OptionA, OptionB, and OptionC.
TIBCO® Fulfillment Order Management User's Guide
Offer and Price Engine | 207
Results
The order returns an error because it is not eligible due to the following constraints:
• In Offer_A, the maximum number for any of the Options is two.
• In Offer_A, Option1 and Option2 are incompatible with Option3.
• Offer_A is incompatible with Offer_B.
• Option_C is incompatible with Option3.
Scenario 5 - Testing with Required UDF Input
Send a validation request when UDF input is required.
Procedure
1. Create a product in which you have defined that the input characteristic gender must be passed in the
request.
2. Set the gender characteristic to active.
3. Set the flag validateData = true in the offer validation request.
4. Add the product to your basket without defining the gender.
TIBCO® Fulfillment Order Management User's Guide
208 | Offer and Price Engine
Results
You get an error in the reply during validation when that product is in your basket and the flag validateData
= true without the UDF gender entry.
Scenario 6 - Testing with ProductRequiredFor with a Group and One Element Passed
Send a validation request with a product group and one element that is not passed.
Procedure
1. Create a group that has the restriction of minimum and maximum number of one and ProductComprisedOf
two products: Phone and SIM_Card.
2. Make the phone product have a ProductRequiredFor relationship for the products Data1 and Data2.
3. In the relationship with Data1 and Data2, define the maximum number of one.
4. Add Data1 and Data2 to your basket.
Results
During validation when you add both products to your basket, an error occurs because the maximum number
is defined as one.
Scenario 7 - Testing ProductRequiredFor with No Group and One Element Not Passed
Send a validation request with no group and one element that is not passed.
Procedure
1.
2.
3.
4.
5.
Create a product bundle that has ProductComprisedOf Phone1.
Set Phone1 ProductComprisedOf SIM_Card.
Set SIM_Card to have ProductRequiredFor Data_Plan.
Set Data_Plan with a restriction of minimum and maximum number of one.
Add Data_Plan and SIM_Card to your basket.
Results
During validation when you add both products (the product bundle and Data_Plan) to your basket, an error
occurs because the minimum and maximum number is defined as one for Data_Plan, which was already
added to the basket from the product bundle.
Scenario 8 - Testing LinkDefinitions with Restrictions with Maximum Number of Products
Send a validation request with LinkDefinitions with a maximum number of products restriction.
Procedure
1.
2.
3.
4.
5.
Create a parent product called Parent1 with ProductComprisedOf a child product called Child1.
Define a record level restriction for Child1 of maximum number of one.
Add group level restriction of maximum number of one.
In the relationship ProductComprisedOf, define a LinkDefinitions value composed by name and address.
Add two pairs of one Parent1 and one Child1 with different values for name and address UDFs to the
basket.
Results
This validation is successful because each pair has a maximum of one Child1 and defines the name and
address for both products.
TIBCO® Fulfillment Order Management User's Guide
Offer and Price Engine | 209
Scenario 9 - Testing LinkDefinitions with Restrictions with Maximum Number of Products in a Group
Send a validation request with LinkDefinitions with a maximum number of products in a group restriction.
Procedure
1.
2.
3.
4.
5.
Create a parent product called Parent1 that ProductComprisedOf a child product called Child1.
Define a record level restriction for Child1 of maximum number of two.
Add a group level restriction of maximum number of one.
In the relationship ProductComprisedOf, define a LinkDefinitions value composed by name and address.
Add one Parent1 and two Child1 with same values for name and address UDFs to the basket.
Results
This validation is unsuccessful because Parent1 has two Child1 associated due to the same name and address
UDF values, while just one child per group is allowed.
TIBCO® Fulfillment Order Management User's Guide
Chapter
10
Fulfillment Order Management User Interface
®
This section describes the TIBCO Fulfillment Order Management user interface.
Fulfillment Order Management (FOM) application provides:
• a visual interface to view order details, order execution plans, plan for Fulfillment Provisioning, jeopardy rule
configuration and activity logs
• facility to search orders fast
• a complete view of orders that were fulfilled or failed during the fulfillment process
• end-to-end tracking, storing and monitoring capability for orders in the order fulfillment system
• capability to perform actions on the orders being executed in the system
• add and submit order in FOM through OMSUI
• show plan preview which provides a view of the plan without adding it into FOM
The date is in the MM/DD/YYYY HH:MM:SS Z format, where Z is the time zone where the request is processed.
For instance, UTC-7. You can configure the date from the Fulfillment Configurator.
You can perform the following actions on Fulfillment Order Management:
Fulfillment Order
Management Actions
Description
Dashboard-specific
actions
Viewing Dashboard: View the Fulfillment Order Management Dashboard for
summarized information about:
Orders Panel
• Order Summary
• Orders in Execution
• Backlog Orders
• Amended Orders
Jeopardy Panel
• Orders in Jeopardy
• Jeopardy Live Alerts
• Jeopardy Recorded Alerts
For details, refer to Dashboard on page 219 .
Order-specific actions
Fulfillment Order Management allows you to:
• View order Details
• Search orders
• Amend orders
• Add orders
• Show Plan preview for orders
For details, refer to Orders Page on page 226.
TIBCO® Fulfillment Order Management User's Guide
212 | Fulfillment Order Management User Interface
Fulfillment Order
Management Actions
Description
Plan-specific actions
Perform the following plan specific actions in the Fulfillment Order Management.
• View Plan Details
• Search plan
• View GANTT chart for the plan
• Dependency View for the plan
Activity Log
Shows the status and revision history of an object (order or a plan) and Fulfillment
Provisioning (FP) logs based on the following criteria:
• Order Ref
• Plan Id
• Rule Name
• FP Order Id
• FP OrderLine Id
• FP Resource Id
• FP TechnicalOrder Id
All the FP related options are displayed only if FP configuration is enabled.
For details, refer to About Activity Log on page 266.
Rule Config
The Rule Config panel allows you to add rule to receive Jeopardy notification on
configured channel or invoke specific service if order is in jeopardy according to the
configured condition.
There are two notification types:
1. Service
2. Notification
If you choose the 'service' as notification type, provide the service parameters in the
respective tab.
The notification channels are:
1. JMS
2. File
3. Tibbr
4. SMTP
Catalog
The Catalog panel allows you to view the catalog model associated with the OMS user
interface.
You can:
1. View a catalog model of all products.
2. Navigate from the order's product ID to view the specific catalog model w.r.t. product
ID.
The Fulfillment Order Management also describes the functionalities of Fulfillment Provisioning related to:
• Activity log
• FP Service Order Hierarchy
• Display Service Order (attributes, parameters, and service logs)
Topics
TIBCO® Fulfillment Order Management User's Guide
Fulfillment Order Management User Interface | 213
•
•
•
•
•
•
•
•
Navigation
Changing Password
OMS User Interface Logging Notifications
Fulfillment Order Management Functionality
Fulfillment Provisioning Service Order Hierarchy
Fulfillment Provisioning Attributes and Parameters
Searaching for Fulfillment Provisioning Components
Third Party Access to Fulfillment Order Management User Interface
TIBCO® Fulfillment Order Management User's Guide
214 | Fulfillment Order Management User Interface
Navigation
Access to the Dashboard is controlled through basic username and password authentication.
To access TIBCO Order Management System form a browser window, perform the following steps:
All latest versions of Google Chrome, Mozilla FireFox, and Internet Explorer are supported by OMSUI.
1. Go to the URL http://<host>:<port number>/omsui/Login/Login.jsp to access the Login page where:
– host is the computer where you installed the Fulfillment Order Management.
– port is the port number of the machine where Fulfillment Order Management installation listens to
the requests. The default port number is 8080.
You can configure host and port from the Fulfillment Configurator.
Figure 64: Fulfillment Order Management Login
2. Enter the username and password to sign in. The default username and password is admin. The Fulfillment
Order Management Dashboard is displayed. For details, see Dashboard on page 219
Figure 65: Fulfillment Order Management Dashboard
TIBCO® Fulfillment Order Management User's Guide
Fulfillment Order Management User Interface | 215
Changing Password
Fulfillment Order Management allows you to change your password in the dashboard. To change the
password:
1. Login to the Fulfillment Order Management.
2. On the top right corner, click Change Password.
Figure 66: Change Password
3. In the Change Password dialog, enter your existing password, new password, and re-enter your new
password to confirm the change.
Figure 67: Change Password Dialog
4. Click Save to successfully change your password. Click Cancel to exit without saving the new password.
TIBCO® Fulfillment Order Management User's Guide
216 | Fulfillment Order Management User Interface
OMS User Interface Logging Notifications
OMS user interface is updated with bootstrap growls that are used for different status of messages like info,
error, and warning, which align themselves based on an order.
A notification label with a notification count on OMS user interface is introduced that shows the number of
notifications.
When clicked it shows the notification details for each level of logs.
Clicking the notification label opens a notification pop up that maintains a different log details based on level.
Alert and Confirmation Box
Alert and confirmation box ui has been changed to facilitate the user to view on upper center of OMSUI page
irrespective of browser. Alerts can be of three types: Warning, Error and Success. Each have respective icons.
The following images are the user interface for Alert and Confirmation window:
TIBCO® Fulfillment Order Management User's Guide
Fulfillment Order Management User Interface | 217
Growls for Information and Error Messages
Information and error messages has been removed from the top of the tab and each information and error
will be shown in growls with respect to their log level.
Growl shown will have fade timeout and can be closed by user.
Notification Logger
Notification Logger lets you view the count of logging notifications as well as their details. You can view
previous and present client side logs on the OMSUI.
The following are some of the major functionalities of Logger notification:
• Notification label implemented in OMSUI next to logged in <Username> label.
• Initially No Notification label will be shown, when there is no notification for the system is logged after
login to OMSUI.
• There will be a counter maintained for the number of notifications for each info, error, and warning
messages logged in to the OMSUI.
• You can see previous and present logs for the system.
• Notification label will be shown in blue color until a critical log is logged into the system.
• Notification label will be shown in red if there is at least one critical or error notification logged and it is
present in notification detail window.
TIBCO® Fulfillment Order Management User's Guide
218 | Fulfillment Order Management User Interface
• There will be a pop-over window for detailed description of different level of logs.
• User interface for log details shown will depend upon the level of log. There are different user interfacesI
for each level error, information, and warning.
• User can delete or remove logs from the notification detail window by clicking the Close button.
• Closing or removing logs from notification detail view will decrease notification count at run time.
• Level of logs to be shown and maintained in notification detail can be configured in OMSUILog4j.xml file
with category: com.tibco.aff.
TIBCO® Fulfillment Order Management User's Guide
Fulfillment Order Management User Interface | 219
Fulfillment Order Management Functionality
The Fulfillment Order Management UI consists of the following:
1. Dashboard on page 219.
2. Orders Page on page 226.
3. Plans Page on page 232.
4. Jeopardy Rule Configuration on page 238.
5. Catalog Tab on page 268.
6. GANTT Chart on page 258.
7. About Activity Log on page 266.
Dashboard
An Fulfillment Order Management Dashboard is a graphical user interface that organizes and presents rich
and enhanced information in a format that is easy to read and interpret. The Dashboard is the default view
when you access the Fulfillment Order Management.
Features of the dashboard include:
• An intuitive graphical display that is easy to navigate - A rich Graphical User Interface (GUI) with
user/role security to manage/view orders.
• A logical structure that makes information easily accessible - Ability to view all orders through graphical
Dashboard summary.
• Data displays that can be customized and categorized - Ability to drill-down into order details by setting
display preferences.
• Regular and frequent updates of dashboard information for accuracy and relevance - Ability to
auto-refresh to display updated details for an order cancellation, amendment, suspension, and resumption.
• Information from multiple sources can be viewed simultaneously - Ability to manage, search and filter
lists of existing orders.
The Dashboard allows effective order management with a comprehensive operations view. The information
displayed is a combination of text and graphical views, as:
• Current number of orders being processed.
• Current number of orders completed in the last 24 hrs.
• Current number of orders in the Execution state.
• Current number of orders errored out in the last 24 hrs.
• Current number of orders amended in the last 24 hrs.
• Current number of suspended orders.
• Current number of orders in Jeopardy.
• Current number of Jeopardy live alerts.
Dashboard Components
The Dashboard displays the following panels:
• Orders Summary
• Amended Orders
• Backlog Orders
• Orders in Execution
TIBCO® Fulfillment Order Management User's Guide
220 | Fulfillment Order Management User Interface
Figure 68: Fulfillment Order Management Dashboard
All the above sections except Backlog Orders by default show the data for the Month. You can change
the data window anytime by editing the display preferences.
Every section updates itself periodically with the default interval of 300 seconds (300000 milliseconds).
However, you can change the default interval by editing the preferences.
Order Summary
The Orders Summary section displays the summary of orders in terms of the order status and corresponding
count of orders.
Summary is displayed in the form of a horizontal bar chart (order status versus number of orders). To see
the details of a particular order status with the list of orders on the Orders page, click on the respective
horizontal bar.
Figure 69: Order Summary Section
Under the Orders Summary section, you can perform the following operations:
• Refresh Interval: This is the Interval after which the chart is refreshed. To set the refresh interval, refer
to Auto-refreshing the Interval on page 221.
• Set the Time Period to View the Chart: You can set the time period to view the order chart. To do this,
refer to Viewing Order Summary Data Based on the Definite Time Period on page 221.
TIBCO® Fulfillment Order Management User's Guide
Fulfillment Order Management User Interface | 221
Auto-refreshing the Interval
Auto-refreshing the chart saves you the time and effort to view the fresh information on the Dashboard. The
interval is in milliseconds.
To auto-refresh the chart after a definite time period, perform the following steps:
1.
On the top-right corner, click the Edit Preferences icon
.
2. In the Auto refresh interval field, enter the time (in milliseconds) that you wish to set to auto-refresh the
Order Summary chart information.
3. Click the Save button to save the setting and exit the dialog. You are now set to see the refreshed Dashboard
after the interval you have specified. Click the Cancel button to exit the dialog without saving the setting.
Viewing Order Summary Data Based on the Definite Time Period
The Dashboard allows you to customize the information format that is displayed through the chart. Here are
the different time period parameters based on which you can see the chart data.
Time Period Result Data Details
Day
The chart shows the data for the current day.
Week
The chart shows the data for the current week.
Month
The chart shows the data for the current month.
Year
The chart shows the data for the current year.
To view the chart for the specified time period, perform the following steps:
1.
On the top-right corner on the Order Summary section, click the Edit Preferences icon
.
2. From the Data Window list, select the time period from the available options - Day, Week, Month, or Year
for which you wish to see the data.
The default selected option is Month.
3. Click the Save button to save the information and exit the dialog. The data is displayed based on the time
period option you selected. Click the Cancel button to exit the dialog without specifying the time period
- the data will be displayed according to the default selected time period Month.
Backlog Orders
This section shows the list of backlog orders . The term backlog orders refers to those orders that have been not
yet completed and not covered in the Order Summary section.
You can select which columns you wish to see by editing the display preferences. The steps to edit the preferences
are similar to those of Order Summary or Amended Orders section.
Like the Amended Orders section, by default you can see the top six records of the backlog orders. To see
more orders, click the Maximize icon
.
If you want to view details for any particular order, click on the respective row and see the details of the
selected order on the Orders page.
Amended Orders
Amended Orders section provides you with the consolidated view of the list of amended orders. By default,
records of the top six amended orders are displayed. To see more orders, click the Maximize icon
.
You can perform the following operations under the Amended Orders section:
• View the Order Details: If you wish to view the details for any particular order, click on the respective
order link in the row. The Orders page with the selected order detail is displayed.
TIBCO® Fulfillment Order Management User's Guide
222 | Fulfillment Order Management User Interface
• Customize the Amended Orders Display Format: The Dashboard allows you to customize the information
display under the Amended Orders section according to your convenience and ease of use. To know how,
refer to Setting Display Preferences for Amended Orders on page 222.
• Filter the Amended Orders Data: You can display the data in the Amended Orders section with the
Submitted Date filter. To do this:
1.
On the Amended Orders section, click the Filter icon . The Filter window is displayed.
Figure 70: Filtering Data
2.
In the Find field, enter the (order) submission date in the mm/dd/yyyy format or click the Calendar
icon to select the date from the calendar.
3. Click the Go button to find orders submitted on the specified date. Click the Clear button to reset the
order submission date.
4.
Click the Filter
icon again to exit the Filter window (optional).
Setting Display Preferences for Amended Orders
You can customize the Amended Orders section display based on the following parameters:
• Column Selection: Choose from a list of available columns that you wish to see.
1.
On the top-right corner on the Amended Orders section, click the
icon. The Edit Preferences dialog
is displayed.
2. Select the column you wish to see to display data in the Amended Orders grid. You can select from
the following available options:
Column Header
Description
Show Order Id column
Displays the Order Ref ID column.
This column is always visible.
Show Customer Id column
Displays the Customer ID column.
Show SubscriberId column
Displays the Subscriber ID column.
Show Status column
Displays the Status column.
Show Submitted Date column
Displays the Submitted Date column.
• Time period: Set the time period to view the amended orders.
1. In the Edit Preferences dialog, select the time period for which you wish to see the amended orders.
For example, if you wish to see the data on a weekly basis, select Week from the list. The default selected
option is Month.
2. Click the Save button to save the information and exit the dialog. The data is displayed based on the
time period option you selected. Click the Cancel button to exit the dialog without specifying the time
period - the data will be displayed according to the default selected time period Month.
• Refresh Interval: Set the auto-refresh interval in milliseconds to display the information for all the amended
orders in a tabular format.
1. In the Auto refresh interval field, enter the time (in milliseconds) that you wish to set to auto-refresh
the Amended Orders information.
TIBCO® Fulfillment Order Management User's Guide
Fulfillment Order Management User Interface | 223
2. Click the Save button to save the setting and exit the dialog. You are now set to see the refreshed
Dashboard for Amended Orders after the interval you have specified. Click the Cancel button to exit
the dialog without saving the setting.
Orders in Execution
This section shows the list of all the orders which are in the execution state.
Like other sections,
• You can select which columns you wish to see by editing the display preferences. The steps to edit the
preferences are similar to those of Order Summary or Amended Orders section.
•
By default you can see the top six records of the orders. To see more orders, click the Maximize icon
.
• If you want to view details for any particular order, click on the respective row and see the details of the
selected order on the Orders page.
Jeopardy Dashboard
This section explains the capabilities of Orders in Jeopardy and the Jeopardy Alerts panels and how to integrate
this with the existing Dashboard components. Current Dashboard user interface has been enhanced and
improved for these additional jeopardy panels.
The Jeopardy dashboard will be available only if you have deployed the Jeopardy .war file in Tomcat.
If the Jeopardy .war is deployed, and you are unable to view the Jeopardy dashboard, press Ctrl+F5
to refresh the page.
The following are the Jeopardy panels:
• Orders In Jeopardy
• Jeopardy Live Alerts
• Jeopardy Recorded Alerts
Orders In Jeopardy
The Order in Jeopardy panel lists all the order in a jeopardy state in a
To access the Orders in Jeopardy panel, click the Jeopardy tab.
The following are the details of the Jeopardy tab:
OrderRef Id
Order reference id of the order in jeopardy. Clickable and takes to order screen.
Plan Id
Plan Id of the order in jeopardy. Clickable and takes to Plan Screen on OmsUI.
Risk Region
The Risk Region comprises below values:
• NORMAL - the plan item section completed less than the typical duration
• HAZARD - the plan item section completed greater than the typical duration but
less than the maximum duration
• CRITICAL - the plan item section completed greater than the maximum duration
• OUT OF SCOPE – the plan exceeded last acceptable duration limit
TIBCO® Fulfillment Order Management User's Guide
224 | Fulfillment Order Management User Interface
Figure 71: The Orders in Jeopardy Panel
The Orders in Jeopardy allows you to select columns you wish to see by editing the display preferences. The
steps to edit the preferences are similar to those of Order Summary or Amended Orders section.
To view details for any particular order in jeopardy, click the respective value in the Order Ref Id column.
The details of the selected order are displayed on the Orders page. Similarly, you can view the order details
and jeopardy plan details on the Plans page when you click the value in the Plan Id column.
Jeopardy Live Alerts
The Jeopardy Live Alerts panel displays the live alerts from the Jeopardy Manager.
The details of the Jeopardy Live Alerts panel are as follows:
Submitted Date
Timestamp details when jeopardy alert message received
Plan Id
If present in the incoming message from Jeopardy Manager, Plan Id of the order
is display under Plan Id column.
Plan Item Id
If present in the incoming message from Jeopardy Manager, Plan Item Id of the
order is display under Plan Item Id column.
Real Time Jeopardy
Alerts
Actual text message contents of the alert
Figure 72: Jeopardy Live Alerts
TIBCO® Fulfillment Order Management User's Guide
Fulfillment Order Management User Interface | 225
Select which columns you wish to see by editing the display preferences. To edit the preferences, perform
the steps mentioned in the Order Summary or Amended Orders section.
You cannot refresh Interval.
If you click on Refresh button, all existing live alert messages will be cleared out. Afterwards these cleared
messages will be available under Jeopardy Recorded Alerts. The in coming messages are always displayed
at the top and push the old messages down.
If you want to view details for any particular plan, click the respective row value. The details of the selected
plan are displayed on the Plans page.
Jeopardy Recorded Alerts
The Jeopardy Recorded Alerts panel displays the recorded alerts from the Jeopardy Manager.
The Jeopardy Recorded Alerts panel displays the following information:
Submitted Date
Timestamp details when jeopardy alert message recorded in OMS server
Plan Id
If present in the incoming message from Jeopardy Manager, Plan Id of the order
is display under Plan Id column.
Plan Item Id
If present in the incoming message from Jeopardy Manager, Plan Item Id of the
order is display under Plan Item Id column.
Historical Jeopardy Alerts Actual text message contents of the alert received in OMS.
Figure 73: Jeopardy Recorded Alerts Panel
Select the columns you wish to see by editing the display preferences. This panel shows the alerts for the past
1 hour (default selected in Edit Preferences), 12 hours or 24 hours. To accommodate newly generated alerts
under this panel, refresh or setup the refresh interval in the Edit Preferences icon.
To view details of any particular plan, click the respective row value. The details of the selected plan are
displayed on the Plans page.
TIBCO® Fulfillment Order Management User's Guide
226 | Fulfillment Order Management User Interface
Orders Page
On the Order page you can view details about the order, including status and revision history of the orders,
add orders, and show plan preview. You can also edit the order and resubmit the order for further fulfillment
process.
You can also view the details for initial request and amendments and also take action on the orders. The
following actions are allowed on the Orders page:
• Suspend Order: This will be available when an order is in the execution state and not yet completed. This
state is also available when an order fails.
• Cancel Order :This will be available before the order goes to the completed state.
• Amend Order: This will be available in the OMS UI when the order is in the suspended state.
• Withdraw Order: This will be available when the order is in the execution or suspended state. Once the
order is withdrawn, it is not listed in the Order or Plans pages. However, the audit log for the withdrawn
order can be viewed on the the Activity Log page.
• Resume Order: This will be available when the order in the execution state.
• Show Execution Plan: You can view the execution plan for the respective order by clicking the Show
Execution Plan option. This option displays the Plans page and the respective plan’s details .
• Show Activity Log: You can view the activity log for the respective order by clicking the Show Activity
Log option. Show Activity Log shows flow of change in statuses for each of the entities: order, order-line,
plan, and plan-items.
• Show Catalog: Click on Product Id in orderline tab to view the related catalog.
• Add Order: You can submit new order functionality through the order component.
• Plan Preview: You can generate a plan preview by providing submit order XML without submitting
order.
You must have ADMIN privileges (USER_ADMIN role) to do the above mentioned operations.
You need to suspend an order before amending an order.
Viewing Order Priority
To track the order, perform the following steps:
1. Go to http://<host>:<port number>/omsui/Login/Login.jsp to access the Login page where:
– host is the computer where you installed the Fulfillment Order Management.
– port is the port number of the machine where Fulfillment Order Management installation listens to
the requests. The default port number is 8080.
Figure 74: Order Management System Login
2. Enter the username and password to sign in.
The OMS Dashboard is displayed.
TIBCO® Fulfillment Order Management User's Guide
Fulfillment Order Management User Interface | 227
Figure 75: Order Management System Dashboard
3. Go to the Orders page.
The order priority is displayed along with the other order details.
Figure 76: Order Priority
Searching for an Order
You can search for the order from the Fulfillment Order Management GUI. The Orders page allows you to
key in the order reference and filters for the search results. The Orders page shows paginated view of search
results. You can click on the order link to view details about the order and perform an action on order.
Do the following to search the order:
• Go to the Orders page.
Click
to refine your search using the search criteria specified in the following table:
Search Criterion
Description
Order Ref ID
The unique identifier of the order, supplied by the order originator.
Customer ID
The reference that enables the OMS to retrieve the current customer profile
and to identify the customer to other systems interested in the order.
Status
The current status of the order.
The different statuses are:
• START
• FEASIBILITY
TIBCO® Fulfillment Order Management User's Guide
228 | Fulfillment Order Management User Interface
Search Criterion
Description
•
•
•
•
•
•
•
Submitted Date
Originator
OPD
EXECUTION
SUSPENDED
COMPLETE
CANCELLED
WITHDRAWN
PREQUALIFICATION FAILED
The date of order submission.
Fulfillment Order Management, where the orders are created.
Fulfillment Engine
AFO or IPC (iProcess Conductor). AFO for fulfillment orchestrator.
Order ID
Order Id is the internal identifier of the Order generated by OMS.
OPD Source
The value can be AOPD or MOPD.
You can use a combination of search criteria to search for a specific order object. For example, you can select
a status of COMPLETE from the Status column and type the username in the Originator column to find all
orders with a status of COMPLETE that were created by a particular user.
The search is case-sensitive.
•
Click
to display the list of orders that match your search criteria. Select the order to display its details.
Viewing Order Information
The Orders page allows you to view the consolidated view of the order details and perform action(s) on an
order.
To view the consolidated order information, complete the following steps:
Go to the Orders page and click a row in the list of orders to view an order (highlighted in red in the figure
below). The order details are displayed in the Order Grid View (highlighted in green below).
The Order Grid view displays the details for the order in two panels: the Tree View and the Details view.
Tree View
TIBCO® Fulfillment Order Management User's Guide
Fulfillment Order Management User Interface | 229
The Tree View displays the status of the order and each order line. Click an order or order line to display the
details in the Details View.
If an order has been amended, the Tree View displays the information of the original order and its order lines
as well as the amended order and its order lines, with the current status.
The order line status and notifications are listed below:
Order Details View
Order Details View gives different information at order level and order line level.
Click ‘Order’ in the Order Tree View to display details at the order header level.
The order line status and notifications are listed below:
Click an individual order line in the Tree View to display order line level details.
The order line status and notifications are listed below:
TIBCO® Fulfillment Order Management User's Guide
230 | Fulfillment Order Management User Interface
Suspending an Order
When you suspend an order, the Fulfillment Order Management suspends each of the processes that are
attached to the execution plan. This means that depending on their current statuses, each of the processes
associated with the process components and the plan tasks is suspended.
To suspend an order, complete the following steps:
1. Go to the Orders page.
2. Select an order in the order row which you wish to suspend. You can view the details of the order in the
pane below. You can view the current order details, original request, and amendments in the below pane
along with the status and revision history of the order.
3.
On the top right of the Orders page, click the
icon.
Resuming an Order
To resume an order, complete the following steps:
1. Go to the Orders page.
2. Select an order in the order row which you wish to resume. You can view the details of the order in the
pane below. You can view the current order details, original request, and amendments in the below pane
along with the status and revision history of the order.
3.
On the top right of the Orders page, click the
icon.
Canceling an Order
To cancel an order, complete the following steps:
1. Go to the Orders page.
2. Select an order in the order row which you wish to cancel. You can view the details of the order in the
pane below. You can view the current order details, original request, and amendments in the below pane
along with the status and revision history of the order.
3. On the top right of the Orders page, click the
icon.
Amending an Order
You can amend an order when an order is in SUSPENDED state. When an order is in SUSPENDED state you
will be given an option to edit the order.
After selecting the edit option, you can perform the following actions before sending the amendment for the
order:
• Add a new order line by clicking the Add Line option.
TIBCO® Fulfillment Order Management User's Guide
Fulfillment Order Management User Interface | 231
•
•
•
•
Remove existing order line by selecting an existing order line and then clicking the Remove Line option.
Add new custom header of Delete existing custom header.
At order line level add new or delete existing Characteristics.
Update the existing order/order line fields.
After completing the changes in the SUSPENDED order, click the Post icon to post the amend order request.
The submitting the amend order request, the SUSPENDED order immediately comes into EXECUTION state.
Submit Order and Import XML
You can use OMSUI to submit an order through the Orders tab by either entering the attribute values through
editable component of the Orders tab or by importing SubmitOrder.xml.
The Add Order button will be displayed when the Orders tab is loaded if the config value
com.tibco.aff.omsui.EnableSubmitOrder is used.
Adding an Order
To add an order perform the following steps:
Procedure
1.
Click Add Order
An editable order component user interface will get generated.
.
2.
Enter values in editable order component or click Import button
.
TIBCO® Fulfillment Order Management User's Guide
232 | Fulfillment Order Management User Interface
Clicking Import opens up the Import Order dialog.
3. Submit the file SubmitOrder.xml in the text area and click the Save button in the Import Order dialog.
The values will be displayed in respective attributes.
4. Click Plan Preview or Save Order to add an order.
5.
Click Show Plan Preview button
.
The plan preview for order will be generated without submitting the order in Fulfillment Order
Management.
6. Click Save Order.
The order will be saved in Fulfillment Order Management.
You can also choose to discard submitting order by clicking the Discard button.
Plans Page
The Plans page provides details for the plan generated by AOPD. Clicking the Plans tab will give you a
tabular list for all the plans in your database repository.
You can even filter plans. For more information, see Searching for a Plan.
TIBCO® Fulfillment Order Management User's Guide
Fulfillment Order Management User Interface | 233
This tabular view of plans is supported by configurable pagination. Plans per page can be configured
through the OMS configurator. Refer to TIBCO Fulfillment Order Management Admininstration for
details.
You can click an individual plan in the table and see the details for the plan. Each of these views is displayed
in the bottom panel.
1. Grid View on page 234.
2. Dependency View on page 234.
3. GANTT Chart on page 258.
4. Activity Log on page 266.
Searching for a Plan
The Plans page allows you to key in the order reference and filters for the search results and the page shows
a paginated view of the search results. To view Plan details, the plan link.
Do the following to search the plan:
• Go to the Plans page.
Click
to refine your search using the search criteria specified in the following table:
Search Criterion
Description
Order Ref ID
The unique identifier of the order, supplied by the order originator.
Plan ID
The unique identifier of the plan.
Description
Description of the plan.
Status
The current status of the Plan.
The different statuses are:
• START
• FEASIBILITY
• OPD
• EXECUTION
• SUSPENDED
• COMPLETE
• CANCELLED
• WITHDRAWN
Plan-Item Status
The current status of the Plan-Item.
The different statuses are:
• START
• FEASIBILITY
• OPD
• EXECUTION
• SUSPENDED
• COMPLETE
• CANCELLED
• WITHDRAWN
• ERROR
• ERROR_HANDLER
Originator
Fulfillment Order Management where the plans are created.
TIBCO® Fulfillment Order Management User's Guide
234 | Fulfillment Order Management User Interface
Search Criterion
Description
Created On
The date of plan creation.
Changed On
Date of plan change.
Order ID
Order Id is the internal identifier of the Order generated by OMS.
You can use a combination of search criteria to search for a specific plan object. For example, you can select
a status of COMPLETE from the Status column and type the username in the Originator column to find all
plans with a status of COMPLETE that were created by a particular user.
The search is case-sensitive.
•
Click
to display the list of plans that match your search criteria. Select the plan to display its details.
Grid View
The Grid View is the default view of the Plans page. The Grid View displays:
1. Details of the plan including custom headers.
2. Details of Plan items, including custom headers, order line, process information and section level
information.
3. Milestone IDs along with their dependency information.
Figure 77: Plan View
GANTT Chart View
You can view the orchestration of an execution plan by using the Gantt chart.
For more information, see GANTT Chart on page 258.
Dependency View
The Dependency View is a statistical tool, used in project management, that is designed to analyze and
represent the plan-items involved in completing a given plan.
The major difference between the Dependency View and GANTT chart is that GANTT charts emphasize the
time it takes to complete tasks (plan-items), while Dependency view charts emphasize relationships between
tasks (plan items).
The Dependency View chart has the following components:
TIBCO® Fulfillment Order Management User's Guide
Fulfillment Order Management User Interface | 235
•
•
•
•
Activity nodes
Dependency Type display
Viewing Plan/Plan-Item/Milestone Details
Toolbar
Activity nodes
Each of the activity nodes corresponds to a section. A section is modeled in the plan-fragment model and it
consists of a start and an end milestone. In case there are intermediate milestones in the plan then there can
be multiple sections in the plan-item. The Dependency view shows all the sections that are present in each
plan-item.
The Activity node consists of the following information:
1. Start time for a particular section. If the section is still in PENDING state then the start time will be empty.
2. End time for a particular section. If the section is still in PENDING/EXECUTION state then the end time
will be empty.
3. Typical duration defined in the plan-fragment model for a particular section. Typical duration is modeled
in milliseconds unit.
4. Maximum duration value defined in the plan-fragment model for a particular section. Maximum duration
is modeled in milliseconds unit.
5. Each section can have one of the following states: PENDING/EXECUTION/COMPLETE. Different color
coding will be used to represent different states of the section.
An Acivity node is illustrated below:
Figure 78: Activity node
Completed states are in green, pending states are gray, and executed states are orange. The Activity node is
illustrated below:
Dependency Types
Two types of dependencies are displayed in the Dependency View: Point Dependencies and Time
Dependencies.
A Point Dependency, illustrated below, is displayed with yellow connecting arrows that indicate a
‘dependent-on’ kind of relationship.
TIBCO® Fulfillment Order Management User's Guide
236 | Fulfillment Order Management User Interface
Figure 79: Point Dependency
The typical critical path is displayed with red connecting arrows. This path, calculated by the Jeopardy
Management System, is the longest duration path that can calculated in the plan. For more information, see
the Jeopardy Management System chapter. The typical critical path is illustrated below:
Figure 80: Typical Critical Path
When there is a point dependency on the typical critical path, the red and yellow arrows will overlap, as
illustrated below:
Figure 81: Dependency View
The Time Dependency is shown at the start milestone level with color notation, illusrated below:
Figure 82: Time Dependencies
• If a Time Dependency has a START milestone state of PENDING and the time dependency defined on
the milestone is not yet met, the START milestone will be shown with a GREY color dot, illustrated below:
TIBCO® Fulfillment Order Management User's Guide
Fulfillment Order Management User Interface | 237
• If a Time Dependency has a START milestone state of COMPLETE and the milestone was completed on
or within the time frame of the assigned time dependency, the START milestone will be shown with a
GREEN color dot, illustrated below:
• If a Time Dependency has a the START milestone state of COMPLETE or PENDING and the milestone
has missed the defined time dependency, the milestone will be shown with a RED color dot, illustrated
below:
Viewing Plan/Plan-Item/Milestone Details
Each row in the details screen represents a single plan-item. The plan-item’s description and plan-item id is
used for representing an individual plan-item. Clicking a plan-item description and a plan-item id combination
will display theplan-item details, illustrated below:
Figure 83: Plan Item Details
Clicking the milestone-id will display the milestone details, as shown below:.
Figure 84: Milestone Details
Toolbar
The toolbar has zoom, plan detail, and help options:
Figure 85: Toolbar
When you hover over the toolbar, you can drag the toolbar anywhere in the frame.
Click the Plan Details icon to display plan details:
Figure 86: Plan Details
Click the Help icon to open the Help window with details on the notations used in the Dependency View.
Hover on the images shown in the help to diisplay more information.
TIBCO® Fulfillment Order Management User's Guide
238 | Fulfillment Order Management User Interface
Figure 87: Help window
Jeopardy Rule Configuration
This section explains how you can configure jeopardy rules for jeopardy management to send notification,
or invoke web services to perform consequential actions. For details on the Jeopardy Management System,
see TIBCO Fulfillment Order Management Concepts and Architecture.
The Jeopardy management is a process of monitoring execution of plan to ensure they are completed according
to a SLA associated with the plan items and plan. Plans are based on a time schedule. When execution is
predicted to violate the schedule, the system raises an event and the user can configure rules to automatically
send notification or perform consequential action by invoking web service.
The Jeopardy Rule Configuration allows you to configure rules for Jeopardy Management.
Refer to the TIBCO® Fulfillment Order Management Concepts and Architecture document for more details on
the Jeopardy Management System.
The Jeopardy Management System raises the following two types of jeopardy events:
• Plan Item Jeopardy
• Plan Jeopardy
Plan Item Jeopardy
The plan item jeopardy occurs when plan items exceed or predicted to exceed following thresholds specified
in a plan fragment model of a process component:
• Typical duration
• Maximum duration
The visual representation of the jeopardy event payload for the PlanItem Jeopardy event XML object is as
follows:
The following is the visual representation of the plan item:
TIBCO® Fulfillment Order Management User's Guide
Fulfillment Order Management User Interface | 239
The following table lists all the jeopardy events that Jeopardy Management System raises for the Plan Item
jeopardy.
Plan Item Jeopardy Conditions Description
AFF-JM-PLANITEM-0100
Plan item has exceeded typical duration
AFF-JM-PLANITEM-0110
Plan item has exceeded maximum duration
AFF-JM-PLANITEM-0120
Plan item has exceeded required start
AFF-JM-PLANITEM-0200
Plan item start is predicted to exceed required start and is increasing
AFF-JM-PLANITEM-0210
Plan item start is predicted to exceed required start and is decreasing
AFF-JM-PLANITEM-0220
Plan item is no longer predicted to exceed required start
Plan Jeopardy
The plan jeopardy occurs when the execution plan exceeds or is predicted to exceed the following thresholds:
TIBCO® Fulfillment Order Management User's Guide
240 | Fulfillment Order Management User Interface
• Typical Duration
• Maximum Duration
Jeopardy event pay load for the
Plan Jeopardy
is an XML object and shown as follows:
Figure 88: Plan Notification Event
The plan element is visually represented as follows:
Figure 89: Plan Element
Following table lists all the jeopardy events that Jeopardy Management System can raise for the Plan Item
jeopardy:
Plan Jeopardy Conditions Description
AFF-JM-PLAN-0100
Plan has exceeded typical duration
AFF-JM-PLAN-0110
Plan has exceeded maximum duration
AFF-JM-PLAN-0120
Plan has exceeded out of scope threshold
AFF-JM-PLAN-0200
Plan is predicted to exceed typical duration and is increasing
AFF-JM-PLAN-0210
Plan is predicted to exceed typical duration and is decreasing
AFF-JM-PLAN-0220
Plan is no longer predicted to exceed typical duration
AFF-JM-PLAN-0230
Plan is predicted to exceed maximum duration and is increasing
AFF-JM-PLAN-0240
Plan is predicted to exceed maximum duration and is decreasing
AFF-JM-PLAN-0250
Plan is no longer predicted to exceed maximum duration
TIBCO® Fulfillment Order Management User's Guide
Fulfillment Order Management User Interface | 241
Jeopardy event rules can be configured in the Fulfillment Order Management UI to either send notification
or invoke a web service.
You can use Rule Configuration to do the following:
• Add rule
• Update rule
• Delete rule
• Suspend rule
• Activate rule
The following table lists the rule header information:
General Details
Condition
Action
Name, description, status,
Criterion to be monitored for Action to be taken if condition matches
Event Group, Event Type, etc. Jeopardy Management
Adding and Configuring Rule
To add a rule, perform the following steps:
1. On the Fulfillment Order UI, click Rule Config
2. Click Add.
Figure 90: Adding Rule
Only active rules are used to monitor jeopardy condition.
3. Edit the following rule attributes:
Name
Description
Run on Error /Run on Failure
rule identifier
description of the rule
You can set them to true if you want the
system to execute in spite of a failure or
error in an action. A failure is the same
thing as an error, except it represents
communication failure to the configured
end point.
Figure 91: Rule Attributes
TIBCO® Fulfillment Order Management User's Guide
242 | Fulfillment Order Management User Interface
Optionally, you may add condition to the rule to filter specific events with attribute values in event
payload.
Adding Condition to Rule
1. On the Fulfillment Order UI, click Condition. The Condition Editor tab is displayed.
Figure 92: Adding Condition to Rule
2. Click Edit Attribute in Condition Editor tab to add or edit conditions. Condition Builder screen will appear
as a pop which can be used to configure conditions for this rule.
Figure 93: Edit Attribute
3. A criteria has the Left Operand, Operator and Right Operand, as displayed:
Left Operand
Operator
Right Operand
The left side of a quantity upon
which a criteria operation is
performed
Performs calculations on the
operands in a query or an
expression
The right side of a quantity upon
which a criteria operation is
performed
Select Left Operand, Operator and Right Operand from the Condition Builder to create a condition. Left and
Right Operand can be selected from a predefined list of attributes or utility methods. Similarly, Operator can
also be selected from a predefined list of attributes depending on the selection of Left Operand.
Selecting Left Operand
To select Left Operand click the Edit icon besides Left Operand in the Condition section. A predefined list
of Attributes/utility methods will appear on right side in Attributes section to select as Left Operand. An
attribute or utility method from this available list can be selected.
Using attributes as Left Operand
TIBCO® Fulfillment Order Management User's Guide
Fulfillment Order Management User Interface | 243
Select an attribute from the available list and click the Map icon to assign this value as left operand. Please
refer Plan Jeopardy and Plan Item jeopardy section for list of attributes which can be selected as Left Operand.
Figure 94: Condition Builder
Using Utility methods as Left Operand
List of utility methods will appear in Attributes section under utility node. Select a utility method from this
list and click Map icon to assign the return value of this method as Left Operand.
Following table shows the utility methods listed under utility node in Attributes section:
TIBCO® Fulfillment Order Management User's Guide
244 | Fulfillment Order Management User Interface
Figure 95: Utility methods as Left Operand
Values to the input parameters of the method can be assigned using the Edit icon appearing besides method
parameter. When you click Edit, a list of attributes appears on right side and value can be assigned by selecting
any attribute. Use Data Input to assign any input value for an input parameter of the method.
TIBCO® Fulfillment Order Management User's Guide
Fulfillment Order Management User Interface | 245
Figure 96: Utility Methods
The following table shows supported utility methods with description:
Method Signature
Description
public boolean wildCardMatch(
java.lang.String text, java.lang.String
pattern)
Test if the pattern matches with given text. Parameters: text java.lang.String to be searched in an effort to find pattern
pattern - character or java.lang.String of one or more characters
to be searched for Returns: Returns value true if the given text
matches the pattern and false otherwise
public java.util.Date
getDateFromTimeStamp( java.lang.Long
inputTimeStamp)
Indicating java.util.Date for specified timestamp in milliseconds.
Parameters: inputTimeStamp - milliseconds value as
java.lang.Long Returns: java.util.Date object and initializes it
to represent the specified number of milliseconds.
public java.lang.Integer getDayOfWeek(
java.lang.String timezone, java.lang.String
country, java.lang.String language,
java.lang.Long timestamp)
Indicating the day of week for specified timestamp in
milliseconds Parameters: timezone - the timezone (e.g.
'America/Chicago') country - the country (e.g. 'US') language
- the language (e.g. 'en') timestamp - the timestamp as
milliseconds Returns: Day of the week as an Integer value for
the timestamp value using the time zone, country and language
specified
public java.lang.Integer getDayOfMonth(
java.lang.String timezone, java.lang.String
country, java.lang.String language,
java.lang.Long timestamp)
Indicating the day of month for specified timestamp in
milliseconds Parameters: timezone -the timezone (e.g.
'America/Chicago') country - the country (e.g. 'US') language
- the language (e.g. 'en') timestamp - the timestamp as
TIBCO® Fulfillment Order Management User's Guide
246 | Fulfillment Order Management User Interface
Method Signature
Description
milliseconds Returns: Day of the month as an Integer value for
the timestamp value using the timezone, country and language
specified.
Select an Operator
To select an Operator, click Edit icon besides Operator in condition section a list of operators with description
will appear on right side. Select any operator to assign Operator value.
Figure 97: Selecting an Operator
Select Right Operand
To select Right Operand click Edit button besides Right Operand in Condition section. A list of attributes
appears on the right side in the Attributes section to select as Right Operand. Select any attribute from the
available list or input a value by selecting Data Input from Attributes section and click Map icon to assign
this value as the Right Operand.
TIBCO® Fulfillment Order Management User's Guide
Fulfillment Order Management User Interface | 247
Figure 98: Selecting Right Operand
4. Click Generate Groovy Method to verify the criteria and generate a corresponding expression
TIBCO® Fulfillment Order Management User's Guide
248 | Fulfillment Order Management User Interface
Figure 99: Groovy Method
An expression is generated using the selected Left Operand, Operator, Right Operand and it is displayed in
the Condition Expression section.
TIBCO® Fulfillment Order Management User's Guide
Fulfillment Order Management User Interface | 249
Figure 100: Expression
5. Click Save to add condition to Condition Editor.
6. To add more condition click Add icon as shown below. To add a nested condition click Add Nested icon.
Match All will be used if all the conditions need to be evaluated true for this rule to execute. Match Any will
be used if any of the specified conditions need to be evaluated true for this rule to execute.
Figure 101: Condition Editor
Conditions in the Condition Editor are shown as follows: You can delete a Condition or nested condition from the
Condition Editor using the Delete icon.
TIBCO® Fulfillment Order Management User's Guide
250 | Fulfillment Order Management User Interface
Figure 102: Deleting Condition
Groovy script generated from a defined condition is shown in the Expression tab as follows.
Figure 103: Groovy script generated from a defined condition
Rule Actions
The rule actions are as follows:
Delete Rule
1. Select an existing rule to delete.
2. Click Delete.
Figure 104: Delete Rule
Suspend Rule
1. Select an existing rule to suspend.
2. Click Suspend.
TIBCO® Fulfillment Order Management User's Guide
Fulfillment Order Management User Interface | 251
Figure 105: Suspend Rule
Activate Rule
1. Select an existing rule to activate.
2. Click Activate.
Figure 106: Activate Rule
Configure Actions
The Jeopardy Management System (JeOMS) supports the following two types of consequential actions for
jeopardy events:
1. Alert or Notification - Supports sending notification to the following end points:
a. SMTP - notification to specific email accounts.
b. JMS - JMS (Java Message Service) messages to JMS queue or topic.
c. Tibbr - notification message to Tibbr subject.
d. File - log notification messages.
2. Service Invocation - Supports invoking web services which uses WSDL 1.1 specification.
Jeopardy Management System also allows you to specify dampening criteria to action. Give the dampening
(or flow control) criteria to action on how often to send notifications or invoke service for the same jeopardy
event.
The frequency for sending alerts depends on the expected behavior of the process component. There are
several frequency settings:
• Every time the jeopardy rule condition evaluates to true. This sends the most alerts. It's the default setting
if dampening criteria is not specified.
• Every X times the condition is true. This sets a number of times that the condition has to occur before an
action is executed. This offsets any occasional spikes in executing plan item in process component or in
the fulfillment system. To add this criteria set following values:
True Count
Evaluation Count
Notification Count
X
Y
1
• Every X times the condition is true in Y evaluations. This sets a number of times that the condition has to
occur in a given number of monitoring evaluations cycles before an action is executed.
True Count
Evaluation Count
Notification Count
X
Y
1
TIBCO® Fulfillment Order Management User's Guide
252 | Fulfillment Order Management User Interface
Every X times the condition is true in Y time period.
True
Count
Evaluation
Count
Notification Count Time Value
Time Unit
X
Y
1
Period
((SECOND/MINUTE/HOUR/DAY/WEEK/MONTH))
Y
• No more than X notification in Y time period
True
Count
Evaluation
Count
Notification
Count
Time Value
Time Unit
X
Y
1
Y
Period
((SECOND/MINUTE/HOUR/DAY/WEEK/MONTH))
Webservice Configuration
Add Action
1. Click Add Action.
2. Edit the following action attributes:
Name
Description
Notification type
Dampening Criteria
(Optional)
action identifier
action description
Select service
specify any dampening
criteria to the action
Select Service Parameter
tab
Enter the WSDL location
If WSDL location
is valid, Service
and Method are
populated with
respective values.
Select a service
name and
Method name to
be invoked
3. Enter the parameter information.
4. Click the Template tab. It shows the web service request parameters in an XML form. This request
parameter can be configured using Template Builder. Click the icon in Template tab to use Template
Builder and a popup would appear with a predefined list of parameters.
TIBCO® Fulfillment Order Management User's Guide
Fulfillment Order Management User Interface | 253
Figure 107: The web service request parameters in an XML form
Configure input parameters using the list of attributes and this would be replaced with actual values
while invoking the web service.
5. Click Save. Webservice request parameters would be saved and display in the Template tab.
Delete Action
• Select an existing action.
• Click Remove Action.
Notification Action Configuration
The notification action configuration is follows:
Add Action
1. Click Add Action.
2. Edit the following action attributes:
TIBCO® Fulfillment Order Management User's Guide
254 | Fulfillment Order Management User Interface
Figure 108: Action Attributes
Name
Description
Notification type
Dampening Criteria
(Optional)
action identifier
action description
Select notification
specify any dampening
criteria to the action
3. Select Notification Parameter tab
4. Select the protocol
5. Enter end point URI. The following table shows supported protocols with syntax and example
End Point Type
URI Syntax
Example
JMS Queue
jms:queue:<queue name>
jms:queue:jeopardy.notification
JMS Topic
jms:topic:<topic name>
jms:topic:jeopardy.notification
Tibbr
tibbr://<hostname:port>
tibbr://xyz.tibbr.com
SMTP
smtp://<hostname:port>
smtp://smtp.xyz.com:25
SMTPS
smtps://<hostname:port>
smtps://smtp.xyz.com:465
File
file://<filepath>
file:///opt/notification
6. Select message type for the notification. The following table shows protocol and supported out message
type
Protocol
OutBound Message Type
JMS
plainStringOutMessage
jsonMessage
javabean
xmlOutMessage
Tibbr
plainStringOutMessage
SMTP
plainStringOutMessage
xmlOutMessage
SMTPS
plainStringOutMessage
xmlOutMessage
File
plainStringOutMessage
jsonMessage
TIBCO® Fulfillment Order Management User's Guide
Fulfillment Order Management User Interface | 255
Protocol
OutBound Message Type
javabean
xmlOutMessage
The following table shows supported out message type:
OutBound Message Type
Description
plainStringOutMessage
Notification message in plain string
jsonMessage
Notification message in form of json object
javabean
Notification message in form of javabean object
xmlOutMessage
Notification message in form of xml string
7. Edit parameters information for selected protocol. The following table shows protocol and respective
parameters configuration required:
8. Edit Template to configure plainStringOutMessage content using Template Builder. Click icon mentioned
in following image in Template tab to open Template Builder screen:
TIBCO® Fulfillment Order Management User's Guide
256 | Fulfillment Order Management User Interface
Figure 109: Template
9. Following is the Template Builder screen which has all the notifications parameters listed to configure a
template for notification messages.
Figure 110: Template Builder Notifications
TIBCO® Fulfillment Order Management User's Guide
Fulfillment Order Management User Interface | 257
10. Click Save to save the template content in action.
11. Click Test Action to verify the action created is valid. If there is no error, the Test
message is displayed.
Connection Successful
If there is any error respective error message is displayed. The following table shows error messages, which
are displayed:
TIBCO® Fulfillment Order Management User's Guide
258 | Fulfillment Order Management User Interface
Hot Deployment
Rules configured using OMS UI are hot deployable, therefore Apache Tomcat where Jeopardy Management
System (JeOMS) deployed need not be restarted to activate the rules. Rules configured through OMS UI are
published to all instances of JeOMS in cluster.
GANTT Chart
You can view the orchestration of an execution plan by using the Gantt chart.
TIBCO® Fulfillment Order Management User's Guide
Fulfillment Order Management User Interface | 259
The GANTT chart displays the following objects as a graphical representation on the Fulfillment Order
Management UI:
• Plan Summary Task
• Plan Item Summary Task
• Milestones
• Sections
• Typical duration constraint for the section
• Maximum Duration constraint for the section
• Forecast the Plan in execution (Prediction)
• Show Critical path
• Time dependencies and point dependencies
• Different Regions in which a Plan can be – Typical Duration, Risk Threshold, Maximum Duration,
Contingency Buffer, Out-Of-Specification region
• Show Jeopardy conditions
• You can view the GANTT chart in different time scale levels (zoom levels), starting from weeks till the
milliseconds level
Configuration
When you deploy JEOMS, JEOMS sends the heartbeat on topic - tibco.aff.jm.publish.jeomsHeartBeat. The
OMS-UI listens to the JEOMS heartbeat and shows the Gantt chart with all the options available. When JEOMS
is not deployed, OMS-UI shows the Gantt chart with limited options.
The Jeopardy Detection Reset Timeout value is used by OMS-UI. If the heartbeat is not received by OMS-UI
within the specified milliseconds, then JEOMS will be considered as un-deployed.
The Jeopardy Detection Publish Topic and Jeopardy Detection Reset Timeout property can be configured
through configurator as shown in the below screenshot
TIBCO® Fulfillment Order Management User's Guide
260 | Fulfillment Order Management User Interface
Figure 111: Configurator - Gantt Chart Without JEOMS
When you opt for deploying JEOMS again; you need to publish the plan-fragment models again.
Plans which are in execution will not be part of Jeopardy cycle but UI will be able to enrich the plan
and show the Gantt chart
JEOMS when deployed enriches the plan and this enriched plan is used by Gantt chart to plot some of the
information. You can choose not to deploy JEOMS and still view the Gantt chart.
When JEOMS is not deployed Gantt chart won’t show the following:
1. Real time predictions for the Gantt chart of the plan. Predicted Gantt chart for the plan will be based on
the typical duration set in plan-fragment model.
2. Background color of Gantt chart for plan in different states.
A grey color is used as a background color for the plan when JEOMS is not deployed.
3. Jeopardy Messages/Notifications on the tool tip of Gantt chart items.
Viewing a GANTT Chart
The GANTT chart displays the execution plan as a graphical representation.
Procedure
1. Go to the Plans page.
2. Select any plan.
.
TIBCO® Fulfillment Order Management User's Guide
Fulfillment Order Management User Interface | 261
3. Click the GANTT chart icon
to view a diagram of the selected plan.
For details on the GANTT chart, see GANTT Chart Details on page 263
GANTT Chart Components
The GANTT chart is made up of several key components.
The following are the components of the GANTT chart:
• Grid Header
• Grid
• Top and Bottom Toolbars
• GANTT Header
• GANTT diagram
Top Tool Bar
The top tool bar changes according to the plan status.
The following table shows the GANTT charts depending upon the plan status:
Plan Status
GANTT Chart
COMPLETE or
CANCELLED
PENDING and
EXECUTION
SUSPENDED
The top tool bar has the following two display options:
• Plan View: This combo-box has different values based on the execution plan status.
- Plan Status COMPLETE or CANCELLED: Shows the GANTT with Actual & Original view.
- Plan Status EXECUTING or PENDING: Shows the GANTT with Predicted & Original view.
- Plan Status SUSPENDED: Shows the GANTT with Original view.
Different execution plan views shown in GANTT chart
Actual view: Shows the plan, plan items, sections & milestone with actual timestamp value.
Predicted view: Plan item with status as EXECUTING or PENDING are shown with predicted timestamp
value and plan items with the COMPLETE status is shown with actual timestamp value.
Original view: Shows plan, plan items, sections, and milestone with typical timestamp value.
• Critical Path: This check-box shows the critical path with the specified plan view.
Bottom Tool Bar
The bottom tool bar has the following options:
• Zoom Options: Allows you to select the zoom level. The GANTT diagram changes according to the
selected zoom level. You can select the following zoom options:
– Week
– Days
– Hours
– Minutes
– Seconds
– Milliseconds
TIBCO® Fulfillment Order Management User's Guide
262 | Fulfillment Order Management User Interface
The Zoom options are available for the user according to the difference between plan start date and plan
end date. For example, if the difference between plan start date and plan end date is more than 1 hour
but less than 24 hours, different zoom levels available are - Hours, Minutes, Seconds, Milliseconds.
• Auto-fit: Allows you to fit the Gantt chart to the best possible zoom level. The GANTT diagram changes
accordingly.
• Help: Shows the color coding for the GANTT chart.
Grid Header
The Grid Header component shows the ID, Action, Plan Details, Status,START, END, Decedents, Duration
Constraint and Description for each grid column
The following table shows the constituents of a Grid Header:
ID
Shows numeric values starting from 1…n.
Plan Details
Shows the following Plan information:
Type
Convention
Plan
Plan ID according to the generated plan.
Plan Item
Plan Item description from the plan.
Milestone
Milestone ID. For Example, START or END.
Sections
Merged Milestone IDs with "-" as delimiter. For
example START-END.
Status
All the status icons used in this column are similar to icons used in the Plan
tab grid level.
START
The start time for each Plan Details.
The value is in the MM/dd/yyyy HH:mm:ss z format (z stands for
time zone offset).You can configure this value through the
Configurator.
TIBCO® Fulfillment Order Management User's Guide
Fulfillment Order Management User Interface | 263
END
The end time for Plan, Plan Item & Section.
The value is in the MM/dd/yyyy HH:mm:ss z format (z stands for
time zone offset).You can configure this value through the
Configurator.
Descendants
The ID value for the next dependent milestone, if any.
Section Maximum End
The Date format value showing maximum end value at the section level.
Section Typical End
The Date format value showing typical end value at the section level.
Action
This column contains icons. Clicking icons details for that particular row are
shown in a popup window. For example, if you click the icon in action column
at plan level, popup appears with plan details. If you click the icon in action
column at plan item level so popup is shown with plan item details and
likewise.
GANTT Chart Diagram
The following table describes the different GANTT chart components:
Component
Description
Plan Summary Task Bar
Indicates the entire plan, from start till end.
Plan Item Summary Task
Bar
Indicates the plan item covering all the milestones and sections of a plan item.
Milestone
Represented by a grey diamond.
Section
Indicates the START and END milestones part.
Duration
The two forecast types are shown at the section level:
• Typical Duration .
• Maximum Duration .
Critical Path
Indicates the path with maximum time duration. It is represented by the section
bar with red border
. When you click the critical path option
check-box on the top tool bar, only the critical path is shown with red border
sections.
Tool tip
Shows the details of the respective GANTT item when you place the cursor
over any GANTT chart items, for example, plan, plan item, section, milestone,
typical or maximum duration icons.
Time and Point
Dependencies
Time dependency: Represented by the icon at the section level, if a section
has started on the specified time dependency. If section start time has missed
the specified time dependency, it is represented by the
icon.
Point dependency: Represented by connecting arrow. This is a unidirectional
arrow which connects two milestones.
GANTT Chart Details
The different color schemes used in the GANTT chart to visually represent the status of the execution plan
and plan item sections are as follows:
TIBCO® Fulfillment Order Management User's Guide
264 | Fulfillment Order Management User Interface
GANTT Chart Background Colors
The background color describes the status of the plan. The following figure displays the background color
codes representing the execution plan in different states:
Figure 112: GANTT Chart Background Colors
Each color in the GANTT chart has its own significance. The following table describes the GANTT chart
background colors:
GANTT Chart Section Color
The Section level color code describes the status of the section. The following figure displays the section color
codes representing the plan item section in different states:
If the section has not started its execution or the section is in the execution state, it is represented by
grey color
.
The following figure displays all the available section colors:
Figure 113: Section Colors
TIBCO® Fulfillment Order Management User's Guide
Fulfillment Order Management User Interface | 265
The following table describes the GANTT chart section level colors:
GANTT Chart Time Snapshot Line
The Time snapshot line represents the time when Gantt chart is loaded on the UI.
Figure 114: Time Snapshot Line
Tooltips
Each of the items on Gantt diagram has a tooltip which has further information about that particular Gantt
item.
Here is a desription of tooltips for each of the Gantt items and the information that will be displayed when
user take mouse pointer over a Gantt item:
•
Figure 115: Plan Summary Task Bar tooltip
•
Figure 116: Plan Item Summary Task Bar tooltip
TIBCO® Fulfillment Order Management User's Guide
266 | Fulfillment Order Management User Interface
•
Figure 117: Milestone tooltip
•
Figure 118: Section tooltip
•
Figure 119: Typical End Icons tooltip
Figure 120: Maximum End Icons tooltip
Activity Log
This section explains how to view the status of objects in the Fulfillment Order Management using the Activity
Log page.
About Activity Log
You can view a detailed log of activities for an Order, Plan, Rule and FP Orders to see the history at run-time
and perform a search on the following objects in the Fulfillment Order Management:
• Order Ref
• Plan Id
• Rule Name
• FP Order Id
• FP OrderLine Id
• FP Resource Id
• FP TechnicalOrder Id
An activity log displays messages for the following actions:
• status changes
Messages are grouped chronologically by the object type. You can press the Refresh button
to update the current view.
at any time
Viewing the Activity Log
You must search an object to view the activity log associated with a particular object. To do this, refer to
Searching for an Order in the Activity Log on page 266.
Searching for an Order in the Activity Log
To view an activity log for a selected object, you must first search for it from the Activity Log page. Once you
have found the object whose log you wish to view, select it to display it in the Activity Log page. To do this,
perform the following steps:
1. Access the Fulfillment Order Management.
2. Click the Activity Log tab.
TIBCO® Fulfillment Order Management User's Guide
Fulfillment Order Management User Interface | 267
3. In the Search field, type the reference ID of an order to search.
The text is case-sensitive.
Figure 121: Searching Order
4.
Click the Search button
. Either of the following is the search result:
a. The details of an order that matches your search criteria is displayed.
b. If no match is found, no list is displayed.
Interpreting the Log Messages
It is important to interpret and understand the meaning of the log messages. To explain the log message,
given below is an example illustrating a search performed on an order.
Figure 122: Log Message
The following information is displayed about the searched order:
Column Heading
Description
Date
The date and time the object was updated.
Ref
The reference ID of the object.
Type
The object type, for example, order, plan, order line, or plan item.
Message
The action that was performed on the object. Refer to Understanding the Types
of Log Messages on page 267 to know about the different types of log messages
and their respective meanings.
Understanding the Types of Log Messages
The log messages describe the action that was performed on the object. That action can be any one of the
following:
Log Message
Description
Updated object from status status to status updated an order where:
• object is either order, plan, order line, or plan item
• the first status is the object’s previous status; the second status
is the status the object has been changed to.
TIBCO® Fulfillment Order Management User's Guide
268 | Fulfillment Order Management User Interface
Log Message
Description
Amended order id of status status
an order has been amended where:
• order id is the unique ID of the order.
• status is the current status of the order.
Order order id created with status status an order has been created where:
• order id is the unique ID of the order.
• status is the current status of the order.
Catalog Tab
The Catalog tab allows you to see the catalog based view of the selected enterprise. The view show the initial
Fulillment Catalog Hierarchy Manager in edit mode where you can drag and drop a particular product and
see the Hierarchy view of it.
You are able to view the product model by clicking the Product Id in the orderline tab. The selected product's
model will be shown in the Catalog tab. Click the Back button to navigate back to order's tab with selected
order Id.
The Catalog tab allows you to view the available product configured in the Product repository in right hand
tree view.
Figure 123: Catalog Tab
TIBCO® Fulfillment Order Management User's Guide
Fulfillment Order Management User Interface | 269
Fulfillment Provisioning Service Order Hierarchy
The FP Service order is displayed in plan tab of Fulfillment Order Management. It is integrated with the Plan
item tree hierarchy displayed at left side of the Plan tab. The FP Service Order (SO) integration with the plan
tree hierarchy display:
• Milestone for the related plans. The milestone contains the START, END, and intermediate milestones
• The hierarchy with the FP service order ID, which contains the child node as the OrderLine, Rollback
flow, and nominal flow
• The Rollback and Nominal node contain technical order IDs
• All the technical order line IDs, which can be rolled back are contained under the Rollback flow
If there is no rollback associated with service order then all the technical order IDs fall under the
service order node.
The Fulfillment Provisioning flow accepts and parses an incoming provisioning message and generates a
corresponding service order. The product orders are also created and attached to the service order.
Fulfillment Order Management performs a number of important tasks on the product order, according to its
currently defined rules and other configuration. These tasks include:
• Decompose each product order into one or more technical product orders
• Validate, add, exclude, and sort these technical product orders and attach product order flows to them
• Enrich the data with specific provisioning parameters
TIBCO® Fulfillment Order Management User's Guide
270 | Fulfillment Order Management User Interface
Fulfillment Provisioning Attributes and Parameters
The Fulfillment Provisioning parameters and attributes are displayed on the right side panel of the Plan page.
These are displayed from the FP server based on the following node type selected from the Plan panel:
• Service Order
• Order Line
• Technical Order Line
• Resource Order Line
The attributes and parameters have name-value pairs based on the node selected in the Plan tree
panel. The corresponding process flow is displayed based on the selected node. If the Plan item does
not contain the FP service order, then only Milestone is added to the hierarchy view.
If a Plan item contains the FP service order then the service order is displayed as:
Figure 124: FP Service Order View
Fulfillment Provisioning Process Flow
The Fulfillment Provisioning parameters and attributes are displayed on the right side panel of the Plan page.
These are displayed from the FP server based on the following node type selected from the Plan panel:
• Service Order
• Order Line
• Technical Order Line
The Process Flow displays a graphical representation of process flow for the selected node.
TIBCO® Fulfillment Order Management User's Guide
Fulfillment Order Management User Interface | 271
Figure 125: FP Process Flow
TIBCO® Fulfillment Order Management User's Guide
272 | Fulfillment Order Management User Interface
Searaching for Fulfillment Provisioning Components
When you select Order Id, Order Line Id, Technical Order Id or Resource Id, a filter icon is displayed. Click
the icon to display the coresponding search fields.
Figure 126: Filter Icon
For Order Line Id, Technical Order Id and Resource Id, the search textbox is disabled and and you
need to select minimum and mandatory fields from the filter. Follow the steps below:
1.
2.
3.
4.
Click the Activity Log tab.
In the Search By box, select FP components
In the Search field, type the FP order Id or select the filter.
Click Enter or the search icon to rertrive records.
Figure 127: Filter Icon
TIBCO® Fulfillment Order Management User's Guide
Fulfillment Order Management User Interface | 273
Third Party Access to Fulfillment Order Management User Interface
OMSUI components are exposed to third party applications using Oauth2 authentication. Where the client
needs to get the initial access token for OMSUI and request for particular OMSUI component by providing
the user name and password.
Implementing OMSUIClient.jar
1. Below dependencies can be added to in pom to access omsuiClient.jar:
2. Fetch access token through OMSUIClient for OMSUI:
a. Call getAccessToken (accessTokenUri, clientID, userName, password, clientSecret) method of
AccessTokenService of omsuiClient.
b. Provide the following parameters:
– Access token URL: http://[hostname]:[PortName]/omsui/oauth/token
– Client ID: [Provided by OMSUi] (for example, my-trusted-client-with-secret)
– User name: [user name for OMSUI authorization]
– Password: [password for OMSUI authorization]
– clientSecret: [some secret key provided by OMSUI]
3. OMSUIClient will fetch access tokens for Oauth2 authorization, you can then add those token in the target
URI to access OMSUI.
Single URI to Access OMSUI Component
You can directly access OMSUI by providing target components for each order, dashboard, plan, ruleconfig,
catalog and activitylog. The target parameter in URI redirects to a specific component of OMSUI, for example,
http://localhost:8080/omsui/OTS/main?target=order will redirect to the Order's tab of OMSUI.
The following are the two different scenarios:
• Using OMSUI Client: URI is redirected to a specific component based on the target and search parameters.
• Directly Accessing OMSUI URL with target specified: Initially you are redirected to the login page and
once authentication completes, you will be redirected to a specific component based on the target and
search parameter.
TIBCO® Fulfillment Order Management User's Guide
274 | Fulfillment Order Management User Interface
Target Parameters for OMSUI
The following are the target parameters for OMSUI:
• Order
• Plan
• Ruleconfig
• ActivityLog
Additional Parameters
Apart from target parameters, you can add other parameters for order, plan and activitylog for a specific
search.
The following are search parameters for order, plan, and activitylog:
Order:
• orderRef
• orderID
• status
Plan:
• orderRef
• PlanID
Activitylog
• Type (orderRef/plan)
TIBCO® Fulfillment Order Management User's Guide
Chapter
11
Data Access Interfaces
Overview
Fulfillment Order Management exposes five JMS based interfaces for process components to access or update the
UDF data during order fulfillment.
The following are the interfaces:
1. GetOrder - to get the order requests of all the versions (including amendments) of an order.
2. GetPlan - to get the UDF data of the execution plan associated with an order. This can also include the UDF
data of all comprising plan items.
3. GetPlanItems - to get the UDF data of the specific plan items passed in the request.
4. SetPlan - to update or replace the UDF data of the execution plan associated with an order. This can also include
the UDF data of one or more comprising plan items.
5. SetPlanItem - to update/replace the UDF data of a specific plan item passed in the request.
The following sub-sections cover these JMS interfaces in details.
The schema for these interfaces is
$AF_HOME/schemas/schema/tds/sharedResources/schemas/services/TransientDataStoreService.xsd.
Topics
•
•
•
•
•
Get Order
Get Plan
Get Plan Items
Set Plan
Set Plan Item
TIBCO® Fulfillment Order Management User's Guide
276 | Data Access Interfaces
Get Order
Overview
The GetOrder interface can be used by the process components to retrieve a specific order from the Fulfillment
Order Management system. It is a synchronous request/reply interface on a JMS queue that returns a reply
either to the specified JMSReplyTo destination on the request message or to the default reply queue if not
specified.
If an exception occurs during Get Order operation then it is logged into the omsServer log. The details of the
exception are returned in the response.
Get Order Request
The request specification is as follows:
Queue or Topic Queue
Destination
tibco.aff.tds.order.read.request
The following properties should be passed in the request message header:
Element
Type
Cardinality
Description
_nm_
String
Required
Interface identifier name; MUST be set as
GetOrderRequestEvent.
businessTransactionID String
Optional
Unique identifier for tracing purposes across function calls.
This is used for logging.
correlationID
String
Optional
Unique identifier for tracing purposes across a single
function call. This is generally used by the calling
application to correlate requests and responses.
orderID
String
Required
Internal unique identifier for the order to retrieve.
requestReply
Boolean
Required
If set to true:
The response will be sent on the temporary queue by
default or on the destination set as JMSReplyTo property
in the request message.
If set to false:
The response will be sent on
queue.
allValues
Boolean
Required
If true, retrieve all versions of the order in case of
amendments.
There is no body (payload) associated with the request message.
Get Order Response
The response specification is as follows:
TIBCO® Fulfillment Order Management User's Guide
tibco.aff.tds.order.reply
Data Access Interfaces | 277
Queue or
Topic
Queue
Destination
temp queue or JMSReplyTo destination or tibco.aff.tds.order.reply queue
The response message contains the following header properties:
Element
Type
Cardinality Description
businessTransactionID String
Optional
Unique identifier for tracing purposes across function calls.
This is used for logging.
correlationID
String
Optional
Unique identifier for tracing purposes across a single function
call. This is generally used by the calling application to
correlate requests and responses.
success
Boolean
Required
Flag indicating if the call was successful.
messageCode
String
Required
Result message code.
message
String
Required
Result message.
orderID
String
Required
Internal unique identifier for the order specified in the request.
found
Boolean
Required
Flag indicating if the order was found.
The response message contains the XML payload as per the following schema:
Figure 128: Get Order Response
The following table lists the details of the elements.
Element
Type
Cardinality Description
businessTransactionID String
Optional
Unique identifier for tracing purposes across function calls.
resultStatus
Required
Result status type. See Appendix A for the specification of this
type.
Type
TIBCO® Fulfillment Order Management User's Guide
278 | Data Access Interfaces
order
Type
Optional
Order type. If the order is not found this will be omitted.
order/orderID
String
Required
Internal unique identifier for the order.
order/orderRef
String
Required
External unique identifier for the order.
order/planID
String
Optional
The internal unique identifier for the plan for the order if it exists.
order/status
String
Required
The Status of the order from a cache data store perspective (active
or complete)
0-M
Xml string representation of the order, multiple if all versions are
requested, otherwise just the active one
order/serializedOrder String
Get Order Messages and Message Codes
The error codes and their respective error messages for the Get Order interface are as follows:
Table 5: Get Order Messages and Message Codes
Message Code in Response
Header and Result Status
Message in Response Header
and Result status
Scenario
FOM-DATA-ACCESS-SUCCESS-0000
Successfully processed
Order is found and data is mapped
in the response successfully.
GetOrderRequestEvent
FOM-DATA-ACCESS-INVALID-INPUT-9999
Invalid value '' for input orderID in orderID parameter in the request
GetOrderReqestEvent
header is null or empty.
FOM-DATA-ACCESS-ORDER-NOT-FOUND-9999
Order not found for orderID
<orderID value>
FOM-DATA-ACCESS-INTERNAL-ERROR-9999
Internal error occurred while
Any other exception occurred while
processing GetOrderReqestEvent processing the request.
FOM-DATA-ACCESS-DBCONN-ERROR-9999
Database connection issues
occurred while processing
GetOrderReqestEvent
TIBCO® Fulfillment Order Management User's Guide
Order is not found against the
orderID specified in the request
header.
Resource Failure (DB connection)
issues are encountered while
processing the request.
Data Access Interfaces | 279
Get Plan
Overview
The GetPlan interface can be used by the process components to retrieve the plan corresponding to an order
from the FOM system. It is a synchronous request/reply interface on a JMS queue that returns a reply either
to the specified JMSReplyTo destination on the request message or to the default reply queue if not specified.
If an exception occurs during GetPlan operation then it is logged into the omsServer log. The details of the
exception are returned in the response.
Get Plan Request
The request specification is as follows:
Queue or Topic
Queue
Destination
tibco.aff.tds.plan.read.request
The following properties should be passed in the request message header:
Element
Type
Cardinality
Description
_nm_
String
Required
Interface identifier name; MUST be set as
GetPlanRequestEvent.
businessTransactionID String
Optional
Unique identifier for tracing purposes across
function calls.
planID
String
Required
Internal unique identifier for the plan to retrieve.
correlationID
String
Optional
requestReply
Boolean
Required
Unique identifier for tracing purposes across a
single function call. This is generally used by the
calling application to correlate requests and
responses.
If set to true:
The response will be sent on the temporary queue
by default or on the destination set as JMSReplyTo
property in the request message.
If set to false:
The response will be sent on
tibco.aff.tds.plan.reply
idsOnly
Boolean
Required
queue.
If true will only return the IDs of elements rather
than all plan data. Otherwise if false will return all
plan data.
TIBCO® Fulfillment Order Management User's Guide
280 | Data Access Interfaces
includeItems
Boolean
Required
If true will return all plan items with the plan.
Otherwise if false then only the plan details are
returned.
originator
String
Optional
The component which has originated this call. E.g.
the name of the process component
PC_BUNDLE_PROVIDE.
There is no body (payload) associated with the request message.
Get Plan Response
The response contains a UDF, namely 'PLAN_DESCRIPTION' under the Plan element which gives the plan
description to the process components. This value comes from the order description provided during order
submission process. If the order description is not provided then a default plan description 'Plan For' <order
ref> is returned in the PLAN_DESCRIPTION UDF field.
The response specification is as follows:
Queue or Topic
Queue
Destination
temp queue or JMSReplyTo destination or tibco.aff.tds.plan.reply queue
The response message contains the following header properties:
Element
Type
Cardinality
Description
businessTransactionID
String
Optional
Unique identifier for tracing
purposes across function calls.
This is used for logging.
correlationID
String
Optional
Unique identifier for tracing
purposes across a single function
call. This is generally used by the
calling application to correlate
requests and responses.
success
Boolean
Required
Flag indicating if the call was
successful.
messageCode
String
Required
Result message code.
message
String
Required
Result message.
planID
String
Required
Internal unique identifier for the
plan specified in the request.
found
Boolean
Required
Flag indicating if the plan was
found.
The response message contains the XML payload as per the following schema:
TIBCO® Fulfillment Order Management User's Guide
Data Access Interfaces | 281
Figure 129: Get Plan Response
The following table lists the details of the elements.
Element
Type
Cardinality Description
businessTransactionID
String
Optional
Unique identifier for tracing purposes across
function calls.
resultStatus
Type
Required
Result status type. See Appendix A for the
specification of this type.
plan
Type
Optional
Plan type. If the plan was not found this will be
omitted.
plan/planID
String
Required
Internal unique identifier for the plan.
plan/orderID
String
Required
Internal unique identifier for the order for the plan.
plan/orderRef
String
Required
External unique identifier for the order for the plan.
plan/udf
Type
0-M
UDF type.
plan/udf/type
String
Optional
Type of the user defined field.
plan/udf/flavour
String
Optional
Flavour of the UDF. The valid values are one of the
following three:
• config - For UDF corresponding to a
characteristic in the product model or a system
UDF generated by AOPD.
• input - For UDF passed in the order.
TIBCO® Fulfillment Order Management User's Guide
282 | Data Access Interfaces
• output - For UDF set by the process component.
plan/udf/name
String
Required
Field name.
plan/udf/value
String
Optional
Field value.
plan/udf/originalValue
String
Optional
Original field value at time of plan creation.
plan/udf/lastModified
DateTime
Optional
Timestamp when the UDF was last modified.
plan/planItem
Type
0-M
Plan item type.
plan/planItem/planItemID String
Required
Internal unique identifier for the plan item.
plan/planItem/planItemName String
Optional
Name of the process component.
plan/planItem/udf
0-M
UDF type.
plan/planItem/udf/type String
Optional
Type of the user defined field.
plan/planItem/udf/flavour String
Optional
Flavour of the UDF. The valid values are one of the
following three:
• config - For UDF corresponding to a
characteristic in the product model or a system
UDF generated by AOPD.
• input - For UDF passed in the order.
• output - For UDF set by the process component.
plan/planItem/udf/name String
Required
Field name.
plan/planItem/udf/value String
Optional
Field value.
plan/planItem/udf/originalValue String
Optional
Original field value at time of plan creation.
plan/planItem/udf/lastModified DateTime
Optional
Timestamp when the UDF was last modified.
plan/planItem/parentID String
0-M
plan/planItem/childID
String
0-M
IDs of the plan items on which the current plan item
depends.
plan/planItem/siblingID String
0-M
IDs of the plan items corresponding to
SIBLING_PRODUCT_* of the product fulfilled by
current plan item.
plan/planItem/dependentID String
0-M
IDs of the plan items corresponding to
DEPENDENT_PRODUCT_* of the product fulfilled
by current plan item.
plan/status
String
Required
Status of the plan from a data perspective: active or
complete.
plan/planDescription
String
Optional
Plan description.
Type
IDs of the plan items which depend on the current
plan item.
Get Plan Messages and Message Codes
The error codes and their respective error messages for the Get Plan interface are as follows:
TIBCO® Fulfillment Order Management User's Guide
Data Access Interfaces | 283
Table 6: Get Plan Messages and Message Codes
Message Code in Response
Header and Result Status
Message in Response Header
and Result Status
Scenario
FOM-DATA-ACCESS-SUCCESS-0000
Successfully processed
Plan is found and data is mapped
in the response successfully.
GetPlanRequestEvent
FOM-DATA-ACCESS-INVALID-INPUT-9999
Invalid value '' for input planID in planID parameter in the request
GetPlanRequestEvent
header is null or empty.
FOM-DATA-ACCESS-PLAN-NOT-FOUND-9999
Plan not found for planID <planID Plan is not found against the
value>
planID specified in the request
header.
FOM-DATA-ACCESS-INTERNAL-ERROR-9999
Internal error occurred while
Any other exception occurred while
processing GetPlanRequestEvent processing the request.
FOM-DATA-ACCESS-DBCONN-ERROR-9999
Database connection issues
occurred while processing
GetPlanRequestEvent
Resource Failure (DB connection)
issues are encountered while
processing the request.
TIBCO® Fulfillment Order Management User's Guide
284 | Data Access Interfaces
Get Plan Items
Overview
The GetPlanItems interface can be used by the process components to retrieve the data of one or many plan
items in the plan corresponding to an order from the FOM system. It is a synchronous request/reply interface
on a JMS queue that returns a reply either to the specified JMSReplyTo destination on the request message
or to the default reply queue if not specified.
If an exception occurs during GetPlanItems operation, then it is logged into the omsServer log. The details
of the exception are returned in the response.
Get Plan Items Request
The request specification is as follows:
Queue or Topic
Queue
Destination
tibco.aff.tds.plan.read.request
The following properties should be passed in the request message header:
Element
Type
Cardinality
Description
_nm_
String
Required
Interface identifier name; MUST be set as
GetPlanItemsRequestEvent.
businessTransactionID
String
Optional
Unique identifier for tracing purposes
across function calls.
planID
String
Required
Internal unique identifier for the plan to
retrieve.
correlationID
String
Optional
requestReply
Boolean
Required
Unique identifier for tracing purposes
across a single function call. This is
generally used by the calling application to
correlate requests and responses.
If set to true:
The response will be sent on the temporary
queue by default or on the destination set
as JMSReplyTo property in the request
message.
If set to false:
The response will be sent on
tibco.aff.tds.plan.reply
idsOnly
Boolean
TIBCO® Fulfillment Order Management User's Guide
Required
queue.
If true will only return the IDs of elements
rather than all plan data. Otherwise if false
will return all plan data.
Data Access Interfaces | 285
originator
String
Optional
The component which has originated this
call. E.g. the name of the process component
PC_BUNDLE_PROVIDE.
The request message body should contain the XML payload as per the following schema:
Figure 130: Get Plan Items Request
The following table lists the details of the elements.
Element
Type
Cardinality
Description
businessTransactionID String
Optional
Unique identifier for tracing purposes across function calls.
planID
String
Required
Internal unique identifier for the plan to retrieve.
idsOnly
String
Optional
If true will only return the IDs of elements rather than all
plan data. Otherwise if false will return all plan data.
udfFlavour
String
Optional
Currently not implemented.
udfMatch
String
Optional
Currently not implemented.
planItem
Type
0-M
Plan item type.
planItem/planItemID String
Required
Internal unique identifier for the plan item to retrieve.
planItem/planItemName String
Optional
Not Applicable.
planItem/udf
Type
0-M
Not Applicable.
parentID
String
0-M
Not Applicable.
TIBCO® Fulfillment Order Management User's Guide
286 | Data Access Interfaces
childID
String
0-M
Not Applicable.
siblingID
String
0-M
Not Applicable.
dependentID
String
0-M
Not Applicable.
Get Plan Items Response
The response specification is as follows:
Queue or Topic
Queue
Destination
temp queue or JMSReplyTo destination or tibco.aff.tds.plan.reply queue
The response message contains the following header properties:
Element
Type
Cardinality
Description
businessTransactionID String
Optional
Unique identifier for tracing purposes
across function calls. This is used for
logging.
correlationID
String
Optional
Unique identifier for tracing purposes
across a single function call. This is
generally used by the calling
application to correlate requests and
responses.
Success
Boolean
Required
Flag indicating if the call was
successful.
messageCode
String
Required
Result message code.
Message
String
Required
Result message.
planID
String
Required
Internal unique identifier for the plan
specified in the request.
Found
Boolean
Required
Flag indicating if the plan was found.
The response message contains the XML payload as per the following schema:
TIBCO® Fulfillment Order Management User's Guide
Data Access Interfaces | 287
Figure 131: Get Plan Items Response
The following table lists the details of the elements.
Element
Type
Cardinality
Description
businessTransactionID
String
See Image
Unique identifier for tracing purposes across
function calls.
resultStatus
Type
See Image
Result status type. See Appendix A for the
specification of this type.
planItem
Type
0-M
Plan item type.
planItem/planItemID
String
Required
Internal unique identifier for the plan item.
planItem/planItemName String
Optional
Name of the process component.
planItem/udf
Type
0-M
UDF type.
planItem/udf/type
String
Optional
Type of the user defined field.
planItem/udf/flavour
String
Optional
Flavour of the UDF. The valid values are one
of the following three:
• config - For UDF corresponding to a
characteristic in the product model or a
system UDF generated by AOPD.
• input - For UDF passed in the order.
TIBCO® Fulfillment Order Management User's Guide
288 | Data Access Interfaces
• output - For UDF set by the process
component.
planItem/udf/name
String
Required
Field name.
planItem/udf/value
String
Optional
Field value.
planItem/udf/originalValue String
Optional
Original field value at time of plan creation.
planItem/udf/lastModified DateTime
Optional
Timestamp when the UDF was last modified.
planItem/parentID
String
0-M
IDs of the plan items which depends on the
current plan item.
planItem/childID
String
0-M
IDs of the plan items on which the current
plan item depends.
planItem/siblingID
String
0-M
IDs of the plan items corresponding to
SIBLING_PRODUCT_* of the product
fulfilled by current plan item.
planItem/dependentID String
0-M
IDs of the plan items corresponding to
DEPENDENT_PRODUCT_* of the product
fulfilled by current plan item.
Get Plan Items Messages and Message Codes
The error codes and their respective error messages for the Get Plan Items interface are as follows:
Table 7: Get Plan Items Messages and Message Codes
Message Code in Response
Header and Result Status
Message in Response Header
and Result Status
Scenario
FOM-DATA-ACCESS-SUCCESS-0000
Successfully processed
PlanItem or PlanItems are found
and data is mapped in the response
successfully.
GetPlanItemsRequestEvent
FOM-DATA-ACCESS-INVALID-INPUT-9999
Invalid value '' for input planID in planID parameter in the request
GetPlanItemsRequestEvent
header or XML payload is null or
empty.
FOM-DATA-ACCESS-INVALID-INPUT-9999
Invalid value '' for input
planItemID in
GetPlanItemsRequestEvent
FOM-DATA-ACCESS-INVALID-REQUEST-9999
Invalid payload in
GetPlanItemsRequestEvent
planItemID parameter in the
request XML payload is null or
empty.
XML payload in the request is not
valid.
FOM-DATA-ACCESS-INCONSISTENT-INPUT-9999
Inconsistent input values in request Value of planID parameter in the
header and payload
request header and XML payload
is not consistent.
FOM-DATA-ACCESS-PLANITEM-NOT-FOUND-9999
PlanItem not found for planID
<planID value> and planItemID
<planItemID value>
PlanItem is not found against the
planID and planItemID specified
in the request header.
FOM-DATA-ACCESS-INTERNAL-ERROR-9999
Internal error occurred while
processing
Any other exception occurred while
processing the request.
GetPlanItemsRequestEvent
TIBCO® Fulfillment Order Management User's Guide
Data Access Interfaces | 289
Message Code in Response
Header and Result Status
Message in Response Header
and Result Status
Scenario
FOM-DATA-ACCESS-DBCONN-ERROR-9999
Database connection issues
occurred while processing
Resource Failure (DB connection)
issues are encountered while
processing the request.
GetPlanItemsRequestEvent
TIBCO® Fulfillment Order Management User's Guide
290 | Data Access Interfaces
Set Plan
Overview
The SetPlan interface can be used by the process components to add a new UDF or update the value of an
existing UDF of plan or any of the containing plan items in the Fulfillment Order Management system.
However, it is suggested to use this interface for plan level UDFs only since there is a separate interface for
plan items as explained further in this guide.
It is a synchronous request/reply interface on a JMS queue that returns a reply either to the specified
JMSReplyTo destination on the request message or to the default reply queue if not specified.
If an exception occurs during SetPlan operation, then it is logged into the omsServer
the exception are returned in the response.
log.
The details of
Set Plan Request
The request specification is as follows:
Queue or
Topic
Queue
Destination
tibco.aff.tds.plan.request
The following properties should be passed in the request message header:
Element
Type
Cardinality
Description
_nm_
String
Required
Interface identifier name; MUST be set as SetPlanRequestEvent.
businessTransactionID String
Optional
Unique identifier for tracing purposes across function calls.
planID
String
Required
Internal unique identifier for the plan to retrieve.
correlationID
String
Optional
requestReply
Boolean
Required
Unique identifier for tracing purposes across a single function
call. This is generally used by the calling application to
correlate requests and responses.
If set to true:
The response will be sent on the temporary queue by default
or on the destination set as JMSReplyTo property in the
request message.
If set to false:
The response will be sent on tibco.aff.tds.plan.reply
queue.
replace
Boolean
Required
If set to true:
All the existing UDFs will be replaced by the UDFs that are
present in the request.
If set to false:
TIBCO® Fulfillment Order Management User's Guide
Data Access Interfaces | 291
The UDFs passed in the request will be merged with the
existing UDFs.
In any of the above case, the uniqueness of a UDF is
maintained on the basis of the 'name' and 'flavor' combination
in the UDF. A UDF having exactly same 'name' and 'flavor'
will not be duplicated, if the flag EnableUniqueUDFNames is
set to true in OMS configurations. In case of multiple UDFs
with exactly same name and flavor in the request, the value
from the last encountered UDF will be considered.
originator
String
Optional
The component which has originated this call. E.g. the name
of the process component PC_BUNDLE_PROVIDE.
The request message body should contain the XML payload as per the following schema:
Figure 132: Set Plan Request
The following table lists the details of the elements.
Element
Type
Cardinality
Description
businessTransactionID
String
Optional
Unique identifier for tracing purposes across
function calls.
Plan
Type
Required
Plan type.
plan/planID
String
Required
Internal unique identifier for the plan to update.
plan/ordered
String
Required
Internal unique identifier for the order related
to the plan to update.
plan/orderRef
String
Required
External unique identifier for the order related
to the plan to update.
TIBCO® Fulfillment Order Management User's Guide
292 | Data Access Interfaces
plan/udf
Type
0-M
plan/udf/type
String
Optional
Type of the user defined field.
plan/udf/flavour
String
Optional
Flavour of the UDF. Must be set as output.
plan /udf/name
String
Required
Field name.
plan/udf/value
String
Required
Field value.
plan/planItem
Type
0-M
Plan item type.
plan/planItem/planItemID String
Required
Internal unique identifier for the plan item to
update.
plan/planItem/planItemName String
Optional
Process component name.
plan/planItem/udf
0-M
UDF type.
plan/planItem/udf/type String
Optional
Type of the user defined field.
plan/planItem/udf/flavour String
Optional
Flavour of the UDF. Must be set as output.
plan/planItem/udf/name String
Required
Field name.
plan/planItem/udf/value String
Required
Field value.
replace
Optional
If true it completely replaces the plan item,
otherwise merges the UDF data.
Type
Any
Set Plan Response
The response specification is as follows:
Queue or Topic Queue
Destination
temp queue or JMSReplyTo destination or tibco.aff.tds.plan.reply queue
The response message contains the following header properties:
Element
Type
Cardinality
Description
businessTransactionID String
Optional
Unique identifier for tracing purposes across
function calls. This is used for logging.
correlationID
String
Optional
Unique identifier for tracing purposes across a
single function call. This is generally used by
the calling application to correlate requests and
responses.
success
Boolean
Required
Flag indicating if the call was successful.
messageCode
String
Required
Result message code.
message
String
Required
Result message.
TIBCO® Fulfillment Order Management User's Guide
Data Access Interfaces | 293
planID
String
Required
Internal unique identifier for the plan specified
in the request.
There is no body (payload) associated with the response message.
Set Plan Messages and Message Codes
The error codes and their respective error messages for the Set Plan interface are as follows:
Table 8: Set Plan Messages and Message Codes
Message Code in Response Header Message in Response Header
and Result Status
and Result Status
FOM-DATA-ACCESS-SUCCESS-0000
Successfully processed
SetPlanRequestEvent
Scenario
Plan is found and UDF data
specified in the request in plan
header and plan items is
updated successfully.
FOM-DATA-ACCESS-INVALID-INPUT-9999
Invalid value '' for input planID in planID parameter in the request
SetPlanRequestEvent
header or XML payload is null
or empty.
FOM-DATA-ACCESS-INVALID-REQUEST-9999
Invalid payload in
SetPlanRequestEvent
XML payload in the request is
not valid.
FOM-DATA-ACCESS-INCONSISTENT-INPUT-9999
Inconsistent input values in request Value of planID parameter in
header and payload
the request header and XML
payload is not consistent.
FOM-DATA-ACCESS-PLAN-NOT-FOUND-9999
Plan not found for planID <planID Plan is not found against the
value>
planID specified in the request.
FOM-DATA-ACCESS-INTERNAL-ERROR-9999
Internal error occurred while
Any other exception occurred
processing SetPlanRequestEvent while processing the request.
FOM-DATA-ACCESS-DBCONN-ERROR-9999
Database connection issues
occurred while processing
SetPlanRequestEvent
Resource Failure (DB
connection) issues are
encountered while processing
the request.
TIBCO® Fulfillment Order Management User's Guide
294 | Data Access Interfaces
Set Plan Item
Overview
The SetPlanItem interface can be used by the process components to add a new UDF or update the value of
an existing UDF of the plan items in a plan in the Fulfillment Order Management System.
It is a synchronous request/reply interface on a JMS queue that returns a reply either to the specified
JMSReplyTo destination on the request message or to the default reply queue if not specified.
If an exception occurs during SetPlanItem operation then it is logged into the omsServer log. The details of
the exception are returned in the response.
Set Plan Item Request
The request specification is as follows:
Queue or Topic
Queue
Destination
tibco.aff.tds.plan.request
The following properties should be passed in the request message header:
Element
Type
Cardinality
Description
_nm_
String
Required
Interface identifier name; MUST be set as
SetPlanItemRequestEvent.
businessTransactionID String
Optional
Unique identifier for tracing purposes across
function calls.
planID
String
Required
Internal unique identifier for the plan to retrieve.
correlationID
String
Optional
requestReply
Boolean
Required
Unique identifier for tracing purposes across a
single function call. This is generally used by the
calling application to correlate requests and
responses.
If set to true:
The response will be sent on the temporary queue
by default or on the destination set as JMSReplyTo
property in the request message.
If set to false:
The response will be sent on
tibco.aff.tds.plan.reply
replace
Boolean
Required
queue.
If set to true:
All the existing UDFs will be replaced by the UDFs
that are present in the request.
If set to false:
TIBCO® Fulfillment Order Management User's Guide
Data Access Interfaces | 295
The UDFs passed in the request will be merged
with the existing UDFs.
In any of the earlier mentioned cases, the
uniqueness of a UDF is maintained on the basis
of the 'name' and 'flavor' combination in the UDF.
A UDF having the exact same 'name' and 'flavor'
will not get duplicated, if the flag
EnableUniqueUDFNames is set to true in OMS
configurations. In case of multiple UDFs with the
exact same name and flavor in the request, the
value from the last encountered UDF will be
considered.
planItemID
String
Required
Internal unique identifier for the plan item to
update.
originator
String
Optional
The component which has originated this call. E.g.
the name of the process component
PC_BUNDLE_PROVIDE.
The request message body should contain the XML payload as per the following schema:
Figure 133: Set Plan Item Request
The following table lists the details of the elements.
TIBCO® Fulfillment Order Management User's Guide
296 | Data Access Interfaces
Element
Type
Cardinality
Description
businessTransactionID
String
Optional
Unique identifier for tracing purposes across
function calls.
planID
String
Required
Internal unique identifier for the plan to update.
planItem
Type
Required
Plan item type. Only UDF Name and Value are
updated. If the UniqueUDFs are enabled for the
engine an update will occur, if disabled the entire
current UDF payload will be dropped and replaced
with the new payload.
planItem/planItemID
String
Required
Internal unique identifier for the plan item to update.
planItem/planItemName String
Optional
Process component name.
planItem/udf
Type
0-M
UDF type.
planItem/udf/type
String
Optional
Type of the user defined field.
planItem/udf/flavour
String
Optional
Flavour of the UDF. Must be set as output.
planItem/udf/name
String
Required
Field name.
planItem/udf/value
String
Required
Field value.
replace
Any
Optional
If true it completely replaces the plan item, otherwise
merges the UDF data.
Set Plan Item Response
The response specification is as follows:
Queue or
Topic
Queue
Destination
temp queue or JMSReplyTo destination or tibco.aff.tds.plan.reply queue
The response message contains the following header properties:
Element
Type
Cardinality
Description
businessTransactionID String
Optional
Unique identifier for tracing purposes across function calls.
This is used for logging.
correlationID
String
Optional
Unique identifier for tracing purposes across a single function
call. This is generally used by the calling application to
correlate requests and responses.
success
Boolean
Required
Flag indicating if the call was successful.
messageCode
String
Required
Result message code.
message
String
Required
Result message.
TIBCO® Fulfillment Order Management User's Guide
Data Access Interfaces | 297
planID
String
Required
Internal unique identifier for the plan specified in the request.
There is no body (payload) associated with the response message.
Set Plan Item Messages and Message Codes
The error codes and their respective error messages for the Set Plan Items interface are as follows:
Table 9: Set Plan Items Messages and Message Codes
Message Code in Response
Header and Result Status
Message in Response Header
and Result Status
Scenario
FOM-DATA-ACCESS-SUCCESS-0000
Successfully processed
PlanItem is found and UDF data
specified in the request is updated
successfully.
SetPlanItemRequestEvent
FOM-DATA-ACCESS-INVALID-INPUT-9999
Invalid value '' for input planID in planID parameter in the request
SetPlanItemRequestEvent
header or XML payload is null or
empty.
FOM-DATA-ACCESS-INVALID-INPUT-9999
Invalid value '' for input
planItemID in
planItemID parameter in the
request header or XML payload is
null or empty.
SetPlanItemRequestEvent
FOM-DATA-ACCESS-INVALID-REQUEST-9999
Invalid payload in
XML payload in the request is not
valid.
SetPlanItemRequestEvent
FOM-DATA-ACCESS-INCONSISTENT-INPUT-9999
Inconsistent input values in request Value of planID or planItemID
header and payload
parameters in the request header
and XML payload are not
consistent.
FOM-DATA-ACCESS-PLANITEM-NOT-FOUND-9999
PlanItem not found for planID
<planID value> and planItemID
<planItemID value>
PlanItem is not found against the
planID and planItemID specified
in the request header.
FOM-DATA-ACCESS-INTERNAL-ERROR-9999
Internal error occurred while
processing
Any other exception occurred while
processing the request.
SetPlanItemRequestEvent
FOM-DATA-ACCESS-DBCONN-ERROR-9999
Database connection issues
occurred while processing
SetPlanItemRequestEvent
Resource Failure (DB connection)
issues are encountered while
processing the request.
TIBCO® Fulfillment Order Management User's Guide
Chapter
12
Best Practices for Fulfillment Order Management
This section covers the best practices that can serve as guidelines for building a fulfillment solution using FOM.
Topics
•
•
•
•
•
Process Component Design Guidelines
BusinessWorks - Asynchronous Process Component
BusinessWorks - Synchronous Process Component
BusinessEvents - Process Component
Exception Handling Guidelines
TIBCO® Fulfillment Order Management User's Guide
300 | Best Practices for Fulfillment Order Management
Process Component Design Guidelines
This topic talks about different guidelines that can be followed for designing and developing the process
components.
Process Component Technology Selection
Process Components may be implemented in any JMS-enabled technology that conforms to the interface
specification in the product documentation.
Generally speaking Process Components can be classified using a combination of the duration of the Process
Component lifecycle as well as a description of the statefulness.
Process Component duration defines how long it takes to execute all tasks in the plan item. There is no
absolute number that defines a short vs. long-lived Process Component. Instead the duration defines whether
or not the task can be amended in-flight:
• Short-lived – an in-flight process cannot be amended. When suspended by Orchestrator the process runs
to completion and returns a complete response.
• Long-lived – an in-flight process can be amended. When suspended by Orchestrator the process may
either run to completion and return a complete response, or it may suspend execution and return a suspend
response. If a suspend response is returned, it must handle an activate request from Orchestrator later to
resume execution.
• Process Component statefulness defines whether or not a Process Component needs to persist state
internally during the life of an invocation. This does not include storing data using OMS data service
interfaces, which is available for all Process Components. Instead the determining requirement is whether
or not state is stored directly within the Process Component:
– Stateless – short-lived process component that is invoked and does not require state persistence.
– Stateful – short or long-lived process component that is invoked and does require state persistence.
The choice of stateless or stateful Process Component is not necessarily determined by whether the backend
systems being invoked are synchronous or asynchronous. Asynchronous backend system invocation is a
common use case for stateful Process Component. However it may be possible to pass a correlationID through
the backend system that allows the use of a stateless Process Component. Consequently a Process Component
is defined as a logical entity that provides a given set of functionality. It does not necessarily translate directly
into a single physical process that is invoked and runs to completion.
If a Process Component requires manual interaction then it will in almost all cases be defined as stateful.
Technology Recommendations based on Requirements
Some technology recommendations for a given set of conditions are as follows:
Requirement
Technology
Short lived process that does one or many
synchronous invocations to back-end systems.
BusinessWorks
BusinessEvents
Short-lived process that does one or many
BusinessWorks
synchronous and/or asynchronous invocations to
BusinessEvents
back-end systems. The back-end system accepts a
correlation ID that comprised of the combination of
orderRef and planItemID.
TIBCO® Fulfillment Order Management User's Guide
Best Practices for Fulfillment Order Management | 301
Requirement
Technology
Short-lived process that does one or many
synchronous and/or asynchronous invocations to
back-end systems. The back-end system accepts a
correlation ID but cannot be comprised of orderRef
and planItemID.
BusinessEvents
Long-lived process that does one or many
synchronous and/or asynchronous invocations to
back-end systems with no manual interaction.
BusinessEvents
Long-lived process that does one or many
iProcess
synchronous and/or asynchronous invocations to
back-end systems with at least one manual interaction.
TIBCO® Fulfillment Order Management User's Guide
302 | Best Practices for Fulfillment Order Management
BusinessWorks - Asynchronous Process Component
This section provides an example on how to approach the implementation of a Business Works process
component that is “asynchronous”, in the sense that the back-end call is asynchronous in nature. After a call
is made to a backend system, the sending process terminates, after passing in a correlation ID that the receiving
process can use to retrieve any context information needed to continue with the processing required. In this
example, only one back-end call is made from the process component.
Use Case Scenario
A telecommunication company wants to provide a new service for new customers and between all the Use
Cases identified there is the Use Case: UserAccount.
This Use Case creates a new user account by calling a backend application and passing it all the information
related to the user. The backend application has an asynchronous interface and after receiving a request will
send a reply back to the caller.
Let’s assume that the Use Case has got:
• A Functional Product (FP) called: UserAccount
• A Technical Product (TP) called: Account, which is related to UserAccount via a Product-Comprised-Of
relationship. To perform an action on the TP Account, an asynchronous backend call is required.
Below there is an Activity Diagram which describes the steps to be performed to create TP Account.
TIBCO® Fulfillment Order Management User's Guide
Best Practices for Fulfillment Order Management | 303
Figure 134: Process Component Example - Use Case Activity Diagram
Account Implementation
As described in the previous section, there is one FP UserAccount and one TP Account.
Once the order for the Product UserAccount has been submitted to OMS, AOPD will generate the PLAN and
the Orchestrator will send a PlanItemExecutionRequest Event with the plan item to be executed based on
the sequence defined in Fulfillment Catalog when the product has been modelled.
The PlanItemExecuteRequest message is received in a main BW process as shown in Figure 134: Process
Component Example - Use Case Activity Diagram on page 303 in the process component implementation.
This process sends a message on a queue which is internal to process component implementation.
Figure 135: Process Component Example: Receive PlanItemExecutionRequest from Orchestrator
Most of the example diagrams for the BW based process components are showing BE Send Event and
BE Receive Event pallets for interaction with Orchestrator. This was possible with the 1.2 version of
TIBCO® Fulfillment Order Management User's Guide
304 | Best Practices for Fulfillment Order Management
TIBCO ActiveFulfillment due to the availability of the BE event references in Orchestrator, exposed
through a project library. However from TIBCO FOM 2.0.x version onwards, the project library usable
in the Designer projects couldn't have the BE event references from Orchestrator. Therefore BW based
process components must use the corresponding JMS based pallets such as JMS Queue Receiver and
JMS Queue Sender in order to interact with the Orchestrator by exchanging the required
request/response messages.
Figure 136: Process Component Example: Send Backend Request
The process in Figure 136: Process Component Example: Send Backend Request on page 304 receives the
message from the internal queue and calls the specific BW process that implements the actual process
component as mentioned in Figure 137: Process Component Example: Backend application call on page 304.
As mentioned in the previous section, the backend interface is asynchronous so when the Process Component
sends a request to the backend application, it also has to send a CorrelationID which needs to be returned
with the response from the backend application in order to correlate it with the request. In this example it is
assumed that the Backend is capable of doing this.
This can be observed in the Figure 137: Process Component Example: Backend application call on page 304
that represents the “Create Account” Process Component which makes a call to the backend application:
Figure 137: Process Component Example: Backend application call
In the Figure 137: Process Component Example: Backend application call on page 304 it is possible to notice
that:
1. The CorrelationID is passed in the call of the CallBackEndApplication.
2. BackEndApplicationName is: “UserAccount”.
3. Action is “create”.
Regarding which CorrelationID to use, one possibility is to use a concatenation of PlanID-PlanItemID. OrderRef
or Order ID could also be used instead of PlanID.
PlanID and PlanItemID can be used to set a UDF using OMS data access interfaces when the Process
Component sends the request to the backend application and this UDF could either contain:
TIBCO® Fulfillment Order Management User's Guide
Best Practices for Fulfillment Order Management | 305
1. A BW process name which will deal with the response.
2. A unique queue name which is used to send a message into it in order to trigger the process that will deal
with the response. This means that each BW process that consumes the reply from the backend application
has to have a unique queue name.
Let’s assume that there will be one BW process that receives all the replies from the backend application and
it will work as a dispatcher of the messages amongst other BW processes that are the consumers of the replies
coming from the backend system.
When the backend application replies it will insert the CorrelationID in the response which can be used to
retrieve information using OMS data access interfaces and the particular UDF which contains the consumer
of the response.
Here it is assumed that TP sends a message to a backend application in a queue and receives the reply by
listening to another queue.
Figure 138: Process Component Example: BW process receiver
In Figure 138: Process Component Example: BW process receiver on page 305 above the JMS Queue Receiver
activity receives the response from the backend application; it is the BW process that receives all the replies
from the backend system. The “GetPlanID” mapper activity parses the id parameter coming from the backend
application and gets the planID and planItemID.
At the end of the process there is a call to a BW process: “ConsumeResponse” which dispatches the response
and it is possible to pass the planID and planItemID to it which will be used to retrieve, using the OMS data
access interfaces, the UDF we set in the request containing the information regarding which BW process has
to be called or to which queue it is necessary to send the reply from the backend application in order to
elaborate the response.
The Figure 139: Process Component Example: Set UDF for response on page 306 shows how to store the UDF
by using the "setPlanItem" JMS data access interface of OMS.
TIBCO® Fulfillment Order Management User's Guide
306 | Best Practices for Fulfillment Order Management
Figure 139: Process Component Example: Set UDF for response
In the Figure 139: Process Component Example: Set UDF for response on page 306 it is possible to observe
that before calling the backend application (CallBackEndApplication), a UDF called “callBackQueue” has
been set with a queue name: “rfs.UserAccount.Account.response”. A BW process as seen in the Figure 141:
Process Component Example: Start Specific BW Technical Product Consumer Process on page 307 will listen
on this queue and will process the message sent by the “ConsumeResponse” BW process as seen in the Figure
140: Process Component Example: BW ConsumeResponse Process on page 306.
Alternatively, as mentioned before, it was also possible to set the UDF with a BW Process name that would
have dealt with the response; in this way the main BW process, which receives all the responses, would have
redirected it to the BW process contained in the UDF by performing a dynamic call to it.
To summarise, these are the steps to be performed by the main BW process that receives all the responses
from the backend application:
1. Upon the receiving of a response from the backend application, retrieve the planID/planItemID from it.
2. Use "getPlanItem" OMS data access interface by using planID/planItemID to retrieve the UDF containing
the BW process that will consume the response.
3. Make a dynamic call to the BW process contained in the UDF and pass the replies obtained from the
backend application as an input to it.
4. If the UDF was set as a queue name, then send a message to the queue specified in the UDF. A BW process
as seen in the Figure 141: Process Component Example: Start Specific BW Technical Product Consumer
Process on page 307 will listen on that queue and process the response received from the back-end
application.
Figure 140: Process Component Example: BW ConsumeResponse Process
TIBCO® Fulfillment Order Management User's Guide
Best Practices for Fulfillment Order Management | 307
Figure 141: Process Component Example: Start Specific BW Technical Product Consumer Process
From the Figure 141: Process Component Example: Start Specific BW Technical Product Consumer Process
on page 307 it is possible to see that if the resultCode coming from the backend application response is not
equal to zero, then a PlanItemExecuteResponse with complete set to true and success set to false is sent back
to orchestrator; otherwise the ImplementConsumer BW process is called and it will consume the response
from the backend application and a successful PlanItemExecuteResponse is sent back to Orchestrator.
Figure 142: Process Component Example: Example of BW Process Component Consumer
When the TP has been executed and the PlanItemExecutionResponse with complete and success set to true
sent back to orchestrator, this will send the PlanItemExecutionRequest for the FP and the Figure 143: Process
Component Example: FP Process Component on page 307 is an example of the BW process that manage the
request for the FP. The FP process component does not make any backend calls,so is simpler than the process
component for the TP. There is always a call to an Implementation BW process that consume the request, it
returns to the process caller and sends a successful PlanItemExecuteResponse back to the Orchestrator.
Figure 143: Process Component Example: FP Process Component
Exception Handling Component
Having a look at the Activity Diagram shown in the Figure 134: Process Component Example - Use Case
Activity Diagram on page 303 it is possible to notice that when a request is submitted to the backend application,
if the error code is equal to zero then the successful path flow is followed (ex: update a variable state with
“Submitted”) whereas if the result code is different from zero, it is possible to have a Retry/Continue or
Rollback scenario.
In this section it is assumed that the Process Component sends/receives a message to/from a queue to
communicate with a backend application.
When the backend application replies with an error code, the Process Component sends a
PlanItemExecutionResponse Event to the Orchestrator with: completed flag set to “true”, success and cancelled
set to “false”.
Here it is necessary to analyse the different kinds of Exception Handling one by one:
1. Retry with Edit
The Process Component made a call to the backend application which replies with an error. Orchestrator
will then communicate with the Exception Handler (see Exception Handling Guidelines on page 313 for
TIBCO® Fulfillment Order Management User's Guide
308 | Best Practices for Fulfillment Order Management
more information) to see what the next action is. The Exception Handler has determined that the required
action is that the data on the order needs to be edited, and the plan item step retried. The Exception Handler
communicates with Orchestrator and asks it to resend the planItem which failed. Orchestrator will resend
another PlanItemExecutionRequest for that Process Component.
2. Continue
In this case, the Exception handler returns to Orchestrator a Resume response. On receipt of the resume,
Orchestrator will send an activate message to the Process Component, with a flag (<resumeExecution>)
to indicate that processing should resume. In this case the Process Component executes the next step that
would have normally executed in a success case scenario, for example: update the installed base. The
Figure 144: Process Component Example: Activate Event on page 308 shows a BW process that implements
the Continue scenario:
Figure 144: Process Component Example: Activate Event
When the Process Component receives the Activate Event(PlanItemActivateRequest Event) message and
the action is not “CANCEL” it means that it has to Resume and carry on with the next step which in the
Figure 144: Process Component Example: Activate Event on page 308 is called the BW process that represent
the continue step.
3. Rollback
In case of Rollback, the following steps will be executed:
– A Cancel Order is sent to OMS by the Exception Handler.
– Orchestrator sends a PlanItemSuspendRequestEvent to the Process Component as shown in the Figure
145: Process Component Example: Suspend Event on page 308. The suspend event is sent because a
plan in execution state needs to go into suspend state before being compensated.
– The Process Component replies with a PlanItemSuspendResponseEvent and sets success and completed
flags to “true”.
– Cancel order is treated as a special case of amendment. An updated plan is created by AOPD to cancel
all the existing plan items. Compensation plan items that are required against some of the existing
plan items are also added in the amended plan so as to actually rollback the tasks there were done by
the existing plan items.
– Once the amendment plan is received by the Orchestrator from AOPD, the Orchestrator will send
PlanItemActivateRequest to all the suspended plan items, for canceling them, by passing the
<cancelWithNoRollback> flag.
– Once the activated plan items are successfully cancelled, the corresponding compensating plan item
(COMP) that were newly added in the amendment plan, will be executed so as to rollback the tasks
that were done by the original plan items.
Figure 145: Process Component Example: Suspend Event
TIBCO® Fulfillment Order Management User's Guide
Best Practices for Fulfillment Order Management | 309
BusinessWorks - Synchronous Process Component
If the backend interface is synchronous, it is possible to implement the process component in a much simpler
way. Of course, be aware of the blocking nature of synchronous calls and the impact this can have on
performance.
Figure 146: Process Component Example: Simple Synchronous BW component
In the Figure 146: Process Component Example: Simple Synchronous BW component on page 309 it can be
seen that a queue requester activity is used to implement the synchronous call to the back-end application
and once the response is received from it, a PlanItemExecuteResponse will be sent to Orchestrator based on
the resultCode. If the resultCode is equal to zero, it sends a PlanItemExecuteResponse with success and
completed equal to “true” otherwise it sends a PlanItemExecuteResponse with completed set to “true” and
success set to “false”. This will trigger the Exception Handler process as described above.
TIBCO® Fulfillment Order Management User's Guide
310 | Best Practices for Fulfillment Order Management
BusinessEvents - Process Component
In case of a BE Process Component it is necessary to create a Concept with a State Machine which will represent
the process component lifecycle.
Figure 147: Process Component Life Cycle
The concept can be created in a rule that fires on receiving PlanItemExecutionRequest event from Orchestrator
to start the Process Component.
This is a good solution in case in the project there are only BE Process Components. In case there are BW and
BE Process Components then the rule has to fire only when the Process Component type is BE. To implement
this, it is possible to create another channel linked to the PlanItemExecutionRequest Event having a selector
such as: processComponentType = 'BE'. In this way the channel will only pick up PlanItemExecutionRequests
coming from the Orchestrator and having BE as processComponentType.
The Figure 148: planItemExecuteRequest (Destination) on page 311 shows how to set the Selector for a BE
Channel:
TIBCO® Fulfillment Order Management User's Guide
Best Practices for Fulfillment Order Management | 311
Figure 148: planItemExecuteRequest (Destination)
In this case then, to create the BE Concept when the Orchestrator sends the PlanItemExecutionRequest Event
for a certain PlanFragment, it is possible to create a rule function having in the declaration the
PlanItemExecutionRequest Event and in the body the code to create the concept that represents the Process
Component.
In the Figure 149: Arguments for PlanItemExecuteRequestEvent on page 311 there is the Argument of the
Rule Function that creates the BE Concept when the PlanItemExecuteRequestEvent comes:
Figure 149: Arguments for PlanItemExecuteRequestEvent
In the Figure 150: Rule Function Code on page 311 there is the body of the Rule Function with the code example
that checks first if the Concept that needs to be created already exists and if not, it creates the Concept:
Figure 150: Rule Function Code
Once that the Concept has been created, it is also necessary to send the PlanItemExecuteResponseEvent back
to the Orchestrator. This can be done in any state of the State Machine based on the logic of the implementation
or alternatively at the END state.
TIBCO® Fulfillment Order Management User's Guide
312 | Best Practices for Fulfillment Order Management
In the Figure 151: Edit Body: StateMachine_End_entryAction on page 312 there is the code example that shows
how to create the PlanItemExecuteResponseEvent and how to send it:
Figure 151: Edit Body: StateMachine_End_entryAction
TIBCO® Fulfillment Order Management User's Guide
Best Practices for Fulfillment Order Management | 313
Exception Handling Guidelines
Exception Handling Guidelines provides information about guidelines that can be followed for handling the
exceptional conditions in process components.
General Approach
FOM does not include any out-of-the-box approach for error handling. The product architecture does account
for exception handlers, and provides the necessary hooks, where it can be integrated with an existing exception
or fallout management system, or to which a custom solution can be connected.
The product capabilities for supporting error handling are fully described in the product documentation,
and it is assumed that the reader is familiar with that document. The basics will not be covered here.
PIF Handler or no PIF Handler
A key question is whether to handle exceptions within the process component itself, or whether to manage
exception handling via Orchestrator and the Plan Item Failed (PIF) handler. In the first case, process
components must only return a success result to Orchestrator, and no PIF handler is required.
In the second case, it is necessary to develop a PIF handler, that receives PlanItemFailedRequest from the
Orchestrator for direction on how to proceed once an error is encountered. The PIF handler must respond to
Orchestrator telling it whether to Retry the plan item, or Continue (that is, mark the plan item as completed
and continue with the plan).
A consideration here is the type of process component. If a process component makes use of a workflow
engine for its implementation, which already includes manual tasks and GUI interaction, it would make
sense for errors in the flow to be managed within the workflow engine, rather than have them passed back
to Orchestrator. If the process component is BW or BE, the PIF handler might be a better option.
Functional Exception against Technical Exception
Any consideration of exception handling should consider the different types of exception that can occur,
which typically fall into two broad categories, Functional exceptions, and Technical exceptions. For the
purposes of this discussion, we define these as follows:
• A Functional Exception occurs when a back-end system returns an error code to the process component,
indicating a problem with the request. Functional exceptions always occur in the context of a process
component. An example could be a request to allocate a phone number that is already in use. Receiving
a Functional Exception is expected to occur under under normal circumstances, and the system is built
to handle these events.
• A Technical Exception occurs when something goes wrong, so that the system is not designed to handle
under normal circumstances. They can occur in process components and also FOM components such as
Orchestrator, OMS, OPE, and so on. They are typically caused by conditions in the external environment,
such as running out of memory, failure in EMS, hardware failure etc. but can also be caused by defects.
Different strategies may be considered for each of these types. For instance, as Functional Exceptions occur
within the context of a process component, and would typically require an operator to review and decide on
remedial action, it makes sense for these to be handled via the Orchestrator and a PIF handler, which might
defer to an external GUI for a resolution.
Technical exception handling is more difficult, as they can be caused by almost anything. In this case, even
if a Technical exception occurs in a plan item, it might make more sense to simply log it and stop execution
of the plan item.
TIBCO® Fulfillment Order Management User's Guide
314 | Best Practices for Fulfillment Order Management
Example Approach
This topic describes an approach for implementing exception handling, where order fallout is managed
externally to the FOM implementation. This is a good approach where the customer site has an existing order
fallout management system, providing GUI screens etc. whose functionality can be leveraged. In the rest of
this topic we will refer to this external error handling system as Exception Management, or EM. Please note
this is an example only, and may not be applicable for your particular circumstance.
In this case, Functional exceptions are managed via the PIF handler, and Technical exceptions via a separate
mechanism.
For Functional exceptions the requirements are to forward all to Exception Management, for an operator to
analyse. The possible resolutions are:
• Retry the Plan Item step, with the possibility to edit input values for the downstream call that failed. Note
this is different to retrying the plan item from the beginning. Some process components could internally
be orchestrating multiple steps.
• Continue the Plan Item, with the possibility to edit output values from the downstream call that failed
(note this may not be quite the same as the Complete PIF handler response, which will instruct Orchestrator
to complete the plan item. There may be activity that we require the process component to complete after
the downstream call but before it completes).
• Rollback the entire order, performing compensating actions if required.
The architectural approach here is to define a clear separation of concerns, between what FOM will do, and
what EM will do. The following diagram shows the approach in the case of Functional exceptions. Also, the
data access GetPlanItem and SetPlanItem calls are used to support the functionality of editing input/output
values.
Figure 152: Example Functional Exception Handling Overview Architecture
The Figure 153: Example Functional Exception Handling FOM Components on page 315 shows an approach
for how this could be implemented within FOM:
TIBCO® Fulfillment Order Management User's Guide
Best Practices for Fulfillment Order Management | 315
Figure 153: Example Functional Exception Handling FOM Components
Plan Item Failed Handler
In this example, the Plan Item Failed (PIF) Hander is built as a pass-through component. It performs the
following:
• On receipt of a PlanItemFailedRequest message from Orchestrator, publishes a message (to EM).
• On receipt of a “Retry” or “Continue” resolution type from EM, creates a PlanItemFailedResponse message
and sends to Orchestrator with an appropriate flag that is either retry, resume, or complete.
• On receipt of a “Rollback” resolution type from EM, send a message to OMS to cancel the entire order.
No PlanItemFailedResponse message is sent to Orchestrator in this case.
Process Component Considerations
When mapping the selected resolution type to a PlanItemFailedResponse to send to Orchestrator, there are
some considerations regarding this and the nature of the process component implementation, i.e. whether it
executes multiple steps, or is atomic.
For process components that implement multiple steps (e.g. a BE process component):
• A Retry action means the entire process component will be re-executed. If what is required is just the
current step to be retried, a Resume action should be specified, not retry.
• A Complete action means the process component will not be invoked again in any way, and the plan item
will simply be marked as complete.
• A distinction needs to be made between a Resume where the current step needs to be retried, or skipped.
There is no way to do this on the PlanItemFailedResponse message, so this needs to be managed another
way, e.g. by setting a UDF on the plan item to indicate which is required.
Pre Qualification Failed Handler
Like the PIF handler, there is no default implementation of the PQF handler provided with the product.
Be aware that the Pre-qualification failed handler deals with errors raised not only in Feasibility, but also,
AOPD. Even if in your architecture you don’t have a Feasibility step, you will always have AOPD, and if
TIBCO® Fulfillment Order Management User's Guide
316 | Best Practices for Fulfillment Order Management
AOPD raises exceptions, Orchestrator will publish an event to the PQF handler and wait for a response. If
there is no PQF handler implemented, nothing further will happen for that order and it will be “stuck”.
Even if AOPD exceptions are expected to be rare for your application (i.e. you validate the order thoroughly
prior to AOPD), consider at the very least, implementing monitoring on the PQF request queue, so that
operations will be aware that AOPD has failed for an order, and some action needs to be taken to move the
order on.
You may want to consider making the PQF handler “just another” source of Technical Exceptions. In this
way, a framework for dealing with automating Technical Exception handling, could be used to also deal with
PQF requests. This is the approach that is described in the next section.
Technical Exception Handling
For Technical exception handling, it is difficult to define a pattern that always can apply, given the diverse
range of possible exceptions that can be raised. Such exceptions can be raised from anywhere – FOM
components, process components, and any other code that may be developed as part of a total fulfilment
solution.
It is of course always good general software engineering practice to build components as resilient as possible
to errors. It may make sense, depending on the context, to build in mechanisms such as retry, when events
such as timeouts occur. Of course, this needs to be weighed up against the additional complexity this introduces
into the solution, and needs to consider the idempotency of interactions. Complex, built-in “self-healing”
type mechanisms themselves increase the risk of coding defects, increase the complexity of testing, and will
never be able to catch all types of errors.
The underlying principle here is, as with Functional exceptions, Technical exceptions will require manual
inspection to determine what to do. The default approach is that all technical exceptions are also dealt with
manually. This can mean messages being manually copied from one queue to another, database entries being
manually edited, etc.
Nevertheless, it is highly desirable, in some common circumstances, for a fulfilment system to be able to
resolve technical exceptions in an automated way. No system can be built to automatically resolve all
exceptions, however one approach is to build a mechanism that can support incremental addition of automated
technical exception resolutions, as the system evolves and experience is gained into the types of exceptions
that can occur, and how best to deal with them. This section outlines a possible approach to building such a
mechanism.
As with the handling of Functional exceptions, it is important to define a clear architectural separation between
the fulfilment system and the system that determines what to do with exceptions. Again, we term this body
Exception Management, see Figure 154: Technical Exception Handling Architecture Overview on page 317.
To simplify the interface, we define here a single “Resolve Exception” service, which is used to resolve all
Technical exceptions. It will expect an argument “Resolution Type”, which is a string that will define what
specific resolution behaviour is required.
It is good practice when building custom components of a fulfilment solution, such as the process components,
any database adapters, enrichment processes etc. to ensure Technical exceptions are caught and logged in a
consistent way. We define a single “Publish Technical Exception” service for FOM to use when publishing
a Technical exception. This same service would be invoked regardless of the source of the Technical exception,
which can be custom code, FOM internal components, or even a PQF error.
When publishing an exception to EM, FOM will need to publish along with the exception, all the information
that it would need to handle the resolution.
TIBCO® Fulfillment Order Management User's Guide
Best Practices for Fulfillment Order Management | 317
Figure 154: Technical Exception Handling Architecture Overview
Types of Technical Exception
We identify the following types of technical exceptions as candidates for automation via this approach. These
are of course not the only types of Technical exception that can occur.
1. Pre FOM submit (i.e. an error that happens during any order pre-processing or enrichment)
a. Resubmit order only action possible – but first state needs to be cleaned from any database tables etc.
b. Relatively easy to automate.
2. Pre-qualification Failed Handler
a. If an error occurs in plan development (or Feasibility, if present).
3. Process Component
a. Most technical exceptions likely to be this type.
b. The Process Component could potentially be restarted (retried), continued or completed, depending
on how far it has progressed.
Fulfillment Order Management Components for Technical Exception Handling
The Figure 155: Components involved in Technical Exception Handling on page 318 outlines the components
within FOM that would be involved in handling technical exceptions. Note that the other components not
directly involved in the solution for technical exception handling are not shown.
It should be noted however that any component within the FOM can generate a technical exception. This
includes those shown below, as well as the FOM core components, such as Orchestrator, data access interfaces,
and AOPD.
TIBCO® Fulfillment Order Management User's Guide
318 | Best Practices for Fulfillment Order Management
Figure 155: Components involved in Technical Exception Handling
The following outlines the required behaviour of the components that need to be built, in the context of
Technical Exception Handling:
Process Component
Technical exceptions occurring during the execution of process components will log a technical exception
directly to Exception Management, via the Technical Exception Logger, and stop execution. Orchestrator will
not be notified when a Technical exception occurs, and will consider the Process Component to be in
“Execution” state. The process component can be retried or continued by the Technical Exception handler,
or the Technical Exception handler can notify Orchestrator directly that the Process Component is complete.
Feasibility
The Feasibility step is invoked by Orchestrator after it has received and stored the order, but before it invokes
AOPD to get the plan. Like AOPD, the feasibility component can return an error to Orchestrator, if Feasibility
fails. Also like AOPD, in the context of the example, a Feasibility error is regarded as a Technical exception,
as Feasibility should always pass under normal circumstances (this may not typically be true though, for
instance if order validation is performed at Feasibility).
Technical Exception Logger
This component publishes Technical exceptions to Exception Management. It should capture all Technical
exceptions generated from custom components, and publish them in a standard way to EM. A standard set
of exception fields should be published, which should include order ids (if available), the component and
service that generated the error, and an error code. The message being processed at that time may also be
logged. The key requirement is that there should be enough information logged to enable EM to choose a
resolution type to be applied to resolve the exception, and enough information to be passed back to the
Technical Exception Handler for it to be able to resolve the exception.
Pre Qualification Failed (PQF) Handler
Its role is to receive notifications that Orchestrator publishes when it receives an error from Feasibility or
AOPD, and publish them to Exception Management.
TIBCO® Fulfillment Order Management User's Guide
Best Practices for Fulfillment Order Management | 319
Technical Exception Handler
Its role is to expose the FOM service for resolving Technical Exceptions for Exception Management to call,
and to implement the logic for performing the resolution. This may involve sending messages to a process
component, or to perform some custom action (such as clean up a database table and resubmit an order). It
may also communicate directly with Orchestrator, for instance to send a PQF Response message.
The number of resolution types this component can expose, may grow over time as new resolutions are
added.
The Figure 156: Process Component Technical Exception Services Overview on page 319 outlines at a high
level, how the Retry, Continue and Complete services could potentially be implemented.
Figure 156: Process Component Technical Exception Services Overview
TIBCO® Fulfillment Order Management User's Guide
Appendix
A
Schema References
Topics
•
•
•
•
Plan Item
ResultStatus
Message
Order Request
TIBCO® Fulfillment Order Management User's Guide
322 | Schema References
Plan Item
Figure 157: Plan Item
Element
Type
Cardinality Description
planItem/planItemID
String
Required
Unique identifier for the plan item within the plan
to be executed.
planItem/description
String
Optional
Description for the plan item to be executed.
planItem/processComponentID String
Required
Unique identifier for the Process Component to be
executed.
planItem/processComponentName String
Required
Process component name for the Process Component
to be executed.
planItem/processComponentVersion String
Optional
Process component version for the Process
Component to be executed.
planItem/processComponentType String
Optional
Process component type for the Process Component
to be executed.
TIBCO® Fulfillment Order Management User's Guide
Schema References | 323
planItem/processComponentRecordType String
Optional
Class of processComponentType.
planItem/orderLine
1-M
Order line type for the plan item to be executed.
planItem/orderLine/orderLineNumber String
Required
Order line number for the order line of the plan item
to be executed.
planItem/orderLine/productID String
Required
Product ID for the order line of the plan item to be
executed.
planItem/orderLine/productVersion String
Optional
Product version for the order line of the plan item
to be executed.
planItem/orderLine/action
String
Required
Order line action for the order line of the plan item
to be executed.
planItem/orderLine/actionMode String
Optional
Order line action mode for the order line of the plan
item to be executed.
planItem/orderLine/quantity
Long
Required
Quantity for the order line of the plan item to be
executed.
planItem/orderLine/uom
String
Required
Unit of measure for the order line of the plan item
to be executed.
planItem/orderLine/subscriberID String
Optional
Subscriber ID for the order line of the plan item to
be executed.
planItem/orderLine/linkID
String
Optional
Link ID for the order line of the plan item to be
executed.
planItem/orderLine/inventoryID String
Optional
Inventory ID for the order line of the plan item to
be executed.
Type
planItem/orderLine/eol
Boolean Required
End of line flag for the order line of the plan item to
be executed. This indicates that this plan item is the
final plan item for the order line.
planItem/action
String
Required
Plan item action for the plan item to be executed.
planItem/actionMode
String
Optional
Plan item action mode for the plan item to be
executed.
TIBCO® Fulfillment Order Management User's Guide
324 | Schema References
ResultStatus
Figure 158: Result Status
Element
Type
Cardinality
Description
deployment
String
Required
The OMS member (value of NODE_ID passed in tomcat's setenv
script) that returned this result. For example, Member1.
service
String
Required
Service that returned this result. It is always returned as
JMS-BASED-DATA-ACCESS-INTERFACE.
operation
String
Required
Operation within the service that returned this result. For
example, GetOrder, GetPlan, or GetPlanItem.
component
String
Required
The component that returned this result. It is always returned
as OMS.
severity
String
Required
Severity result. Valid values are: 1. S - Success 2. E - Error.
code
String
Required
Message code for this result.
message
String
Required
Message details for this result.
TIBCO® Fulfillment Order Management User's Guide
Schema References | 325
Message
Figure 159: Message
Element
Type
Cardinality Description
lineNumber String,
Optional
Order line number that this message refers to.
type
String
Required
Message type. Valid values are:
1. Information
2. Warning
3. Error
Code
String
Required
Message code for this message.
Description String
Required
Message text for this message.
udf
Type
0-M
UDF type.
udf/name
String
Required
User defined field name.
udf/value
String
Required
User defined field value.
TIBCO® Fulfillment Order Management User's Guide
326 | Schema References
Order Request
Figure 160: Order Request
Element
Type
Cardinality Description
orderRef
String
Required
External unique identifier for an order.
header
Type
Required
Order request header type. Refer to the Order Request Header
definition for details.
line
Type
1-M
Order request line type. Refer to the Order Request Line definition for
details.
extension
Type
Optional
Extension attributes for user-defined fields.
extension/#any Any
Required
Any data
TIBCO® Fulfillment Order Management User's Guide
Appendix
B
Samples
Topics
•
•
•
Sample Order XML
Sample Plan Item XML
Sample XPATHs
TIBCO® Fulfillment Order Management User's Guide
328 | Samples
Sample Order XML
The sample order XML is as follows:
<?xml version="1.0" encoding="UTF-8"?>
<Order Id="544">
<orderID>8ae1f9ac3898656f0138986ae70c0001</orderID>
<sessionID>CORRELATION-3baee8b0-b483-47aa-89b2-bf7b03d0c41f</sessionID>
<orderlines Id="545">
<lineID>1</lineID>
<productID>CFS TV</productID>
<action>PROVIDE</action>
<quantity>1.0</quantity>
<requiredByDate>2011-04-30T23:50:00+05:30</requiredByDate>
<LineUsed>false</LineUsed>
<OrderlinesUDF Id="546">
<name>OrderRef</name>
<value>OrderRefID</value>
<flavor>input</flavor>
</OrderlinesUDF>
</orderlines>
<orderlines Id="547">
<lineID>2</lineID>
<productID>CFS Live Box</productID>
<action>PROVIDE</action>
<quantity>1.0</quantity>
<requiredByDate>2011-04-30T23:50:00+05:30</requiredByDate>
<LineUsed>false</LineUsed>
<OrderlinesUDF Id="548">
<name>OrderRef</name>
<value>OrderRefID</value>
<flavor>input</flavor>
</OrderlinesUDF>
</orderlines>
<orderlines Id="549">
<lineID>3</lineID>
<productID>CFS VOIP</productID>
<action>PROVIDE</action>
<quantity>1.0</quantity>
<requiredByDate>2011-04-30T23:50:00+05:30</requiredByDate>
<LineUsed>false</LineUsed>
<OrderlinesUDF Id="550">
<name>OrderRef</name>
<value>OrderRefID</value>
<flavor>input</flavor>
</OrderlinesUDF>
</orderlines>
<status>NewOrder</status>
<currentTime>2012-07-18T10:19:03+05:30</currentTime>
<TineDelay>0</TineDelay>
<customerref>Apple</customerref>
<OrderHeaderUDF Id="551">
<name>Company</name>
<value>Orange</value>
<flavor>input</flavor>
</OrderHeaderUDF>
<Originator>Orchestrator</Originator>
<OrderRef>OrderRefID</OrderRef>
<businessTransactionID>a7eb1e1de1fa45c993f65589dba70648</businessTransactionID>
</Order>
TIBCO® Fulfillment Order Management User's Guide
Samples | 329
Sample Plan Item XML
The sample plan item is as follows:
<?xml version="1.0" encoding="UTF-8"?>
<PlanItem Id="2169">
<planID>PF1</planID>
<parentID>CORRELATION-1b1260e6-9cdd-4903-a184-d473aa11b622</parentID>
<lineID>2</lineID>
<dependentOn>PF10.7747556</dependentOn>
<planDesc> PROVIDE</planDesc>
<planItemID>PF10.8786092</planItemID>
<EOL>N</EOL>
<TimeDelay>0</TimeDelay>
<status>addDependency</status>
<singleUse>false</singleUse>
<sequence>0</sequence>
<sequenceName>leaf</sequenceName>
<action>PROVIDE</action>
<productID>GSMDataService</productID>
<itemMark4Del>false</itemMark4Del>
<mustComplete>true</mustComplete>
<affinityType>ConditionalAffinity</affinityType>
<affintyPlanID>PF1</affintyPlanID>
<affintyPlanDesc> AFFINITY PROVIDE</affintyPlanDesc>
<udfs Id="2170">
<name>TASKID</name>
<value>PF10.8786092</value>
<flavor>config</flavor>
</udfs>
<udfs Id="2172">
<name>PRODUCTID</name>
<value>GSMDataService</value>
<flavor>config</flavor>
</udfs>
<udfs Id="2173">
<name>RECORD_TYPE</name>
<value>SERVICE</value>
<flavor>config</flavor>
</udfs>
<udfs Id="2174">
<name>MSISDN</name>
<value>123</value>
<flavor>input</flavor>
</udfs>
<Ancestors>PF10.7747556</Ancestors>
<cancelUsed>false</cancelUsed>
<M_EP_UDFS Id="2171">
<name>M_EP_UDFS</name>
<value>PF10.8786092</value>
</M_EP_UDFS>
<pI_Used>false</pI_Used>
<isLeaf>false</isLeaf>
<counter>0</counter>
<LinkID>1</LinkID>
<affinityCorrelation>$var/PlanItem[productID='GSMLine']/udfs[name='MSISDN']/value/text()</affinityCorrelation>
<affinityParentGroup>false</affinityParentGroup>
<affinityActionGroup>false</affinityActionGroup>
<isDynamic>false</isDynamic>
</PlanItem>
TIBCO® Fulfillment Order Management User's Guide
330 | Samples
Sample XPATHs
•
<ns0:affinityCondition>exists($var/Order/OrderHeaderUDF[name="SubscriberProduct"and
value="Product BB Network Access"])</ns0:affinityCondition>
•
<ns0:affinityCorrelation>exists($var/Order/OrderHeaderUDF[name="SubscriberProduct"and
value="Product BB Network Access"])</ns0:affinityCorrelation>
•
<ns0:affinityActionValue>$var/Order/orderlines[productID='CFS
STB']/action/text()</ns0:affinityActionValue>
•
<affinityCorrelation>$var/PlanItem[productID='GSMLine']/udfs[name='MSISDN']/value/text()</affinityCorrelation>
TIBCO® Fulfillment Order Management User's Guide
Appendix
C
Global Variables
Topics
•
•
•
AOPD Global Variables
Orchestrator Global Variables
Global Variables and Configurations
TIBCO® Fulfillment Order Management User's Guide
332 | Global Variables
AOPD Global Variables
This table is a mapping that shows the global variables mapped to configuration properties.
For readability purpose, to property names are abbreviated as follow:
• c.t.a.a for com.tibco.af.aopd
• c.t.f.o for com.tibco.fom.oms
Global Variable Name
Configuration Property
Purpose
AFF/Global/Constants/InternalUDFs AOPD Application Flags configuration
UDFList
c.t.a.a.flags.udflist
Internal UDFs to be
skipped for affinity
merging
NA
These properties are not
required in AOPD
NA
These properties are not
required in AOPD
NA
These properties are not
required in AOPD
NA
These properties are not
required in AOPD
NA
These properties are not
required in AOPD
NA
These properties are not
required in AOPD
NA
These properties are not
required in AOPD
NA
These properties are not
required in AOPD
AFF/Global/Constants/InventoryStatus
AFF/Global/Constants/
InventoryUserStatus
AFF/Global/Constants/
LineItemActionModes
AFF/Global/Constants/LineItemActions
AFF/Global/Constants/OfferValidation
AFF/Global/Constants/OrderUDFs
AFF/Global/Constants/PlanUDFs
AFF/Global/Constants/
ProductModelCharacteristics
AFF/Global/Constants/ProductType
TIBCO® Fulfillment Order Management User's Guide
Global Variables | 333
Global Variable Name
Configuration Property
Purpose
NA
These properties are not
required in AOPD
NA
These properties are not
required in AOPD
NA
These properties are not
required in AOPD
AFF/Global/Constants/
RegularExpressions
AFF/Global/Constants/ResultStatus
AffinityUDFNameMerge
c.t.a.a.flags.affinity.affinityudfnamemerge Controls the flag to
merge affinity UDF
name
CharacterisitcsWithoutAffinityPostfix
c.t.a.a.flags.affinity.
characterisitcswithoutaffinitypostfix
To not merge certain
UDFs during Affinity
Sequencing those UDFs
should be added as CSV
in the variable
skipItemSequence
c.t.a.a.flags.skipitemsequence
Within AOPD, if the
sequence is -1, it will
skip the product and all
its mandatory children
in the Execution Plan
MergeAffinityItemDescription
c.t.a.a.flags.affinity.mergeaffinityitemdescription MergeAffinityItemDescription
HierarchySingleUse
c.t.a.a.flags.singleuse.hierarchysingleuse Flag to determine
whether heirarchy child
of single use product
should be deleted
EnableAffinityUDFParent
c.t.a.a.flags.affinity.enableaffinityudfparent Enable the UDF syntax
to determine the parent
product name and
product name of the
affinity plan item
AllowMultipleRequiredProducts
c.t.a.a.flags.allowmultiplerequiredproducts Allow Multiple Required
Products for the same
link ID
IgnorePDOFirstChildDependency
c.t.a.a.flags.ignorepdofirstchilddependency Ignore First child
dependency for source
product in PDO
relationship
LoadInventory
MIG_Password
NA
These properties are not
required in AOPD
c.t.a.a.jms.jndi.security.credentials
Password for the JMS
server events.
TIBCO® Fulfillment Order Management User's Guide
334 | Global Variables
Global Variable Name
Configuration Property
Purpose
MIG_QueueConnectionFactory
NA
These properties are not
required in AOPD
MIG_TopicConnectionFactory
NA
These properties are not
required in AOPD
MIG_Url
c.t.a.a.jms.jndi.url
URL for the JMS server
events.
MIG_Username
c.t.a.a.jms.jndi.security.principal
Username for the JMS
server events.
NA
These properties are not
required in AOPD
NA
These properties are not
required in AOPD
NA
These properties are not
required in AOPD
AFF/OrderManagement/Constants
AFF/OrderManagement/Flags
AFF/OrderManagement/HTTP
AFF/OrderManagement/JMS
The value for the
properties will be picked
up from the JMS config
mentioned above
GLB_PlanDevelopmentAmend
RequestQueue
c.t.f.o.afi.aopd.amendplanrequest.sender.queue
GLB_PlanDevelopmentAmend
ResponseQueue
c.t.f.o.afi.aopd.amendplanresponse.receiver.queue
GLB_PlanDevelopmentNew
RequestQueue
c.t.f.o.afi.aopd.newplanrequest.sender.queue
GLB_PlanDevelopmentNew
ResponseQueue
c.t.f.o.afi.aopd.newplanresponse.receiver.queue
GLB_ProductCataloguePublishTopic
c.t.f.o.afi.productmodel.publish.topic
GLB_ActionCataloguePublishTopic
c.t.f.o.afi.actionmodel.publish.topic
AFF/OrderManagement/ProductManagement/
Interfaces/JMS/Services
The value for the
properties will be picked
up from the JMS config
mentioned above
CommonServicesClientLib/CommonServices
NA
TIBCO® Fulfillment Order Management User's Guide
These properties are not
required in AOPD
Global Variables | 335
Global Variable Name
Configuration Property
Purpose
NA
These properties are not
required in AOPD
NA
These properties are not
required in AOPD
CommonServicesClientLib/Events
CommonServicesClientLib/Timing
TIBCO® Fulfillment Order Management User's Guide
336 | Global Variables
Orchestrator Global Variables
This table is a mapping that shows the global variables mapped to configuration properties.
For readability purpose, to property names are abbreviated as follow:
• c.t.f for com.tibco.fom
Global Variable Name
Configuration Property (name
and propname in
ConfigValues_OMS.xml)
Description
Comments
affv4/common/constants/
resultStatus
Error
NA
These GVs are not
exposed for
modification in
Administrator. In
OMS, this is handled
internally. Hence it is
not carried forward as
a property in
Orchestrator.
Fatal
NA
These GVs are not
exposed for
modification in
Administrator. In
OMS, this is handled
internally. Hence it is
not carried forward as
a property in
Orchestrator.
Information
NA
These GVs are not
exposed for
modification in
Administrator. In
OMS, this is handled
internally. Hence it is
not carried forward as
a property in
Orchestrator.
Success
NA
These GVs are not
exposed for
modification in
Administrator. In
OMS, this is handled
internally. Hence it is
not carried forward as
a property in
Orchestrator.
TIBCO® Fulfillment Order Management User's Guide
Global Variables | 337
Global Variable Name
Configuration Property (name
and propname in
ConfigValues_OMS.xml)
Description
Comments
Warning
NA
These GVs are not
exposed for
modification in
Administrator. In
OMS, this is handled
internally. Hence it is
not carried forward as
a property in
Orchestrator.
NA.
String to be prefixed All the jms
to each JMS
destination name
destination name.
properties in OMS
contains this prefix in
their value itself.
Since beginning, there
is no separate prefix
property. Hence this
GV is not carried
forward as a property
in Orchestrator.
affv4/common/messaging/
jms
GLB_MessagingPrefix
affv4/orchestrator/
configuration
GLB_CleanUpObjectsDelay NA
Auto purge enabled
Time delay in msec
after which the
instances of orders
and plans which are
scheduled to cleanup
will be actually
cleaned up (deleted).
This GV is not
relevant in
Orchestrator and
hence not carried
forward in 2.1.0. Since
OMS DB is the only
datastore now, the
cleanup of order data
from it is handled by
the purge utility.
c.t.f.orch.autoPurgeOnCompletion Flag to enable or
NA
disable auto purge of
orders in Orchestrator
GLB_DefaultProcessComponent Default Process Component Error The name of the
NA
ErrorHandler
Handler c.t.f.orch.pcErrorHandler default error handler
component to which
Orchestrator sends
the PlanItemExecute
FailedRequest for
failed plan items.
GLB_FeasibilityRetries
Feasibility Retries
c.t.f.orch.feasibilityRetries
Retry count for failed NA
Feasibility step.
TIBCO® Fulfillment Order Management User's Guide
338 | Global Variables
Global Variable Name
Configuration Property (name
and propname in
ConfigValues_OMS.xml)
GLB_FeasibilityRetryInterval Feasibility Retry Interval
c.t.f.orch.feasibilityRetryInterval
Description
Comments
Interval in msec to
NA
wait before retrying
failed Feasibility step.
GLB_OPDRetries
OPD Retries c.t.f.orch.OPDRetries Retry count for failed NA
OPD step.
GLB_OPDRetryInterval
OPD Retry Interval
c.t.f.orch.opdRetryInterval
GLB_PlanItemSLAThreshold NA
Constant
Interval in msec to
wait before retrying
failed OPD step.
NA
SLA threshold for
percentage of
maximum duration to
publish an SLA
notification.
Plan Item SLA
notification feature is
removed from
Orchestrator in 2.1.0
release. This GV is not
relevant and hence
not carried forward.
GLB_ProcessComponent Maximum number of retries for Default retry count
Retries
failed process component
for failed process
c.t.f.orch.failedPC.maxRetryCount components.
NA
GLB_ProcessComponent Time interval between consecutive Default retry delay in NA
RetryInterval
retry attempts for failed process msec for failed
component
process components.
c.t.f.orch.failedPC.retryInterval
GLB_SchedulerPollingInterval NA
Polling interval in
msec for scheduler.
This property is used
in BE Orchestrator to
create the BE
scheduler threads on
startup. It is not
relevant in the
Orchestrator and
hence not carried
forward.
GLB_BEProfilerOutputFile NA
Path
The path of output
file to be used by BE
profiler.
This property was
added specifically to
control the BE
engine's profiling. It
is not relevant in the
Orchestrator and
hence not carried
forward.
GLB_BEProfilerLevel
The level of BE engine This property was
profiling
added specifically to
control the BE
engine's profiling. It
is not relevant in the
Orchestrator and
hence not carried
forward.
NA
TIBCO® Fulfillment Order Management User's Guide
Global Variables | 339
Global Variable Name
Configuration Property (name
and propname in
ConfigValues_OMS.xml)
Description
Comments
The time duration in
seconds for which the
profiling is to be
done.
This property was
added specifically to
control the BE
engine's profiling. It
is not relevant in the
Orchestrator and
hence not carried
forward.
NA
Order line cancel
action.
This GV is not
exposed for
modification in
Administrator. In
OMS, this is handled
internally. Hence it is
not carried forward as
a property in
Orchestrator.
NA
NA
None of the GVs
under this category
are exposed for
modification through
Administrator. In
OMS, dependency
status constants are
maintained internally.
Hence these GVs are
not carried forward as
a properties in
Orchestrator.
NA
NA
None of the GVs
under this category
are exposed for
modification through
Administrator. In
Orchestrator, the
error messages are
not exactly same.
Hence these GVs are
not carried forward in
Orchestrator.
GLB_BEProfilerDuration NA
InSeconds
affv4/orchestrator/constants/
actions
Cancel
affv4/orchestrator/constants/
dependencyStatus
NA
affv4/orchestrator/constants/
errors
NA
TIBCO® Fulfillment Order Management User's Guide
340 | Global Variables
Global Variable Name
Configuration Property (name
and propname in
ConfigValues_OMS.xml)
Description
Comments
NA
NA
This property was
introduced and used
in Orchestrator to
TDS integration (pre
2.1.0). It is not
relevant in the
Orchestrator and
hence not carried
forward.
NA
NA
None of the GVs
under this category
are exposed for
modification through
Administrator. In
OMS, milestone
names are maintained
internally. Hence
these GVs are not
carried forward as a
properties in
Orchestrator.
NA
NA
None of the GVs
under this category
are exposed for
modification through
Administrator. In
OMS, milestone
status constants are
maintained internally.
Hence these GVs are
not carried forward as
a properties in
Orchestrator.
NA
NA
None of the GVs
under this category
are exposed for
modification through
Administrator. These
were added in BE
affv4/orchestrator/constants/
Generic
GLB_OriginatorString
affv4/orchestrator/constants/
Milestone
NA
affv4/orchestrator/constants/
milestoneStatus
NA
affv4/orchestrator/constants/
notificationEventName
NA
TIBCO® Fulfillment Order Management User's Guide
Global Variables | 341
Global Variable Name
Configuration Property (name
and propname in
ConfigValues_OMS.xml)
Description
Comments
Orchestrator to
identify the
notification event
type in the common
internal event. None
of these GVs are
relevant and hence
not carried forward as
a properties in
Orchestrator.
affv4/orchestrator/constants/
notifications
NA
NA
NA
None of the GVs
under this category
are exposed for
modification through
Administrator. The
messages to be sent in
various entity status
change notification
events are handled in
Orchestrator
internally. None of
these GVs are
relevant and hence
not carried forward as
a properties in
Orchestrator.
NA
NA
None of the GVs
under this category
are exposed for
modification through
Administrator. In
OMS, order
amendment status
constants are
maintained internally.
Hence these GVs are
not carried forward as
a properties in
Orchestrator.
NA
NA
None of the GVs
under this category
are exposed for
affv4/orchestrator/constants/
orderAmendmentStatus
NA
affv4/orchestrator/constants/
orderLineStatus
NA
TIBCO® Fulfillment Order Management User's Guide
342 | Global Variables
Global Variable Name
Configuration Property (name
and propname in
ConfigValues_OMS.xml)
Description
Comments
modification through
Administrator. In
OMS, order line
status constants are
maintained internally.
Hence these GVs are
not carried forward as
a properties in
Orchestrator.
affv4/orchestrator/constants/
orderStatus
NA
NA
NA
None of the GVs
under this category
are exposed for
modification through
Administrator. In
OMS, order status
constants are
maintained internally.
Hence these GVs are
not carried forward as
a properties in
Orchestrator.
NA
NA
None of the GVs
under this category
are exposed for
modification through
Administrator. In
OMS, plan item status
constants are
maintained internally.
Hence these GVs are
not carried forward as
a properties in
Orchestrator.
NA
NA
None of the GVs
under this category
are exposed for
modification through
Administrator. In
OMS, plan status
constants are
maintained internally.
Hence these GVs are
affv4/orchestrator/constants/
planItemStatus
NA
affv4/orchestrator/constants/
planStatus
NA
TIBCO® Fulfillment Order Management User's Guide
Global Variables | 343
Global Variable Name
Configuration Property (name
and propname in
ConfigValues_OMS.xml)
Description
Comments
not carried forward as
a properties in
Orchestrator.
affv4/orchestrator/constants/
processComponentID
NoReciprocalAction
Need to externalize in
ConfigValues_OMS.xml
Name of the process NA
component to
indicate no reciprocal
action is required on
cancellation.
NonExecuting
Non Executing Planfragment ID
c.t.f.orch.nonexecuting.
planfragmentID
Name of the process NA
component to
indicate that no action
need to be sent to
process components.
affv4/orchestrator/flags
GLB_CleanupObjectsAtEndOf NA
Order
Flag to enable
cleanup of objects at
the end of an order
lifecycle.
This GV is not
relevant in
Orchestrator and
hence not carried
forward in 2.1.0. Since
OMS DB is the only
datastore now, the
cleanup of order data
from it is handled by
the purge utility.
GLB_EnableExternalOrderID NA
Source
Flag to enable
orderID generation
external to
Orchestrator.
This GV is not
relevant in
Orchestrator and
hence not carried
forward in 2.1.0. OMS
generates the unique
orderID for each
incoming order and
the Orchestrator uses
only that.
GLB_EnableFeasibilityError Enable Feasibility Error Handling Flag to enable
Handling
c.t.f.orch.enableFeasibility
PreQualification
ErrorHandling
Failed Handler for
feasibility failures.
NA
GLB_EnableOMSIntegration NA
This GV is not
relevant in
Orchestrator and
hence not carried
forward in 2.1.0. The
Orchestrator is an
integral part of OMS.
Flag to enable OMS
integration.
TIBCO® Fulfillment Order Management User's Guide
344 | Global Variables
Global Variable Name
Configuration Property (name
and propname in
ConfigValues_OMS.xml)
Description
Comments
GLB_EnableOPDError
Handling
Enable OPD Error Handling
c.t.f.orch.enableOPD
ErrorHandling
Flag to enable
PreQualification
Failed Handler for
OPD failures.
NA
GLB_EnableOrderAmendment Enable Order Amendment Status Flag to enable order
StatusNotifications
Change c.t.f.orch.enableOrder
amendment status
AmendmentStatusChange
notifications.
NA
GLB_EnableOrder
Amendments
Flag to enable order
amendments.
There is no need to
have a flag to
enable/disable
amendments.
Amendment
functionality is
widely used by
customers and is
OOTB. Since it is not
relevant, this GV is
not carried forward in
Orchestrator.
GLB_EnableOrderLineStatus Enable OrderLine Status Change
Notifications
c.t.f.orch.enableOrderLine
StatusChange
Flag to enable order
line status
notifications.
NA
GLB_EnableOrderReject
Notifications
Flag to enable order
reject notifications.
Order reject
functionality is not
relevant in 2.1.0. OMS
web service interface
takes care of rejecting
the order by sending
the appropriate
response. Since it is
not relevant, this GV
is not carried forward
in Orchestrator.
Flag to enable order
status notifications.
NA
NA
NA
GLB_EnableOrderStatus Enable Order Status Change
Notifications
c.t.f.orch.enableOrder
StatusChange
GLB_EnablePlanDevelopment Enable Plan development
Flag to enable plan
Notifications
notification
development
c.t.f.orch.enablePlanDevelopment notifications.
Notification
NA
GLB_EnablePlanItemFailed NA
Notifications
This flag was added
in BE Orchestrator
specifically from OMS
perspective. PlanItem
NotificationEvent for
a failed plan item is
published if this flag
TIBCO® Fulfillment Order Management User's Guide
Flag to enable plan
item failed
notifications.
Global Variables | 345
Global Variable Name
Configuration Property (name
and propname in
ConfigValues_OMS.xml)
Description
Comments
is enabled. Based on
the notification, OMS
could show the status
as
ERROR_HANDLER.
Since Orchestrator is
an integral part of
OMS in 2.1.0, it is
handled internally.
This flag is not
relevant and hence
not carried forward.
GLB_EnablePlanItemSLA NA
Notification
Flag to enable SLA
Plan Item SLA
notifications for plan notification feature is
items.
removed from
Orchestrator in 2.1.0
release. This GV is not
relevant and hence
not carried forward.
GLB_EnablePlanItemStatus Enable PlanItem Status Change
Notifications
c.t.f.orch.enablePlanItem
StatusChange
Flag to enable plan
item status
notifications.
NA
Enable Plan Status Change
Flag to enable plan
c.t.f.orch.enablePlan StatusChange status notifications.
NA
GLB_EnablePlanStatus
Notifications
GLB_EnableSubmitOrder NA
Responses
Flag to enable
Orchestrator is an
sending response to integral part of OMS
submit order events. now. OMS web
service is the only
entry point interface
and there is no need
to send any response
event. This GV is not
relevant and hence
not carried forward.
GLB_FeasibilityRequired Feasibility Required
c.t.f.orch.feasibilityRequired
Flag to enable
feasibility step.
GLB_RetryFailedFeasibility Retry Failed Feasibility
c.t.f.orch.retryFailedFeasibility
Flag to enable retry of NA
failed Feasibility step.
GLB_RetryFailedOPD
Flag to enable retry of NA
failed OPD step.
Retry Failed OPD
c.t.f.orch.retryFailedOPD
NA
GLB_RetryFailedProcess Enable retries for failed process
Components
components c.t.f.orch.failedPC.
enableRetry
Flag to enable retry of NA
failed process
components.
GLB_StoreFailedPlanItem NA
Messages
Flag to enable storing This flag is not
failed plan item
relevant and hence
messages.
TIBCO® Fulfillment Order Management User's Guide
346 | Global Variables
Global Variable Name
Configuration Property (name
and propname in
ConfigValues_OMS.xml)
Description
Comments
not carried forward in
Orchestrator.
GLB_StoreFailedProcess
ComponentsMessages
NA
Flag to enable storing
failed process
components
messages.
This flag is not
relevant and hence
not carried forward in
Orchestrator.
GLB_StorePreQualification NA
FailedMessages
Flag to enable storing
failed process Pre
Qualification
messages.
This flag is not
relevant and hence
not carried forward in
Orchestrator.
GLB_EnableBEProfiling
NA
Flag to enable BE
engine's profiling.
This flag is not
relevant and hence
not carried forward in
Orchestrator.
GLB_IncludeOrderOnOrder NA
AmendmentNotification
Flag to include the
order on order
amendment
notifications.
Need to decide on
whether to support
this functionality in
Orchestrator.
GLB_IncludeOrderOnOrder NA
LineNotification
Flag to include the
order on order line
notifications.
Need to decide on
whether to support
this functionality in
Orchestrator.
GLB_IncludeOrderOn
OrderNotification
NA
Flag to include the
order on order
notifications.
Need to decide on
whether to support
this functionality in
Orchestrator.
GLB_IncludePlanOnOrder NA
AmendmentNotification
Flag to include the
plan on order
amendment
notifications.
Need to decide on
whether to support
this functionality in
Orchestrator.
GLB_IncludePlanOnOrder NA
LineNotification
Flag to include the
plan on order line
notifications.
Need to decide on
whether to support
this functionality in
Orchestrator.
GLB_IncludePlanOnOrde NA
rNotification
Flag to include the
plan on order
notifications.
Need to decide on
whether to support
this functionality in
Orchestrator.
NA
None of the GVs
under this category
affv4/orchestrator/flags/
notification
affv4/orchestrator/interfaces/
jdbc/backingstore
NA
NA
TIBCO® Fulfillment Order Management User's Guide
Global Variables | 347
Global Variable Name
Configuration Property (name
and propname in
ConfigValues_OMS.xml)
Description
Comments
are relevant for
Orchestrator since
starting version 2.1.0,
Orchestrator is an
integral part of OMS
now and uses only
OMS DB. Hence these
GVs are not carried
forward in
Orchestrator.
affv4/orchestrator/interfaces/
jms/events
NA
NA
NA
None of the GVs
under this category
are relevant for
Orchestrator since
starting version 2.1.0,
Orchestrator is an
integral part of OMS
now and uses the JMS
connection properties
used by OMS. Hence
these GVs are not
carried forward in
Orchestrator.
GLB_DataDeleteOrder
Request
NA
Delete order request
destination.
DeleteOrderRequestEvent
is not relevant in
Orchestrator and
hence this GV is not
carried forward.
GLB_DataDeleteOrder
Response
NA
Delete order response DeleteOrderResponseEvent
destination.
is not relevant in
Orchestrator and
hence this GV is not
carried forward.
GLB_DataDeletePlan
Request
NA
Delete plan request
destination.
GLB_DataDeletePlan
Response
NA
Delete plan response DeletePlanResponseEvent
destination.
is not relevant in
Orchestrator and
hence this GV is not
carried forward.
affv4/orchestrator/messaging/
jms/destinations
DeletePlanRequestEvent
is not relevant in
Orchestrator and
hence this GV is not
carried forward.
TIBCO® Fulfillment Order Management User's Guide
348 | Global Variables
Global Variable Name
Configuration Property (name
and propname in
ConfigValues_OMS.xml)
Description
Comments
GLB_DataGetOrderRequest NA
Get order request
destination.
GetOrderRequestEvent
is not relevant in
Orchestrator and
hence this GV is not
carried forward.
GLB_DataGetOrderResponse NA
Get order response
destination.
GetOrderResponseEvent
is not relevant in
Orchestrator and
hence this GV is not
carried forward.
GLB_DataGetOrder
SummaryRequest
NA
Get order summary
request destination.
GetOrderSummaryRequest
Event is not relevant
in Orchestrator and
hence this GV is not
carried forward.
GLB_DataGetOrder
SummaryResponse
NA
Get order summary GetOrderSummaryResponse
response destination. Event is not relevant
in Orchestrator and
hence this GV is not
carried forward.
GLB_DataGetPlanItems
Request
NA
Get plan items
request destination.
GLB_DataGetPlanItems
Response
NA
Get plan items
GetPlanItemsResponse
response destination. Event is not relevant
in Orchestrator and
hence this GV is not
carried forward.
GetPlanItemsRequest
Event is not relevant
in Orchestrator and
hence this GV is not
carried forward.
GLB_DataGetPlanRequest NA
Get plan request
destination.
GetPlanRequestEvent
is not relevant in
Orchestrator and
hence this GV is not
carried forward.
GLB_DataGetPlanResponse NA
Get plan response
destination.
GetPlanResponseEvent
is not relevant in
Orchestrator and
hence this GV is not
carried forward.
GLB_ExternalFeasibility
Request
External Feasibility request queue External feasibility
c.t.f.orch.feasibility.request.queue handler request
destination.
NA
GLB_ExternalFeasibility
Response
External Feasibility reply queue
c.t.f.orch.feasibility.reply.queue
NA
TIBCO® Fulfillment Order Management User's Guide
External feasibility
handler response
destination.
Global Variables | 349
Global Variable Name
Configuration Property (name
and propname in
ConfigValues_OMS.xml)
Description
Comments
GLB_ExternalOPDRequest OPDRequest from Orchestrator
receiver queue
c.t.f.oms.afi.orch.opdrequest.
receiver.queue
External plan
NA
development handler
request destination.
GLB_ExternalOPDResponse OPDResponse to Orchestrator
sender queue
c.t.f.oms.afi.orch.opdresponse.
sender.queue
External plan
NA
development handler
response destination.
GLB_ExternalPlanItemFailed PlanItem error handler request
Request
queue
c.t.f.orch.planItem.errhandler.
request.queue
External plan item
NA
failed handler request
destination.
GLB_ExternalPlanItemFailed PlanItem error handler response
Response
queue
c.t.f.orch.planItem.errhandler.
response.queue
External plan item
NA
failed handler
response destination.
GLB_ExternalPreQualification External PreQualificationFailed
FailedRequest
request queue
c.t.f.orch.prequalificationfailed.
request.queue
External
NA
pre-qualification
failed handler request
destination.
GLB_ExternalPreQualification External PreQualificationFailed
FailedResponse
reply queue
c.t.f.orch.prequalificationfailed.
reply.queue
External
NA
pre-qualification
failed handler
response destination.
GLB_InternalDependencyTime NA
Delta
Dependency time
delta trigger
destination.
The JMS queue
specified by this GV
is not relevant and
hence not carried
forward in
Orchestrator. It was
BE implementation
specific.
GLB_InternalFeasibilityRequest NA
Feasibility request
trigger destination.
The JMS queue
specified by this GV
is not relevant and
hence not carried
forward in
Orchestrator. It was
BE implementation
specific.
GLB_InternalOPDRequest NA
OPD request trigger
destination.
The JMS queue
specified by this GV
is not relevant and
hence not carried
forward in
Orchestrator. It was
TIBCO® Fulfillment Order Management User's Guide
350 | Global Variables
Global Variable Name
Configuration Property (name
and propname in
ConfigValues_OMS.xml)
Description
Comments
BE implementation
specific.
GLB_InternalPlanItem
RetryTimeDelta
NA
Plan item retry time
delta trigger
destination.
GLB_InternalPlanItem
SLANotifyTrigger
NA
Plan item SLA trigger The JMS queue
destination.
specified by this GV
is not relevant and
hence not carried
forward in
Orchestrator. It was
BE implementation
specific.
GLB_ModelProcess
ComponentModel
NA
Process component
model publish
destination.
GLB_NotificationOrder
Order status change destination Order change
c.t.f.orch.order.statusChange.destination notification publish
destination.
NA
GLB_NotificationOrder
Amendment
Order Amendment status change Order amendment
destination
change notification
c.t.f.orch.orderAmendment.
publish destination.
statusChange.destination
NA
GLB_NotificationOrderLine OrderLine status change
Order line change
destination
notification publish
c.t.f.orch.orderLine.statusChange. destination.
destination
NA
GLB_NotificationOrderReject NA
The JMS topic
specified by this GV
is not relevant and
hence not carried
forward in
Orchestrator.
Orchestrator uses the
plan fragment from
OMS DB.
TIBCO® Fulfillment Order Management User's Guide
Order reject
notification publish
destination.
The JMS queue
specified by this GV
is not relevant and
hence not carried
forward in
Orchestrator. It was
BE implementation
specific.
The JMS topic
specified by this GV
is not relevant and
hence not carried
forward in
Orchestrator.
Orchestrator uses the
plan fragment from
OMS DB.
Global Variables | 351
Global Variable Name
Configuration Property (name
and propname in
ConfigValues_OMS.xml)
Description
Comments
GLB_NotificationPlan
Plan status change destination
Plan change
c.t.f.orch.plan.statusChange.destination notification publish
destination.
NA
GLB_NotificationPlan
Development
Plan development notification
destination
c.t.f.orch.planDevelopment.
notification.destination
Plan development
notification publish
destination.
NA
GLB_NotificationPlanItem PlanItem status change destination Plan item change
c.t.f.orch.planItem.statusChange. notification publish
destination
destination.
NA
GLB_NotificationPlanItem NA
SLA
Plan item SLA
notification publish
destination.
Plan Item SLA
notification feature is
removed from
Orchestrator in 2.1.0
release. This GV is not
relevant and hence
not carried forward.
GLB_OrchestratorStartup NA
Event
Orchestrator startup
event request for
process component
models
The Orchestrator
doesn't use the queue
specified in this GV
anymore. Hence this
GV is not carried
forward.
GLB_OrchestratorStartup NA
Service
Orchestrator startup
service request for
process component
models
The Orchestrator
doesn't use the queue
specified in this GV
anymore. Hence this
GV is not carried
forward.
GLB_OrderActivate
Activate order request queue
c.t.f.orch.order.
activateRequest.queue
Order activate request NA
publish destination.
GLB_OrderCancel
NA
Order cancel request Order cancellation is
publish destination. implemented and
achieved using order
amendment
functionality. The
Orchestrator doesn't
use the queue
specified in this GV
anymore. Hence this
GV is not carried
forward.
GLB_OrderSubmit
Need to externalize in
ConfigValues_OMS.xml
Order submit request NA
publish destination.
TIBCO® Fulfillment Order Management User's Guide
352 | Global Variables
Global Variable Name
Configuration Property (name
and propname in
ConfigValues_OMS.xml)
Description
Comments
GLB_OrderSuspend
Suspend order request queue
c.t.f.orch.order.
suspendRequest.queue
Order suspend
request publish
destination.
NA
GLB_OrderWithdraw
Need to externalize in
ConfigValues_OMS.xml
Order withdraw
request publish
destination.
NA
GLB_PlanItemActivate
Request
PlanItem activate request queue
c.t.f.orch.planItem.
activate.request.queue
Plan item activate
request destination.
NA
GLB_PlanItemExecute
Request
PlanItem execution request queue Plan item execute
c.t.f.orch.planItem.
request destination.
execute.request.queue
NA
GLB_PlanItemExecute
Response
PlanItem suspend request queue
c.t.f.orch.planItem.
suspend.request.queue
Plan item execute
NA
response destination.
GLB_PlanItemExternal
PlanItem External Dependency
Plan item external
DependencyReleaseRequest Release Request queue
dependency release
c.t.f.orch.planItem.externalDependency. destination.
release.request.queue
NA
GLB_PlanItemMilestone MilestoneNotifyRequest from
NotifyRequest
process components to
Orchestrator queue
c.t.f.orch.planItem.milestone.
notifyRequest.queue
Plan item milestone NA
notify destination
(Process Component
to Orchestrator).
GLB_PlanItemMilestone MilestoneReleaseRequest from
ReleaseRequest
Orchestrator to process
components queue
c.t.f.orch.planItem.
milestone.releaseRequest.queue
Plan item milestone NA
release destination
(Orchestrator to
Process Component).
GLB_PlanItemSuspend
Request
PlanItem suspend request queue
c.t.f.orch.planItem.suspend.
request.queue
Plan item suspend
request destination.
GLB_PlanItemSuspend
Response
PlanItem suspend response queue Plan item suspend
NA
c.t.f.orch.planItem.suspend.
response destination.
response.queue
GLB_PlanOMSSet
NA
GLB_PlanSetPlanItemStatus NA
Request
TIBCO® Fulfillment Order Management User's Guide
NA
Set plan to OMS
destination.
Since Orchestrator is
an integral part of
OMS now, it doesn't
use the queue
specified in this GV.
Hence it is not
relevant and not
carried forward.
Plan item set status
request destination.
The Orchestrator
doesn't use the queue
Global Variables | 353
Global Variable Name
Configuration Property (name
and propname in
ConfigValues_OMS.xml)
Description
Comments
specified in this GV
anymore. Hence this
GV is not relevant
and not carried
forward.
GLB_PlanSetPlanItemStatus NA
Response
Plan item set status
reply destination.
The Orchestrator
doesn't use the queue
specified in this GV
anymore. Hence this
GV is not relevant
and not carried
forward.
GLB_PlanOMSSet
Response
NA
Set plan OMS
Since Orchestrator is
response destination. an integral part of
OMS now, it doesn't
use the queue
specified in this GV.
Hence it is not
relevant and not
carried forward.
GLB_InternalCleanUpOrder NA
Request
CleanUpOrderRequest The JMS queue
destination
specified by this GV
is not relevant and
hence not carried
forward in
Orchestrator. It was
BE implementation
specific.
GLB_InternalCleanUpPlan NA
Request
CleanUpPlanRequest The JMS queue
destination
specified by this GV
is not relevant and
hence not carried
forward in
Orchestrator. It was
BE implementation
specific.
commonServices/configuration
GLB_LogLevel
NA
Log level to be used. The Orchestrator is
Java based and uses
the same Log4J
configurations used
by OMS from
omsServerLog4j.xml
file. Hence this GV is
not carried forward.
TIBCO® Fulfillment Order Management User's Guide
354 | Global Variables
Global Variable Name
Configuration Property (name
and propname in
ConfigValues_OMS.xml)
Description
Comments
GLB_LogPublishLevel
NA
Log level to be used
for publishing the
logs.
The Orchestrator is
Java based and uses
the same Log4J
configurations used
by OMS from
omsServerLog4j.xml
file. Hence this GV is
not carried forward.
GLB_EnableError Publish NA
Flag to enable error
publishing.
The Orchestrator is
Java based and uses
the same Log4J
configurations used
by OMS from
omsServerLog4j.xml
file. Hence this GV is
not carried forward.
GLB_EnableInstrumentation NA
Publish
Flag to enable
instrumentation
publishing.
Need to decide on
whether to support
instrumentation
functionality in
Orchestrator.
GLB_EnableLogPublish
NA
Flag to enable log
publishing.
The Orchestrator is
Java based and uses
the same Log4J
configurations used
by OMS from
omsServerLog4j.xml
file. Hence this GV is
not carried forward.
NA
NA
None of the GVs
under this category
are relevant for
Orchestrator since
Orchestrator is an
integral part of OMS
now and uses the JMS
connection properties
used by OMS. Hence
these GVs are not
carried forward in
Orchestrator.
commonServices/flags
common
services/interfaces/jms/
events
NA
TIBCO® Fulfillment Order Management User's Guide
Global Variables | 355
Global Variable Name
Configuration Property (name
and propname in
ConfigValues_OMS.xml)
Description
Comments
NA
String to be prefixed All the jms
to each JMS
destination name
destination name.
properties in OMS
contains this prefix in
their value itself.
Since beginning, there
is no separate prefix
property. Hence this
GV is not carried
forward as a property
in Orchestrator.
common
services/messaging/
jms/
GLB_MessagingPrefix
commonServices/messaging/
jms/destinations
GLB_DiscoverEngineRequest NA
Need to decide on
whether to support
this functionality in
Orchestrator.
GLB_DiscoverEngineResponse NA
Need to decide on
whether to support
this functionality in
Orchestrator.
GLB_Exception
NA
Exception publish
topic.
The Orchestrator is
Java based and uses
the same Log4J
configurations used
by OMS from
omsServerLog4j.xml
file. Hence this GV is
not carried forward.
GLB_GetActiveConfigVariable NA
Request
Get active
The JMS topic
configuration variable specified by this GV
request topic.
is not relevant and
hence not carried
forward in
Orchestrator. It was
BE implementation
specific.
GLB_GetActiveConfigVariable NA
Response
Get active
The JMS topic
configuration variable specified by this GV
response topic.
is not relevant and
hence not carried
forward in
Orchestrator. It was
TIBCO® Fulfillment Order Management User's Guide
356 | Global Variables
Global Variable Name
Configuration Property (name
and propname in
ConfigValues_OMS.xml)
Description
Comments
BE implementation
specific.
GLB_Instrumentation
NA
Instrumentation
publish topic.
Need to decide on
whether to support
instrumentation
functionality in
Orchestrator.
GLB_Log
NA
Log publish topic.
The Orchestrator is
Java based and uses
the same Log4J
configurations used
by OMS from
omsServerLog4j.xml
file. Hence this GV is
not carried forward.
TIBCO® Fulfillment Order Management User's Guide
Global Variables | 357
Global Variables and Configurations
The following section lists the global variables in the OPE component and the configuration properties in
OMS.
Offer and Price Engine (OPE)
The following are the global variables in the OPE component:
Name
Description
Default Value
com.tibco.af.ope.jms.jndi.connectionfactory JNDI Connection factory JNDI
Name
GenericConnectionFactory
com.tibco.af.ope.jms.jndi.initialContextFactory JNDI Initial Context Factory
GenericConnectionFactory
com.tibco.af.ope.jms.jndi.url
tibjmsnaming://localhost:7222
Full JNDI URL for JMS Service
com.tibco.af.ope.jms.jndi.security.principal JNDI username
admin
com.tibco.af.ope.jms.jndi.security.credentials JNDI password
admin
com.tibco.af.ope.cacheType
true
OPE Cache Type
com.tibco.af.ope.cacheType.cache.max The maximum number of product 0
NoProductcached
models that can be cached
com.tibco.af.ope.cacheType.cache.max The minimum number of price
NoPriceCached
models that can be cached
0
com.tibco.af.ope.cacheType.cache.max The maximum number of discount 0
NoDiscountCached
models that can be cached
com.tibco.fom.oms.afi.productmodel. Product model purge topic
purge.topic
tibco.aff.ocv.events.products.purge
com.tibco.fom.oms.afi.productmodel. Product model publish topic
publish.topic
tibco.aff.ocv.events.products.publish
com.tibco.af.ope.opeService.queue Queue for receiving SOAP Over
JMS OPE Service requests
tibco.aff.ope.opeService
com.tibco.af.ope.flags.chkrelevantoludfs Validates UDFs attached to the
product that are defined as input
characteristics of the product
false
com.tibco.af.ope.flags.chkvalidoludfs Validates mandatory characteristics false
attached to the product model that
are found in the corresponding
product instance as UDFs in the
request
com.tibco.af.ope.flags.chkvalidlinkudfs Validates mandatory linking UDFs false
that are attached as UDFs to the
product in the order request
com.tibco.af.ope.flags.chkrecordtypevalid Checks if the RecordType is valid
false
com.tibco.af.ope.flags.setnorecordstatustoactive Sets no RecordStatus to active
false
com.tibco.af.ope.flags.validateudfdatatype Validates the data types for
orderline udfs
false
TIBCO® Fulfillment Order Management User's Guide
358 | Global Variables
Name
Description
Default Value
com.tibco.af.ope.flags.validateudfrange Validates the orderline UDFs are false
within the specified range specified
com.tibco.af.ope.flags.validateudfregex Validates that the orderline UDFs
have the values per the regex.
false
com.tibco.af.ope.flags.regexcurrency The regular expression for currency [0-9]*.?[0-9]*
com.tibco.af.ope.flags.regexdigits
The regular expression for digits
[0-9]*.?[0-9]*"
com.tibco.af.ope.flags.regexdate
The regular expression for date.
[0-3]?[0-9]/[0-1][0-9]/[1-2][0-9]{3}
com.tibco.af.ope.flags.regextime
The regular expression for time.
[0-2]?[0-9]:[0-5][0-9]
com.tibco.af.ope.flags.regexboolean The regular expression for boolean. TRUE|FALSE
com.tibco.af.ope.flags.udfignorelist The udfs in this property will not
be shown as incompatible if they
are in the same order:
EPMR_ACTION_PROVIDE
EPMR_ACTION_UPDATE
EPMR_ACTION_CEASE
EPMR_ACTION_WITHDRAW
COMPENSATE_PROVIDE
COMPENSATE_UPDATE
COMPENSATE_CEASE
MODIFICATION_IDENTIFYING_ATTR
com.tibco.af.ope.model.max.redelivery.delay The maximum delay in
milliseconds for the fetching the
product model.
10000
com.tibco.af.ope.model.min.idle.delay The model loading's minimum idle 10000
time in milliseconds.
Order Management System
The following are the configuration properties in OMS:
Name
Description
Default Value
com.tibco.aff.oms.jmx.rmiport
JMX RMI Port.
10099
com.tibco.af.oms.statusnotification.order Order Status Notification Queue.
.queue
tibco.aff.oms.statusNotification.ord
er.queue
com.tibco.af.oms.statusnotification.order Order Status Notification Queue
.queue.concurrentConsumersCount Concurrent Listener Count.
2
com.tibco.af.oms.statusnotification.order Order Line Status Notification
Line.queue
Queue.
tibco.aff.oms.statusNotification.ord
erLine.queue
com.tibco.af.oms.statusnotification.order Order Line Status Notification
1
Line.queue.concurrentConsumersCount Queue Concurrent Listener Count.
com.tibco.af.oms.statusnotification.plan. Plan Status Notification Queue.
queue
TIBCO® Fulfillment Order Management User's Guide
tibco.aff.oms.statusNotification.pla
n.queue
Global Variables | 359
Name
Description
Default Value
com.tibco.af.oms.statusnotification.plan. Plan Status Notification Queue
queue.concurrentConsumersCount Concurrent Listener Count.
1
com.tibco.af.oms.statusnotification.planI Plan Item Status Notification Queue. tibco.aff.oms.statusNotification.pla
tem.queue
nItem.queue
com.tibco.af.oms.statusnotification.planI Plan Item Status Notification Queue 6
tem.queue.concurrentConsumersCount Concurrent Listener Count.
com.tibco.af.oms.statusnotification.order Order Amendment Status
Amendment.queue
Notification Queue.
tibco.aff.oms.statusNotification.ord
erAmendment.queue
com.tibco.af.oms.statusnotification.order Order Amendment Status
Amendment.queue.concurrent
Notification Queue Concurrent
ConsumersCount
Listener Count.
1
com.tibco.af.oms.statusnotification.dead. Status Notification Dead Queue.
queue
tibco.aff.oms.statusNotification.dea
d.queue
com.tibco.af.oms.centrallog.queue
Central Log Queue.
tibco.aff.centrallog.queue
com.tibco.af.oms.centrallog.queue.
concurr entConsumersCount
Central Log Queue Concurrent
Listener Count.
1
com.tibco.af.oms.setplan.queue
Set Plan Queue.
tibco.aff.orchestrator.plan.oms.set
com.tibco.af.oms.setplan.queue.concurrent Set Plan Queue Concurrent Listener 3
ConsumersCount
Count.
com.tibco.af.oms.setplan.dead.queue Set Plan Dead Queue.
tibco.aff.orchestrator.plan.oms.set.
dead
com.tibco.af.oms.setplan.reply.queue Set Plan Response Queue.
tibco.aff.orchestrator.plan.oms.set.
reply
com.tibco.af.oms.setplanfragmentmodel.que Set Plan Fragment Model Queue.
ue
tibco.aff.oms.planfragmentmodel
com.tibco.af.oms.setplanfragmentmodel.que Set Plan Fragment Model Queue
ue.concurrentConsumersCount
Concurrent Listener Count.
1
com.tibco.af.oms.setplanfragmentmodel.dea Set Plan Fragment Model Dead
d.queue
Queue.
tibco.aff.oms.planfragmentmodel.dead
com.tibco.af.oms.setplanitem.queue Set Plan Item Queue.
tibco.aff.oms.setplanitem
com.tibco.af.oms.setplanitem.queue.concur Set Plan Item Queue Concurrent
rentConsumersCount
Listener Count.
1
com.tibco.af.oms.orderService.syncOrderSt Synchronous Order Submission
atusRecovery.concurrentConsumersCount Status Recovery Consumer Count.
1
com.tibco.af.oms.orderService.syncOrderSt Synchronous Order Submission
atusRecovery.queue
Status Recovery Queue.
tibco.aff.oms.syncorderstatusrecover
y
com.tibco.af.oms.setplanitem.dead.queue Set Plan Item Dead Queue.
tibco.aff.oms.setplanitem.dead
com.tibco.af.oms.ordersService.queue Queue for receiving SOAP Over JMS tibco.aff.oms.orderService
Order Service requests.
com.tibco.af.oms.webservice.soap.jms.conc Minimum number of concurrent
urrentConsumers
consumers for listener (default 1).
1
TIBCO® Fulfillment Order Management User's Guide
360 | Global Variables
Name
Description
Default Value
com.tibco.af.oms.webservice.soap.jms.maxC Maximum number of concurrent
oncurrentConsumers
consumers for listener (default 1).
5
com.tibco.af.oms.milestone.notify.request Milestone Notify Request Queue.
.queue
tibco.aff.oms.planItem.milestone.not
ify.request
com.tibco.af.oms.milestone.notify.request Milestone Notify Request Queue
.queue.concurrentConsumersCount Concurrent Listener Count.
3
com.tibco.af.oms.milestone.notify.request Milestone Notify Request Dead
.dead.queue
Queue.
tibco.aff.orchestrator.oms.planItem.
milestone.notify.request.dead
com.tibco.af.oms.milestone.release.reques Milestone Release Request Queue.
t.queue
tibco.aff.oms.planItem.milestone.rel
ease.request
com.tibco.af.oms.milestone.release.reques Milestone Release Request Queue
t.queue.concurrentConsumersCount Concurrent Listener Count.
3
com.tibco.af.oms.milestone.release.reques Milestone Release Request Dead
t.dead.queue
Queue.
tibco.aff.orchestrator.oms.planItem.
milestone.release.request.dead
com.tibco.af.oms.events.jeopardy.update.q Jeopardy Events Update Queue.
ueue
tibco.aff.oms.events.jeopardy.update
com.tibco.af.oms.events.jeopardy.update.q Jeopardy Events Update Queue
ueue.concurrentConsumersCount Concurrent Listener Count.
1
com.tibco.af.oms.events.jeopardy.update.d Jeopardy Events Update Dead
ead.queue
Queue.
com.tibco.aff.dead
com.tibco.af.dead.queue
com.tibco.aff.dead
AFF Dead Queue.
com.tibco.af.oms.router.destination. Purge Order Reply Queue for
beoPurgeOrder.reply.queue.
Orchestrator Concurrent Listener
concurrentConsumersCount
Count.
1
com.tibco.af.oms.plan.migrated.request Enrich Migrated Plan Request
Queue.
tibco.aff.oms.plan.migrated.request
com.tibco.af.oms.plan.migrated.response Enrich Migrated Plan Response
Queue.
tibco.aff.oms.plan.migrated.response
com.tibco.af.oms.migratedPlanTimeOut Enrich Migrated Plan Timeout.
30000
com.tibco.af.oms.jeoms.update.rule Update Jeopardy Configuration Rule tibco.aff.oms.jeoms.update.rule
Queue.
com.tibco.af.oms.statusmessage.max.redeli Maximum number of times the
veries
Status Message to be retried.
3
com.tibco.af.oms.statusmessage.redelivery Interval delay in millisecs between 3000
.delay
Status Message retries.
com.tibco.af.oms.statusmessage.max.redeli Maximum delay in millisecs For
very.delay
Status Message retries.
30000
com.tibco.af.oms.statusmessage.useExponen Use Exponential backoff For Status FALSE
tialBackOff
Message retries.
com.tibco.af.oms.statusmessage.exponentia Exponential backoff Multiplier For 2
lBackOffMultiplier
Status Message retries.
TIBCO® Fulfillment Order Management User's Guide
Global Variables | 361
Name
Description
Default Value
com.tibco.af.oms.statusmessage.logRetryAt Log retry attempt For Status
tempted
Message retries.
FALSE
com.tibco.af.oms.statusmessage.logStackTr Log retry failed stacktrace For Status FALSE
ace
Message retries.
com.tibco.af.oms.router.type
Router Type.
passthroughRouter
com.tibco.af.oms.router.destination.beoWi Withdraw Order Queue for
thdrawOrder
Orchestrator.
tibco.aff.orchestrator.order.withdra
w
com.tibco.af.oms.router.destination.beoSu Submit Order Queue for
bmitOrderReply
Orchestrator.
tibco.aff.orchestrator.order.submitR
esponse
com.tibco.af.oms.syncSubmitOrderRequestTi Request time out for synchronous
meout
order submission.
30000
com.tibco.af.oms.router.destination.beoSu Submit Order Queue for
bmitOrder
Orchestrator.
tibco.aff.orchestrator.order.submit
com.tibco.af.oms.router.destination.beoAm Amend Order Queue for
endOrder
Orchestrator.
tibco.aff.orchestrator.order.submit
com.tibco.af.oms.router.destination.beoCa Cancel Order Queue for
ncelOrder
Orchestrator.
tibco.aff.orchestrator.order.submit
com.tibco.af.oms.router.destination.beoRe Resume Order Queue for
sumeOrder
Orchestrator.
tibco.aff.orchestrator.order.activat
e
com.tibco.af.oms.router.destination.beoSu Suspend Order Queue for
spendOrder
Orchestrator.
tibco.aff.orchestrator.order.suspend
com.tibco.af.oms.router.destination. Purge Order Request Queue for
beoPurgeOrder
Orchestrator.
tibco.aff.orchestrator.data.order.de
lete.request
com.tibco.af.oms.router.destination. Purge Order Reply Queue for
beoPurgeOrder.reply
Orchestrator.
tibco.aff.orchestrator.data.order.de
lete.reply
com.tibco.af.oms.router.recoveryFileFolde Path to folder containing Router
rPath
Recovery Files.
../../routerRecoveryFileFolder
com.tibco.af.oms.router.type
filteringRouter
Router Type.
com.tibco.af.oms.router.destination.beoSu Submit Order Queue for
bmitOrderReply
Orchestrator.
tibco.aff.orchestrator.order.submitR
esponse
com.tibco.af.oms.syncSubmitOrderRequestTi Request time out for synchronous
meout
order submission.
30000
com.tibco.af.oms.router.filterCondition Xpath filter Condition.
/SubmitOrderRequest/orderRequest/hea
der/udf[name='Orchestrator']/value/text()
com.tibco.af.oms.router.destination.beoSu Submit Order Queue for
bmitOrder
Orchestrator.
tibco.aff.orchestrator.order.submit
com.tibco.af.oms.router.destination.ipcSu Submit Order Queue for IPC.
bmitOrder
tibco.aff.ipc.order.submit
com.tibco.af.oms.router.destination.beoWi Withdraw Order Queue for
thdrawOrder
Orchestrator.
tibco.aff.orchestrator.order.withdra
w
TIBCO® Fulfillment Order Management User's Guide
362 | Global Variables
Name
Description
Default Value
com.tibco.af.oms.router.destination.ipcWi Withdraw Order Queue for iPC.
thdrawOrder
tibco.aff.ipc.order.withdraw
com.tibco.af.oms.router.destination.ipcSu Submit Order Queue for
bmitOrderReply
Orchestrator.
tibco.aff.ipc.order.submitResponse
com.tibco.af.oms.router.destination.beoAm Amend Order Queue for
endOrder
Orchestrator.
tibco.aff.orchestrator.order.submit
com.tibco.af.oms.router.destination.ipcAm Amend Order Queue for IPC.
endOrder
tibco.aff.ipc.order.amend
com.tibco.af.oms.router.destination.beoCa Cancel Order Queue for
ncelOrder
Orchestrator.
tibco.aff.orchestrator.order.submit
com.tibco.af.oms.router.destination.ipcCa Cancel Order Queue for iPC.
ncelOrder
tibco.aff.ipc.order.submit
com.tibco.af.oms.router.destination.beoRe Resume Order Queue for
sumeOrder
Orchestrator.
tibco.aff.orchestrator.order.activat
e
com.tibco.af.oms.router.destination.ipcRe Resume Order Queue for iPC.
sumeOrder
tibco.aff.ipc.order.activate
com.tibco.af.oms.router.destination.beoSu Suspend Order Queue for
spendOrder
Orchestrator.
tibco.aff.orchestrator.order.suspend
com.tibco.af.oms.router.destination.ipcSu Suspend Order Queue for iPC.
spendOrder
tibco.aff.ipc.order.suspend
com.tibco.af.oms.router.recoveryFileFolde Path to folder containing Router
rPath
Recovery Files.
../../routerRecoveryFileFolder
com.tibco.af.oms.hibernate.dialect
org.hibernate.dialect.Oracle10gDiale
ct
com.tibco.af.oms.hibernate.cache.use_seco Hibernate Second Level Cache
nd_level_cache
Usage.
FALSE
com.tibco.af.oms.hibernate.cache.provider Hibernate Cache Provider Class.
_class
org.hibernate.cache.NoCacheProvider
com.tibco.af.oms.hibernate.transaction.fa Hibernate Transaction Factory Class. org.hibernate.transaction.JDBCTransa
ctory_class
ctionFactory
com.tibco.af.oms.hibernate.current_sessio Hibernate Session Context Class.
n_context_class
thread
com.tibco.af.oms.hibernate.jdbc.batch_siz Hibernate JDBC Batch size.
e
30
com.tibco.af.oms.hibernate.show_sql Hibernate Show SQL.
FALSE
com.tibco.af.oms.hibernate.default_catalo Hibernate Default Catalog.
g
aff_oms
com.tibco.af.oms.hibernate.default_archiv Hibernate Default Archive Catalog. aff_oms_archive
e_catalog
com.tibco.af.omsui.httpChannelType
com.tibco.af.omsui.http.port
TIBCO® Fulfillment Order Management User's Guide
8080
Global Variables | 363
Name
Description
Default Value
com.tibco.af.omsui.https.port
8443
com.tibco.af.omsui.enableRecordCountFetch Enable the Record count fetch for
TRUE
pagination. This will make the data
fetch slower and enable Last Page
option in pagination.
com.tibco.af.omsui.session-fixation-prote
ction
com.tibco.af.omsServer.proxyHost
Host address of the OMS server.
localhost
com.tibco.af.fpServer.enableConfiguration Enable FP configuration.
TRUE
com.tibco.af.fpServer.nodeName
Node name of the FP server.
knode
com.tibco.af.fpServer.proxyHost
Host address of the FP server.
localhost
com.tibco.af.fpServer.fpPlanFragmentType Owner for FP.
FP
com.tibco.af.omsServer.proxyPort
Port number of the OMS Server.
8080
com.tibco.af.fpServer.proxyPort
Port number of the FP Server.
8080
com.tibco.af.concurrencyControl.maxSessio
nPerUser
1
com.tibco.af.omsui.shortDateFormat OMS UI Short Date Format (Day
[dd].
Month[MM] and Year [yyyy])
com.tibco.af.omsui.longDateFormat OMS UI Long Date Time Format
(Day [dd].
Month [MM]
com.tibco.af.omsui.
longDateFormatTimeZone
OMS UI Long Date Time Format
(Day [dd].
Month [MM]
com.tibco.af.omsui.
longDateFormatTimeZoneMillis
OMS UI Long Date Time Format
(Day [dd].
Month [MM]
com.tibco.af.omsui.planItemExpression. OMS UI PlanItem Display Template {PlanItemID}
gridView
for Grid View. Possible template
variables are - PlanItemID,
PlanFragmentID, ProductID, Action
and Description; these template
variables are case sensitive and have
to be specified within curly braces
{}. Different template variables can
be combined with any type of
delimiter e.g.
{PlanFragmentID}|{PlanItemID}.
com.tibco.af.omsui.planItemExpression. OMS UI PlanItem Display Template {Description}
ganttView
for Gantt View. Possible template
variables are - PlanItemID,
PlanFragmentID,ProductID, Action
and Description; these template
variables are case sensitive and have
to be specified within curly braces
{}. Different template variables can
be combined with any type of
TIBCO® Fulfillment Order Management User's Guide
364 | Global Variables
Name
Description
Default Value
delimiter e.g.
{PlanFragmentID}|{PlanItemID}.
com.tibco.af.omsui.planItemExpression. OMS UI PlanItem Display Template {Description}|{PlanItemID}
dependencyView
for Dependency View. Possible
template variables are - PlanItemID,
PlanFragmentID, ProductID, Action
and Description; these template
variables are case sensitive and have
to be specified within curly braces
{}. Different template variables can
be combined with any type of
delimiter e.g.
{PlanFragmentID}|{PlanItemID}"
name="PlanItem Template for
Dependency View.
com.tibco.af.purge.threads.count
Purge Thread Count.
4
com.tibco.aff.PublishInventoryNotifications PublishInventoryNotifications.
FALSE
value
Product model receiver queue.
com.tibco.fom.oms.afi.productmodel.receiv
er.queue
tibco.aff.catalog.product.request
com.tibco.fom.oms.afi.productmodel.receiv Product model receiver count.
er.count
3
com.tibco.fom.oms.afi.productmodel.publis Product model publish topic.
h.topic
tibco.aff.ocv.events.products.publis
h
com.tibco.fom.oms.afi.customermodel.recei Customer model receiver queue.
ver.queue
tibco.aff.catalog.customer.request
com.tibco.fom.oms.afi.customermodel.recei Customer model receiver count.
ver.count
3
com.tibco.fom.oms.afi.segmentmodel.receiv Segment model receiver queue.
er.queue
tibco.aff.catalog.segment.request
com.tibco.fom.oms.afi.segmentmodel.receiv Segment model receiver count.
er.count
3
com.tibco.fom.oms.afi.planfragmentmodel.r PlanFragment model receiver queue. tibco.aff.catalog.planfragment.reque
eceiver.queue
st
com.tibco.fom.oms.afi.planfragmentmodel.r PlanFragment model receiver count. 3
eceiver.count
com.tibco.fom.oms.afi.planfragmentmodel.p ProcessComponent model publish
ublish.topic
topic.
tibco.aff.orchestrator.model.process
Component.pub
com.tibco.fom.oms.afi.actionmodel.receive Action model receiver queue.
r.queue
tibco.aff.catalog.action.request
com.tibco.fom.oms.afi.actionmodel.receive Action model receiver count.
r.count
3
com.tibco.fom.oms.afi.actionmodel.publish Action model publish topic.
.topic
tibco.aff.ocv.events.actions.publish
TIBCO® Fulfillment Order Management User's Guide
Global Variables | 365
Name
Description
Default Value
com.tibco.fom.oms.afi.pcsmodel.event.requ Product customer segment model
est.queue
invocation event request receiver
queue.
tibco.aff.catalog.events.request
com.tibco.fom.oms.afi.pcsmodel.event.rece Product customer segment model
iver.count
invocation event request receiver
count.
1
com.tibco.fom.oms.afi.pfmodel.event.reque Plan fragment model invocation
st.queue
event request receiver queue.
tibco.aff.orchestrator.startup.event
.request
com.tibco.fom.oms.afi.pfmodel.event.reque Plan fragment model invocation
st.receiver.count
event request receiver count.
1
com.tibco.fom.oms.afi.fcintegration.host Server host.
localhost
com.tibco.fom.oms.afi.fcintegration.port Server port.
8800
com.tibco.fom.oms.afi.fcintegration.enter Enterprise name.
prise
AC
com.tibco.fom.oms.afi.fcintegration.usern Username.
ame
admin
com.tibco.fom.oms.afi.fcintegration.passw Password.
ord
admin
com.tibco.fom.oms.afi.fcintegration.workf Workflow invocation response
low.response.success.code
success code.
SVC-11045
com.tibco.fom.oms.afi.fcintegration.workf Workflow invocation response
low.response.success.message
success message.
Workflow initiated successfully.
com.tibco.fom.oms.afi.fcintegration.produ Master catalog name.
ct.mctname
PRODUCT
com.tibco.fom.oms.afi.fcintegration.produ Product record ID.
ct.id
BU_000001
com.tibco.fom.oms.afi.fcintegration.produ Product record ID extension.
ct.idext
com.tibco.fom.oms.afi.fcintegration.custo Master catalog name.
mer.mctname
PARTY
com.tibco.fom.oms.afi.fcintegration.custo Customer record ID.
mer.id
68000001
com.tibco.fom.oms.afi.fcintegration.custo Customer record ID extension.
mer.idext
com.tibco.fom.oms.afi.fcintegration.segme Master catalog name.
nt.mctname
SEGMENT
com.tibco.fom.oms.afi.fcintegration.segme Segment record ID.
nt.id
PB_000001
com.tibco.fom.oms.afi.fcintegration.segme Segment record ID extension.
nt.idext
TIBCO® Fulfillment Order Management User's Guide
366 | Global Variables
Name
Description
Default Value
com.tibco.fom.oms.afi.fcintegration.planf Master catalog name.
ragment.mctname
PLANFRAGMENT
com.tibco.fom.oms.afi.fcintegration.planf PlanFragment record ID.
ragment.id
PF_00001
com.tibco.fom.oms.afi.fcintegration.planf PlanFragment record ID extension.
ragment.idext
com.tibco.fom.oms.afi.fcintegration.actio Master catalog name.
n.mctname
ACTION
com.tibco.fom.oms.afi.fcintegration.actio Action record ID.
n.id
Provide
com.tibco.fom.oms.afi.fcintegration.actio Action record ID extension.
n.idext
com.tibco.fom.oms.afi.offline.common.poll Polling interval in seconds.
ing.interval
60
com.tibco.fom.oms.afi.offline.common.cata Catalog request interval in
logrequest.interval
milliseconds.
30
com.tibco.fom.oms.afi.offline.product.use Use offline product.
FALSE
com.tibco.fom.oms.afi.offline.product.mas Offline product catalog master
ter.directory
directory.
/usr/tibco/product/master
com.tibco.fom.oms.afi.offline.product.mas Offline product catalog import
ter.importsuccess.directory
success master directory.
/usr/tibco/product-success/master
com.tibco.fom.oms.afi.offline.product.mas Offline product catalog import
ter.importfailure.directory
failure master directory.
/usr/tibco/product-failure/master
com.tibco.fom.oms.afi.offline.product.dir Offline product catalog directory.
ectory
/usr/tibco/product
com.tibco.fom.oms.afi.offline.product.imp Offline product catalog import
ortsuccess.directory
success directory.
/usr/tibco/product-success
com.tibco.fom.oms.afi.offline.product.imp Offline product catalog import
ortfailure.directory
failure directory.
/usr/tibco/product-failure
com.tibco.fom.oms.afi.offline.customer.us Use offline customer.
e
FALSE
com.tibco.fom.oms.afi.offline.customer.ma Offline customer catalog master
ster.directory
directory.
/usr/tibco/customer/master
com.tibco.fom.oms.afi.offline.customer.ma Offline customer catalog import
ster.importsuccess.directory
success master directory.
/usr/tibco/customer-success/master
com.tibco.fom.oms.afi.offline.customer.ma Offline customer catalog import
ster.importfailure.directory
failure master directory.
/usr/tibco/customer-failure/master
com.tibco.fom.oms.afi.offline.customer.di Offline customer catalog directory.
rectory
/usr/tibco/customer
com.tibco.fom.oms.afi.offline.customer.im Offline customer catalog import
portsuccess.directory
success directory.
/usr/tibco/customer-success
TIBCO® Fulfillment Order Management User's Guide
Global Variables | 367
Name
Description
Default Value
com.tibco.fom.oms.afi.offline.customer.im Offline customer catalog import
portfailure.directory
failure directory.
/usr/tibco/customer-failure
com.tibco.fom.oms.afi.offline.segment.use Use offline segment.
FALSE
com.tibco.fom.oms.afi.offline.segment.mas Offline segment catalog master
ter.directory
directory.
/usr/tibco/segment/master
com.tibco.fom.oms.afi.offline.segment.mas Offline segment catalog import
ter.importsuccess.directory
success master directory.
/usr/tibco/segment-success/master
com.tibco.fom.oms.afi.offline.segment.mas Offline segment catalog import
ter.importfailure.directory
failure master directory.
/usr/tibco/segment-failure/master
com.tibco.fom.oms.afi.offline.segment.dir Offline segment catalog directory
ectory
/usr/tibco/segment
com.tibco.fom.oms.afi.offline.segment.imp Offline segment catalog import
ortsuccess.directory
success directory.
/usr/tibco/segment-success
com.tibco.fom.oms.afi.offline.segment.imp Offline segment catalog import
ortfailure.directory
failure directory.
/usr/tibco/segment-failure
com.tibco.fom.oms.afi.offline.planfragmen Use offline planfragment.
t.use
FALSE
com.tibco.fom.oms.afi.offline.planfragmen Offline planfragment catalog master /usr/tibco/planfragment/master
t.master.directory
directory.
com.tibco.fom.oms.afi.offline.planfragmen Offline planfragment catalog import /usr/tibco/planfragment-success/mast
t.master.importsuccess.directory
success master directory.
er
com.tibco.fom.oms.afi.offline.planfragmen Offline planfragment catalog import /usr/tibco/planfragment-failure/mast
t.master.importfailure.directory
failure master directory.
er
com.tibco.fom.oms.afi.offline.planfragmen Offline planfragment catalog
t.directory
directory.
/usr/tibco/planfragment
com.tibco.fom.oms.afi.offline.planfragmen Offline planfragment catalog import /usr/tibco/planfragment-success
t.importsuccess.directory
success directory.
com.tibco.fom.oms.afi.offline.planfragmen Offline planfragment catalog import /usr/tibco/planfragment-failure
t.importfailure.directory
failure directory.
com.tibco.fom.oms.afi.offline.action.use Use offline action.
FALSE
com.tibco.fom.oms.afi.offline.action.mast Offline action catalog master
er.directory
directory.
/usr/tibco/action/master
com.tibco.fom.oms.afi.offline.action.mast Offline action catalog import success /usr/tibco/action-success/master
er.importsuccess.directory
master directory.
com.tibco.fom.oms.afi.offline.action.mast Offline action catalog import failure /usr/tibco/action-failure/master
er.importfailure.directory
master directory.
com.tibco.fom.oms.afi.offline.action.dire Offline action catalog directory.
ctory
/usr/tibco/action
com.tibco.fom.oms.afi.offline.action.impo Offline action catalog import success /usr/tibco/action-success
rtsuccess.directory
directory.
TIBCO® Fulfillment Order Management User's Guide
368 | Global Variables
Name
Description
Default Value
com.tibco.fom.oms.afi.offline.action.impo Offline action catalog import failure /usr/tibco/action-failure
rtfailure.directory
directory.
com.tibco.fom.oms.afi.orch.opdrequest.rec OPDRequest from Orchestrator
eiver.queue
receiver queue.
tibco.aff.orchestrator.provider.orde
r.opd.request
com.tibco.fom.oms.afi.orch.opdrequest.rec OPDRequest from Orchestrator
eiver.count
receiver count.
3
com.tibco.fom.oms.afi.aopd.newplanrequest ExecutionPlanNewRequest to AOPD tibco.aff.ocv.events.plan.new.reques
.sender.queue
sender queue.
t
com.tibco.fom.oms.afi.aopd.amendplanreque ExecutionPlanAmendRequest to
st.sender.queue
AOPD sender queue.
tibco.aff.ocv.events.plan.amend.requ
est
com.tibco.fom.oms.afi.aopd.newplanrespons ExecutionPlanNewResponse from
e.receiver.queue
AOPD receiver queue.
tibco.aff.ocv.events.newplan.reply
com.tibco.fom.oms.afi.aopd.newplanrespons ExecutionPlanNewResponse from
e.receiver.count
AOPD receiver count.
3
com.tibco.fom.oms.afi.aopd.amendplanrespo ExecutionPlanAmendResponse from tibco.aff.ocv.events.amendplan.reply
nse.receiver.queue
AOPD receiver queue.
com.tibco.fom.oms.afi.aopd.amendplanrespo ExecutionPlanAmendResponse from 3
nse.receiver.count
AOPD receiver count.
com.tibco.fom.oms.afi.orch.opdresponse.se OPDResponse to Orchestrator
nder.queue
sender queue.
tibco.aff.orchestrator.provider.orde
r.opd.reply
com.tibco.fom.oms.afi.aopd.merge.inventor Merge inventory in AOPD request. FALSE
y
com.tibco.fom.oms.tds.getorderrequest.rec GetOrderRequest receiver queue.
eiver.queue
tibco.aff.tds.order.read.request
com.tibco.fom.oms.tds.getorderrequest.rec GetOrderRequest receiver count.
eiver.count
3
com.tibco.fom.oms.tds.getorderrequest.rec GetOrderRequest receiver dead
eiver.deadqueue
queue.
tibco.aff.oms.tds.order.read.request
.dead
com.tibco.fom.oms.tds.getorderresponse.se GetOrderResponse sender queue.
nder.queue
tibco.aff.tds.order.reply
com.tibco.fom.oms.tds.getplanrequest.rece GetPlan/GetPlanItem Request
iver.queue
receiver queue.
tibco.aff.tds.plan.read.request
com.tibco.fom.oms.tds.getplanrequest.rece GetPlan/GetPlanItem Request
iver.count
receiver count.
3
com.tibco.fom.oms.tds.getplanrequest.rece GetPlan/GetPlanItem Request
iver.deadqueue
receiver dead queue.
tibco.aff.oms.tds.plan.read.request.
dead
com.tibco.fom.oms.tds.getplanresponse.sen GetPlan/GetPlanItem Response
der.queue
sender queue.
tibco.aff.tds.plan.reply
com.tibco.fom.oms.tds.setplanrequest.rece SetPlan/SetPlanItem Request
iver.queue
receiver queue.
tibco.aff.tds.plan.request
TIBCO® Fulfillment Order Management User's Guide
Global Variables | 369
Name
Description
Default Value
com.tibco.fom.oms.tds.setplanrequest.rece SetPlan/SetPlanItem Request
iver.count
receiver count.
3
com.tibco.fom.oms.tds.setplanrequest.rece SetPlan/SetPlanItem Request
iver.deadqueue
receiver dead queue.
tibco.aff.oms.tds.plan.request.dead
com.tibco.fom.oms.tds.setplanresponse.sen SetPlan/SetPlanItem Response
der.queue
sender queue.
tibco.aff.tds.plan.reply
com.tibco.fom.oms.tds.enable.unique.udfna Flag to enable unique UDF names to TRUE
me
permit updates on UDF values.
com.tibco.afs.destination.listen.timeout Wait Timeout for listening to
response from JMS Destination.
60000
tibco.aff.ocv.events.offer.validate.reque Queue where request for validating tibco.aff.ocv.events.offer.validate.
st
the offer is posted.
request
com.tibco.af.oms.jms.jndi.ConnectionFacto JNDI Connection factory JNDI
ry
Name.
GenericConnectionFactory
com.tibco.af.oms.jms.jndi.initialContextF JNDI Initial Context Factory.
actory
com.tibco.tibjms.naming.TibjmsInitia
lContextFactory
com.tibco.af.oms.jms.jndi.url
tibjmsnaming://localhost:7222
JNDI URL for JMS Service.
com.tibco.af.oms.jms.jndi.security.princi JNDI Username.
pal
admin
com.tibco.af.oms.jms.jndi.security.creden JNDI Password.
tials
admin
com.tibco.af.oms.jms.jndi.cf.beo
BE Orchestrator Queue Connection QueueConnectionFactory
factory JNDI Name.
com.tibco.af.oms.jms.cf.beo.deliverymode BE Orchestrator JMS Delivery Mode. 1
com.tibco.af.oms.jms.cf.beo.qosEnabled BE Orchestrator JMS QoS Enabled? FALSE
com.tibco.af.oms.jms.jndi.cf.ipc
IPC Queue Connection factory JNDI GenericConnectionFactory
Name.
com.tibco.af.oms.jms.cf.ipc.deliverymode IPC JMS Delivery Mode.
1
com.tibco.af.oms.jms.cf.ipc.qosEnabled IPC JMS QoS Enabled.
FALSE
com.tibco.af.oms.jms. jndi.cf.
OPE Queue Connection factory JNDI QueueConnection Factory
Name
ope
com.tibco.af.oms.jms.cf.ope.
OPE JMS Delivery Mode.
1
OPE JMS JMS QoS Enabled.
TRUE
deliverymode
com.tibco.af.oms.jms.cf.OPE.
qosEnabled
com.tibco.af.oms.pooledDataSource.driverC Pooled Data Source Driver Class
lassName
Name.
oracle.jdbc.driver.OracleDriver
TIBCO® Fulfillment Order Management User's Guide
370 | Global Variables
Name
Description
Default Value
com.tibco.af.oms.pooledDataSource.host Pooled Data Source Host.
localhost
com.tibco.af.oms.pooledDataSource.port Pooled Data Source Port.
1521
com.tibco.af.oms.pooledDataSource.databas Pooled Data Source Database.
e
orcl
com.tibco.af.oms.pooledDataSource.usernam Pooled Data Source Username.
e
aff_oms
com.tibco.af.oms.pooledDataSource.passwor Pooled Data Source Password.
d
aff_oms
com.tibco.af.oms.pooledDataSource.url Pooled Data Source URL.
jdbc:oracle:thin:@//${com.tibco.af.o
ms.pooledDataSource.host}:${com.
tibco.af.oms.pooledDataSource.
port}/${com.tibco.af.oms.
pooledDataSource.database}
com.tibco.af.oms.pooledDataSource.initial Pooled Data Source Initialize Size.
izeSize
2
com.tibco.af.oms.pooledDataSource.maxIdle Pooled Data Source Max Idle.
8
com.tibco.af.oms.pooledDataSource.maxActi Pooled Data Source Max Active.
ve
12
com.tibco.af.oms.pooledDataSource.maxWait Pooled Data Source Max Wait.
10000
com.tibco.af.oms.pooledDataSource.validat Pooled Data Source Validation
ionQuery
Query.
select 1 from dual
com.tibco.af.oms.pooledDataSource.testOnB Pooled Data Source Test OnBorrow. FALSE
orrow
com.tibco.af.oms.pooledDataSource.testWhi Pooled Data Source Test WhileIdle. TRUE
leIdle
com.tibco.af.oms.pooledDataSource.timeBet Pooled Data Source Eviction
weenEvictionRunsMillis
Interval.
1200000
com.tibco.af.oms.pooledDataSource.minEvic Pooled Data Source Minimum
tableIdleTimeMillis
Evictable Idle Time.
1800000
com.tibco.af.oms.pooledDataSource.numTest Pooled Data Source Tests Per
sPerEvictionRun
Eviction Run.
5
com.tibco.af.oms.pooledDataSource.default Pooled Data Source Default
AutoCommit
AutoCommit.
FALSE
com.tibco.af.oms.pooledArchiveDataSource. Pooled Data Source Driver Class
driverClassName
Name.
oracle.jdbc.driver.OracleDriver
com.tibco.af.oms.pooledArchiveDataSource. Pooled Data Source Host.
host
localhost
com.tibco.af.oms.pooledArchiveDataSource. Pooled Data Source Port.
port
1521
TIBCO® Fulfillment Order Management User's Guide
Global Variables | 371
Name
Description
Default Value
com.tibco.af.oms.pooledArchiveDataSource. Pooled Data Source Database.
database
orcl
com.tibco.af.oms.pooledArchiveDataSource. Pooled Data Source Username.
username
aff_oms_archive
com.tibco.af.oms.pooledArchiveDataSource. Pooled Data Source Password.
password
aff_oms_archive
com.tibco.af.oms.pooledArchiveDataSource. Pooled Data Source URL.
url
jdbc:oracle:thin:@//${com.tibco.af.o
ms.pooledArchiveDataSource.host}:
${com.tibco.af.oms.
pooledArchiveDataSource.port}/
${com.tibco.af.oms.
pooledArchiveDataSource.database}
com.tibco.af.oms.pooledArchiveDataSource. Pooled Data Source Initialize Size.
initializeSize
2
com.tibco.af.oms.pooledArchiveDataSource. Pooled Data Source Max Idle.
maxIdle
8
com.tibco.af.oms.pooledArchiveDataSource. Pooled Data Source Max Active.
maxActive
12
com.tibco.af.oms.pooledArchiveDataSource. Pooled Data Source Max Wait.
maxWait
10000
com.tibco.af.oms.pooledArchiveDataSource. Pooled Data Source Validation
validationQuery
Query.
select 1 from dual
com.tibco.af.oms.pooledArchiveDataSource. Pooled Data Source Test OnBorrow. FALSE
testOnBorrow
com.tibco.af.oms.pooledArchiveDataSource. Pooled Data Source Test WhileIdle. TRUE
testWhileIdle
com.tibco.af.oms.pooledArchiveDataSource. Pooled Data Source Eviction
timeBetweenEvictionRunsMillis
Interval.
1200000
com.tibco.af.oms.pooledArchiveDataSource. Pooled Data Source Minimum
minEvictableIdleTimeMillis
Evictable Idle Time.
1800000
com.tibco.af.oms.pooledArchiveDataSource. Pooled Data Source Tests Per
numTestsPerEvictionRun
Eviction Run.
5
com.tibco.af.oms.pooledArchiveDataSource. Pooled Data Source Default
defaultAutoCommit
AutoCommit.
FALSE
com.tibco.af.oms.security.authProvider Default Authentication Provider.
defaultAuthenticationProvider
com.tibco.af.oms.security.authProvider Ldap Authentication Provider.
ldapAuthenticationProvider
com.tibco.af.oms.security.authProvider.ld LDAP Server URL.
ap.server.url
ldap://localhost:389/dc=oms
com.tibco.af.oms.security.authProvider.ld LDAP User Manager ID.
ap.server.userDn
uid=admin
TIBCO® Fulfillment Order Management User's Guide
372 | Global Variables
Name
Description
Default Value
com.tibco.af.oms.security.authProvider.ld LDAP User Manager Password.
ap.server.password
password
com.tibco.af.oms.security.authProvider.ld User SearchBase.
ap.user.searchBase
ou=users
com.tibco.af.oms.security.authProvider.ld User Search Filter.
ap.user.userSearchFilter
(uid={0})
com.tibco.af.oms.security.authProvider.ld Group Search Base.
ap.role.groupSearchBase
ou=Groups
com.tibco.af.oms.security.authProvider.ld Group Role Attribute.
ap.role.groupRoleAttribute
cn
com.tibco.af.oms.security.authProvider.ld Group Search Filter.
ap.role.groupSearchFilter
uniqueMember={0}
com.tibco.af.oms.security.authProvider.ld Seach Sub Tree.
ap.role.searchSubTree
FALSE
com.tibco.af.oms.security.authProvider.ld convert values To UpperCase.
ap.role.convertToUpperCase
TRUE
com.tibco.af.oms.OCVEnabled
Enable Offer and Price Engine
FALSE
com.tibco.af.oms.OCVTimeOut
Offer and Price EngineTimeout.
60000
com.tibco.af.oms.ocv.request
Offer and Price Engine Request
Queue.
tibco.aff.ocv.events.offer.validate.
request
com.tibco.af.oms.ocv.response
Offer and Price Engine Response
Queue. Specify a different queue
name for OMS than other OPE
clients.
tibco.aff.ocv.events.offer.validate.
reply.oms
com.tibco.af.oms.OCVExceptionLoggingEnabl Enable or disable logging of
TRUE
ed
exception stack trace in OMS when
Offer and Price Engine fails.
com.tibco.af.oms.webservice.security.user Enable User Name token based
NameTokenBased
Security.
TRUE
com.tibco.af.oms.webservice.schema.valida Enable Schema validation.
tion
TRUE
com.tibco.af.oms.webservice.idempotency Enable Submit Order Web Service
Idempotency.
TRUE
com.tibco.af.oms.webservice.httpChannelTy HTTP Channel type.
pe
com.tibco.af.oms.http.port
8080
com.tibco.af.oms.https.port
8443
com.tibco.af.oms.webservice.useExternalBu Use external business transactionId FALSE
sinessTransactionId
as business transaction id within
OMS.
TIBCO® Fulfillment Order Management User's Guide
Global Variables | 373
Name
Description
Default Value
com.tibco.af.oms.updateToken.timeout Time out value in millisecond for
order lock.
150000
com.tibco.af.oms.none.validityWindow Nonce validity time in Milliseconds. 1000
com.tibco.af.oms.persistenceDelay
Delay to be introduced before
persisting order objects.
0
com.tibco.af.oms.orderValidationDelay Delay to be introduced before
validating orders.
0
com.tibco.af.oms.summaryDataCollectionMet Order Summary collection on every onStatusChange
hod
order status change.
com.tibco.af.oms.summaryDataCollectionMet Order Summary collection on
hod
scheduled interval.
scheduled
com.tibco.af.oms.summaryDataCollection.sc schedule interaval for order
heduled.cronExpress
summary data collection.
00***?
TIBCO® Fulfillment Order Management User's Guide
Glossary
AOPD
Automatic Order Plan Development (AOPD) is a component that generates execution plan based on product
model and submitted order(s).
Accessed through a JMS event interface
Cache
Cache saves order data in a persistent data store, as well as stores transient order data throughout the order
lifecycle. This component serves order and plan data to client Process Components when requested, and
updates plan data.
Accessed through a JMS event interface.
Feasibility Provider
Feasibility Provider (FP) is a component, which analyzes the order to determine if it can be fulfilled. Feasibility
checking is an optional step in the order lifecycle and it may involve validating the order containing the
required products, physical network capacity checking, or inventory stock level check. The Feasibility Provider
is a customer-implemented component because feasibility checking is highly customized to the requirements
of a customer.
Accessed through a JMS event interface.
Product Catalog
The Product Catalog component stores the product data model which details relationships between products.
It also links products to the associated fulfillment Process Components. The Fulfillment Order Management
AOPD system accesses the Product Catalog through JMS. The Plan Fragment Model definitions repositories
describing the Process Components are contained within the Product Catalog
Order
An order is a set of items that a customer requests to be fulfilled. Orders consist of a series of order lines, with
each line corresponding to a requested product. Order lines are an abstraction of the work that will be done
as part of the plan, with order lines broadly mapping onto plan items
Plan
A plan is a representation of the tasks to be completed to reach the Fulfillment goal.
Plan Item
Plan item is a set of work that must be performed to fulfill an order. Like an order consists of order lines, a
plan consists of plan items.
Plan Fragment
A plan fragment is an abstraction of a Process Component that contains configuration information that
Orchestrator requires in order to handle errors and SLA notifications. Plan fragments are optional.
Product Affinity
Product Affinity allows different plan fragment types to be grouped together on the same order. For instance,
when two plan items in an execution plan have an Affinity to each other, these two items are grouped together
and are executed as a single task during provisioning. Product Affinity is specified in the product catalog.
TIBCO® Fulfillment Order Management User's Guide
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement