tibco fulfillment order management user's guide · • tibco fulfillment order management...

TIBCO® Fulfillment OrderManagement User's GuideSoftware Release 3.0.0July 2015

Important Information

SOME TIBCO SOFTWARE EMBEDS OR BUNDLES OTHER TIBCO SOFTWARE. USE OF SUCH EMBEDDEDOR BUNDLED TIBCO SOFTWARE IS SOLELY TO ENABLE THE FUNCTIONALITY (OR PROVIDE LIMITEDADD-ON FUNCTIONALITY) OF THE LICENSED TIBCO SOFTWARE. THE EMBEDDED OR BUNDLEDSOFTWARE IS NOT LICENSED TO BE USED OR ACCESSED BY ANY OTHER TIBCO SOFTWARE OR FORANY OTHER PURPOSE.

USE OF TIBCO SOFTWARE AND THIS DOCUMENT IS SUBJECT TO THE TERMS AND CONDITIONS OF ALICENSE AGREEMENT FOUND IN EITHER A SEPARATELY EXECUTED SOFTWARE LICENSE AGREEMENT,OR, IF THERE IS NO SUCH SEPARATE AGREEMENT, THE CLICKWRAP END USER LICENSE AGREEMENTWHICH IS DISPLAYED DURING DOWNLOAD OR INSTALLATION OF THE SOFTWARE (AND WHICH ISDUPLICATED IN LICENSE.PDF) OR IF THERE IS NO SUCH SOFTWARE LICENSE AGREEMENT ORCLICKWRAP END USER LICENSE AGREEMENT, THE LICENSE(S) LOCATED IN THE “LICENSE” FILE(S) OFTHE SOFTWARE. USE OF THIS DOCUMENT IS SUBJECT TO THOSE TERMS AND CONDITIONS, AND YOURUSE HEREOF SHALL CONSTITUTE ACCEPTANCE OF AND AN AGREEMENT TO BE BOUND BY THE SAME.

This document contains confidential information that is subject to U.S. and international copyright laws and treaties.No part of this document may be reproduced in any form without the written authorization of TIBCO SoftwareInc.

TIBCO, 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. inthe United States and/or other countries.

EJB, Java EE, J2EE, and all Java-based trademarks and logos are trademarks or registered trademarks of SunMicrosystems, Inc. in the U.S. and other countries.

All other product and company names and marks mentioned in this document are the property of their respectiveowners and are mentioned for identification purposes only.

THIS SOFTWARE MAY BE AVAILABLE ON MULTIPLE OPERATING SYSTEMS. HOWEVER, NOT ALLOPERATING SYSTEM PLATFORMS FOR A SPECIFIC SOFTWARE VERSION ARE RELEASED AT THE SAMETIME. SEE THE README FILE FOR THE AVAILABILITY OF THIS SOFTWARE VERSION ON A SPECIFICOPERATING SYSTEM PLATFORM.

THIS DOCUMENT IS PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS ORIMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY,FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT.

THIS DOCUMENT COULD INCLUDE TECHNICAL INACCURACIES OR TYPOGRAPHICAL ERRORS. CHANGESARE PERIODICALLYADDED TO THE INFORMATION HEREIN; THESE CHANGES WILL BE INCORPORATEDIN NEW EDITIONS OF THIS DOCUMENT. TIBCO SOFTWARE INC. MAY MAKE IMPROVEMENTS AND/ORCHANGES IN THE PRODUCT(S) AND/OR THE PROGRAM(S) DESCRIBED IN THIS DOCUMENT AT ANYTIME.

THE CONTENTS OF THIS DOCUMENT MAY BE MODIFIED AND/OR QUALIFIED, DIRECTLY OR INDIRECTLY,BY OTHER DOCUMENTATION WHICH ACCOMPANIES THIS SOFTWARE, INCLUDING BUT NOT LIMITEDTO ANY RELEASE NOTES AND "READ ME" FILES.

Copyright © 2010-2015 TIBCO Software Inc. ALL RIGHTS RESERVED.

TIBCO Software Inc. Confidential Information.

TIBCO® Fulfillment Order Management User's Guide

Contents

Preface................................................................................................11Related Documentation..........................................................................................................12

Typographical Conventions....................................................................................................13

Connecting with TIBCO Resources........................................................................................14

Chapter 1 Orchestrator....................................................................15Architecture............................................................................................................................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


TOC | 5

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............................71Overview................................................................................................................................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................................127Searching 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


6 | TOC

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...................................145Jeopardy Management System............................................................................................146

Jeopardy Management..............................................................................................146

Chapter 5 Router............................................................................153

Chapter 6 Internal Error Handler..................................................155Internal 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............................................165State Machine Pagination Sequence Diagram.....................................................................166

State Machine Pagination Flow Diagram.............................................................................167

Chapter 8 Order Capture System Overview................................169Order 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


TOC | 7

Order Capture System Error Codes and Messages.............................................................177

Search Syntax......................................................................................................................179

Chapter 9 Offer and Price Engine................................................181Offer 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........211Navigation............................................................................................................................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


8 | TOC

Chapter 11 Data Access Interfaces..............................................275Get 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...299Process 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..................................................321Plan Item..............................................................................................................................322

ResultStatus.........................................................................................................................324

Message...............................................................................................................................325

Order Request......................................................................................................................326

Appendix B Samples.....................................................................327


TOC | 9

Sample Order XML...............................................................................................................328

Sample Plan Item XML.........................................................................................................329

Sample XPATHs...................................................................................................................330

Appendix C Global Variables........................................................331AOPD Global Variables........................................................................................................332

Orchestrator Global Variables..............................................................................................336

Global Variables and Configurations....................................................................................357

Glossary..............................................................................................................375


10 | TOC

Preface

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


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 installationand 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. Itprovides the details of the User and Administrator tasks.


12 | Preface

Typographical Conventions

The following typographical conventions are used in this manual:

Table 1: General Typographical Conventions

UseConvention

Many TIBCO products are installed within the same home directory. Thisdirectory is referenced in documentation as TIBCO_HOME. The value of

TIBCO_HOME

TIBCO_HOME depends on the operating system. For example, on Unix systemsthe default value is $HOME/tibco.

TIBCO Fulfillment Order Management installs into a directory insideENV_HOME. This directory is referenced in documentation as AF_HOME. The

AF_HOME

value of AF_HOME depends on the operating system. For example, on Unixsystems the default value is $TIBCO_HOME/af/3.0.

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

code font

Use MyCommand to start the foo process.

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

• In procedures, to indicate what a user types. For example: Type admin.• In large code samples, to indicate the parts of the sample that are of particular

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

example, if no parameter is specified, MyCommand is enabled:

MyCommand [enable | disable]

Italic font is used in the following ways:italic font

• To indicate a document title. For example: See TIBCO BusinessWorks Concepts.• To introduce new terms For example: A portal page may contain several

portlets. Portlets are mini-applications that run in a portal.• To indicate a variable in a command or code syntax that you must replace.

For example: MyCommand pathname

The note icon indicates information that is of special interest or importance, forexample, an additional action required only in certain circumstances.

The tip icon indicates an idea that could be useful, for example, a way to applythe 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.


Preface | 13

Connecting with TIBCO Resources

How to Join TIBCOmmunity

TIBCOmmunity is an online destination for TIBCO customers, partners, and resident experts—a place toshare 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 asfollows:• 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.


14 | Preface

http://www.tibcommunity.com

https://docs.tibco.com

http://www.tibco.com/services/support

https://support.tibco.com

Chapter

1Orchestrator

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


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 ismulti-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 communicationwas identified as one of the bottleneck. Orchestrator can now invoke some of these components directlyinstead of using JMS. Orchestrator can invoke the AOPD component interface directly (if AOPD is in colocatedmode 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, planitem, order amendment). The data for supporting the other features such as clustering, member failover, andrecovery 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 deployOrchestrator.

Resource Failure Handling

The Resource Failure Handling feature identifies the failure or unavailability of resources as soon as possibleand takes necessary actions. The Resource Failure Handling feature implements automatic reconnectionfeature 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 submittedorder 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 andchecks for resource failure. If an exception is identified then status of the particular resource is updated tothe HealthCheckEngine repository. If an exception is thrown while sending a JMS message by orchestratorthen that exception is reported to the HealthCheck thread and the resources are verified for failure. If a failureis detected then that failure is reported to the HealthCheckEngine repository. The HealthCheckEnginerepository is checked by the respective application to take the respective action on resource failure or recovery.


16 | Orchestrator

In case of a resource issue, the cluster processing will be stopped and the cluster status will be changed toINIT. The advisory messages will be processed by the Orchestrator for the JMS and the database. The messageswill be processed by the respective resource that is available. The Orchestrator will not process any requestsin case of a resource failure. The SOAP requests over JMS or HTTP will return back with the response codeto 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 willreturn an error code signifying a resource issue.

In case of resource recovery, the processing of the advisory messages will be stopped and the processing ofnormal heartbeat will resume. The cluster will be initilaized with all the available members in the clusterusing 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 markedto 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 ManagementAdministration Guide.


Orchestrator | 17

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, OrderAmendment, 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 configuredinternally to dispatch the JMS Messages, process Database notifications and logging. These actions are executedin batches using the batch processor.

Batch threads are configured to run in the Orchestrator. Batch Threads execute the actions with each threaddedicated 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 tothe Batch Queue and are processed in the sequence that was sent to Batch queue. Batch threads groups theaction execute requests and executes them in batch.


18 | Orchestrator

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 ismoved to the dead letter table in database. Any other notifications for the same order are moved to deadletter table. Users can execute them manually using the JMX console. The following screenshot is of thejconsole with available operations to process dead letter table entries:

Figure 1: jConsole UI for Operations to Process Dead Letter Table Entries


Orchestrator | 19

Batch Event Processing

Events are consumed by state machine and notifications generated by state machines are posted in the Batchprocess. 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 loggingd. 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.


20 | Orchestrator

Locking Strategy

The share nothing architecture is used while processing the orders. Each order is mapped to one node andany subsequent event to the order is processed by the same node. JMS message selector is used for routingorders to the correct nodes. If the event message header does not have the routing information, messages areintercepted and routed to an appropriate node by adding the appropriate message selector.


Orchestrator | 21

Failover

