TIBCO® Fulfillment Order Management Administration

Transcription

TIBCO® Fulfillment Order
Management Administration
Software Release 2.0.1
March 2013
Important Information
SOME TIBCO SOFTWARE EMBEDS OR BUNDLES OTHER TIBCO SOFTWARE. USE OF SUCH EMBEDDED
OR BUNDLED TIBCO SOFTWARE IS SOLELY TO ENABLE THE FUNCTIONALITY (OR PROVIDE LIMITED
ADD-ON FUNCTIONALITY) OF THE LICENSED TIBCO SOFTWARE. THE EMBEDDED OR BUNDLED
SOFTWARE IS NOT LICENSED TO BE USED OR ACCESSED BY ANY OTHER TIBCO SOFTWARE OR FOR
ANY OTHER PURPOSE.
USE OF TIBCO SOFTWARE AND THIS DOCUMENT IS SUBJECT TO THE TERMS AND CONDITIONS OF A
LICENSE AGREEMENT FOUND IN EITHER A SEPARATELY EXECUTED SOFTWARE LICENSE AGREEMENT,
OR, IF THERE IS NO SUCH SEPARATE AGREEMENT, THE CLICKWRAP END USER LICENSE AGREEMENT
WHICH IS DISPLAYED DURING DOWNLOAD OR INSTALLATION OF THE SOFTWARE (AND WHICH IS
DUPLICATED IN LICENSE.PDF) OR IF THERE IS NO SUCH SOFTWARE LICENSE AGREEMENT OR
CLICKWRAP END USER LICENSE AGREEMENT, THE LICENSE(S) LOCATED IN THE “LICENSE” FILE(S) OF
THE SOFTWARE. USE OF THIS DOCUMENT IS SUBJECT TO THOSE TERMS AND CONDITIONS, AND YOUR
USE HEREOF SHALL CONSTITUTE ACCEPTANCE OF AND AN AGREEMENT TO BE BOUND BY THE SAME.
This document contains confidential information that is subject to U.S. and international copyright laws and treaties.
No part of this document may be reproduced in any form without the written authorization of TIBCO Software
Inc.
TIBCO, Two-Second Advantage, TIBCO ActiveMatrix BusinessWorks, TIBCO Runtime Agent, TIBCO Administrator,
TIBCO Enterprise Message Service, and TIBCO BusinessEvents are either registered trademarks or trademarks of
TIBCO Software Inc. in the United States and/or other countries.
EJB, Java EE, J2EE, and all Java-based trademarks and logos are trademarks or registered trademarks of Sun
Microsystems, Inc. in the U.S. and other countries.
All other product and company names and marks mentioned in this document are the property of their respective
owners and are mentioned for identification purposes only.
THIS SOFTWARE MAY BE AVAILABLE ON MULTIPLE OPERATING SYSTEMS. HOWEVER, NOT ALL
OPERATING SYSTEM PLATFORMS FOR A SPECIFIC SOFTWARE VERSION ARE RELEASED AT THE SAME
TIME. SEE THE README FILE FOR THE AVAILABILITY OF THIS SOFTWARE VERSION ON A SPECIFIC
OPERATING SYSTEM PLATFORM.
THIS DOCUMENT IS PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR
IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT.
THIS DOCUMENT COULD INCLUDE TECHNICAL INACCURACIES OR TYPOGRAPHICAL ERRORS. CHANGES
ARE PERIODICALLYADDED TO THE INFORMATION HEREIN; THESE CHANGES WILL BE INCORPORATED
IN NEW EDITIONS OF THIS DOCUMENT. TIBCO SOFTWARE INC. MAY MAKE IMPROVEMENTS AND/OR
CHANGES IN THE PRODUCT(S) AND/OR THE PROGRAM(S) DESCRIBED IN THIS DOCUMENT AT ANY
TIME.
THE CONTENTS OF THIS DOCUMENT MAY BE MODIFIED AND/OR QUALIFIED, DIRECTLY OR INDIRECTLY,
BY OTHER DOCUMENTATION WHICH ACCOMPANIES THIS SOFTWARE, INCLUDING BUT NOT LIMITED
TO ANY RELEASE NOTES AND "READ ME" FILES.
Copyright © 2010-2013 TIBCO Software Inc. ALL RIGHTS RESERVED..
TIBCO Software Inc. Confidential Information
TOC | 5
Contents
Preface..................................................................................................9
Related Documentation..........................................................................................................10
Typographical Conventions....................................................................................................11
Connecting with TIBCO Resources........................................................................................12
Chapter 1 Getting Started...............................................................13
Models Required by Fulfillment Order Management Engines ...............................................14
Model Loading........................................................................................................................15
Consumer of Fulfillment Catalog Models...............................................................................16
Invoking Model Publisher in TIBCO Fulfillment Catalog.........................................................17
Offline Catalog........................................................................................................................18
Chapter 2 Queue Management.......................................................19
Status Listener Queues..........................................................................................................20
Chapter 3 Order Management System...........................................23
Third-party Product Requirement...........................................................................................24
OMS Architecture...................................................................................................................25
OMS Configuration.................................................................................................................26
Messaging Configuration.............................................................................................26
User Interface Configuration........................................................................................26
Router Configuration...................................................................................................27
Managing Application Security....................................................................................31
OMS WebService........................................................................................................34
Collecting Order Summary Data.................................................................................35
Configuring OCV....................................................................................................................36
Load Balancing.......................................................................................................................37
Performance Tuning................................................................................................................38
Chapter 4 Order Purging.................................................................41
Purge Configuration...............................................................................................................42
Archiving Database.....................................................................................................42
PurgeThreadCount......................................................................................................43
Purging Orders Within a Given Time Period and Matching Order Type..................................44
Retrieving Purge Status.........................................................................................................45
6 | TOC
Chapter 5 Bulk Order Actions.........................................................47
Importance of Bulk Order Actions..........................................................................................48
WSDL Location......................................................................................................................49
Security..................................................................................................................................50
Error Codes............................................................................................................................51
Invoking Bulk Order Operation...............................................................................................52
Tracking the Request Status...................................................................................................53
Logging...................................................................................................................................54
Schema..................................................................................................................................55
Bulk Order Schema.....................................................................................................55
Bulk Orders Operation Request Schema....................................................................55
Bulk Orders Operation Response schema..................................................................55
Sample Request.....................................................................................................................56
Sample Response..................................................................................................................57
Chapter 6 Jeopardy Management System.....................................59
JeoMS Configuration..............................................................................................................60
Chapter 7
Deployment Topologies................................................63
Single Node Single Instance Topology...................................................................................64
Single Node Multi-Instance Topology.....................................................................................65
Multi-node Multi-instance Topology........................................................................................71
Chapter 8 Orchestrator Interfaces..................................................73
Global Variables.....................................................................................................................74
Feasibility Providers...............................................................................................................75
Feasibility Request......................................................................................................75
Feasibility Response...................................................................................................76
Process Components.............................................................................................................78
Plan Item Execute Request Event...............................................................................78
Plan Item Milestone Release Request Event..............................................................81
Plan Item Milestone Notify Request Event..................................................................83
Plan Item Execute Response Event............................................................................84
Plan Item Suspend Request Event..............................................................................86
Plan Item Suspend Response Event...........................................................................88
Plan Item Activate Request Event...............................................................................89
Pre-qualification Failed Handlers............................................................................................92
Pre-Qualification Failed Request Event.......................................................................93
Pre-qualification Failed Response Event.....................................................................94
Plan Item Error Handlers........................................................................................................96
Plan Item Failed Request Event..................................................................................97
TOC | 7
Plan Item Failed Response Event...............................................................................99
Chapter 9 Data Access Interfaces................................................101
Get Order.............................................................................................................................102
Get Order Request....................................................................................................102
Get Order Response.................................................................................................102
Get Plan...............................................................................................................................105
Get Plan Request......................................................................................................105
Get Plan Response...................................................................................................106
Get Plan Items......................................................................................................................109
Get Plan Items Request............................................................................................109
Get Plan Items Response..........................................................................................111
Set Plan................................................................................................................................114
Set Plan Request.......................................................................................................114
Set Plan Response....................................................................................................116
Set Plan Item........................................................................................................................117
Set Plan Item Request...............................................................................................117
Set Plan Item Response............................................................................................119
Chapter 10 Offline Catalog............................................................121
Accessing Offline Catalog....................................................................................................122
Flat File Format ...................................................................................................................124
Chapter 11 Logging.......................................................................125
How Logging Works.............................................................................................................126
Contents of the Log Message....................................................................................126
Configuring Logging.............................................................................................................128
Configuring Logging for BE Components..................................................................128
Configuring Logging for Java Components...............................................................128
Controlling Log Levels..........................................................................................................130
Controlling Logging for BE Components...................................................................130
Controlling Logging for Java Components.................................................................130
Chapter 12 FAQs and Troubleshooting........................................133
Appendix A Schema References..................................................135
Plan Item..............................................................................................................................136
Result Status........................................................................................................................138
Message...............................................................................................................................139
Order Request......................................................................................................................140
Order Request Header.........................................................................................................141
8 | TOC
Order Request Line..............................................................................................................144
Process Component Model..................................................................................................148
Appendix B Global Variables and Configurations......................151
Appendix C Database Schema Changes.....................................181
Preface
The preface contains information about documentation related to the current document, typographical
conventions, and information on how to contact TIBCO support.
10 | Preface
Related Documentation
This section lists documentation resources you may find useful.
• TIBCO Fulfillment Order Management Installation and Configuration Read this manual for instructions on installation
and configuration.
• TIBCO Fulfillment Order Management Administration Read this manual for instructions on administration tasks.
• TIBCO Fulfillment Order Management Web Services Read this manual for information about the web services.
• TIBCO Fulfillment Order Management Release Notes Read the release notes for a list of features. This document
also contains the list of known issues for this release.
• TIBCO Fulfillment Order Management User's Guide Read this manual for information on Fulfillment Order
Management features, functionality, and all the screens.
• TIBCO Fulfillment Order Management Concepts and Architecture Read this manual for information on TIBCO
Fulfillment Order Management terminology and concepts.
Preface | 11
Typographical Conventions
The following typographical conventions are used in this manual:
Table 1: General Typographical Conventions
Convention
Use
TIBCO_HOME
Many TIBCO products are installed within the same home directory. This directory is
referenced in documentation as TIBCO_HOME. The value of TIBCO_HOME depends on
the operating system. For example, on Unix systems the default value is $HOME/tibco.
TRA_HOME
AF_HOME
code font
TIBCO Runtime Agent installs into a directory inside ENV_HOME. This directory is
referenced in documentation as TRA_HOME. The value of TRA_HOME depends on the
operating system. For example, on Unix systems the default value is $TIBCO_HOME/tra.
TIBCO Fulfillment Order Management installs into a directory inside ENV_HOME. This
directory is referenced in documentation as AF_HOME. The value of AF_HOME depends
on the operating system. For example, on Unix systems the default value is
$TIBCO_HOME/af/2.0.
Code font identifies commands, code examples, filenames, pathnames, and output
displayed in a command window. For example:
Use MyCommand to start the foo process.
bold code font
Bold code font is used in the following ways:
• In procedures, to indicate what a user types. For example: Type admin.
• In large code samples, to indicate the parts of the sample that are of particular
interest.
• In command syntax, to indicate the default parameter for a command. For example,
if no parameter is specified, MyCommand is enabled:
MyCommand [enable | disable]
italic font
Italic font is used in the following ways:
• To indicate a document title. For example: See TIBCO BusinessWorks Concepts.
• To introduce new terms For example: A portal page may contain several portlets.
Portlets are mini-applications that run in a portal.
• To indicate a variable in a command or code syntax that you must replace. For
example: MyCommand pathname
The note icon indicates information that is of special interest or importance, for example,
an additional action required only in certain circumstances.
The tip icon indicates an idea that could be useful, for example, a way to apply the
information provided in the current section to achieve a specific result.
The warning icon indicates the potential for a damaging situation, for example, data
loss or corruption if certain steps are taken or not taken.
12 | Preface
Connecting with TIBCO Resources
How to Join TIBCOmmunity
TIBCOmmunity is an online destination for TIBCO customers, partners, and resident experts—a place to
share and access the collective experience of the TIBCO community. TIBCOmmunity offers forums, blogs,
and access to a variety of resources. To register, go to http://www.tibcommunity.com.
How to Access All TIBCO Documentation
After you join TIBCOmmunity, you can access the documentation for all supported product versions here:
http://docs.tibco.com.
How to Contact TIBCO Support
For comments or problems with this manual or the software it addresses, please contact TIBCO Support as
follows:
• For an overview of TIBCO Support, and information about getting started with TIBCO Support, visit this
site:
http://www.tibco.com/services/support
• If you already have a valid maintenance or support contract, visit this site:
https://support.tibco.com
Entry to this site requires a username and password. If you do not have a username, you can request one.
Chapter
1
Getting Started
Topics
•
•
•
•
•
Models Required by Fulfillment Order Management Engines
Model Loading
Consumer of Fulfillment Catalog Models
Invoking Model Publisher in TIBCO Fulfillment Catalog
Offline Catalog
14 | Getting Started
Models Required by Fulfillment Order Management Engines
The Fulfillment Order Management components - AOPD, OCV, and Orchestrator require the context of
specific data models in order to generate and execute the execution plan for fulfillment of an order. Refer to
the following matrix for the "required", "optional", and "not required" models for each component.
Components
Data Models
Product
Customer
Segment
Action
Plan Fragment
AOPD
Required
Not
Required
Not Required
Optional
Not Required
OCV
Required
Required
Optional
Not Required
Not Required
Orchestrator
Not Required Not
Required
Not Required
Not Required
Required
JeOMS
Not Required Not
Required
Not Required
Not Required
Required
All these components enable their incoming JMS destinations and process the requests only after the 'required'
models are published to them and loaded.
Getting Started | 15
Model Loading
On startup, AOPD, OCV and Orchestrator engines send a JMS message as a model publish request on the
designated queues to OMS-AFI.
AOPD & OCV on queue - tibco.aff.catalog.events.request
Orchestrator on queue - tibco.aff.orchestrator.startup.event.request
Using the engineName header property in the request message, OMS-AFI identifies the requesting engine
type and publishes the "required" & "optional" data models to them as given in the above matrix.
Model publish request is processed by OMS-AFI using either of the two modes based on the configurations
for the particular model.
1. Online - By invoking catalog publish workflow in TIBCO Fulfillment Catalog.
2. Offline - By reading and publishing the contents from the offline catalog files that are exported earlier from
TIBCO Fulfillment Catalog.
If you want to load the models without restarting the engines, simulate and send the JMS message
(as would have done by the engines on startup) on the queues mentioned above.
For example, if the models are to be loaded in AOPD without restarting it, send a JMS message on queue
tibco.aff.catalog.events.request explicitly with the header property engineName=aopd. Please note
that the message should not have any contents in the body. Similarly, you can do for the OCV and Orchestrator
engines.
Consumer of Fulfillment Catalog Models
In online mode, TIBCO Fulfillment Catalog processes the catalog publish workflow request received from
OMS-AFI and publishes the bulk models on the designated JMS topics in the configured EMS server. These
models should be available on the below mentioned queues for TIBCO Fulfillment Order Management to
process and consume them.
•
•
•
•
•
•
tibco.aff.catalog.customer.request
tibco.aff.catalog.product.request
tibco.aff.catalog.segment.request
tibco.aff.catalog.action.request
tibco.aff.catalog.planfragment.request
tibco.aff.oms.planfragmentmodel
Create JMS bridges between the designated TIBCO Fulfillment Catalog topics and the corresponding queues.
SOURCE TOPIC
TARGET QUEUE
tibco.ac.productmodel.topic tibco.aff.catalog.product.request
tibco.ac.customermodel.topic tibco.aff.catalog.customer.request
tibco.ac.segmentmodel.topic tibco.aff.catalog.segment.request
tibco.ac.actionmodel.topic
tibco.ac.planfragmentmodel.topic tibco.aff.catalog.planfragment.request
tibco.ac.planfragmentmodel.topic tibco.aff.oms.planfragmentmodel
The schema for plan fragment model is
$AF_HOME/schemas/schema/orchestrator/sharedResources/schemas/classes/planFragmentModel.xsd.
The schema for product, customer, segment, and action models is available in the
$AF_HOME/schemas/schema/afi/SharedResources/Schemas/Classes directory.
Getting Started | 17
Invoking Model Publisher in TIBCO Fulfillment Catalog
The user can invoke the catalog publish workflow in TIBCO Fulfillment Catalog directly by using the sample
SOAP web service requests available in the $AF_HOME/samples directory. The request can be sent using any
standard SOAP client tools such as SOAPUI.
Specify the correct enterprise name, user name, and password in the request. Also specify the correct
MASTERCATALOGNAME key and a PRODUCTID to publish the specific catalog. The request should be
invoked against the running instance of TIBCO Fulfillment Catalog on the following URL:
http://<HOST>:<PORT>/eml/services/router/MasterCatalogRecordAction
Where:
HOST and PORT are the machine name and port number where TIBCO Fulfillment Catalog is deployed and
running.
Offline Catalog
Offline catalog is a feature in TIBCO Fulfillment Order Management that enables it to have the context of the
required data models in AOPD, OCV, & Orchestrator engines through the use of catalog XML files exported
from TIBCO Fulfillment Catalog. It reduces the dependency on TIBCO Fulfillment Catalog to be online at all
the times. For details, refer Offline Catalog on page 121.
Chapter
2
Queue Management
It is highly recommended that the Configurator be used to manage the queues.
Topics
•
Status Listener Queues
20 | Queue Management
Status Listener Queues
When OMS receives orders, it sends the orders to JMS queues which are routed to the Orchestrator engine
based on type of the router configurator and routing condition specified by the administrator.
Multiple concurrent listeners can be listening for incoming orders on the Listener queue to allow parallel
processing of incoming orders. The number of such concurrent listeners is configurable.
OMS receives notification on status for orders in the system for fulfillment and supports two routers types,
viz. Pass-through router and Filter based router.
Pass-through does not apply any condition on the incoming order message and passes the message to the
default orchestrator.
Figure 1: Listener Queues
The following table describes the properties of the Listener Queues.
Name
Descriptions
Order Status Notification Queue
Destination queue for receiving status message from
Orchestrator
Order Status Notification Queue Concurrent Order Status Notification Queue Concurrent Listener Count
Listener
Order Line Status Notification Queue
Concurrent Listener
Order Line Status Notification Queue Concurrent Listener
Count
Plan Status Notification Queue
Plan Status Notification Queue
Plan Status Notification Queue Concurrent
Listener
Plan Status Notification Queue Concurrent Listener Count
Plan Item Status Notification Queue
Plan Item Status Notification Queue
Order Amendment Status Notification Queue Order Amendment Status Notification Queue
Queue Management | 21
Name
Descriptions
Set Plan Queue
Destination queue for receiving execution plan from
Orchestrator
Set Plan Item Queue
Destination queue for receiving execution plan item from
Orchestrator
Set Plan Fragment Model Queue
Destination queue for receiving plan fragment from
Fulfillment Catalog
Status Notification Dead Queue
Destination queue for poison message for status notification.
OMS will move the message to the dead letter queue after
retrying a pre-configured number of times to avoid messages
becoming poison message
Set Plan Dead Queue
Dead letter queue destination for execution plan
Set Plan Item Dead Queue
Dead letter queue destination for execution plan item
Set Plan Fragment Dead Queue
Dead letter queue destination for plan fragment
Update Jeopardy Configuration Rule Queue Destination to send jeopardy rule updates
Enrich Migrated Plan Request Queue
Destination to send request to JeoMS to enrich execution
plan with the jeopardy information
The independent AFI, AFS, and TDS components have been rewritten in release 2.0.0 and they are now an
integral part of OMS server. So apart from the above listed queue configurations for core OMS component
which are present since version 1.1.0, the queue/topic configurations corresponding to these three components
have been added newly under separate categories in the configurator.
For details, refer to the Global Variables and Configurations section in Fulfillment Order Management
Administration.
Chapter
3
Order Management System
This section describes the OMS architecture and how to do configuration settings, load balancing, and performance
tuning.
Topics
•
•
•
•
•
•
Third-party Product Requirement
OMS Architecture
OMS Configuration
Configuring OCV
Load Balancing
Performance Tuning
24 | Order Management System
Third-party Product Requirement
Refer to the TIBCO® Fulfillment Order Management Installation and Configuration document for third-party
product requirements.
Order Management System | 25
OMS Architecture
The Order Management System (OMS) consists of the following four application components:
1. OMS Server - Core OMS server component, which provides SOAP-based web services over HTTP and
JMS, JMS data interfaces, offline catalog web service and file polling interfaces, and REST APIs for OMS
UI.
2. JEOMS - Jeopardy management server component provides order SLA monitoring capabilities.
3. OMS UI - provides GWT based Web interface to browse orders and execution plans and perform actions
on the orders.
4. Dashboard - Shindig based gadget container for providing summary information about the order fulfillment
engine. Current version provides four gadgets, namely Order Summary, Orders in Execution, backlog
Order, and Amended Orders.
All the above components are shipped as a WAR (.war) file.
It is essential for all the components in an application to work together and support the architecture. The
following diagram demonstrates the working of the components of the OMS.
Figure 2: OMS Components
OMS Configuration
Messaging Configuration
All the application components of Fulfillment Order Management use JMS as one of the conduits for passing
a message within Fulfillment Order Management and with the external applications. The following properties
are required to connect to the JMS server.
Figure 3: Messaging Configuration
Parameters
Description
Host
JMS provider host name
Port
Port number of the JMS Provider
Username
Username
Password
Password
User Interface Configuration
OMS provides a web user interface to browse and perform actions on the orders and execution plans. OMS
UI is deployed as a separate application in tomcat server and it requires parameters to connect to OMS Server
application.
OMS does not support deploying OMS UI application and OMS Server application separately in
different containers. OMS UI also provides configurable parameters to control the access to the
application.
Figure 4: User Interface Configuration
The following table shows configurable parameters for the UI.
Parameters
Description
Maximum Session Per User Number of sessions allowed per user. By default, OMS allows only one session
to be created for any user. In the case of a scenario in which multiple users
share user id and password, this value needs to be set appropriately.
Error If Maximum Session
Expired
Http Session Fixation
Protection
You can either expire the user's previous login or you can report an error
when the user tries to log in again, preventing the second login. Note that if
you are using the second approach, a user who has not explicitly logged out
(but who has just closed the browser, for example) will not be able to log in
again until original session expires.
Session fixation vulnerabilities occur when the application authenticates a
user without first invalidating the existing session ID, thereby continuing to
use the session ID already associated with the user. The behavior can be
controlled using the session-fixation-protection attribute which has the
following three options:
• migrateSession - creates a new session and copies the existing session
attributes to the new session. This is the default.
• none - Don't do anything. The original session will be retained.
• newSession - Create a new, clean session without copying the existing
session data.
Router Configuration
The Content-based router in OMS allows routing of the order to the correct destination based on the contents
of the order message.
Content-based routing schedules the order of the messages that are based on the actual content of the message
itself, rather than by a destination specified by the message. Content-based routing works by opening a
message and applying a set of rules to its content to determine the destination of a message . By freeing the
sending application from the need to know anything about where an order should be routed for fulfillment,
content-based routing provides a high degree of flexibility to configure multiple types of Orchestration
engines.
OMS supports two types of routers:
1. Pass-through router (passthroughRouter), and
2. Filter based router (filteringRouter).
Figure 5: Router Types and Properties
A pass-through does not apply any condition on the incoming order message and passes the message to the
default orchestrator.
The following table shows configurable parameters for Filter based Router.
Parameters
Description
Router Condition
XPath filter condition to be applied on the incoming order message.
If the XPath condition is not satisfied, the message will be routed
to the default AF Orchestrator or else the message will be routed
to the IPC destination.
AF Orchestrator Submit Order Queue Destination queue name of Orchestrator for submit order request.
AF Orchestrator Amend Order Queue Destination queue name of Orchestrator for amend order request.
AF Orchestrator Suspend Order Queue Destination queue name of Orchestrator for suspend order request.
AF Orchestrator Activate Order Queue Destination queue name of Orchestrator for activate order request.
iPC Orchestrator Submit Order Queue Destination queue name of iPC for submit order request.
iPC Orchestrator Amend Order Queue Destination queue name of iPC for amend order request.
iPC Orchestrator Suspend Order
Queue
Destination queue name of iPC for suspend order request.
iPC Orchestrator Activate Order
Queue
Destination queue name of iPC for activate order request.
Figure 6: Router
The functional support for TIBCO iProcess Conductor (iPC) has been deprecated in Fulfillment Order
Management version 2.0.0. However, orders to be sent to iPC are still routed by OMS to the above
listed iPC queues, if configured.
Filtering Router
A filter condition for a router is applied only for a submit order request. Any subsequent request related to
the order will always be routed through the same orchestrator where the original submit order request was
submitted. The XPath condition specified must be based on Order schema.
For example, XPath
/SubmitOrderRequest/orderRequest/header/udf[name='Orchestrator']/value/text() specified for
a filter condition results in sending all the orders containing User Defined Field (UDF) with name value pair
'Orchestrator' and IPC' to TIBCO iProcess Conductor. It is not required to be based on the UDF element. The
only requirement is that it should be a valid XPath condition on the order schema. Fulfillment Order
Management supports specifying a filter condition but it does not perform any validation on the XPath
condition. It must be validated before specifying it in the Fulfillment Order Management Configurator.
1. Any XPath filter condition results in the Orchestrator name. The following two Orchestrators are
supported for routing:
– AFO
– IPC (iProcess Conductor)
2. Orchestrator names are case sensitive. The OMS router matches the text value to the Orchestrator
name (case sensitive). If the text value is iPC, the order is routed to the AFO Orchestrator.
The router uses an XML configuration to configure the routing and mediation rules which are added to a
router-context.xml of the OMS component. The path to the router-context.xml file is
<AF_HOME>/apache-tomcat-<version>/webapps/omsServer/WEB-INF/classes/spring.
The following example shows a router configuration to route the order message to Business Events (BE)
Orchestrator based on the User Defined Field (UDF) value in the order message:
/SubmitOrderRequest/orderRequest/header/udf[name='Orchestrator']/value/text()
You must restart the OMS server to apply the updated XPath filter condition after updating the router
information in AF Configurator.
Routing Orders to Other Engines
OMS routes orders to AFO and IPC.
To enable OMS to route an order to any other engine, perform the following steps:
1. Configure the router-context.xml file.
2. Change ConfigValues using AF Configurator.
Configuring Router Context
Router uses XML configuration to configure routing and mediation rules which are added to a
router-context.xml of the OMS. The path to router-context.xml file is
<AF_HOME>/apache-tomcat-<version>/webapps/omsServer/WEB-INF/classes/spring.
To submit an order, consider an example with engine name as Fulfillment Provisioning (kpsa).
The following sections step you through the process of configuring the router context:
1. Create an instance of submit order router.
a. Create a JMS template. To do this, make the following changes:
<bean id="kpsaJmsTemplate" class="org.springframework.jms.core.JmsTemplate">
<property name="connectionFactory" ref="kpsaConnectionFactory"/>
<property name="destinationResolver" ref="beoDestinationResolver"/>
<property name="pubSubDomain" value="false"/>
</bean>
a. Create a connection factory.
<bean id="kpsaConnectionFactory"
class="org.springframework.jms.connection.CachingConnectionFactory">
<constructor-arg>
<bean class="org.springframework.jndi.JndiObjectFactoryBean">
<property name="jndiName" value="GenericConnectionFactory"/>
<property name="jndiTemplate" ref="kpsaJndiTemplate"/>
</bean>
</constructor-arg>
<property name="reconnectOnException" value="true"/>
<property name="cacheProducers" value="true"/>
</bean>
b. Add a JNDI template.
<bean id="kpsaJndiTemplate" class="org.springframework.jndi.JndiTemplate">
<property name="environment">
<props>
<prop
key="java.naming.provider.url">tcp://${com.tibco.af.oms.jms.jndi.host}:${com.tibco.af.oms.jms.jndi.port}
</prop>
<prop
key="java.naming.factory.initial">${com.tibco.af.oms.jms.jndi.initialContextFactory}
</prop>
<prop
key="java.naming.security.principal">${com.tibco.af.oms.jms.jndi.security.principal}
</prop>