The Orchestrators can be deployed in a cluster domain. One of the members in the cluster can be ClusterManager (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 infailed 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. Thisnumber is also included in the heartbeat published by the members. Eventually all members in the clusterare aware of the sequence number assigned to the other members in cluster, based on the heartbeat. Eachmember can identify the lowest sequence numbers and find the corresponding node mapped to it. Memberwith 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 OMSdatabase.

4. The Cluster Domain Name and members of the cluster are configured in the OMS database. The tablesdefinitions are as follows:

Table 2: table DOMAIN

DescriptionColumn

Name for the Cluster DomainDOMAINID

Short Description of the domainDESCRIPTION

Backing store (DB). DB will use SQL for updating the status ofthe node.

BACKINGSTORE

Interval between Heart Beat in millisecondsHEARTBEATINTERVAL

Interval between cycles in milliseconds to check if the node canbe cluster manager and start executing the cluster manager tasks.

MANAGERACTIVATIONINTERVAL

Cluster manager assumes the node is failed if does not receivethe heartbeat from failed node after this specified interval inmillisecond.

FTTHRESHOLDINTERVAL

Allowed values are 1 or 0. Default is 1. If set to 1, Orchestratorwill transfer the events from failed nodes and start processing it.If 0, events from failed nodes will not be transfered.

HANDLEFAILEDNODEEVENTS

Table 3: table DOMAINMEMBERS

DescriptionColumn

Name for the Cluster MemberMEMBERID

Short Description of the memberDESCRIPTION

Domain that the member belongs to.DOMAINID

Cluster ID is uniquely generated by the node on runtime.CLUSTERID


22 | Orchestrator

DescriptionColumn

Flag is true if the member is cluster manager or its false if thisworker.

ISCLUSTERMANAGER

Sequence number generated by the member.SEQNUMBER

Last updated Timestamp.LASTUPDATETIMESTAMP

INIT or STARTED. INIT means the node is initializing. STARTEDmeans the node has started.

STATUS

Heartbeat Time Stamp.HEARTBEATTIMESTAMP

5. The Orchestrator restores the data during failure from the checkpoints. The Orchestrator supports databasecheck pointing.

6. On cluster failure, the Orchestrator's listeners and throttling are disabled. Node will join again in to thecluster with a new sequence number.


Orchestrator | 23

Notification

External clients can listen to JMS notifications that are sent by the Orchestrator for state changes. User canenable the JMS notifications and configure the JMS destination name. Also user can filter the state changenotification.

Property name to filter notificationProperty name to enable notificationType ofstatechange

c.t.f.o.order.statusChange.filterc.t.f.o.enableOrderStatusChangeOrder StatusChange

c.t.f.o.orderLine.statusChange.filterc.t.f.o.enableOrderLineStatusChangeOrderLineStatusChange

c.t.f.o.plan.statusChange.filterc.t.f.o.enablePlanStatusChangePlan StatusChange

c.t.f.o.planItem.statusChange.filterc.t.f.o.enablePlanItemStatusChangePlanItemStatusChange

c.t.f.o.orderAmendment.filterc.t.f.o.enableOrderAmendmentStatusChangeOrderAmendmentStatusChange

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. Filterproperty 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"/>


24 | Orchestrator

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


Orchestrator | 25

Throttling

Throttling controls the number of messages that the Orchestrator can consume and that can be dispatchedto the process component. If the Orchestrator dispatches more messages than the process components loadcapacity, then the process component becomes a bottleneck.

User controls the number of incoming messages the Orchestrator can consume at given point of time, byconfiguring the number of receivers for order receivers and process component receivers. For the outgoingmessages sent to the process components, the user can configure the default load capacity of the processcomponent. The Orchestrator stops consuming new orders when the number of process component requeststhat are not responded to exceeds the default load capacity.

Also the user can configure the load capacity for individual process components in the processProcessComponent.props located in the $AF_HOME\config directory. This property overrides the defaultload capacity. The user can configure the activation threshold in Percentage of load capacity so that the nodecan enable the listeners when the number of pending process component requests is less than this configuredvalue.


26 | Orchestrator

Order Request Optimization

The Router sends the order request to the Orchestrator with the payload. If the Orchestrator is throttled tonot pick more messages from the router, the message size will grow with the load. EMS Backing store willgrow when you have huge payload in the order request. User can enable a flag so the payload is truncatedfrom the message. The message contains only the order id in JMS Properties. The node that picks up thismessage 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>


Orchestrator | 27

Dead Letter Queue

When a JMS message reaches the maximum retry defined; it is sent to a dead queue configured with therespective route. In case of time dependencies if time dependency is not executed within the predefined retrycount it is saved into database and will not be picked by Orchestrator. This can be still triggered from JConsoleusing 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 queueevents 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 maxnumber 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 andcommitted in batch. If the transaction fails, each notification from the batch is executed separately andcommitted in the database. If it still fails, order id that is related to the notification is marked as batch errorand notification is moved to dead letter table in database. Any other notifications for the same order aremoved 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

DescriptionColumn

IDSID

Dead Letter ID (Any reference based on the dead letter type) For Timedependency and Batch, its order id.

DEADLETTERID

Allowed Values are TIME_DEPENDENCY and BATCH.DEADLETTERTYPE

Data blob.VALUE

Timestamp when record was last updated.LASTSTATUSCHANGE

5. Any JMS events on those orders before manually executing these requests are moved to JMS dead letterqueue.

6. Any Timer events on those orders before manually executing these requests are moved to DB dead letterqueue.

7. Following JMX operations are exposed to the user for viewing and executing the dead letter queue.

Expected ResultsArgumentsOperation

Displays list of all dead lettersaccording to the input parameter. If

A string value indicates deadletter type. Allowed values:

getDLQDB

input is empty string; it will list outTIME_DEPENDENCY andBATCH. It can be an empty string. all the dead letters including batch

errors and time events.

Displays list of messages pending onrespective dead queue provided as

A string value indicates deadqueue name or it can be an emptystring.

getDLQJMS

input. If input is empty string; it willlist out all the pending messages onall Orchestrator related dead queues.


28 | Orchestrator

Expected ResultsArgumentsOperation

Schedules the respective time eventfor execution. If dependencyID is

Two input parameter as stringvalue.

runDLQTimeDependencyErrors

empty string; schedules all time events1. orderIDof orderID available in dead letter forexecution.

2. dependencyID

Executes further processing ofrespective orderID. If input is an

A string value indicates orderIDor it can be an empty string.

runDLQBatchErrors

empty string, it will process allorderIDs available in dead letter.

Processes all messages pending onrespective dead queue. If input is an

A string value indicates deadqueue name or it can be an emptystring.

runOrchJMSDLQ

empty string, it will process messagespending on all dead queues.

The following dead queues are supported by JMX operations to move back the messages to its sourcedestination:

DescriptionDead Queue Name

Submit Order Request dead queuetibco.aff.orchestrator.order.submit.dead

PlanItem execution response dead queuetibco.aff.orchestrator.planItem.execute.reply.dead

MilestoneNotifyRequest from process componentsto Orchestrator dead queue

tibco.aff.orchestrator.planItem.milestone.notify.request.dead

Withdraw Order dead queuetibco.aff.orchestrator.order.withdraw.dead

Activate order request dead queuetibco.aff.orchestrator.order.activate.dead

PlanItem suspend response dead queuetibco.aff.orchestrator.planItem.suspend.reply.dead

Suspend order request dead queuetibco.aff.orchestrator.order.suspend.dead

Cache cleanup dead queuetibco.aff.orchestrator.cache.cleanup.dead

External Feasibility reply dead queuetibco.aff.orchestrator.provider.order.feasibility.reply.dead

External PreQualificationFailed reply dead queuetibco.aff.orchestrator.provider.order.prequal.failed.reply.dead

PlanItem error handler response dead queuetibco.aff.orchestrator.provider.planItem.failed.reply.dead

PlanItem External Dependency Releasetibco.aff.orchestrator.planItem.externalDependency

Request dead queuerelease.request.dead

Time dependency add event dead queuetibco.aff.orchestrator.cache.addEvent.dead


Orchestrator | 29

External Dependency

External dependency is a dependency type that waits for notification from an external system by an eventbefore 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 planitem has to ensure that the combination of event name and event id is unique across all the orders. A uniquedependency 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 processcomponent to Orchestrator using the following schema on the queuetibco.aff.orchestrator.planItem.externalDependency.release.request. The process componentmay choose to add 'originator' as a JMS message property with value as 'NodeID' if known to indicate toOMS 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 interfacecom.tibco.aff.oms.server.jms.orch.custom.OrchestratorPlanEnricher present in omsCommon-1.0.jarlocated 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 compiledimplementation should then be added to the classpath of omsServer.war and the fully qualified name of theimplementer class should be added to the com.tibco.fom.orch.enrich.CustomOrchPlanEnricher propertyin Configurator. In order to complete the process, omsServer.war should be re-deployed in Tomcat. .

Steps To Enable Enrichment1. 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.


30 | Orchestrator

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 presentat $AF_HOME/lib with the namecom.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.

Logging1. 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 {}.


Orchestrator | 31

Time Dependency

Time dependency in plan items is satisfied when a certain time period has elapsed, or a certain absolute dateand time has been reached. Time dependencies take the form of an absolute date time and once the time hasreached or passed, then the dependency is considered satisfied.

Time dependencies of a planItem are scheduled to be EXECUTED at the specified absolute time and onlyexecuted once the time is reached. If execution fails then the Orchestrator tries to execute it until maximumretries (com.tibco.fom.orch.timeDependency.maxRetryCount) is reached. If it fails during max retries then theOrchestrator puts the order into DEAD LETTER for future reference and the time dependencies will not bescheduled and not executed by the Orchestrator.


32 | Orchestrator

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 namecom.tibco.fom.orch.nonexecuting.planfragmentID which indicates a planItem having these PlanFragments willbe 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 alongwith its milestone dependencies.


Orchestrator | 33

Process Component Destination

Currently, process component notifications are sent to a default destination if there is no owner defined inthe process component or to a destination with owner name if owner is defined in process component. Thisdestination can be overridden and a new destination can be used as destination for process componentnotifications. This can be configured using property com.tibco.fom.orch.overridePlanfragmentDestination. If thisproperty is set to true then the destination will be picked from ProcessComponent.props file for respectiveprocess component ID. Content of this property file will be loaded when file is modified and the updatedvalue will be used for sending notifications. This properties file will have destination defined for processcomponent 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 propertycom.tibco.fom.orch.overridePlanfragmentDestination is configured as false then default behavior will be used andall the process component related notifications will be sent to a predefined queue. If the property is true andthe value is not configured, the default destination is used. The default value is false.


34 | Orchestrator

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 anew execution plan and orchestrate it to completion. This is the normal mode of operation for submittingnew orders to the system.

Partially Completed Order Fulfillment

Partially completed order fulfillment works in a similar manner, except as part of the plan development stepcertain plan items are indicated as having previously been completed. The new orchestration is created basedon this information. This will allow migration of partially completed orders from other fulfillment systemsinto Orchestrator.

In order for a partial order fulfillment to work, the previous fulfillment system must have suspended executionof the plan at a location that allows for migration. This will mean pushing orders through to completion ofthe currently in progress process component, and then suspending the order once all current in progresstasks have been completed. A sample scenario is outlined below:

Figure 4: Partially Completed Order Submission - Existing Fulfillment System


Orchestrator | 35

In the existing fulfillment system a plan is in execution. The plan snapshot occurs while process componentPC_2 is in progress. This plan will be in an inconsistent state and cannot be migrated. Therefore the in progressprocess component must be pushed through to completion before migrating the order. At this point PC_2will 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 plandevelopment 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 iscreated and returned to Orchestrator. Orchestrator will then set the status of previously completed plan itemsto complete so that they do not execute again. Orchestration will then continue at the next steps in the executionplan when the plan is resumed.

Amend Order

An order amendment is the process of making changes to a previously submitted order. An order can beamended by sending through the new order with the same orderID and orderRef as the previously submittedorder.

Orders may only be amended in certain lifecycle states.

Not AmendableAmendable

• Complete• Submitted

• •Feasibility Cancelled

•• WithdrawnPlan Development

• 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 restartingthe order lifecycle back from Submitted. At this point a plan has not been generated and does not need to bemodified. When the fulfillment process reaches the Plan Development step, the updated order as it existsfrom 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 orderis updated in the database, the existing plan is discarded and the order starts back from Submitted. Thisapplies to order status of Execution, but with a plan status of Pending. However, this is a very rare scenarioas the plan immediately goes into EXECUTION state.


36 | Orchestrator

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. Thisapplies 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 oneamendment may be active at any one time. Once the amendment has completed, and the order resumesexecution 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 beamended.

If an order is amended in Pre-Qualification Failed state, the action of order line in the amendment orderrequest 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 respondwith 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 COMPLETEstate. 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 statecannot be suspended again.

The suspended orders can be activated back into the EXECUTION state so as to proceed ahead with thefulfillment.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.


Orchestrator | 37

Order Submission

A customer order is received from an external order capture or request injection system, for example a CRMsystem 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 orderfulfillment. 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 backthe response to the calling application after the order has been completed through Orchestrator. The orderis stored in OMS and then sent to Orchestrator, which on completion (or failure) of order responds back. Thisresponse is then shown to the calling application. This is different from the Submit Order Service, whichaccepts the new order request, stores the order in OMS, sends the order to orchestrator, and returns theresponse back to the calling application with the order status as submitted without waiting for Orchestratorto respond back.


38 | Orchestrator

Execution Plan

Execution Plan is a process model which is developed for a concrete order and can also be termed as acollection of the activities that need to be completed to fulfill a customer order. Execution plans usually specifyhow 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 particularproduct against a particular action. The process component specified in plan item will be invoked for thefulfillment.

Actions

Each plan task has an action associated with it. These are the possible actions you can select for each plantask:• Provide• Cease• Update• Custom Actions

A plan task manages a particular item. Each action defines what needs to be done for a particular item. Anaction 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, MilestoneB cannot start until Milestone A completes.

For details, see Intermediate Milestones Dependencies on page 106.


Orchestrator | 39

Order Header

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

DescriptionType

A unique identifier supplied by the system that submits the order. The OrderReference is used to determine whether the order is a new request or an

Order Ref ID

amendment. OMS does this by checking if an order with the same OrderReference is already stored in the database. If the order already exists, the orderis an amendment. If there is not, then it is a new order request.

If the orderRefId is not supplied by external system, then Fulfillment OrderManagement system generates the reference ID and sends in response.

Internal ID of the order generated and assigned by OMS.Order ID

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

Execution Plan ID.Execution Plan

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

Notes about the order. Basically this is any additional text that may be suppliedby the summiteer or submitting system.

Notes

Reference ID of the subscriber.Subscriber ID

Used to retrieve the current customer profile and to identify the customer toother systems interested in the order.

Customer ID

Date when the order is changed.Changed Date

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

Currently not supported.Required On Date

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

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

This is a list of the identifiers of any service level agreement that applies to aparticular order.

Service Level Agreements(SLA)


40 | Orchestrator

Order Line

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

DescriptionType

Line no. of an order.Line No

The identifier of the specification of the product to be provided.Product ID

Inventory ID.Inventory ID

The action required for the specific product referred to in the order line. Youcan enter one of the following actions:

Action

• Provide: The customer has requested a new service.• Cease: The customer has requested that an existing service should cease.• Update: The customer has requested that an existing service be updated in

some way.• Cancel: the customer has cancelled the requested product.• <Custom Action>: Any defined custom action.

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

The number of the product required.Quantity

Currently not supported.Required On Date

Reference ID of the subscriber.Subscriber ID

Version of a particular product.Product Version

Link reference ID.Link ID

The current status of the order. This is automatically filled in and you cannotamend it. The status changes with the order item’s lifecycle.

Status

The date and time that the order line status last changed. This is automaticallyfilled in and you cannot amend it. It initially shows the date and time the orderline was created, and is updated to reflect later status changes.

Status Changed

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

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

A list of product characteristics that are supplied as input parameters to theorder to provide additional information to the product specification. Forinstance, this may be the color of a mobile telephone.

Characteristics


Orchestrator | 41

Orchestrator Interfaces

Fulfillment Order Management Orchestrator is the primary fulfillment engine and implemented in a Javacomponent. Orchestrator requests Fulfillment Order Management AOPD to generate the execution plan forthe order submitted by OMS. On receiving the execution plan from AOPD, it executes the plan tasks for orderfulfillment.

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 productunder 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. AF_Orchestrator_ForDesigner.projlib - This library is used in the TIBCO Designer projects for theTIBCO BusinessWorks-based process component development and contains simple resources. For example,XML payload schema, JMS connections, JMS application properties, and global variables.

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 forfulfillment. 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 todetermine 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 feasibilitychecking, no Feasibility Provider is required. However, if feasibility is enabled, then a Feasibility Providermust be available for orders to proceed. Feasibility Providers must conform to the following requirementsin 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 concludefeasibility.

• In the response event specify whether the order has passed feasibility by setting the passed flag to TRUEif 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 passedfeasibility or not.


42 | Orchestrator

Since the feasibility checking process is a customer-implemented component, the functional specification forthis 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 feasibilitychecking. It is an asynchronous request/reply event to a JMS queue that returns a reply to the default replyqueue 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.

Asynchronous request eventEvent Type

QueueQueue orTopic

tibco.aff.orchestrator.provider.order.feasibility.requestDestination

The event has the following property:

DescriptionCardinalityTypeProperty

The value of the NODE_ID Java property that is set in thesetenv script of the Apache Tomcat instance, which is

OptionalStringoriginator

running the Orchestrator component. This property is sentby the Orchestrator in all the outbound JMS messages andis expected to be mapped back by the external systems(process components, feasibility providers, pre-qualificationfailure handlers, and error handlers) in the correspondingresponse messages.

The event has the following payload:

Figure 6: Feasibility Request

The following table lists the details of the elements.

DescriptionCardinalityTypeElement

Unique identifier for tracing purposes across function calls.OptionalStringbusinessTransactionID

Unique identifier to correlate the request message with aresponse message.

OptionalStringcorrelationID

Order ID for the order to feasibility check.RequiredStringorderID

Order Request type. See Appendix A for the specificationof this type.

RequiredTypeorderRequest


Orchestrator | 43

Feasibility Response

Feasibility Response is an event sent by Feasibility Provider back to Orchestrator in response to a FeasibilityRequest 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 basedon the returned value of these flags. The two flags can be used to distinguish between technical and businessexceptions. For example, a failure to complete would generally indicate a technical exception so completewould be false. A validation failure would indicate a business exception where complete would be true, butpassed would be false.

This flag indicates whether the feasibility call completed. If this is set to true, then the Passedflag becomes relevant.

Completed

This flag indicates whether the order has passed feasibility.Passed

Based on different scenarios, these flags should be set as follows:

DescriptionPassedCompleted

Orchestrator refers the order to the Pre-Qualification FailedHandler if error handling is enabled for feasibility, or the erroris withdrawn if error handling is not enabled.

False TrueFalseTechnical Error

Orchestrator refers the order to the Pre-Qualification FailedHandler if error handling is enabled for feasibility, or the erroris withdrawn if error handling is not enabled.

FalseTrueBusiness Error

Processing continues as normal.TrueTrueSuccess

Asynchronous reply eventEvent Type

QueueQueue or Topic

tibco.aff.orchestrator.provider.order.feasibility.replyDestination



The value of the originator property in theFeasibilityRequest message, received from the Orchestrator,


which should be mapped and sent back in the responsemessage.



44 | Orchestrator

Figure 7: Feasibility Response




Unique identifier to correlate the request message with aresponse message. Even though this field is marked as

RequiredStringcorrelationID

optional in the response schema, it is required forOrchestrator to be able to correlate the response with thecorrect version of the submitted order. Populate this fieldthe same as correlationID in the request message.

Result status type. See Appendix A for the specification ofthis type.

RequiredTyperesultStatus

Order ID for the order that was feasibility checked.RequiredStringorderID

Order ref for the order that was feasibility checked.RequiredStringorderRef

Flag indicating whether the feasibility call completed.RequiredBooleancompleted

Flag indicating whether the order has passed feasibility.RequiredBooleanpassed

Message type. See Appendix A for the specification of thistype. This list of messages will be passed to thePre-Qualification Failed Handler if invoked.

0-MTypemessage

Process Components

Overview

A Process Component is the implementation of a series of steps that are required to fulfill a plan item. Processcomponents should be implemented using any JMS-enabled technology provided they meet the requirementsoutlined here. Typically short-lived, automated processes will be implemented in TIBCO BusinessEvents orTIBCO BusinessWorks, while long-lived and manual processes will be implemented using TIBCO BPM.

These are required components in the architecture.


Orchestrator | 45

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 Requestb. Plan Item Suspend Requestc. Plan Item Activate Request

3. For plan item execute requests, perform a series of tasks that are required to fulfill the product and actionspecified 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 planitem suspend response if execution was suspended.

6. For plan item activate requests, resume execution of a previously suspended process component. Thisresume 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 Responseb. 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 fulfillmentof a particular plan item. It is received by the Process Component and a series of tasks then executes. It is anasynchronous event to a JMS queue. The response is another asynchronous event on a different JMS queue.

Asynchronous eventEvent Type

QueueQueue or Topic

tibco.aff.orchestrator.planItem.execute.requestDestination

The destination name tibco.aff.orchestrator.planItem.execute.request is valid only if ownervalue is "". Otherwise, the destination would be as follows: (If owner value is defined), the destinationwould be tibco.aff.orchestrator.planItem.<ownertype>.execute.request .

For example, if the owner value in the plan fragment model is BPM, the destination would betibco.aff.orchestrator.planItem.BPM.execute.request.

The event has the following properties:


Unique identifier for the Process Component to beexecuted.

RequiredStringprocessComponentID

Name of the Process Component to be executed. Thisis the name as configured in the Process Component

RequiredStringprocessComponentName

Model for the specified processComponentID. If thereis no model specified then this field is null.


46 | Orchestrator

Version of the Process Component to be executed. Thisis the version as configured in the Process Component

RequiredStringprocessComponentVersion

Model for the specified processComponentID. If thereis no model specified then this field is null.

Type of the Process Component to be executed. This isthe type as configured in the Process Component Model

RequiredStringprocessComponentType

for the specified processComponentID. If there is nomodel specified then this field is null.

It is a class of processComponentType. This is theprocessComponentRecordType as configured in the

RequiredStringprocessComponentRecordType

Process Component Model. If there is no modelspecified then this field is null.

It is the standard JMS message priority to be sent in theoutbound message to support order priority.

RequiredIntegerJMSPriority

The value of the NODE_ID Java property that is set inthe setenv script of the Apache Tomcat instance, which


is running the Orchestrator component. This propertyis sent by the Orchestrator in all the outbound JMSmessages and is expected to be mapped back by theexternal systems (process components, feasibilityproviders, pre-qualification failure handlers, and errorhandlers) in the corresponding response messages.

The payload specification is as follows:


Orchestrator | 47

Figure 8: Plan Item Execute Request



Unique identifier for tracing purposes acrossfunction calls.

OptionalStringbusinessTransactionID

Unique identifier to correlate the request messagewith a response message.


Internal unique identifier for the order associatedwith the plan containing the plan item to execute.

RequiredStringorderID

External unique identifier for the order associatedwith the plan containing the plan item to execute.

RequiredStringorderRef

Internal unique identifier for the plan that containsthe plan item to execute.

RequiredStringplanID

Plan item type for the plan item to execute. SeeAppendix A for the specification of this type.

RequiredTypeplanItem

Service level agreement type.OptionalTypesla

Typical duration in msec for this execution whenSLAs are implemented in the Process Component.

RequiredLongsla/typicalDuration

Maximum duration in msec for this execution whenSLAs are implemented in the Process Component.

RequiredLongsla/maximumDuration


48 | Orchestrator

Milestone ID for a milestone within the ProcessComponent where execution must wait until notifiedby Orchestrator that it should proceed.

0-MStringwaitAtMilestoneID

MilestoneID for a milestone within the ProcessComponent where the Process Component must

0-MStringnotifyAtMilestoneID

notify Orchestrator that the milestone has beenpassed 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 continueexecution when stopped at a particular milestone. It may be possible that this notification will occur beforethe Process Component has reached the milestone during execution. Therefore it is necessary for the ProcessComponent to maintain a state of the milestone at any time during execution. There is no response to thisinterface.


QueueQueue or Topic

tibco.aff.orchestrator.planItem.milestone.release.requestDestination



Unique identifier for the Process Componentto be executed.


Name of the Process Component to beexecuted. This is the name as configured in the


Process Component Model for the specifiedprocessComponentID. If there is no modelspecified then this field is null.

Version of the Process Component to beexecuted. This is the version as configured in


the Process Component Model for the specifiedprocessComponentID. If there is no modelspecified then this field is null.

Type of the Process Component to be executed.This is the type as configured in the Process


Component Model for the specifiedprocessComponentID. If there is no modelspecified then this field is null.

Internal unique identifier for the plan thatcontains the plan item with the milestone to bereleased.


Unique identifier for the plan item that containsthe milestone to be released.

RequiredStringplanItemID

Unique identifier for the milestone within theplan item and plan to be released.

RequiredStringmilestoneID


Orchestrator | 49

The value of the NODE_ID Java property that isset in the setenv script of the Apache Tomcat


instance, which is running the Orchestratorcomponent. This property is sent by theOrchestrator in all the outbound JMS messagesand is expected to be mapped back by theexternal systems (process components,feasibility providers, pre-qualification failurehandlers, and error handlers) in thecorresponding response messages.


Figure 9: Plan Item Milestone Release Request


Unique identifier fortracing purposes acrossfunction calls.


Unique identifier tocorrelate the request


message with a responsemessage.

Internal unique identifierfor the order associated


with the plan containingthe plan item with themilestone to be released.

External unique identifierfor the order associated


with the plan containingthe plan item with themilestone to be released.

Internal unique identifierfor the plan that contains



50 | Orchestrator

the plan item with themilestone to be released.

Plan item type for theplan item with the


milestone to be released.See Appendix A for thespecification of this type.

Unique identifier for themilestone within the plan


item and plan to bereleased.

Plan Item Milestone Notify Request Event

Plan Item Milestone Notify Event is sent by a Process Component to Orchestrator to notify the orchestrationengine that a particular milestone has been passed during execution. This event will enable the Orchestratorto release the milestone which was waiting on the current milestone that was notified.


QueueQueue or Topic

tibco.aff.orchestrator.planItem.milestone.notify.requestDestination



The value of the originator property in thePlanItemExecuteRequest message, received from the


Orchestrator, which should be mapped and sent back inthis response message.


Figure 10: Plan Item Milestone Notify Request Event


Orchestrator | 51


Unique identifier for tracingpurposes across function calls.


Unique identifier to correlate therequest message with a responsemessage.


Internal unique identifier for theorder associated with the plan


containing the plan item with themilestone to notify.

External unique identifier for theorder associated with the plan


containing the plan item with themilestone to notify.

Internal unique identifier for theplan that contains the plan itemwith the milestone to notify.


Unique identifier for the planitem within the plan with themilestone to notify.


Unique identifier for themilestone within the plan item inthe 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 ExecuteRequest Event or a Plan Item Suspend Event. Orchestrator receives the result and interprets the resultaccordingly. It is an asynchronous event to a JMS queue.

The response for Plan Item Execute has success, completed, and cancelled flags. Orchestrator does not takeany action in response to the cancelled flag. However it does route plan items to either Plan Item InternalError 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 exceptiondifferently depending on a completed or failure status.

The two flags can be used to distinguish between technical and business exceptions. For example, a failureto complete would generally indicate a technical exception so completed would be false. A validation failurewould indicate a business exception where complete would be true, but success would be false.

This flag indicates that the Process Component completed. If this is set to true, then the Successflag becomes relevant. If this is false then the Process Component did not complete and theSuccess flag is automatically considered to be false as well.

Completed

This flag indicates whether the Process Component was successful. This is only relevant ifthe complete flag is set to true.

Success

The possible response scenarios are:

DescriptionPassedComplete


52 | Orchestrator

Orchestrator will retry the Process Component call for thedefined number of retries with the defined retry interval. If

False TrueFalseTechnical Error

the Process Component call continues to fail, then it will referthe plan item to the Plan Item Failed Handler.

Orchestrator will refer the plan item to the Plan Item FailedHandler.

FalseTrueBusiness Error


In addition to the completed and success values, the Plan Item Execute Response Event also allows returninga cancelled flag. This is only valid if responding to a Plan Item Activate Request Event and it indicates whetherthe cancellation was completed successfully whether or not a rollback was requested. The completed andsuccess values retain the same definitions in the event of an activation request as in an execution request.

The possible response scenarios are:

DescriptionCancelled

No cancellation occurred.FalseExecute Request

Cancellation requested with rollback.TrueActivate Request with Rollback

Cancellation requested with no rollback.TrueActivate Request withoutRollback


QueueQueue or Topic

tibco.aff.orchestrator.planItem.execute.replyDestination



The value of the originator property in thePlanItemExecuteRequest message, received from the


Orchestrator, which should be mapped and sent back inthe response message.



Orchestrator | 53

Figure 11: Plan Item Execute Response







Result status type. See Appendix A for thespecification of this type.


Internal unique identifier for the order associatedwith the plan containing the plan item to execute.


External unique identifier for the order associatedwith the plan containing the plan item to execute.


Internal unique identifier for the plan that containsthe plan item to execute.


Unique identifier for the plan item within the planto be executed.


Flag indicating if the Process Component completedprocessing.

RequiredBooleancompleted

Flag indicating if the Process Component completedsuccessfully.

RequiredBooleansuccess


54 | Orchestrator

Flag indicating that the Process Componentsuccessfully cancelled previously completed tasks.

RequiredBooleancancelled

Message type. See Appendix A for the specificationfor this type.

0-MTypemessage

Flag indicating that the execution time of the ProcessComponent violated the typical SLA duration.

OptionalTypetypicalSLAViolated

Flag indicating that the execution time of the ProcessComponent violated the maximum SLA duration.

OptionalTypemaximumSLAViolated

Plan Item Suspend Request Event

Plan Item Suspend Request Event is sent by Orchestrator to a Process Component to request suspension ofexecution of a particular plan item. It is received by the Process Component which then either suspendsexecution or completes execution. It is an asynchronous event to a JMS queue. The response is anotherasynchronous event on a different JMS queue.


QueueQueue or Topic

tibco.aff.orchestrator.planItem.suspend.requestDestination

The destination name tibco.aff.orchestrator.planItem.suspend.request is valid only if ownervalue is "". Otherwise, the destination would be as follows: (If owner value is defined), the destinationwould be tibco.aff.orchestrator.planItem.<ownertype>.suspend.request .

For example, if the owner value in the plan fragment model is BPM, the destination would betibco.aff.orchestrator.planItem.BPM.suspend.request.



Unique identifier for the Process Component to be executed.RequiredStringprocessComponentID

Name of the Process Component to be executed. This is thename as configured in the Process Component Model for the


specified processComponentID. If there is no model specifiedthen this field is null.

Version of the Process Component to be executed. This is theversion as configured in the Process Component Model for the


specified processComponentID. If there is no model specifiedthen this field is null.

Type of the Process Component to be executed. This is the typeas configured in the Process Component Model for the specified


processComponentID. If there is no model specified then thisfield is null.

It is a class of processComponentType. This is theprocessComponentRecordType as configured in the Process


Component Model. If there is no model specified then this fieldis null.


Orchestrator | 55

It is the standard JMS message priority to be sent in theoutbound message to support order priority.


The value of the NODE_ID Java property that is set in the setenvscript of the Apache Tomcat instance, which is running the


Orchestrator component. This property is sent by theOrchestrator in all the outbound JMS messages and is expectedto be mapped back by the external systems (processcomponents, feasibility providers, pre-qualification failurehandlers, and error handlers) in the corresponding responsemessages.


Figure 12: Plan Item Suspend Request



Unique identifier for tracing purposes across functioncalls.




Internal unique identifier for the order associatedwith the plan containing the plan item to besuspended.


External unique identifier for the order associatedwith the plan containing the plan item to besuspended.


Internal unique identifier for the plan that containsthe plan item to be suspended.


Plan item type for the plan item to be suspended.See Appendix A for the specification of this type.



56 | Orchestrator

Plan Item Suspend Response Event

Plan Item Suspend Response Event is sent by a Process Component as a response to a Plan Item SuspendRequest Event. Orchestrator receives the result and interprets the result accordingly. It is an asynchronousevent to a JMS queue.


QueueQueue orTopic

tibco.aff.orchestrator.planItem.suspend.replyDestination



The value of the originator property in thePlanItemSuspendRequest message, received from the




Figure 13: Plan Item Suspend Response




Unique identifier to correlate the request message with aresponse message.



Orchestrator | 57

Result status type. See Appendix A for the specification ofthis type.


Internal unique identifier for the order associated with theplan containing the plan item to suspend.


External unique identifier for the order associated with theplan containing the plan item to suspend.


Internal unique identifier for the plan that contains the planitem to suspend.


Unique identifier for the plan item within the plan to besuspended.


Flag indicating if the Process Component suspendcompleted processing.

RequiredBooleancompleted

Flag indicating if the Process Component suspendcompleted successfully.


Plan Item Activate Request Event

Plan Item Activate Request Event is sent by Orchestrator to a Process Component to request activation of apreviously suspended plan item. It is received by the Process Component which then resumes, cancels withrollback, or cancels without rollback. It is an asynchronous event to a JMS queue. There is no specific responseto a Plan Item Activate Request Event, however the Process Component is expected to complete processingand return a Plan Item Execute Response Event as usual.


QueueQueue orTopic

tibco.aff.orchestrator.planItem.activate.requestDestination

The destination name tibco.aff.orchestrator.planItem.activate.request is valid only if ownervalue is "". Otherwise, the destination would be as follows: (If owner value is defined), the destinationwould be tibco.aff.orchestrator.planItem.<ownertype>.activate.request .

For example, if the owner value in the plan fragment model is BPM, the destination would betibco.aff.orchestrator.planItem.BPM.activate.request.



Unique identifier for the Process Component tobe executed.


Name of the Process Component to be executed.This is the name as configured in the Process



Version of the Process Component to be executed.This is the version as configured in the Process


Component Model for the specified


58 | Orchestrator

processComponentID. If there is no modelspecified then this field is null.

Type of the Process Component to be executed.This is the type as configured in the Process



It is a class of processComponentType. This is theprocessComponentRecordType as configured in


the Process Component Model. If there is nomodel specified then this field is null.

It is the standard JMS message priority to be sentin the outbound message to support orderpriority.


The value of the NODE_ID Java property that is setin the setenv script of the Apache Tomcat


instance, which is running the Orchestratorcomponent. This property is sent by theOrchestrator in all the outbound JMS messagesand is expected to be mapped back by the externalsystems (process components, feasibilityproviders, pre-qualification failure handlers, anderror handlers) in the corresponding responsemessages.


Figure 14: Plan Item Activate Request



Orchestrator | 59




Unique identifier to correlate the requestmessage with a response message.


Internal unique identifier for the orderassociated with the plan containing the planitem to activate.


External unique identifier for the orderassociated with the plan containing the planitem to activate.


Internal unique identifier for the plan thatcontains the plan item to activate.


Plan item type for the plan item to activate. SeeAppendix A for the specification of this type.


Flag indicating that the Process Componentshould resume execution from the point whereit was previously suspended.

Required,Choice

TyperesumeExecution

Flag indicating that the Process Componentshould cancel execution and roll backpreviously completed tasks.

Required,Choice

TypecancelAndRollback

Flag indicating that the Process Componentshould cancel execution and not roll backpreviously completed tasks.

Required,Choice

TypecancelWithNoRollback

Pre-qualification Failed Handlers

Overview

A Pre-Qualification Failed Handler is a customer-implemented component used to manage failed feasibilityand plan development steps in Orchestrator. During the fulfillment process, Orchestrator would optionallycall 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 ordercannot be fulfilled, then the fulfillment process cannot proceed. The order may be referred to thePre-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 fulfillmentprocess cannot proceed and the order may be referred to the Pre-Qualification Failed Handler for manualintervention if OPD error handling is enabled.

Pre-Qualification Failed Handler is an optional component in the architecture. Customers may choose toimplement full error handling within the Feasibility Provider and the Plan Development Provider. In thatcase it is not valid to return anything back to Orchestrator other than passed in the case of feasibility andsuccess in the case of plan development. If anything else is returned to Orchestrator there is no handler toprocess 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 validimplementation.


60 | Orchestrator

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:

The Pre-Qualification Failed Handler sends back a new orderRequest that Orchestrator resubmitsautomatically. This is handled as a pre-execution order amendment and execution begins from

Resubmit

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

Orchestrator resubmits the order to either the Feasibility Provider or the Plan DevelopmentProvider as it was originally submitted. If this new call fails, the order is sent back to thePre-Qualification Failed Handler again.

Retry

The order will be withdrawn from Orchestrator and not be fulfilled. It is deleted from the engineand Transient Data Store.

Withdraw

The details of the Pre-Qualification Failed Handler is left as a customer-specific implementation. An exampleof 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 ordershould be resubmitted.

b. Update configurations in back-end systems or product catalogue that allows the order to pass feasibilityand 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 procedurethen 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 plandevelopment call. It is received by the Pre-Qualification Failed Handler for manual processing. It is anasynchronous event to a JMS queue. The response is another asynchronous event on a different JMS queue.


QueueQueue or Topic

tibco.aff.orchestrator.provider.order.prequal.failed.requestDestination


Orchestrator | 61







Figure 15: Pre-Qualification Failed Request



Unique identifier for tracing purposes across functioncalls.


Unique identifier to correlate the request message witha response message.


Order ID for the order that failed feasibility or plandevelopment.


Order Request type for the order that failed feasibilityor plan development. See Appendix A for thespecification of this type.

RequiredTypeorderRequest

Flag indicating that this failure was due to a feasibilityfailure.

Required, ChoiceTypefeasibilityFailed

Flag indicating that this failure was due to a plandevelopment failure.

Required, ChoiceTypeopdFailed

Message type. See Appendix A for the specification ofthis type. This will be any list of messages passed back

0-MTypemessage

from the Feasibility Provider or the Plan DevelopmentProvider.


62 | Orchestrator

Pre-qualification Failed Response Event

Pre-Qualification Failed Response Event is sent by Pre-Qualification Failed Handler as a response to the failedfeasibility or plan development step. Orchestrator receives the result and interprets the result accordingly.It is an asynchronous event to a JMS queue.


QueueQueue or Topic

tibco.aff.orchestrator.provider.order.prequal.failed.replyDestination



The value of the originator property in thePre-QualificationFailedRequest message, received from


the Orchestrator, which should be mapped and sent backin the response message.


Figure 16: Pre-qualification Failed Response





Unique identifier to correlate the request messagewith a response message. Even though this field


is marked as optional in the response schema, itis required for Orchestrator to be able to correlatethe response with the correct version of the


Orchestrator | 63

submitted order. Populate this field the same ascorrelationID in the request message.

Internal unique identifier for the order that failedfeasibility or plan development.


External unique identifier for the order that failedfeasibility or plan development.


Flag indicating that the order should bewithdrawn.

Required, ChoiceTypewithdraw

Flag indicating that the order should retryfeasibility without any changes. This response

Required, ChoiceTyperetryFeasibility

may be made in cases where the request was foreither feasibility or plan development failure.

Flag indicating that the order should retry plandevelopment without any changes. This response

Required, ChoiceTyperetryOPD

may be made in cases where the request was forplan development failure. Technically there is norestriction on doing so in the case of a feasibilityfailure, but functionally it does not make senseto do so.

Order request type. See Appendix A for thespecification of this type. This is provided in thecase of an order resubmit.

Required, ChoiceTypeorderRequest

Message type. See Appendix A for thespecification of this type. If populated, this list of

0-MTypemessage

messages will be returned in any Submit OrderResponse message occurring after the call to thePreQualification 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 executioncompletes, 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 thenext items in the plan.

Error or incomplete execution means that the plan item has not been successfully completed and thereforethe 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 determininghow to handle the failed plan item. Both are handled the same by invoking the Plan Item Error Handler andindicating which failure mode returned. The semantics of how to determine whether a Process Componentis incomplete or in error is left to a customer-specific interpretation and implementation. The implementationbetween Process Components and the Plan Item Error Handler should be consistent.


64 | Orchestrator

Plan Item Error Handler is an optional component in the architecture. Customers may choose to implementfull error handling within the Process Component. In that case it is not valid to return anything back toOrchestrator other than success. If anything else is returned to Orchestrator, there would be no handler toprocess the result and the plan remains in an execution state without progressing beyond the failed planitem.

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

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:

The plan item is resubmitted to the Process Component to start over from the beginning. Thisoccurs immediately upon receipt of the Plan Item Failed Response event as all dependencies

Retry

have been previously satisfied. The Process Component is notified to re-execute the plan itemthrough a Plan Item Execute Request event. If Orchestrator has been automatically set up to retryfailed process components, and this retry fails as well, the retry count is not reset to zero. In otherwords, if the retry from a Plan Item Failed Handler response fails, then that failure is immediatelyredirected back to the Plan Item Failed Handler for processing again as a new failed plan item,and not automatically retried further.

The plan item is resumed in the Process Component from the point of failure. The implementationdetails of this are left for Process Component design. However it is conceivable that the Process

Resume

Component may choose to handle a resume the same as a full retry if it is not functionally possibleto resume execution from the point of failure. The Process Component is notified to resume theplan item through a Plan Item Activate event.

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

Complete

the newly Completed plan item is evaluated and further plan items triggered as in the normalexecution.

The details of the Plan Item Failed Handler is left as a customer-specific implementation. An example of ahandler 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 ProcessComponent. The plan item may be retried or resumed.

c. Implement the required functionality for the plan item manually in the back-end systems. The planitem may be completed.


Orchestrator | 65

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 thePlan Item Failed Handler for manual processing. It is an asynchronous event to a JMS queue. The responseis another asynchronous event on a different JMS queue.


QueueQueue orTopic

tibco.aff.orchestrator.provider.planItem.failed.requestDestination







Figure 17: Plan Item Failed Request



66 | Orchestrator






Internal unique identifier for the order associatedwith the plan containing the failed plan item.


External unique identifier for the order associatedwith the plan containing the failed plan item.


Internal unique identifier for the plan that containsthe failed plan item.


Plan item type for the plan item that failed. SeeAppendix A for the specification of this type.


Name of the error handler to invoke for this failedplan item. This value is either populated from the

RequiredStringerrorHandler

Process Component Model for the ProcessComponent if it exists or with the default errorhandler from the Orchestrator configuration.

Message type. See Appendix A for the specificationof this type. This is the list of messages as returnedin the Plan Item Execute Response Event.

0-MTypemessage

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


QueueQueue or Topic

tibco.aff.orchestrator.provider.planItem.failed.replyDestination



The value of the originator property in thePlanItemFailedRequest message, received from the





Orchestrator | 67

Figure 18: Plan Item Failed Response




Unique identifier to correlate the request message with aresponse message. Even though this field is marked as optional


in the response schema, it is required for Orchestrator to beable to correlate the response with the correct version of thesubmitted order. Populate this field the same as correlationIDin the request message.

Internal unique identifier for the order associated with the plancontaining the failed plan item.


External unique identifier for the order associated with theplan containing the failed plan item.


Internal unique identifier for the plan that contains the failedplan item.


Unique identifier for the plan item within the plan that failed.RequiredStringplanItemID

Flag indicating that the plan item should be retried.Required,Choice

Typeretry

Flag indicating that the plan item should be resumed from thepoint of failure.

Required,Choice

Typeresume

Flag indicating that the plan item should be marked asComplete and execution continue.

Required,Choice

Typecomplete

Message type. See Appendix A for the specification of thistype. If populated, this list of messages will be returned in any

0-MTypemessage


68 | Orchestrator

Submit Order Response message occurring after the call to thePlan Item Failed Handler occurred.


Orchestrator | 69

Chapter

2Automated 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


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

A Product Model contains Bundles and Products Services. A Product model also contains concepts such assequencing and dependencies.

When an order is received, order lines are decomposed using a Product model. The product specification foreach 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 Fragmentdefineservices, products, and resources required. For example, an order line may contain a bundle, which may becomprised of several products and services. Taking into consideration factors such as sequencing anddependencies, these execution plan fragments are then combined to create a single execution plan.


72 | Automated Order Plan Development

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 thedefault 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 throughEMS.

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 isin omsServer.war.

Standalone Mode

In standalone mode, AOPD is not running on the same application server than OMS. AOPD can run on anotherapplication 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 thatis in omsServer.war.

Using shipped AOPD implementation

The FOM installation provides the AOPD implementation in a war file, ready to be deployed in an applicationserver. It can be used to setup another application server, either on the same machine (vertical scaling), or adifferent machine (horizontal scaling).


Automated Order Plan Development | 73

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 deployaopd.war in the same application server. The file aopd.war is provided for convenience, if user wantsto 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 othercomponents. In a same way, the custom AOPD can be deployed, either on the same machine, or a differentmachine.

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 thatis in omsServer.war.

Figure 22: Custom AOPD in Standalone Mode (Vertical Scaling)



Figure 23: Custom AOPD in Standalone Mode (Horizontal Scaling)



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 whetherAOPD is deployed in standalone and colocated mode.

Additional listeners, Execution Plan and Amendment are active when AOPD is in standalone mode. Incolocated mode, there is direct API call from AFI to AOPD bypassing the queues and listenersconfiguration for Execution plan and Amendment plan requests.

AOPD stores Action and Product models into the OMS database (data_model table) for both online andoffline 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. Ifan existing product is loaded again then it is first updated in OMS database, deleted from local repositoryand then the incoming product model is loaded in AOPD.



Configuration

AOPD configuration is stored in different files in the directory $AF_HOME/config. The files can be eithermanually 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.

DescriptionParameter Name

Merges affinity UDF name (default: false)AffinityUDFNameMerge

To not merge certain UDFs during Affinity Sequencing, those UDFsshould be added as CSV in the variable (default: "")

CharacterisitcsWithoutAffinityPostfix

Within AOPD, if the sequence is -1, it will skip the product and all itsmandatory children in the Execution Plan (default: -1)

SkipItemSequence

Merges affinity item description (default: false)MergeAffinityItemDescription

Uses unconditional removal of child product (default: false)HierarchySingleUse

Enables affinity UDF parent (default: false)EnableAffinityUDFParent

List of internal UDFs to be skipped for affinity merging (default:"EPMR_ACTION_PROVIDE, EPMR_ACTION_UPDATE,

UDFList

EPMR_ACTION_CEASE, EPMR_ACTION_WITHDRAW,COMPENSATE_PROVIDE, COMPENSATE_UPDATE,COMPENSATE_CEASE")

Enables extended behavior for PDO/MDO and LinkID mapping(default: false)

EnableBiDirectionalLinkID

Allows Multiple Required Products for the same link ID (default: false)AllowMultipleRequiredProducts

Ignores First child dependency for source product in PDO relationship(default: false)

IgnorePDOFirstChildDependency

Configurable handling for PCO conflict (default: "Apply")HandleConflict

Include only the orderline for attribute based decomposition(default:false)

ABDProductOrderline

Include plan item udfs for evaluating attribute based decomposition(default:false)

ABDIncludeCharacteristics

Enables COMPENSATE and RESTART behavior in case of the requiredEPMR characteristic that is not present in the product model.

CompensateRestartForNoEPMRChar

Enables the backward compatibility for Date Shift amendment togenerate comp redo tasks (default: false)

EnableDateShiftCompRedo

Enables the backward compatibility for udf change amendment usingMODIFICATION_IDENTIFYING_ATTR (default: false)

EnableModificationIdentifyingAttribute

Enables the backward compatibility of NO dependency in theCOMPENSATE plan item on the existing plan item being cancelled.

NoDependencyInCOMPPlanItems



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.

DescriptionParameter Name

Name of the OPDRequest from Orchestrator receiver queue (default:tibco.aff.orchestrator.provider.order.opd.request)

OPDRequest from Orchestratorreceiver queue

Number of the OPDRequest from Orchestrator receiver (default: 3)OPDRequest from Orchestratorreceiver count

Name of the ExecutionPlanNewRequest to AOPD sender queue (default:tibco.aff.ocv.events.plan.new.request)

ExecutionPlanNewRequest toAOPD sender queue

Name of the ExecutionPlanAmendRequest to AOPD sender queue(default: tibco.aff.ocv.events.plan.amend.request)

ExecutionPlanAmendRequest toAOPD sender queue

Name of the ExecutionPlanNewResponse from AOPD receiver queue(default: tibco.aff.ocv.events.newplan.reply)

ExecutionPlanNewResponse fromAOPD receiver queue

Number of the ExecutionPlanNewResponse from AOPD receiver(default: 3)

ExecutionPlanNewResponse fromAOPD receiver count

Name of the ExecutionPlanAmendResponse from AOPD receiver queue(default: tibco.aff.ocv.events.amendplan.reply)

ExecutionPlanAmendResponsefrom AOPD receiver queue

Number of the ExecutionPlanAmendResponse from AOPD receiver(default: 3)

ExecutionPlanAmendResponsefrom AOPD receiver count

Name of the OPDResponse to Orchestrator sender queue (default:tibco.aff.orchestrator.provider.order.opd.reply)

OPDResponse to Orchestratorsender queue



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 ismandatory or not. For instance, consider a product A having a child product B, which has AutoProvision setas TRUE.

Static: If Autoprovision is set to TRUE, then the product is considered to be a static bundle and the child isautomatically be assumed to be a part of the order. This indicates that the child product is implicitly assumedto 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 includedin 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, whichis 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 anditems are selected by the user and then submitted for order plan development. An example would be wherea 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 anorderline 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 hasthe required product before any decomposition occurs.

It is possible to reuse the common products having Autoprovision=false using LinkParentID andLinkedParentID UDFs in the orderline. The LinkParentID-LinkedParentID and LinkID UDFs are used todefine 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)



T-COM Wireline --> (PCO) Tarrif1(autoproivision=false)Additional Voice Service --> (PCO) Tarrif1(autoproivision=false)

Therefore, the order can be:

LinkedParentIDLinkParentIDProductOrderline Number

T-COM WirelineT-COM Wireline1

T-Com WirelineAdditional VoiceService

Additional Voice Service2

Additional VoiceService

Tarrif1Tarrif13

T-Com WirelineTarrif1Tarrif14

The LinkParentID-LinkedParentID UDFs are added for orderline number 2 in the following format to adddependency 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 theLinkParentID-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 onlycontaining mandatory options. An example of this would be a bundle with mandatory products and whena customer orders this bundle all the dependent products are provisioned without the customer needing toselecting any more products.

Time Dependency

The decomposition component has the ability to provision an execution plan for a given order based uponthe time constraints, if any, placed on the products within that order e.g. it determines when a particularproduct execution should be started. This time constraint could apply to an individual plan item within anexecution plan or to the entire execution plan. Time dependency will be added in each plan item if therequiredByDate specified in order is in future.

Time dependency defines the absolute time when the particular plan fragment starts execution. It is calculatedon the basis of requiredByDate present in either the Orderheader or OrderLine. The expected behaviour forthe required by date is as follows1. 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 forthat 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 behaviourapplies: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 usedis the one at order line level.



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 decomposedto 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 oris 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 itemscan have UDFs as well which are copied to the execution plan. All theses UDFs can be used later throughthe service call.

Custom Action Based Product Decomposition

The custom action provides flexible way to define products and product fulfillment by allowing productdecomposition 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 modelspecific 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:

Characteristic (C)ProductComprisedOf (PCO)

The characteristic is alwaysincluded as planItem UDFs

If C.ActionID=nullThe child product is always apart of the decompositionduring decomposition

IfPCO.ActionID=null

The characteristic is included ifthe following order action is

If C.ActionID=notnull

The child product is only addedif the following order action isspecified duringdecomposition:

order Action = the ActionID

IfPCO.ActionID=not

null specified duringdecomposition:

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.

PlanOrderData Model Configuration

There are three planItems:OL=B(PROVIDE)Action repository has record with IDas HomeMove and recordtype as • BPROVIDE. Product B has PCO • P1relationship with P1, P2, P3 with • P2autoprovision=true

B depends on P1 & P2P1.PCO.ActionID=null



PlanOrderData Model Configuration

P1.PCO.ActionID=PROVIDEP1.PCO.ActionID=HomeMove

There are two planItems:OL=B(UPDATE)• B• P1

B depends on P1

There are two planItems:OL=B(HomeMove)• B• P3

B depends on P3

Sequencing

The product catalog defines the sequencing requirements between the fulfillment steps for various productsin a product offering.

When the order plan is being developed, the information in the product catalog is used such that the instancesequence defined for each sub-product and products which contain these sub-products translates to adependencies between Plan Fragments associated with each product/sub-product and the fulfillment happensin 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 ofback-end systems is utilized in the decomposition to ensure back-end (process component) are called in thecorrect 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 productsuse the provide instance sequence number.

CEASE Sequencing: This scenario occurs when the order line action is CEASE and all the sub products usethe cease instance sequence number.

UPDATE Sequencing: This scenario occurs when the order line action is UPDATE and all the sub productsuse the update instance sequence number.

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



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 setto 2, 1 and 3 respectively. When an order plan is developed, Product B is executed first, followed by ProductA 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 of3, 1, and 2 for products A, B, and C respectively. In this manner, the order may be fulfilled in the correctsequence 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 theproduct 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 AutomatedOrder Plan Development on page 71).



Figure 26: Sample Product Model

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

DescriptionDiagram Element

Product entity.

The arrows represent the ProductComprisedOfrelationship in the product catalogue betweenBUNDLE and a group of products. Thus, thediagrams states that:• BUNDLE is comprised of the product

Broadband.• BUNDLE is comprised of the product VOIP.

The Broadband Product Offering (PO) containsthe following mandatory products:• Telephone• UserID• Line ActivationThe dotted line indicates that the Modem is anoptional product.



DescriptionDiagram Element

The VOIP Product Offering (PO) contains thefollowing 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 themandatory 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 recordattribute set to true with both its parents.

Using (relationship) sequencing, all the child products of the BUNDLE would be fulfilled or processed inparallel, and all must complete before the entire BUNDLE can be fulfilled. Often, additional sequencing isrequired within elements at the same hierarchy level in the model. This can be accomplished by providingsequence 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:

Product OfferingParent Product

UserIDBUNDLE

Telephone/COMBOXBUNDLE

Line ActivationBUNDLE

Modem Installation (optional)BUNDLE

VOIPBUNDLE

BUNDLE Order completeBUNDLE



Delta Provisioning

Delta Provisioning ensures that products which have been defined for 'single use' are not provisioned morethan once for a given order. The combination of the order line action of the products is used to determinehow 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 theorder line actions as PROVIDE then those products are not provisioned more than once. It deletes one of theinstances and ensures that the dependencies point to the single instance, which still remains in the plan. Thisis 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 VOIPrespectively.

If the product exists more than once on the order, then it is only included once in the final plan. If the productexists 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 singleuse set to “True” while B has the attribute set to “False”. BundleB contains 2 sub products A and C. Both thesub 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 actionProvide. Order line 2 contains BundleB with order line action Provide. Both the order lines will contain aUDF 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 dependencyto sub product A and B. BundleB will contain a dependency to sub product A and C. The UDFs will not bemerged into the retained product.

Figure 27: Single use (Provide-Provide)

Cease Single Use



This functionality ensures that if the products have same product ID and have been defined for single usewith their order line actions as PROVIDE and CEASE then those products are not provisioned more thanonce. It deletes instance which has its order line action as CEASE, mark the action as UPDATE and also ensurethat the dependencies point to the PROVIDE instance which still remains in the plan. This is done for productswith the same parent only. Single Use is modeled in product model by setting record attribute single use astrue.

In this scenario the Cease instance of the product will be removed from the plan. Bundle A will have adependency 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 mergedinto the retained product.

The plan fragment as well as the plan description will be set to the Update fragments from the productinformation.

In cases where the sub product A has dependent products all those dependent products will be madedependent 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 usewith their order line actions as PROVIDE and UPDATE then those products are not provisioned more thanonce. It deletes instance which has its order line action as PROVIDE and also ensure that the dependenciespoint to the UPDATE instance which still remains in the plan. This is done for products with the same parentonly.

In the following scenario the Update instance of sub product A will remain in the plan. Bundle A will havea 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 theretained product.

The plan fragment as well as the plan description will be set to the Update fragments from the productinformation



Figure 29: Single use (Provide-Update)

Sequenced Single Use

In this scenario OfferingA contains both BundleA and BundleB which have been sequenced 2 and 1respectively. 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 beprovisioned 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 mergedas 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 productsfrom the Plan. To enable this functionality, set the following flags:1. HierarchySingleUse = true (in AOPD).



2. Merge inventory in AOPD request = true (in the OMS UI Configurator/ Member1/OMS AFIConfiguration/Orchestrator-AOPD Integration Configuration).

The HierarchySingleUse flag needs to be set for the Inventory Single Use functionality to work irrespectiveof Unconditional Removal of products. Unconditional removal of products removes all the child productsof a product deleted due to single use. The MergeInventory flag should be set to true even if products areremoved conditionally for inventory single use.

After implementing these settings, the HierarchySingleUse use case works for SingleUse as well asInventorySingleUse cases.

The HierarchySingleUse global variable is disabled by default (HierarchySingleUse = false) tocontinue with the default implementation. The HierarchySingleUse flag works for all Single Usecases 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 andfulfilled together through the execution of a single plan item. It can be termed as an order fulfillmentoptimization.

Generally, a plan item corresponding to an order line specifies a product to be fulfilled in the order. If anaffinity is specified between the products that are either being fulfilled implicitly as mandatory children, orordered explicitly as separate order lines, the individual plan items are grouped together into a single affinityplan item during plan optimization in AOPD. Thus, the corresponding products are fulfilled through theexecution 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 uponthe 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 responsiblefor populating the UDFs that are associated with these plan items. The potential exists for the same UDF tobe present on different order lines, all values must be available in the plan and the relevant order linesidentified.

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.

Sample Plan ItemData

Sample Order LineData

OutcomeRuleSrNo



UDF Name =ServiceID:1 UDFValue = 1234

Order Line = 1 UDFName = ServiceIDUDF Value = 1234Order Line = 2 Does

UDF name is theoriginal UDF nameconcatenated with theorder line number.

UDF exists on only one of theorder lines being affinity grouped

1

not contain ServiceIDUDF

Value is the originalUDF value.

UDF Name =ServiceID:1,2 UDFValue = 1234

Order Line = 1 UDFName = ServiceIDUDF Value = 1234Order Line = 2 UDF

UDF name is theoriginal UDF nameconcatenated with theorder line number as a

UDF exists on more than one ofthe order lines being affinitygrouped, but not all order lines.UDF value is the same on allorder lines.

2

Name = ServiceIDUDF Value = 1234

comma-separated list.Value is the originalUDF value. Order Line = 3 Does

not contain ServiceIDUDF

UDF Name =ServiceID:1,2,3 UDFValue = 1234

Order Line = 1 UDFName = ServiceIDUDF Value = 1234Order Line = 2 UDF

UDF name is theoriginal UDF name.Value is the originalUDF value.

UDF exists on all order linesbeing affinity grouped. UDFvalue is the same on all orderlines.

3

Name = ServiceIDUDF Value = 1234Order Line = 3 UDFName = ServiceIDUDF Value = 1234

UDF Name =ServiceID:1,2 UDF

Order Line = 1 UDFName = ServiceID

UDF is created foreach unique UDF

UDF exists on more than oneorder line being affinity grouped.

4

Value = 1234 UDFUDF Value = 1234value, with theUDF value is different ondifferent order lines. Name = ServiceID:3

UDF Value = 6789Order Line = 2 UDFName = ServiceIDUDF Value = 1234

corresponding namecontaining the originalUDF name

Order Line = 3 UDFconcatenated with theName = ServiceIDUDF Value = 6789

order line numbers asa comma-separatedlist.

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



As shown in the figure, the InLink affinity can be defined between the Product B and Product C for PROVIDEaction 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 planfragment 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 betweenthem. While order fulfillment process, both these technical products would be installed and configured inone 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 fragmentsare 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.

ExampleDescriptionElement TypeElement Name



Plan fragment canceltype.

String (Optional)planFragmentUniqueId_CANCEL

EP_BUNDLE_CANCELNO_RECIPROCAL_ACTION

Name of the planfragment to execute whencancelling this product.

String (Optional)planFragmentUniqueId_CANCEL/name

Product 1 CancelDescription of the planfragment to execute whencancelling this product.

String (Optional)planFragmentUniqueId_CANCEL/description

Plan fragment providetype.

String (Optional)planFragmentUniqueId_PROVIDE

EP_BUNDLE_PROVIDEName of the planfragment to execute whenproviding this product.

String (Optional)planFragmentUniqueId_PROVIDE/ name

Product 1 ProvideDescription of the planfragment to execute whenproviding this product.

String (Optional)planFragmentUniqueId_PROVIDE/ description

Plan fragment cease type.String (Optional)planFragmentUniqueId_CEASE

EP_BUNDLE_CEASEName of the planfragment to execute whenceasing this product.

String (Optional)planFragmentUniqueId_CEASE/name

Product 1 CeaseDescription of the planfragment to execute whenceasing this product.

String (Optional)planFragmentUniqueId_CEASE/ description

Plan fragment updatetype.

String (Optional)planFragmentUniqueId_UPDATE

EP_BUNDLE_UPDATEName of the planfragment to execute whenupdating this product.

String (Optional)planFragmentUniqueId_UPDATE/name

Product 1 UpdateDescription of the planfragment to execute whenupdating this product.

String (Optional)planFragmentUniqueId_UPDATE/description

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



– itemB parent will be updated with the plan item ID from itemA, thus making itemA dependent to itsown 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 theitems in this case itemB will be deleted from the plan. The dependent items to itemB which are childB1and childB2 are made dependent to itemA. Then itemA is made dependent to parentB which is the parentto 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



The figure depicts an offering which has items that are in parallel as well as in sequence that need to beaffinity grouped. For items that are in parallel they are handled similar to the figure 1. For the item thatis in sequence itemC. It is dependent item offerB is made dependent to CommercialA which is the parentto 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 theAffinitySequnce defined and updated.

To not merge certain udfs during Affinity Sequencing, those udfs should be added as a commaseparated 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 additionalflexibility. Affinity grouping enables different plan items to be grouped together based on the evaluation ofthe XPATH expression defined at the product catalog. The two affinity grouping types are:



Crosslink AffinityInlik Affinity

Affinity groups plan items having the same affinityplan fragment name

Affinity groups plan items having the same parentproduct share a common LinkID UDF value and havethe same affinity plan fragment name

The additional configuration fields and rules in conditional affinity are:

DescriptionField

Determines the type of affinity implemented.AffinityType• InLink• CrossLink• Sequenced Affinity• ConditionalAffinity

Valid for Conditional type only. A String field containing an XPATH expressionthat evaluates to true or false based on data is in the order:

AffinityCondition

• 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 exceptionThe 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

Valid for Conditional type only. The XPATH is evaluated on the Plan data and theorder data. A String field containing an xpath expression based on a data is in thefollowing order:

AffinityCorrelation

• 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 complexconditions without a restriction on the UDF names

• If the field is blank, a default LinkID value is shared by all other blankconfigurations

• If the XPATH expression evaluates to an empty string, the XPATH expressionis 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



DescriptionField

• planItem UDF name value• planItem Action

Valid for Conditional type only. A boolean field containing the value true or false:AffinityParentGroup• 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

Valid for Conditional type only. A boolean field containing the value true or false:AffinityActionGroup• 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 is considered for grouping when AffinityActionGroup is setto true. This is valid for Conditional type only. String field containing an XPATH

AffinityActionValue

expression that evaluates to a String based on data is in the following order: TheXPATH expression must evaluate to one of the following:• PROVIDE• UPDATE• CEASE• Empty StringIf the XPATH expression evaluates to anything other than these actions, then AOPDfails 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 theorder:• 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

Provide plan fragment name for affinity grouped plan item. Only plan items withthe Provide action and the same value in this field are grouped together

AffinityProvide

Update plan fragment name for affinity grouped plan item. Only plan items withthe Update action and the same value in this field are grouped together

AffinityUpdate

Cease plan fragment name for affinity grouped plan item. Only plan items withthe Cease action and the same value in this field are grouped together

AffinityCease

Cancel plan fragment name for affinity grouped plan item. Only plan items withthe Cancel action and the same value in this field are grouped together

AffinityCancel

In the case where plan items with different actions are grouped together due to affinity, the following logicis 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.



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> containingstring $var/PlanItem. For example, if you want to define the XPath for UDF name-value pairMSISDN=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 XPath> containingstring $var/Order. Refer to Sample order XML

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 mapsdirectly to the action of the associated order line that caused the creation of the plan item. In the case whereplan items with different actions are grouped together, the following logic is applicable to determine whataction 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



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:

Order PayloadSample XPATH ExpressionsAttribute

<ord1:udf>exists($var/Order/OrderHeaderUDF[name=UDFNAME

and value="UDFVALUE"])

AffinityCondition

<ord1:name>UDFNAME</ord1:name><ord1:value>UDFVALUE</ord1:value></ord1:udf>

<ord1:line>$var/Order/orderlines[productID=

'Child_A1']/ OrderlinesUDF[name=

'UDFNAME']/ value/text()

AffintyCorrelation

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

Child_B1 and Child_B2 have immediate parent.The two will be affinity grouped when:AffintyParentGroup=true

AffintyParentGroup



Order PayloadSample XPATH ExpressionsAttribute

<ord1:line>$var/Order/orderlines[productID=

'Child_A1']/OrderlinesUDF[name=

'UDFNAME']/value/text()

AffinityActionValue

TheaffinityAction <ord1:lineNumber>1</ord1:lineNumber>

Group must betrue <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 moreproducts must be grouped together through a single affinity plan item for execution but have different parentswhich provisioning must be sequenced in a specific order. The affinity plan item is executed for all parentsirrespectively of the PCO action-based sequencing which breaks product model and could lead to circulardependencies 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 orderswith multiple subscribers contained within the plan.

The sort plan function is defined to sort the plan according to an attribute defined within the order. Thisfunction will make sure that products that belong to similar grouping attributes will follow each other in theGUI.

In scenarios where bulk orders for multiple subscribers are submitted into Fulfillment Order Managementthe subscriber ID will be used as the grouping mechanism. All the order lines will have a UDF defined withthe name SubscriberID. Once the entire plan has been generated all the plan items will be sorted according



to the value for the subscriber ID UDF. This will ensure that all products for an individual subscriber willfollow 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 anywayalong the order. E.g. We can define that Copper Access or Fibre Access process component should only bein 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 trueor false. The logic could either be for a check of the UDFS or an existence of a particular product withinthe 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 thesubscriber can specify during order entry. In our figure above this will be the fulfillment of Product “E” orProduct “F”. The bundled offering will have an associated characteristic named “AccessType” where thevalue can either be “E” or “F”. For the fulfillment of access type E or F a unique execution plan will begenerated. 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 determinewhich 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”. Thedecomposition engine will process this characteristic and determine which branch in the product hierarchyis required for the final execution plan. If in our order access type “E” is specified then branch “F” will notbe included in the execution plan and “E” will be included. If access type “F” is specified then “E” will notbe included in the execution plan.

XPath for attribute based decomposition can be used against the UDFs. The UDFs can come from orderlineor from product model characteristics. AOPD configuration flag "includeproductmodelcharacteristics" is



used to include product model characteristics for xpath execution. By default product model characteristicsare not considered.

By default all the orderlines from the order will be considered to check against whom the Xpath should beexecuted. Conditionally it can also be made to execute only against the orderline from which product is beingdecomposed. AOPD configuration "includeonlyproductorderline" needs to be set to true in this case. Bydefault its false.

The xpath expression is relative to the element "Product". A sample xpath isexists($var//Product[udf[name='AccessType' and value='copper']])

ProductDependsOn and ProductRequiredFor Relationships

ProductDependsOn relationship: The ProductDependsOn (PDO) is a product dependency relationship tosequence the associated target and source plan items. The PDO relationship allows flexible productdecomposition. This establishes a relationship between two products and is evaluated during the decompositionprocess.

ProductRequiredFor relationship: The ProductRequiredFor (PRF) relationship is a prerequisite relationshipfor a product to add a target plan item.

The ProductDependsOn (PDO) and ProductRequiredFor (PRF) relationships enable you to create productoffers without defining sequencing for the products. You can create ProductDependsOn relationship to lowerlevel products instead of using ProductComprisedOf links.

The PDO functionality provides a base behavior that permits to sequence plan items corresponding to productsrelated 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 productsrelated 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 extendedcases 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. Bydefault 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 overridethis 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 flagfor validation. Based on validation flag, AOPD adds product configured with the PRF relationship in theplan.



The PDO relationship also has the third relationship attribute named 'sequenceDirection'. The valid valuesof this attribute are either 'AFTER' or 'BEFORE'. This attribute will be paired with the provided values ofSourceAction and TargetAction. For each SourceAction and TargetAction, there will be a value defined forthe 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 thefunctionality works as it did before the introduction of sequenceDirection relationship attribute. This allowsbackward compatibility.

The value defined in the sequenceDirection attribute will create a dependency of the target product on thesource 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 dependencyon the PDO target product by default. If there is a need to override this default behavior and set the dependencyof 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 optionalproduct characteristic DECOMPOSITION_REQUIRED_FOR.

ProductRequiredFor relationship can be made conditional using XPATH statement stored in optionalproduct characteristic DECOMPOSITION_DEPENDS_ON.

Source and Target Attribute Values

The following table describes the different possible combinations:

TargetActionSourceAction

PROVIDEPROVIDE

UPDATEPROVIDE

CEASEPROVIDE

CANCELPROVIDE

PROVIDEUPDATE

UPDATEUPDATE

CEASEUPDATE

CANCELUPDATE

PROVIDECEASE

UPDATECEASE

CEASECEASE

CANCELCEASE

PROVIDECANCEL

UPDATECANCEL

CEASECANCEL

CANCELCANCEL



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

PlanOrderProduct Configuration

Two plan item (A and B) do notdepend on each other

OL1=ProductAProduct A has a PRF relationship withProduct B having source action andtarget action PROVIDE and PROVIDE

planItemA depends on planItemBOL1=ProductA(Action=Provide)OL2=ProductB(Action=Provide)

Product A has PRF and PDOrelationship with B and PRF and PDOhas source action and target actionPROVIDE and PROVIDE

planItemA depends on planItemBOL1=ProductAProduct A has PRF and PDOrelationship with B and PRF and PDOhas source action and target actionPROVIDE and PROVIDE

planItemA depends on planItemBOL1=ProductA(Action=Provide)OL2=ProductB(Action=Provide)

Product A has PDO relationship withB having source action and targetaction PROVIDE and PROVIDE

The following table explains PDO with Sequence direction and their impact on orders and plans.


Two planitem having planItemAdepends on planItemB

OL1=ProductA(Action=Provide)OL2=ProductB(Action=Provide)

Product A has PDO relationship withB having SA & TA as PROVIDE &PROVIDE. SequenceDirection isAFTER.

Two planitem having planItemBdepends on planItemA

OL1=ProductA(Action=Provide)OL2=ProductB(Action=Provide)

Product A has PDO relationship withB having SA & TA as PROVIDE &PROVIDE. SequenceDirection isBEFORE.




Three planitems having planItemAdepends on planItemB and planItemCdepends on planItemB

OL1=ProductA(Action=Provide)OL2=ProductB(Action=Provide)OL3=ProductC(Action=Provide)

Product A has PDO relationship withB having SA & TA as PROVIDE &PROVIDE. SequenceDirection isAFTER. Product B has PDOrelationship with C having SA & TAas PROVIDE & PROVIDE andSequenceDirection is BEFORE.

Three planitems having planItemBdepends on planItemA and planItemBdepends on planItemC

OL1=ProductA(Action=Provide)OL2=ProductB(Action=Provide)OL3=ProductC(Action=Provide)

Product A has PDO relationship withB having SA & TA as PROVIDE &PROVIDE. SequenceDirection isBEFORE. Product B has PDOrelationship with C having SA & TAas PROVIDE & PROVIDE andSequenceDirection is AFTER.

Dependent and Sibling Products

TIBCO Fulfillment Order Management provides the ability in the product catalog to indicate that a productis 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 wouldnot add the peer product's children to be included in the subsequent southbound service calls while siblingproduct 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 P8can use the output UDFs of P7 and P6 during the execution provided P7 and P6 have been ordered directlyor indirectly in the order and corresponding process components have been executed.



P3 has a sibling product link to P2. This means that the process component corresponding to P3 can use theoutput UDFs of P2, P4, P5, P6, P7, P8 and P9 during the execution provided P2 has been ordered directly orindirectly 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 definedin TIBCO Fulfillment Catalog or offline model xml. The dependent or sibling link can be defined for a productby creating the Characteristic relationship with one of the above relevant products [as per the scenario] withthe value of RelationshipValue attribute as the comma separated IDs of the dependent or sibling products.

DescriptionName

Dependent product characteristic for PROVIDE scenarioDEPENDENT_PRODUCT

Dependent product characteristic for CEASE scenarioDEPENDENT_PRODUCT_CEASE

Dependent product characteristic for UPDATE scenarioDEPENDENT_PRODUCT_UPDATE

Sibling product characteristic for PROVIDE scenarioSIBLING_PRODUCT

Sibling product characteristic for CEASE scenarioSIBLING_PRODUCT_CEASE

Sibling t product characteristic for UPDATE scenarioSIBLING_PRODUCT_UPDATE

For example, Dependent link for P8 in case of PROVIDE scenario can be specified by creating a Characteristicrelationship 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 itscorresponding value and an update in the value of one needs to be reflected in the other. If an attribute isdeemed as a shared attribute and when the value was passed on the order then during decomposition valueis 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 mergedwith same shared attribute in other products, user needs to define the EvaluationPriority, which indicatesthe 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 thenit checks the EvaluationPriority for the characteristic. If products mentioned on the EvaluationPriority havethe same shared attribute, then the value for the characteristic is taken from the product. If none of the productsmentioned 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 oneproduct 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 thevalue of a UDF, the Process Component calls setPlanItem on TDS mentioning the UDFs to be updated. ProcessComponent sends the following details for the UDF:

1. name - name of the UDF to update2. value - updated value3. 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 indicatesthat Process Component has updated the value from Product model)

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



On the subsequent calls to getPlanItems on TDS (Process Component may make this call to get details suchas UDFs for plan items from TDS), TDS checks if requested plan items have any UDF (i.e. attributes) withtype 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 checksif it contains the UDF with same name and flavor = output. If TDS finds such UDF then value from this UDFis returned. If EvaluationPriority is not defined OR products mentioned on the EvaluationPriority do notcontain 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. Referto Order Submission Process for order submission process. Send new value for the shared attribute in theUDF 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 SetPlanItemRequestservice, 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 anew value, which is reflected in B, thus corresponding value and an update in the value of one is reflectedin 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. START2. END

These milestones represent the starting and the end parts of it. There is a direct dependency between theprocess components due to sequencing of the products in the catalogue. This dependency is of typeEND-to-START, or once a process component is completely executed, then only the dependent processcomponent can start its execution as shown in the following figure:



Figure 39: END-to-START dependency

The process component EP_DEVICE_PROV can start only when EP_SERVICE_PROV is completed andEP_TARIFF_PROV can start only when EP_DEVICE_PROV is completed.

TIBCO Fulfillment Order Management also supports the following complex types of dependencies betweenthe 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 processcomponent in addition to the START and END.

The functionality provides a base behavior that permits plan items to be sequenced corresponding to productsrelated 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 productsrelated 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 andextended 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 LINKIDdefined.

• An MDO related parent product that has no LINKID defined and is related to a child product instancethat has no LINKID defined shall be also related to MDO related child product instances that have aLINKID 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



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 intermediatemilestones 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 activatingthe 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. SeeTIBCO® Fulfillment Catalog Product Catalog Guide for newly added repository and relationships to support theintermediate milestones dependencies.

Conditional Milestones Dependency

The dependency between intermediate milestones can be conditional. This is specified using the relationshipattribute called Condition in TIBCO Fulfillment Catalog. It is represented in the product model as illustratedbelow:



Figure 44: Conditional Milestones Dependency

In this sample, the START milestone of EP_PROVIDE_11 is dependent on MILE1 of EP_PROVIDE_10, onlyif 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 BasedDecomposition.

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 propagatedinto the plan item for that order line.

• Child: The plan fragment on whose milestone a milestone in another plan fragment depends. The childUDF will be referred to a UDF passed in the order line in the order for that product which will bepropagated 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 SyntaxValue: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 thecondition as "ExpectedValue".

Child UDF SyntaxValue: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 thecondition as "ExpectedValue".

Match Parent-Child UDF SyntaxMatch:ParentUDFName=ChildUDFName

The condition is satisfied only if the value of the UDF [ParentUDFName] in parent plan item is equal to thevalue of the UDF [ChildUDFName] in child plan item.



Order Amendment

Order Amendment allows the order, that is currently being fulfilled, to be modified for different parameterssuch as action, requiredByDate, and UDFs in the existing order lines. It also allows adding a new order linein 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 orderline. The bandwidth in the original order was 1 Mbps. When the order was being fulfilled, the customerrequested the bandwidth to be updated to 2 Mbps. This is done by sending an amendment request bychanging 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:

If the order is amended in these states then it is calleda pre-plan development amendment, because the

START

SUBMITTED execution plan has not yet been created. In thisFEASIBILITY scenario, the execution plan generated for the

amendment request will be considered and executed.OPD

PREQUALIFICATIONFAILED

If the order is amended in these states it is post-plandevelopment amendment, because the execution plan

EXECUTION

SUSPENDED was already created and had begun execution. In thisERROR_HANDLER scenario, the existing plan requires modification and

merging with the plan that has been generated as perthe amendment request. Post-plan developmentamendment 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 isadopted. 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 arein EXECUTION state. Based on the implementation of the process components, and the point at which theprocess 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 generationrequest 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 modifythe plan items as per the changes in the amendment request.

4. Based upon the modification rule characteristics defined in the product model, the compensatory planitems are added in the new execution plan to allow the undoing of the tasks that were performed by the



earlier corresponding plan items. If required, the REDO plan items are also added in the new executionplan 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 Orchestratoractivates the SUSPENDED plan and starts orchestrating it as per the latest dependencies.

6. All SUSPNDED plan items will be activated, either for cancellation (cancelWithNoRollback orcancelAndRollback) or resume execution (resumeExecution) by sending the PlanItemActivateRequestmessages.

7. Any compensatory and redo plan items, created during the amendment process, will be executed in thesame way as the regular plan items by sending the PlanItemExecuteRequest messages, so as to eithercomplete 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 requiredto be available in the product model published to FOM. The modelling of these characteristics and relatingthem with the required products, needs to be done in TIBCO Fulfillment Catalog at the design time. Referthe generic steps given below for modelling.

This section covers just the high level modelling steps specific to the characteristics required foramendments. 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 characteristicsmentioned below in generic format. Note that these characteristics are used only in case of the new andimproved UDF modification functionality. Refer the New Characteristics sub-section in OrderLine UDFchange.– 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 moreEPMR_ACTION_* records in the CHARACTERISTIC repository mentioned in point 1 and 2 above. The logicallyvalid value for the RelationshipValue attributes in all these Characteristic relationships can be one of thefour EPMR actions - COMPENSATE, RESTART, COMPENSATE_RESTART, or IGNORE. Refer the Execution PlanModification Rules (EPMR) on page 118 topic for the significance of these four actions. For example, thetechnical 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 moreCOMPENSATE_* records in the CHARACTERISTIC repository mentioned in point 1 above. The logically validvalue for the RelationshipValue attributes in all these Characteristic relationships should be the ID of theplan 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_PROVIDEcharacteristic, 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 asdescribed below:1. Changes at order line level



Action Change - Changing the action in one or more order lines.a.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 levela. 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 typesis allowed for a particular order line in an amendment request. E.g. the action and UDFs cannot besimultaneously updated in an order line. If multiple amendment types are tried simultaneously for an orderline in a single amendment request, an exception with the appropraite code and an appropriate message isthrown. 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 requiredByDatecannot 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 amendmentrequest. That is, action change in one order line and UDF or requiredByDate change in another one can bedone simultaneously.

OrderLine Action Change

In this amendment type, the fulfillment action in an order line can be changed as part of the amendmentrequest. E.g. action was PROVIDE in an order line in the original order request and changed to UPDATE inthe amendment request. Since CANCEL can also be passed as the action in one or all the order lines in theamendment request, order line cancellation and entire order cancellation are the sub-types of this amendmenttype.

OrderLine Cancellation

In order to cancel a particular order line, CANCEL must be passed as action in the amendment request. ThePENDING plan items associated to the order line are directly CANCELLED. Execution Plan ModificationRules are applied on the plan items that were COMPLETE or SUSPENDED before the amendment so as tocompensate them, as per the EPMR action defined in the product model. Once all the associated plan itemsare either cancelled or compensated, the order line is marked as cancelled by changing its status toCANCELLED.

Entire Order Cancellation

In order to cancel the entire order, CANCEL must be passed as action in all the order lines in the amendmentrequest. All the PENDING plan items in the execution plan are directly CANCELLED. Execution PlanModification Rules are applied on the plan items that were COMPLETE and SUSPENDED before theamendment to compensate them, as per the EPMR action defined in the product model. Once all the planitems are either cancelled or compensated, all the order lines and also the order is marked as cancelled bychanging the statuses to CANCELLED. The Execution Plan Modification Rules are applied in case of orderline or entire order cancellation, based on the boolean value (true/false) of the rollback UDF passed in theorder header. The modification rules will be applied if the rollback UDF's value is true, otherwise it will notbe 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.



2. The lineID, productID, requiredByDate, and UDFs in all the order lines in the amendment request mustmatch 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 theexisting 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 redoingthe tasks from beginning.

For any action change in the amendment request other than CANCEL, the EPMR characteristic correspondingto the action in the original plan item, from the product being fulfilled by that plan item, is considered whileapplying the modification rule.

EPMR Characteristic ConsideredOrderLine Action in AmendmentRequest

OrderLine Action in OriginalRequest

EPMR_ACTION_PROVIDEAny, except for CANCEL andPROVIDE

PROVIDE

EPMR_ACTION_UPDATEAny, except for CANCEL and UPDATEUPDATE

EPMR_ACTION_CEASEAny, except for CANCEL and CEASECEASE

On the other hand, if CANCEL is passed as the order line action in the amendment request, theEPMR_ACTION_WITHDRAW characteristic from the product being fulfilled by the corresponding planitem 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 onthe required plan items. See topic Execution Plan Modification Rules (EPMR) on page 118 to understand theeffect of each action.

If the EPMR characteristic to be considered (e.g. EPMR_ACTION_PROVIDE) is not present in thecorresponding product model, COMPENSATE_RESTART will be considered as the default EPMRaction, only if the flag CompensateRestartForNoEPMRChar is set in AOPD configurations. See thetopic 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 planitems are generated, the dependencies in the parent plan items will be updated appropriately. See topicImpact on Dependencies on page 122 to understand how the dependencies are modified. The amendmentplan 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 mentionedat both the order header level or/and the order line level. In terms of dependency in the order plan, it generatesa 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 Followingis 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



• If requiredByDate is set on the order header level and on the order line level, the following behaviourapplies:– 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 itsFINAL stages as mentioned earlier. The following matrix defines the conditions to identify a RequiredByDatechange amendment type:

IsAmendmentNew line dateNew header dateOriginal line dateOriginal headerdate

Nopast dated butgreater thanoriginalheader date

past dated butgreater thanoriginalheader date

Past DatedPast Dated

Yes, for thatparticular OrderLine

Future DatedSame as originalPast DatedPast Dated

Yes, for all orderlines

Same as originalFuture DatedPast DatedPast Dated


Same as originalBack DatedPast DatedFuture Dated


Same as originalFuture date thanoriginal

Past DatedFuture Dated

NoSame as originalSame as originalFuture DatedPast Dated

Yes, for all orderlines. The time

Future DatedFutrure DatedPast DatedPast Dated

dependency will becalculated asexplained earlier.

NoSame as originalBack datedPast DateNo Date

NoSame as originalBack datedFuture DateNo Date

Yes, for all orderlines. The time

Fuutre DatedFuture DatedNo DateNo Date

dependency will becalculated asexplained earlier.

The default behaviour in 2.1.1 for required by date change is not to create compensation or restart any planitems. Below matrix defines the amendment behaviour based on plan item status

DescriptionPlan Item Status

Plan item dependency time will be updated so the plan item triggers at the amendedrequired by date.

Pending

Not permitted. Any required by date changes are ignored. As the plan item is alreadystarted, it is not possible to change the start date.

Suspended



DescriptionPlan Item Status

Not permitted. Any required by date changes are ignored. As the plan item is alreadycompleted, it is not possible to change the start date.

Complete

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 theircorresponding UDFs. All other attributes remain unchanged. FOM will be able to identify if the orders havechanged 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, whereUDF 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_ATTRUDF 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 followingconditions, 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.



New EPMR Characteristics

Starting with the version number 2.1.0, FOM provides more granular EPMR actions to be configured for UDFmodifications based on the status of the plan items, so as to have more control while generating theCOMPENSATE 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 canbe configured on per Amendment Type and Plan Item Status . The supported values of Plan Item Statusare: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>



Backward Compatibility with FOM 2.0.1

FOM 3.0.0 supports the use of MODIFICATION_IDNETIFYING_ATTR udf to denote the UDF being changedthrough the use of a flag. This flag , called EnableModificationIdentifyingAttribute, can configured fromFOM 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 haveany impact on the existing plan in terms of the creation of compensatory and redo plan items. Therewill be no changes in the dependencies between the plan items either. However, the amendment planwill contain the updated value of the UDFs. The plan items which go into EXECUTION postamendment will be able to get the updated value of the header level UDFs using GetPlan JMS datainterface or GetOrderExecutionPlan service.

OrderPriority Change

The orderPriority change in an amendment request doesn’t have any impact on the existing plan in terms ofthe creation of compensatory and redo plan items. There will be no changes in the dependencies betweenthe plan items either. However, once the amendment plan is activated, the updated value of the orderPriorityis passed as JMSPriority in all further outbound JMS messages corresponding to that order so as prioritizethe 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 fulfilthe additional products. The plan items corresponding to the newly added order lines are added into theexecution 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 createdplan item for parent product will have a dependency on the existing plan item of the child product.



For example, if B is an optional child product of A, in case of the above mentioned scenario; the newlyadded 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 requestitself. Once the amendment plan is activated, the plan item for the parent product goes into EXECUTIONafter the plan item for child product is successfully completed. If the plan item for child product wasalready 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 theoriginal request and the child product is then ordered in a new order line in the amendment request, thedependency of the child plan item is added based on the status of the parent plan item, as explained inthe 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 planitem 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_PROVIDEcharacteristic is referred.

b. Or the required EPMR characteristic is missing in the product model and theCompensateRestartForNoEPMRChar flag is enabled in AOPD configurations.

See Execution Plan Modification Rules (EPMR) on page 118 for details about EPMR actions. Thedependency of the child plan item will be added into the newly created REDO plan item for the parentproduct. Once the amendment plan is activated, the newly added plan item for the child product goesinto EXECUTION. After it is successfully completed, the REDO plan item for parent will go intoEXECUTION.

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 mustmatch with those in the original order request.

Unlike addition, the deletion or removal of an existing order line is not allowed and supported in anamendment request. For cancelling the fulfillment of the product in an order line, the order line actionshould 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 rulesthat 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 towhile applying the modifications on the execution plan. For UDF change functionality, additional set ofcharacteristics 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 orCOMPLETE 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 particularproduct.



COMPENSATE_RESTART

This EPMR action is assigned as the value of an EPMR characteristic if a compensatory as well as a redo planitem 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 existingplan item before the amendment request was initiated. The important aspect of a compensatory plan itemare 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-4f3382400000and a compensatory plan item is created against it during the first amendment request, the planItemIdassigned 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 assignedon the basis of the action in the existing plan item, which is described in the following table:

processComponentID inCompensatory Plan Item

Action in Compensatory PlanItem

Action in Existing Plan Item

Value of CharacteristicCOMPENSATE_PROVIDE

CEASEPROVIDE

Value of CharacteristicCOMPENSATE_UPDATE

UPDATEUPDATE

Value of CharacteristicCOMPENSATE_CEASE

PROVIDECEASE

If the required COMPENSATE_<ACTION> characteristic (for example COMPENSATE_PROVIDE) is notpresent 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 existingplan item being cancelled, as shown in the following figure. This is to ensure that the compensatory taskshould 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 planitem P1 that will be cancelled

In order to enable the backward compatibility of having no dependency in the compensatory plan itemsin FOM 2.0.x, the flag NoDependencyInCOMPPlanItems must be set in AOPD configurations. Refer topicAmendment 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 andNO_RECIPROCAL_ACTION respectively so as to cancel the existing plan item. Note that the Orchestratorchanges the processComponentID to NO_RECIPROCAL_ACTION only for the PENDING plan itemsthat are cancelled. The processComponentID for the SUSPENSED plan items remain the same.



A compensatory plan item, if requiring creation, is created always against a regular plan item in thefirst amendment. However, in the subsequent amendment requests, it can be created against a regularor 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 anothercompensatory plan item that was created during the last amendment.

Figure 46: Dependency between the compensatory plan item COMP-2_REDO-1_P1 createdduring second amendment and the REDO plan item from the last amendment REDO_P1, whichwill 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 donein the existing plan item before the amendment request was initiated. The important aspects of a redo planitem 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>. Forexample, if the planItemId of the existing plan item is 04ceddc8-60fc-4800-82b9-4f3382400000 and aredo plan item is created against it during the first amendment request, the planItemId assigned to thatredo 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 amendmentrequest.

3. The planFragmentUniqueID (processComponentID) in the redo plan item is the same as the one in theexisting plan item, except in case of order line action change amendments. In such cases, the plan fragmentassociated 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 planitem that is created, as shown in the following figure. This ensures that the designated tasks is restartedonly after the compensatory tasks are finished.

Figure 47: Dependency between the REDO plan item REDO_P1 and the compensatory plan itemCOMP-1_P1

A redo plan item, requiring creation, is always created against a regular plan item in the firstamendment. However, in the subsequent amendment requests, it can be created against a regular ora REDO plan item from the earlier amendments based on the execution plan at that point of time, asshown in the following figure. A redo plan item is never created against a compensatory plan itemthat was created during the last amendment.



Figure 48: Dependency between the redo plan item REDO-2_REDO-1_P1 created during secondamendment 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 isCOMPENSATE_RESTART, only compensatory plan item will be created. There is no need to create a redoplan 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 RESTARTaction is encountered while processing the order line or the order cancellation, no action will be takenon 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 tobe 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 againstan 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 itemthat is going to be activated and cancelled, due to the non-existense of a compensatory plan item as shownin the following figure. This is to ensure that the designated task should be restarted only after the cancellationof the existing task

Figure 49: Dependency between the REDO plan item REDO_P1 and the existing plan item P1, whichwill be cancelled

.

IGNORE

This EPMR action is assigned as the value of an EPMR characteristic, if no explicit action is required to betaken against an existing plan item as part of the amendment processing. In case of OrderLine Cancellationor Order Cancellation, the planFragmentUniqueID (processComponentID) of the plan item is set toNO_RECIPROCAL_ACTION.



No EPMR Characteristic in Product

In case a product model does not contain the required EPMR characteristic, then behaviour of amendmentto generate redo or compensate plan item can be controlled using the flag,CompensateRestartForNoEPMRChar, in AOPD configurations. See the topic Amendment ConfigurationFlags on page 122 for this flag.

Amendment Configuration Flags

The following are the flags available in AOPD configurations to tweak some of the functionalities aroundorder amendments:1. EnableModificationIdentifyingAttribute

This flag, if true, enables the OrderLine UDF modification functionality using theMODIFICATION_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 planitem being cancelled, in the compensatory plan item. The compensatory plan item will immediately gointo 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 redoplan items in case of requiredByDate change (Date Shift) type amendments. This value of rollback udfcontrols 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 EPMRcharacteristics will be consistent with implementation of other amendment types configured for 2.0.x inthis release.

4. CompensateRestartForNoEPMRChar

This flag, if true, considers COMPENSATE_RESTART as the EPMR action in case of the required EPMRcharacteristic not present in the product model. If this flag is false and the required EPMR characteristicis also not present in the product model, no action will be taken on the plan items associated to thatproduct, 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 existingplan items while processing an amendment request, the dependencies in the overall execution plan areimpacted. The dependency on the existing plan item being cancelled is implicitly added in the compensatoryand/or redo plan item when they are created. There can be some additional dependencies in the redo planitems in certain cases. Also, the dependencies in other regular plan items are modified, if required. Thefollowing 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



plan item is removed and a new dependency is added on the REDO plan item, as shown in the followingfigures. The REDO plan item has higher priority over the COMP plan item while replacing the dependencyon the corresponding existing plan item. If the REDO plan item does not exist, the dependency on theexisting plan item will be replaced with a dependency on the COMP plan item. This keeps the dependencystructure 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 theamendment plan

2. If REDO plan items have been created against an existing parent as well as child plan item, then the samedependency is maintained between the corresponding REDO plan items. The parent REDO plan item willhave a dependency on the child REDO plan item, in addition to the dependency on the existing originalplan 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



3. If COMP plan items have been created against an existing parent plan item as well as child plan item, areverse 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. Itis done to ensure that the exact compensation of the plan items, that is, the compensation of parent planitem 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 whichis currently being amended cannot be amended again at the same time. Once the existing amendment requestis 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 thesame way as explained in section Amendments Workflow.

The planItemId assigned to a compensatory or a redo plan item created during an amendment contains theamendment number as one of the prefixes. Refer sections Compensatory Plan Item and Redo Plan Item forthe 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 JMSbroker to deliver the high priority orders to downstream components on priority. The order priority is alsopropagated to downstream process components. The priority value ranged from 0 to 9. The priority informationor priority value to process any given order is set in the JMSHeader field of the JMS message which is sent tothe following Fulfillment Order Management components:• Orchestrator engine• AOPD engine



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 deliveredto the Orchestrator engine or AOPD engine. The priority value can be changed before JMS brokersends the order request to the engines.

Order Schema Changes

The order schema allows you to submit the orderPriority information with the order. The orderPriorityis 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 JMSPrioritymessage 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 ordersmay 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 isreached, EMS blocks message producers when new messages are sent. This effectively slows down messageproducers 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 todefine 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 theplanfragment.

The planfragment is selected based on the PlanFragmenthasCustomAction relationship from theproduct datamodel.



Chapter

3Manual Order Plan Development

If MOPD is enabled and the order has the configured property for identifying the order for MOPD, then the planfor 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


Searching Orders for Manual Order Plan DevelopmentTo 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 theplan shown for editing will be in non-draft mode. The user needs to bring the plan in draft mode in orderto get the options for modifying the plan. All the plan and plan-items will be in START state and milestoneswill be in PENDING state.

5. Click the Draft Plan icon and you will receive options for modifying the plan. There might be a possibilitythat some other user is already accessing the plan and modifying it. In such cases you will be prompted


128 | Manual Order Plan Development

for confirmation on breaking the lock from the other user who is accessing it. If you choose to beak thelock then the unsaved changes of the other user will be removed.


Manual Order Plan Development | 129

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. Create a new plan item2. Create a new milestone3. Delete plan item4. Delete milestone5. Modify plan item6. Modify milestone7. Creating new dependencies8. Deleting dependencies9. 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 optionof 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 productsavailable in the OMS repository.

You can browse through the entire list of products by using pagination or can directly search for the desiredproduct by keying in the product ID in the search box. This search is case sensitive. When you get the desiredproduct in the list, select the product and click the OK button. The selected product will appear in the ProductID text box and all the Action or Owner associated to the selected product will be fetched in the Actiondrop-down box.

If you click on the cancel button in the Product ID popup window, no product will be selected. Either theProduct ID text box will appear blank or the earlier product will be retained in the text box.



As you associate the correct action or owner to the newly created plan-item, Process Info tab and the Sectionstab will be populated for the plan item.

If the originally submitted order consists of an Affinity Plan Item, the products will appear commaseparated in Product Textbox. If the user modifies the product by clicking on the textbox or the iconbeside 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 alreadycreated for the user and you are not allowed to modify these. Values for these UDFs will automatically bepopulated 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 youselect 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 rowwill be created with two dropdown boxes: Order Line and EOL.