</props>
</property>
</bean>
b. Assign a destination queue.
<bean id="kpsaSubmitOrderDestination" class="com.tibco.tibjms.TibjmsQueue">
<constructor-arg value="${com.tibco.af.oms.router.destination.kpsaSubmitOrder}"
/>
</bean>
c. Create an instance of Router Message Create.
<bean id="kpsaSubmitMessage" class="com.tibco.aff.oms.router.RouterMessageCreator"/>
d. Create an instance of Router.
<bean id="kpsaSubmitOrderRouter" class="com.tibco.aff.oms.router.RouterProcessor">
<property name="jmsTemplate"><ref local="kpsaJmsTemplate"/></property>
<property name="destination"><ref local="kpsaSubmitOrderDestination"/></property>
<property name="messageCreator"><ref local="kpsaSubmitMessage"/></property>
</bean>
e. Add an entry to router context for the required action.
<routeContext id="routerContext" xmlns="http://camel.apache.org/schema/spring">
<route id="orderSubmitRoute">
<from uri="direct:tibco.aff.routerproxy.order.submit"/>
<choice>
<when>
<xpath>$orchestrator = 'IPC'</xpath>
<to uri="bean:ipcSubmitOrderRouter" pattern="InOnly" />
<transform>
<simple> IPC</simple>
</transform>
<to uri="bean:routerDataProcessor"/>
</when>
<when>
<xpath>$orchestrator = 'KPSA'</xpath>
<to uri="bean:kpsaSubmitOrderRouter" pattern="InOnly" />
<transform>
<simple>KPSA</simple>
</transform>
</when>
<otherwise>
<to uri="bean:beoSubmitOrderRouter" pattern="InOnly" />
<transform>
<simple>AFO</simple>
</transform>
</otherwise>
</choice>
</route>
2. Changes to ConfigValues using AF Configurator.
a. Add a new property in the config values for the submit order destination according to 1.b (Assign a
destination queue).
Managing Application Security
OMS provides two application-level security options.
• Default Authentication Provider
• Lightweight Directory Access Protocol (LDAP) Authentication Provider
Default authentication provider is database-based security, which does not require configuration to use the
default authentication provider. OMS uses the configured database to store the operational data of orders
and execution plans.
Figure 7: OMS Application Security
OMS also supports LDAP-based authentication.
Figure 8: LDAP Authentication Properties
The following properties are required to configure OMS to use external LDAP server authentication.
Parameters
Description
LDAP Server URL
LDAP Server URL ldap://<hostname>:port/<root context>. Many LDAP
servers also support SSL-encrypted LDAPS, preferred for security purposes
and to configure OMS to use SSL LDAP to connect to server use ldaps://
at the beginning of the LDAP server URL.
Parameters
Description
LDAP User Manager DN
User Manager Distinguished Name to be used to connect to LDAP Server.
LDAP User manager
Password
Password of the user manager to be used for authentication.
User Search Base
A search base (the distinguished name of the search base object) defines the
location in the directory from which the LDAP user search begins.
User Search Filter
Search filter to be used to locate the user. For example, the following filter
can be used to substitute the login name with value for the uid (filter) in the
directory:
filter (uid={0})
Search Subtree
Flag to enable deep search through the sub tree of the LDAP Server URL +
User Search Base. True by default.
Group Search Base
It defines the base DN under which the LDAP integration should look for
one or more matches for the users' DN. The default value performs a search
from the LDAP root.
Group Search Filter
It defines the LDAP search filter used to match user's DN to an attribute of
an entry located under Group Search Base. The default value is
(uniqueMember={0}).
Group Role Attribute
It defines the attribute of the matching entries, which will be used to compose
the user's role in OMS. Default value is cn. Attribute must have either admin
or user as the value for the role attribute. Role-based authorization provided
by OMS depends on the value specified in this attribute to provide appropriate
permission for the user.
Managing Users and Roles
OMS supports role-based authorization. The user must belong to either ROLE_USER or ROLE_ADMIN.
The following table shows business functions and a list of roles that are authorized to perform the business
functions.
OMS Interface
Function
Roles
OMS UI
Dashboard
ROLE_USER, ROLE_ADMIN
Search Order
Order Detail
Suspend Order
ROLE_ADMIN
Cancel Order
ROLE_ADMIN
Resume Order
ROLE_ADMIN
Amend Order
ROLE_ADMIN
Search Execution Plan
View Execution Plan
Submit Order
ROLE_ADMIN
OMS Web Service
OMS Interface
Function
Roles
Synchronous Submit
Order
ROLE_ADMIN
Amend Order
ROLE_ADMIN
Get Orders
Get Order Detail
Get Execution Plan
Cancel Order
ROLE_ADMIN
By default, OMS provides a set of user id and password for accessing OMS through the web and for submitting
a web service request.
The following table shows the default user id and password provided by the OMS.
User Name
Password
Role
admin
admin
ROLE_ADMIN
affadmin
affadmin
ROLE_ADMIN
afuser
afuser
ROLE_USER
Mentioned below is the UserManagement application available with FOM.
Before running the UserManagement application, set the environment variable AF_OMS_CONTEXT_URL to
the URL where the omsServer Web application is up and running. For example:
http://<machineIPAddress>:<port>/omsServer
.
Where:
• host is the computer where you installed the Fulfillment Order Management.
• port number is the port number of the machine where OMS Web server is listening to requests. The
default port number is 8080.
• omsServer is the application context.
The UserManagement application is used to manage users in the Fulfillment Order Management solution.
The application has a userservice command line interface that allows you to:
• Create User. Refer to Create user.
• Read User Details. Refer to Read the details of user.
• Delete User. Refer to Delete the user.
• Reset User Password. Refer to Reset the password of the user.
You must have role assigned as ROLE_ADMIN in order to invoke the command-line application.
Running the userservice with -help option displays all the options with userservice and corresponding arguments.
Creating User
To create the user, do the following:
1. On the command prompt, access the AF_HOME/bin directory.
2. Run the following command:
$AF_HOME/bin/userservice.sh -action create
-adminusername <adminusername> -adminuserpassword <adminpassword>
-username <user> -userpassword <password> -userrole <role>
$./startup.sh
Reading User Details
To read the user details, do the following:
$AF_HOME/bin/userservice.sh -action read
-username <user>
Deleting User
To delete the user, do the following:
$AF_HOME/bin/userservice.sh -action delete
-username <user>
Resetting Password
To reset the user password, do the following:
$AF_HOME/bin/userservice.sh -action reset
-adminusername <adminusername>
-adminuserpassword <adminpassword>
-username <user> -newpassword <newpasswordtoreset>
If the passwords have special characters, then enclose them with double quotes or proper escape
sequence compatible with the underlying operating system. For example: "welcome>123", "ab\"c",
etc.
OMS WebService
OMS supports both HTTP and JMS as transport protocols for invoking SOAP-based web services. Order
services in OMS can be secured by enabling username token-based security. OMS supports the WS-Security
UserName Token mechanism, which allows for the sending and receiving of user credentials in a
standards-compliant manner. The UserName token is a mechanism for providing credentials to a Web service
where the credentials consist of the UserName and Password. The password must be passed in clear text.
The UserName token mechanism provides a web service with the ability to operate without having the
username and password in its URL or having to pass a session cookie with the HTTP request.
The following is a sample of the UserName token showing the username and password:
<soapenv:Header>
<wsse:Security soapenv:mustUnderstand="1"
xmlns:wsse="
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
">
<wsse:UsernameToken>
<wsse:Username>admin</wsse:Username>
<wsse:Password Type="
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">
admin</wsse:Password>
<wsse:Nonce>WScqanjCEAC4mQoBE07sAQ==</wsse:Nonce>
<wsu:Created>2010-05-11T01:24:32Z</wsu:Created>
</wsse:UsernameToken>
</wsse:Security>
</soapenv:Header>
The table below shows configurable properties for order related WebServices in OMS.
Figure 9: OMS WebService
Parameters
Description
Enable User Token based Security
The Order service provided by OMS can be secured by enabling
username token-based security.
Enable Schema Validation
Defines a flag to specify if schema validation is required on the
order requests submitted to OMS.
Enable Order Receiver Idempotency
Making the order Web services idem potent allows the client to
submit orders with the same order reference multiple times
without any side effects. The web service detects duplicate orders
and responds with the same response for all the submission(s).
HTTP Channel Type
Defines channel type to be used for the transport. Specifying
channel type to be HTTPS allows the client and server to use
mutual authentication and encrypts the communication.
HTTP Port Number
Port number of HTTP Channel. This port number must match the
port number specified for the tomcat server http port transport.
HTTPS Port Number
Port number of HTTPS Channel. This port number must match
the port number specified for the tomcat server HTTPS transport.
Collecting Order Summary Data
OMS provides the Dashboard component to view summary information about the fulfillment engine. This
requires collection of information about status orders in the system and other summary information. In the
case of a heavy load, it is desirable to collect the summary information periodically by scheduled interval
rather than updating summary data on every status change. Cron Expression is used to define the time interval
for summary collection.
For example, Cron expression "0 0 * * *?" defines an hourly time interval for the summary collection.
Configuring OCV
OMS provides different configurable options to enable or disable the validation of an order request against
configured offers in the system.
Figure 10: OMS OCV Property
The following table shows properties that can be specified on OCV.
Parameters
Description
Enable Offer
Configuration and
Validation
This parameter specifies if OCV validation needs to be performed for incoming orders
or not. Add flag name for creating OCV Validation = com.tibco.af.oms.OCVEnabled.
This value can be set true or false through the configurator.
Offer Configuration OMS makes an asynchronous call to the OCV application component. This field
and Validation
represents the timeout value in milliseconds. If a timeout occurs, OMS throws a SOAP
Timeout
fault to the client.
(Milliseconds)
Offer Configuration Default request queue for OCV validation. Request queue name is
and Validation
tibco.aff.ocv.events.offer.validate.request.
Request Queue
Offer Configuration Default response queue for OCV validation response from OMS=
and Validation
tibco.aff.ocv.events.offer.validate.reply.oms.
Response Queue
The response is sent to the Offer Configuration and Validation response queue for
the validation request sent from OMS. For other OCV clients, the response is sent to
the default queue = tibco.aff.ocv.events.offer.validate.reply.
OCV Exception
Logging Enabled
Allows you to enable or disable logging of the exception stack trace in OMS when
validation fails.
Exception Logging Enabled (Property
value = true)
Exception Logging Enabled (Property
value = false)
Exception stack trace is logged in the
OMS log.
One line error message is logged in the
OMS log. No exception stack trace is
logged.
Load Balancing
OMS itself does not provide any load balancing capability but any third party load balancer can be used to
load balance across multiple instances of OMS. For this, no specific configuration is required. The only
requirement is that the load balancer should have support for sticky session. Sticky sessions means the load
balancer will always direct a given client to the same back-end server.
Hardware Load Balancer (HLB), which has Layer 7 capability, can direct traffic and maintain session persistence
for Web applications without relying on the user's IP address with session cookies. Typically, HLB inserts a
cookie that the load balancer creates and manages automatically to remember which back-end server a given
HTTP connection should use. Then it would always direct the request originating from that client browser
to the same server.
Some of the HLBs which support layer 7 capability include:
• Barracuda
• jetNEXUS
• f5
Performance Tuning
There have been significant performance improvements to OMS. The queue for order submission has multiple
concurrent listeners to process incoming orders in parallel. The queues for receiving status notifications are
separated for the different types of notifications such as Order, OrderLine, Plan, PlanItem, or OrderAmendment
(See figure Figure 11: Listener Queues on page 38). Each of these queues supports multiple concurrent
listeners for processing the notifications in parallel. The number of concurrent listeners for the various queues
are configurable, and can be configured using the Fulfillment Order Management Configurator User Interface.
Figure 11: Listener Queues
For details on the properties of the Listener Queues, see Status Listener Queues on page 20.
In addition, the number of concurrent listeners for JMS interfaces from AFI, AFS, and TDS components
merged as the integral part of OMS server can also be configured as per the need.
Figure 12: AFI, TDS, AFS Configuration
Chapter
4
Order Purging
Purging is an act of removing undesired elements in the order information. Order purging enables you to remove
old order information from the fulfillment system such as already fulfilled or delivered (met the delivery date line)
orders, or an order replaced to accomplish a purpose and function effectively.
Order purging removes an order's data from the OMS and Orchestrator components by allowing you to provide
certain criteria in order to purge the unwanted data. You can track the purge progress by retrieving the status of
your purge request.
You can purge orders based on the following criterion:
Purge All Orders Within a Given Period of Time (Absolute Date/Time Range) and Matching Order Type
(Order Type Match Parameter)
You can delete the order data from the OMS for all the orders submitted within a given period of time with a
specific order type. For example, you can initiate a request to delete all the order data from the OMS database and
Orchestrator between 01/10/2010 and 10/10/2011 and having order type as 'COMPLETE'.
Valid values for order type are:
• COMPLETE
• CANCELLED
Server restart is not required to purge order data.
Perform the following to initiate or track the purge process:
• Edit the ${AF_HOME}/bin/purgeorder.properties file to specify the purge criteria and the choice of operation.
• Execute the ${AF_HOME}/bin/purgeorderservice.sh shell script.
Topics
•
•
•
Purge Configuration
Purging Orders Within a Given Time Period and Matching Order Type
Retrieving Purge Status
42 | Order Purging
Purge Configuration
You can configure the required purge settings through the Configurator.
The purge configuration details are provided in the following sections:
• Archiving Database on page 42
• PurgeThreadCount on page 43
Archiving Database
You can archive the purged data by setting and configuring an archive database in Configurator.
1. Create a new user/schema similar to the one used for OMS. This can be done through Configurator or
manually. For details, see Creating and Configuring Database section in the TIBCO Fulfillment Order
Management Installation and Configuration guide on how to create a new user and schema specific to OMS.
2. Configure the newly created schema through Configurator as displayed:
Figure 13: Archival Configuration Sample
Figure 14: Archive Default Catalog for hibernate
Order Purging | 43
3. Execute the steps mentioned in the Purging Orders Between Given Time Period and Matching Order Type
section. Before you execute the shell script, in the purgeorder.properties file, set the archive value to
true.
PurgeThreadCount
The purge thread count can be configured through the Configurator.
You must restart the OMS server after setting the property.
Set the Purge Thread Count Property as displayed:
Figure 15: Purge Thread Count Property
The thread count should be set depending on the number of cores in the CPU.
44 | Order Purging
Purging Orders Within a Given Time Period and Matching Order
Type
Use this feature of the purge utility to clean-up your database by removing old or irrelevant orders within
any given period of time and having a particular order type.
Procedure
1.
2.
3.
4.
5.
Go to the command prompt.
Change the directory to ${AF_HOME}/bin.
Open the purgeorder.properties file using any text editor to edit the purge input parameters.
Type 1 as your choice of operation.
Type the START_DATE in the <MM-DD-YYYY> format. For example, 05-18-2012.
START_DATE=05-18-2012
6. Type the END_DATE in the <MM-DD-YYYY> format. For example, 05-19-2012.
END_DATE=05-19-2012
END_DATE must be greater than START_DATE.
7. Type the ORDER_TYPE. For example, COMPLETE.
ORDER_TYPE=COMPLETE
You must specify valid order type. For example, either COMPLETE or CANCELLED. Invalid order
type may result in execution error.
8. Type the ARCHIVE. For example, false.
ARCHIVE=false
9. Save the file.
10. Execute the purgeorderservice.sh shell script.
Order Purging | 45
Retrieving Purge Status
You can find the status of your purge request by using the purge ID returned in response to invoking the
purge operation.
Procedure
1.
2.
3.
4.
5.
Go to the command prompt.
Change the directory to ${AF_HOME}/bin.
Open the purgeorder.properties file using any text editor to edit the purge input parameters.
Type 2 as your choice of operation.
Type the PURGE_ID. For example, 518c1fa1-a109-4f80-af69-0c53cb1c6350.
PURGE_ID=518c1fa1-a109-4f80-af69-0c53cb1c6350
6. Save the file.
7. Execute the purgeorderservice.sh shell script.
The purge status is visible on the console.
Chapter
5
Bulk Order Actions
Operations on an order are performed depending upon the requirement. Performing the same action on individual
orders is difficult and time-consuming. You can apply actions to the group of orders simultaneously using Bulk
Order action.
The following operations can be performed on the group of orders:
• CANCEL
• SUSPEND
• RESUME
• WITHDRAW
These operations are exposed by the OMS order service.
Topics
•
•
•
•
•
•
•
•
•
•
Importance of Bulk Order Actions
WSDL Location
Security
Error Codes
Invoking Bulk Order Operation
Tracking the Request Status
Logging
Schema
Sample Request
Sample Response
48 | Bulk Order Actions
Importance of Bulk Order Actions
The bulk order actions allow administrators to cancel, suspend, resume, or withdraw a group of orders in a
single invocation of a web service. This is useful:
• To perform a specific action on all orders in a particular region.
• To prevent repetitive intervention to perform similar actions.
The bulk order actions are based on the existing OMS order service. This operation is called
PerformBulkOrderAction.
The existing OMS order service is modified to include a new operation. This operation allows you to specify
the type of action to be performed along with the group of orders on which the action must be performed.
You can monitor the request status through:
• Event log - contains the information about the status of the request.
• Order lists - shows the change in the order status when refreshed.
All the errors that occur during this process are logged and handled individually.
Bulk Order Actions | 49
WSDL Location
This is the default location where all the WSDL files are copied after the installation.
• $AF_HOME\schemas\wsdl\http\OrderServiceHTTP.wsdl
• $AF_HOME\schemas\wsdl\jms\OrderServiceJMS.wsdl
Security
The PerformBulkOrderAction web service is fully secure. All the calls to the bulk order action operation of
an order web service is authenticated by using an existing Usernametoken based apporach.
You must have an ADMIN right to invoke the operation.
Error Codes
The following table lists the error codes:
Error Code
Description
TIBCO-AFF-OMS-100046: INVALID_ACTION
Web service fault code for invalid values of
action.
TIBCO-AFF-OMS-100047: NO ORDERS FOUND
Web service fault code when neither order
id nor order reference is present in the
request.
TIBCO-AFF-OMS-100048: BOTH ORDERID AND ORDERREF Web service fault code when both order id
FOUND
and order reference are present in the
request.
TIBCO-AFF-OMS-100020: ORDER_NOT_FOUND
This exception is logged if an order to be
cancelled or withdrawn is not present in the
OMS component.
Invoking Bulk Order Operation
The PerformBulkOrderAction bulk order operation requires the following input parameters to perform the
selected action on all the orders contained in the request:
• Action type
• List of order IDs or order refs
The PerformBulkOrderAction bulk order operation is an asynchronous operation and the consumer of the
operation receives an acknowledgment immediately upon the submission of the request. This acknowledgment
is not an indication that the process is complete. This indicates that the request is under process by the OMS
component. For tracking the status of individual orders, activity logs, or an order, use the browse screens of
the Fulfillment Order Management UI. The operation can be invoked by a user with ADMIN role only.
A user with an ADMIN role can invoke the bulk order actions.
The property Use external business transactionId as business transaction
OMS in the Configurator should be set to false while invoking bulk cancel operation.
id within
Tracking the Request Status
The request status for the invoked bulk order action can be tracked using:
• Fulfillment Order Management UI (Dashboard, Order Screen and Activity logs)
• Logs in the OMS and Orchestrator components
Logging
TIBCO Fulfillment Order Management provides detailed logging and auditing capabilities to identify the
system errors, and key errors that can be gracefully handled by the calling system.
For bulk order actions, the logging is done using the AFFLogger APIs and the log file (omsServer-local.log)
is created in the corresponding location based on the configured Appender. The log location is
$AF_HOME/apache-tomcat-7.0.6/logs. The incoming bulk order request is validated and an INFO level
log is generated. The log contains the action to be performed along with the number of orders in the request.
For all bulk order actions, if a particular order is not found in the OMS component, an 'ERROR' level log is
generated indicating that the order was not found.
Schema
A schema is an organization or structure for the PerformBulkOrderAction bulk order actions web service.
Bulk Order Schema
The following figure depicts the bulk order action operation added to the OMS order service.
Figure 16: Bulk order action operation added to the OMS order service
Bulk Orders Operation Request Schema
The following figure depicts the bulk operation request schema.
Figure 17: Request schema for bulk operation
Bulk Orders Operation Response schema
The following figure depicts the bulk operation response schema.
Figure 18: Response schema for bulk operation
Sample Request
The sample request applicable to the bulk operation is as follows:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:ord="http://www.tibco.com/aff/orderservice">
<soapenv:Header/>
<soapenv:Body>
<ord:PerformBulkOrderActionRequest businessTransactionID="bTranID">
<ord:action>SUSPEND</ord:action>
<ord:orderID>ddb74135-ee66-4eb4-8aaa-4a842ae23510</ord:orderID>
<ord:orderID>567db5aa-06d3-44e4-abf1-c6f06a8fb110</ord:orderID>
<ord:orderID>2611964b-5648-4b00-82c3-c2acdefe5240</ord:orderID>
<ord:orderID>30015c77-b4fe-44d6-9eb4-0d7a433e49e4</ord:orderID>
<ord:orderID>031c0e65-859d-4a58-8089-f9c25e5f2244</ord:orderID>
<ord:orderID>088a25d9-2db3-4ab1-99c7-492cc9108c71</ord:orderID>
<ord:orderID>b57da5dc-7b76-49c7-9fd6-9af3234be4d9</ord:orderID>
<ord:orderID>27637077-4c7d-4748-bf47-3c43cf7ce640</ord:orderID>
<ord:orderID>6716b0aa-a617-470a-9d7d-bbfc38dcfec1</ord:orderID>
<ord:orderID>3ca37c35-fe0c-4d2a-90e6-f1b7f2dbf6d9</ord:orderID>
</ord:PerformBulkOrderActionRequest>
</soapenv:Body>
</soapenv:Envelope>
Sample Response
The sample response applicable to the bulk operation is as follows:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<ns3:PerformBulkOrderActionResponse xmlns="http://www.tibco.com/aff/order"
xmlns:ns2="http://www.tibco.com/aff/commontypes"
xmlns:ns3="http://www.tibco.com/aff/orderservice"
xmlns:ns4="http://www.tibco.com/aff/orderservice/result"
xmlns:ns5="http://www.tibco.com/aff/plan"
xmlns:ns6="http://www.tibco.com/aff/planfragments">
<ns3:timestamp>2012-08-01T15:36:54.166+05:30</ns3:timestamp>
<ns3:message>Request Submitted Successfully</ns3:message>
<ns3:noOfOrders>10</ns3:noOfOrders>
</ns3:PerformBulkOrderActionResponse>
</soap:Body>
</soap:Envelope>
Chapter
6
Jeopardy Management System
The Jeopardy Management System consists of the following components:
• Jeopardy Management Server - Monitors execution plans and detects jeopardy conditions.
• Notification Engine - Evaluates user configured rules and sending notifications to user defined destinations.
The following figure depicts the component architecture of the Jeopardy Management System:
Figure 19: JeOMS Component Architecture
Topics
•
JeoMS Configuration
60 | Jeopardy Management System
JeoMS Configuration
All the parameters of JeoMS have default values and no parameter value required to deploy and run JeoMS
in basic mode. You may change the following parameters to tune the performance of the Jeopardy Management
System.
Jeopardy Management Tuning Parameters
The Jeopardy Management Tuning Parameters are as follows:
Operational Data Store Type
The data store type to be used in order to cache operational data of JeoMS. Supported types are:
• local
• activespace
Operation Data Store location
The directory location to persist operational store files in file system.
Risk Threshold
Set this parameter to specify percentile increase over typical duration beyond which a task can be considered
to be running in a hazard region. For example, if typical duration of a process component is 60 minutes and
if risk threshold is 50, any plan item that is executing for more than 90 minutes is considered to be running
in a hazard region. Default value is 25 percentile point.
Out of Scope Threshold
Set this parameter to specify Percentile increase over maximum duration beyond which an execution can be
considered running out of scope for jeopardy detection. And no further jeopardy monitoring be performed
on the plan. For example, if maximum duration of a process component is 60 minutes and if out of scope
threshold is 100, any plan item that is executing for more than 120 minutes is considered as out of scope and
JeoMS stops monitoring the plan.
Time Window Value/Time Window Unit
The Configuration parameter Time window value and Time Window Unit are combined together to determine
the Time window or Chronon to which plan items of execution plans belong in JeoMS. It is a user-defined
interval of time during which any execution of any plan item would result in grouping the plan item together.
Configure this value based on execution characteristics of process components in fulfillment eco system. This
value is used by jeoMS to cluster plan items in execution to optimize jeopardy detection cycle.
Jeopardy Management System | 61
Figure 20: Time Window Value/Time Window Unit
For example, if fulfillment tasks executed by the process components typically take few days to complete, it
is probably meaningless to use seconds or milliseconds to track the progress of a plan item. In this case, the
you can provide a value in terms of hour units. On the other hand, if JeoMS monitors very fast executing
plans, JeoMS will require a Chronon of milliseconds or seconds to accurately predict the jeopardy condition.
The default value is 10 Minutes.
Messaging Configuration
JeoMS piggyback on message configuration parameters of OMS and no additional configuration required.
Datasource Configuration
JeoMS piggyback on data source configuration parameters of OMS and no additional configuration required.
Chapter
7
Deployment Topologies
Although application components can be deployed separately on different tomcat containers, it is recommended
that they are all deployed together in the same container. However, multiple instances of the OMS, JeOMS servers
can be executed on the same machine or multiple machines.
One of the following topologies can be employed to deploy OMS and JeOMS.
Topics
•
•
•
Single Node Single Instance Topology
Single Node Multi-Instance Topology
Multi-node Multi-instance Topology
64 | Deployment Topologies
Single Node Single Instance Topology
In a single Node Single Instance configuration, single OMS, JeOMS instances deployed in default Apache
Tomcat will run on a single machine. It refers to the default configuration from a local file system. The Installer
would add the necessary environment variable $AF_CONFIG_HOME to point to the configuration home on the
local file system where configuration files for the OMS, JeOMS, and other application components are stored.
For example, $AF_HOME/config directory.
Figure 21: Single Node Single Instance Topology
Deployment Topologies | 65
Single Node Multi-Instance Topology
This is also known as Vertical Scaling Topology.
Vertical scaling refers to setting up multiple instances of OMS, JeOMS on one machine, usually by creating
cluster members. Vertical scaling allows applications to take advantage of power efficiency of the machine.
An instance of an OMS, JeOMS runs in a single Java virtual machine (JVM) process. However, the inherent
concurrency limitations of a JVM process means that the application cannot fully utilize the processing power
of a machine. Creating additional JVM processes provides multiple thread pools, each corresponding to the
JVM process associated with the application process. This correspondence avoids concurrency limitations
and lets the Application Server use the full processing power of the machine.
The following steps will help to set up multiple OMS and JeOMS instances on single machine:
Prerequisites
1. TIBCO Fulfillment Order Management 2.0.0 is installed on the designated server with all the underlying
required TIBCO products installed. Please note that TIBCO ActiveSpaces 2.0.1 HF-001 is required for
JeOMS in the cluster deployment.
2. Correct configurations are in place for the default topology. For example, Single Node Single Instance. This
indicates that the Apache Tomcat instance under $AF_HOME is up and running with omsServer, omsUi,
config, dashboard and JeOMS wars deployed successfully.
Creating New Cluster Members
1. Access FOM configurator by using http://<HOST>:<PORT>/config/launchConfig.html.
2. Select Order Management System configuration.
3. Select existing Member1 Cluster. Click the right mouse button to pop up the menu. Select Clone Member
as shown in the following figure:
Figure 22: Creating a New Cluster Member
4. In the Clone Member dialog, provide a unique name for the new cluster, for example, Member2, and click
the Create button. A new cluster member Member2 is created.
Figure 23: Clone Member
5. Change the JMX RMI port for Member2 using the following configuration:
Figure 24: JMX RMI Port
6. Save the configuration changes. Newly created Member2 is saved in the
$AF_HOME/config/ConfigValues_OMS.xml file.
7. Select User Interface configuration for Member2 cluster member and change the values for the following
properties.
Provide unique values as displayed:
Figure 25: User Interface
8. Save the port configuration changes for Member2.
9. Perform steps 3 to 7 for configuring more OMS members - Member3, Member4, and so on in the cluster,
according to the requirement.
10. Select Jeopardy Management configuration.
11. Select existing Member1 Cluster. Right-click and select "Clone Member".
12. Perform the same step as 4 to clone the existing JeOMS member, for example, Member1.
13. The value of the property Operation data store location must be different for all the JeOMS instances. It
must be a valid file path.
14. Save the configuration changes. The Configuration Saved popup appears.
15. The new <Server> element entry containing configuration categories corresponding to Member2 are
saved in the $AF_HOME/config/ConfigValues_JEOMS.xml file.
16. OMS/JEOMS deployment itself does not provide load balancing capability but any third party load
balancer can be used to load balance across multiple instances of OMS. For this, no specific configuration
is required. The only requirement is the load balancer must have support for the sticky session. Sticky
sessions means the load balancer always directs a given client to the same back-end server.
Hardware Load Balancer (HLB), which has Layer 7 capability, can direct the traffic and maintain session
persistence for the web applications without relying on the user's IP address with session cookies. Typically,
HLB inserts a cookie that the load balancer creates and manages automatically to remember which back- end
server a given HTTP connection should use. And then it would always direct the request originating from
that client browser to the same server. Some of the HLBs which support layer 7 capability include Barracuda,
jetNexus, and F5.
Configuration of ActiveSpaces Data Grid for Members
1. Go to the $AF_HOME/config directory.
2. The ascache-config.properties file contains the configuration properties for TIBCO ActiveSpaces
such as metaspace and space configurations. This single file is referred by all the members in the cluster.
3. If the default TIBCO PGM protocol is to be used for discovery, there is NO need to change the value of
the metaspace.discovery.url property in the ascache-config.properties file. It must be the same
for each member so that they can discover each other for connecting to the metaspace. For example, the
default value of discovery URL in ascache-config.properties is
metaspace.discovery.url=tibpgm://7889/0.0.0.0;239.8.8.9.
4. If the TCP protocol is to be used for discovery, it must be as according to the TIBCO ActiveSpaces
specifications and contain the ports corresponding to each member. For example, if the ports in the Listen
URL for Member1 & Member2 are 50000 and 500001 respectively, the discovery URL should be
metaspace.discovery.url=tcp://0.0.0.0:50000;0.0.0.0:50001.
5. Listen URL is always TCP protocol based. You can choose to keep metaspace.listen.url property in
ascache-config.properties commented as it is. In that case, ActiveSpaces acquires the TCP ports starting
from 50000 onwards for each new members trying to join the metaspace.
If you want to specify the listen URL, the values of ports specified in the Listen URLs must match with
the ones specified in the Discovery URL considering TCP was used for discovery.
6. See TIBCO ActiveSpaces 2.0.1 documentation for details about the configurations.
Creating Additional Apache Tomcat Instances
1. Stop the only running instance of Apache Tomcat from $AF_HOME/apache-tomcat-7.0.6.
2. Create as many number of copies of the apache-tomcat-7.0.6 directory under $AF_HOME as the number
of members you want to deploy in cluster. This can be done as follows (assuming total three instances are
running):
> cd $AF_HOME
> cp apache-tomcat-7.0.6 apache-tomcat-7.0.6-Member2
> cp apache-tomcat-7.0.6 apache-tomcat-7.0.6-Member3
3. Modify the connector ports and SHUTDOWN port in the conf/server.xml file under each Tomcat
instance as shown in the figure. Set the connector and redirect port values same as the unique values set
for each cloned member.
Figure 26: server.xml file
4. Modify the NODE_ID (member name) for each Tomcat instance in the bin/setenv file.
Specify the NODE_ID as the name of the cluster member, for example, Member2.
All the members will refer the same file - ascache-config.properties for ActiveSpaces configurations. So, there
is no need to change the location of the property ascache.properties.location in setenv.
OMS cluster deployment is primarily done to scale the server components i.e. omsServer and jeoms. This is
performed by deploying omsServer and jeoms components into more than one Tomcat instances. The UI
components, omsui, dashboard, and config can be deployed in any one of the Tomcat instances to have UI
access (see figure).
Essentially, the omsServer component is scaled using EMS. A larger number of message listeners & processors
are activated on deploying more omsServer components. Also, each member connects to the same backend
database through ActiveSpaces data grid cache to get/set the data.
The user can access the configurator and OMS UI applications using one of the Tomcat instances in which
these components are deployed along with omsServer and JeOMS.
Member2 and Member3 have only omsServer and JeOMS components deployed so as to scale the server
capabilities.
Sanity Test
1. Start each Apache Tomcat instance one after another using bin/startup.sh script to start the deployed
components.
2. Ensure using catalina.out logs that all the deployed components in each Tomcat instance have started
correctly without any start-up errors.
3. Assuming AOPD & Orchestrator engines are already started and the required models are published to
them, submit a new order into the system using SOAP/JMS submit order interface.
4. The EMS delivers the message to the first activated order service queue listener in one of the servers.
5. Observe the catalina.out log of each server. One of servers would pick up the submit order request message
and start processing it.
6. For the order to cache and persist in the database, the member which has started processing the request
connects to the configured metaspace, for example, oms_metaspace first. The following figure displays
the typical log statements in the catalina logs (note that 50000 is the TCP port used by the first member
while connecting to the metaspace).
7. Submit another order into the system using SOAP/JMS submit order interface.
8. The EMS delivers the message to the second activated order service queue listener in one of the servers
as per the round robin algorithm.
9. The member which is processing the second order request also connects to the oms_metaspace metaspace
while persisting the order into the database (Note that the second member has acquired the TCP port
50001 while connecting to the metaspace).
10. Both the orders would persist into the same database.
11. The status notification messages received from Orchestrator would also be picked up by the servers in
round robin fashion to process and persist them in the database.
12. You can use as-admin utility available under $AS_HOME/lib to monitor the various members connected
to the metaspace, browse the spaces, and so on. The following figure shows all the connected members
to the oms_metaspace including Member1, Member2, and as admin member.
Multi-node Multi-instance Topology
Multi Node Multi Instance environments extend basic single machine OMS and JeOMS configurations by
distributing the OMS and JeOMS applications over multiple machines, increasing the overall processing
power from one machine to contributions from all machines in the configuration. All running instances can
be part of one administrative group.
For the instance to be a part of one administrative group, the reference to the same configuration should be
given by setting the following environment variable when the tomcat server for each instance is started:
AF_CONFIG_HOME.
AF_CONFIG_HOME should point to the configuration directory of primary OMS installation. For
secondary installation, NODE_ID should point to the configuration created using Configurator. For
example, NODE_ID=Member2.
Figure 27: Multi-node Multi-instance Topology
The steps given in Single Node Multi Instance setup are applicable to setting up multiple OMS and
JeOMS instances on multiple machines. The only difference is to copy Apache Tomcat directory to
the other machines.
Chapter
8
Orchestrator Interfaces
Fulfillment Order Management Orchestrator is the primary fulfillment engine and implemented using TIBCO
BusinessEvents. Orchestrator requests Fulfillment Order Management AOPD to generate the execution plan for
the order submitted by OMS. On receiving the execution plan from AOPD, it executes the plan tasks for order
fulfillment.
This chapter provides the details of various interfaces exposed by Orchestrator for external integration.
For process component development, the following two project library files are shipped with the product under
the $AF_HOME/be/projectLibs directory:
1. AF_Orchestrator.projlib - This library is used in the TIBCO BusinessEvents studio projects for BE 5.x based
process component development. It contains the Orchestrator resources. For example, events,
channels/destinations, XML payload schema, JMS connections, JMS application properties, global variables,
and so on.
2. AF_Orchestrator_ForDesigner.projlib - This library is used in the TIBCO Designer projects for the TIBCO
BusinessWorks-based process component development and contains simple resources. For example, XML
payload schema, JMS connections, JMS application properties, and global variables.
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.
Topics
•
•
•
•
•
Global Variables
Feasibility Providers
Process Components
Pre-qualification Failed Handlers
Plan Item Error Handlers
74 | Orchestrator Interfaces
Global Variables
The following table lists the important global variables for Fulfillment Order Management Orchestrator
configuration related to feasibility enabling, retries, and error handling.
Global Variable
Description
GLB_FeasibilityRequired
Flag that enables/disables an order feasibility request to
a feasibility provider from Orchestrator.
GLB_EnableFeasibilityErrorHandling
Flag that determines whether or not to refer the failed
feasibility request to a pre-qualification failed error
handler.
GLB_EnableOPDErrorHandling
Flag that determines whether or not to refer the failed
OPD request to a pre-qualification failed error handler.
GLB_RetryFailedProcessComponent
Flag that enables/disables the retries of a failed process
component.
GLB_DefaultProcessComponentErrorHandler
Specifies the name of the default error handler for the
process component.
GLB_ProcessComponentRetries
Specifies the number of retries for a failed process
component.
GLB_ProcessComponentRetryInterval
Specifies the time in milliseconds between the two process
component retries.
GLB_PlanItemSLAThresholdConstant
A value between 0.1 to 1.0 that is used to calculate the
threshold duration to be used for plan item SLA
notifications. Threshold Duration =
GLB_PlanItemSLAThresholdConstant * Maximum
Duration.
Orchestrator Interfaces | 75
Feasibility Providers
Overview
Feasibility Provider is a customer-specific implementation that checks whether an order is feasible for
fulfilment. Feasibility might involve network inventory capacity analysis, stock checks, order line validation,
or any other number of checks.
Fulfillment Order Management validation engine (OCV) may be used as part of feasibility checking to
determine if the order has the required order lines to constitute a valid order.
Feasibility checking is an optional step in the fulfilment process within Orchestrator. By disabling feasibility
checking, no Feasibility Provider is required. However, if feasibility is enabled, then a Feasibility Provider
must be available for orders to proceed. Feasibility Providers must conform to the following requirements
in order to be a valid implementation.
Specification
• Receive event messages on a JMS queue.
• Interpret the Feasibility Request event and determine if the order is feasible for fulfilment.
• Create and send a response event on a JMS queue.
• In the response event, specify whether the feasibility check has completed successfully by setting the
completed flag to TRUE if it was able to determine feasibility or FALSE if it was not able to conclude
feasibility.
• In the response event specify whether the order has passed feasibility by setting the passed flag to TRUE
if the order is feasible, or FALSE if it is not feasible.
• In the response event, optionally specify a list of warning or error messages whether the order has passed
feasibility or not.
Since the feasibility checking process is a customer-implemented component, the functional specification for
this process is out of scope of this document.
Feasibility Request
Feasibility Request is an event sent by Orchestrator to the Feasibility Provider to request order feasibility
checking. It is an asynchronous request/reply event to a JMS queue that returns a reply to the default reply
queue for Feasibility Response.
If an exception occurs during feasibility checking, then it should be logged to the Feasibility Provider log.
The details of the exception are returned in the response.
Event Type
Asynchronous request event
Queue or
Topic
Queue
Destination
tibco.aff.orchestrator.provider.order.feasibility.request
The event does not have any properties.
The event has the following payload:
Figure 28: Feasibility Request
The following table lists the details of the elements.
Element
Type
Cardinality Description
businessTransactionID String
Optional
Unique identifier for tracing purposes across function calls.
correlationID
String
Optional
Unique identifier to correlate the request message with a
response message.
orderID
String
Required
Order ID for the order to feasibility check.
orderRequest
Type
Required
Order Request type. Refer to Appendix A for the
specification of this type.
Feasibility Response
Feasibility Response is an event sent by Feasibility Provider back to Orchestrator in response to a Feasibility
Request event. It is an asynchronous reply event to a JMS queue.
The response for feasibility has completed and passed flags. Orchestrator will route the order lifecycle based
on the returned value of these flags. The two flags can be used to distinguish between technical and business
exceptions. For example, a failure to complete would generally indicate a technical exception so complete
would be false. A validation failure would indicate a business exception where complete would be true, but
passed would be false.
Completed This flag indicates whether the feasibility call completed. If this is set to true, then the Passed
flag becomes relevant.
Passed
This flag indicates whether the order has passed feasibility.
Based on different scenarios, these flags should be set as follows:
Completed
Passed
Description
Technical Error False
False True
Orchestrator refers the order to the Pre-Qualification Failed
Handler if error handling is enabled for feasibility, or the error
is withdrawn if error handling is not enabled.
Business Error True
False
Orchestrator refers the order to the Pre-Qualification Failed
Handler if error handling is enabled for feasibility, or the error
is withdrawn if error handling is not enabled.
Success
True
True
Processing continues as normal.
Event Type
Asynchronous reply event
Queue or Topic Queue
Destination
tibco.aff.orchestrator.provider.order.feasibility.reply
Figure 29: Feasibility Response
Element
Type
Cardinality
Description
Optional
correlationID
String
Required
response message. Even though this field is marked as
optional in the response schema, it is required for
Orchestrator to be able to correlate the response with the
correct version of the submitted order. Populate this field
the same as correlationID in the request message.
resultStatus
Type
Required
orderID
String
Required
Order ID for the order that was feasibility checked.
orderRef
String
Required
Order ref for the order that was feasibility checked.
completed
Boolean
Required
Flag indicating whether the feasibility call completed.
passed
Boolean
Required
Flag indicating whether the order has passed feasibility.
message
Type
0-M
Message type. Refer to Appendix A for the details of this
type of specification. This list of messages will be passed
to the Pre-Qualification Failed Handler if invoked.
Result status type. Refer to Appendix A for the specification
for this type.
Process Components
Overview
A Process Component is the implementation of a series of steps that are required to fulfill a plan item. Process
components should be implemented using any JMS-enabled technology provided they meet the requirements
outlined here. Typically short-lived, automated processes will be implemented in BusinessEvents or
BusinessWorks, while long-lived and manual processes will be implemented in iProcess.
These are required components in the architecture.
Specification
Process Components must conform to the following requirements in order to be a valid implementation.
1. Receive event messages on a JMS queue.
2. Receive the following event types:
a. Plan Item Execute Request
b. Plan Item Suspend Request
c. Plan Item Activate Request
3. For plan item execute requests, perform a series of tasks that are required to fulfill the product and action
specified in the plan item. Once it has completed, send a plan item execute response.
4. When instructed to do so, halt execution at certain milestones until notified by Orchestrator it may continue.
5. For plan item suspend requests, halt execution of an in-progress process component. This may or may
not be possible so it is valid to send back a plan item execute response if execution completed, or plan
item suspend response if execution was suspended.
6. For plan item activate requests, resume execution of a previously suspended process component. This
resume takes the form of one of the following cases:
a. Resume execution from the point where it was previously suspended.
b. Cancel execution and rollback previously completed tasks.
c. Cancel execution and do not rollback previously completed tasks.
7. Create and send response events on a JMS queue.
8. Respond with the following event types:
a. Plan Item Execute Response
b. Plan Item Suspend Response
Plan Item Execute Request Event
Plan Item Execute Request Event is sent by Orchestrator to a Process Component to request the fulfillment
of a particular plan item. It is received by the Process Component and a series of tasks then executes. It is an
asynchronous event to a JMS queue. The response is another asynchronous event on a different JMS queue.
Event Type
Asynchronous event
Queue or Topic
Queue
Destination
tibco.aff.orchestrator.planItem.execute.request
The destination name tibco.aff.orchestrator.planItem.execute.request is valid only if owner
value is "". Otherwise, the destination would be as follows: (If owner value is defined), the destination
would be tibco.aff.orchestrator.planItem.<ownertype>.execute.request .
For example, if the owner value in the plan fragment model is BPM, the destination would be
tibco.aff.orchestrator.planItem.BPM.execute.request.
The event has the following properties:
Property
Type
Cardinality
Description
processComponentID String
Required
Unique identifier for the Process Component to be
executed.
processComponentName String
Required
Name of the Process Component to be executed. This
is the name as configured in the Process Component
Model for the specified processComponentID. If there
is no model specified then this field is null.
processComponentVersion String
Required
Version of the Process Component to be executed. This
is the version as configured in the Process Component
Model for the specified processComponentID. If there
is no model specified then this field is null.
processComponentType String
Required
Type of the Process Component to be executed. This is
the type as configured in the Process Component Model
for the specified processComponentID. If there is no
model specified then this field is null.
processComponentRecordType String
Required
JMSPriority
Required
Integer
It is a class of processComponentType. This is the
processComponentRecordType as configured in the
Process Component Model. If there is no model
specified then this field is null.
It is the standard JMS message priority to be sent in the
outbound message to support order priority.
The payload specification is as follows:
Figure 30: Plan Item Execute Request
Element
Type
businessTransactionID
String
Optional
Unique identifier for tracing purposes across
function calls.
correlationID
String
Optional
Unique identifier to correlate the request message
with a response message.
orderID
String
Required
Internal unique identifier for the order associated
with the plan containing the plan item to execute.
orderRef
String
Required
External unique identifier for the order associated
planID
String
Required
Internal unique identifier for the plan that contains
the plan item to execute.
planItem
Type
Required
Plan item type for the plan item to execute. Refer to
the Plan Item schema in Appendix A.
sla
Type
Optional
Service level agreement type.
sla/typicalDuration
Long
Required
Typical duration in msec for this execution when
SLAs are implemented in the Process Component.
sla/maximumDuration
Long
Required
Maximum duration in msec for this execution when
SLAs are implemented in the Process Component.
waitAtMilestoneID
String
0-M
Milestone ID for a milestone within the Process
Component where execution must wait until notified
by Orchestrator that it should proceed.
notifyAtMilestoneID
String
0-M
MilestoneID for a milestone within the Process
Component where the Process Component must
notify Orchestrator that the milestone has been
passed during execution.
Plan Item Milestone Release Request Event
Plan Item Milestone Release Event is sent by Orchestrator to a Process Component to instruct it to continue
execution when stopped at a particular milestone. It may be possible that this notification will occur before
the Process Component has reached the milestone during execution. Therefore it is necessary for the Process
Component to maintain a state of the milestone at any time during execution. There is no response to this
interface.
Event Type
Asynchronous event
Queue or Topic
Queue
Destination
tibco.aff.orchestrator.planItem.milestone.release.request
Property
Type
Cardinality
Description
processComponentID
String
Required
Unique identifier for the Process Component
to be executed.
Required
Name of the Process Component to be
executed. This is the name as configured in the
Process Component Model for the specified
processComponentID. If there is no model
Required
Version of the Process Component to be
executed. This is the version as configured in
the Process Component Model for the specified
Required
Type of the Process Component to be executed.
This is the type as configured in the Process
Component Model for the specified
planID
String
Required
Internal unique identifier for the plan that
contains the plan item with the milestone to be
released.
planItemID
String
Required
Unique identifier for the plan item that contains
the milestone to be released.
milestoneID
String
Required
Unique identifier for the milestone within the
plan item and plan to be released.
Figure 31: Plan Item Milestone Release Request
Element
Type
Cardinality
Description
String
Optional
Unique identifier for
tracing purposes across
function calls.
correlationID
String
Optional
Unique identifier to
correlate the request
message with a response
message.
orderID
String
Required
Internal unique identifier
for the order associated
with the plan containing
the plan item with the
milestone to be released.
orderRef
String
Required
External unique identifier
for the order associated
with the plan containing
planID
String
Required
Internal unique identifier
for the plan that contains
planItem
Type
Required
Plan item type for the
plan item with the
Refer to the Plan Item
schema in Appendix A.
milestoneID
String
Required
Unique identifier for the
milestone within the plan
item and plan to be
released.
Plan Item Milestone Notify Request Event
Plan Item Milestone Notify Event is sent by a Process Component to Orchestrator to notify the orchestration
engine that a particular milestone has been passed during execution.
Event Type
Asynchronous event
Queue or Topic
Queue
Destination
tibco.aff.orchestrator.planItem.milestone.notify.request
Figure 32: Plan Item Milestone Notify Request Event
Element
Type
Cardinality
Description
String
Optional
Unique identifier for tracing
purposes across function calls.
correlationID
String
Optional
Unique identifier to correlate the
request message with a response
message.
orderID
String
Required
Internal unique identifier for the
order associated with the plan
containing the plan item with the
milestone to notify.
orderRef
String
Required
External unique identifier for the
order associated with the plan
containing the plan item with the
planID
String
Required
plan that contains the plan item
with the milestone to notify.
planItemID
String
Required
Unique identifier for the plan
item within the plan with the
milestoneID
String
Required
milestone within the plan item in
the plan to notify.
Plan Item Execute Response Event
Plan Item Execute Response Event is sent by a Process Component as a response to a Plan Item Execute
Request Event or a Plan Item Suspend Event. Orchestrator receives the result and interprets the result
accordingly. It is an asynchronous event to a JMS queue.
The response for Plan Item Execute has success, completed, and cancelled flags. Orchestrator does not take
any action in response to the cancelled flag. However it does route plan items to the Plan Item Failed Handler
if either completed or success is set to false. Functionally, Orchestrator handles both of these the same. Plan
Item Failed Handlers may choose to handle the exception differently depending on a completed or failure
status.
The two flags can be used to distinguish between technical and business exceptions. For example, a failure
to complete would generally indicate a technical exception so completed would be false. A validation failure
would indicate a business exception where complete would be true, but success would be false.
Completed
This flag indicates that the Process Component completed. If this is set to true, then the Success
flag becomes relevant. If this is false then the Process Component did not complete and the
Success flag is automatically considered to be false as well.
Success
This flag indicates whether the Process Component was successful. This is only relevant if
the complete flag is set to true.
The possible response scenarios are:
Complete
Passed
Description
Technical Error
False
False True
Orchestrator will retry the Process Component call for the
defined number of retries with the defined retry interval. If
the Process Component call continues to fail, then it will refer
the plan item to the Plan Item Failed Handler.
Business Error
True
False
Orchestrator will refer the plan item to the Plan Item Failed
Handler.
Success
True
True
Processing continues as normal.
In addition to the completed and success values, the Plan Item Execute Response Event also allows returning
a cancelled flag. This is only valid if responding to a Plan Item Activate Request Event and it indicates whether
the cancellation was completed successfully whether or not a rollback was requested. The completed and
success values retain the same definitions in the event of an activation request as in an execution request.
The possible response scenarios are:
Cancelled
Description
Execute Request
False
No cancellation occurred.
Activate Request with Rollback True
Cancellation requested with rollback.
Activate Request without
Rollback
Cancellation requested with no rollback.
True
Event Type
Asynchronous event
Queue or Topic
Queue
Destination
tibco.aff.orchestrator.planItem.execute.reply
Figure 33: Plan Item Execute Response
Element
Type
Cardinality
Description
Optional
function calls.
correlationID
String
Optional
resultStatus
Type
Required
Result status type. Refer to Appendix A for the
specification for this type.
orderID
String
Required
orderRef
String
Required
planID
String
Required
the plan item to execute.
planItemID
String
Required
Unique identifier for the plan item within the plan
to be executed.
completed
Boolean
Required
Flag indicating if the Process Component completed
processing.
success
Boolean
Required
Flag indicating if the Process Component completed
successfully.
cancelled
Boolean
Required
Flag indicating that the Process Component
successfully cancelled previously completed tasks.
message
Type
0-M
Message type. Refer to Appendix A for the
specification for this type.
typicalSLAViolated Type
Optional
Flag indicating that the execution time of the Process
Component violated the typical SLA duration.
maximumSLAViolated Type
Optional
Flag indicating that the execution time of the Process
Component violated the maximum SLA duration.
Plan Item Suspend Request Event
Plan Item Suspend Request Event is sent by Orchestrator to a Process Component to request suspension of
execution of a particular plan item. It is received by the Process Component which then either suspends
execution or completes execution. It is an asynchronous event to a JMS queue. The response is another
asynchronous event on a different JMS queue.
Event Type
Asynchronous event
Queue or Topic
Queue
Destination
tibco.aff.orchestrator.planItem.suspend.request
The destination name tibco.aff.orchestrator.planItem.suspend.request is valid only if owner
would be tibco.aff.orchestrator.planItem.<ownertype>.suspend.request .
tibco.aff.orchestrator.planItem.BPM.suspend.request.
Property
Type
processComponentID String
Required
Unique identifier for the Process Component to be executed.
Required
Name of the Process Component to be executed. This is the
name as configured in the Process Component Model for the
specified processComponentID. If there is no model specified
then this field is null.
Required
Version of the Process Component to be executed. This is the
version as configured in the Process Component Model for the
specified processComponentID. If there is no model specified
then this field is null.
Required
Type of the Process Component to be executed. This is the type
as configured in the Process Component Model for the specified
processComponentID. If there is no model specified then this
field is null.
Required
JMSPriority
Integer Required
processComponentRecordType as configured in the Process
Component Model. If there is no model specified then this field
is null.
It is the standard JMS message priority to be sent in the
outbound message to support order priority.
Figure 34: Plan Item Suspend Request
Element
Type
String
Optional
Unique identifier for tracing purposes across function
calls.
correlationID
String
Optional
orderID
String
Required Internal unique identifier for the order associated
with the plan containing the plan item to be
suspended.
orderRef
String
Required External unique identifier for the order associated
with the plan containing the plan item to be
suspended.
planID
String
Required Internal unique identifier for the plan that contains
the plan item to be suspended.
planItem
Type
Required Plan item type for the plan item to be suspended.
Refer to Plan Item schema in Appendix A.
Plan Item Suspend Response Event
Plan Item Suspend Response Event is sent by a Process Component as a response to a Plan Item Suspend
Request Event. Orchestrator receives the result and interprets the result accordingly. It is an asynchronous
event to a JMS queue.
Event Type
Asynchronous event
Queue or
Topic
Queue
Destination
tibco.aff.orchestrator.planItem.suspend.reply
Figure 35: Plan Item Suspend Response
Element
Type
Cardinality
Description
Optional
correlationID
String
Optional
response message.
resultStatus
Type
Required
Result status type. Refer to Appendix A for the specification
for this type.
orderID
String
Required
Internal unique identifier for the order associated with the
plan containing the plan item to suspend.
orderRef
String
Required
External unique identifier for the order associated with the
plan containing the plan item to suspend.
planID
String
Required
Internal unique identifier for the plan that contains the plan
item to suspend.
planItemID
String
Required
Unique identifier for the plan item within the plan to be
suspended.
completed
Boolean
Required
Flag indicating if the Process Component suspend
completed processing.
success
Boolean
Required
Flag indicating if the Process Component suspend
completed successfully.
Plan Item Activate Request Event
Plan Item Activate Request Event is sent by Orchestrator to a Process Component to request activation of a
previously suspended plan item. It is received by the Process Component which then resumes, cancels with
rollback, or cancels without rollback. It is an asynchronous event to a JMS queue. There is no specific response
to a Plan Item Activate Request Event, however the Process Component is expected to complete processing
and return a Plan Item Execute Response Event as usual.
Event Type
Asynchronous event
Queue or
Topic
Queue
Destination
tibco.aff.orchestrator.planItem.activate.request
The destination name tibco.aff.orchestrator.planItem.activate.request is valid only if owner
would be tibco.aff.orchestrator.planItem.<ownertype>.activate.request .
tibco.aff.orchestrator.planItem.BPM.activate.request.
Property
Type
Cardinality
Description
processComponentID
String
Required
Unique identifier for the Process Component to
be executed.
processComponentName
String
Required
Name of the Process Component to be executed.
This is the name as configured in the Process
Required
Version of the Process Component to be executed.
This is the version as configured in the Process
processComponentType
String
Required
Required
JMSPriority
Required
Integer
Type of the Process Component to be executed.
This is the type as configured in the Process
processComponentRecordType as configured in
the Process Component Model. If there is no
model specified then this field is null.
It is the standard JMS message priority to be sent
in the outbound message to support order
priority.
Figure 36: Plan Item Activate Request
Element
Type
Cardinality
Description
String
Optional
function calls.
correlationID
String
Optional
Unique identifier to correlate the request
message with a response message.
orderID
String
Required
Internal unique identifier for the order
associated with the plan containing the plan
item to activate.
orderRef
String
Required
External unique identifier for the order
associated with the plan containing the plan
item to activate.
planID
String
Required
Internal unique identifier for the plan that
contains the plan item to activate.
planItem
Type
Required
Plan item type for the plan item to activate.
Refer to Plan Item schema in Appendix A.
resumeExecution
Type
Required,
Choice
should resume execution from the point where
it was previously suspended.
cancelAndRollback
Type
Required,
Choice
should cancel execution and roll back
previously completed tasks.
cancelWithNoRollback
Type
Required,
Choice
should cancel execution and not roll back
previously completed tasks.
Pre-qualification Failed Handlers
Overview
A Pre-Qualification Failed Handler is a customer-implemented component used to manage failed feasibility
and plan development steps in Orchestrator. During the fulfillment process, Orchestrator would optionally
call out to a Feasibility Provider and always call out to a Plan Development Provider.
The Feasibility Provider analyzes the order to determine if it can be fulfilled. If it indicates that the order
cannot be fulfilled, then the fulfillment process cannot proceed. The order may be referred to the
Pre-Qualification Failed Handler for manual intervention if feasibility error handling is enabled.
The Plan Development Provider designs a plan from the order. If a plan cannot be designed then the fulfillment
process cannot proceed and the order may be referred to the Pre-Qualification Failed Handler for manual
intervention if OPD error handling is enabled.
Please refer to the Global Variables on page 74 for enabling feasibility and OPD error handling.
Pre-Qualification Failed Handler is an optional component in the architecture. Customers may choose to
implement full error handling within the Feasibility Provider and the Plan Development Provider. In that
case it is not valid to return anything back to Orchestrator other than passed in the case of feasibility and
success in the case of plan development. If anything else is returned to Orchestrator there is no handler to
process the result and the plan remains either in feasibility or OPD state.
Specification
Pre-Qualification Failed Handlers must conform to the following requirements in order to be a valid
implementation.
2. Interpret the Pre-Qualification Failed Request event and determine how best to route the failed order for
further processing.
3. If necessary, distinguish between feasibility and plan development failures and direct the order to the
correct handling component.
4. Create and send a response event on a JMS queue.
5. In the response event specify one of three possible actions that Orchestrator is to take in response to the
error: resubmit, retry, or withdraw.
The three actions that can be specified are as follows:
Resubmit
The Pre-Qualification Failed Handler sends back a new orderRequest that Orchestrator resubmits
automatically. This is handled as a pre-execution order amendment and execution begins from
Submitted state. An audit history of the original order is maintained in the Transient Data Store.
In order to resubmit, the orderID and orderRef in the new order must match that of the original
order.
Retry
Orchestrator resubmits the order to either the Feasibility Provider or the Plan Development
Provider as it was originally submitted. If this new call fails, the order is sent back to the
Pre-Qualification Failed Handler again.
Withdraw The order will be withdrawn from Orchestrator and not be fulfilled. It is deleted from the engine
and Transient Data Store.
The details of the Pre-Qualification Failed Handler is left as a customer-specific implementation. An example
of a handler could be the following:
1. Receive a Pre-Qualification Failed Handler Request event messages on a JMS queue by a BusinessWorks
process.
2. BusinessWorks starts a process instance in iProcess.
3. The iProcess process model creates a manual task and displays a form in a work queue for operations
support. The form displays the order as well as the details of the failure.
4. Operations support reviews the task and chooses one of the following options:
a. Make changes to the order that allows the order to pass feasibility and plan development. The order
should be resubmitted.
b. Update configurations in back-end systems or product catalogue that allows the order to pass feasibility
and plan development. The order may then be retried.
c. Determine the order is invalid and withdraw the order.
5. The task is completed.
6. iProcess then invokes a BusinessWorks service that creates the Pre-Qualification Failed Handler Response
event, and populates the event with the appropriate information and flags the response to resubmit, retry,
or withdraw as appropriate. This event is then sent on a JMS queue to Orchestrator. The iProcess procedure
then terminates.
7. Orchestrator receives the Pre-Qualification Failed Handler Response and processes it accordingly.
Pre-Qualification Failed Request Event
Pre-Qualification Failed Request Event is sent by Orchestrator in response to a failed feasibility or plan
development call. It is received by the Pre-Qualification Failed Handler for manual processing. It is an
asynchronous event to a JMS queue. The response is another asynchronous event on a different JMS queue.
Event Type
Asynchronous event
Destination
tibco.aff.orchestrator.provider.order.prequal.failed.request
Figure 37: Pre-Qualification Failed Request
Element
Type
Cardinality
Description
Optional
Unique identifier for tracing purposes across function
calls.
correlationID
String
Optional
Unique identifier to correlate the request message with
a response message.
orderID
String
Required
Order ID for the order that failed feasibility or plan
development.
orderRequest
Type
Required
Order Request type for the order that failed feasibility
or plan development. Refer to Appendix A for the
feasibilityFailed
Type
Required, Choice Flag indicating that this failure was due to a feasibility
failure.
opdFailed
Type
Required, Choice Flag indicating that this failure was due to a plan
development failure.
message
Type
0-M
Message type. Refer to Appendix A for the specification
for this type. This will be any list of messages passed
back from the Feasibility Provider or the Plan
Development Provider.
Pre-qualification Failed Response Event
Pre-Qualification Failed Response Event is sent by Pre-Qualification Failed Handler as a response to the failed
feasibility or plan development step. Orchestrator receives the result and interprets the result accordingly.
It is an asynchronous event to a JMS queue.
Event Type
Asynchronous event
Destination
tibco.aff.orchestrator.provider.order.prequal.failed.reply
Figure 38: Pre-qualification Failed Response
Element
Type
Cardinality
Description
Optional
function calls.
correlationID
String
Required
with a response message. Even though this field
is marked as optional in the response schema, it
is required for Orchestrator to be able to correlate
the response with the correct version of the
submitted order. Populate this field the same as
correlationID in the request message.
orderID
String
Required
Internal unique identifier for the order that failed
feasibility or plan development.
orderRef
String
Required
External unique identifier for the order that failed
feasibility or plan development.
withdraw
Type
Required, Choice
Flag indicating that the order should be
withdrawn.
retryFeasibility
Type
Required, Choice
Flag indicating that the order should retry
feasibility without any changes. This response
may be made in cases where the request was for
either feasibility or plan development failure.
retryOPD
Type
Required, Choice
Flag indicating that the order should retry plan
development without any changes. This response
may be made in cases where the request was for
plan development failure. Technically there is no
restriction on doing so in the case of a feasibility
failure, but functionally it does not make sense
to do so.
orderRequest
Type
Required, Choice
Order request type. Refer to Appendix A for the
specification for this type. This is provided in the
case of an order resubmit.
message
Type
0-M
Message type. Refer to Appendix A for
specification of this type. If populated, this list of
messages will be returned in any Submit Order
Response message occurring after the call to the
PreQualification Failed Handler occurred.
Plan Item Error Handlers
Overview
A Plan Item Error Handler is a customer-implemented component used to manage failed plan items. During
fulfillment, the Orchestrator requests plan item execution from a Process Component. When execution
completes, the Process Component may specify one of three result conditions:
• Execution completed successfully
• Execution completed, but with error
• Execution did not complete
Successful execution results in the plan item being flagged as Complete and execution continuing with the
next items in the plan.
Error or incomplete execution means that the plan item has not been successfully completed and therefore
the next items in the plan should not begin execution until the conditions that caused the failure are rectified.
Orchestrator does not distinguish between an incomplete execution and an error response when determining
how to handle the failed plan item. Both are handled the same by invoking the Plan Item Error Handler and
indicating which failure mode returned. The semantics of how to determine whether a Process Component
is incomplete or in error is left to a customer-specific interpretation and implementation. The implementation
between Process Components and the Plan Item Error Handler should be consistent.
Plan Item Error Handler is an optional component in the architecture. Customers may choose to implement
full error handling within the Process Component. In that case it is not valid to return anything back to
Orchestrator other than success. If anything else is returned to Orchestrator, there would be no handler to
process the result and the plan remains in an execution state without progressing beyond the failed plan
item.
Specification
Plan Item Error Handlers must conform to the following requirements in order to be a valid implementation.
2. Interpret the Plan Item Failed Request event and determine how best to route the failed plan item for
further processing.
3. If necessary, distinguish between incomplete execution and error response execution and interpret the
Error Handler field in the Plan Item Failed Request and direct the plan item to the correct handling
component.
4. Create and send a response event on a JMS queue.
5. In the response event, specify one of three possible actions that Orchestrator is to take in response to the
reply: retry, resume, or complete.
The three actions that can be specified are as follows:
Retry
The plan item is resubmitted to the Process Component to start over from the beginning. This
occurs immediately upon receipt of the Plan Item Failed Response event as all dependencies
have been previously satisfied. The Process Component is notified to re-execute the plan item
through a Plan Item Execute Request event. If Orchestrator has been automatically set up to retry
failed process components, and this retry fails as well, the retry count is not reset to zero. In other
words, if the retry from a Plan Item Failed Handler response fails, then that failure is immediately
redirected back to the Plan Item Failed Handler for processing again as a new failed plan item,
and not automatically retried further.
Resume
The plan item is resumed in the Process Component from the point of failure. The implementation
details of this are left for Process Component design. However it is conceivable that the Process
Component may choose to handle a resume the same as a full retry if it is not functionally possible
to resume execution from the point of failure. The Process Component is notified to resume the
plan item through a Plan Item Activate event.
Complete The plan item is considered to be completed and not resubmitted to the Process Component.
Orchestrator marks the plan item as Complete and processing continues. Any dependencies on
the newly Completed plan item is evaluated and further plan items triggered as in the normal
execution.
The details of the Plan Item Failed Handler is left as a customer-specific implementation. An example of a
handler could be the following:
1. Receive a Plan Item Failed Handler Request event message on a JMS queue by a BusinessWorks process.
2. BusinessWorks starts a process instance in iProcess.
3. The iProcess process model makes a service call out to Transient Data Store to retrieve the order.
4. The iProcess process model creates a manual task and displays a form in a work queue for operations
support. The form displays the order as well as the details of the failure.
5. Operations support reviews the task and chooses one of the following options:
a. Make changes to the order which allow the order to process successfully in the Process Component.
The changed order is then saved in TDS and the plan item may be retried or resumed.
b. Make changes to back-end systems that allow the order to process successfully in the Process
Component. The plan item may be retried or resumed.
c. Implement the required functionality for the plan item manually in the back-end systems. The plan
item may be completed.
6. iProcess then invokes a BusinessWorks service that creates the Plan Item Failed Handler Response event,
populates the event with the appropriate information, and flags the plan item to complete, retry, or resume.
This event is then sent on a JMS queue to Orchestrator.
7. Orchestrator receives the Plan Item Failed Handler Response and processes it accordingly.
Plan Item Failed Request Event
Plan Item Failed Request Event is sent by Orchestrator in response to a failed plan item. It is received by the
Plan Item Failed Handler for manual processing. It is an asynchronous event to a JMS queue. The response
is another asynchronous event on a different JMS queue.
Event Type
Asynchronous event
Queue or
Topic
Queue
Destination
tibco.aff.orchestrator.provider.planItem.failed.request
Figure 39: Plan Item Failed Request
Element
Type
Cardinality
Description
Optional
function calls.
correlationID
String
Optional
orderID
String
Required
with the plan containing the failed plan item.
orderRef
String
Required
with the plan containing the failed plan item.
planID
String
Required
the failed plan item.
planItem
Type
Required
Plan item type for the plan item that failed. Refer to
the Plan Item schema in Appendix A.
errorHandler
String
Required
Name of the error handler to invoke for this failed
plan item. This value is either populated from the
Process Component Model for the Process
Component if it exists or with the default error
handler from the Orchestrator configuration.
message
Type
0-M
Message type. Refer to Appendix A for the
specification for this type. This is the list of messages
as returned in the Plan Item Execute Response Event.
Plan Item Failed Response Event
Plan Item Failed Response Event is sent by Plan Item Failed Handler as a response to the failed plan item.
Orchestrator receives the result and interprets the result accordingly. It is an asynchronous event to a JMS
queue.
Event Type
Asynchronous event
Destination
tibco.aff.orchestrator.provider.planItem.failed.reply
Figure 40: Plan Item Failed Response
Element
Type
Optional
correlationID
String
Required
response message. Even though this field is marked as optional
in the response schema, it is required for Orchestrator to be
able to correlate the response with the correct version of the
submitted order. Populate this field the same as correlationID
in the request message.
orderID
String
Required
Internal unique identifier for the order associated with the plan
containing the failed plan item.
orderRef
String
Required
External unique identifier for the order associated with the
plan containing the failed plan item.
planID
String
Required
Internal unique identifier for the plan that contains the failed
plan item.
planItemID
String
Required
Unique identifier for the plan item within the plan that failed.
retry
Type
Required,
Choice
Flag indicating that the plan item should be retried.
resume
Type
Required,
Choice
Flag indicating that the plan item should be resumed from the
point of failure.
complete
Type
Required,
Choice
Flag indicating that the plan item should be marked as
Complete and execution continue.
message
Type
0-M
Message type. Refer to Appendix A for specification of this
type. If populated, this list of messages will be returned in any
Submit Order Response message occurring after the call to the
Plan Item Failed Handler occurred.
Chapter
9
Data Access Interfaces
Overview
In the ActiveFulfillment 1.2.0 architecture, the Transient Data Store component was a BE engine intended to store
the intermittent data such as the user defined data passed into the order, propagated in the plan and required by
the process components during the order life cycle.
The primary functionalities of Transient Data Store BE engine were as follows:
• Storing the full order and plan data in a transient, fault-tolerant data store.
• Returning the order and plan data to the requesting process components over the standard JMS interfaces.
In Fulfillment Order Management 2.0.0, the BE-based Transient Data Store component has been removed from the
architecture. The required functionality and interfaces are now handled by the OMS server component and driven
by the order and plan data in OMS database. This has helped simplify the architecture and avoid the duplication
of data in OMS database and TDS backing store database.
The following sub-sections cover the details of various data access JMS interfaces which are now exposed by OMS.
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
102 | Data Access Interfaces
Get Order
Overview
The GetOrder interface can be used by the process components to retrieve a specific order from the Fulfillment
Order Management system. It is a synchronous request/reply interface on a JMS queue that returns a reply
either to the specified JMSReplyTo destination on the request message or to the default reply queue if not
specified.
If an exception occurs during Get Order operation then it is logged into the omsServer log. The details of the
exception are returned in the response.
Get Order Request
The request specification is as follows:
Destination
tibco.aff.tds.order.read.request
The following properties should be passed in the request message header:
Element
Type
Cardinality
Description
_nm_
String
Required
Interface identifier name; MUST be set as
GetOrderRequestEvent.
Optional
This is used for logging.
correlationID
String
Optional
Unique identifier for tracing purposes across a single
function call. This is generally used by the calling
application to correlate requests and responses.
orderID
String
Required
Internal unique identifier for the order to retrieve.
requestReply
Boolean
Required
If set to true:
The response will be sent on the temporary queue by
default or on the destination set as JMSReplyTo property
in the request message.
If set to false:
The response will be sent on
queue.
allValues
Boolean
Required
If true, retrieve all versions of the order in case of
amendments.
There is no body (payload) associated with the request message.
Get Order Response
The response specification is as follows:
tibco.aff.tds.order.reply
Data Access Interfaces | 103
Queue or
Topic
Queue
Destination
temp queue or JMSReplyTo destination or tibco.aff.tds.order.reply queue
The response message contains the following header properties:
Element
Type
Optional
correlationID
String
Optional
Unique identifier for tracing purposes across a single function
call. This is generally used by the calling application to
correlate requests and responses.
success
Boolean
Required
Flag indicating if the call was successful.
messageCode
String
Required
Result message code.
message
String
Required
Result message.
orderID
String
Required
Internal unique identifier for the order specified in the request.
found
Boolean
Required
Flag indicating if the order was found.
The response message contains the XML payload as per the following schema:
Figure 41: Get Order Response
Element
Type
Optional
resultStatus
Required
Result status type. Refer to Appendix A for specification of this
type.
Type
order
Type
Optional
Order type. If the order is not found this will be omitted.
order/orderID
String
Required
Internal unique identifier for the order.
order/orderRef
String
Required
External unique identifier for the order.
order/planID
String
Optional
The internal unique identifier for the plan for the order if it exists.
order/status
String
Required
The Status of the order from a cache data store perspective (active
or complete)
0-M
Xml string representation of the order, multiple if all versions are
requested, otherwise just the active one
order/serializedOrder String
Get Plan
Overview
The GetPlan interface can be used by the process components to retrieve the plan corresponding to an order
from the FOM system. It is a synchronous request/reply interface on a JMS queue that returns a reply either
to the specified JMSReplyTo destination on the request message or to the default reply queue if not specified.
If an exception occurs during GetPlan operation then it is logged into the omsServer log. The details of the
exception are returned in the response.
Get Plan Request
Queue or Topic
Queue
Destination
tibco.aff.tds.plan.read.request
Element
Type
Cardinality
Description
_nm_
String
Required
GetPlanRequestEvent.
Optional
function calls.
planID
String
Required
Internal unique identifier for the plan to retrieve.
correlationID
String
Optional
requestReply
Boolean
Required
Unique identifier for tracing purposes across a
single function call. This is generally used by the
calling application to correlate requests and
responses.
If set to true:
The response will be sent on the temporary queue
by default or on the destination set as JMSReplyTo
property in the request message.
If set to false:
tibco.aff.tds.plan.reply
idsOnly
Boolean
Required
queue.
If true will only return the IDs of elements rather
than all plan data. Otherwise if false will return all
plan data.
includeItems
Boolean
Required
If true will return all plan items with the plan.
Otherwise if false then only the plan details are
returned.
originator
String
Optional
The component which has originated this call. E.g.
the name of the process component
PC_BUNDLE_PROVIDE.
There is no body (payload) associated with the request message.
Get Plan Response
The response contains a UDF, namely 'PLAN_DESCRIPTION' under the Plan element which gives the plan
description to the process components. This value comes from the order description provided during order
submission process. If the order description is not provided then a default plan description 'Plan For' <order
ref> is returned in the PLAN_DESCRIPTION UDF field.
Queue or Topic
Queue
Destination
temp queue or JMSReplyTo destination or tibco.aff.tds.plan.reply queue
Element
Type
Cardinality
Description
String
Optional
purposes across function calls.
correlationID
String
Optional
purposes across a single function
call. This is generally used by the
calling application to correlate
requests and responses.
success
Boolean
Required
Flag indicating if the call was
successful.
messageCode
String
Required
message
String
Required
Result message.
planID
String
Required
plan specified in the request.
found
Boolean
Required
Flag indicating if the plan was
found.
Figure 42: Get Plan Response
Element
Type
String
Optional
function calls.
resultStatus
Type
Required
Result status type. Refer to Appendix A for
plan
Type
Optional
Plan type. If the plan was not found this will be
omitted.
plan/planID
String
Required
Internal unique identifier for the plan.
plan/orderID
String
Required
Internal unique identifier for the order for the plan.
plan/orderRef
String
Required
External unique identifier for the order for the plan.
plan/udf
Type
0-M
UDF type.
plan/udf/type
String
Optional
Type of the user defined field.
plan/udf/flavour
String
Optional
Flavour of the UDF. The valid values are one of the
following three:
• config - For UDF corresponding to a
characteristic in the product model or a system
UDF generated by AOPD.
• input - For UDF passed in the order.
• output - For UDF set by the process component.
plan/udf/name
String
Required
Field name.
plan/udf/value
String
Optional
Field value.
plan/udf/originalValue
String
Optional
Original field value at time of plan creation.
plan/udf/lastModified
DateTime
Optional
Timestamp when the UDF was last modified.
plan/planItem
Type
0-M
Plan item type.
plan/planItem/planItemID String
Required
Internal unique identifier for the plan item.
plan/planItem/planItemName String
Optional
Name of the process component.
plan/planItem/udf
0-M
UDF type.
plan/planItem/udf/type String
Optional
plan/planItem/udf/flavour String
Optional
Flavour of the UDF. The valid values are one of the
following three:
characteristic in the product model or a system
UDF generated by AOPD.
• output - For UDF set by the process component.
plan/planItem/udf/name String
Required
Field name.
plan/planItem/udf/value String
Optional
Field value.
plan/planItem/udf/originalValue String
Optional
plan/planItem/udf/lastModified DateTime
Optional
plan/planItem/parentID String
0-M
plan/planItem/childID
String
0-M
IDs of the plan items on which the current plan item
depends.
plan/planItem/siblingID String
0-M
IDs of the plan items corresponding to
SIBLING_PRODUCT_* of the product fulfilled by
current plan item.
plan/planItem/dependentID String
0-M
DEPENDENT_PRODUCT_* of the product fulfilled
by current plan item.
plan/status
String
Required
Status of the plan from a data perspective: active or
complete.
plan/planDescription
String
Optional
Plan description.
Type
IDs of the plan items which depend on the current
plan item.
Get Plan Items
Overview
The GetPlanItems interface can be used by the process components to retrieve the data of one or many plan
items in the plan corresponding to an order from the FOM system. It is a synchronous request/reply interface
on a JMS queue that returns a reply either to the specified JMSReplyTo destination on the request message
or to the default reply queue if not specified.
If an exception occurs during GetPlanItems operation, then it is logged into the omsServer log. The details
of the exception are returned in the response.
Get Plan Items Request
Queue or Topic
Queue
Destination
tibco.aff.tds.plan.read.request
Element
Type
Cardinality
Description
_nm_
String
Required
GetPlanItemsRequestEvent.
String
Optional
Unique identifier for tracing purposes
across function calls.
planID
String
Required
Internal unique identifier for the plan to
retrieve.
correlationID
String
Optional
requestReply
Boolean
Required
across a single function call. This is
generally used by the calling application to
If set to true:
The response will be sent on the temporary
queue by default or on the destination set
as JMSReplyTo property in the request
message.
If set to false:
idsOnly
Boolean
Required
queue.
If true will only return the IDs of elements
rather than all plan data. Otherwise if false
will return all plan data.
originator
String
Optional
The component which has originated this
call. E.g. the name of the process component
PC_BUNDLE_PROVIDE.
The request message body should contain the XML payload as per the following schema:
Figure 43: Get Plan Items Request
Element
Type
Cardinality
Description
Optional
planID
String
Required
idsOnly
String
Optional
If true will only return the IDs of elements rather than all
plan data. Otherwise if false will return all plan data.
udfFlavour
String
Optional
Currently not implemented.
udfMatch
String
Optional
Currently not implemented.
planItem
Type
0-M
Plan item type.
planItem/planItemID String
Required
Internal unique identifier for the plan item to retrieve.
planItem/planItemName String
Optional
Not Applicable.
planItem/udf
Type
0-M
Not Applicable.
parentID
String
0-M
Not Applicable.
childID
String
0-M
Not Applicable.
siblingID
String
0-M
Not Applicable.
dependentID
String
0-M
Not Applicable.
Get Plan Items Response
Queue or Topic
Queue
Destination
Element
Type
Cardinality
Description
Optional
across function calls. This is used for
logging.
correlationID
String
Optional
across a single function call. This is
generally used by the calling
application to correlate requests and
responses.
Success
Boolean
Required
Flag indicating if the call was
successful.
messageCode
String
Required
Message
String
Required
Result message.
planID
String
Required
Internal unique identifier for the plan
specified in the request.
Found
Boolean
Required
Flag indicating if the plan was found.
Figure 44: Get Plan Items Response
Element
Type
Cardinality
Description
String
See Image
function calls.
resultStatus
Type
See Image
Result status type. Refer to Appendix A for
planItem
Type
0-M
Plan item type.
planItem/planItemID
String
Required
Internal unique identifier for the plan item.
Optional
Name of the process component.
planItem/udf
Type
0-M
UDF type.
planItem/udf/type
String
Optional
planItem/udf/flavour
String
Optional
Flavour of the UDF. The valid values are one
of the following three:
characteristic in the product model or a
system UDF generated by AOPD.
• output - For UDF set by the process
component.
planItem/udf/name
String
Required
Field name.
planItem/udf/value
String
Optional
Field value.
planItem/udf/originalValue String
Optional
planItem/udf/lastModified DateTime
Optional
planItem/parentID
String
0-M
IDs of the plan items which depends on the
current plan item.
planItem/childID
String
0-M
IDs of the plan items on which the current
plan item depends.
planItem/siblingID
String
0-M
SIBLING_PRODUCT_* of the product
fulfilled by current plan item.
planItem/dependentID String
0-M
DEPENDENT_PRODUCT_* of the product
fulfilled by current plan item.
Set Plan
Overview
The SetPlan interface can be used by the process components to add a new UDF or update the value of an
existing UDF of plan or any of the containing plan items in the Fulfillment Order Management system.
However, it is suggested to use this interface for plan level UDFs only since there is a separate interface for
plan items as explained further in this guide.
It is a synchronous request/reply interface on a JMS queue that returns a reply either to the specified
JMSReplyTo destination on the request message or to the default reply queue if not specified.
If an exception occurs during SetPlan operation, then it is logged into the omsServer
the exception are returned in the response.
log.
The details of
Set Plan Request
Queue or
Topic
Queue
Destination
tibco.aff.tds.plan.request
Element
Type
Cardinality
Description
_nm_
String
Required
Interface identifier name; MUST be set as SetPlanRequestEvent.
Optional
planID
String
Required
correlationID
String
Optional
requestReply
Boolean
Required
If set to true:
The response will be sent on the temporary queue by default
or on the destination set as JMSReplyTo property in the
request message.
If set to false:
The response will be sent on tibco.aff.tds.plan.reply
queue.
replace
Boolean
Required
If true will completely replace the plan item, otherwise it will
merge the UDF data.
originator
String
Optional
The component which has originated this call. E.g. the name
of the process component PC_BUNDLE_PROVIDE.
Figure 45: Set Plan Request
Element
Type
Cardinality
Description
String
Optional
function calls.
Plan
Type
Required
Plan type.
plan/planID
String
Required
Internal unique identifier for the plan to update.
plan/ordered
String
Required
Internal unique identifier for the order related
to the plan to update.
plan/orderRef
String
Required
External unique identifier for the order related
to the plan to update.
plan/udf
Type
0-M
plan/udf/type
String
Optional
plan/udf/flavour
String
Optional
Flavour of the UDF. Must be set as output.
plan /udf/name
String
Required
Field name.
plan/udf/value
String
Required
Field value.
plan/planItem
Type
0-M
Plan item type.
plan/planItem/planItemID String
Required
Internal unique identifier for the plan item to
update.
plan/planItem/planItemName String
Optional
Process component name.
plan/planItem/udf
Type
0-M
UDF type.
plan/planItem/udf/type String
Optional
plan/planItem/udf/flavour String
Optional
plan/planItem/udf/name String
Required
Field name.
plan/planItem/udf/value String
Required
Field value.
replace
Optional
If true it completely replaces the plan item,
otherwise merges the UDF data.
Any
Set Plan Response
Destination
Element
Type
Cardinality
Description
Optional
function calls. This is used for logging.
correlationID
String
Optional
single function call. This is generally used by
the calling application to correlate requests and
responses.
success
Boolean
Required
messageCode
String
Required
message
String
Required
Result message.
planID
String
Required
Internal unique identifier for the plan specified
in the request.
There is no body (payload) associated with the response message.
Set Plan Item
Overview
The SetPlanItem interface can be used by the process components to add a new UDF or update the value of
an existing UDF of the plan items in a plan in the Fulfillment Order Management System.
It is a synchronous request/reply interface on a JMS queue that returns a reply either to the specified
JMSReplyTo destination on the request message or to the default reply queue if not specified.
If an exception occurs during SetPlanItem operation then it is logged into the omsServer log. The details of
the exception are returned in the response.
Set Plan Item Request
Queue or Topic
Queue
Destination
tibco.aff.tds.plan.request
Element
Type
Cardinality
Description
_nm_
String
Required
SetPlanItemRequestEvent.
Optional
function calls.
planID
String
Required
correlationID
String
Optional
requestReply
Boolean
Required
single function call. This is generally used by the
calling application to correlate requests and
responses.
If set to true:
The response will be sent on the temporary queue
by default or on the destination set as JMSReplyTo
property in the request message.
If set to false:
replace
Boolean
Required
queue.
If true will completely replace the plan item,
otherwise it will merge the UDF data.
planItemID
String
Required
Internal unique identifier for the plan item to
update.
originator
String
Optional
The component which has originated this call. E.g.
the name of the process component
PC_BUNDLE_PROVIDE.
Figure 46: Set Plan Item Request
Element
Type
Cardinality
Description
String
Optional
function calls.
planID
String
Required
Internal unique identifier for the plan to update.
planItem
Type
Required
Plan item type. Only UDF Name and Value are
updated. If the UniqueUDFs are enabled for the
engine an update will occur, if disabled the entire
current UDF payload will be dropped and replaced
with the new payload.
planItem/planItemID
String
Required
Internal unique identifier for the plan item to update.
Optional
Process component name.
planItem/udf
Type
0-M
UDF type.
planItem/udf/type
String
Optional
planItem/udf/flavour
String
Optional
planItem/udf/name
String
Required
Field name.
planItem/udf/value
String
Required
Field value.
replace
Any
Optional
If true it completely replaces the plan item, otherwise
merges the UDF data.
Set Plan Item Response
Queue or
Topic
Queue
Destination
Element
Type
Cardinality
Description
Optional
correlationID
String
Optional
success
Boolean
Required
messageCode
String
Required
message
String
Required
Result message.
planID
String
Required
Internal unique identifier for the plan specified in the request.
There is no body (payload) associated with the response message.
Chapter
10
Offline Catalog
The Offline Catalog feature enables TIBCO Fulfillment Order Management to have no dependency on TIBCO
Fulfillment Catalog to be online all the time for the data models.
All the required catalogs viz PRODUCT, CUSTOMER, SEGMENT, ACTION, and PLANFRAGMENT can be
published out of TIBCO Fulfillment Catalog in the form of flat XML files. TIBCO Fulfillment Order Management
can then be configured to read the catalogs from these XML files instead of publishing them on JMS topics from
TIBCO Fulfillment Catalog as per the online mode.
Topics
•
•
Accessing Offline Catalog
Flat File Format
122 | Offline Catalog
Accessing Offline Catalog
Offline catalog mode can be enabled for each catalog separately using Fulfillment Order Management
configurator.
For example, only Product catalog can be configured to use offline mode and the remaining catalogs to use
the online mode.
The following figure shows the offline catalog configuration for the PRODUCT catalog. However, the
configurations for other catalogs can be done in the similar way.
Figure 47: Offline Product Catalog Configuration
The offline catalog can be used in one of the following three ways:
1. Reading from the master directories to process the catalog publish requests sent by AOPD, OCV and
Orchestrator engines on their startup. The master directory set for PRODUCT catalog is shown bordered
in green color in the above screen cap. The model data contained in the xml files under the master directory
will be read and published on the JMS topics for the respective engines.
Once read, the files in the master directory will NOT be moved. Just a copy of the original file will be
created under master success or master failure directory based on whether the 'read & publish' operation
is successful or failed.
2. By using the polling mechanism to poll the non-master directories. The non-master directory set for
PRODUCT catalog is shown bordered in red color in the above screen cap. The directory is polled according
to the polling interval as shown in the following configuration figure:
Figure 48: Offline Polling Configuration
3. By sending the SOAP web service request to read one or more catalogs from non-master directories on
demand. The web service request will also be processed by reading the XML files under the non-master
directory set.
Offline catalog invocation web service WDSL is
$AF_HOME/schemas/wsdl/http/OfflineCatalogue.wsdl.
The following sample request can be sent on the URL
http://<HOST>:<PORT>/omsServer/api/offlineCatalogueWS:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:off="http://www.tibco.com/AFF/OfflineCatalogue">
<soapenv:Header/>
<soapenv:Body>
<off:OfflineCatalogRequest>
<off:ActionOffline>?</off:ActionOffline>
<off:ProductOffline>?</off:ProductOffline>
Offline Catalog | 123
<off:CustomerOffline>?</off:CustomerOffline>
<off:SegmentOffline>?</off:SegmentOffline>
<off:PlanFragmentOffline>?</off:PlanFragmentOffline>
</off:OfflineCatalogRequest>
</soapenv:Body>
</soapenv:Envelope>
Once read, the files in the non-master directory are removed. A copy of the original file will be created
under non-master success or non-master failure directory based on whether the 'read and publish' operation
is successful or not.
If a new file is added in a non-master directory for loading the models on demand, the same file must
be synched up in the corresponding master directory. This is to ensure that the updated models are
published to the BusinessEvents engines on their next restart.
124 | Offline Catalog
Flat File Format
The offline catalog XML files have the following format:
<? Xml version="1.0" encoding="UTF-8"?>
<jms1:ActivityOutput
xmlns:jms1="http://www.tibco.com/namespaces/tnt/plugins/jms">
<OtherProperties>
<CURRENTBATCH>1</CURRENTBATCH> -- Current batch number.
<TOTALBATCH>12</TOTALBATCH> -- Total catalog model present in repository.
</OtherProperties>
<Body>
Actual Catalog Model Data in XML format as per Fulfillment Order Management schema.
</Body>
</jms1:ActivityOutput>
Chapter
11
Logging
Logging is used to record information about a program's execution. This information is typically used for debugging
purposes, and additionally, depending on the type and detail of information contained in a trace log, to diagnose
common problems with software.
Topics
•
•
•
How Logging Works
Configuring Logging
Controlling Log Levels
126 | Logging
How Logging Works
There are the following types of logging for every component:
• Local Logging: This refers to writing log output to a local log file for every component.
• Central Logging: This refers to publishing log messages from individual components to a central location
where logs are collated and logged to a central log file.
The individual components publish log messages to a central queue and then the central log server picks up
the log messages from this queue.
The advantage of having a central logging framework is that different individual components can log the
data in an agreeable, common format and in a common location, which makes it easy to correlate the log
records. This also helps you analyze the records more easily and effectively.
The logging can be effective in the following ways:
• Standardizes the contents of a log message for logging data across all the components.
• Provides with an ability to collect the log messages in a central location in addition to being available
on an individual engine.
• Empowers the correlation of different log messages coming across from various components.
• Enables filtering of messages for effective analysis of the logs.
Figure 49: Central Logging
Contents of the Log Message
The log message is comprised of several log components that are required to explain the log message in its
entirety. These log message components help you analyze the log.
Log Message
Component
Description
Log level
One of the levels - DEBUG, INFO, WARN, ERROR, OFF.
BusinessTransactionId Useful for correlating messages from various components.
OrderRef
An Identifier to identify the Order for which this log message is written.
Component
Context information about the origin of the log (typically the engine name).
Logging | 127
Log Message
Component
Description
Service
Context information about the origin of the log (Typically the class name).
Operation
Context information about the origin of the log (Typically the method name).
StackTrace
Entire stacktrace of the activity.
TimeStamp
Indicates when the message was logged.
128 | Logging
Configuring Logging
Different configuration options are supported for different components.
This topic describes the configuration options for the following Fulfillment Order Management components:
• BE Components
• Java Components
Configuring Logging for BE Components
Logging configuration for BE components applies to the Orchestrator, OCV and AOPD engines.
Use the following global variables to configure logging for the BE components:
commonServices/configuration/GLB_LogLevel - This variable sets the logging level at which logs are written
to the local log file. Valid values are any numeric value. The default value is 5 (indicating INFO).
The table lists the numeric value against its meaning:
NUMERIC
VALUE
MEANING
-1
OFF
0
ERROR
1
WARN
5
INFO
9
DEBUG
commonServices/configuration/GLB_LogPublishLevel - This variable sets the logging level at which logs
are written to the cental log server. Valid values are the same as mentioned in the table. The default value is
0 (ERROR).
commonServices/messaging/jms/destinations/GLB_Log - The name of the topic on which the log messages
are sent which are then picked up by the central log server.
Configuring Logging for Java Components
Logging configuration for Java components applies to the OMS Server and OMS UI.
OMS logging is done using log4j and you can use the same file to configure logs.
OMS Server : $AF_CONFIG_HOME/OMSServerLog4j.xml file is used to configure logging for OMS Server.
• The default logLevel is:
– INFO for com.tibco.aff package and its subpackage
– ERROR for all other packages
• Default publishLogLevel (for central logging )
– WARN (Look for "JMSAppender" and the following entry within it <param
value="WARN"/>)
name="Threshold"
OMS UI: $AF_CONFIG_HOME/OMSUILog4j.xml file is used to configure logging for OMS UI.
• The default logLevel is:
– INFO for com.tibco.aff package and its subpackage
Logging | 129
– ERROR for all other packages
• OMS UI does not send messages to the central log server.
130 | Logging
Controlling Log Levels
You can control logging using the configuration options before the engines are brought up. However, it may
be required that the log levels be changed dynamically at runtime without bringing down the engines.
This ability to control or change logging levels at runtime is provided for various components, viz:
• Controlling Logging for BE Components on page 130
• Controlling Logging for Java Components on page 130
Controlling Logging for BE Components
Fulfillment Order Management provides a utility to control the log levels at
$AF_HOME\bin\HotDeployVariable.sh.
This utility expects properties file HotDeployVariable.properties. A sample file is provided at
$AF_HOME\bin\HotDeployVariable.properties.
Sample Properties File
initialContextFactory=com.tibco.tibjms.naming.TibjmsInitialContextFactory
providerURL=tcp://localhost:7222
destinationName=tibco.aff.hot.deploy.variable.request.topic
component=AFO
engineID=AFF_V4_Orchestrator_CacheAndAgent
variableName=logLevel
value=7
To turn off logging, set the value as -1.
Controlling Logging for Java Components
Logging can be controlled using the configuration options mentioned in the Configuring Logging for Java
Components on page 128 before the engines are brought up.
However, it may be required that the log levels be changed dynamically at runtime without bringing down
the engines.
This ability to change logging levels at runtime is provided for various components. For OMS, it is as follows
(JMS-based configuration is provided to change log levels at runtime):
1. Go to Tools -> Change OMS Log Level.
Logging | 131
Figure 50: Change OMS
2. To change the log level of all com.tibco.aff loggers to ERROR, provide the following:
OMS Log Level
Values
Package
com.tibco.aff
Level
ERROR
JMX Host
localhost
JMX Port
100999
Username
admin
Password
adminpassword
To turn off logging, provide the Level as OFF for that package.
Chapter
12
FAQs and Troubleshooting
This topic lists some common errors along with their causes and solutions.
Why are the web services returning activity timed out error code?
The Product Model, Customer Model, and Segment Model are not loaded into AOPD and OCV applications. To
resolve this issue, load the models into the application.
Where can I find the log files generated by TIBCO Fulfillment Order Management?
The location of the log files is $TIBCO_HOME/tra/domain/<af_domain>/application/logs.
Why is the subscriber ID not found?
If the Segment, Customer, and Product models are not loaded, the web service does not return the Subscriber ID
even if the subscribers are loaded.
In the Fulfillment Order Management Rule Configuration, using Internet Explorer browser, what should I do
if the selected value is not inserted where cursor is pointing?
If you try to enter a value by selecting the tree attribute for template builder, enter the value at the position where
the cursor is pointing. Due to the restriction in the Internet Explorer browser, put a symbol in the editor, for example,
'?', select the symbol so that it is highlighted and then select the attribute value from attribute tree and remove the
symbol.
Appendix
A
Schema References
Topics
•
•
•
•
•
•
•
Plan Item
Result Status
Message
Order Request
Order Request Header
Order Request Line
Process Component Model
136 | Schema References
Plan Item
Figure 51: Plan Item
Element
Type
planItem/planItemID
String
Required
Unique identifier for the plan item within the plan
to be executed.
planItem/description
String
Optional
Description for the plan item to be executed.
planItem/processComponentID String
Required
executed.
planItem/processComponentName String
Required
Process component name for the Process Component
to be executed.
planItem/processComponentVersion String
Optional
Process component version for the Process
Component to be executed.
planItem/processComponentType String
Optional
Process component type for the Process Component
to be executed.
Schema References | 137
planItem/processComponentRecordType String
Optional
Class of processComponentType.
planItem/orderLine
1-M
Order line type for the plan item to be executed.
planItem/orderLine/orderLineNumber String
Required
Order line number for the order line of the plan item
to be executed.
planItem/orderLine/productID String
Required
Product ID for the order line of the plan item to be
executed.
planItem/orderLine/productVersion String
Optional
Product version for the order line of the plan item
to be executed.
planItem/orderLine/action
String
Required
Order line action for the order line of the plan item
to be executed.
planItem/orderLine/actionMode String
Optional
Order line action mode for the order line of the plan
item to be executed.
planItem/orderLine/quantity
Long
Required
Quantity for the order line of the plan item to be
executed.
planItem/orderLine/uom
String
Required
Unit of measure for the order line of the plan item
to be executed.
planItem/orderLine/subscriberID String
Optional
Subscriber ID for the order line of the plan item to
be executed.
planItem/orderLine/linkID
String
Optional
Link ID for the order line of the plan item to be
executed.
planItem/orderLine/inventoryID String
Optional
Inventory ID for the order line of the plan item to
be executed.
Type
planItem/orderLine/eol
Boolean Required
End of line flag for the order line of the plan item to
be executed. This indicates that this plan item is the
final plan item for the order line.
planItem/action
String
Required
Plan item action for the plan item to be executed.
planItem/actionMode
String
Optional
Plan item action mode for the plan item to be
executed.
Result Status
Figure 52: Result Status
Element
Type
Cardinality
Description
deployment
String
Required
Engine deployment that returned this result.
service
String
Required
Service name that returned this result
operation
String
Required
Operation within the service that returned this result.
component
String
Optional
Component within the operation and service that returned this
result.
severity
String
Required
Severity result. Valid values are:
1. S - Success
2. W - Warning
3. E - Error
code
String
Required
Message code for this result.
message
String
Required
Message details for this result.
Message
Figure 53: Message
Element
Type
lineNumber String,
Optional
Order line number that this message refers to.
type
String
Required
Message type. Valid values are:
1. Information
2. Warning
3. Error
Code
String
Required
Message code for this message.
Description String
Required
Message text for this message.
udf
Type
0-M
UDF type.
udf/name
String
Required
User defined field name.
udf/value
String
Required
User defined field value.
Order Request
Figure 54: Order Request
Element
Type
orderRef
String
Required
External unique identifier for an order.
header
Type
Required
Order request header type. Refer to the Order Request Header
definition for details.
line
Type
1-M
Order request line type. Refer to the Order Request Line definition for
details.
extension
Type
Optional
Extension attributes for user-defined fields.
extension/#any Any
Required
Any data
Order Request Header
Figure 55: Order Request Header
Figure 56: Invoice Address
Figure 57: Delivery Address
Element
Type
description
String
Optional
Description for the order.
customerID
String
Required
Unique identifier for the customer for this order.
subscriberID
String
Required
Unique identifier for the subscriber for this
order.
requiredByDate
DateTime
Optional,
Choice
Date and time when this order is required to
start.
requiredOnDate
DateTime
Optional,
Choice
Date and time by which this order is required
to complete.
invoiceAddress
Type
Required
Invoice address type.
invoiceAddress/line1
String
Required
Invoice address line 1.
String
Optional
String
Optional
invoiceAddress/locality
String
Required
Invoice address locality.
invoiceAddress/region
String
Optional
Invoice address region.
invoiceAddress/country
String
Required
Invoice address country.
invoiceAddress/postcode
String
Required
Invoice address post code.
invoiceAddress/supplementaryLocation String
Optional
Invoice address supplementary location.
deliveryAddress
Type
Required
Delivery address type.
deliveryAddress/line1
String
Required
Delivery address line 1.
String
Optional
String
Optional
deliveryAddress/locality
String
Required
Delivery address locality.
deliveryAddress/region
String
Optional
Delivery address region.
deliveryAddress/country
String
Required
Delivery address country.
deliveryAddress/postcode
String
Required
Delivery address post code.
deliveryAddress/supplementaryLocation String
Optional
Delivery address supplementary location.
notes
String
Optional
Order notes.
slaID
String
0-M
Unique identifier for an SLA that is applied to
this order.
udf
Type
0-M
UDF type.
udf/name
String
Required
udf/value
String
Required
udf/extension
Type
Optional
udf/extension/#any
Any
Required
Any data
extension
Type
Optional
extension/#any
Any
Required
Any data
Order Request Line
Figure 58: Order Request Line
Figure 59: Order Line Characteristics
Element
Type
Cardinality
Description
lineNumber
String
Required
Unique identifier for this
order line within this order.
subscriberID
String
Optional
subscriber for this order line.
productID
String
Required
Product identifier for this
order line.
productVersion
String
Optional
Product version for the
product for this order line.
quantity
Integer
Required
Quantity of the product being
ordered.
uom
String
Required
Unit of measure of the
product being ordered.
deliveryAddress
Type
Required
Delivery address type.
String
Required
String
Optional
String
Optional
deliveryAddress/locality
String
Required
Delivery address locality.
deliveryAddress/region
String
Optional
Delivery address region.
deliveryAddress/country
String
Required
Delivery address country.
deliveryAddress/postcode
String
Required
Delivery address post code.
deliveryAddress/supplementaryLocation String
Optional
Delivery address
supplementary location.
action
String
Required
Action for this order line.
Valid values are:
1. Provide
2. Update
3. Cease
4. Cancel
actionMode
String
Optional
Supplementary action mode
for the action.
requiredByDate
DateTime
Optional, Choice
Date and time by which this
order line is required to start.
requiredOnDate
DateTime
Optional, Choice
Date and time by which this
order line is required to
complete.
linkID
String
Optional
Unique identifier used to link
across order lines on this
order.
inventoryID
String
Optional
Unique identifier that
identifies this order line
product with an entry in an
external inventory
management system.
notes
String
Optional
Order line notes.
slaID
String
0-M
Unique identifier for an SLA
that is applied to this order
line.
udf
Type
0-M
UDF type.
udf/name
String
Required
udf/value
String
Required
udf/extension
Type
Optional
Extension attributes for
user-defined fields.
udf/extension/#any
Any
Required
Any data
characteristic
Type
Required
Characteristic type.
characteristic/name
String
Required
Characteristic name.
characteristic/description
String
Required
Characteristic description.
characteristic/value
Type
0-M
Characteristic value type.
characteristic/value/name
String
Required
Characteristic value name.
characteristic/value/type
String
Required
Characteristic value type.
characteristic/value/value
String
Optional
Characteristic value value.
characteristic/value/valueFrom
String
Optional
Characteristic value value
from.
characteristic/value/valueTo
String
Optional
Characteristic value value to.
characteristic/value/extension
Type
Optional
characteristic/value/extension/#any
Any
Required
Any data
characteristic/extension
Type
Optional
characteristic/extension/#any
Any
Required
Any data
customerItemID
String
Optional
Customer item unique
identifier.
extension
Type
Optional
extension/#any
Any
Required
Any data
Process Component Model
Figure 60: Process Component Model
Element
Type
Cardinality
Description
processComponentID
String
Required
executed.
Optional
Process component name for the Process Component
to be executed.
Optional
Process component version for the Process
Component to be executed.
processComponentType
String
Optional
Process component type for the Process Component
to be executed.
Optional
Class of processComponentType.
errorHandler
String
Optional
Error handler to use in the event of the Process
Component returning an incomplete or unsuccessful
execution response message.
retry
Type
Optional
Retry type.
retry/retryFailed
Boolean Required
Flag indicating that Orchestrator should retry failed
plan items.
retry/retryCount
Integer
Required
Number of times Orchestrator should retry the failed
plan item before referring it to Plan Item Failed
Handler for manual intervention.
retry/retryDelay
Long
Required
Delay in msec between calls to the Process Component
in the event that the plan item is retried.
section
Type
1-M
Process component model section type.
section/startMilestoneID
String
Required
Unique identifier for the start milestone that describes
this section.
section/endMilestoneID
String
Required
Unique identifier for the end milestone that describes
this section.
section/typicalDuration
Long
Required
Typical duration for this section in msec.
section/maximumDuration Long
Required
Maximum duration for this section in msec.
Appendix
B
Global Variables and Configurations
The following section lists the global variables in AOPD, OCV and Orchestrator components, and the OMS
configurations.
ActiveFulfillmentRulesEngine (AOPD, OCV)
The global variables in AOPD and OCV components are listed as follows:
Name
Description
Value
Type
Move
Move IPC line item action mode.
MOVE
String
New
New IPC line item action mode.
NEW
String
AffinityUDFNameMerge
Controls the flag to merge affinity UDF name.
false
String
CharacterisitcsWithoutAffinityPostfix To not merge certain UDFs during Affinity
Sequencing, those UDFs should be added as
comma separated values in the global variable
CharacteristicsWithoutAffinityPostfix in the rules
engine (AOPD).
String
ExtnalProductIDsUsed
If Customer wants to use External ProductIDs
then enable this global variable. By default it is
be 'false'.
false
String
LoadInventory
This flag loads the inventory into memory from false
the AOPD plan request.
String
skipItemSequence
Within AOPD, if the sequence is "-1", it will skip -1
the product and all its mandatory children in the
Execution Plan.
Integer
GLB_IgnoreUDFPersistFlag
Flag indicating whether Persist flag shoud be
ignored when UDF is stored in Inventory.
false
Boolean
true
Boolean
GLB_PublishInventoryNotifications Flag indicating if inventory services should
publish event notifications.
GLB_SortItemsOnGet
Flag indicating whether or not inventory needs false
to be sorted.
String
GLB_StoreInpCharUDFsOnly
Flag indicating that only UDFs that are Input
Characteristics are stored in Inventory.
true
Boolean
GLB_FilterTechnicalProducts
Flag indicating if eligible product calls should
filter out technical products.
true
Boolean
GLB_OfferPersistenceMode
Persistence mode for offers. Valid values are BE DB
or DB.
String
152 | Global Variables and Configurations
CheckInstallbase
Instructs rules to check for products in installbase true
in addition to order lines.
Boolean
EligibilityValidationByCustomer
Eligibility is always validated for
ParentCustomerID, not subscriber.
false
Boolean
GLB_UseExternalValidationEngine Flag indicating if an external validation engine
is to be used.
false
Boolean
ImplicitValidation
Selects Implicit or Explicit validation mode for
Validation rules.
true
Boolean
PoolBuyersPrefixes
Buyer prefix used to bypass some validations
POOL_
String
TestCeaseOrderLineRequired
Enables rule testing that order line item with
CEASE action contains InventoryID.
true
Boolean
TestCheckUpdatesValid
Enables rule checking that UPDATEs contain
InventoryID and ActionMode.
true
Boolean
TestConcurrentOrderViolation
Enables rule testing Concurrent Order violation true
Boolean
TestGroupAndProductCounts
Enables rule checking both group and product
counts.
true
Boolean
TestGroupRequirementsSatisfied
Enables rule testing ProductComprisedOf and
ProductsRequiredFor groups.
true
Boolean
TestMoveOrderLineRequired
Enables rule testing that order line with action
mode MOVE contains InventoryID.
true
Boolean
TestOrderLineUDFsDatatype
Enables rule testing datatype and length of Order true
line UDFs.
Boolean
TestOrderLineUDFsRange
Enables rule testing RangeValue of Order line
UDFs.
true
Boolean
TestOrderLineUDFsRegex
Enables rule testing that UDF value conforms to true
regex provided in MDM.
Boolean
TestOrderLineUDFsValid
Enables rule testing validity of Order line UDFs true
Boolean
TestPCORelationshipsSatisfied
Enables rule testing PCO relationships.
true
Boolean
TestProductCompatible
Enables rule testing that Product is compatible
with order or installbase.
true
Boolean
TestProductCountSatisfied
Enables rule testing RecMin and RecMax for
individual products.
true
Boolean
TestProductExistsInIB
Enables rule testing that Product exists in
installbase.
true
Boolean
TestProductIncompatible
Enables rule testing that Product is incompatible true
with order or installbase.
Boolean
TestProductIsEligible
Enables rule testing that Product is Eligible.
true
Boolean
TestProductRecordTypeValid
Enables rule testing that RECORD_TYPE is valid. true
Boolean
Values
Satisfied
Values
Global Variables and Configurations | 153
TestUpdateOrderLineRequiredValues Enables rule testing that order line item with
UPDATE action contains required values.
true
Boolean
ValidateOrderCaptureUDFsOnly
When loading ProductInputCharacteristics helper false
concept, only use those with Order Capture set.
Boolean
WaitForCustomerModel
Flag controls the destinations for accepting order true
until the customer model is received in OCV.
String
onBEStartUp
Flag controls whether the BE engine start up
events should be fired.
true
String
GLB_DBOrderRefPrefix
Prefix to append to database-generated order ref. REF
String
GLB_OrderRefGenerator
Flag indicating what type of order ref generator DB
to use. Valid values are DB or UID.
String
GLB_PublishOrderNotifications
Flag indicating if order services should publish
event notifications.
true
Boolean
GLB_UpdateOfferOnSubmit
Flag indicating if orders should be updated in
the offer cache on submit.
true
Boolean
GLB_UseExternalAmendmentAOPD Flag indicating if an external amendment AOPD false
engine is available.
Boolean
GLB_ValidateOnSubmit
Flag indicating if orders should be validated as
part of the SubmitOrder process.
true
Boolean
GLB_BEEventReplyTimeout
Timeout in msec for BE event wait for reply
activities.
60000
Integer
GLB_IPCOrderPlanRequest
Timeout in msec for IPC order plan JMS requests. 10000
Integer
GLB_CreateParentStringAtProduct
false
Boolean
MergeAffinityItemDescription =
true
planItem
false
name /
planItem
description
merges with
the comma
separated
value (as per
the case in
AF 1.2).
Boolean
MergeAffinityItemDescription =
false
planItem
name /
planItem
description
shows static
description
"This is an
affinity plan
item".
ModelLoad
MergeAffinityItemDescription
GLB_IntegrityValidationRequired
false
Boolean
HierarchySingleUse
Works for SingleUse and InventorySingleUse
false
cases. Enables child products to be removed from
the plan if a parent product is removed.
Boolean
EnableAffinityUDFParent
Identifies the common characteristics/UDF in a false
plan item.
Boolean
MIG_Password
Password for the JMS server for PC services.
Password
MIG_QueueConnectionFactory
Queue connection factory for the JMS server for QueueConnection String
PC services.
Factory
MIG_TopicConnectionFactory
Topic connection factory for the JMS server for
PC services.
TopicConnection String
URL for the JMS server for PC services.
tibjmsnaming:// String
MIG_Url
Factory
localhost:7222
MIG_Username
Username for the JMS server for PC services.
MIG_Password
Password for the JMS server for OM services.
Queue connection factory for the JMS server for QueueConnection String
OM services.
Factory
Topic connection factory for the JMS server for
OM services.
TopicConnection String
URL for the JMS server for OM services.
MIG_Url
admin
String
Password
Factory
localhost:7222
MIG_Username
Username for the JMS server for OM services.
admin
String
MIG_Password
Password for the JMS server for OM events.
Queue connection factory name for the JMS server QueueConnection String
for OM events.
Factory
Topic connection factory name for the JMS server TopicConnection String
for OM events.
Factory
MIG_Url
URL for the JMS server for OM events.
Password
localhost:7222
MIG_Username
Username for the JMS server for OM events.
MIG_Password
Password for the JMS server for OCV services.
for OCV services.
Factory
for OCV services.
Factory
admin
String
Password
MIG_Url
URL for the JMS server for OCV services.
localhost:7222
MIG_Username
Username for the JMS server for OCV services.
admin
String
MIG_Password
Password for the JMS server for OCV events.
for OCV events.
Factory
for OCV events.
Factory
MIG_Url
URL for the JMS server for OCV events.
Password
localhost:7222
URL for the JMS server for OCV
events
Username for the JMS server for OCV events.
MIG_Host
MIG_Port
admin
String
localhost
String
HTTP port for northbound SOAP over HTTP web 25400
services.
MIG_Host
localhost
String
String
MIG_Port
HTTP port for northbound SOAP over HTTP web 25401
services.
String
GLB_LoginTimeout
Login timeout in sec for the BE backing store
database.
10
Integer
GLB_MaxConnections
Maximum number of database connections for
the BE backing store database.
10
Integer
oracle.jdbc.
String
MIG_Driver
OracleDriver
MIG_Host
Hostname for the BE backing store database.
localhost
String
MIG_JDBCURL
Provide JDBC URL for the BE backing store
database.
<jdbcurl>
String
MIG_Password
Password for the BE backing store database.
be_user
String
MIG_Port
Database port for the BE backing store database. 1521
String
MIG_SID
Database SID or service name for the BE backing AFF
store database.
String
MIG_Username
Username for the BE backing store database.
be_user
String
GLB_MessagingPrefix
Messaging prefix for all JMS message queues and tibco.aff
topics.
String
GLB_CatalogRequestQueue
catalog.events. String
request
GLB_OrderDevelopmentAmend
ocv.events.
ResponseQueue
amendorder.
String
reply
GLB_BEEventReplyTimeout
Timeout in msec for BE event wait for reply
activities.
60000
Integer
GLB_IPCOrderPlanRequest
Timeout in msec for IPC order plan JMS requests. 10000
Integer
HotDeployVariableRequestTopic
tibco.aff.hot.
String
deploy.variable.
request.topic
LogHandler
Name of the log handler implementation to call BWLogHandler String
for log steps.
LogTopic
tibco.aff.
String
centrallog.topic
User
User log role.
logLevel
logLevel
Logging level for BE log statements.
EnableTiming
App_User
String
INFO
String
1
Integer
true
Boolean
GLB_LoginTimeout
Login timeout in sec for the BE backing store
database.
10
Integer
GLB_MaxConnections
Maximum number of database connections for
the BE backing store database.
10
Integer
Orchestrator
The global variables in Orchestrator component are listed below. Few of these are also seen in the AOPD and OCV
deployments due to the importing of the Orchestrator project library. However, they are not being used there.
Name
Description
Value
Type
GLB_LogLevel
Logging level for printing
logs.
5
Integer
GLB_LogPublishLevel
Logging level for
publishing logs.
0
Integer
GLB_EnableErrorPublish
Flag to enable publication
of errors.
true
Boolean
GLB_EnableInstrumentationPublish
Flag to enable publication false
of instrumentation events.
Boolean
GLB_EnableLogPublish
Flag to enable publication
of logs.
Boolean
GLB_OPDRetryInterval
Interval in msec to wait
60000
before retrying failed OPD
step.
true
Integer
GLB_PlanItemSLAThresholdConstant
SLA threshold for
1. 8
percentage of maximum
duration to publish an SLA
notification.
String
GLB_ProcessComponentRetries
Default retry count for
3
failed process components.
Integer
GLB_ProcessComponentRetryInterval
Default retry delay in msec 5000
for failed process
components.
Integer
GLB_SchedulerPollingInterval
Polling interval in msec for 60000
scheduler.
Integer
GLB_OriginatorStringForTDS
Constant string to be passed AFOrchestrator
as the value of originator
field in
SetPlanRequestEvent to
TDS.
String
AFF-ORCH-NOTIFY-0112
Notification message for
order amendment status
change.
String
NoReciprocalAction
Name of the process
NO_RECIPROCAL_ACTION String
component to indicate no
reciprocal action is required
on cancellation.
NonExecuting
Name of the process
EP_BUNDLE_PROVIDE
component to indicate that
no action need to be sent to
process components.
String
GLB_CleanupObjectsAtEndOfOrder
Flag to enable cleanup of
objects at the end of an
order lifecycle.
false
Boolean
GLB_EnableExternalOrderIDSource
Flag to enable orderID
generation external to
Orchestrator.
true
Boolean
GLB_EnableFeasibilityErrorHandling
Flag to enable
PreQualification Failed
Handler for feasibility
failures.
false
Boolean
GLB_EnableOMSIntegration
Flag to enable OMS
integration.
true
Boolean
GLB_EnableOPDErrorHandling
Flag to enable
PreQualification Failed
Handler for OPD failures.
false
Boolean
GLB_EnableOrderAmendmentStatus
Flag to enable order
amendment status
notifications.
true
Boolean
Flag to enable order
amendments.
true
Boolean
Notifications
GLB_EnableOrderAmendments
Order Amendment status
changed
GLB_EnableOrderLineStatusNotifications Flag to enable order line
status notifications.
true
Boolean
GLB_EnableOrderRejectNotifications
Flag to enable order reject
notifications.
true
Boolean
GLB_EnableOrderStatusNotifications
Flag to enable order status true
notifications.
Boolean
GLB_EnablePlanDevelopmentNotifications Flag to enable plan
true
development notifications.
Boolean
GLB_EnablePlanItemFailedNotifications Flag to enable plan item
failed notifications.
true
Boolean
Flag to enable SLA
false
notifications for plan items.
Boolean
GLB_EnablePlanItemSLANotification
GLB_EnablePlanItemStatusNotifications Flag to enable plan item
status notifications.
true
Boolean
GLB_EnablePlanStatusNotifications
Flag to enable plan status
notifications.
true
Boolean
GLB_EnableSubmitOrderResponses
Flag to enable sending
response to submit order
events.
true
Boolean
GLB_FeasibilityRequired
Flag to enable feasibility
step.
false
Boolean
GLB_RetryFailedFeasibility
Flag to enable retry of failed false
Feasibility step.
Boolean
GLB_RetryFailedOPD
Flag to enable retry of failed false
OPD step.
Boolean
GLB_RetryFailedProcessComponents
Flag to enable retry of failed true
process components.
Boolean
GLB_StoreFailedPlanItemMessages
Flag to enable storing failed true
plan item messages.
Boolean
GLB_StoreFailedProcessComponentsMessages Flag to enable storing failed true
process components
messages.
Boolean
GLB_StorePreQualificationFailedMessages Flag to enable storing failed true
process Pre-Qualification
messages.
Boolean
GLB_IncludeOrderOnOrderAmendment Flag to include the order on false
order amendment
Notification
notifications.
Boolean
GLB_IncludeOrderOnOrderLineNotification Flag to include the order on true
order line notifications.
Boolean
GLB_IncludeOrderOnOrderNotification Flag to include the order on true
order notifications.
Boolean
GLB_IncludePlanOnOrderAmendment Flag to include the plan on false
order amendment
Notification
notifications.
Boolean
GLB_IncludePlanOnOrderLineNotification Flag to include the plan on false
order line notifications.
Boolean
GLB_IncludePlanOnOrderNotification Flag to include the plan on false
order notifications.
Boolean
MIG_Driver
JDBC driver for backing
store
oracle.jdbc.OracleDriver
String
MIG_JDBCURL
Database URL for backing
store.
jdbc:oracle:thin:@localhost:1521: String
MIG_LoginTimeoutSec
Login timeout in msec for
backing store.
10
Integer
MIG_MaxConnection
Maximum number of
connections for backing
store.
50
Integer
MIG_Password
Password for the backing
store user.
MIG_Username
Username for the backing
store user.
MIG_Password
Password for the JMS server
for Orchestrator events.
Queue connection factory
for the JMS server for
Orchestrator events.
Topic connection factory for TopicConnectionFactory
the JMS server for
MIG_Url
URL for the JMS server for tibjmsnaming://localhost:7222 String
MIG_Username
Username for the JMS
server for Orchestrator
events.
admin
GLB_DataDeleteOrderRequest
Delete order request
destination.
orchestrator.data.order.delete. String
Delete order response
destination.
orchestrator.data.order.delete. String
Delete plan request
destination.
orchestrator.data.plan.delete.
Delete plan response
destination.
orchestrator.data.plan.delete.reply String
GLB_DataDeleteOrderResponse
GLB_DataDeletePlanRequest
GLB_DataDeletePlanResponse
ORCL
Password
affv4_orch
String
Password
QueueConnectionFactory
String
String
String
request
reply
String
request
GLB_DataGetOrderRequest
Get order request
destination.
orchestrator.data.order.get.request String
GLB_DataGetOrderResponse
Get order response
destination.
orchestrator.data.order.get.reply String
GLB_DataGetOrderSummaryRequest
Get order summary request orchestrator.data.orderSummary. String
destination.
get.request
GLB_DataGetOrderSummaryResponse Get order summary
response destination.
orchestrator.data.orderSummary. String
GLB_DataGetPlanItemsRequest
Get plan items request
destination.
orchestrator.data.planItem.get.request String
GLB_DataGetPlanItemsResponse
Get plan items response
destination.
orchestrator.data.planItem.get.reply String
GLB_DataGetPlanRequest
Get plan request
destination.
orchestrator.data.plan.get.request String
GLB_DataGetPlanResponse
Get plan response
destination.
orchestrator.data.plan.get.reply String
GLB_ExternalFeasibilityRequest
External feasibility handler orchestrator.provider.order.
request destination.
feasibility.request
String
GLB_ExternalFeasibilityResponse
External feasibility handler orchestrator.provider.order.
response destination.
feasibility.reply
String
GLB_ExternalOPDRequest
External plan development orchestrator.provider.order.opd. String
handler request destination.
request
GLB_ExternalOPDResponse
External plan development orchestrator.provider.order.opd. String
handler response
reply
destination.
GLB_ExternalPlanItemFailedRequest
External plan item failed
orchestrator.provider.planItem. String
handler request destination.
failed.request
get.reply
GLB_ExternalPlanItemFailedResponse External plan item failed
handler response
destination.
orchestrator.provider.planItem. String
GLB_ExternalPreQualificationFailedRequest External pre-qualification
failed handler request
destination.
orchestrator.provider.order.
GLB_ExternalPreQualificationFailedResponse External pre-qualification
failed handler response
destination.
orchestrator.provider.order.
GLB_InternalDependencyTimeDelta
orchestrator.internal.dependency. String
Dependency time delta
trigger destination.
failed.reply
String
prequal.failed.request
String
prequal.failed.reply
timeDelta
GLB_InternalFeasibilityRequest
GLB_InternalOPDRequest
GLB_InternalPlanItemRetryTimeDelta
Feasibility request trigger
destination.
orchestrator.internal.order.
OPD request trigger
destination.
orchestrator.internal.order.
Dependency time delta
trigger destination.
orchestrator.internal.
String
feasibility.request
String
opd.request
String
planItemRetry.timeDelta
GLB_InternalPlanItemSLANotifyTrigger Plan item SLA trigger
destination.
orchestrator.internal.planItem. String
GLB_ModelProcessComponentModel
Plan fragment model
publish destination.
orchestrator.model.
GLB_NotificationOrder
Order change notification
orchestrator.notification.order String
GLB_NotificationOrderAmendment
Order amendment change orchestrator.notification.
notification publish
orderAmendment
destination.
GLB_NotificationOrderLine
Order line change
destination.
orchestrator.notification.orderLine String
GLB_NotificationOrderReject
Order reject notification.
orchestrator.notification.order.reject String
GLB_NotificationPlan
Plan change notification
orchestrator.notification.plan
String
GLB_NotificationPlanDevelopment
Plan development
destination.
orchestrator.notification.plan.
String
GLB_NotificationPlanItem
Plan item change
destination.
orchestrator.notification.planItem String
GLB_NotificationPlanItemSLA
Plan item SLA notification orchestrator.notification.planItem.sla String
GLB_OrchestratorStartupEvent
Orchestrator startup event orchestrator.startup.event.request String
request for process
component models.
GLB_OrchestratorStartupService
Orchestrator startup service orchestrator.startup.service.request String
request for process
component models.
GLB_OrderActivate
Order activate request
orchestrator.order.activate
String
GLB_OrderCancel
Order cancel request
orchestrator.order.cancel
String
GLB_OrderSubmit
Order submit request
orchestrator.order.submit
String
slaNotifyTrigger
String
processComponent.pub
String
development
GLB_OrderSuspend
Order suspend request
orchestrator.order.suspend
String
GLB_OrderWithdraw
Order withdraw request
publish.
orchestrator.order.withdraw
String
GLB_PlanItemActivateRequest
Plan item activate request
destination.
orchestrator.planItem.activate.request String
GLB_PlanItemExecuteRequest
Plan item execute request
destination.
orchestrator.planItem.execute.request String
GLB_PlanItemExecuteResponse
Plan item execute response orchestrator.planItem.execute.reply String
destination.
GLB_PlanItemExternalDependency
Plan item external
dependency release
destination.
ReleaseRequest
orchestrator.planItem.
String
externalDependency.release.request
GLB_PlanItemMilestoneNotifyRequest Plan item milestone notify orchestrator.planItem.milestone. String
destination (Process
notify.request
Component to
Orchestrator).
GLB_PlanItemMilestoneReleaseRequest Plan item milestone release orchestrator.planItem.milestone. String
destination (Orchestrator to
release.request
Process Component).
GLB_PlanItemSuspendRequest
Plan item suspend request orchestrator.planItem.suspend.request String
destination.
GLB_PlanItemSuspendResponse
Plan item suspend response orchestrator.planItem.suspend.reply String
destination.
GLB_PlanOMSSet
Destination queue to send orchestrator.plan.oms.set
the complete plan to OMS.
GLB_PlanSetPlanItemStatusRequest
Plan item set status request orchestrator.plan.planItem.status. String
destination.
request
GLB_PlanSetPlanItemStatusResponse
Plan item set status reply
destination.
GLB_MessagingPrefix
String to be prefixed to JMS tibco.aff
destinations.
String
GLB_CleanUpObjectsDelay
Delay time between order
completion and order
deletion.
Integer
String
orchestrator.plan.planItem.status.reply String
300000
GLB_DefaultProcessComponentErrorHandler Default error handler name DefaultErrorHandler
for failed plan items.
String
GLB_FeasibilityRetries
Retry count for failed
Feasibility step.
5
Integer
GLB_FeasibilityRetryInterval
Interval in msec to wait
before retrying failed
Feasibility step.
60000
Integer
GLB_OPDRetries
Retry count for failed OPD 5
step.
Integer
GLB_BEProfilerOutputFilePath
Directory path in which BE
profiler csv file will be
written. By default it will
write into BE application
deployment directory.
String
GLB_BEProfilerLevel
Level for BE profiling
output. By default, -1 for
profiling everything.
-1
Integer
GLB_BEProfilerDurationInSeconds
Duration for which the BE -1
profiler will run. By default,
-1 to run till the BE engine
is shutdown.
Integer
GLB_EnableBEProfiling
Flag to enable BE profiling. False
Boolean
GLB_PlanOMSSetResponse
Destination to receive Set
Plan response from OMS.
orchestrator.plan.oms.set.reply String
GLB_InternalCleanUpOrderRequest
CleanUpOrderRequest
destination.
orchestrator.internal.order.delete. String
CleanUpPlanRequest
destination.
orchestrator.internal.plan.delete. String
GLB_InternalCleanUpPlanRequest
request
request
GLB_DefaultExceptionCode
Default exception code from AFF-ORCH-9999
Orchestrator.
String
GLB_Exception
JMS destination on which
exception event is
published.
becs.exception.publish
String
GLB_Instrumentation
exception event is
published.
becs.instrumentation.publish
String
GLB_Log
log event is published.
becs.log.publish
String
Order Management System
The following table lists down the consolidated configuration properties in the Order Management System.
Name
Description
Default Value
com.tibco.aff.oms.jmx.rmiport
JMX RMI Port.
10099
com.tibco.af.oms.statusnotification.order Order Status Notification Queue.
.queue
tibco.aff.oms.statusNotification.ord
er.queue
com.tibco.af.oms.statusnotification.order Order Status Notification Queue
.queue.concurrentConsumersCount
Concurrent Listener Count.
2
com.tibco.af.oms.statusnotification.order Order Line Status Notification Queue. tibco.aff.oms.statusNotification.ord
Line.queue
erLine.queue
Name
Description
Default Value
com.tibco.af.oms.statusnotification.order Order Line Status Notification Queue 1
Line.queue.concurrentConsumersCount Concurrent Listener Count.
com.tibco.af.oms.statusnotification.plan. Plan Status Notification Queue.
queue
tibco.aff.oms.statusNotification.pla
n.queue
com.tibco.af.oms.statusnotification.plan. Plan Status Notification Queue
queue.concurrentConsumersCount
1
com.tibco.af.oms.statusnotification.planI Plan Item Status Notification Queue. tibco.aff.oms.statusNotification.pla
tem.queue
nItem.queue
com.tibco.af.oms.statusnotification.planI Plan Item Status Notification Queue
tem.queue.concurrentConsumersCount Concurrent Listener Count.
6
com.tibco.af.oms.statusnotification.order Order Amendment Status Notification tibco.aff.oms.statusNotification.ord
Amendment.queue
Queue.
erAmendment.queue
com.tibco.af.oms.statusnotification.order Order Amendment Status Notification 1
Amendment.queue.concurrentConsumersCount Queue Concurrent Listener Count.
com.tibco.af.oms.statusnotification.dead. Status Notification Dead Queue.
queue
tibco.aff.oms.statusNotification.dea
d.queue
com.tibco.af.oms.centrallog.queue
tibco.aff.centrallog.queue
Central Log Queue.
com.tibco.af.oms.centrallog.queue.concurr Central Log Queue Concurrent
entConsumersCount
Listener Count.
1
com.tibco.af.oms.setplan.queue
tibco.aff.orchestrator.plan.oms.set
Set Plan Queue.
com.tibco.af.oms.setplan.queue.concurrent Set Plan Queue Concurrent Listener
ConsumersCount
Count.
3
com.tibco.af.oms.setplan.dead.queue Set Plan Dead Queue.
tibco.aff.orchestrator.plan.oms.set.
dead
com.tibco.af.oms.setplan.reply.queue Set Plan Response Queue.
tibco.aff.orchestrator.plan.oms.set.
reply
com.tibco.af.oms.setplanfragmentmodel.que Set Plan Fragment Model Queue.
ue
tibco.aff.oms.planfragmentmodel
com.tibco.af.oms.setplanfragmentmodel.que Set Plan Fragment Model Queue
ue.concurrentConsumersCount
1
com.tibco.af.oms.setplanfragmentmodel.dea Set Plan Fragment Model Dead Queue. tibco.aff.oms.planfragmentmodel.dead
d.queue
com.tibco.af.oms.setplanitem.queue
Set Plan Item Queue.
com.tibco.af.oms.setplanitem.queue.concur Set Plan Item Queue Concurrent
rentConsumersCount
Listener Count.
tibco.aff.oms.setplanitem
1
com.tibco.af.oms.orderService.syncOrderSt Synchronous Order Submission Status 1
atusRecovery.concurrentConsumersCount Recovery Consumer Count.
com.tibco.af.oms.orderService.syncOrderSt Synchronous Order Submission Status tibco.aff.oms.syncorderstatusrecover
atusRecovery.queue
Recovery Queue.
y
com.tibco.af.oms.setplanitem.dead.queue Set Plan Item Dead Queue.
tibco.aff.oms.setplanitem.dead
Name
Description
Default Value
com.tibco.af.oms.ordersService.queue Queue for receiving SOAP Over JMS tibco.aff.oms.ordersService
Order Service requests.
com.tibco.af.oms.webservice.soap.jms.conc Minimum number of concurrent
urrentConsumers
consumers for listener (default 1).
1
com.tibco.af.oms.webservice.soap.jms.maxC Maximum number of concurrent
oncurrentConsumers
consumers for listener (default 1).
5
com.tibco.af.oms.milestone.notify.request Milestone Notify Request Queue.
.queue
tibco.aff.oms.planItem.milestone.not
ify.request
com.tibco.af.oms.milestone.notify.request Milestone Notify Request Queue
.queue.concurrentConsumersCount
3
com.tibco.af.oms.milestone.notify.request Milestone Notify Request Dead Queue. tibco.aff.orchestrator.oms.planItem.
.dead.queue
milestone.notify.request.dead
com.tibco.af.oms.milestone.release.reques Milestone Release Request Queue.
t.queue
tibco.aff.oms.planItem.milestone.rel
ease.request
com.tibco.af.oms.milestone.release.reques Milestone Release Request Queue
t.queue.concurrentConsumersCount Concurrent Listener Count.
3
com.tibco.af.oms.milestone.release.reques Milestone Release Request Dead
t.dead.queue
Queue.
tibco.aff.orchestrator.oms.planItem.
milestone.release.request.dead
com.tibco.af.oms.events.jeopardy.update.q Jeopardy Events Update Queue.
ueue
tibco.aff.oms.events.jeopardy.update
com.tibco.af.oms.events.jeopardy.update.q Jeopardy Events Update Queue
ueue.concurrentConsumersCount
1
com.tibco.af.oms.events.jeopardy.update.d Jeopardy Events Update Dead Queue. com.tibco.aff.dead
ead.queue
com.tibco.af.dead.queue
AFF Dead Queue.
com.tibco.aff.dead
com.tibco.af.oms.router.destination.beoPu Purge Order Reply Queue for
rgeOrder.reply.queue.concurrentConsumersCount Orchestrator Concurrent Listener
Count.
1
com.tibco.af.oms.plan.migrated.request Enrich Migrated Plan Request Queue. tibco.aff.oms.plan.migrated.request
com.tibco.af.oms.plan.migrated.response Enrich Migrated Plan Response Queue. tibco.aff.oms.plan.migrated.response
com.tibco.af.oms.migratedPlanTimeOut Enrich Migrated Plan Timeout.
com.tibco.af.oms.jeoms.update.rule
30000
Update Jeopardy Configuration Rule tibco.aff.oms.jeoms.update.rule
Queue.
com.tibco.af.oms.statusmessage.max.redeli Maximum number of times the Status 3
veries
Message to be retried.
com.tibco.af.oms.statusmessage.redelivery Interval delay in millisecs between
.delay
Status Message retries.
3000
com.tibco.af.oms.statusmessage.max.redeli Maximum delay in millisecs For Status 30000
very.delay
Message retries.
com.tibco.af.oms.statusmessage.useExponen Use Exponential backoff For Status
tialBackOff
Message retries.
FALSE
Name
Description
com.tibco.af.oms.statusmessage.exponentia Exponential backoff Multiplier For
lBackOffMultiplier
Status Message retries.
Default Value
2
com.tibco.af.oms.statusmessage.logRetryAt Log retry attempt For Status Message FALSE
tempted
retries.
com.tibco.af.oms.statusmessage.logStackTr Log retry failed stacktrace For Status FALSE
ace
Message retries.
com.tibco.af.oms.router.type
Router Type.
com.tibco.af.oms.router.destination.beoWi Withdraw Order Queue for
thdrawOrder
Orchestrator.
passthroughRouter
tibco.aff.orchestrator.order.withdra
w
com.tibco.af.oms.router.destination.beoSu Submit Order Queue for Orchestrator. tibco.aff.orchestrator.order.submitR
bmitOrderReply
esponse
com.tibco.af.oms.syncSubmitOrderRequestTi Request time out for synchronous
meout
order submission.
30000
com.tibco.af.oms.router.destination.beoSu Submit Order Queue for Orchestrator. tibco.aff.orchestrator.order.submit
bmitOrder
com.tibco.af.oms.router.destination.beoAm Amend Order Queue for Orchestrator. tibco.aff.orchestrator.order.submit
endOrder
com.tibco.af.oms.router.destination.beoCa Cancel Order Queue for Orchestrator. tibco.aff.orchestrator.order.submit
ncelOrder
com.tibco.af.oms.router.destination.beoRe Resume Order Queue for Orchestrator. tibco.aff.orchestrator.order.activat
sumeOrder
e
com.tibco.af.oms.router.destination.beoSu Suspend Order Queue for
spendOrder
Orchestrator.
tibco.aff.orchestrator.order.suspend
com.tibco.af.oms.router.destination.beoPu Purge Order Request Queue for
rgeOrder
Orchestrator.
tibco.aff.orchestrator.data.order.de
lete.request
com.tibco.af.oms.router.destination.beoPu Purge Order Reply Queue for
rgeOrder.reply
Orchestrator.
tibco.aff.orchestrator.data.order.de
lete.reply
com.tibco.af.oms.router.recoveryFileFolde Path to folder containing Router
rPath
Recovery Files.
../../routerRecoveryFileFolder
com.tibco.af.oms.router.type
filteringRouter
Router Type.
com.tibco.af.oms.router.destination.beoSu Submit Order Queue for Orchestrator. tibco.aff.orchestrator.order.submitR
bmitOrderReply
esponse
com.tibco.af.oms.syncSubmitOrderRequestTi Request time out for synchronous
meout
order submission.
30000
com.tibco.af.oms.router.filterCondition Xpath filter Condition.
/SubmitOrderRequest/orderRequest/hea
der/udf[name='Orchestrator']/value/text()
com.tibco.af.oms.router.destination.beoSu Submit Order Queue for Orchestrator. tibco.aff.orchestrator.order.submit
bmitOrder
com.tibco.af.oms.router.destination.ipcSu Submit Order Queue for IPC.
bmitOrder
tibco.aff.ipc.order.submit
Name
Description
Default Value
com.tibco.af.oms.router.destination.beoWi Withdraw Order Queue for
thdrawOrder
Orchestrator.
tibco.aff.orchestrator.order.withdra
w
com.tibco.af.oms.router.destination.ipcWi Withdraw Order Queue for iPC.
thdrawOrder
tibco.aff.ipc.order.withdraw
com.tibco.af.oms.router.destination.ipcSu Submit Order Queue for Orchestrator. tibco.aff.ipc.order.submitResponse
bmitOrderReply
com.tibco.af.oms.router.destination.beoAm Amend Order Queue for Orchestrator. tibco.aff.orchestrator.order.submit
endOrder
com.tibco.af.oms.router.destination.ipcAm Amend Order Queue for IPC.
endOrder
tibco.aff.ipc.order.amend
com.tibco.af.oms.router.destination.beoCa Cancel Order Queue for Orchestrator. tibco.aff.orchestrator.order.submit
ncelOrder
com.tibco.af.oms.router.destination.ipcCa Cancel Order Queue for iPC.
ncelOrder
tibco.aff.ipc.order.submit
com.tibco.af.oms.router.destination.beoRe Resume Order Queue for Orchestrator. tibco.aff.orchestrator.order.activat
sumeOrder
e
com.tibco.af.oms.router.destination.ipcRe Resume Order Queue for iPC.
sumeOrder
tibco.aff.ipc.order.activate
com.tibco.af.oms.router.destination.beoSu Suspend Order Queue for
spendOrder
Orchestrator.
tibco.aff.orchestrator.order.suspend
com.tibco.af.oms.router.destination.ipcSu Suspend Order Queue for iPC.
spendOrder
tibco.aff.ipc.order.suspend
com.tibco.af.oms.router.recoveryFileFolde Path to folder containing Router
rPath
Recovery Files.
../../routerRecoveryFileFolder
com.tibco.af.oms.hibernate.dialect
org.hibernate.dialect.Oracle10gDiale
ct
com.tibco.af.oms.hibernate.cache.use_seco Hibernate Second Level Cache Usage. FALSE
nd_level_cache
com.tibco.af.oms.hibernate.cache.provider Hibernate Cache Provider Class.
_class
org.hibernate.cache.NoCacheProvider
com.tibco.af.oms.hibernate.transaction.fa Hibernate Transaction Factory Class. org.hibernate.transaction.JDBCTransa
ctory_class
ctionFactory
com.tibco.af.oms.hibernate.current_sessio Hibernate Session Context Class.
n_context_class
thread
com.tibco.af.oms.hibernate.jdbc.batch_siz Hibernate JDBC Batch size.
e
30
com.tibco.af.oms.hibernate.show_sql
FALSE
Hibernate Show SQL.
com.tibco.af.oms.hibernate.default_catalo Hibernate Default Catalog.
g
aff_oms
com.tibco.af.oms.hibernate.default_archiv Hibernate Default Archive Catalog.
e_catalog
aff_oms_archive
Name
Description
Default Value
com.tibco.af.omsui.httpChannelType
com.tibco.af.omsui.http.port
8080
com.tibco.af.omsui.https.port
8443
com.tibco.af.omsui.enableRecordCountFetch Enable the Record count fetch for
pagination. This will make the data
fetch slower and enable Last Page
option in pagination.
TRUE
com.tibco.af.omsui.session-fixation-prote
ction
com.tibco.af.omsServer.proxyHost
Host address of the OMS server.
localhost
com.tibco.af.fpServer.enableConfiguration Enable FP configuration.
TRUE
com.tibco.af.fpServer.nodeName
Node name of the FP server.
knode
com.tibco.af.fpServer.proxyHost
Host address of the FP server.
localhost
com.tibco.af.fpServer.fpPlanFragmentType Owner for FP.
FP
com.tibco.af.omsServer.proxyPort
Port number of the OMS Server.
8080
com.tibco.af.fpServer.proxyPort
Port number of the FP Server.
8080
com.tibco.af.concurrencyControl.maxSessio
nPerUser
1
com.tibco.af.omsui.shortDateFormat
OMS UI Short Date Format (Day [dd]. Month[MM] and Year [yyyy])
com.tibco.af.omsui.longDateFormat
OMS UI Long Date Time Format (Day Month [MM]
[dd].
com.tibco.af.omsui.longDateFormatTimeZone OMS UI Long Date Time Format (Day Month [MM]
[dd].
com.tibco.af.omsui.longDateFormatTimeZone OMS UI Long Date Time Format (Day Month [MM]
Millis
[dd].
com.tibco.af.purge.threads.count
Purge Thread Count.
4
com.tibco.aff.PublishInventoryNotificatio PublishInventoryNotifications.
ns
FALSE
publish.assigninventoryitem
AssignInventoryItem publish topic.
tibco.aff.ocv.publish.inventory.assi
gnitem
publish.removeinventoryitem
RemoveInventoryItem publish topic. tibco.aff.ocv.publish.inventory.remo
veitem
publish.updateinventoryitem
UpdateInventoryItem publish topic.
publish.reassigninventoryitem
ReassignInventoryItem publish topic. tibco.aff.ocv.publish.inventory.reas
signitem
publish.rollbackinventoryitem
RollbackInventoryItem publish topic. tibco.aff.ocv.publish.inventory.roll
backitem
tibco.aff.ocv.publish.inventory.upda
teitem
Name
Description
Default Value
com.tibco.fom.oms.afi.productmodel.receiv Product model receiver queue.
er.queue
tibco.aff.catalog.product.request
com.tibco.fom.oms.afi.productmodel.receiv Product model receiver count.
er.count
3
com.tibco.fom.oms.afi.productmodel.publis Product model publish topic.
h.topic
tibco.aff.ocv.events.products.publis
h
com.tibco.fom.oms.afi.customermodel.recei Customer model receiver queue.
ver.queue
tibco.aff.catalog.customer.request
com.tibco.fom.oms.afi.customermodel.recei Customer model receiver count.
ver.count
3
com.tibco.fom.oms.afi.customermodel.publi Customer model publish topic.
sh.topic
tibco.aff.ocv.events.customers.publi
sh
com.tibco.fom.oms.afi.segmentmodel.receiv Segment model receiver queue.
er.queue
tibco.aff.catalog.segment.request
com.tibco.fom.oms.afi.segmentmodel.receiv Segment model receiver count.
er.count
3
com.tibco.fom.oms.afi.segmentmodel.sender Segment model sender queue.
.queue
tibco.aff.ocv.events.segment.set.req
uest
com.tibco.fom.oms.afi.planfragmentmodel.r PlanFragment model receiver queue. tibco.aff.catalog.planfragment.reque
eceiver.queue
st
com.tibco.fom.oms.afi.planfragmentmodel.r PlanFragment model receiver count.
eceiver.count
3
com.tibco.fom.oms.afi.planfragmentmodel.p ProcessComponent model publish
ublish.topic
topic.
tibco.aff.orchestrator.model.process
Component.pub
com.tibco.fom.oms.afi.actionmodel.receive Action model receiver queue.
r.queue
com.tibco.fom.oms.afi.actionmodel.receive Action model receiver count.
r.count
3
com.tibco.fom.oms.afi.actionmodel.publish Action model publish topic.
.topic
tibco.aff.ocv.events.actions.publish
com.tibco.fom.oms.afi.pcsmodel.event.requ Product customer segment model
est.queue
invocation event request receiver
queue.
tibco.aff.catalog.events.request
com.tibco.fom.oms.afi.pcsmodel.event.rece Product customer segment model
iver.count
invocation event request receiver
count.
1
com.tibco.fom.oms.afi.pfmodel.event.reque Plan fragment model invocation event tibco.aff.orchestrator.startup.event
st.queue
request receiver queue.
.request
com.tibco.fom.oms.afi.pfmodel.event.reque Plan fragment model invocation event 1
st.receiver.count
request receiver count.
com.tibco.fom.oms.afi.fcintegration.host Server host.
localhost
Name
Description
Default Value
com.tibco.fom.oms.afi.fcintegration.port Server port.
8800
com.tibco.fom.oms.afi.fcintegration.enter Enterprise name.
prise
AC
com.tibco.fom.oms.afi.fcintegration.usern Username.
ame
admin
com.tibco.fom.oms.afi.fcintegration.passw Password.
ord
admin
com.tibco.fom.oms.afi.fcintegration.workf Workflow invocation response success SVC-11045
low.response.success.code
code.
com.tibco.fom.oms.afi.fcintegration.workf Workflow invocation response success Workflow initiated successfully.
low.response.success.message
message.
com.tibco.fom.oms.afi.fcintegration.produ Master catalog name.
ct.mctname
PRODUCT
com.tibco.fom.oms.afi.fcintegration.produ Product record ID.
ct.id
BU_000001
com.tibco.fom.oms.afi.fcintegration.produ Product record ID extension.
ct.idext
com.tibco.fom.oms.afi.fcintegration.custo Master catalog name.
mer.mctname
PARTY
com.tibco.fom.oms.afi.fcintegration.custo Customer record ID.
mer.id
68000001
com.tibco.fom.oms.afi.fcintegration.custo Customer record ID extension.
mer.idext
com.tibco.fom.oms.afi.fcintegration.segme Master catalog name.
nt.mctname
SEGMENT
com.tibco.fom.oms.afi.fcintegration.segme Segment record ID.
nt.id
PB_000001
com.tibco.fom.oms.afi.fcintegration.segme Segment record ID extension.
nt.idext
com.tibco.fom.oms.afi.fcintegration.planf Master catalog name.
ragment.mctname
PLANFRAGMENT
com.tibco.fom.oms.afi.fcintegration.planf PlanFragment record ID.
ragment.id
PF_00001
com.tibco.fom.oms.afi.fcintegration.planf PlanFragment record ID extension.
ragment.idext
com.tibco.fom.oms.afi.fcintegration.actio Master catalog name.
n.mctname
ACTION
com.tibco.fom.oms.afi.fcintegration.actio Action record ID.
n.id
Provide
com.tibco.fom.oms.afi.fcintegration.actio Action record ID extension.
n.idext
Name
Description
Default Value
com.tibco.fom.oms.afi.offline.common.poll Polling interval in seconds.
ing.interval
60
com.tibco.fom.oms.afi.offline.common.cata Catalog request interval in
logrequest.interval
milliseconds.
30
com.tibco.fom.oms.afi.offline.product.use Use offline product.
FALSE
com.tibco.fom.oms.afi.offline.product.mas Offline product catalog master
ter.directory
directory.
/usr/tibco/product/master
com.tibco.fom.oms.afi.offline.product.mas Offline product catalog import success /usr/tibco/product-success/master
ter.importsuccess.directory
master directory.
com.tibco.fom.oms.afi.offline.product.mas Offline product catalog import failure /usr/tibco/product-failure/master
ter.importfailure.directory
master directory.
com.tibco.fom.oms.afi.offline.product.dir Offline product catalog directory.
ectory
/usr/tibco/product
com.tibco.fom.oms.afi.offline.product.imp Offline product catalog import success /usr/tibco/product-success
ortsuccess.directory
directory.
com.tibco.fom.oms.afi.offline.product.imp Offline product catalog import failure /usr/tibco/product-failure
ortfailure.directory
directory.
com.tibco.fom.oms.afi.offline.customer.us Use offline customer.
e
FALSE
com.tibco.fom.oms.afi.offline.customer.ma Offline customer catalog master
ster.directory
directory.
/usr/tibco/customer/master
com.tibco.fom.oms.afi.offline.customer.ma Offline customer catalog import
ster.importsuccess.directory
success master directory.
/usr/tibco/customer-success/master
com.tibco.fom.oms.afi.offline.customer.ma Offline customer catalog import failure /usr/tibco/customer-failure/master
ster.importfailure.directory
master directory.
com.tibco.fom.oms.afi.offline.customer.di Offline customer catalog directory.
rectory
/usr/tibco/customer
com.tibco.fom.oms.afi.offline.customer.im Offline customer catalog import
portsuccess.directory
success directory.
/usr/tibco/customer-success
com.tibco.fom.oms.afi.offline.customer.im Offline customer catalog import failure /usr/tibco/customer-failure
portfailure.directory
directory.
com.tibco.fom.oms.afi.offline.segment.use Use offline segment.
FALSE
com.tibco.fom.oms.afi.offline.segment.mas Offline segment catalog master
ter.directory
directory.
/usr/tibco/segment/master
com.tibco.fom.oms.afi.offline.segment.mas Offline segment catalog import success /usr/tibco/segment-success/master
ter.importsuccess.directory
master directory.
com.tibco.fom.oms.afi.offline.segment.mas Offline segment catalog import failure /usr/tibco/segment-failure/master
ter.importfailure.directory
master directory.
com.tibco.fom.oms.afi.offline.segment.dir Offline segment catalog directory
ectory
/usr/tibco/segment
Name
Description
Default Value
com.tibco.fom.oms.afi.offline.segment.imp Offline segment catalog import success /usr/tibco/segment-success
ortsuccess.directory
directory.
com.tibco.fom.oms.afi.offline.segment.imp Offline segment catalog import failure /usr/tibco/segment-failure
ortfailure.directory
directory.
com.tibco.fom.oms.afi.offline.planfragmen Use offline planfragment.
t.use
FALSE
com.tibco.fom.oms.afi.offline.planfragmen Offline planfragment catalog master
t.master.directory
directory.
/usr/tibco/planfragment/master
com.tibco.fom.oms.afi.offline.planfragmen Offline planfragment catalog import
t.master.importsuccess.directory
success master directory.
/usr/tibco/planfragment-success/mast
er
t.master.importfailure.directory
failure master directory.
/usr/tibco/planfragment-failure/mast
er
com.tibco.fom.oms.afi.offline.planfragmen Offline planfragment catalog directory. /usr/tibco/planfragment
t.directory
t.importsuccess.directory
success directory.
/usr/tibco/planfragment-success
t.importfailure.directory
failure directory.
/usr/tibco/planfragment-failure
com.tibco.fom.oms.afi.offline.action.use Use offline action.
FALSE
com.tibco.fom.oms.afi.offline.action.mast Offline action catalog master directory. /usr/tibco/action/master
er.directory
com.tibco.fom.oms.afi.offline.action.mast Offline action catalog import success /usr/tibco/action-success/master
er.importsuccess.directory
master directory.
com.tibco.fom.oms.afi.offline.action.mast Offline action catalog import failure
er.importfailure.directory
master directory.
/usr/tibco/action-failure/master
com.tibco.fom.oms.afi.offline.action.dire Offline action catalog directory.
ctory
/usr/tibco/action
com.tibco.fom.oms.afi.offline.action.impo Offline action catalog import success /usr/tibco/action-success
rtsuccess.directory
directory.
com.tibco.fom.oms.afi.offline.action.impo Offline action catalog import failure
rtfailure.directory
directory.
/usr/tibco/action-failure
com.tibco.fom.oms.afi.orch.opdrequest.rec OPDRequest from Orchestrator
eiver.queue
receiver queue.
tibco.aff.orchestrator.provider.orde
r.opd.request
com.tibco.fom.oms.afi.orch.opdrequest.rec OPDRequest from Orchestrator
eiver.count
receiver count.
3
com.tibco.fom.oms.afi.aopd.newplanrequest ExecutionPlanNewRequest to AOPD tibco.aff.ocv.events.plan.new.reques
.sender.queue
sender queue.
t
com.tibco.fom.oms.afi.aopd.amendplanreque ExecutionPlanAmendRequest to
st.sender.queue
AOPD sender queue.
tibco.aff.ocv.events.plan.amend.requ
est
com.tibco.fom.oms.afi.aopd.newplanrespons ExecutionPlanNewResponse from
e.receiver.queue
AOPD receiver queue.
tibco.aff.ocv.events.newplan.reply
Name
Description
Default Value
com.tibco.fom.oms.afi.aopd.newplanrespons ExecutionPlanNewResponse from
e.receiver.count
AOPD receiver count.
3
com.tibco.fom.oms.afi.aopd.amendplanrespo ExecutionPlanAmendResponse from tibco.aff.ocv.events.amendplan.reply
nse.receiver.queue
AOPD receiver queue.
com.tibco.fom.oms.afi.aopd.amendplanrespo ExecutionPlanAmendResponse from 3
nse.receiver.count
AOPD receiver count.
com.tibco.fom.oms.afi.orch.opdresponse.se OPDResponse to Orchestrator sender tibco.aff.orchestrator.provider.orde
nder.queue
queue.
r.opd.reply
com.tibco.fom.oms.afi.aopd.merge.inventor Merge inventory in AOPD request.
y
FALSE
com.tibco.fom.oms.tds.getorderrequest.rec GetOrderRequest receiver queue.
eiver.queue
tibco.aff.tds.order.read.request
com.tibco.fom.oms.tds.getorderrequest.rec GetOrderRequest receiver count.
eiver.count
3
com.tibco.fom.oms.tds.getorderrequest.rec GetOrderRequest receiver dead queue. tibco.aff.oms.tds.order.read.request
eiver.deadqueue
.dead
com.tibco.fom.oms.tds.getorderresponse.se GetOrderResponse sender queue.
nder.queue
tibco.aff.tds.order.reply
com.tibco.fom.oms.tds.getplanrequest.rece GetPlan/GetPlanItem Request receiver tibco.aff.tds.plan.read.request
iver.queue
queue.
com.tibco.fom.oms.tds.getplanrequest.rece GetPlan/GetPlanItem Request receiver 3
iver.count
count.
com.tibco.fom.oms.tds.getplanrequest.rece GetPlan/GetPlanItem Request receiver tibco.aff.oms.tds.plan.read.request.
iver.deadqueue
dead queue.
dead
com.tibco.fom.oms.tds.getplanresponse.sen GetPlan/GetPlanItem Response sender tibco.aff.tds.plan.reply
der.queue
queue.
com.tibco.fom.oms.tds.setplanrequest.rece SetPlan/SetPlanItem Request receiver tibco.aff.tds.plan.request
iver.queue
queue.
com.tibco.fom.oms.tds.setplanrequest.rece SetPlan/SetPlanItem Request receiver 3
iver.count
count.
com.tibco.fom.oms.tds.setplanrequest.rece SetPlan/SetPlanItem Request receiver tibco.aff.oms.tds.plan.request.dead
iver.deadqueue
dead queue.
com.tibco.fom.oms.tds.setplanresponse.sen SetPlan/SetPlanItem Response sender tibco.aff.tds.plan.reply
der.queue
queue.
com.tibco.fom.oms.tds.enable.unique.udfna Flag to enable unique UDF names to
me
permit updates on UDF values.
TRUE
com.tibco.afs.destination.listen.timeout Wait Timeout for listening to response 60000
from JMS Destination.
tibco.aff.ocv.events.inventory.assignitem AssignInventory request queue.
.request
tibco.aff.ocv.events.inventory.assig
nitem.request
Name
Description
Default Value
tibco.aff.ocv.events.inventory.assignitem Destination where assignInventory
.response
response is posted.
tibco.aff.ocv.events.inventory.assig
nitem.response
tibco.aff.ocv.events.inventory.getitem.re Queue where the getItem request is
quest
posted.
tibco.aff.ocv.events.inventory.getit
em.request
tibco.aff.ocv.events.inventory.getitem.re Queue where the getItem reponse is
sponse
posted.
em.response
tibco.aff.ocv.events.inventory.getitems.r Queue where the getItems request is
equest
posted.
ems.request
tibco.aff.ocv.events.inventory.getitems.r Queue where the getItems reponse is tibco.aff.ocv.events.inventory.getit
esponse
posted.
ems.response
tibco.aff.ocv.events.inventory.removeitem Queue where the removeItem request tibco.aff.ocv.events.inventory.remov
.request
is posted.
eitem.request
tibco.aff.ocv.events.inventory.removeitem Queue where the removeItem reponse tibco.aff.ocv.events.inventory.remov
.response
is posted.
eitem.response
tibco.aff.ocv.events.inventory.rollbackit Queue where the rollbackItem request tibco.aff.ocv.events.inventory.rollb
em.request
is posted.
ackitem.request
tibco.aff.ocv.events.inventory.rollbackit Queue where the rollbackItem
em.response
response is posted.
tibco.aff.ocv.events.inventory.rollb
ackitem.response
tibco.aff.ocv.events.inventory.reassignit Queue where the reassignitem request tibco.aff.ocv.events.inventory.reass
em.request
is posted.
ignitem.request
tibco.aff.ocv.events.inventory.reassignit Queue where the reassignitem
em.response
response is posted.
tibco.aff.ocv.events.inventory.reass
ignitem.response
tibco.aff.ocv.events.inventory.updateitem Queue where the updateitem request tibco.aff.ocv.events.inventory.updat
.request
is posted.
eitem.request
tibco.aff.ocv.events.inventory.updateitem Queue where the updateitem response tibco.aff.ocv.events.inventory.updat
.response
is posted.
eitem.response
tibco.aff.ocv.events.inventory.setusersta Queue where the setuserstatus request tibco.aff.ocv.events.inventory.setus
tus.request
is posted.
erstatus.request
tibco.aff.ocv.events.inventory.setusersta Queue where the setuserstatus
tus.response
response is posted.
tibco.aff.ocv.events.inventory.setus
erstatus.response
tibco.aff.ocv.events.inventory.getusersta Queue where the getuserstatus request tibco.aff.ocv.events.inventory.getus
tus.request
is posted.
erstatus.request
tibco.aff.ocv.events.inventory.getusersta Queue where the getuserstatus
tus.response
response is posted.
tibco.aff.ocv.events.inventory.getus
erstatus.response
tibco.aff.ocv.events.subscriber.set.reque Queue where CreateSubscriberRequest tibco.aff.ocv.events.subscriber.set.
st
is posted.
request
tibco.aff.ocv.events.subscriber.set.reply Topic where CreateSubsriberResponse tibco.aff.ocv.events.subscriber.set.
is posted.
reply
tibco.aff.ocv.events.subscriber.remove.re Queue where
tibco.aff.ocv.events.subscriber.remo
quest
RemoveSubscriberRequest is posted. ve.request
Name
Description
Default Value
tibco.aff.ocv.events.subscriber.remove.re Queue where the RemoveSubscriber
ply
reponse is posted.
tibco.aff.ocv.events.subscriber.remo
ve.reply
tibco.aff.ocv.events.subscriber.get.reque Queue where the getSubscriber request tibco.aff.ocv.events.subscriber.get.
st
is posted.
request
tibco.aff.ocv.events.subscriber.get.reply Queue where the getSubscriber
reponse is posted.
tibco.aff.ocv.events.subscriber.get.
reply
tibco.aff.ocv.events.customer.hierarchy.g Queue where request for
et.request
CustomerHierarchy is posted.
tibco.aff.ocv.events.customer.hierar
chy.get.request
tibco.aff.ocv.events.customer.hierarchy.g Topic where CustomerHierarchy
et.reply
response is posted.
tibco.aff.ocv.events.customer.hierar
chy.get.reply
tibco.aff.ocv.events.customer.get.request Queue where request for
CustomerImage is posted.
tibco.aff.ocv.events.customer.get.re
quest
tibco.aff.ocv.events.customer.get.reply Topic where the CustomerImage
reponse is posted.
tibco.aff.ocv.events.customer.get.re
ply
tibco.aff.ocv.events.customer.eligiblepro Queue where request for getting
tibco.aff.ocv.events.customer.eligib
ducts.get.request
customer's eligible products is posted. leproducts.get.request
tibco.aff.ocv.events.customer.eligiblepro Topic where customer's eligible
ducts.get.reply
product response is posted.
tibco.aff.ocv.events.customer.eligib
leproducts.get.reply
tibco.aff.ocv.events.subscriber.eligiblep Queue where request for getting
tibco.aff.ocv.events.subscriber.elig
roducts.get.request
subscriber's eligible products is posted. ibleproducts.get.request
tibco.aff.ocv.events.subscriber.eligiblep Topic where subscriber's eligible
roducts.get.reply
product response is posted.
tibco.aff.ocv.events.subscriber.elig
ibleproducts.get.reply
tibco.aff.ocv.events.product.get.request Queue where request for getting
product information is posted.
tibco.aff.ocv.events.product.get.req
uest
tibco.aff.ocv.events.product.get.reply
tibco.aff.ocv.events.product.get.rep
ly
Topic where product information
response is posted.
tibco.aff.ocv.events.subscriber.ineligibl Queue where request for getting
e.get.request
ineligible subscribers information is
posted.
tibco.aff.ocv.events.subscriber.inel
igible.get.request
tibco.aff.ocv.events.subscriber.ineligibl Topic where ineligible subscriber
e.get.reply
information response is posted.
tibco.aff.ocv.events.subscriber.inel
igible.get.reply
tibco.aff.ocv.events.segment.get.request Queue where request for getting
segment information is posted.
tibco.aff.ocv.events.segment.get.req
uest
tibco.aff.ocv.events.segment.get.reply Topic where segment information
response is posted.
tibco.aff.ocv.events.segment.get.rep
ly
tibco.aff.ocv.events.offer.validate.reque Queue where request for validating
st
the offer is posted.
tibco.aff.ocv.events.offer.validate.
request
tibco.aff.ocv.events.offer.validate.reply Topic where response of offer
validation is posted.
reply
tibco.aff.ocv.events.offer.price.request Queue where request for getting offer tibco.aff.ocv.events.offer.price.req
price is posted.
uest
Name
Description
Default Value
tibco.aff.ocv.events.offer.price.reply
Topic where offer price information is tibco.aff.ocv.events.offer.price.rep
posted.
ly
com.tibco.af.oms.jms.jndi.ConnectionFacto JNDI Connection factory JNDI Name. GenericConnectionFactory
ry
com.tibco.af.oms.jms.jndi.initialContextF JNDI Initial Context Factory.
actory
com.tibco.tibjms.naming.TibjmsInitia
lContextFactory
com.tibco.af.oms.jms.jndi.url
tibjmsnaming://localhost:7222
JNDI URL for JMS Service.
com.tibco.af.oms.jms.jndi.security.princi JNDI Username.
pal
admin
com.tibco.af.oms.jms.jndi.security.creden JNDI Password.
tials
admin
com.tibco.af.oms.jms.jndi.cf.beo
QueueConnectionFactory
BE Orchestrator Queue Connection
factory JNDI Name.
com.tibco.af.oms.jms.cf.beo.deliverymode BE Orchestrator JMS Delivery Mode. 1
com.tibco.af.oms.jms.cf.beo.qosEnabled BE Orchestrator JMS QoS Enabled?
FALSE
com.tibco.af.oms.jms.jndi.cf.ipc
GenericConnectionFactory
IPC Queue Connection factory JNDI
Name.
com.tibco.af.oms.jms.cf.ipc.deliverymode IPC JMS Delivery Mode.
1
com.tibco.af.oms.jms.cf.ipc.qosEnabled IPC IPC JMS JMS QoS Enabled.
FALSE
com.tibco.af.oms.jms.jndi.cf.ocv
OCV Queue Connection factory JNDI QueueConnectionFactory
Name.
com.tibco.af.oms.jms.cf.ocv.deliverymode OCV JMS Delivery Mode.
1
com.tibco.af.oms.jms.cf.ocv.qosEnabled OCV JMS JMS QoS Enabled.
TRUE
com.tibco.af.oms.pooledDataSource.driverC Pooled Data Source Driver Class
lassName
Name.
oracle.jdbc.driver.OracleDriver
com.tibco.af.oms.pooledDataSource.host Pooled Data Source Host.
localhost
com.tibco.af.oms.pooledDataSource.port Pooled Data Source Port.
1521
com.tibco.af.oms.pooledDataSource.databas Pooled Data Source Database.
e
orcl
com.tibco.af.oms.pooledDataSource.usernam Pooled Data Source Username.
e
aff_oms
com.tibco.af.oms.pooledDataSource.passwor Pooled Data Source Password.
d
aff_oms
com.tibco.af.oms.pooledDataSource.url Pooled Data Source URL.
jdbc:oracle:thin:@//${com.tibco.af.o
ms.pooledDataSource.host}:${com.
tibco.af.oms.pooledDataSource.
port}/${com.tibco.af.oms.
pooledDataSource.database}
Name
Description
Default Value
com.tibco.af.oms.pooledDataSource.initial Pooled Data Source Initialize Size.
izeSize
2
com.tibco.af.oms.pooledDataSource.maxIdle Pooled Data Source Max Idle.
8
com.tibco.af.oms.pooledDataSource.maxActi Pooled Data Source Max Active.
ve
12
com.tibco.af.oms.pooledDataSource.maxWait Pooled Data Source Max Wait.
10000
com.tibco.af.oms.pooledDataSource.validat Pooled Data Source Validation Query. select 1 from dual
ionQuery
com.tibco.af.oms.pooledDataSource.testOnB Pooled Data Source Test OnBorrow.
orrow
FALSE
com.tibco.af.oms.pooledDataSource.testWhi Pooled Data Source Test WhileIdle.
leIdle
TRUE
com.tibco.af.oms.pooledDataSource.timeBet Pooled Data Source Eviction Interval. 1200000
weenEvictionRunsMillis
com.tibco.af.oms.pooledDataSource.minEvic Pooled Data Source Minimum
tableIdleTimeMillis
Evictable Idle Time.
1800000
com.tibco.af.oms.pooledDataSource.numTest Pooled Data Source Tests Per Eviction 5
sPerEvictionRun
Run.
com.tibco.af.oms.pooledDataSource.default Pooled Data Source Default
AutoCommit
AutoCommit.
FALSE
com.tibco.af.oms.pooledArchiveDataSource. Pooled Data Source Driver Class
driverClassName
Name.
oracle.jdbc.driver.OracleDriver
com.tibco.af.oms.pooledArchiveDataSource. Pooled Data Source Host.
host
localhost
com.tibco.af.oms.pooledArchiveDataSource. Pooled Data Source Port.
port
1521
com.tibco.af.oms.pooledArchiveDataSource. Pooled Data Source Database.
database
orcl
com.tibco.af.oms.pooledArchiveDataSource. Pooled Data Source Username.
username
aff_oms_archive
com.tibco.af.oms.pooledArchiveDataSource. Pooled Data Source Password.
password
aff_oms_archive
com.tibco.af.oms.pooledArchiveDataSource. Pooled Data Source URL.
url
jdbc:oracle:thin:@//${com.tibco.af.o
ms.pooledArchiveDataSource.host}:
${com.tibco.af.oms.
pooledArchiveDataSource.port}/
${com.tibco.af.oms.
pooledArchiveDataSource.database}
com.tibco.af.oms.pooledArchiveDataSource. Pooled Data Source Initialize Size.
initializeSize
2
Name
Description
Default Value
com.tibco.af.oms.pooledArchiveDataSource. Pooled Data Source Max Idle.
maxIdle
8
com.tibco.af.oms.pooledArchiveDataSource. Pooled Data Source Max Active.
maxActive
12
com.tibco.af.oms.pooledArchiveDataSource. Pooled Data Source Max Wait.
maxWait
10000
com.tibco.af.oms.pooledArchiveDataSource. Pooled Data Source Validation Query. select 1 from dual
validationQuery
com.tibco.af.oms.pooledArchiveDataSource. Pooled Data Source Test OnBorrow.
testOnBorrow
FALSE
com.tibco.af.oms.pooledArchiveDataSource. Pooled Data Source Test WhileIdle.
testWhileIdle
TRUE
com.tibco.af.oms.pooledArchiveDataSource. Pooled Data Source Eviction Interval. 1200000
timeBetweenEvictionRunsMillis
com.tibco.af.oms.pooledArchiveDataSource. Pooled Data Source Minimum
minEvictableIdleTimeMillis
Evictable Idle Time.
1800000
com.tibco.af.oms.pooledArchiveDataSource. Pooled Data Source Tests Per Eviction 5
numTestsPerEvictionRun
Run.
com.tibco.af.oms.pooledArchiveDataSource. Pooled Data Source Default
defaultAutoCommit
AutoCommit.
FALSE
com.tibco.af.oms.security.authProvider Default Authentication Provider.
defaultAuthenticationProvider
com.tibco.af.oms.security.authProvider Ldap Authentication Provider.
ldapAuthenticationProvider
com.tibco.af.oms.security.authProvider.ld LDAP Server URL.
ap.server.url
ldap://localhost:389/dc=oms
com.tibco.af.oms.security.authProvider.ld LDAP User Manager ID.
ap.server.userDn
uid=admin
com.tibco.af.oms.security.authProvider.ld LDAP User Manager Password.
ap.server.password
password
com.tibco.af.oms.security.authProvider.ld User SearchBase.
ap.user.searchBase
ou=users
com.tibco.af.oms.security.authProvider.ld User Search Filter.
ap.user.userSearchFilter
(uid={0})
com.tibco.af.oms.security.authProvider.ld Group Search Base.
ap.role.groupSearchBase
ou=Groups
com.tibco.af.oms.security.authProvider.ld Group Role Attribute.
ap.role.groupRoleAttribute
cn
com.tibco.af.oms.security.authProvider.ld Group Search Filter.
ap.role.groupSearchFilter
uniqueMember={0}
com.tibco.af.oms.security.authProvider.ld Seach Sub Tree.
ap.role.searchSubTree
FALSE
Name
Description
Default Value
com.tibco.af.oms.security.authProvider.ld convert values To UpperCase.
ap.role.convertToUpperCase
TRUE
com.tibco.af.oms.OCVEnabled
Enable Offer Configuration and
Validation.
FALSE
com.tibco.af.oms.OCVTimeOut
Offer Configuration and Validation
Timeout.
60000
com.tibco.af.oms.ocv.request
Request Queue.
request
com.tibco.af.oms.ocv.response
Response Queue. Specify a different reply.oms
queue name for OMS than other OCV
clients.
com.tibco.af.oms.OCVExceptionLoggingEnabl Enable or disable logging of exception TRUE
ed
stack trace in OMS when Offer
Configuration and Validation fails.
com.tibco.af.oms.webservice.security.user Enable User Name token based
NameTokenBased
Security.
TRUE
com.tibco.af.oms.webservice.schema.valida Enable Schema validation.
tion
TRUE
com.tibco.af.oms.webservice.idempotency Enable Submit Order Web Service
Idempotency.
TRUE
com.tibco.af.oms.webservice.httpChannelTy HTTP Channel type.
pe
com.tibco.af.oms.http.port
8080
com.tibco.af.oms.https.port
8443
com.tibco.af.oms.webservice.useExternalBu Use external business transactionId as FALSE
sinessTransactionId
business transaction id within OMS.
com.tibco.af.oms.updateToken.timeout Time out value in millisecond for order 150000
lock.
com.tibco.af.oms.none.validityWindow Nonce validity time in Milliseconds.
1000
com.tibco.af.oms.persistenceDelay
Delay to be introduced before
persisting order objects.
0
com.tibco.af.oms.orderValidationDelay Delay to be introduced before
validating orders.
0
com.tibco.af.oms.summaryDataCollectionMet Order Summary collection on every
hod
order status change.
onStatusChange
com.tibco.af.oms.summaryDataCollectionMet Order Summary collection on
hod
scheduled interval.
scheduled
com.tibco.af.oms.summaryDataCollection.sc schedule interaval for order summary 0 0 * * * ?
heduled.cronExpress
data collection.
Appendix
C
Database Schema Changes
The database schema changes in the Fulfillment Order Management System 2.0.0 are as follows:
Component Name
Summary
Behavior in AF 1.2
Behavior in FOM 2.0
Column length change
PLANFRAGMENTID -- 32 PLANFRAGMENTID -- 255
chars
chars
STARTMILESTONEID - 32 STARTMILESTONEID char
255 chars
ENDMILESTONEID - 32
char
ENDMILESTONEID - 255
chars
MILESTONEID - 32 char
MILESTONEID - 255 chars
PLANFRAGMENTTYPE - PLANFRAGMENTTYPE 10 chars
255 chars
NA
Data Schema Changes
OMS
Planfragment
Order
PLANFRAGMENTRECORDTYPE
-- 40 CHAR
Unique contraint change - No unique contraint
Section Table
Unique Constraint
(PLANFRAGMENTID,
STARTMILESTONEID,
ENDMILESTONEID)
Column Datatype change
LINENUMBER NUMBER(10)
LINENUMBER VARCHAR2(255 CHAR)
NA
ORDERPRIORITY
-Number (3)
Column removed from
current tables
EXTENSION,
HEADEREXTENSION
NA
CREATE TABLE
NA
ORDER_UDF_DATA_MAPPER
ORDER_UDF_DATA_MAPPER
CREATE TABLE
NA
PLAN_UDF_DATA_MAPPER
PLAN_UDF_DATA_MAPPEr
CREATE TABLE
EXTENSION
TABLE EXTENSION
NA
182 | Database Schema Changes
Index on Order_Line
NA
ORDERID,
LINENUMBER,status
Index on Order
NA
ORDERREF, ORDERID
INDEX ON
ORDERS_HISTORY
NA
PLAN_ITEM_RELATION
-- ORDERID
INDEX ON
NA
ORDERS_AMENDMENT
ORDERID,
ORDERIDHISTORYSID
INDEX ON ORDERS
PLANID
NA
INDEX ON
NA
ORDERLINE_SLA_DATA
ORDERLINESID
INDEX ON
ORDER_UDF_DATA_HISTORY
ORDERIDHISTORYSID
INDEX ON
ORDER_UDF_DATA
ORDERID
INDEX ON
ORDER_SLA_DATA_HISTORY
ORDERIDHISTORYSID
INDEX ON
ORDER_SLA_DATA
ORDERID
INDEX ON
ORDER_LINE_UDF_DATA
ORDERLINESID
INDEX ON
ORDER_LINE_HISTORY
ORDERIDHISTORYSID
INDEX ON
ORDER_LINE_CHAR_VALUE
CHARACTERISTICSID
INDEX ON
ORDER_LINE_CHAR_HISTORY
ORDERLINEHISTORYSID
INDEX ON
ORDER_LINE_CHAR
ORDERLINESID
INDEX ON ORDER_LINE
ORDERID
INDEX ON
ORDER_LINE_UDF_DATA_HISTORY
ORDERLINEHISTORYSID
Plan
PLANITEMID - Number 19 PLANITEMID - 255 char
DESCRIPTION - 10 CHAR DESCRIPTION -255 char
CREATE TABLE
MILESTONE_STATUS
NA
MILESTONE_STATUS
CREATE TABLE
MILESTONE_DETAILS
NA
MILESTONE_DETAILS
CREATE TABLE
PLAN_SDF_DATA
NA
PLAN_SDF_DATA
Database Schema Changes | 183
Primary key Constraint for PRIMARY KEY (PLANID, PRIMARY KEY
PLAN_ITEM_DETAILS
PLANITEMID)
(PLANITEMSID)
Audit Trail
Index on PLAN_ITEM
Table
NA
PLANITEMID
UNIQUE INDEX ON
PLAN_ITEM_DETAILS
NA
PLANID, PLANITEMID
INDEX ON
PLANITEM_UDF_DATA
NA
PLANITEMSID, PLANID
INDEX ON
NA
PLAN_ITEM_RELATION
PLANITEMSID, PLANID
INDEX ON
MILESTONE_DEPENDENCY
MILESTONESID
INDEX ON MILESTONE
PLANITEMSID
Column Added
NA
RULEID - 255
Column Added
NA
EXTENSION - 4000 char
INDEX ON AUDIT_TRAIL
ORDERREF
Jeopardy
Create table Rule Header
NA
RULE_HEADER
Create table
RULE_UI_DETAILS
RULE_UI_DETAILS
CREATE TABLE
JEOPARDY_ALERT
NA
JEOPARDY_ALERT
Purge
CREATE TABLE
PURGE_STATUS
NA
CREATE TABLE
PURGE_STATUS
Extension
CREATE TABLE
EXTENSION
NA
CREATE TABLE
EXTENSION
INDEX ON extension
ORDERIDHISTORYSID,
ORDERLINEHISTORYSID,
orderUdfDataHistorySid,
orderHistorySid, orderid,
ORDERLINEUDFDATAHISTORYSID,
CHARACTERISTICSID,
ORDERLINECHARHISTORYSID,
ORDERAMENDMENTSID,
ORDERLINECHARVALUESID,
ORDERLINEUDFDATASID,
ORDERLINESID,
ORDERLINECHARVA
Orchestrator Schema
Changes
Drop Table
D_onOrchestratorStartUp
NA
Create Table
NA
D_SetPlanOMSResponseEvent
Create Table
NA
D_CommonActiveConfig
Create Table
NA
D_CommonActiveConfig_rrf$
CREATE INDEX
NA
D_CommonActiveConfig_rrf$(PID$)
Add new column
D_OPDResponseEvent
NA
JMSPriority
Add new column
NA
D_SubmitOrderRequestEvent
JMSPriority
Add new column D_Order NA
JMSPriority
Add new column D_Plan
NA
JMSPriority
Add new column
D_PlanItem
NA
JMSPriority
Add new column
D_GenericConstants
NA
JMSPriority
Drop Table
D_SubmitOrderRequestEvent NA
Drop Table
D_AbstractObject
NA
Drop Table
D_onOrchestratorStartUp
NA
Drop Table
D_AbstractObject_rrf$
NA
Drop Table
D_ExecutionPlanAmendRequest NA
Drop Table
D_ExecutionPlanAmendResponse NA
Drop Table
D_FeasibilityResponseEvent NA
Drop Table
D_onBEStartUp
NA
Drop Table
D_OPDResponseEvent
NA
Drop Table
D_SendOrderPlan
NA
Drop Table
D_Ancestor
NA
Drop Table
D_Ancestor_rrf$
NA
Drop Table
D_ActiveTaskForCancelTask NA
Drop Table
D_ActiveTaskForCancelTask_rrf$ NA
Drop Table
D_AncestorForCompensate NA
Drop Table
D_AncestorForCompensate_rrf$ NA
Drop Table
D_AncestorForRestart
Drop Table
D_AncestorForRestart_rrf$ NA
Drop Table
D_Parent
NA
Drop Table
D_Parent_rrf$
NA
OCV Schema Changes
NA
Database Schema Changes | 185
Drop Table
D_ParentForCompensate
NA
Drop Table
D_ParentForCompensate_rrf$ NA
Drop Table
D_ParentForRestart
NA
Drop Table
D_ParentForRestart_rrf$
NA
Drop Table
D_ChildProduct
NA
Drop Table
D_ChildProduct_rrf$
NA
Drop Table
D_ModificationSequence
NA
Drop Table
D_ModificationSequence_elem_29 NA
Drop Table
D_ModificationSequence_rrf$ NA
Drop Table
D_ModificationSequenceElement NA
Drop Table
D_ModificationSequenceEleme_9A NA
Drop Table
D_Order
NA
Drop Table
D_Order_lines
NA
Drop Table
D_Order_rrf$
NA
Drop Table
D_NewOrder
NA
Drop Table
D_NewOrder_lines
NA
Drop Table
D_NewOrder_rrf$
NA
Drop Table
D_OrderLine
NA
Drop Table
D_OrderLine_rrf$
NA
Drop Table
D_ParentProductIdStringHolder NA
Drop Table
D_ParentProductIdStringHold_6E NA
Drop Table
D_Product
NA
Drop Table
D_Product_udf
NA
Drop Table
D_Product_rrf$
NA
Drop Table
D_SimpleEP
NA
Drop Table
D_SimpleEP_Items
NA
Drop Table
D_SimpleEP_rrf$
NA
Drop Table
D_NewEP
NA
Drop Table
D_NewEP_Items
NA
Drop Table
D_NewEP_rrf$
NA
Drop Table
D_OldEP
NA
Drop Table
D_OldEP_Items
NA
Drop Table
D_OldEP_rrf$
NA
Drop Table
D_SimpleItem
NA
Drop Table
D_SimpleItem_UDFs
Drop Table
D_SimpleItem_OrderLineIds NA
Drop Table
D_SimpleItem_PointDependencies NA
Drop Table
D_SimpleItem_TimeDependencies NA
Drop Table
D_SimpleItem_parentsForRestart NA
Drop Table
D_SimpleItem_ancestorsForRe_F9 NA
Drop Table
D_SimpleItem_parentsForComp_AB NA
Drop Table
D_SimpleItem_ancestorsForCo_3D NA
Drop Table
D_SimpleItem_dependeniesOnA_9B NA
Drop Table
D_SimpleItem_rrf$
NA
Drop Table
D_SimpleOrderLineId
NA
Drop Table
D_SimpleOrderLineId_rrf$ NA
Drop Table
D_SimplePointDependency NA
Drop Table
D_SimplePointDependency_rrf$ NA
Drop Table
D_SimpleTimeDependency NA
Drop Table
D_SimpleTimeDependency_rrf$ NA
Drop Table
D_SimpleUDF
NA
Drop Table
D_SimpleUDF_rrf$
NA
Drop Table
D_Temp
NA
Drop Table
D_Temp_rrf$
NA
Drop Table
D_UDF
NA
Drop Table
D_UDF_rrf$
NA
Drop Table
D_Workspace
NA
Drop Table
D_Workspace_modificationSeq_A6 NA
Drop Table
D_Workspace_rrf$
NA
NA

TIBCO® Fulfillment Order Management Administration

Transcription

Similar documents

Jaeckle Distributors Uses Spotfire to Differentiate in a

E - DEVLET

SciStream - PerkinElmer

Solution Brief TIBCO StreamBase for Foreign Exchange DOWNLOAD

Meade County RECC Improves Member Service, Reliability, and

Flemish String Board Attachment

Qmatic Pharmacy - Customer Flow Management