Order Line dropdown box contains all the order line numbers in an order. You can select one of the orderlines 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 tothe 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 wantto add intermediate milestones to the plan item then first you need to have correct intermediate milestonesections defined in the plan fragment model. Adding a new intermediate milestone is always dependent onsections (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 planfragment which can be associated to the plan item and if this plan fragment has correct intermediate milestonesdefined then you will be able to create new intermediate milestones. In case there is no intermediate milestonesection defined for this particular plan fragment associated to the plan item then you won’t be able to createany new milestone.

You can confirm the sections which are defined for the plan fragment by clicking the plan item in thetree and selecting Sections tab.



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 IDfrom the available milestone ID list in the dropdown box.

For every intermediate milestone assigning a correct milestone ID from available milestone list and creatingat least one dependency to or from this intermediate milestone is mandatory. Any intermediate milestonecreated should be part of the flow of the plan that is the intermediate milestone must have at least onedependency on it, or from it.

While selecting the milestone ID from milestone ID list, you are expected to select the milestone ID whosesection 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 youhave 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 whilecreating the specified milestone, in this case message shows it didn’t find START – Mile-15-3 section soMile-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 sectionfor 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 thosemilestones.

Select the plan item you want to delete and click Remove.



Delete Milestone

You cannot delete START or END milestone. You can select any intermediate milestone and delete it. Deletingany 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 willsee Add and Delete options in the dependencies tab. When you create a dependency you will be creating aDependent-On type of relationship between the milestones, which means when you select a milestone fromthe tree, as shown in the example START milestone was selected in the tree and while creating the dependency



you are trying to define that this selected START milestone is Dependent-On which other milestone fromother 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, anempty 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 withall 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 thedependency-tree widget you will be able to select all the milestones other than the START milestone. Youcannot create dependency on START milestone.

Select the appropriate milestone from dependency-tree widget and click the OK button. A point dependencyis created in the empty row created earlier.

Creating Time Dependencies

Click on the Add new time dependency icon to create a new time dependency. A date time picker popupwill appear.

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 dependencyis created in the empty dependency row you had created earlier.



If you want to create multiple point dependencies from the selected milestone in the tree then you shouldcreate multiple rows in the dependency table. You can only create a single dependency (point or time) perrow 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 thedependency table shown in the following screenshot:

You can add Time-Dependency only to START milestone and cannot add multiple Time-Dependencies onthe same milestone.

If you are to create more than one dependency on the selected milestone and you don’t have enough milestoneson 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 is shown at plan item or milestone level, along with proper error message on hover of theicon.

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 aplan-item with product BPO_DUO, here BPO_DUO can be associate to any available order line.



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



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 inthe tool bar for the plan. Click Draft Plan in Gantt view and you will be get Add and Remove options on thetop bar of the Gantt chart.

You can perform all the modification options described in section using the Gantt chart option. We have triedto keep the MOPD modifications similar in Grid and Gantt view. There are some differences in how to accessthe edit widgets in Gantt.

Create a New Plan Item

Click planID to select it in the Plan Details column and click the Add icon on the top toolbar. You willsee a popup for filling the details of the new plan item.

Create a New Milestone

Click the plan item to select the plan item in the Plan Details column and then click Add icon on thetop toolbar. You will see the popup for filling the new milestone details.

Delete Plan Item

Select a plan item in Plan Details column and click the Remove icon on the top toolbar and the selectedplan item would be deleted. Deleting a plan-item will delete all the associated milestones and the dependencieson, or from the milestones.

Delete Milestone

Select a milestone in Plan Details column and click the Remove icon on the top toolbar. The selectedmilestone would be deleted. You cannot delete START or END milestone. You can select any intermediatemilestone and delete it. Deleting any intermediate milestone will delete all the dependencies on or from themilestone.



Modify Plan Item

When the plan is in draft mode, you can click the icon in the Actions column corresponding to theplan-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 themilestone 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 creatinga new milestone, or by modifying existing milestone. In the first case the creation of dependency when creatingnew milestone the milestone details pops up. Retrieve the details and visit the Dependencies tab. In thesecond 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 is shown in the Status column of the Ganttchart.



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 casethere are some client side validations then the plan won’t be saved and upon clicking the save icon you willsee an appropriate message. If the plan is saved succesfully then you will see the success message on the userinterface.



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 ofthe plan is saved only when there are no validation errors at the UI side in the plan. The plan is sent forexecution only when server side validations are passed. See TIBCO Fulfillment Order Management Conceptsand 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, theuser1 will have a stale copy of the plan. Hence, when user1 tries to save the plan, a message will appear: Newcopy of plan available in database, please update. Cannot Save the plan. The changes willnot be saved. user1 will have to reload the plan and make the modifications again.



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 presentedwith a confirmation box. Click OK and your changes will disappear and you will be presented with lastsaved copy of the plan. Discarding changes is possible only when the plan is in OPD state in FOM userinterface.



Modifying Plan in EXECUTION StateIn case you need to modify the plan which is already in EXECUTION state, you must submit an orderamendment with MOPD UDF as per the configurations. Order Amendment can be submitted either throughSOAP Service or through User Interface.

Once the order amendment is submitted with appropriate MOPD UDF, the order will remain in SUSPENDEDstate 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.



Chapter

4Jeopardy Management System

This section describes the functions of TIBCO® Fulfillment Order Management Jeopardy Management System

feature.

Topics

• Jeopardy Management System


Jeopardy Management System

Service level agreements(SLAs) are commonly used to ensure the quality of service (QoS). The conventionalway 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 JeopardyManagement module rely on predicting the result of QoS compliance of process components that are part oforder fulfillment eco system. Therefore, it is frequently possible to take corrective action before a problemoccurs, thus minimizing its impact.

Jeopardy Management

The jeopardy management process involve three main activities:1. Monitoring the QoS2. Reporting the QoS3. Predicting the QoS

The objectives of Jeopardy Management are as follows:1. Continuous collection of performance data and status information of all execution plan2. Detect SLA violation3. Predict Jeopardy Conditions for execution plan4. Perform consequential actions

a. Send notificationb. Invoke web service

The Jeopardy Management System enables you to manage the risk associated with plan tasks falling behindschedule, and to prevent them from jeopardizing the timely fulfillment of an order. The Jeopardy ManagementSystem is a key component of Fulfillment Order Management (FOM). Jeopardy management is the processof monitoring execution of a set of tasks in a plan to fulfill a customer order. In FOM, execution plans aregenerated 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 notifiesthe 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 thatplan item. Service-level agreement of service provider that executes plan items are specified through processcomponent model or Plan fragment model which stipulate among other things - the provided Servicesperformance. 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 thefollowing 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 processcomponents. The third type of critical path is based on the actual duration to date, once the execution planhas started processing. The critical paths are used to predict the completion date and time of the executionplan. By viewing the critical paths in the UI GANTT Chart, you can determine whether your executionplan is progressing normally or if it is in danger of being in jeopardy. The OMS UI highlights each planitem 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.


146 | Jeopardy Management System

b. Plan item instance is marked in the HAZARD region, if its execution is started late and delayed thanexpected 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 thanexpected time lines and lies on the critical path. The UI also highlights risk regions of a plan with colorscheme.

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 followingelements 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 thatplan item.

There are two types of milestone dependencies:

Time DependencyPoint Dependency

dependency on a given date and time being exceededdependency on release of a givenmilestone in another plan item inthe plan

Execution of a plan item stops at a milestone until that milestone has been released. A milestone withno dependencies is released immediately. However, a milestone with attached dependencies is onlyreleased once all the point and time dependencies are satisfied.


Jeopardy Management System | 147

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 criticalpaths 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 ofa single execution path. For example:

Figure 58: Plan with Single Execution Path

Some plans have multiple execution paths as shown in the following figure:



Figure 59: Plan with Multiple Execution Paths

Understanding Dependencies

Dependency can be defined as a relationship between milestones in an execution plan. For example, MilestoneB 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, orfinished.

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.

EffectDependency

The milestone must start on the date/time specified. If it cannot started for somereason (for example, because a previous plan task is late), a jeopardy condition istriggered.

Must Start On

One milestone is able to be released when the other milestone is releasedFinish to Finish

One milestone can be released only when the other beginsStart to Finish One

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 isin jeopardy. The jeopardy manager also provides facilities for monitoring whether the whole execution planis running on time, or taking longer to complete than expected. This is done by monitoring the forecast enddate 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 setof jeopardy conditions at plan level.



Jeopardy Management for Plan Task

A simple process component that has only start and end milestones consists only of one section, but morecomplex 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 detectboth if the task has taken longer to complete than it should have, and also to detect if a task that is under wayor 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 durationsof the plan tasks included in those plans. If one of the process component sections being monitored has notcompleted 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 istriggered. For Example, a plan has taken longer than expected/predicted. The plan task has exceeded itstypical duration, its maximum duration, and two subsequent monitoring intervals. A monitor event has beenfired 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



Must Start On Dependencies

The must start on dependency indicates that an activity must start at a specific point in time. You can applythese dependencies to milestones that denote the start of such activities; in normal circumstances, when theexecution plan is running on schedule, these are used to schedule activities at the right time, by releasing therelevant milestones. However, if it is predicted that it is not possible to release a milestone at the scheduledtime, or if that time is reached and the milestone still cannot be released, the Jeopardy Management Systemrecognizes the jeopardy condition.

Predictions are calculated during jeopardy detection cycle. Frequency of Jeopardy detection cycle isconfigurable.

Consequential Actions

Jeopardy Manager raises the jeopardy event. If a plan item is in jeopardy, the PlanItemJeopardy event israised. 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 predictivenotification or the actual notification at the plan level. For example, if the jeopardy sends out a predictivenotification AFF-JM-PLAN-0200 for the Plan to possibly exceed the typical duration, then the jeopardy willnot send out the AFF-JM-PLAN-0100 notification if the plan actually exceeds typical duration, as they arethe notifications for the same risk region.

Jeopardy event message contains payload with information about the jeopardy condition. You can configurethe consequential that you want to perform when these events are raised by the system that configures theJeopardy 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 forjeopardy in the active space data store. Now in FOM, jeopardy has been designed to work in cache (servermemory) 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 availablein the server cache, jeopardy ignores orders that were placed prior to the FOM 2.1.1 implementation, and arestill in the execution status. Hence, it is recommended that all existing orders, placed prior to the FOM 2.1.1implementation, should be in their logical end status, that is COMPLETED, CANCELLED, or WITHDRAWN.

Predictive Jeopardy

Predictive jeopardy is measured on several metrics:

Plan DurationPlan Item Start Date

The overall duration of the plan can be calculated byperforming a critical path analysis on the plan itemsthat compose the plan

For plan item milestones with both point and timedependencies, it is possible that the specified timedependency is not feasible based on the durations ofthe previously executed plan items that form the pointdependencies on the same milestone

Plan duration predictive jeopardy determines whetherthe execution duration of the plan will exceed thedesign duration of the plan

Plan item start date predictive jeopardy determineswhether the plan item will later than the specifiedstart date due to the other dependencies



Jeopardy Events

The following are the types of jeopardy events:

Plan Item Jeopardy

The following table lists the jeopardy conditions for the plan item:

DescriptionPlan Item Jeopardy Conditions

Plan item has exceeded typical durationAFF-JM-PLANITEM-0100

Plan item has exceeded maximum durationAFF-JM-PLANITEM-0110

Plan item has exceeded required startAFF-JM-PLANITEM-0120

Plan item start is predicted to exceed required start and is increasingAFF-JM-PLANITEM-0200

Plan item start is predicted to exceed required start and is decreasingAFF-JM-PLANITEM-0210

Plan item is no longer predicted to exceed required startAFF-JM-PLANITEM-0220

Plan Jeopardy

The following table lists the jeopardy conditions for plan:

DescriptionPlan Jeopardy Conditions

Plan has exceeded typical durationAFF-JM-PLAN-0100

Plan has exceeded maximum durationAFF-JM-PLAN-0110

Plan has exceeded out of scope thresholdAFF-JM-PLAN-0120

Plan is predicted to exceed typical duration and is increasingAFF-JM-PLAN-0200

Plan is predicted to exceed typical duration and is decreasingAFF-JM-PLAN-0210

Plan is no longer predicted to exceed typical durationAFF-JM-PLAN-0220

Plan is predicted to exceed maximum duration and is increasingAFF-JM-PLAN-0230

Plan is predicted to exceed maximum duration and is decreasingAFF-JM-PLAN-0240

Plan is no longer predicted to exceed maximum durationAFF-JM-PLAN-0250

Order Selection for Jeopardy Management

Since Jeopardy Management System is designed to send an alert on the plan tasks that are falling behindschedule, and to prevent the plan tasks from jeopardizing the SLA for the entire order fulfillment, JeOMSmakes 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 theshort running orders (orders expected to finish in 5 minutes or less) will not be helpful as sending alerts toproduction support personnel, and the subsequent manual action on the alerts, will take more time than thelifespan of the order.

Jeopardy, therefore, has a stronger focus on the long running orders (orders that are expected to run for anhour or more). Jeopardy will process almost all the orders, but for short running orders, jeopardy may skipsome alerts that are not expected to be handled when the risk level for that alert changes to a severe one.



Chapter

5Router

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 OMSinstances deployed in the cluster.

5. Router can optionally send only the order id in the payload properties (i.e. the order request is removedfromthe payload). The Orchestrator listener gets the payload with order Request from Activespaces hibernate secondlevel cache after consuming the order request.

Figure 62: Router Diagram


Chapter

6Internal Error Handler

Internal Error Handler marks the failed plan items in ERROR state and gives you the control to select appropriateaction 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 stepprocess: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. Retryb. Resumec. Completed. 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


Internal Error Handler Data Flow Diagram

The following is the data flow diagram for Internal Error Handler:


156 | Internal Error Handler

Understanding Data Flow in Internal Error HandlerThe 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:

DescriptionSuccessComplete

Orchestrator will retry the process component call for the defined numberof retries with the defined retry interval. If the process component call

False/TrueFalseTechnicalError

continues to fail, then it will refer the plan item to the Plan Item FailedHandler.

Orchestrator will refer the plan item to the Plan Item Failed Handler.FalseTrueBusinessError


Steps 1 through 3 are part of existing implementation

4. The orchestrator will invoke the plan item Error Handler according to your configuration. Going forwardthe system will consider that you have configured Internal Error Handler, and refer the Internal ErrorHandler 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 which indicates that the plan item is in ERRORstate.

10. You can access the plan item in ERROR state and take appropriate action on it. Action on the plan itemin ERROR state can be from one of the following options:a. Retryb. Resumec. Completed. MOPD


Internal Error Handler | 157

11. You can take different actions on different failed plan items in the same plan. This would vary only if youhave chosen MOPD as your action for the plan item in ERROR, since MOPD as the error resolution wouldact 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.



Internal Error Handler Sequence DiagramThe following is the sequence diagram to show the actual sequence of the flow of data in Internal ErrorHandler:



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 hasbeen added named Plan Item Status with all the possible values of the plan item.

Modifying the Plan Item StateAfter you have searched the plans with plan item or plan items in ERROR state, you need to select the desiredplan 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 aplan item in ERROR state, it will be shown with an appropriate icon, the icon will represent the plan item inERROR state and needs user intervention.



Choosing Error Resolution for the Plan Item in Error StateAfter clicking the plan item you will get the details for the plan item. This plan item will have Status as ERRORand will have option so that you can choose the appropriate Error Resolution and Comments for the specificplan item.

Error Resolution is a dropdown box that contains actions that you need to perform to fix the plan item inERROR 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 planitem in ERROR state. In case you dont choose the error resolution for some plan items and submit the choiceto the server, then the error resolution will be executed as per your choice for those few plan items and therest of the plan items will still remain in ERROR state.

Details of Each Resolution ChoiceYou can choose any appropriate action from the error resolution drop down box and the error resolutionchosen 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 ErrorResolution 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 choosesa resolution type for the plan item in ERROR state:



Error Resolution - RETRY

When you submit the error resolution with RETRY as the appropriate action, a new Plan Item Execute Requestwill 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 ActivateRequest will be sent for the plan item and the orchestrator will move the plan item state from ERROR toEXECUTION.

Error Resolution - COMPLETE

When you submit the error resolution with COMPLETE as the appropriate action, the plan item will directlybe marked as COMPLETE by the orchestrator. The orchestrator will move the plan item state from ERRORto COMPLETE.

Error Resolution - MOPD

You can select MOPD as the appropriate Error Resolution. MOPD action is treated at plan level which meansif 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 MOPDflag. This would be done in the background without any user intervention as soon as you submit MOPD asthe 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.



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 planitem before it failed. All the other state transitions will remain intact.



Submit the Error ResolutionAfter taking the error resolution on the plan item in ERROR state, you can submit your changes. With errorresolution choice as Retry, Resume, or Complete, you can submit these error resolutions for the plan itemsin ERROR state all in one go, or you can submit each error resolutions for the plan item in ERROR stateseparately.

When you choose error resolution as MOPD for any of the plan item, it would impact the entire plan and notthe individual plan item in ERROR state. So once you choose the error resolution as MOPD for any of theplan item in ERROR state, any other error resolution selection for other plan item in ERROR state will haveno impact. If there were three plan items in ERROR state and for one plan item you have chosen errorresolution as Retry, and for another plan item, which is in ERROR state, you have chosen as Resume, andfor the third plan item you chose MOPD as error resolution, then the resolution type for first two plan itemswill 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.



Chapter

7State Machine Pagination

A state machine is initiated for every order submitted. With large number of state machine in heap memory thereis possibility that the application may go out of memory. To control the memory usage of state machine, it isnecessary 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 ascom.tibco.fom.orch.intervalMonitoring. Within this interval before the eviction process starts it ispossible that number of state machines in memory exceeds the threshold configured depending upon theorder 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 waitsuntil the number of state machine is less than or equal to the threshold configuration defined. Once theeviction cycle completes and state machine counts is below the threshold defined further requests will beprocessed.

3. As part of every eviction cycle, the application will try to find out the least used object. The application identifiesa timestamp that can be used as a threshold called the critical timesatmp and all the state machines withtimestamps smaller than this will be eligible for eviction. Memory Cleanup threads started at time of initializationof orchestrator node runs at a predefined interval to identify the state machines which are eligible for evictionlooking at the timestamp of all the state machines. State machines which are idle for more than the configuredidle time out are selected for eviction till the count of state machines matches to the configured threshold numberwhich can live in memory. To identify state machine for eviction, first timestamp of all the state machines aresorted in ascending order and then ignores the same no of state machines configured as threshold count havinghighest timestamp value. Out of these timestamps which have the highest timestamp and count remains withinthreshold is selected not to be evicted; the smallest timestamp is selected as critical timestamp. Any state machinehaving timestamp smaller than the critical time stamp are eligible for eviction. To evict a state machine frommemory, an event is submitted to respective state machine or BatchProcessor to clear the state machine entryfrom memory.

4. For any subsequent request, if state machine is not available in memory then state machine information will beretrieved back from backing store using the data stored as state machine context checkpoint. Using this checkpointdata, all the required data will be populated and a state machine entry will be created in memory for furtheruse.

5. A cleanup thread keeps running after some interval which removes the state machine context checkpoint dataalong 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


State Machine Pagination Sequence DiagramThe following diagram represents the State Machine Pagination Sequence Diagram:


166 | State Machine Pagination

State Machine Pagination Flow DiagramThe following diagram represents the State Machine Pagination Flow Diagram:


State Machine Pagination | 167

Chapter

8Order Capture System Overview

Order Capture System (OCS) is a new component in TIBCO Fulfillment Suite to create, manage, and submit TIBCOFulfillment 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 FulfillmentOrder Management.

Topics

• Order Capture System User Interface 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


170 | Order Capture System Overview

Order Capture System User Interface OverviewThis 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 withinthat 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 viewthe 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 ofproducts or bundles and characteristic values. Using the remove icon, you can remove products or bundlesfrom the cart.

After clicking CHECKOUT, you can see the Edit order option. Using the Edit order option, you can addorder 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 buttonto submit the built order to TIBCO Fulfillment Order Management.


Order Capture System Overview | 171

Searching for SubscribersLog 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 aprevious 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, orcancel 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 themagnifying glass.



Submitting an Order in OCSSelect a subscriber, browse TIBCO Fulfillment Catalog, customize an order for the selected subscriber, andsubmit 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 SearchSyntax 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 themto see the impact on retrieved products.

For example, a subscriber is moving states. Clearing the local area filter can display or hidecertain 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 moreitems to the cart.

6. Optional: Click the shopping cart icon to review your order. From the Shopping Cart page, click theproduct 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 thatOCS 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 samesubscriber.

• CLEAR CUSTOMER SELECTION - Using this feature, you can submit an order for a differentsubscriber.

If you need to make changes to a submitted order, see Amending an Order in OCS on page 174.



Amending an Order in OCSAmend 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 onpage 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 orderis complete or cancelled, you can only view order details.

4. View order details, modify, or add a product.

– View order details1. Click View order details to see all the details associated with that specific order on a read only

screen.

– Modify an order1. 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 product1. 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 . This must be clicked to compare orders. Click COMPAREto review the changes made.

The "Compare orders" window does not show price details for the original order to avoid displayingan incorrect price. Pricing models within OPE could have been changed and reloaded during theamendment.

6.

Optional: Hover over the item, to see the edit and remove icons. If you click theedit icon, you can change quantity of products or bundles and the characteristic values. If you click theremove icon, you can remove products or bundles from the cart.

7. Click CHECKOUT.



8.Optional: Hover over the product or bundle, and click the edit icon to edit any order details suchas priority, delivery date, and notes, and click Save.

9. Click PLACE ORDER.

After you click PLACE ORDER, you see the Confirmation screen. This screen is displayed to indicate thatOCS 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 samesubscriber.

• CLEAR CUSTOMER SELECTION - Using this feature, you can submit an order for a differentsubscriber.



Canceling an Order in OCSCancel 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 onpage 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.



Order Capture System Error Codes and MessagesMessages returned by the software consist of a code and an associated message.

The following table lists the error IDs and their descriptions.

DescriptionError MessageError Code

The server is not responding to theGUI. "no server" indicates that anerror code cannot be returned.

The server is not responding.

Please try again later.

no server

The server is not responding.


1

Every 15 minutes you areautomatically logged out of the

Your session has timed out.

Please sign in again.

401

system. Log back in with your IDand password.

Enter a valid email or password.The username or password you

entered is invalid.

10002

The HTTP session is invalid. Thismay happen if you are still on a

Your session has expired.

Please sign in again.10003

page when the session has expired.Sign in to log back into the system.

An HTTP request to the server isinvalid as per server authentication.Sign in to log back into the system.

Your request is invalid.

Please sign in again.

10004

This indicates failure to access theSubscriber Inventory. Reasons

There's a problem accessing

the subscriber inventory.


20000

might be network problem,configuration problem on thecurrent application, configurationproblem on the remote app, orimplementation problem (bug).Retrying later might solve theproblem depending on the problemnature.

There's a problem retrieving

the pricing info. Please try

again later.

20100


the eligible products. Please

try again later.

20101

There's a problem submitting

or modifying this order.


20102


the plan preview details.


20103



DescriptionError MessageError Code

There's a problem rebuilding

the product/bundle hierarchy.

20104

Are the catalogs used in OCS

and in the order you want to

display the same?

There's a problem accessing

the subscriber item

20200

inventory. Please try again

later.


the plan preview details.


20201



Search SyntaxThe search input supports complex searches and is case sensitive. You can use this feature to search forsubscribers 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, suchas "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 yousearch 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 anycombination 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 amountof 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'.



Chapter

9Offer 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


Offer and Price Engine Product ModelOffer and Price Engine (OPE) uses the same offline models schema currently being used by the TIBCOFulfillment Order Management engine. OPE uses the product models to get the offers configured in theproduct catalog.

In terms of the OPE engine, the top level product has no autoprovisioned parents associated with it. All suchproducts are considered as a product offering. All such products are considered as a product offering. Usingthe 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 TIBCOFulfillment Order Management set up. The models can be made to load in the engine using the offline modelsweb service or the offline poller mechanism. Online integration with TIBCO Fulfillment Catalog is alsopossible using the publish catalog method.

Relationships

OPE makes use of the following relationships for offer generation and validation, and price determination:

DescriptionRelationship

This relationship is used to define the dependenciesbetween the products, which leads to decompositionof a parent and child products.

Product Comprised Of

This relationship is used to associate the characteristicentities with a product. In addition to characteristics

Characteristic

that are fulfillment related, some internalcharacteristics are used by the product for internallogic. These are related to error handling. For example,a characteristic called DECOMPOSITION is used tofilter out certain products when a condition is met,which could be based on data from the incomingorder request.

This relationship defines that two products can existin an order or customer image.

Compatible Product

This relationship defines that two products cannotexist in an order or customer image.

Incompatible Product

This relationship defines that a product is compatiblewith the segment. A product can either be compatible,

Compatible Segment

incompatible, or not related with the segment. If aproduct is defined as both compatible andincompatible in the model, it is considered as acompatible product. Segments are grouped bysegment type.

This relationship defines that a product isincompatible with the segment type and name.

Incompatible Segment


182 | Offer and Price Engine


This relationship can be used to classify products intodifferent logical types.

Class and Subclass

This relationship is used to define the prerequisitebetween two products. This relationship allows you

Product Required For

to create offers without defining the sequence ordependency between products. These products areimplicitly provisioned with the parent.

This relationship defines that a product belongs to acategory. A product can belong to no categories, onecategory, or to many categories.

Category

Record or Relationship Attributes

This engine uses the following record attributes and relationship attributes:

DescriptionAttribute

This record status characteristic indicates whether therecord is active or not.

RECORD_STATUS

This record level attribute indicates whether theproduct is an eligible product for the requested orderdate if it is after the start date.

Start Date

This record level attribute indicates whether theproduct is an eligible product for the requested orderdate if it is before the end date.

End Date

This a type field in the characteristics that defines thelinking attributes, for example, subscriber ID or any

Link Definitions

other characteristic between two products. TheLinkDefinitions are evaluated for the followingrelationships:• ProductComprisedOf• ProductRequiredFor• ProductRequiredFor• IncompatibleProducts

If LinkDefinitions are provided for relationships thenthese values must match with the values for UDFsfor the corresponding products in the offer and theorder request.

Filters

OPE uses the following filters to get the initial list of eligible products, which are then validated through thenormal process of eligible products evaluation:


Offer and Price Engine | 183

DescriptionFilter

The focus filter considers the products that are presentin the basket, or order to get the initial list of eligible

Focus

products. If the focus filter is present, the rest of thefilters are ignored. Because the product in focus isalready present with the customer, the optionalproducts for the selected focus is used as the initiallist of eligible products.

The products in promotions filters are directly usedto get the initial list of eligible products. If promotions

Promotions

are present, all other filters except focus are ignoredto get the initial list of eligible products.

The segment filter provides a way to get a list ofproducts belonging to the same segment. The

Segment

products are related to segment name and segmenttypes. The initial list of eligible products containsunion of all the products, which include the same anddifferent segment types unless they have anincompatible relationship defined. Any products thatdo not have any compatible or incompatiblerelationships defined are considered to be compatiblewith that segment type.

This filter provides a way to get the initial list of allthe products belonging to the record type specified.

Record Type

This filter provides a way to get the initial list ofproducts belonging to the sub record types specified.

Record Sub Type

This filter provides a way to get the initial list ofproducts belonging to the specified category.

Category

This field sets linking relevant fields and returnseligible products using those fields. This means that

Input Field

it checks for the linkdefinitions from the relationships,such as ProductComprisedOf, ProductRequiredFor,and compatibleProducts. If those linkdefinitions arepresent in the input filter list, the product isconsidered as eligible.

This filter defines the order date for the request. Ifthis is not set, then the engine assumes the currentdate as the order date.

Order Date Filter

Flags

The following flag names are for the get offer request and for the validate offer request:

Get Offer Request Flag Names

validateData



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 relationshipto get the auto provisioned products. The product is not valid if any of its auto provisioned products areinvalid due to the product integrity, segment compatibility, category compatibility, and product validity.

Product IntegrityThe 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.



Segment EligibilityThe initial list of eligible products is checked for segment eligibility with the specified segments. All productsare 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.



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



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 becompatible 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 orderdoes not consist of any dynamic products of any bundle in offer, that product is not eligible.

Data ValidationsData validations does all the data and UDF validations on the offer request and order request and validatesor 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.

DescriptionValidation FlagProperty Name

Validates UDFs attached to theproduct that are defined as input

com.tibco.af.ope.flags.chkrelevantoludfsCheckRelevantOLUDFs

characteristics of the product. Thisfunctionality can be switched onusing the configuration.

Validates mandatory characteristicsattached to the product model that

com.tibco.af.ope.flags.chkvalidoludfsCheckValidOLUDFs

are found in the corresponding



DescriptionValidation FlagProperty Name

product instance as UDFs in therequest. This functionality can beswitched on using the configuration.

Validates mandatory linking UDFsthat are attached as UDFs to the

com.tibco.af.ope.flags.chkvalidlinkudfsCheckValidLinkUDFs

product in the order request. Thisfunctionality can be switched onusing the configuration.

Validates the UDFs datatype. Thedatatype can be configured in the

com.tibco.af.ope.flags.validateudfdatatypeValidateOrderLineUDFsDatatype

product model. The following arevalid values: Currency, Digits, Date,Time, and Boolean

Validates the orderline UDFs arewithin the range specified in the

com.tibco.af.ope.flags.validateudfrangeValidateOrderLineUDFRange

corresponding product model. Thisfunctionality can be switched onusing the configuration.

Validates the orderline UDFs have thevalues per the regex. This

com.tibco.af.ope.flags.validateudfregexValidateOrderLineUDFRegex

functionality can be switched onusing the configuration.

Get Offer CompatibilitiesThe products in the offer must be compatible with the category, input field, record type, record subtype, theexisting 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 consideredeligible. 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 aremultiple record types or record sub types, the products must belong to at least one of the types and sub typesspecified.

Product Compatibility

All the products in the offer must be compatible with all the products in the order. If there is no explicitincompatibility defined, the product is compatible. Compatibility checks with all the autoprovisioned productchains in the orderline product and the offer product. If there are no compatible products, then OPE checksfor 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 orderand the product in offer (not all products in offer). The attribute SingleUSE is from the product modelcharacteristics that is used for this functionality.

Group and Record Evaluation

The group and record constraint of ProductComprisedOf and ProductRequiredFor are evaluated for all theeligible products with the customer order to check if the eligible product for the customer order does notviolate the group constraints present in the product model. Eligible products are not checked with each otherfor group and record violation. For more information on the group and record attributes, see Group andRecord Constraints on page 190.

Validate Offer CompatibilitiesThe products in the offer must be validated with segment compatibility, product compatibility, group levelcompatibility, and record level compatibility.

Segment Compatibility

All the products in the offer must pass the segment compatibility validation. If any product does not passthe 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 explicitincompatibility defined, the product is compatible. Compatibility checks with all the autoprovisioned productchains in the orderline product and the offer product. If there are no compatible products, then OPE checksfor migrations in the product, as well as consequential products. All the eligibility rules need to be appliedin 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 orderand the product in offer (not all products in offer). The attribute SingleUSE is from the product modelcharacteristics that is used for this functionality.

Group and Record Validations

The group and record constraint of ProductComprisedOf and ProductRequiredFor are evaluated for all theeligible products with the customer order to check if the eligible product for the customer order does notviolate the group constraints present in the product model. For more information on the group and recordattributes, see Group and Record Constraints on page 190.

Group and Record ConstraintsGroup 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 forthe 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.



• groupMin specifies the minimum number of products that must be ordered for a bundle.• groupMax 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 offerrequest 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.



Offer and Price Engine Price ModelOPE uses the price models to get the prices configured in the price catalog and correlates these prices to agiven product based on relationship.

Price models can be loaded in the engine using the offline or the online integration, or both online and offlineintegration 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 onintegrating the price models online, see Integrating TIBCO Fulfillment Catalog Discount Model Offline onpage 201.

Pricing Fields

The following pricing fields are the basic fields applicable to all price types.

DescriptionPricing Field

This field defines the price type of the price. Validvalues are TARIFFUSAGE, USAGE, FIXED,

RECORD_TYPE

RECURRING, COMPOSITE, ONE_TIME, andMIGRATION_FEE.

This characteristic defines if a price is valid. If it is setto true the price is used for the calculation. If not, theprice is ignored.

Record Satus

These characteristics are used to define the validityof a price in a certain time frame. None of these fields

Start Date/Start Time, End Date/End Time,Duration/Duration UOM

are mandatory. If the End Date/End Time is notpresent, it is calculated based on the Start Date/StartTime and the Duration/Duration UOM if they arepresent. Duration UOM can have Year, Month, Weekand Day as valid parameters. If only Start or Endparameters are defined, only that boundary is takeninto account to verify the validity of that price.

This characteristic is used to specify the amount in adot separated manner.

Charge Value

This characteristic is used to specify the type ofcurrency for the price.

Currency

This characteristic is used if a product providesseveral prices, whereby the priority provides the

Charge Priority

system a way to choose which charge to bill thecustomer. Therefore the price with the higher ChargePriority is taken. Lower the number the higher thepriority.

This field attributes the minimum amount a price canhave. If a price is reduced by multiple discounts, it is

Min Amount

possible to reduce the price to a negative amount. The




MinAmount attribute prevents that as it sets theamount to the specified value if the prices value fallsbelow that limit. In the end, all kinds of price anddiscount selections are done and all discounts, whichare attached to the price, are returned even, if theyhave not been applied due to the MinAmount.

Price Types

The following pricing types can be used in the OPE Price Model:

DescriptionPrice Type

This type specifies a non-recurring (one-off) chargingelement defined as fixed monetary values. This is

ONE_TIME price

modeled as a One-Time Price. One_Time prices arecreated by setting the Class to 'ONE_TIME'.CHARGE_PER, CHARGEMINBOUNDARY andCHARGEMAXBOUNDARY are not used.

This type specifies recurring charging element definedas monetary values. This is modeled in TIBCO

RECURRING Price

Fulfillment Catalog as a RECURRING price. Recurringprices are created by setting the class to RECURRING.

Prices with Boundaries should not be attacheddirectly to a Product. The reason is that it isnearly impossible to distinguish if the Pricesshould coexist for a Product or if they ruleeach other out. In order to accomplish thiscoexistence use a composite price and attachthe according prices with boundaries aschildren to that composite price.

This type specifies a usage based charging elementsdefined as monetary values. This is modeled in TIBCO

Usage Price

Fulfillment Catalog as a usage price. Usage prices arecreated by setting the class to USAGE.

Prices with Boundaries should not be attacheddirectly to a Product. The reason is that it issupported to distinguish if the Prices shouldcoexist for a Product or if they rule each otherout. In order to accomplish this coexistenceuse a composite price and attach the accordingprices with boundaries as children to thatcomposite price.

The composite price is not calculated as a price itselfbut is meant as a container for child prices. This

COMPOSITE

container can be used to reuse existing prices aschildren and put one discount on all these children.



Relationships

Restrictive relationships are used to make a price applicable only to certain compositions of products, segmentsor characteristics in a request. The following table explains the different types of relationships used and theirbehavior.


Prices are attached to a product using theProductPricedBy relationship. This relationship has

ProductPricedBy

an attribute ChargePriority, which specifies thepriority in which the charges should be applied incase there are multiple prices associated. If theChargePriority attribute is equal for several prices, ina case of multiple prices of the same type, prices arechosen based on the restrictions it has. So if there are2 valid prices configured for a product, the applicationtakes the price with more and higher valuedrestrictions first.

Choosing a mechanism is only performed forprices of the same class attached to the sameproduct. For example, ONE TIME prices willnot be compared to RECURRING prices.

The PriceRequiresSegment relationship is used tomodel prices, which should be offered only to

PriceRequiresSegment

customers belonging to a certain segment. Prices canhave PriceRequiresSegment relationships to multipleSegments. In that case, the price only is only taken ifall the segments are passed in the getPrices request.

PriceRequiresSegment relationship isconsidered as the most important relationshipwhen choosing between different prices for aproduct.

The PriceRequiresProductGroup relationship is usedto model prices which should only be offered when

PriceRequiresProductGroup

ordering a certain composition of products. ThePriceRequiresProductGroup relationship is consideredas the second highest after PriceRequiresSegmentrelationship when choosing between different pricesfor a product.

The PriceRequiresProductGroup repository has 3flags in the Scope tab named CalculatedProducts,RelatedProducts and LinkedOnly. TheCalculatedProducts and RelatedProducts flags defineif the RequiresProductGroup only 'searches' inCalculatedProducts and in RelatedProducts passedin with the request. The LinkedOnly parameterdefines if the search is only restricted to otherCalculatedProducts and RelatedProducts sharing thesame defined LinkDefinitions as the one the price




needs to be applied to both products to have the sameSubscriber.

The default values for CalculatedProducts andRelatedProducts is true and false for LinkedOnly, theengine looks for all products specified in the requestunless it is specifically configured in a differentfashion in the RequiresProductGroup. IfLinkDefinitions is not configured, it is set toSubscriberID by default.

The PriceRequiresCharacteristic relationship is usedto model different prices for a product based on their

PriceRequiresCharacteristic

characteristic value. Prices can havePriceRequiresCharacteristic relationships to multipleCharacteristics.

The PriceRequiresCharacteristic relationshipis considered as the least importantrelationship when choosing between differentprices for a product

Prices on a bundle level are either aggregated pricesof the underlying offerings or set directly on the

PriceComprisedOf Relationship for Price and Product

bundle level and ignore the prices of the underlyingofferings. Both product and price can have children,which are aggregated towards the parent. TheSubClass attribute with value Override prevents this,and the price acts as an override. PriceComprisedOfrelationship fulfills these requirements, but thePrice.PriceComprisedOf relationship can be used toreuse multiple existing prices as children and attacha discount on all children by using thePriceAlteredByDiscount relationship on the parentlevel of the containing price. The override behaviorof parent prices are transferred to all child prices. Achild price has to have the same class as the parentotherwise it will be ignored on runtime. In order togroup multiple prices with different types, thecomposite price has to be used.

Integrating TIBCO Fulfillment Catalog Price Models OfflinePrice models can be loaded in to the engine using the offline online integration with TIBCO FulfillmentCatalog. The offline format for price models must conform to the schema used by TIBCO Fulfillment Catalogto generate the models.

Procedure

1. Set the following configurations for OPE to consume the price models offline using poller mechanism oroffline web service.<Category description="Price Catalog Configuration" name="Price Catalog Configuration" visibility="Advanced"><ConfValue description="Use offline price" name="Use offline price"



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 CalculationsAll products in the get prices service are decomposed. Prices and discounts are determined in the offer; thenthe price is calculated.

Product Decomposition

All products defined in CalculationProduct(s), OptionalProduct(s) are decomposed in their auto provisionedchild products. CalculationProducts are decomposed in their optional or non-auto provisioned children. Inorder to identify optional children, the parent product and the child product need to share the sameLinkDefinitions, such as the same subscriber, or certain UDFs. The fields that are taken for the link are specifiedin the ProductComprisedOf relationship. This enables the pricing part of OPE to detect child products. Whensetting LinkedOnly in the ProductRequiredForPriceGroup and ProductRequiredForDiscountGroup, theLinkDefinitions 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 beingsame the weight for the price is decided as per the relationships. The price is determined for the quantitymentioned for the calculation product. This means if the quantity is specified >1 then the price is mappedfor each price type (CLASS) until all the quantities are exhausted for that price type. The price for the parentprice is calculated first. Then the child prices using the pricecomprisedof relationship are calculated for theparent price quantity and are then aggregated towards the parent price. The quantity is reset for each newprice type.

Discount Determination

The discount for the price is determined as per the priority mentioned in the price model using thePriceAlteredByDiscount relationship. In case the priority has the same weight for the discount, it is decidedas per the relationships. The engine determines discounts for each price quantity. Unit discounts are detectedfor the complete quantity of the price. Discounts for child prices are applied before applying the parent pricediscount. Parent Price discounts are applied to the child prices as well.



Price Calculation

After price and discount determination, all prices are resolved by aggregating child price elements up therespective 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 followingconditions:• 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.



Offer and Price Engine Discount ModelOPE uses the discount models to get the discounts configured in the discount catalog and correlates thesediscounts to a given price based on relationship.

Discount Fields

The following discount fields are the basic fields applicable to all discount types.


This field defines the record type of the discount.Valid values are DISCOUNT.

RECORD_TYPE

These characteristics are used to define the validityof a price in a certain time frame. None of these fields

Start Date/Start Time, End Date/End Time,Duration/Duration UOM

are mandatory. If the End Date/End Time is notpresent, it is calculated based on the Start Date/StartTime and the Duration/Duration UOM if they arepresent. Duration UOM can have Year, Month, Weekand Day as valid parameters. If only Start or Endparameters are defined, only that boundary is takeninto account to verify the validity of that price.

The discount value for the discount model.Discount Value

This characteristic is used to specify the type ofcurrency for the price.

Currency

This characteristic is used if a product providesseveral prices, whereby the priority provides the

Discount Priority

system a way to choose which charge to bill thecustomer. Therefore the price with the higher ChargePriority is taken. Lower the number, the higher thepriority.

This field is used if a price has multiple discounts,whereby the priority provides the system a way tochoose which discount to attach. Therefore thediscount with the higher (lower number)DiscountPriority will be taken.

If the DiscountPriority is equal for several discountsin case of multiple discounts attached to a price, thediscount will be chosen based on the restrictions ithas. So if there are 2 valid discounts configured for aprice, the application takes the discount with moreor higher valued restrictions first. For example, forPrice A there are 3 discounts configured. Discount Awithout any DiscountRequires restriction, DiscountB with a DiscountRequiresProduct restriction, andDiscount C with a DiscountRequiresSegmentrestriction. For a getPricesRequest which fulfills the




restrictions of all 3 discounts, then Discount C is takenas it has the highest value restriction. For agetPricesRequest which fulfills only the restrictionsof Discount A and B, then Discount B is taken as ithas the highest value restriction. Multiple restrictionssum up whereby the summed value will be taken forthe determination of which discount to choose.

Discount Types

The following discount types can be used in the OPE Price Model:

DescriptionPrice Type

Percent or Flat is used to define if the discount isaltering a price in percent manner or in a totalreduction manner; valid values are percent or flat.

DISCOUNTUOM

Relationships

Restrictive Relationships are used to make a discount applicable only to certain compositions of products,segments or characteristics in a getPrices request.


The DiscountRequiresProduct relationship is used tomodel discounts which should only be applied when

DiscountRequiresProduct

ordering a certain composition of products. TheProductRequiredForDiscount is used since it followsa different mechanism and offers more flexibility interms of modeling capabilities. Discounts can haveProductRequiredForDiscount relationships to multipleProducts.

All groups need to be fulfilled in order tomake the discount applicable.

The ProductRequiredForDiscount relationshipis considered as the lower important type afterDiscountRequiresSegment relationship whenchoosing between different prices for aproduct.

The RequiresProductGroup repository has 3 flags inthe Scope tab named CalculatedProducts,

ProductRequiredForDiscount

RelatedProducts and LinkedOnly. TheCalculatedProducts and RelatedProducts flags defineif the RequiresProductGroup only 'searches' inCalculatedProducts or in RelatedProducts passed inwith the request. The LinkedOnly parameter definesif the search is only restricted to otherCalculatedProducts and RelatedProducts sharing thesame defined LinkDefinitions as the one the discount




needs to be applied to, for example, if theLinkDefinition is SubscriberID, both products haveto have the same Subscriber.

The default values for CalculatedProducts andRelatedProducts is true and false forLinkedOnly, so the engine will look for allproducts specified in the request unless it isspecifically configured in a different fashionin the RequiresProductGroup.

If LinkDefinitions is not configured, it will beset to SubscriberID by default.

The DiscountRequiresSegment relationship is usedto model discounts which should be offered only to

DiscountRequiresSegment

customers belonging to a certain segment. Discountscan have DiscountRequiresSegment relationships tomultiple segments. In that case, the discount will onlybe taken if all the segments are passed in the getPricesrequest.

The DiscountRequiresSegment relationship isconsidered as the most important relationshipwhen choosing between different prices for aproduct.

The DiscountRequiresCharacteristic relationship isused to model different discounts for a price based

DiscountRequiresCharacteristic

on a characteristic value of the corresponding product.Discounts can have DiscountsRequiresCharacteristicrelationships to multiple characteristics. In that caseall the restrictions need to be fulfilled in order to makethe discount applicable.

The DiscountRequiresCharacteristicrelationship is considered the least importantrelationship when choosing between differentdiscounts for a price.

This relationship is used to reuse existing discountsas children and apply an aggregated discount basedon the discount amount of the children.

DiscountComprisedOf

A child discount has to have the same discounttype (Percent or Flat) as the parent otherwiseit will be ignored



Integrating TIBCO Fulfillment Catalog Discount Model OfflineDiscount models can be loaded in the engine using the offline or online integration with TIBCO FulfillmentCatalog. The offline format for discount models must conform to the schema used by TIBCO FulfillmentCatalog to generate the models.

About this taskOPE uses the discount models to get the discounts configured in the discount catalog and correlates thesediscounts 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 oroffline 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



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

ResultsPassing this specific segment filter in the eligibility request retrieves Phone1 and Phone3 as eligible productsfor the order because they are compatible with the segment type.

Scenario 2 - Testing with the SegmentCompatibleWith RecordType FilterSend 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.

ResultsPassing this specific segment in the eligibility request and this specific RecordType retrieves only Phone1because it is compatible with the segment and with the RecordType.



Scenario 3 - Testing with the flag ReturnBundleOfferings EnabledSend an eligibility request when the flag ReturnBundleOfferings is enabled.

Procedure

1. Create a group with Phone1 and SIM_Card as the parent products and Data_Plan as the child product.2. Create another group with Phone2 as the parent product and Data_Plan as the child product.3. Set autoprovision = true for Data_Plan.4. Set the ReurnBundleOfferings = true.5. Add Data_Plan to your order.6. Send a request for all eligible products.

ResultsPhone1, 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=trueSend an eligibility request using the focus filter for products with different types when some products haveautoprovision 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.



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 forsegment and product compatibility.

4. Request eligible products for ProductType = Family and ProductType = PO.

ResultsPassing the specific ProductTypes in the eligibility request retrieves Product 1, Product 2, Product 3, Product4, 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 ReachedSend an eligibility request when maximum number of products in a group is reached.

Procedure

1. Create a hierarchy of products within a group. Name the group Phone Bundle.2. Set the maximum number of instances of the products in the group to two.3. Add two products from the Phone Bundle group to the order.4. Children from the Phone Bundle group are evaluated for eligibility.

ResultsAll the remaining children in the Phone Bundle group are not eligible because the group has a restriction ofmaximum number of two, so only one Bundle Product can be eligible.



Testing Product Validation Scenarios

Test product validation with these nine scenarios.

Scenario 1 - Testing with Maximum Number of Products in a Group is ReachedSend a validation request when maximum number of products in a group is reached.

Procedure

1. Create a hierarchy of products within a group. Name the group Charging Bundle.2. Set the maximum number of instances of the products in the group to four.3. Add five products from the Charging Bundle to the order.4. Send a request of validation for the order.

ResultsThe 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 ReachedSend a validation request when the minimum number of products in a group is not reached.

Procedure

1. Create a hierarchy of products within a group. Create two products in that group: Phone1 and Phone2.2. Set the restriction of a minimum number of one for products within the group.3. Do not add Phone1 or Phone2 to the order.4. Send a request of validation for the order.

ResultsThe validation triggers an error because the group is defined to have at least one element.

Scenario 3 - Testing with the Compatibility RelationshipSend 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.

ResultsDuring 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 SIMcomprised 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 SIMcomprised of SIM_Group which is ProductComprisedOf Option1, Option2, and Option3.



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.



ResultsThe 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 InputSend 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 therequest.

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.



ResultsYou 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 PassedSend 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 ProductComprisedOftwo 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.

ResultsDuring validation when you add both products to your basket, an error occurs because the maximum numberis defined as one.

Scenario 7 - Testing ProductRequiredFor with No Group and One Element Not PassedSend a validation request with no group and one element that is not passed.

Procedure

1. Create a product bundle that has ProductComprisedOf Phone1.2. Set Phone1 ProductComprisedOf SIM_Card.3. Set SIM_Card to have ProductRequiredFor Data_Plan.4. Set Data_Plan with a restriction of minimum and maximum number of one.5. Add Data_Plan and SIM_Card to your basket.

ResultsDuring validation when you add both products (the product bundle and Data_Plan) to your basket, an erroroccurs because the minimum and maximum number is defined as one for Data_Plan, which was alreadyadded to the basket from the product bundle.

Scenario 8 - Testing LinkDefinitions with Restrictions with Maximum Number of ProductsSend a validation request with LinkDefinitions with a maximum number of products restriction.

Procedure

1. Create a parent product called Parent1 with ProductComprisedOf a child product called Child1.2. Define a record level restriction for Child1 of maximum number of one.3. Add group level restriction of maximum number of one.4. In the relationship ProductComprisedOf, define a LinkDefinitions value composed by name and address.5. Add two pairs of one Parent1 and one Child1 with different values for name and address UDFs to the

basket.

ResultsThis validation is successful because each pair has a maximum of one Child1 and defines the name andaddress for both products.



Scenario 9 - Testing LinkDefinitions with Restrictions with Maximum Number of Products in a GroupSend a validation request with LinkDefinitions with a maximum number of products in a group restriction.

Procedure

1. Create a parent product called Parent1 that ProductComprisedOf a child product called Child1.2. Define a record level restriction for Child1 of maximum number of two.3. Add a group level restriction of maximum number of one.4. In the relationship ProductComprisedOf, define a LinkDefinitions value composed by name and address.5. Add one Parent1 and two Child1 with same values for name and address UDFs to the basket.

ResultsThis validation is unsuccessful because Parent1 has two Child1 associated due to the same name and addressUDF values, while just one child per group is allowed.



Chapter

10Fulfillment 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:

DescriptionFulfillment OrderManagement Actions

Viewing Dashboard: View the Fulfillment Order Management Dashboard forsummarized information about:

Orders Panel

Dashboard-specificactions

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

Fulfillment Order Management allows you to:Order-specific actions• View order Details• Search orders• Amend orders• Add orders• Show Plan preview for orders

For details, refer to Orders Page on page 226.


DescriptionFulfillment OrderManagement Actions

Perform the following plan specific actions in the Fulfillment Order Management.Plan-specific actions• View Plan Details• Search plan• View GANTT chart for the plan• Dependency View for the plan

Shows the status and revision history of an object (order or a plan) and FulfillmentProvisioning (FP) logs based on the following criteria:

Activity Log

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

The Rule Config panel allows you to add rule to receive Jeopardy notification onconfigured channel or invoke specific service if order is in jeopardy according to theconfigured condition.

There are two notification types:

Rule Config

1. Service2. Notification

If you choose the 'service' as notification type, provide the service parameters in therespective tab.The notification channels are:1. JMS2. File3. Tibbr4. SMTP

The Catalog panel allows you to view the catalog model associated with the OMS userinterface.

You can:

Catalog

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


212 | Fulfillment Order Management User Interface

• 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


Fulfillment Order Management User Interface | 213

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 URLhttp://<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 FulfillmentOrder Management Dashboard is displayed. For details, see Dashboard on page 219

Figure 65: Fulfillment Order Management Dashboard



Changing Password

Fulfillment Order Management allows you to change your password in the dashboard. To change thepassword: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 newpassword 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.



OMS User Interface Logging NotificationsOMS 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 ofnotifications.

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 BoxAlert and confirmation box ui has been changed to facilitate the user to view on upper center of OMSUI pageirrespective 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:



Growls for Information and Error MessagesInformation and error messages has been removed from the top of the tab and each information and errorwill be shown in growls with respect to their log level.

Growl shown will have fade timeout and can be closed by user.

Notification LoggerNotification Logger lets you view the count of logging notifications as well as their details. You can viewprevious 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 warningmessages 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 ispresent in notification detail window.



• 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 filewith category: com.tibco.aff.



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 richand enhanced information in a format that is easy to read and interpret. The Dashboard is the default viewwhen 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) withuser/role security to manage/view orders.

• A logical structure that makes information easily accessible - Ability to view all orders through graphicalDashboard summary.

• Data displays that can be customized and categorized - Ability to drill-down into order details by settingdisplay preferences.

• Regular and frequent updates of dashboard information for accuracy and relevance - Ability toauto-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 filterlists of existing orders.

The Dashboard allows effective order management with a comprehensive operations view. The informationdisplayed 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



Figure 68: Fulfillment Order Management Dashboard

All the above sections except Backlog Orders by default show the data for the Month. You can changethe 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 correspondingcount of orders.

Summary is displayed in the form of a horizontal bar chart (order status versus number of orders). To seethe details of a particular order status with the list of orders on the Orders page, click on the respectivehorizontal 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.



Auto-refreshing the Interval

Auto-refreshing the chart saves you the time and effort to view the fresh information on the Dashboard. Theinterval 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 arethe different time period parameters based on which you can see the chart data.

Result Data DetailsTime Period

The chart shows the data for the current day.Day

The chart shows the data for the current week.Week

The chart shows the data for the current month.Month

The chart shows the data for the current year.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 timeperiod 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 notyet 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 preferencesare 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 theselected 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.



• Customize the Amended Orders Display Format: The Dashboard allows you to customize the informationdisplay 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 theSubmitted 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 Calendaricon 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 theorder 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 dialogis displayed.

2. Select the column you wish to see to display data in the Amended Orders grid. You can select fromthe following available options:

DescriptionColumn Header

Displays the Order Ref ID column.Show Order Id column

This column is always visible.

Displays the Customer ID column.Show Customer Id column

Displays the Subscriber ID column.Show SubscriberId column

Displays the Status column.Show Status column

Displays the Submitted Date column.Show 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 selectedoption is Month.

2. Click the Save button to save the information and exit the dialog. The data is displayed based on thetime period option you selected. Click the Cancel button to exit the dialog without specifying the timeperiod - 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 amendedorders 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.



2. Click the Save button to save the setting and exit the dialog. You are now set to see the refreshedDashboard for Amended Orders after the interval you have specified. Click the Cancel button to exitthe 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 integratethis with the existing Dashboard components. Current Dashboard user interface has been enhanced andimproved 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+F5to refresh the page.

The following are the Jeopardy panels:• Orders In Jeopardy• Jeopardy Live Alerts• Jeopardy Recorded Alerts

Orders In JeopardyThe 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:

Order reference id of the order in jeopardy. Clickable and takes to order screen.OrderRef Id

Plan Id of the order in jeopardy. Clickable and takes to Plan Screen on OmsUI.Plan Id

The Risk Region comprises below values:Risk Region• 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



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. Thesteps 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 detailsand jeopardy plan details on the Plans page when you click the value in the Plan Id column.

Jeopardy Live AlertsThe Jeopardy Live Alerts panel displays the live alerts from the Jeopardy Manager.

The details of the Jeopardy Live Alerts panel are as follows:

Timestamp details when jeopardy alert message receivedSubmitted Date

If present in the incoming message from Jeopardy Manager, Plan Id of the orderis display under Plan Id column.

Plan Id

If present in the incoming message from Jeopardy Manager, Plan Item Id of theorder is display under Plan Item Id column.

Plan Item Id

Actual text message contents of the alertReal Time JeopardyAlerts

Figure 72: Jeopardy Live Alerts



Select which columns you wish to see by editing the display preferences. To edit the preferences, performthe 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 clearedmessages will be available under Jeopardy Recorded Alerts. The in coming messages are always displayedat 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 selectedplan are displayed on the Plans page.

Jeopardy Recorded AlertsThe Jeopardy Recorded Alerts panel displays the recorded alerts from the Jeopardy Manager.

The Jeopardy Recorded Alerts panel displays the following information:

Timestamp details when jeopardy alert message recorded in OMS serverSubmitted Date

If present in the incoming message from Jeopardy Manager, Plan Id of the orderis display under Plan Id column.

Plan Id

If present in the incoming message from Jeopardy Manager, Plan Item Id of theorder is display under Plan Item Id column.

Plan Item Id

Actual text message contents of the alert received in OMS.Historical Jeopardy Alerts

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 past1 hour (default selected in Edit Preferences), 12 hours or 24 hours. To accommodate newly generated alertsunder 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 aredisplayed on the Plans page.



Orders PageOn 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 fulfillmentprocess.

You can also view the details for initial request and amendments and also take action on the orders. Thefollowing 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 withdrawnorder 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.



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 tokey in the order reference and filters for the search results. The Orders page shows paginated view of searchresults. 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:

DescriptionSearch Criterion

The unique identifier of the order, supplied by the order originator.Order Ref ID

The reference that enables the OMS to retrieve the current customer profileand to identify the customer to other systems interested in the order.

Customer ID

The current status of the order.

The different statuses are:

Status

• START• FEASIBILITY




• OPD• EXECUTION• SUSPENDED• COMPLETE• CANCELLED• WITHDRAWN• PREQUALIFICATION FAILED

The date of order submission.Submitted Date

Fulfillment Order Management, where the orders are created.Originator

AFO or IPC (iProcess Conductor). AFO for fulfillment orchestrator.Fulfillment Engine

Order Id is the internal identifier of the Order generated by OMS.Order ID

The value can be AOPD or MOPD.OPD Source

You can use a combination of search criteria to search for a specific order object. For example, you can selecta status of COMPLETE from the Status column and type the username in the Originator column to find allorders 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 anorder.

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 figurebelow). 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



The Tree View displays the status of the order and each order line. Click an order or order line to display thedetails in the Details View.

If an order has been amended, the Tree View displays the information of the original order and its order linesas 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.


Click an individual order line in the Tree View to display order line level details.




Suspending an Order

When you suspend an order, the Fulfillment Order Management suspends each of the processes that areattached to the execution plan. This means that depending on their current statuses, each of the processesassociated 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 panealong 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


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


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 youwill be given an option to edit the order.

After selecting the edit option, you can perform the following actions before sending the amendment for theorder:• Add a new order line by clicking the Add Line option.



• 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 XMLYou can use OMSUI to submit an order through the Orders tab by either entering the attribute values througheditable 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 valuecom.tibco.aff.omsui.EnableSubmitOrder is used.

Adding an OrderTo 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 .



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

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 atabular list for all the plans in your database repository.

You can even filter plans. For more information, see Searching for a Plan.



This tabular view of plans is supported by configurable pagination. Plans per page can be configuredthrough the OMS configurator. Refer to TIBCO Fulfillment Order Management Admininstration fordetails.

You can click an individual plan in the table and see the details for the plan. Each of these views is displayedin 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 showsa 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:


The unique identifier of the order, supplied by the order originator.Order Ref ID

The unique identifier of the plan.Plan ID

Description of the plan.Description

The current status of the Plan.


Status

• START• FEASIBILITY• OPD• EXECUTION• SUSPENDED• COMPLETE• CANCELLED• WITHDRAWN

The current status of the Plan-Item.


Plan-Item Status

• START• FEASIBILITY• OPD• EXECUTION• SUSPENDED• COMPLETE• CANCELLED• WITHDRAWN• ERROR• ERROR_HANDLER

Fulfillment Order Management where the plans are created.Originator




The date of plan creation.Created On

Date of plan change.Changed On

Order Id is the internal identifier of the Order generated by OMS.Order ID

You can use a combination of search criteria to search for a specific plan object. For example, you can selecta status of COMPLETE from the Status column and type the username in the Originator column to find allplans 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 ViewYou 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 andrepresent the plan-items involved in completing a given plan.

The major difference between the Dependency View and GANTT chart is that GANTT charts emphasize thetime it takes to complete tasks (plan-items), while Dependency view charts emphasize relationships betweentasks (plan items).

The Dependency View chart has the following components:



• 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 itconsists of a start and an end milestone. In case there are intermediate milestones in the plan then there canbe multiple sections in the plan-item. The Dependency view shows all the sections that are present in eachplan-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 isillustrated below:

Dependency Types

Two types of dependencies are displayed in the Dependency View: Point Dependencies and TimeDependencies.

A Point Dependency, illustrated below, is displayed with yellow connecting arrows that indicate a‘dependent-on’ kind of relationship.



Figure 79: Point Dependency

The typical critical path is displayed with red connecting arrows. This path, calculated by the JeopardyManagement System, is the longest duration path that can calculated in the plan. For more information, seethe 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, asillustrated 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 onthe milestone is not yet met, the START milestone will be shown with a GREY color dot, illustrated below:



• If a Time Dependency has a START milestone state of COMPLETE and the milestone was completed onor within the time frame of the assigned time dependency, the START milestone will be shown with aGREEN color dot, illustrated below:

• If a Time Dependency has a the START milestone state of COMPLETE or PENDING and the milestonehas missed the defined time dependency, the milestone will be shown with a RED color dot, illustratedbelow:

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 isused for representing an individual plan-item. Clicking a plan-item description and a plan-item id combinationwill 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.



Figure 87: Help window

Jeopardy Rule ConfigurationThis 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 accordingto a SLA associated with the plan items and plan. Plans are based on a time schedule. When execution ispredicted to violate the schedule, the system raises an event and the user can configure rules to automaticallysend 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 onthe 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 specifiedin 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 asfollows:

The following is the visual representation of the plan item:



The following table lists all the jeopardy events that Jeopardy Management System raises for the Plan Itemjeopardy.

DescriptionPlan Item Jeopardy Conditions

Plan item has exceeded typical durationAFF-JM-PLANITEM-0100

Plan item has exceeded maximum durationAFF-JM-PLANITEM-0110

Plan item has exceeded required startAFF-JM-PLANITEM-0120

Plan item start is predicted to exceed required start and is increasingAFF-JM-PLANITEM-0200

Plan item start is predicted to exceed required start and is decreasingAFF-JM-PLANITEM-0210

Plan item is no longer predicted to exceed required startAFF-JM-PLANITEM-0220

Plan Jeopardy

The plan jeopardy occurs when the execution plan exceeds or is predicted to exceed the following thresholds:



• 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 Itemjeopardy:

DescriptionPlan Jeopardy Conditions

Plan has exceeded typical durationAFF-JM-PLAN-0100

Plan has exceeded maximum durationAFF-JM-PLAN-0110

Plan has exceeded out of scope thresholdAFF-JM-PLAN-0120

Plan is predicted to exceed typical duration and is increasingAFF-JM-PLAN-0200

Plan is predicted to exceed typical duration and is decreasingAFF-JM-PLAN-0210

Plan is no longer predicted to exceed typical durationAFF-JM-PLAN-0220

Plan is predicted to exceed maximum duration and is increasingAFF-JM-PLAN-0230

Plan is predicted to exceed maximum duration and is decreasingAFF-JM-PLAN-0240

Plan is no longer predicted to exceed maximum durationAFF-JM-PLAN-0250



Jeopardy event rules can be configured in the Fulfillment Order Management UI to either send notificationor 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:

ActionConditionGeneral Details

Action to be taken if condition matchesCriterion to be monitored forJeopardy Management

Name, description, status,Event Group, Event Type, etc.

Adding and Configuring Rule

To add a rule, perform the following steps:1. On the Fulfillment Order UI, click Rule Config2. Click Add.

Figure 90: Adding Rule

Only active rules are used to monitor jeopardy condition.

3. Edit the following rule attributes:

Run on Error /Run on FailureDescriptionName

You can set them to true if you want thesystem to execute in spite of a failure or

description of the rulerule identifier

error in an action. A failure is the samething as an error, except it representscommunication failure to the configuredend point.

Figure 91: Rule Attributes



Optionally, you may add condition to the rule to filter specific events with attribute values in eventpayload.

Adding Condition to Rule1. 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 appearas 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:

Right OperandOperatorLeft Operand

The right side of a quantity uponwhich a criteria operation isperformed

Performs calculations on theoperands in a query or anexpression

The left side of a quantity uponwhich a criteria operation isperformed

Select Left Operand, Operator and Right Operand from the Condition Builder to create a condition. Left andRight Operand can be selected from a predefined list of attributes or utility methods. Similarly, Operator canalso 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 listof Attributes/utility methods will appear on right side in Attributes section to select as Left Operand. Anattribute or utility method from this available list can be selected.

Using attributes as Left Operand



Select an attribute from the available list and click the Map icon to assign this value as left operand. Pleaserefer 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 thislist 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:



Figure 95: Utility methods as Left Operand

Values to the input parameters of the method can be assigned using the Edit icon appearing besides methodparameter. When you click Edit, a list of attributes appears on right side and value can be assigned by selectingany attribute. Use Data Input to assign any input value for an input parameter of the method.



Figure 96: Utility Methods

The following table shows supported utility methods with description:

DescriptionMethod Signature

Test if the pattern matches with given text. Parameters: text -java.lang.String to be searched in an effort to find pattern

public boolean wildCardMatch(java.lang.String text, java.lang.Stringpattern) pattern - character or java.lang.String of one or more characters

to be searched for Returns: Returns value true if the given textmatches the pattern and false otherwise

Indicating java.util.Date for specified timestamp in milliseconds.Parameters: inputTimeStamp - milliseconds value as

public java.util.DategetDateFromTimeStamp( java.lang.LonginputTimeStamp) java.lang.Long Returns: java.util.Date object and initializes it

to represent the specified number of milliseconds.

Indicating the day of week for specified timestamp inmilliseconds Parameters: timezone - the timezone (e.g.

public java.lang.Integer getDayOfWeek(java.lang.String timezone, java.lang.String

'America/Chicago') country - the country (e.g. 'US') languagecountry, java.lang.String language,java.lang.Long timestamp) - the language (e.g. 'en') timestamp - the timestamp as

milliseconds Returns: Day of the week as an Integer value forthe timestamp value using the time zone, country and languagespecified

Indicating the day of month for specified timestamp inmilliseconds Parameters: timezone -the timezone (e.g.

public java.lang.Integer getDayOfMonth(java.lang.String timezone, java.lang.String

'America/Chicago') country - the country (e.g. 'US') languagecountry, java.lang.String language,java.lang.Long timestamp) - the language (e.g. 'en') timestamp - the timestamp as



DescriptionMethod Signature

milliseconds Returns: Day of the month as an Integer value forthe timestamp value using the timezone, country and languagespecified.

Select an Operator

To select an Operator, click Edit icon besides Operator in condition section a list of operators with descriptionwill 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 attributesappears on the right side in the Attributes section to select as Right Operand. Select any attribute from theavailable list or input a value by selecting Data Input from Attributes section and click Map icon to assignthis value as the Right Operand.



Figure 98: Selecting Right Operand

4. Click Generate Groovy Method to verify the criteria and generate a corresponding expression



Figure 99: Groovy Method

An expression is generated using the selected Left Operand, Operator, Right Operand and it is displayed inthe Condition Expression section.



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 willbe 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 theCondition Editor using the Delete icon.



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.



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 forjeopardy 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 jeopardyevent.

The frequency for sending alerts depends on the expected behavior of the process component. There areseveral 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 inthe fulfillment system. To add this criteria set following values:

Notification CountEvaluation CountTrue Count

1YX

• Every X times the condition is true in Y evaluations. This sets a number of times that the condition has tooccur in a given number of monitoring evaluations cycles before an action is executed.

Notification CountEvaluation CountTrue Count

1YX



Every X times the condition is true in Y time period.

Time UnitTime ValueNotification CountEvaluationCount

TrueCount

Period((SECOND/MINUTE/HOUR/DAY/WEEK/MONTH))

Y1YX

• No more than X notification in Y time period

Time UnitTime ValueNotificationCount

EvaluationCount

TrueCount

Period((SECOND/MINUTE/HOUR/DAY/WEEK/MONTH))

Y1YX

Webservice Configuration

Add Action

1. Click Add Action.2. Edit the following action attributes:

Dampening Criteria(Optional)

Notification typeDescriptionName

specify any dampeningcriteria to the action

Select Service Parametertab

Select serviceaction descriptionaction identifier

Enter the WSDL location

If WSDL locationis valid, Serviceand Method arepopulated withrespective values.Select a servicename andMethod name tobe invoked

3. Enter the parameter information.

4. Click the Template tab. It shows the web service request parameters in an XML form. This requestparameter can be configured using Template Builder. Click the icon in Template tab to use TemplateBuilder and a popup would appear with a predefined list of parameters.



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 valueswhile 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:



Figure 108: Action Attributes

Dampening Criteria(Optional)

Notification typeDescriptionName

specify any dampeningcriteria to the action

Select notificationaction descriptionaction identifier

-

3. Select Notification Parameter tab4. Select the protocol5. Enter end point URI. The following table shows supported protocols with syntax and example

ExampleURI SyntaxEnd Point Type

jms:queue:jeopardy.notificationjms:queue:<queue name>JMS Queue

jms:topic:jeopardy.notificationjms:topic:<topic name>JMS Topic

tibbr://xyz.tibbr.comtibbr://<hostname:port>Tibbr

smtp://smtp.xyz.com:25smtp://<hostname:port>SMTP

smtps://smtp.xyz.com:465smtps://<hostname:port>SMTPS

file:///opt/notificationfile://<filepath>File

6. Select message type for the notification. The following table shows protocol and supported out messagetype

OutBound Message TypeProtocol

plainStringOutMessageJMS

jsonMessage

javabean

xmlOutMessage

plainStringOutMessageTibbr

plainStringOutMessageSMTP

xmlOutMessage

SMTPS plainStringOutMessage

xmlOutMessage

File plainStringOutMessage

jsonMessage



OutBound Message TypeProtocol

javabean

xmlOutMessage

The following table shows supported out message type:

DescriptionOutBound Message Type

Notification message in plain stringplainStringOutMessage

Notification message in form of json objectjsonMessage

Notification message in form of javabean objectjavabean

Notification message in form of xml stringxmlOutMessage

7. Edit parameters information for selected protocol. The following table shows protocol and respectiveparameters configuration required:

8. Edit Template to configure plainStringOutMessage content using Template Builder. Click icon mentionedin following image in Template tab to open Template Builder screen:



Figure 109:Template

9. Following is the Template Builder screen which has all the notifications parameters listed to configure atemplate for notification messages.

Figure 110:Template Builder Notifications



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 Connection Successful

message is displayed.

If there is any error respective error message is displayed. The following table shows error messages, whichare displayed:



Hot Deployment

Rules configured using OMS UI are hot deployable, therefore Apache Tomcat where Jeopardy ManagementSystem (JeOMS) deployed need not be restarted to activate the rules. Rules configured through OMS UI arepublished to all instances of JeOMS in cluster.

GANTT Chart

You can view the orchestration of an execution plan by using the Gantt chart.



The GANTT chart displays the following objects as a graphical representation on the Fulfillment OrderManagement 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. TheOMS-UI listens to the JEOMS heartbeat and shows the Gantt chart with all the options available. When JEOMSis 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-UIwithin the specified milliseconds, then JEOMS will be considered as un-deployed.

The Jeopardy Detection Publish Topic and Jeopardy Detection Reset Timeout property can be configuredthrough configurator as shown in the below screenshot



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 planand show the Gantt chart

JEOMS when deployed enriches the plan and this enriched plan is used by Gantt chart to plot some of theinformation. 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 ChartThe GANTT chart displays the execution plan as a graphical representation.

Procedure

1. Go to the Plans page.2. Select any plan.

.



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 ComponentsThe 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 BarThe top tool bar changes according to the plan status.

The following table shows the GANTT charts depending upon the plan status:

GANTT ChartPlan Status

COMPLETE orCANCELLED

PENDING andEXECUTION

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



The Zoom options are available for the user according to the difference between plan start date and planend date. For example, if the difference between plan start date and plan end date is more than 1 hourbut 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 changesaccordingly.

• Help: Shows the color coding for the GANTT chart.

Grid HeaderThe Grid Header component shows the ID, Action, Plan Details, Status,START, END, Decedents, DurationConstraint and Description for each grid column

The following table shows the constituents of a Grid Header:

Shows numeric values starting from 1…n.ID

Shows the following Plan information:Plan Details

ConventionType

Plan ID according to the generated plan.Plan

Plan Item description from the plan.Plan Item

Milestone ID. For Example, START or END.Milestone

Merged Milestone IDs with "-" as delimiter. Forexample START-END.

Sections

All the status icons used in this column are similar to icons used in the Plantab grid level.

Status

The start time for each Plan Details.START

The value is in the MM/dd/yyyy HH:mm:ss z format (z stands fortime zone offset).You can configure this value through theConfigurator.



The end time for Plan, Plan Item & Section.END

The value is in the MM/dd/yyyy HH:mm:ss z format (z stands fortime zone offset).You can configure this value through theConfigurator.

The ID value for the next dependent milestone, if any.Descendants

The Date format value showing maximum end value at the section level.Section Maximum End

The Date format value showing typical end value at the section level.Section Typical End

This column contains icons. Clicking icons details for that particular row areshown in a popup window. For example, if you click the icon in action column

Action

at plan level, popup appears with plan details. If you click the icon in actioncolumn at plan item level so popup is shown with plan item details andlikewise.

GANTT Chart Diagram

The following table describes the different GANTT chart components:

DescriptionComponent

Indicates the entire plan, from start till end.Plan Summary Task Bar

Indicates the plan item covering all the milestones and sections of a plan item.Plan Item Summary TaskBar

Represented by a grey diamond.Milestone

Indicates the START and END milestones part.Section

The two forecast types are shown at the section level:Duration• Typical Duration .• Maximum Duration .

Indicates the path with maximum time duration. It is represented by the sectionbar with red border . When you click the critical path option

Critical Path

check-box on the top tool bar, only the critical path is shown with red bordersections.

Shows the details of the respective GANTT item when you place the cursorover any GANTT chart items, for example, plan, plan item, section, milestone,typical or maximum duration icons.

Tool tip

Time dependency: Represented by the icon at the section level, if a sectionhas 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 unidirectionalarrow which connects two milestones.

Time and PointDependencies

GANTT Chart Details

The different color schemes used in the GANTT chart to visually represent the status of the execution planand plan item sections are as follows:



GANTT Chart Background Colors

The background color describes the status of the plan. The following figure displays the background colorcodes 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 chartbackground colors:

GANTT Chart Section Color

The Section level color code describes the status of the section. The following figure displays the section colorcodes 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



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

Here is a desription of tooltips for each of the Gantt items and the information that will be displayed whenuser take mouse pointer over a Gantt item:•

Figure 115: Plan Summary Task Bar tooltip

•

Figure 116: Plan Item Summary Task Bar tooltip



•

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 ActivityLog 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-timeand 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 at any timeto update the current view.

Viewing the Activity Log

You must search an object to view the activity log associated with a particular object. To do this, refer toSearching 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 youhave 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.



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:

DescriptionColumn Heading

The date and time the object was updated.Date

The reference ID of the object.Ref

The object type, for example, order, plan, order line, or plan item.Type

The action that was performed on the object. Refer to Understanding the Typesof Log Messages on page 267 to know about the different types of log messagesand their respective meanings.

Message

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 thefollowing:

DescriptionLog Message

updated an order where:Updated object from status status to status

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



DescriptionLog Message

an order has been amended where:Amended order id of status status

• order id is the unique ID of the order.• status is the current status of the order.

an order has been created where:Order order id created with status status

• 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 initialFulillment Catalog Hierarchy Manager in edit mode where you can drag and drop a particular product andsee 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'smodel will be shown in the Catalog tab. Click the Back button to navigate back to order's tab with selectedorder Id.

The Catalog tab allows you to view the available product configured in the Product repository in right handtree view.

Figure 123: Catalog Tab



Fulfillment Provisioning Service Order Hierarchy

The FP Service order is displayed in plan tab of Fulfillment Order Management. It is integrated with the Planitem tree hierarchy displayed at left side of the Plan tab. The FP Service Order (SO) integration with the plantree 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 theservice order node.

The Fulfillment Provisioning flow accepts and parses an incoming provisioning message and generates acorresponding 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 itscurrently 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



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 treepanel. The corresponding process flow is displayed based on the selected node. If the Plan item doesnot 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.



Figure 125: FP Process Flow



Searaching for Fulfillment Provisioning Components

When you select Order Id, Order Line Id, Technical Order Id or Resource Id, a filter icon is displayed. Clickthe 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 youneed to select minimum and mandatory fields from the filter. Follow the steps below:

1. Click the Activity Log tab.2. In the Search By box, select FP components3. In the Search field, type the FP order Id or select the filter.4. Click Enter or the search icon to rertrive records.

Figure 127: Filter Icon



Third Party Access to Fulfillment Order Management User InterfaceOMSUI components are exposed to third party applications using Oauth2 authentication. Where the clientneeds to get the initial access token for OMSUI and request for particular OMSUI component by providingthe 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 targetURI to access OMSUI.

Single URI to Access OMSUI ComponentYou 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 andsearch parameter.



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

The following are search parameters for order, plan, and activitylog:

Order:

• orderRef• orderID• status

Plan:

• orderRef• PlanID

Activitylog

• Type (orderRef/plan)



Chapter

11Data Access Interfaces

Overview

Fulfillment Order Management exposes five JMS based interfaces for process components to access or update theUDF 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


Get Order

Overview

The GetOrder interface can be used by the process components to retrieve a specific order from the FulfillmentOrder Management system. It is a synchronous request/reply interface on a JMS queue that returns a replyeither to the specified JMSReplyTo destination on the request message or to the default reply queue if notspecified.

If an exception occurs during Get Order operation then it is logged into the omsServer log. The details of theexception are returned in the response.

Get Order Request

The request specification is as follows:

QueueQueue or Topic

tibco.aff.tds.order.read.requestDestination

The following properties should be passed in the request message header:


Interface identifier name; MUST be set asGetOrderRequestEvent.

RequiredString_nm_

Unique identifier for tracing purposes across function calls.This is used for logging.


Unique identifier for tracing purposes across a singlefunction call. This is generally used by the callingapplication to correlate requests and responses.


Internal unique identifier for the order to retrieve.RequiredStringorderID

If set to true:

The response will be sent on the temporary queue bydefault or on the destination set as JMSReplyTo propertyin the request message.

RequiredBooleanrequestReply

If set to false:

The response will be sent on tibco.aff.tds.order.replyqueue.

If true, retrieve all versions of the order in case ofamendments.

RequiredBooleanallValues

There is no body (payload) associated with the request message.

Get Order Response

The response specification is as follows:


276 | Data Access Interfaces

QueueQueue orTopic

temp queue or JMSReplyTo destination or tibco.aff.tds.order.reply queueDestination

The response message contains the following header properties:




Unique identifier for tracing purposes across a single functioncall. This is generally used by the calling application tocorrelate requests and responses.


Flag indicating if the call was successful.RequiredBooleansuccess

Result message code.RequiredStringmessageCode

Result message.RequiredStringmessage

Internal unique identifier for the order specified in the request.RequiredStringorderID

Flag indicating if the order was found.RequiredBooleanfound

The response message contains the XML payload as per the following schema:

Figure 128: Get Order Response




Result status type. See Appendix A for the specification of thistype.



Data Access Interfaces | 277

Order type. If the order is not found this will be omitted.OptionalTypeorder

Internal unique identifier for the order.RequiredStringorder/orderID

External unique identifier for the order.RequiredStringorder/orderRef

The internal unique identifier for the plan for the order if it exists.OptionalStringorder/planID

The Status of the order from a cache data store perspective (activeor complete)

RequiredStringorder/status

Xml string representation of the order, multiple if all versions arerequested, otherwise just the active one

0-MStringorder/serializedOrder

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

ScenarioMessage in Response Headerand Result status

Message Code in ResponseHeader and Result Status

Order is found and data is mappedin the response successfully.

Successfully processedGetOrderRequestEvent

FOM-DATA-ACCESS-SUCCESS-0000

orderID parameter in the requestheader is null or empty.

Invalid value '' for input orderID inGetOrderReqestEvent

FOM-DATA-ACCESS-INVALID-INPUT-9999

Order is not found against theorderID specified in the requestheader.

Order not found for orderID<orderID value>

FOM-DATA-ACCESS-ORDER-NOT-FOUND-9999

Any other exception occurred whileprocessing the request.

Internal error occurred whileprocessing GetOrderReqestEvent

FOM-DATA-ACCESS-INTERNAL-ERROR-9999

Resource Failure (DB connection)issues are encountered whileprocessing the request.

Database connection issuesoccurred while processingGetOrderReqestEvent

FOM-DATA-ACCESS-DBCONN-ERROR-9999



Get Plan

Overview

The GetPlan interface can be used by the process components to retrieve the plan corresponding to an orderfrom the FOM system. It is a synchronous request/reply interface on a JMS queue that returns a reply eitherto 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 theexception are returned in the response.

Get Plan Request


QueueQueue or Topic

tibco.aff.tds.plan.read.requestDestination



Interface identifier name; MUST be set asGetPlanRequestEvent.

RequiredString_nm_



Internal unique identifier for the plan to retrieve.RequiredStringplanID

Unique identifier for tracing purposes across asingle function call. This is generally used by the


calling application to correlate requests andresponses.

If set to true:

The response will be sent on the temporary queueby default or on the destination set as JMSReplyToproperty in the request message.


If set to false:

The response will be sent ontibco.aff.tds.plan.reply queue.

If true will only return the IDs of elements ratherthan all plan data. Otherwise if false will return allplan data.

RequiredBooleanidsOnly



If true will return all plan items with the plan.Otherwise if false then only the plan details arereturned.

RequiredBooleanincludeItems

The component which has originated this call. E.g.the name of the process componentPC_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 plandescription to the process components. This value comes from the order description provided during ordersubmission process. If the order description is not provided then a default plan description 'Plan For' <orderref> is returned in the PLAN_DESCRIPTION UDF field.


QueueQueue or Topic

temp queue or JMSReplyTo destination or tibco.aff.tds.plan.reply queueDestination



Unique identifier for tracingpurposes across function calls.This is used for logging.


Unique identifier for tracingpurposes across a single function


call. This is generally used by thecalling application to correlaterequests and responses.

Flag indicating if the call wassuccessful.




Internal unique identifier for theplan specified in the request.


Flag indicating if the plan wasfound.

RequiredBooleanfound




Figure 129: Get Plan Response







Plan type. If the plan was not found this will beomitted.

OptionalTypeplan

Internal unique identifier for the plan.RequiredStringplan/planID

Internal unique identifier for the order for the plan.RequiredStringplan/orderID

External unique identifier for the order for the plan.RequiredStringplan/orderRef

UDF type.0-MTypeplan/udf

Type of the user defined field.OptionalStringplan/udf/type

Flavour of the UDF. The valid values are one of thefollowing three:

OptionalStringplan/udf/flavour

• config - For UDF corresponding to acharacteristic in the product model or a systemUDF generated by AOPD.

• input - For UDF passed in the order.



• output - For UDF set by the process component.

Field name.RequiredStringplan/udf/name

Field value.OptionalStringplan/udf/value

Original field value at time of plan creation.OptionalStringplan/udf/originalValue

Timestamp when the UDF was last modified.OptionalDateTimeplan/udf/lastModified

Plan item type.0-MTypeplan/planItem

Internal unique identifier for the plan item.RequiredStringplan/planItem/planItemID

Name of the process component.OptionalStringplan/planItem/planItemName

UDF type.0-MTypeplan/planItem/udf

Type of the user defined field.OptionalStringplan/planItem/udf/type

Flavour of the UDF. The valid values are one of thefollowing three:

OptionalStringplan/planItem/udf/flavour

• config - For UDF corresponding to acharacteristic in the product model or a systemUDF generated by AOPD.

• input - For UDF passed in the order.• output - For UDF set by the process component.

Field name.RequiredStringplan/planItem/udf/name

Field value.OptionalStringplan/planItem/udf/value

Original field value at time of plan creation.OptionalStringplan/planItem/udf/originalValue

Timestamp when the UDF was last modified.OptionalDateTimeplan/planItem/udf/lastModified

IDs of the plan items which depend on the currentplan item.

0-MStringplan/planItem/parentID

IDs of the plan items on which the current plan itemdepends.

0-MStringplan/planItem/childID

IDs of the plan items corresponding toSIBLING_PRODUCT_* of the product fulfilled bycurrent plan item.

0-MStringplan/planItem/siblingID

IDs of the plan items corresponding toDEPENDENT_PRODUCT_* of the product fulfilledby current plan item.

0-MStringplan/planItem/dependentID

Status of the plan from a data perspective: active orcomplete.

RequiredStringplan/status

Plan description.OptionalStringplan/planDescription

Get Plan Messages and Message Codes

The error codes and their respective error messages for the Get Plan interface are as follows:



Table 6: Get Plan Messages and Message Codes

ScenarioMessage in Response Headerand Result Status


Plan is found and data is mappedin the response successfully.

Successfully processedGetPlanRequestEvent


planID parameter in the requestheader is null or empty.

Invalid value '' for input planID inGetPlanRequestEvent


Plan is not found against theplanID specified in the requestheader.

Plan not found for planID <planIDvalue>

FOM-DATA-ACCESS-PLAN-NOT-FOUND-9999


Internal error occurred whileprocessing GetPlanRequestEvent



Database connection issuesoccurred while processingGetPlanRequestEvent




Get Plan Items

Overview

The GetPlanItems interface can be used by the process components to retrieve the data of one or many planitems in the plan corresponding to an order from the FOM system. It is a synchronous request/reply interfaceon a JMS queue that returns a reply either to the specified JMSReplyTo destination on the request messageor to the default reply queue if not specified.

If an exception occurs during GetPlanItems operation, then it is logged into the omsServer log. The detailsof the exception are returned in the response.

Get Plan Items Request


QueueQueue or Topic

tibco.aff.tds.plan.read.requestDestination



Interface identifier name; MUST be set asGetPlanItemsRequestEvent.

RequiredString_nm_

Unique identifier for tracing purposesacross function calls.


Internal unique identifier for the plan toretrieve.


Unique identifier for tracing purposesacross a single function call. This is


generally used by the calling application tocorrelate requests and responses.

If set to true:

The response will be sent on the temporaryqueue by default or on the destination set


as JMSReplyTo property in the requestmessage.If set to false:


If true will only return the IDs of elementsrather than all plan data. Otherwise if falsewill return all plan data.

RequiredBooleanidsOnly



The component which has originated thiscall. E.g. the name of the process componentPC_BUNDLE_PROVIDE.


The request message body should contain the XML payload as per the following schema:

Figure 130: Get Plan Items Request





If true will only return the IDs of elements rather than allplan data. Otherwise if false will return all plan data.

OptionalStringidsOnly

Currently not implemented.OptionalStringudfFlavour

Currently not implemented.OptionalStringudfMatch

Plan item type.0-MTypeplanItem

Internal unique identifier for the plan item to retrieve.RequiredStringplanItem/planItemID

Not Applicable.OptionalStringplanItem/planItemName

Not Applicable.0-MTypeplanItem/udf

Not Applicable.0-MStringparentID



Not Applicable.0-MStringchildID

Not Applicable.0-MStringsiblingID

Not Applicable.0-MStringdependentID

Get Plan Items Response


QueueQueue or Topic




Unique identifier for tracing purposesacross function calls. This is used forlogging.


Unique identifier for tracing purposesacross a single function call. This is


generally used by the callingapplication to correlate requests andresponses.

Flag indicating if the call wassuccessful.

RequiredBooleanSuccess


Result message.RequiredStringMessage

Internal unique identifier for the planspecified in the request.


Flag indicating if the plan was found.RequiredBooleanFound




Figure 131: Get Plan Items Response




See ImageStringbusinessTransactionID


See ImageTyperesultStatus

Plan item type.0-MTypeplanItem

Internal unique identifier for the plan item.RequiredStringplanItem/planItemID

Name of the process component.OptionalStringplanItem/planItemName

UDF type.0-MTypeplanItem/udf

Type of the user defined field.OptionalStringplanItem/udf/type

Flavour of the UDF. The valid values are oneof the following three:

OptionalStringplanItem/udf/flavour

• config - For UDF corresponding to acharacteristic in the product model or asystem UDF generated by AOPD.

• input - For UDF passed in the order.



• output - For UDF set by the processcomponent.

Field name.RequiredStringplanItem/udf/name

Field value.OptionalStringplanItem/udf/value

Original field value at time of plan creation.OptionalStringplanItem/udf/originalValue

Timestamp when the UDF was last modified.OptionalDateTimeplanItem/udf/lastModified

IDs of the plan items which depends on thecurrent plan item.

0-MStringplanItem/parentID

IDs of the plan items on which the currentplan item depends.

0-MStringplanItem/childID

IDs of the plan items corresponding toSIBLING_PRODUCT_* of the productfulfilled by current plan item.

0-MStringplanItem/siblingID

IDs of the plan items corresponding toDEPENDENT_PRODUCT_* of the productfulfilled by current plan item.

0-MStringplanItem/dependentID

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



PlanItem or PlanItems are foundand data is mapped in the responsesuccessfully.

Successfully processedGetPlanItemsRequestEvent


planID parameter in the requestheader or XML payload is null orempty.

Invalid value '' for input planID inGetPlanItemsRequestEvent


planItemID parameter in therequest XML payload is null orempty.

Invalid value '' for inputplanItemID inGetPlanItemsRequestEvent


XML payload in the request is notvalid.

Invalid payload inGetPlanItemsRequestEvent

FOM-DATA-ACCESS-INVALID-REQUEST-9999

Value of planID parameter in therequest header and XML payloadis not consistent.

Inconsistent input values in requestheader and payload

FOM-DATA-ACCESS-INCONSISTENT-INPUT-9999

PlanItem is not found against theplanID and planItemID specifiedin the request header.

PlanItem not found for planID<planID value> and planItemID<planItemID value>

FOM-DATA-ACCESS-PLANITEM-NOT-FOUND-9999


Internal error occurred whileprocessingGetPlanItemsRequestEvent







Database connection issuesoccurred while processingGetPlanItemsRequestEvent




Set Plan

Overview

The SetPlan interface can be used by the process components to add a new UDF or update the value of anexisting 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 forplan 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 specifiedJMSReplyTo 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 log. The details ofthe exception are returned in the response.

Set Plan Request


QueueQueue orTopic

tibco.aff.tds.plan.requestDestination



Interface identifier name; MUST be set as SetPlanRequestEvent.RequiredString_nm_





If set to true:

The response will be sent on the temporary queue by defaultor on the destination set as JMSReplyTo property in therequest message.


If set to false:

The response will be sent on tibco.aff.tds.plan.replyqueue.

If set to true:

All the existing UDFs will be replaced by the UDFs that arepresent in the request.

RequiredBooleanreplace

If set to false:



The UDFs passed in the request will be merged with theexisting UDFs.

In any of the above case, the uniqueness of a UDF ismaintained on the basis of the 'name' and 'flavor' combinationin the UDF. A UDF having exactly same 'name' and 'flavor'will not be duplicated, if the flag EnableUniqueUDFNames isset to true in OMS configurations. In case of multiple UDFswith exactly same name and flavor in the request, the valuefrom the last encountered UDF will be considered.

The component which has originated this call. E.g. the nameof the process component PC_BUNDLE_PROVIDE.



Figure 132: Set Plan Request





Plan type.RequiredTypePlan

Internal unique identifier for the plan to update.RequiredStringplan/planID

Internal unique identifier for the order relatedto the plan to update.

RequiredStringplan/ordered

External unique identifier for the order relatedto the plan to update.

RequiredStringplan/orderRef



0-MTypeplan/udf

Type of the user defined field.OptionalStringplan/udf/type

Flavour of the UDF. Must be set as output.OptionalStringplan/udf/flavour

Field name.RequiredStringplan /udf/name

Field value.RequiredStringplan/udf/value

Plan item type.0-MTypeplan/planItem

Internal unique identifier for the plan item toupdate.

RequiredStringplan/planItem/planItemID

Process component name.OptionalStringplan/planItem/planItemName

UDF type.0-MTypeplan/planItem/udf

Type of the user defined field.OptionalStringplan/planItem/udf/type

Flavour of the UDF. Must be set as output.OptionalStringplan/planItem/udf/flavour

Field name.RequiredStringplan/planItem/udf/name

Field value.RequiredStringplan/planItem/udf/value

If true it completely replaces the plan item,otherwise merges the UDF data.

OptionalAnyreplace

Set Plan Response


QueueQueue or Topic




Unique identifier for tracing purposes acrossfunction calls. This is used for logging.


Unique identifier for tracing purposes across asingle function call. This is generally used by


the calling application to correlate requests andresponses.






Internal unique identifier for the plan specifiedin 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 Headerand Result Status

Plan is found and UDF dataspecified in the request in plan

Successfully processedSetPlanRequestEvent


header and plan items isupdated successfully.

planID parameter in the requestheader or XML payload is nullor empty.

Invalid value '' for input planID inSetPlanRequestEvent


XML payload in the request isnot valid.

Invalid payload inSetPlanRequestEvent


Value of planID parameter inthe request header and XMLpayload is not consistent.



Plan is not found against theplanID specified in the request.

Plan not found for planID <planIDvalue>

FOM-DATA-ACCESS-PLAN-NOT-FOUND-9999

Any other exception occurredwhile processing the request.

Internal error occurred whileprocessing SetPlanRequestEvent


Resource Failure (DBconnection) issues are

Database connection issuesoccurred while processingSetPlanRequestEvent


encountered while processingthe request.



Set Plan Item

Overview

The SetPlanItem interface can be used by the process components to add a new UDF or update the value ofan 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 specifiedJMSReplyTo 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 ofthe exception are returned in the response.

Set Plan Item Request


QueueQueue or Topic

tibco.aff.tds.plan.requestDestination



Interface identifier name; MUST be set asSetPlanItemRequestEvent.

RequiredString_nm_




Unique identifier for tracing purposes across asingle function call. This is generally used by the


calling application to correlate requests andresponses.

If set to true:

The response will be sent on the temporary queueby default or on the destination set as JMSReplyToproperty in the request message.


If set to false:


If set to true:

All the existing UDFs will be replaced by the UDFsthat are present in the request.

RequiredBooleanreplace

If set to false:



The UDFs passed in the request will be mergedwith the existing UDFs.

In any of the earlier mentioned cases, theuniqueness of a UDF is maintained on the basisof the 'name' and 'flavor' combination in the UDF.A UDF having the exact same 'name' and 'flavor'will not get duplicated, if the flagEnableUniqueUDFNames is set to true in OMSconfigurations. In case of multiple UDFs with theexact same name and flavor in the request, thevalue from the last encountered UDF will beconsidered.

Internal unique identifier for the plan item toupdate.


The component which has originated this call. E.g.the name of the process componentPC_BUNDLE_PROVIDE.



Figure 133: Set Plan Item Request







Internal unique identifier for the plan to update.RequiredStringplanID

Plan item type. Only UDF Name and Value areupdated. If the UniqueUDFs are enabled for the


engine an update will occur, if disabled the entirecurrent UDF payload will be dropped and replacedwith the new payload.

Internal unique identifier for the plan item to update.RequiredStringplanItem/planItemID

Process component name.OptionalStringplanItem/planItemName

UDF type.0-MTypeplanItem/udf

Type of the user defined field.OptionalStringplanItem/udf/type

Flavour of the UDF. Must be set as output.OptionalStringplanItem/udf/flavour

Field name.RequiredStringplanItem/udf/name

Field value.RequiredStringplanItem/udf/value

If true it completely replaces the plan item, otherwisemerges the UDF data.

OptionalAnyreplace

Set Plan Item Response


QueueQueue orTopic













Internal unique identifier for the plan specified in the request.RequiredStringplanID

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



PlanItem is found and UDF dataspecified in the request is updatedsuccessfully.

Successfully processedSetPlanItemRequestEvent


planID parameter in the requestheader or XML payload is null orempty.

Invalid value '' for input planID inSetPlanItemRequestEvent


planItemID parameter in therequest header or XML payload isnull or empty.

Invalid value '' for inputplanItemID inSetPlanItemRequestEvent


XML payload in the request is notvalid.

Invalid payload inSetPlanItemRequestEvent


Value of planID or planItemIDparameters in the request header



and XML payload are notconsistent.

PlanItem is not found against theplanID and planItemID specifiedin the request header.

PlanItem not found for planID<planID value> and planItemID<planItemID value>

FOM-DATA-ACCESS-PLANITEM-NOT-FOUND-9999


Internal error occurred whileprocessingSetPlanItemRequestEvent



Database connection issuesoccurred while processingSetPlanItemRequestEvent




Chapter

12Best 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


Process Component Design Guidelines

This topic talks about different guidelines that can be followed for designing and developing the processcomponents.

Process Component Technology Selection

Process Components may be implemented in any JMS-enabled technology that conforms to the interfacespecification in the product documentation.

Generally speaking Process Components can be classified using a combination of the duration of the ProcessComponent 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 noabsolute number that defines a short vs. long-lived Process Component. Instead the duration defines whetheror 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 suspendresponse. If a suspend response is returned, it must handle an activate request from Orchestrator later toresume execution.

• Process Component statefulness defines whether or not a Process Component needs to persist stateinternally during the life of an invocation. This does not include storing data using OMS data serviceinterfaces, which is available for all Process Components. Instead the determining requirement is whetheror 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 backendsystems being invoked are synchronous or asynchronous. Asynchronous backend system invocation is acommon use case for stateful Process Component. However it may be possible to pass a correlationID throughthe backend system that allows the use of a stateless Process Component. Consequently a Process Componentis defined as a logical entity that provides a given set of functionality. It does not necessarily translate directlyinto 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:

TechnologyRequirement

BusinessWorksShort lived process that does one or manysynchronous invocations to back-end systems. BusinessEvents

BusinessWorksShort-lived process that does one or manysynchronous and/or asynchronous invocations to BusinessEventsback-end systems. The back-end system accepts acorrelation ID that comprised of the combination oforderRef and planItemID.


300 | Best Practices for Fulfillment Order Management

TechnologyRequirement

BusinessEventsShort-lived process that does one or manysynchronous and/or asynchronous invocations toback-end systems. The back-end system accepts acorrelation ID but cannot be comprised of orderRefand planItemID.

BusinessEventsLong-lived process that does one or manysynchronous and/or asynchronous invocations toback-end systems with no manual interaction.

iProcessLong-lived process that does one or manysynchronous and/or asynchronous invocations toback-end systems with at least one manual interaction.


Best Practices for Fulfillment Order Management | 301

BusinessWorks - Asynchronous Process Component

This section provides an example on how to approach the implementation of a Business Works processcomponent that is “asynchronous”, in the sense that the back-end call is asynchronous in nature. After a callis made to a backend system, the sending process terminates, after passing in a correlation ID that the receivingprocess can use to retrieve any context information needed to continue with the processing required. In thisexample, 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 UseCases 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 informationrelated to the user. The backend application has an asynchronous interface and after receiving a request willsend 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.



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 andthe Orchestrator will send a PlanItemExecutionRequest Event with the plan item to be executed based onthe 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: ProcessComponent 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 andBE Receive Event pallets for interaction with Orchestrator. This was possible with the 1.2 version of



TIBCO ActiveFulfillment due to the availability of the BE event references in Orchestrator, exposedthrough a project library. However from TIBCO FOM 2.0.x version onwards, the project library usablein the Designer projects couldn't have the BE event references from Orchestrator. Therefore BW basedprocess components must use the corresponding JMS based pallets such as JMS Queue Receiver andJMS Queue Sender in order to interact with the Orchestrator by exchanging the requiredrequest/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 themessage from the internal queue and calls the specific BW process that implements the actual processcomponent 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 Componentsends a request to the backend application, it also has to send a CorrelationID which needs to be returnedwith the response from the backend application in order to correlate it with the request. In this example it isassumed that the Backend is capable of doing this.

This can be observed in the Figure 137: Process Component Example: Backend application call on page 304that 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 noticethat: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. OrderRefor 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 ProcessComponent sends the request to the backend application and this UDF could either contain:



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 applicationhas 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 andit will work as a dispatcher of the messages amongst other BW processes that are the consumers of the repliescoming from the backend system.

When the backend application replies it will insert the CorrelationID in the response which can be used toretrieve information using OMS data access interfaces and the particular UDF which contains the consumerof the response.

Here it is assumed that TP sends a message to a backend application in a queue and receives the reply bylistening 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 Receiveractivity receives the response from the backend application; it is the BW process that receives all the repliesfrom the backend system. The “GetPlanID” mapper activity parses the id parameter coming from the backendapplication and gets the planID and planItemID.

At the end of the process there is a call to a BW process: “ConsumeResponse” which dispatches the responseand it is possible to pass the planID and planItemID to it which will be used to retrieve, using the OMS dataaccess interfaces, the UDF we set in the request containing the information regarding which BW process hasto be called or to which queue it is necessary to send the reply from the backend application in order toelaborate the response.

The Figure 139: Process Component Example: Set UDF for response on page 306 shows how to store the UDFby using the "setPlanItem" JMS data access interface of OMS.



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 observethat before calling the backend application (CallBackEndApplication), a UDF called “callBackQueue” hasbeen 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 listenon this queue and will process the message sent by the “ConsumeResponse” BW process as seen in the Figure140: 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 wouldhave dealt with the response; in this way the main BW process, which receives all the responses, would haveredirected 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 responsesfrom 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 ConsumerProcess on page 307 will listen on that queue and process the response received from the back-endapplication.

Figure 140: Process Component Example: BW ConsumeResponse Process



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 Processon page 307 it is possible to see that if the resultCode coming from the backend application response is notequal to zero, then a PlanItemExecuteResponse with complete set to true and success set to false is sent backto orchestrator; otherwise the ImplementConsumer BW process is called and it will consume the responsefrom 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 truesent back to orchestrator, this will send the PlanItemExecutionRequest for the FP and the Figure 143: ProcessComponent Example: FP Process Component on page 307 is an example of the BW process that manage therequest for the FP. The FP process component does not make any backend calls,so is simpler than the processcomponent for the TP. There is always a call to an Implementation BW process that consume the request, itreturns 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 CaseActivity 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 orRollback scenario.

In this section it is assumed that the Process Component sends/receives a message to/from a queue tocommunicate with a backend application.

When the backend application replies with an error code, the Process Component sends aPlanItemExecutionResponse Event to the Orchestrator with: completed flag set to “true”, success and cancelledset 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. Orchestratorwill then communicate with the Exception Handler (see Exception Handling Guidelines on page 313 for



more information) to see what the next action is. The Exception Handler has determined that the requiredaction is that the data on the order needs to be edited, and the plan item step retried. The Exception Handlercommunicates with Orchestrator and asks it to resend the planItem which failed. Orchestrator will resendanother 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 thatwould have normally executed in a success case scenario, for example: update the installed base. TheFigure 144: Process Component Example: Activate Event on page 308 shows a BW process that implementsthe Continue scenario:

Figure 144: Process Component Example: Activate Event

When the Process Component receives the Activate Event(PlanItemActivateRequest Event) message andthe action is not “CANCEL” it means that it has to Resume and carry on with the next step which in theFigure 144: Process Component Example: Activate Event on page 308 is called the BW process that representthe 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 aplan in execution state needs to go into suspend state before being compensated.

– The Process Component replies with a PlanItemSuspendResponseEvent and sets success and completedflags to “true”.

– Cancel order is treated as a special case of amendment. An updated plan is created by AOPD to cancelall the existing plan items. Compensation plan items that are required against some of the existingplan items are also added in the amended plan so as to actually rollback the tasks there were done bythe existing plan items.

– Once the amendment plan is received by the Orchestrator from AOPD, the Orchestrator will sendPlanItemActivateRequest 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 tasksthat were done by the original plan items.

Figure 145: Process Component Example: Suspend Event



BusinessWorks - Synchronous Process Component

If the backend interface is synchronous, it is possible to implement the process component in a much simplerway. Of course, be aware of the blocking nature of synchronous calls and the impact this can have onperformance.

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 beseen that a queue requester activity is used to implement the synchronous call to the back-end applicationand once the response is received from it, a PlanItemExecuteResponse will be sent to Orchestrator based onthe resultCode. If the resultCode is equal to zero, it sends a PlanItemExecuteResponse with success andcompleted equal to “true” otherwise it sends a PlanItemExecuteResponse with completed set to “true” andsuccess set to “false”. This will trigger the Exception Handler process as described above.



BusinessEvents - Process Component

In case of a BE Process Component it is necessary to create a Concept with a State Machine which will representthe process component lifecycle.

Figure 147: Process Component Life Cycle

The concept can be created in a rule that fires on receiving PlanItemExecutionRequest event from Orchestratorto 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 andBE Process Components then the rule has to fire only when the Process Component type is BE. To implementthis, it is possible to create another channel linked to the PlanItemExecutionRequest Event having a selectorsuch as: processComponentType = 'BE'. In this way the channel will only pick up PlanItemExecutionRequestscoming from the Orchestrator and having BE as processComponentType.

The Figure 148: planItemExecuteRequest (Destination) on page 311 shows how to set the Selector for a BEChannel:



Figure 148: planItemExecuteRequest (Destination)

In this case then, to create the BE Concept when the Orchestrator sends the PlanItemExecutionRequest Eventfor a certain PlanFragment, it is possible to create a rule function having in the declaration thePlanItemExecutionRequest Event and in the body the code to create the concept that represents the ProcessComponent.

In the Figure 149: Arguments for PlanItemExecuteRequestEvent on page 311 there is the Argument of theRule 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 examplethat 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 backto the Orchestrator. This can be done in any state of the State Machine based on the logic of the implementationor alternatively at the END state.



In the Figure 151: Edit Body: StateMachine_End_entryAction on page 312 there is the code example that showshow to create the PlanItemExecuteResponseEvent and how to send it:

Figure 151: Edit Body: StateMachine_End_entryAction



Exception Handling Guidelines

Exception Handling Guidelines provides information about guidelines that can be followed for handling theexceptional conditions in process components.

General Approach

FOM does not include any out-of-the-box approach for error handling. The product architecture does accountfor exception handlers, and provides the necessary hooks, where it can be integrated with an existing exceptionor 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 manageexception handling via Orchestrator and the Plan Item Failed (PIF) handler. In the first case, processcomponents 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 theOrchestrator for direction on how to proceed once an error is encountered. The PIF handler must respond toOrchestrator telling it whether to Retry the plan item, or Continue (that is, mark the plan item as completedand continue with the plan).

A consideration here is the type of process component. If a process component makes use of a workflowengine for its implementation, which already includes manual tasks and GUI interaction, it would makesense for errors in the flow to be managed within the workflow engine, rather than have them passed backto 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 thepurposes 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 processcomponent. An example could be a request to allocate a phone number that is already in use. Receivinga Functional Exception is expected to occur under under normal circumstances, and the system is builtto handle these events.

• A Technical Exception occurs when something goes wrong, so that the system is not designed to handleunder normal circumstances. They can occur in process components and also FOM components such asOrchestrator, 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 occurwithin the context of a process component, and would typically require an operator to review and decide onremedial action, it makes sense for these to be handled via the Orchestrator and a PIF handler, which mightdefer to an external GUI for a resolution.

Technical exception handling is more difficult, as they can be caused by almost anything. In this case, evenif a Technical exception occurs in a plan item, it might make more sense to simply log it and stop executionof the plan item.



Example Approach

This topic describes an approach for implementing exception handling, where order fallout is managedexternally to the FOM implementation. This is a good approach where the customer site has an existing orderfallout management system, providing GUI screens etc. whose functionality can be leveraged. In the rest ofthis topic we will refer to this external error handling system as Exception Management, or EM. Please notethis 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 separatemechanism.

For Functional exceptions the requirements are to forward all to Exception Management, for an operator toanalyse. 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 internallybe 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 Orchestratorto complete the plan item. There may be activity that we require the process component to complete afterthe 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, andwhat EM will do. The following diagram shows the approach in the case of Functional exceptions. Also, thedata access GetPlanItem and SetPlanItem calls are used to support the functionality of editing input/outputvalues.

Figure 152: Example Functional Exception Handling Overview Architecture

The Figure 153: Example Functional Exception Handling FOM Components on page 315 shows an approachfor how this could be implemented within FOM:



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 thefollowing:• 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 aresome considerations regarding this and the nature of the process component implementation, i.e. whether itexecutes 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 anotherway, 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



AOPD raises exceptions, Orchestrator will publish an event to the PQF handler and wait for a response. Ifthere 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 thoroughlyprior to AOPD), consider at the very least, implementing monitoring on the PQF request queue, so thatoperations will be aware that AOPD has failed for an order, and some action needs to be taken to move theorder on.

You may want to consider making the PQF handler “just another” source of Technical Exceptions. In thisway, a framework for dealing with automating Technical Exception handling, could be used to also deal withPQF 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 diverserange of possible exceptions that can be raised. Such exceptions can be raised from anywhere – FOMcomponents, process components, and any other code that may be developed as part of a total fulfilmentsolution.

It is of course always good general software engineering practice to build components as resilient as possibleto errors. It may make sense, depending on the context, to build in mechanisms such as retry, when eventssuch as timeouts occur. Of course, this needs to be weighed up against the additional complexity this introducesinto 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 willnever be able to catch all types of errors.

The underlying principle here is, as with Functional exceptions, Technical exceptions will require manualinspection to determine what to do. The default approach is that all technical exceptions are also dealt withmanually. This can mean messages being manually copied from one queue to another, database entries beingmanually edited, etc.

Nevertheless, it is highly desirable, in some common circumstances, for a fulfilment system to be able toresolve technical exceptions in an automated way. No system can be built to automatically resolve allexceptions, however one approach is to build a mechanism that can support incremental addition of automatedtechnical exception resolutions, as the system evolves and experience is gained into the types of exceptionsthat can occur, and how best to deal with them. This section outlines a possible approach to building such amechanism.

As with the handling of Functional exceptions, it is important to define a clear architectural separation betweenthe fulfilment system and the system that determines what to do with exceptions. Again, we term this bodyException 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 allTechnical exceptions. It will expect an argument “Resolution Type”, which is a string that will define whatspecific 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 aconsistent way. We define a single “Publish Technical Exception” service for FOM to use when publishinga 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 informationthat it would need to handle the resolution.



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. Theseare 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 Handlera. If an error occurs in plan development (or Feasibility, if present).

3. Process Componenta. 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 componentswithin FOM that would be involved in handling technical exceptions. Note that the other components notdirectly 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. Thisincludes those shown below, as well as the FOM core components, such as Orchestrator, data access interfaces,and AOPD.



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 ofTechnical Exception Handling:

Process Component

Technical exceptions occurring during the execution of process components will log a technical exceptiondirectly to Exception Management, via the Technical Exception Logger, and stop execution. Orchestrator willnot 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 invokesAOPD to get the plan. Like AOPD, the feasibility component can return an error to Orchestrator, if Feasibilityfails. 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, forinstance if order validation is performed at Feasibility).

Technical Exception Logger

This component publishes Technical exceptions to Exception Management. It should capture all Technicalexceptions generated from custom components, and publish them in a standard way to EM. A standard setof exception fields should be published, which should include order ids (if available), the component andservice that generated the error, and an error code. The message being processed at that time may also belogged. The key requirement is that there should be enough information logged to enable EM to choose aresolution type to be applied to resolve the exception, and enough information to be passed back to theTechnical 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 orAOPD, and publish them to Exception Management.



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 processcomponent, or to perform some custom action (such as clean up a database table and resubmit an order). Itmay 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 areadded.

The Figure 156: Process Component Technical Exception Services Overview on page 319 outlines at a highlevel, how the Retry, Continue and Complete services could potentially be implemented.

Figure 156: Process Component Technical Exception Services Overview



Appendix

ASchema References

Topics

• Plan Item• ResultStatus• Message• Order Request


Plan Item

Figure 157: Plan Item


Unique identifier for the plan item within the planto be executed.

RequiredStringplanItem/planItemID

Description for the plan item to be executed.OptionalStringplanItem/description

Unique identifier for the Process Component to beexecuted.

RequiredStringplanItem/processComponentID

Process component name for the Process Componentto be executed.

RequiredStringplanItem/processComponentName

Process component version for the ProcessComponent to be executed.

OptionalStringplanItem/processComponentVersion

Process component type for the Process Componentto be executed.

OptionalStringplanItem/processComponentType


322 | Schema References

Class of processComponentType.OptionalStringplanItem/processComponentRecordType

Order line type for the plan item to be executed.1-MTypeplanItem/orderLine

Order line number for the order line of the plan itemto be executed.

RequiredStringplanItem/orderLine/orderLineNumber

Product ID for the order line of the plan item to beexecuted.

RequiredStringplanItem/orderLine/productID

Product version for the order line of the plan itemto be executed.

OptionalStringplanItem/orderLine/productVersion

Order line action for the order line of the plan itemto be executed.

RequiredStringplanItem/orderLine/action

Order line action mode for the order line of the planitem to be executed.

OptionalStringplanItem/orderLine/actionMode

Quantity for the order line of the plan item to beexecuted.

RequiredLongplanItem/orderLine/quantity

Unit of measure for the order line of the plan itemto be executed.

RequiredStringplanItem/orderLine/uom

Subscriber ID for the order line of the plan item tobe executed.

OptionalStringplanItem/orderLine/subscriberID

Link ID for the order line of the plan item to beexecuted.

OptionalStringplanItem/orderLine/linkID

Inventory ID for the order line of the plan item tobe executed.

OptionalStringplanItem/orderLine/inventoryID

End of line flag for the order line of the plan item tobe executed. This indicates that this plan item is thefinal plan item for the order line.

RequiredBooleanplanItem/orderLine/eol

Plan item action for the plan item to be executed.RequiredStringplanItem/action

Plan item action mode for the plan item to beexecuted.

OptionalStringplanItem/actionMode


Schema References | 323

ResultStatus

Figure 158: Result Status


The OMS member (value of NODE_ID passed in tomcat's setenvscript) that returned this result. For example, Member1.

RequiredStringdeployment

Service that returned this result. It is always returned asJMS-BASED-DATA-ACCESS-INTERFACE.

RequiredStringservice

Operation within the service that returned this result. Forexample, GetOrder, GetPlan, or GetPlanItem.

RequiredStringoperation

The component that returned this result. It is always returnedas OMS.

RequiredStringcomponent

Severity result. Valid values are: 1. S - Success 2. E - Error.RequiredStringseverity

Message code for this result.RequiredStringcode

Message details for this result.RequiredStringmessage



Message

Figure 159: Message


Order line number that this message refers to.OptionalString,lineNumber

Message type. Valid values are:RequiredStringtype1. Information2. Warning3. Error

Message code for this message.RequiredStringCode

Message text for this message.RequiredStringDescription

UDF type.0-MTypeudf

User defined field name.RequiredStringudf/name

User defined field value.RequiredStringudf/value


Schema References | 325

Order Request

Figure 160: Order Request


External unique identifier for an order.RequiredStringorderRef

Order request header type. Refer to the Order Request Headerdefinition for details.

RequiredTypeheader

Order request line type. Refer to the Order Request Line definition fordetails.

1-MTypeline

Extension attributes for user-defined fields.OptionalTypeextension

Any dataRequiredAnyextension/#any



Appendix

BSamples

Topics

• Sample Order XML• Sample Plan Item XML• Sample XPATHs


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>


328 | Samples

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>


Samples | 329

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>


330 | Samples

Appendix

CGlobal Variables

Topics

• AOPD Global Variables• Orchestrator Global Variables• Global Variables and Configurations


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

PurposeConfiguration PropertyGlobal Variable Name

AOPD Application Flags configurationAFF/Global/Constants/InternalUDFs

Internal UDFs to beskipped for affinitymerging

c.t.a.a.flags.udflistUDFList

AFF/Global/Constants/InventoryStatus

These properties are notrequired in AOPD

NA

AFF/Global/Constants/InventoryUserStatus


NA

AFF/Global/Constants/LineItemActionModes


NA

AFF/Global/Constants/LineItemActions


NA

AFF/Global/Constants/OfferValidation


NA

AFF/Global/Constants/OrderUDFs


NA

AFF/Global/Constants/PlanUDFs


NA

AFF/Global/Constants/ProductModelCharacteristics


NA

AFF/Global/Constants/ProductType


332 | Global Variables



NA

AFF/Global/Constants/RegularExpressions


NA

AFF/Global/Constants/ResultStatus


NA

Controls the flag tomerge affinity UDFname

c.t.a.a.flags.affinity.affinityudfnamemergeAffinityUDFNameMerge

To not merge certainUDFs during Affinity

c.t.a.a.flags.affinity.characterisitcswithoutaffinitypostfix

CharacterisitcsWithoutAffinityPostfix

Sequencing those UDFsshould be added as CSVin the variable

LoadInventory

Within AOPD, if thesequence is -1, it will

c.t.a.a.flags.skipitemsequenceskipItemSequence

skip the product and allits mandatory childrenin the Execution Plan

MergeAffinityItemDescriptionc.t.a.a.flags.affinity.mergeaffinityitemdescriptionMergeAffinityItemDescription

Flag to determinewhether heirarchy child

c.t.a.a.flags.singleuse.hierarchysingleuseHierarchySingleUse

of single use productshould be deleted

Enable the UDF syntaxto determine the parent

c.t.a.a.flags.affinity.enableaffinityudfparentEnableAffinityUDFParent

product name andproduct name of theaffinity plan item

Allow Multiple RequiredProducts for the samelink ID

c.t.a.a.flags.allowmultiplerequiredproductsAllowMultipleRequiredProducts

Ignore First childdependency for source

c.t.a.a.flags.ignorepdofirstchilddependencyIgnorePDOFirstChildDependency

product in PDOrelationship


NA

Password for the JMSserver events.

c.t.a.a.jms.jndi.security.credentialsMIG_Password


Global Variables | 333



NAMIG_QueueConnectionFactory


NAMIG_TopicConnectionFactory

URL for the JMS serverevents.

c.t.a.a.jms.jndi.urlMIG_Url

Username for the JMSserver events.

c.t.a.a.jms.jndi.security.principalMIG_Username

AFF/OrderManagement/Constants


NA

AFF/OrderManagement/Flags


NA

AFF/OrderManagement/HTTP


NA

AFF/OrderManagement/JMS

The value for theproperties will be pickedup from the JMS configmentioned above

c.t.f.o.afi.aopd.amendplanrequest.sender.queueGLB_PlanDevelopmentAmendRequestQueue

c.t.f.o.afi.aopd.amendplanresponse.receiver.queueGLB_PlanDevelopmentAmendResponseQueue

c.t.f.o.afi.aopd.newplanrequest.sender.queueGLB_PlanDevelopmentNewRequestQueue

c.t.f.o.afi.aopd.newplanresponse.receiver.queueGLB_PlanDevelopmentNewResponseQueue

c.t.f.o.afi.productmodel.publish.topicGLB_ProductCataloguePublishTopic

c.t.f.o.afi.actionmodel.publish.topicGLB_ActionCataloguePublishTopic

AFF/OrderManagement/ProductManagement/Interfaces/JMS/Services

The value for theproperties will be pickedup from the JMS configmentioned above

CommonServicesClientLib/CommonServices


NA




CommonServicesClientLib/Events


NA

CommonServicesClientLib/Timing


NA



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

CommentsDescriptionConfiguration Property (nameand propname inConfigValues_OMS.xml)

Global Variable Name

affv4/common/constants/resultStatus

These GVs are notexposed for

NAError

modification inAdministrator. InOMS, this is handledinternally. Hence it isnot carried forward asa property inOrchestrator.


NAFatal



NAInformation



NASuccess







NAWarning


affv4/common/messaging/jms

All the jmsdestination name

String to be prefixedto each JMSdestination name.

NA.GLB_MessagingPrefix

properties in OMScontains this prefix intheir value itself.Since beginning, thereis no separate prefixproperty. Hence thisGV is not carriedforward as a propertyin Orchestrator.

affv4/orchestrator/configuration

This GV is notrelevant in

Time delay in msecafter which the

NAGLB_CleanUpObjectsDelay

Orchestrator andinstances of ordershence not carriedand plans which areforward in 2.1.0. Sincescheduled to cleanupOMS DB is the onlywill be actually

cleaned up (deleted). datastore now, thecleanup of order datafrom it is handled bythe purge utility.

NAFlag to enable ordisable auto purge oforders in Orchestrator

c.t.f.orch.autoPurgeOnCompletionAuto purge enabled

NAThe name of thedefault error handler

Default Process Component ErrorHandler c.t.f.orch.pcErrorHandler

GLB_DefaultProcessComponentErrorHandler

component to whichOrchestrator sendsthe PlanItemExecuteFailedRequest forfailed plan items.

NARetry count for failedFeasibility step.

Feasibility Retriesc.t.f.orch.feasibilityRetries

GLB_FeasibilityRetries





NAInterval in msec towait before retryingfailed Feasibility step.

Feasibility Retry Intervalc.t.f.orch.feasibilityRetryInterval

GLB_FeasibilityRetryInterval

NARetry count for failedOPD step.

OPD Retries c.t.f.orch.OPDRetriesGLB_OPDRetries

NAInterval in msec towait before retryingfailed OPD step.

OPD Retry Intervalc.t.f.orch.opdRetryInterval

GLB_OPDRetryInterval

Plan Item SLAnotification feature is

SLA threshold forpercentage of

NAGLB_PlanItemSLAThresholdConstant

removed frommaximum duration toOrchestrator in 2.1.0publish an SLA

notification. release. This GV is notrelevant and hencenot carried forward.

NADefault retry countfor failed processcomponents.

Maximum number of retries forfailed process componentc.t.f.orch.failedPC.maxRetryCount

GLB_ProcessComponentRetries

NADefault retry delay inmsec for failedprocess components.

Time interval between consecutiveretry attempts for failed processcomponentc.t.f.orch.failedPC.retryInterval

GLB_ProcessComponentRetryInterval

This property is usedin BE Orchestrator to

Polling interval inmsec for scheduler.

NAGLB_SchedulerPollingInterval

create the BEscheduler threads onstartup. It is notrelevant in theOrchestrator andhence not carriedforward.

This property wasadded specifically to

The path of outputfile to be used by BEprofiler.

NAGLB_BEProfilerOutputFilePath

control the BEengine's profiling. Itis not relevant in theOrchestrator andhence not carriedforward.


The level of BE engineprofiling

NAGLB_BEProfilerLevel

control the BEengine's profiling. Itis not relevant in theOrchestrator andhence not carriedforward.






The time duration inseconds for which the

NAGLB_BEProfilerDurationInSeconds

control the BEprofiling is to bedone. engine's profiling. It

is not relevant in theOrchestrator andhence not carriedforward.

affv4/orchestrator/constants/actions

This GV is notexposed for

Order line cancelaction.

NACancel


affv4/orchestrator/constants/dependencyStatus

None of the GVsunder this category

NANANA

are exposed formodification throughAdministrator. InOMS, dependencystatus constants aremaintained internally.Hence these GVs arenot carried forward asa properties inOrchestrator.

affv4/orchestrator/constants/errors


NANANA

are exposed formodification throughAdministrator. InOrchestrator, theerror messages arenot exactly same.Hence these GVs arenot carried forward inOrchestrator.





affv4/orchestrator/constants/Generic

This property wasintroduced and used

NANAGLB_OriginatorString

in Orchestrator toTDS integration (pre2.1.0). It is notrelevant in theOrchestrator andhence not carriedforward.

affv4/orchestrator/constants/Milestone


NANANA

are exposed formodification throughAdministrator. InOMS, milestonenames are maintainedinternally. Hencethese GVs are notcarried forward as aproperties inOrchestrator.

affv4/orchestrator/constants/milestoneStatus


NANANA

are exposed formodification throughAdministrator. InOMS, milestonestatus constants aremaintained internally.Hence these GVs arenot carried forward asa properties inOrchestrator.

affv4/orchestrator/constants/notificationEventName


NANANA

are exposed formodification throughAdministrator. Thesewere added in BE





Orchestrator toidentify thenotification eventtype in the commoninternal event. Noneof these GVs arerelevant and hencenot carried forward asa properties inOrchestrator.

affv4/orchestrator/constants/notifications


NANANA

are exposed formodification throughAdministrator. Themessages to be sent invarious entity statuschange notificationevents are handled inOrchestratorinternally. None ofthese GVs arerelevant and hencenot carried forward asa properties inOrchestrator.

affv4/orchestrator/constants/orderAmendmentStatus


NANANA

are exposed formodification throughAdministrator. InOMS, orderamendment statusconstants aremaintained internally.Hence these GVs arenot carried forward asa properties inOrchestrator.

affv4/orchestrator/constants/orderLineStatus


NANANA

are exposed for





modification throughAdministrator. InOMS, order linestatus constants aremaintained internally.Hence these GVs arenot carried forward asa properties inOrchestrator.

affv4/orchestrator/constants/orderStatus


NANANA

are exposed formodification throughAdministrator. InOMS, order statusconstants aremaintained internally.Hence these GVs arenot carried forward asa properties inOrchestrator.

affv4/orchestrator/constants/planItemStatus


NANANA

are exposed formodification throughAdministrator. InOMS, plan item statusconstants aremaintained internally.Hence these GVs arenot carried forward asa properties inOrchestrator.

affv4/orchestrator/constants/planStatus


NANANA

are exposed formodification throughAdministrator. InOMS, plan statusconstants aremaintained internally.Hence these GVs are





not carried forward asa properties inOrchestrator.

affv4/orchestrator/constants/processComponentID

NAName of the processcomponent to

Need to externalize inConfigValues_OMS.xml

NoReciprocalAction

indicate no reciprocalaction is required oncancellation.

NAName of the processcomponent to

Non Executing Planfragment IDc.t.f.orch.nonexecuting.planfragmentID

NonExecuting

indicate that no actionneed to be sent toprocess components.

affv4/orchestrator/flags


Flag to enablecleanup of objects at

NAGLB_CleanupObjectsAtEndOfOrder

Orchestrator andthe end of an orderlifecycle. hence not carried

forward in 2.1.0. SinceOMS DB is the onlydatastore now, thecleanup of order datafrom it is handled bythe purge utility.


Flag to enableorderID generation

NAGLB_EnableExternalOrderIDSource

Orchestrator andexternal toOrchestrator. hence not carried

forward in 2.1.0. OMSgenerates the uniqueorderID for eachincoming order andthe Orchestrator usesonly that.

NAFlag to enablePreQualification

Enable Feasibility Error Handlingc.t.f.orch.enableFeasibilityErrorHandling

GLB_EnableFeasibilityErrorHandling

Failed Handler forfeasibility failures.


Flag to enable OMSintegration.

NAGLB_EnableOMSIntegration

Orchestrator andhence not carriedforward in 2.1.0. TheOrchestrator is anintegral part of OMS.





NAFlag to enablePreQualification

Enable OPD Error Handlingc.t.f.orch.enableOPDErrorHandling

GLB_EnableOPDErrorHandling

Failed Handler forOPD failures.

NAFlag to enable orderamendment statusnotifications.

Enable Order Amendment StatusChange c.t.f.orch.enableOrderAmendmentStatusChange

GLB_EnableOrderAmendmentStatusNotifications

There is no need tohave a flag to

Flag to enable orderamendments.

NAGLB_EnableOrderAmendments

enable/disableamendments.Amendmentfunctionality iswidely used bycustomers and isOOTB. Since it is notrelevant, this GV isnot carried forward inOrchestrator.

NAFlag to enable orderline statusnotifications.

Enable OrderLine Status Changec.t.f.orch.enableOrderLineStatusChange

GLB_EnableOrderLineStatusNotifications

Order rejectfunctionality is not

Flag to enable orderreject notifications.

NAGLB_EnableOrderRejectNotifications

relevant in 2.1.0. OMSweb service interfacetakes care of rejectingthe order by sendingthe appropriateresponse. Since it isnot relevant, this GVis not carried forwardin Orchestrator.

NAFlag to enable orderstatus notifications.

Enable Order Status Changec.t.f.orch.enableOrderStatusChange

GLB_EnableOrderStatusNotifications

NAFlag to enable plandevelopmentnotifications.

Enable Plan developmentnotificationc.t.f.orch.enablePlanDevelopmentNotification

GLB_EnablePlanDevelopmentNotifications

This flag was addedin BE Orchestrator

Flag to enable planitem failednotifications.

NAGLB_EnablePlanItemFailedNotifications

specifically from OMSperspective. PlanItemNotificationEvent fora failed plan item ispublished if this flag





is enabled. Based onthe notification, OMScould show the statusasERROR_HANDLER.Since Orchestrator isan integral part ofOMS in 2.1.0, it ishandled internally.This flag is notrelevant and hencenot carried forward.


Flag to enable SLAnotifications for planitems.

NAGLB_EnablePlanItemSLANotification

removed fromOrchestrator in 2.1.0release. This GV is notrelevant and hencenot carried forward.

NAFlag to enable planitem statusnotifications.

Enable PlanItem Status Changec.t.f.orch.enablePlanItemStatusChange

GLB_EnablePlanItemStatusNotifications

NAFlag to enable planstatus notifications.

Enable Plan Status Changec.t.f.orch.enablePlan StatusChange

GLB_EnablePlanStatusNotifications

Orchestrator is anintegral part of OMS

Flag to enablesending response tosubmit order events.

NAGLB_EnableSubmitOrderResponses

now. OMS webservice is the onlyentry point interfaceand there is no needto send any responseevent. This GV is notrelevant and hencenot carried forward.

NAFlag to enablefeasibility step.

Feasibility Requiredc.t.f.orch.feasibilityRequired

GLB_FeasibilityRequired

NAFlag to enable retry offailed Feasibility step.

Retry Failed Feasibilityc.t.f.orch.retryFailedFeasibility

GLB_RetryFailedFeasibility

NAFlag to enable retry offailed OPD step.

Retry Failed OPDc.t.f.orch.retryFailedOPD

GLB_RetryFailedOPD

NAFlag to enable retry offailed processcomponents.

Enable retries for failed processcomponents c.t.f.orch.failedPC.enableRetry

GLB_RetryFailedProcessComponents

This flag is notrelevant and hence

Flag to enable storingfailed plan itemmessages.

NAGLB_StoreFailedPlanItemMessages





not carried forward inOrchestrator.


Flag to enable storingfailed process

NAGLB_StoreFailedProcessComponentsMessages


componentsmessages.


Flag to enable storingfailed process Pre

NAGLB_StorePreQualificationFailedMessages


Qualificationmessages.


Flag to enable BEengine's profiling.

NAGLB_EnableBEProfiling


affv4/orchestrator/flags/notification

Need to decide onwhether to support

Flag to include theorder on order

NAGLB_IncludeOrderOnOrderAmendmentNotification

this functionality inOrchestrator.

amendmentnotifications.


Flag to include theorder on order linenotifications.

NAGLB_IncludeOrderOnOrderLineNotification



Flag to include theorder on ordernotifications.

NAGLB_IncludeOrderOnOrderNotification



Flag to include theplan on order

NAGLB_IncludePlanOnOrderAmendmentNotification


amendmentnotifications.


Flag to include theplan on order linenotifications.

NAGLB_IncludePlanOnOrderLineNotification



Flag to include theplan on ordernotifications.

NAGLB_IncludePlanOnOrderNotification


affv4/orchestrator/interfaces/jdbc/backingstore


NANANA





are relevant forOrchestrator sincestarting version 2.1.0,Orchestrator is anintegral part of OMSnow and uses onlyOMS DB. Hence theseGVs are not carriedforward inOrchestrator.

affv4/orchestrator/interfaces/jms/events


NANANA

are relevant forOrchestrator sincestarting version 2.1.0,Orchestrator is anintegral part of OMSnow and uses the JMSconnection propertiesused by OMS. Hencethese GVs are notcarried forward inOrchestrator.

affv4/orchestrator/messaging/jms/destinations

DeleteOrderRequestEventis not relevant in

Delete order requestdestination.

NAGLB_DataDeleteOrderRequest

Orchestrator andhence this GV is notcarried forward.

DeleteOrderResponseEventis not relevant in

Delete order responsedestination.

NAGLB_DataDeleteOrderResponse


DeletePlanRequestEventis not relevant in

Delete plan requestdestination.

NAGLB_DataDeletePlanRequest


DeletePlanResponseEventis not relevant in

Delete plan responsedestination.

NAGLB_DataDeletePlanResponse






GetOrderRequestEventis not relevant in

Get order requestdestination.

NAGLB_DataGetOrderRequest


GetOrderResponseEventis not relevant in

Get order responsedestination.

NAGLB_DataGetOrderResponse


GetOrderSummaryRequestEvent is not relevant

Get order summaryrequest destination.

NAGLB_DataGetOrderSummaryRequest

in Orchestrator andhence this GV is notcarried forward.

GetOrderSummaryResponseEvent is not relevant

Get order summaryresponse destination.

NAGLB_DataGetOrderSummaryResponse


GetPlanItemsRequestEvent is not relevant

Get plan itemsrequest destination.

NAGLB_DataGetPlanItemsRequest


GetPlanItemsResponseEvent is not relevant

Get plan itemsresponse destination.

NAGLB_DataGetPlanItemsResponse


GetPlanRequestEventis not relevant in

Get plan requestdestination.

NAGLB_DataGetPlanRequest


GetPlanResponseEventis not relevant in

Get plan responsedestination.

NAGLB_DataGetPlanResponse


NAExternal feasibilityhandler requestdestination.

External Feasibility request queuec.t.f.orch.feasibility.request.queue

GLB_ExternalFeasibilityRequest

NAExternal feasibilityhandler responsedestination.

External Feasibility reply queuec.t.f.orch.feasibility.reply.queue

GLB_ExternalFeasibilityResponse





NAExternal plandevelopment handlerrequest destination.

OPDRequest from Orchestratorreceiver queuec.t.f.oms.afi.orch.opdrequest.receiver.queue

GLB_ExternalOPDRequest

NAExternal plandevelopment handlerresponse destination.

OPDResponse to Orchestratorsender queuec.t.f.oms.afi.orch.opdresponse.sender.queue

GLB_ExternalOPDResponse

NAExternal plan itemfailed handler requestdestination.

PlanItem error handler requestqueuec.t.f.orch.planItem.errhandler.request.queue

GLB_ExternalPlanItemFailedRequest

NAExternal plan itemfailed handlerresponse destination.

PlanItem error handler responsequeuec.t.f.orch.planItem.errhandler.response.queue

GLB_ExternalPlanItemFailedResponse

NAExternalpre-qualification

External PreQualificationFailedrequest queue

GLB_ExternalPreQualificationFailedRequest

failed handler requestdestination.

c.t.f.orch.prequalificationfailed.request.queue

NAExternalpre-qualification

External PreQualificationFailedreply queue

GLB_ExternalPreQualificationFailedResponse

failed handlerresponse destination.

c.t.f.orch.prequalificationfailed.reply.queue

The JMS queuespecified by this GV

Dependency timedelta triggerdestination.

NAGLB_InternalDependencyTimeDelta

is not relevant andhence not carriedforward inOrchestrator. It wasBE implementationspecific.


Feasibility requesttrigger destination.

NAGLB_InternalFeasibilityRequest



OPD request triggerdestination.

NAGLB_InternalOPDRequest

is not relevant andhence not carriedforward inOrchestrator. It was





BE implementationspecific.


Plan item retry timedelta triggerdestination.

NAGLB_InternalPlanItemRetryTimeDelta



Plan item SLA triggerdestination.

NAGLB_InternalPlanItemSLANotifyTrigger


The JMS topicspecified by this GV

Process componentmodel publishdestination.

NAGLB_ModelProcessComponentModel

is not relevant andhence not carriedforward inOrchestrator.Orchestrator uses theplan fragment fromOMS DB.

NAOrder changenotification publishdestination.

Order status change destinationc.t.f.orch.order.statusChange.destination

GLB_NotificationOrder

NAOrder amendmentchange notificationpublish destination.

Order Amendment status changedestinationc.t.f.orch.orderAmendment.statusChange.destination

GLB_NotificationOrderAmendment

NAOrder line changenotification publishdestination.

OrderLine status changedestinationc.t.f.orch.orderLine.statusChange.destination

GLB_NotificationOrderLine


Order rejectnotification publishdestination.

NAGLB_NotificationOrderReject

is not relevant andhence not carriedforward inOrchestrator.Orchestrator uses theplan fragment fromOMS DB.





NAPlan changenotification publishdestination.

Plan status change destinationc.t.f.orch.plan.statusChange.destination

GLB_NotificationPlan

NAPlan developmentnotification publishdestination.

Plan development notificationdestinationc.t.f.orch.planDevelopment.notification.destination

GLB_NotificationPlanDevelopment

NAPlan item changenotification publishdestination.

PlanItem status change destinationc.t.f.orch.planItem.statusChange.destination

GLB_NotificationPlanItem


Plan item SLAnotification publishdestination.

NAGLB_NotificationPlanItemSLA

removed fromOrchestrator in 2.1.0release. This GV is notrelevant and hencenot carried forward.

The Orchestratordoesn't use the queue

Orchestrator startupevent request for

NAGLB_OrchestratorStartupEvent

specified in this GVprocess componentmodels anymore. Hence this

GV is not carriedforward.


Orchestrator startupservice request for

NAGLB_OrchestratorStartupService

specified in this GVprocess componentmodels anymore. Hence this

GV is not carriedforward.

NAOrder activate requestpublish destination.

Activate order request queuec.t.f.orch.order.activateRequest.queue

GLB_OrderActivate

Order cancellation isimplemented and

Order cancel requestpublish destination.

NAGLB_OrderCancel

achieved using orderamendmentfunctionality. TheOrchestrator doesn'tuse the queuespecified in this GVanymore. Hence thisGV is not carriedforward.

NAOrder submit requestpublish destination.


GLB_OrderSubmit





NAOrder suspendrequest publishdestination.

Suspend order request queuec.t.f.orch.order.suspendRequest.queue

GLB_OrderSuspend

NAOrder withdrawrequest publishdestination.


GLB_OrderWithdraw

NAPlan item activaterequest destination.

PlanItem activate request queuec.t.f.orch.planItem.activate.request.queue

GLB_PlanItemActivateRequest

NAPlan item executerequest destination.

PlanItem execution request queuec.t.f.orch.planItem.execute.request.queue

GLB_PlanItemExecuteRequest

NAPlan item executeresponse destination.

PlanItem suspend request queuec.t.f.orch.planItem.suspend.request.queue

GLB_PlanItemExecuteResponse

NAPlan item externaldependency releasedestination.

PlanItem External DependencyRelease Request queuec.t.f.orch.planItem.externalDependency.release.request.queue

GLB_PlanItemExternalDependencyReleaseRequest

NAPlan item milestonenotify destination

MilestoneNotifyRequest fromprocess components to

GLB_PlanItemMilestoneNotifyRequest

(Process Componentto Orchestrator).

Orchestrator queuec.t.f.orch.planItem.milestone.notifyRequest.queue

NAPlan item milestonerelease destination

MilestoneReleaseRequest fromOrchestrator to process

GLB_PlanItemMilestoneReleaseRequest

(Orchestrator toProcess Component).

components queuec.t.f.orch.planItem.milestone.releaseRequest.queue

NAPlan item suspendrequest destination.

PlanItem suspend request queuec.t.f.orch.planItem.suspend.request.queue

GLB_PlanItemSuspendRequest

NAPlan item suspendresponse destination.

PlanItem suspend response queuec.t.f.orch.planItem.suspend.response.queue

GLB_PlanItemSuspendResponse

Since Orchestrator isan integral part of

Set plan to OMSdestination.

NAGLB_PlanOMSSet

OMS now, it doesn'tuse the queuespecified in this GV.Hence it is notrelevant and notcarried forward.


Plan item set statusrequest destination.

NAGLB_PlanSetPlanItemStatusRequest





specified in this GVanymore. Hence thisGV is not relevantand not carriedforward.


Plan item set statusreply destination.

NAGLB_PlanSetPlanItemStatusResponse

specified in this GVanymore. Hence thisGV is not relevantand not carriedforward.

Since Orchestrator isan integral part of

Set plan OMSresponse destination.

NAGLB_PlanOMSSetResponse

OMS now, it doesn'tuse the queuespecified in this GV.Hence it is notrelevant and notcarried forward.


CleanUpOrderRequestdestination

NAGLB_InternalCleanUpOrderRequest



CleanUpPlanRequestdestination

NAGLB_InternalCleanUpPlanRequest


commonServices/configuration

The Orchestrator isJava based and uses

Log level to be used.NAGLB_LogLevel

the same Log4Jconfigurations usedby OMS fromomsServerLog4j.xmlfile. Hence this GV isnot carried forward.






Log level to be usedfor publishing thelogs.

NAGLB_LogPublishLevel


commonServices/flags


Flag to enable errorpublishing.

NAGLB_EnableError Publish



Flag to enableinstrumentationpublishing.

NAGLB_EnableInstrumentationPublish

instrumentationfunctionality inOrchestrator.


Flag to enable logpublishing.

NAGLB_EnableLogPublish


commonservices/interfaces/jms/events


NANANA

are relevant forOrchestrator sinceOrchestrator is anintegral part of OMSnow and uses the JMSconnection propertiesused by OMS. Hencethese GVs are notcarried forward inOrchestrator.





commonservices/messaging/jms/

All the jmsdestination name

String to be prefixedto each JMSdestination name.

NAGLB_MessagingPrefix

properties in OMScontains this prefix intheir value itself.Since beginning, thereis no separate prefixproperty. Hence thisGV is not carriedforward as a propertyin Orchestrator.

commonServices/messaging/jms/destinations


NAGLB_DiscoverEngineRequest



NAGLB_DiscoverEngineResponse



Exception publishtopic.

NAGLB_Exception



Get activeconfiguration variablerequest topic.

NAGLB_GetActiveConfigVariableRequest



Get activeconfiguration variableresponse topic.

NAGLB_GetActiveConfigVariableResponse

is not relevant andhence not carriedforward inOrchestrator. It was





BE implementationspecific.


Instrumentationpublish topic.

NAGLB_Instrumentation

instrumentationfunctionality inOrchestrator.


Log publish topic.NAGLB_Log




Global Variables and ConfigurationsThe following section lists the global variables in the OPE component and the configuration properties inOMS.

Offer and Price Engine (OPE)

The following are the global variables in the OPE component:

Default ValueDescriptionName

GenericConnectionFactoryJNDI Connection factory JNDIName

com.tibco.af.ope.jms.jndi.connectionfactory

GenericConnectionFactoryJNDI Initial Context Factorycom.tibco.af.ope.jms.jndi.initialContextFactory

tibjmsnaming://localhost:7222Full JNDI URL for JMS Servicecom.tibco.af.ope.jms.jndi.url

adminJNDI usernamecom.tibco.af.ope.jms.jndi.security.principal

adminJNDI passwordcom.tibco.af.ope.jms.jndi.security.credentials

trueOPE Cache Typecom.tibco.af.ope.cacheType

0The maximum number of productmodels that can be cached

com.tibco.af.ope.cacheType.cache.maxNoProductcached

0The minimum number of pricemodels that can be cached

com.tibco.af.ope.cacheType.cache.maxNoPriceCached

0The maximum number of discountmodels that can be cached

com.tibco.af.ope.cacheType.cache.maxNoDiscountCached

tibco.aff.ocv.events.products.purgeProduct model purge topiccom.tibco.fom.oms.afi.productmodel.purge.topic

tibco.aff.ocv.events.products.publishProduct model publish topiccom.tibco.fom.oms.afi.productmodel.publish.topic

tibco.aff.ope.opeServiceQueue for receiving SOAP OverJMS OPE Service requests

com.tibco.af.ope.opeService.queue

falseValidates UDFs attached to theproduct that are defined as inputcharacteristics of the product

com.tibco.af.ope.flags.chkrelevantoludfs

falseValidates mandatory characteristicsattached to the product model that

com.tibco.af.ope.flags.chkvalidoludfs

are found in the correspondingproduct instance as UDFs in therequest

falseValidates mandatory linking UDFsthat are attached as UDFs to theproduct in the order request

com.tibco.af.ope.flags.chkvalidlinkudfs

falseChecks if the RecordType is validcom.tibco.af.ope.flags.chkrecordtypevalid

falseSets no RecordStatus to activecom.tibco.af.ope.flags.setnorecordstatustoactive

falseValidates the data types fororderline udfs

com.tibco.af.ope.flags.validateudfdatatype




falseValidates the orderline UDFs arewithin the specified range specified

com.tibco.af.ope.flags.validateudfrange

falseValidates that the orderline UDFshave the values per the regex.

com.tibco.af.ope.flags.validateudfregex

[0-9]*.?[0-9]*The regular expression for currencycom.tibco.af.ope.flags.regexcurrency

[0-9]*.?[0-9]*"The regular expression for digitscom.tibco.af.ope.flags.regexdigits

[0-3]?[0-9]/[0-1][0-9]/[1-2][0-9]{3}The regular expression for date.com.tibco.af.ope.flags.regexdate

[0-2]?[0-9]:[0-5][0-9]The regular expression for time.com.tibco.af.ope.flags.regextime

TRUE|FALSEThe regular expression for boolean.com.tibco.af.ope.flags.regexboolean

EPMR_ACTION_PROVIDEThe udfs in this property will notbe shown as incompatible if theyare in the same order:

com.tibco.af.ope.flags.udfignorelist

EPMR_ACTION_UPDATE

EPMR_ACTION_CEASE

EPMR_ACTION_WITHDRAW

COMPENSATE_PROVIDE

COMPENSATE_UPDATE

COMPENSATE_CEASE

MODIFICATION_IDENTIFYING_ATTR

10000The maximum delay inmilliseconds for the fetching theproduct model.

com.tibco.af.ope.model.max.redelivery.delay

10000The model loading's minimum idletime in milliseconds.

com.tibco.af.ope.model.min.idle.delay

Order Management System

The following are the configuration properties in OMS:


10099JMX RMI Port.com.tibco.aff.oms.jmx.rmiport

tibco.aff.oms.statusNotification.order.queue

Order Status Notification Queue.com.tibco.af.oms.statusnotification.order.queue

2Order Status Notification QueueConcurrent Listener Count.

com.tibco.af.oms.statusnotification.order.queue.concurrentConsumersCount

tibco.aff.oms.statusNotification.orderLine.queue

Order Line Status NotificationQueue.

com.tibco.af.oms.statusnotification.orderLine.queue

1Order Line Status NotificationQueue Concurrent Listener Count.

com.tibco.af.oms.statusnotification.orderLine.queue.concurrentConsumersCount

tibco.aff.oms.statusNotification.plan.queue

Plan Status Notification Queue.com.tibco.af.oms.statusnotification.plan.queue




1Plan Status Notification QueueConcurrent Listener Count.

com.tibco.af.oms.statusnotification.plan.queue.concurrentConsumersCount

tibco.aff.oms.statusNotification.planItem.queue

Plan Item Status Notification Queue.com.tibco.af.oms.statusnotification.planItem.queue

6Plan Item Status Notification QueueConcurrent Listener Count.

com.tibco.af.oms.statusnotification.planItem.queue.concurrentConsumersCount

tibco.aff.oms.statusNotification.orderAmendment.queue

Order Amendment StatusNotification Queue.

com.tibco.af.oms.statusnotification.orderAmendment.queue

1Order Amendment StatusNotification Queue ConcurrentListener Count.

com.tibco.af.oms.statusnotification.orderAmendment.queue.concurrentConsumersCount

tibco.aff.oms.statusNotification.dead.queue

Status Notification Dead Queue.com.tibco.af.oms.statusnotification.dead.queue

tibco.aff.centrallog.queueCentral Log Queue.com.tibco.af.oms.centrallog.queue

1Central Log Queue ConcurrentListener Count.

com.tibco.af.oms.centrallog.queue.concurr entConsumersCount

tibco.aff.orchestrator.plan.oms.setSet Plan Queue.com.tibco.af.oms.setplan.queue

3Set Plan Queue Concurrent ListenerCount.

com.tibco.af.oms.setplan.queue.concurrentConsumersCount

tibco.aff.orchestrator.plan.oms.set.dead

Set Plan Dead Queue.com.tibco.af.oms.setplan.dead.queue

tibco.aff.orchestrator.plan.oms.set.reply

Set Plan Response Queue.com.tibco.af.oms.setplan.reply.queue

tibco.aff.oms.planfragmentmodelSet Plan Fragment Model Queue.com.tibco.af.oms.setplanfragmentmodel.queue

1Set Plan Fragment Model QueueConcurrent Listener Count.

com.tibco.af.oms.setplanfragmentmodel.queue.concurrentConsumersCount

tibco.aff.oms.planfragmentmodel.deadSet Plan Fragment Model DeadQueue.

com.tibco.af.oms.setplanfragmentmodel.dead.queue

tibco.aff.oms.setplanitemSet Plan Item Queue.com.tibco.af.oms.setplanitem.queue

1Set Plan Item Queue ConcurrentListener Count.

com.tibco.af.oms.setplanitem.queue.concurrentConsumersCount

1Synchronous Order SubmissionStatus Recovery Consumer Count.

com.tibco.af.oms.orderService.syncOrderStatusRecovery.concurrentConsumersCount

tibco.aff.oms.syncorderstatusrecovery

Synchronous Order SubmissionStatus Recovery Queue.

com.tibco.af.oms.orderService.syncOrderStatusRecovery.queue

tibco.aff.oms.setplanitem.deadSet Plan Item Dead Queue.com.tibco.af.oms.setplanitem.dead.queue

tibco.aff.oms.orderServiceQueue for receiving SOAP Over JMSOrder Service requests.

com.tibco.af.oms.ordersService.queue

1Minimum number of concurrentconsumers for listener (default 1).

com.tibco.af.oms.webservice.soap.jms.concurrentConsumers




5Maximum number of concurrentconsumers for listener (default 1).

com.tibco.af.oms.webservice.soap.jms.maxConcurrentConsumers

tibco.aff.oms.planItem.milestone.notify.request

Milestone Notify Request Queue.com.tibco.af.oms.milestone.notify.request.queue

3Milestone Notify Request QueueConcurrent Listener Count.

com.tibco.af.oms.milestone.notify.request.queue.concurrentConsumersCount

tibco.aff.orchestrator.oms.planItem.milestone.notify.request.dead

Milestone Notify Request DeadQueue.

com.tibco.af.oms.milestone.notify.request.dead.queue

tibco.aff.oms.planItem.milestone.release.request

Milestone Release Request Queue.com.tibco.af.oms.milestone.release.request.queue

3Milestone Release Request QueueConcurrent Listener Count.

com.tibco.af.oms.milestone.release.request.queue.concurrentConsumersCount

tibco.aff.orchestrator.oms.planItem.milestone.release.request.dead

Milestone Release Request DeadQueue.

com.tibco.af.oms.milestone.release.request.dead.queue

tibco.aff.oms.events.jeopardy.updateJeopardy Events Update Queue.com.tibco.af.oms.events.jeopardy.update.queue

1Jeopardy Events Update QueueConcurrent Listener Count.

com.tibco.af.oms.events.jeopardy.update.queue.concurrentConsumersCount

com.tibco.aff.deadJeopardy Events Update DeadQueue.

com.tibco.af.oms.events.jeopardy.update.dead.queue

com.tibco.aff.deadAFF Dead Queue.com.tibco.af.dead.queue

1Purge Order Reply Queue forOrchestrator Concurrent ListenerCount.

com.tibco.af.oms.router.destination.beoPurgeOrder.reply.queue.concurrentConsumersCount

tibco.aff.oms.plan.migrated.requestEnrich Migrated Plan RequestQueue.

com.tibco.af.oms.plan.migrated.request

tibco.aff.oms.plan.migrated.responseEnrich Migrated Plan ResponseQueue.

com.tibco.af.oms.plan.migrated.response

30000Enrich Migrated Plan Timeout.com.tibco.af.oms.migratedPlanTimeOut

tibco.aff.oms.jeoms.update.ruleUpdate Jeopardy Configuration RuleQueue.

com.tibco.af.oms.jeoms.update.rule

3Maximum number of times theStatus Message to be retried.

com.tibco.af.oms.statusmessage.max.redeliveries

3000Interval delay in millisecs betweenStatus Message retries.

com.tibco.af.oms.statusmessage.redelivery.delay

30000Maximum delay in millisecs ForStatus Message retries.

com.tibco.af.oms.statusmessage.max.redelivery.delay

FALSEUse Exponential backoff For StatusMessage retries.

com.tibco.af.oms.statusmessage.useExponentialBackOff

2Exponential backoff Multiplier ForStatus Message retries.

com.tibco.af.oms.statusmessage.exponentialBackOffMultiplier




FALSELog retry attempt For StatusMessage retries.

com.tibco.af.oms.statusmessage.logRetryAttempted

FALSELog retry failed stacktrace For StatusMessage retries.

com.tibco.af.oms.statusmessage.logStackTrace

passthroughRouterRouter Type.com.tibco.af.oms.router.type

tibco.aff.orchestrator.order.withdraw

Withdraw Order Queue forOrchestrator.

com.tibco.af.oms.router.destination.beoWithdrawOrder

tibco.aff.orchestrator.order.submitResponse

Submit Order Queue forOrchestrator.

com.tibco.af.oms.router.destination.beoSubmitOrderReply

30000Request time out for synchronousorder submission.

com.tibco.af.oms.syncSubmitOrderRequestTimeout

tibco.aff.orchestrator.order.submitSubmit Order Queue forOrchestrator.

com.tibco.af.oms.router.destination.beoSubmitOrder

tibco.aff.orchestrator.order.submitAmend Order Queue forOrchestrator.

com.tibco.af.oms.router.destination.beoAmendOrder

tibco.aff.orchestrator.order.submitCancel Order Queue forOrchestrator.

com.tibco.af.oms.router.destination.beoCancelOrder

tibco.aff.orchestrator.order.activate

Resume Order Queue forOrchestrator.

com.tibco.af.oms.router.destination.beoResumeOrder

tibco.aff.orchestrator.order.suspendSuspend Order Queue forOrchestrator.

com.tibco.af.oms.router.destination.beoSuspendOrder

tibco.aff.orchestrator.data.order.delete.request

Purge Order Request Queue forOrchestrator.

com.tibco.af.oms.router.destination.beoPurgeOrder

tibco.aff.orchestrator.data.order.delete.reply

Purge Order Reply Queue forOrchestrator.

com.tibco.af.oms.router.destination.beoPurgeOrder.reply

../../routerRecoveryFileFolderPath to folder containing RouterRecovery Files.

com.tibco.af.oms.router.recoveryFileFolderPath

filteringRouterRouter Type.com.tibco.af.oms.router.type

tibco.aff.orchestrator.order.submitResponse

Submit Order Queue forOrchestrator.

com.tibco.af.oms.router.destination.beoSubmitOrderReply

30000Request time out for synchronousorder submission.

com.tibco.af.oms.syncSubmitOrderRequestTimeout

/SubmitOrderRequest/orderRequest/header/udf[name='Orchestrator']/value/text()

Xpath filter Condition.com.tibco.af.oms.router.filterCondition

tibco.aff.orchestrator.order.submitSubmit Order Queue forOrchestrator.

com.tibco.af.oms.router.destination.beoSubmitOrder

tibco.aff.ipc.order.submitSubmit Order Queue for IPC.com.tibco.af.oms.router.destination.ipcSubmitOrder

tibco.aff.orchestrator.order.withdraw

Withdraw Order Queue forOrchestrator.

com.tibco.af.oms.router.destination.beoWithdrawOrder




tibco.aff.ipc.order.withdrawWithdraw Order Queue for iPC.com.tibco.af.oms.router.destination.ipcWithdrawOrder

tibco.aff.ipc.order.submitResponseSubmit Order Queue forOrchestrator.

com.tibco.af.oms.router.destination.ipcSubmitOrderReply

tibco.aff.orchestrator.order.submitAmend Order Queue forOrchestrator.

com.tibco.af.oms.router.destination.beoAmendOrder

tibco.aff.ipc.order.amendAmend Order Queue for IPC.com.tibco.af.oms.router.destination.ipcAmendOrder

tibco.aff.orchestrator.order.submitCancel Order Queue forOrchestrator.

com.tibco.af.oms.router.destination.beoCancelOrder

tibco.aff.ipc.order.submitCancel Order Queue for iPC.com.tibco.af.oms.router.destination.ipcCancelOrder

tibco.aff.orchestrator.order.activate

Resume Order Queue forOrchestrator.

com.tibco.af.oms.router.destination.beoResumeOrder

tibco.aff.ipc.order.activateResume Order Queue for iPC.com.tibco.af.oms.router.destination.ipcResumeOrder

tibco.aff.orchestrator.order.suspendSuspend Order Queue forOrchestrator.

com.tibco.af.oms.router.destination.beoSuspendOrder

tibco.aff.ipc.order.suspendSuspend Order Queue for iPC.com.tibco.af.oms.router.destination.ipcSuspendOrder

../../routerRecoveryFileFolderPath to folder containing RouterRecovery Files.

com.tibco.af.oms.router.recoveryFileFolderPath

org.hibernate.dialect.Oracle10gDialect

com.tibco.af.oms.hibernate.dialect

FALSEHibernate Second Level CacheUsage.

com.tibco.af.oms.hibernate.cache.use_second_level_cache

org.hibernate.cache.NoCacheProviderHibernate Cache Provider Class.com.tibco.af.oms.hibernate.cache.provider_class

org.hibernate.transaction.JDBCTransactionFactory

Hibernate Transaction Factory Class.com.tibco.af.oms.hibernate.transaction.factory_class

threadHibernate Session Context Class.com.tibco.af.oms.hibernate.current_session_context_class

30Hibernate JDBC Batch size.com.tibco.af.oms.hibernate.jdbc.batch_size

FALSEHibernate Show SQL.com.tibco.af.oms.hibernate.show_sql

aff_omsHibernate Default Catalog.com.tibco.af.oms.hibernate.default_catalog

aff_oms_archiveHibernate Default Archive Catalog.com.tibco.af.oms.hibernate.default_archive_catalog

com.tibco.af.omsui.httpChannelType

8080com.tibco.af.omsui.http.port




8443com.tibco.af.omsui.https.port

TRUEEnable the Record count fetch forpagination. This will make the data

com.tibco.af.omsui.enableRecordCountFetch

fetch slower and enable Last Pageoption in pagination.

com.tibco.af.omsui.session-fixation-protection

localhostHost address of the OMS server.com.tibco.af.omsServer.proxyHost

TRUEEnable FP configuration.com.tibco.af.fpServer.enableConfiguration

knodeNode name of the FP server.com.tibco.af.fpServer.nodeName

localhostHost address of the FP server.com.tibco.af.fpServer.proxyHost

FPOwner for FP.com.tibco.af.fpServer.fpPlanFragmentType

8080Port number of the OMS Server.com.tibco.af.omsServer.proxyPort

8080Port number of the FP Server.com.tibco.af.fpServer.proxyPort

1com.tibco.af.concurrencyControl.maxSessionPerUser

Month[MM] and Year [yyyy])OMS UI Short Date Format (Day[dd].

com.tibco.af.omsui.shortDateFormat

Month [MM]OMS UI Long Date Time Format(Day [dd].

com.tibco.af.omsui.longDateFormat


com.tibco.af.omsui.longDateFormatTimeZone


com.tibco.af.omsui.longDateFormatTimeZoneMillis

{PlanItemID}OMS UI PlanItem Display Templatefor Grid View. Possible template

com.tibco.af.omsui.planItemExpression.gridView

variables are - PlanItemID,PlanFragmentID, ProductID, Actionand Description; these templatevariables are case sensitive and haveto be specified within curly braces{}. Different template variables canbe combined with any type ofdelimiter e.g.{PlanFragmentID}|{PlanItemID}.

{Description}OMS UI PlanItem Display Templatefor Gantt View. Possible template

com.tibco.af.omsui.planItemExpression.ganttView

variables are - PlanItemID,PlanFragmentID,ProductID, Actionand Description; these templatevariables are case sensitive and haveto be specified within curly braces{}. Different template variables canbe combined with any type of




delimiter e.g.{PlanFragmentID}|{PlanItemID}.

{Description}|{PlanItemID}OMS UI PlanItem Display Templatefor Dependency View. Possible

com.tibco.af.omsui.planItemExpression.dependencyView

template variables are - PlanItemID,PlanFragmentID, ProductID, Actionand Description; these templatevariables are case sensitive and haveto be specified within curly braces{}. Different template variables canbe combined with any type ofdelimiter e.g.{PlanFragmentID}|{PlanItemID}"name="PlanItem Template forDependency View.

4Purge Thread Count.com.tibco.af.purge.threads.count

FALSEPublishInventoryNotifications.com.tibco.aff.PublishInventoryNotifications

tibco.aff.catalog.product.requestProduct model receiver queue.valuecom.tibco.fom.oms.afi.productmodel.receiver.queue

3Product model receiver count.com.tibco.fom.oms.afi.productmodel.receiver.count

tibco.aff.ocv.events.products.publish

Product model publish topic.com.tibco.fom.oms.afi.productmodel.publish.topic

tibco.aff.catalog.customer.requestCustomer model receiver queue.com.tibco.fom.oms.afi.customermodel.receiver.queue

3Customer model receiver count.com.tibco.fom.oms.afi.customermodel.receiver.count

tibco.aff.catalog.segment.requestSegment model receiver queue.com.tibco.fom.oms.afi.segmentmodel.receiver.queue

3Segment model receiver count.com.tibco.fom.oms.afi.segmentmodel.receiver.count

tibco.aff.catalog.planfragment.request

PlanFragment model receiver queue.com.tibco.fom.oms.afi.planfragmentmodel.receiver.queue

3PlanFragment model receiver count.com.tibco.fom.oms.afi.planfragmentmodel.receiver.count

tibco.aff.orchestrator.model.processComponent.pub

ProcessComponent model publishtopic.

com.tibco.fom.oms.afi.planfragmentmodel.publish.topic

tibco.aff.catalog.action.requestAction model receiver queue.com.tibco.fom.oms.afi.actionmodel.receiver.queue

3Action model receiver count.com.tibco.fom.oms.afi.actionmodel.receiver.count

tibco.aff.ocv.events.actions.publishAction model publish topic.com.tibco.fom.oms.afi.actionmodel.publish.topic




tibco.aff.catalog.events.requestProduct customer segment modelinvocation event request receiverqueue.

com.tibco.fom.oms.afi.pcsmodel.event.request.queue

1Product customer segment modelinvocation event request receivercount.

com.tibco.fom.oms.afi.pcsmodel.event.receiver.count

tibco.aff.orchestrator.startup.event.request

Plan fragment model invocationevent request receiver queue.

com.tibco.fom.oms.afi.pfmodel.event.request.queue

1Plan fragment model invocationevent request receiver count.

com.tibco.fom.oms.afi.pfmodel.event.request.receiver.count

localhostServer host.com.tibco.fom.oms.afi.fcintegration.host

8800Server port.com.tibco.fom.oms.afi.fcintegration.port

ACEnterprise name.com.tibco.fom.oms.afi.fcintegration.enterprise

adminUsername.com.tibco.fom.oms.afi.fcintegration.username

adminPassword.com.tibco.fom.oms.afi.fcintegration.password

SVC-11045Workflow invocation responsesuccess code.

com.tibco.fom.oms.afi.fcintegration.workflow.response.success.code

Workflow initiated successfully.Workflow invocation responsesuccess message.

com.tibco.fom.oms.afi.fcintegration.workflow.response.success.message

PRODUCTMaster catalog name.com.tibco.fom.oms.afi.fcintegration.product.mctname

BU_000001Product record ID.com.tibco.fom.oms.afi.fcintegration.product.id

Product record ID extension.com.tibco.fom.oms.afi.fcintegration.product.idext

PARTYMaster catalog name.com.tibco.fom.oms.afi.fcintegration.customer.mctname

68000001Customer record ID.com.tibco.fom.oms.afi.fcintegration.customer.id

Customer record ID extension.com.tibco.fom.oms.afi.fcintegration.customer.idext

SEGMENTMaster catalog name.com.tibco.fom.oms.afi.fcintegration.segment.mctname

PB_000001Segment record ID.com.tibco.fom.oms.afi.fcintegration.segment.id

Segment record ID extension.com.tibco.fom.oms.afi.fcintegration.segment.idext




PLANFRAGMENTMaster catalog name.com.tibco.fom.oms.afi.fcintegration.planfragment.mctname

PF_00001PlanFragment record ID.com.tibco.fom.oms.afi.fcintegration.planfragment.id

PlanFragment record ID extension.com.tibco.fom.oms.afi.fcintegration.planfragment.idext

ACTIONMaster catalog name.com.tibco.fom.oms.afi.fcintegration.action.mctname

ProvideAction record ID.com.tibco.fom.oms.afi.fcintegration.action.id

Action record ID extension.com.tibco.fom.oms.afi.fcintegration.action.idext

60Polling interval in seconds.com.tibco.fom.oms.afi.offline.common.polling.interval

30Catalog request interval inmilliseconds.

com.tibco.fom.oms.afi.offline.common.catalogrequest.interval

FALSEUse offline product.com.tibco.fom.oms.afi.offline.product.use

/usr/tibco/product/masterOffline product catalog masterdirectory.

com.tibco.fom.oms.afi.offline.product.master.directory

/usr/tibco/product-success/masterOffline product catalog importsuccess master directory.

com.tibco.fom.oms.afi.offline.product.master.importsuccess.directory

/usr/tibco/product-failure/masterOffline product catalog importfailure master directory.

com.tibco.fom.oms.afi.offline.product.master.importfailure.directory

/usr/tibco/productOffline product catalog directory.com.tibco.fom.oms.afi.offline.product.directory

/usr/tibco/product-successOffline product catalog importsuccess directory.

com.tibco.fom.oms.afi.offline.product.importsuccess.directory

/usr/tibco/product-failureOffline product catalog importfailure directory.

com.tibco.fom.oms.afi.offline.product.importfailure.directory

FALSEUse offline customer.com.tibco.fom.oms.afi.offline.customer.use

/usr/tibco/customer/masterOffline customer catalog masterdirectory.

com.tibco.fom.oms.afi.offline.customer.master.directory

/usr/tibco/customer-success/masterOffline customer catalog importsuccess master directory.

com.tibco.fom.oms.afi.offline.customer.master.importsuccess.directory

/usr/tibco/customer-failure/masterOffline customer catalog importfailure master directory.

com.tibco.fom.oms.afi.offline.customer.master.importfailure.directory

/usr/tibco/customerOffline customer catalog directory.com.tibco.fom.oms.afi.offline.customer.directory

/usr/tibco/customer-successOffline customer catalog importsuccess directory.

com.tibco.fom.oms.afi.offline.customer.importsuccess.directory




/usr/tibco/customer-failureOffline customer catalog importfailure directory.

com.tibco.fom.oms.afi.offline.customer.importfailure.directory

FALSEUse offline segment.com.tibco.fom.oms.afi.offline.segment.use

/usr/tibco/segment/masterOffline segment catalog masterdirectory.

com.tibco.fom.oms.afi.offline.segment.master.directory

/usr/tibco/segment-success/masterOffline segment catalog importsuccess master directory.

com.tibco.fom.oms.afi.offline.segment.master.importsuccess.directory

/usr/tibco/segment-failure/masterOffline segment catalog importfailure master directory.

com.tibco.fom.oms.afi.offline.segment.master.importfailure.directory

/usr/tibco/segmentOffline segment catalog directorycom.tibco.fom.oms.afi.offline.segment.directory

/usr/tibco/segment-successOffline segment catalog importsuccess directory.

com.tibco.fom.oms.afi.offline.segment.importsuccess.directory

/usr/tibco/segment-failureOffline segment catalog importfailure directory.

com.tibco.fom.oms.afi.offline.segment.importfailure.directory

FALSEUse offline planfragment.com.tibco.fom.oms.afi.offline.planfragment.use

/usr/tibco/planfragment/masterOffline planfragment catalog masterdirectory.

com.tibco.fom.oms.afi.offline.planfragment.master.directory

/usr/tibco/planfragment-success/master

Offline planfragment catalog importsuccess master directory.

com.tibco.fom.oms.afi.offline.planfragment.master.importsuccess.directory

/usr/tibco/planfragment-failure/master

Offline planfragment catalog importfailure master directory.

com.tibco.fom.oms.afi.offline.planfragment.master.importfailure.directory

/usr/tibco/planfragmentOffline planfragment catalogdirectory.

com.tibco.fom.oms.afi.offline.planfragment.directory

/usr/tibco/planfragment-successOffline planfragment catalog importsuccess directory.

com.tibco.fom.oms.afi.offline.planfragment.importsuccess.directory

/usr/tibco/planfragment-failureOffline planfragment catalog importfailure directory.

com.tibco.fom.oms.afi.offline.planfragment.importfailure.directory

FALSEUse offline action.com.tibco.fom.oms.afi.offline.action.use

/usr/tibco/action/masterOffline action catalog masterdirectory.

com.tibco.fom.oms.afi.offline.action.master.directory

/usr/tibco/action-success/masterOffline action catalog import successmaster directory.

com.tibco.fom.oms.afi.offline.action.master.importsuccess.directory

/usr/tibco/action-failure/masterOffline action catalog import failuremaster directory.

com.tibco.fom.oms.afi.offline.action.master.importfailure.directory

/usr/tibco/actionOffline action catalog directory.com.tibco.fom.oms.afi.offline.action.directory

/usr/tibco/action-successOffline action catalog import successdirectory.

com.tibco.fom.oms.afi.offline.action.importsuccess.directory




/usr/tibco/action-failureOffline action catalog import failuredirectory.

com.tibco.fom.oms.afi.offline.action.importfailure.directory

tibco.aff.orchestrator.provider.order.opd.request

OPDRequest from Orchestratorreceiver queue.

com.tibco.fom.oms.afi.orch.opdrequest.receiver.queue

3OPDRequest from Orchestratorreceiver count.

com.tibco.fom.oms.afi.orch.opdrequest.receiver.count

tibco.aff.ocv.events.plan.new.request

ExecutionPlanNewRequest to AOPDsender queue.

com.tibco.fom.oms.afi.aopd.newplanrequest.sender.queue

tibco.aff.ocv.events.plan.amend.request

ExecutionPlanAmendRequest toAOPD sender queue.

com.tibco.fom.oms.afi.aopd.amendplanrequest.sender.queue

tibco.aff.ocv.events.newplan.replyExecutionPlanNewResponse fromAOPD receiver queue.

com.tibco.fom.oms.afi.aopd.newplanresponse.receiver.queue

3ExecutionPlanNewResponse fromAOPD receiver count.

com.tibco.fom.oms.afi.aopd.newplanresponse.receiver.count

tibco.aff.ocv.events.amendplan.replyExecutionPlanAmendResponse fromAOPD receiver queue.

com.tibco.fom.oms.afi.aopd.amendplanresponse.receiver.queue

3ExecutionPlanAmendResponse fromAOPD receiver count.

com.tibco.fom.oms.afi.aopd.amendplanresponse.receiver.count

tibco.aff.orchestrator.provider.order.opd.reply

OPDResponse to Orchestratorsender queue.

com.tibco.fom.oms.afi.orch.opdresponse.sender.queue

FALSEMerge inventory in AOPD request.com.tibco.fom.oms.afi.aopd.merge.inventory

tibco.aff.tds.order.read.requestGetOrderRequest receiver queue.com.tibco.fom.oms.tds.getorderrequest.receiver.queue

3GetOrderRequest receiver count.com.tibco.fom.oms.tds.getorderrequest.receiver.count

tibco.aff.oms.tds.order.read.request.dead

GetOrderRequest receiver deadqueue.

com.tibco.fom.oms.tds.getorderrequest.receiver.deadqueue

tibco.aff.tds.order.replyGetOrderResponse sender queue.com.tibco.fom.oms.tds.getorderresponse.sender.queue

tibco.aff.tds.plan.read.requestGetPlan/GetPlanItem Requestreceiver queue.

com.tibco.fom.oms.tds.getplanrequest.receiver.queue

3GetPlan/GetPlanItem Requestreceiver count.

com.tibco.fom.oms.tds.getplanrequest.receiver.count

tibco.aff.oms.tds.plan.read.request.dead

GetPlan/GetPlanItem Requestreceiver dead queue.

com.tibco.fom.oms.tds.getplanrequest.receiver.deadqueue

tibco.aff.tds.plan.replyGetPlan/GetPlanItem Responsesender queue.

com.tibco.fom.oms.tds.getplanresponse.sender.queue

tibco.aff.tds.plan.requestSetPlan/SetPlanItem Requestreceiver queue.

com.tibco.fom.oms.tds.setplanrequest.receiver.queue




3SetPlan/SetPlanItem Requestreceiver count.

com.tibco.fom.oms.tds.setplanrequest.receiver.count

tibco.aff.oms.tds.plan.request.deadSetPlan/SetPlanItem Requestreceiver dead queue.

com.tibco.fom.oms.tds.setplanrequest.receiver.deadqueue

tibco.aff.tds.plan.replySetPlan/SetPlanItem Responsesender queue.

com.tibco.fom.oms.tds.setplanresponse.sender.queue

TRUEFlag to enable unique UDF names topermit updates on UDF values.

com.tibco.fom.oms.tds.enable.unique.udfname

60000Wait Timeout for listening toresponse from JMS Destination.

com.tibco.afs.destination.listen.timeout

tibco.aff.ocv.events.offer.validate.request

Queue where request for validatingthe offer is posted.


GenericConnectionFactoryJNDI Connection factory JNDIName.

com.tibco.af.oms.jms.jndi.ConnectionFactory

com.tibco.tibjms.naming.TibjmsInitialContextFactory

JNDI Initial Context Factory.com.tibco.af.oms.jms.jndi.initialContextFactory

tibjmsnaming://localhost:7222JNDI URL for JMS Service.com.tibco.af.oms.jms.jndi.url

adminJNDI Username.com.tibco.af.oms.jms.jndi.security.principal

adminJNDI Password.com.tibco.af.oms.jms.jndi.security.credentials

QueueConnectionFactoryBE Orchestrator Queue Connectionfactory JNDI Name.

com.tibco.af.oms.jms.jndi.cf.beo

1BE Orchestrator JMS Delivery Mode.com.tibco.af.oms.jms.cf.beo.deliverymode

FALSEBE Orchestrator JMS QoS Enabled?com.tibco.af.oms.jms.cf.beo.qosEnabled

GenericConnectionFactoryIPC Queue Connection factory JNDIName.

com.tibco.af.oms.jms.jndi.cf.ipc

1IPC JMS Delivery Mode.com.tibco.af.oms.jms.cf.ipc.deliverymode

FALSEIPC JMS QoS Enabled.com.tibco.af.oms.jms.cf.ipc.qosEnabled

QueueConnection FactoryOPE Queue Connection factory JNDINamecom.tibco.af.oms.jms. jndi.cf.

ope

1OPE JMS Delivery Mode.com.tibco.af.oms.jms.cf.ope.

deliverymode

TRUEOPE JMS JMS QoS Enabled.com.tibco.af.oms.jms.cf.OPE.

qosEnabled

oracle.jdbc.driver.OracleDriverPooled Data Source Driver ClassName.

com.tibco.af.oms.pooledDataSource.driverClassName




localhostPooled Data Source Host.com.tibco.af.oms.pooledDataSource.host

1521Pooled Data Source Port.com.tibco.af.oms.pooledDataSource.port

orclPooled Data Source Database.com.tibco.af.oms.pooledDataSource.database

aff_omsPooled Data Source Username.com.tibco.af.oms.pooledDataSource.username

aff_omsPooled Data Source Password.com.tibco.af.oms.pooledDataSource.password

jdbc:oracle:thin:@//${com.tibco.af.oms.pooledDataSource.host}:${com.

tibco.af.oms.pooledDataSource.

Pooled Data Source URL.com.tibco.af.oms.pooledDataSource.url

port}/${com.tibco.af.oms.

pooledDataSource.database}

2Pooled Data Source Initialize Size.com.tibco.af.oms.pooledDataSource.initializeSize

8Pooled Data Source Max Idle.com.tibco.af.oms.pooledDataSource.maxIdle

12Pooled Data Source Max Active.com.tibco.af.oms.pooledDataSource.maxActive

10000Pooled Data Source Max Wait.com.tibco.af.oms.pooledDataSource.maxWait

select 1 from dualPooled Data Source ValidationQuery.

com.tibco.af.oms.pooledDataSource.validationQuery

FALSEPooled Data Source Test OnBorrow.com.tibco.af.oms.pooledDataSource.testOnBorrow

TRUEPooled Data Source Test WhileIdle.com.tibco.af.oms.pooledDataSource.testWhileIdle

1200000Pooled Data Source EvictionInterval.

com.tibco.af.oms.pooledDataSource.timeBetweenEvictionRunsMillis

1800000Pooled Data Source MinimumEvictable Idle Time.

com.tibco.af.oms.pooledDataSource.minEvictableIdleTimeMillis

5Pooled Data Source Tests PerEviction Run.

com.tibco.af.oms.pooledDataSource.numTestsPerEvictionRun

FALSEPooled Data Source DefaultAutoCommit.

com.tibco.af.oms.pooledDataSource.defaultAutoCommit

oracle.jdbc.driver.OracleDriverPooled Data Source Driver ClassName.

com.tibco.af.oms.pooledArchiveDataSource.driverClassName

localhostPooled Data Source Host.com.tibco.af.oms.pooledArchiveDataSource.host

1521Pooled Data Source Port.com.tibco.af.oms.pooledArchiveDataSource.port




orclPooled Data Source Database.com.tibco.af.oms.pooledArchiveDataSource.database

aff_oms_archivePooled Data Source Username.com.tibco.af.oms.pooledArchiveDataSource.username

aff_oms_archivePooled Data Source Password.com.tibco.af.oms.pooledArchiveDataSource.password

jdbc:oracle:thin:@//${com.tibco.af.oms.pooledArchiveDataSource.host}:

${com.tibco.af.oms.

Pooled Data Source URL.com.tibco.af.oms.pooledArchiveDataSource.url

pooledArchiveDataSource.port}/

${com.tibco.af.oms.

pooledArchiveDataSource.database}

2Pooled Data Source Initialize Size.com.tibco.af.oms.pooledArchiveDataSource.initializeSize

8Pooled Data Source Max Idle.com.tibco.af.oms.pooledArchiveDataSource.maxIdle

12Pooled Data Source Max Active.com.tibco.af.oms.pooledArchiveDataSource.maxActive

10000Pooled Data Source Max Wait.com.tibco.af.oms.pooledArchiveDataSource.maxWait

select 1 from dualPooled Data Source ValidationQuery.

com.tibco.af.oms.pooledArchiveDataSource.validationQuery

FALSEPooled Data Source Test OnBorrow.com.tibco.af.oms.pooledArchiveDataSource.testOnBorrow

TRUEPooled Data Source Test WhileIdle.com.tibco.af.oms.pooledArchiveDataSource.testWhileIdle

1200000Pooled Data Source EvictionInterval.

com.tibco.af.oms.pooledArchiveDataSource.timeBetweenEvictionRunsMillis

1800000Pooled Data Source MinimumEvictable Idle Time.

com.tibco.af.oms.pooledArchiveDataSource.minEvictableIdleTimeMillis

5Pooled Data Source Tests PerEviction Run.

com.tibco.af.oms.pooledArchiveDataSource.numTestsPerEvictionRun

FALSEPooled Data Source DefaultAutoCommit.

com.tibco.af.oms.pooledArchiveDataSource.defaultAutoCommit

defaultAuthenticationProviderDefault Authentication Provider.com.tibco.af.oms.security.authProvider

ldapAuthenticationProviderLdap Authentication Provider.com.tibco.af.oms.security.authProvider

ldap://localhost:389/dc=omsLDAP Server URL.com.tibco.af.oms.security.authProvider.ldap.server.url

uid=adminLDAP User Manager ID.com.tibco.af.oms.security.authProvider.ldap.server.userDn




passwordLDAP User Manager Password.com.tibco.af.oms.security.authProvider.ldap.server.password

ou=usersUser SearchBase.com.tibco.af.oms.security.authProvider.ldap.user.searchBase

(uid={0})User Search Filter.com.tibco.af.oms.security.authProvider.ldap.user.userSearchFilter

ou=GroupsGroup Search Base.com.tibco.af.oms.security.authProvider.ldap.role.groupSearchBase

cnGroup Role Attribute.com.tibco.af.oms.security.authProvider.ldap.role.groupRoleAttribute

uniqueMember={0}Group Search Filter.com.tibco.af.oms.security.authProvider.ldap.role.groupSearchFilter

FALSESeach Sub Tree.com.tibco.af.oms.security.authProvider.ldap.role.searchSubTree

TRUEconvert values To UpperCase.com.tibco.af.oms.security.authProvider.ldap.role.convertToUpperCase

FALSEEnable Offer and Price Enginecom.tibco.af.oms.OCVEnabled

60000Offer and Price EngineTimeout.com.tibco.af.oms.OCVTimeOut


Offer and Price Engine RequestQueue.

com.tibco.af.oms.ocv.request

tibco.aff.ocv.events.offer.validate.reply.oms

Offer and Price Engine ResponseQueue. Specify a different queuename for OMS than other OPEclients.

com.tibco.af.oms.ocv.response

TRUEEnable or disable logging ofexception stack trace in OMS whenOffer and Price Engine fails.

com.tibco.af.oms.OCVExceptionLoggingEnabled

TRUEEnable User Name token basedSecurity.

com.tibco.af.oms.webservice.security.userNameTokenBased

TRUEEnable Schema validation.com.tibco.af.oms.webservice.schema.validation

TRUEEnable Submit Order Web ServiceIdempotency.

com.tibco.af.oms.webservice.idempotency

HTTP Channel type.com.tibco.af.oms.webservice.httpChannelType

8080com.tibco.af.oms.http.port

8443com.tibco.af.oms.https.port

FALSEUse external business transactionIdas business transaction id withinOMS.

com.tibco.af.oms.webservice.useExternalBusinessTransactionId




150000Time out value in millisecond fororder lock.

com.tibco.af.oms.updateToken.timeout

1000Nonce validity time in Milliseconds.com.tibco.af.oms.none.validityWindow

0Delay to be introduced beforepersisting order objects.

com.tibco.af.oms.persistenceDelay

0Delay to be introduced beforevalidating orders.

com.tibco.af.oms.orderValidationDelay

onStatusChangeOrder Summary collection on everyorder status change.

com.tibco.af.oms.summaryDataCollectionMethod

scheduledOrder Summary collection onscheduled interval.

com.tibco.af.oms.summaryDataCollectionMethod

0 0 * * * ?schedule interaval for ordersummary data collection.

com.tibco.af.oms.summaryDataCollection.scheduled.cronExpress



Glossary

AOPD

Automatic Order Plan Development (AOPD) is a component that generates execution plan based on productmodel and submitted order(s).

Accessed through a JMS event interfaceCache

Cache saves order data in a persistent data store, as well as stores transient order data throughout the orderlifecycle. This component serves order and plan data to client Process Components when requested, andupdates 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. Feasibilitychecking is an optional step in the order lifecycle and it may involve validating the order containing therequired products, physical network capacity checking, or inventory stock level check. The Feasibility Provideris a customer-implemented component because feasibility checking is highly customized to the requirementsof 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 ManagementAOPD system accesses the Product Catalog through JMS. The Plan Fragment Model definitions repositoriesdescribing 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, witheach line corresponding to a requested product. Order lines are an abstraction of the work that will be doneas 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, aplan consists of plan items.

Plan Fragment

A plan fragment is an abstraction of a Process Component that contains configuration information thatOrchestrator 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 togetherand are executed as a single task during provisioning. Product Affinity is specified in the product catalog.


tibco fulfillment order management user's guide · • tibco fulfillment order management...

Documents