TIBCO® Fulfillment Orchestration Suite Best … Fulfillment Orchestration Suite Best Practices...

TIBCO® Fulfillment Orchestration Suite BestPracticesSoftware Release 3.0.2June 2016

Two-Second Advantage®

Important Information

SOME TIBCO SOFTWARE EMBEDS OR BUNDLES OTHER TIBCO SOFTWARE. USE OF SUCHEMBEDDED OR BUNDLED TIBCO SOFTWARE IS SOLELY TO ENABLE THE FUNCTIONALITY (ORPROVIDE LIMITED ADD-ON FUNCTIONALITY) OF THE LICENSED TIBCO SOFTWARE. THEEMBEDDED OR BUNDLED SOFTWARE IS NOT LICENSED TO BE USED OR ACCESSED BY ANYOTHER TIBCO SOFTWARE OR FOR ANY OTHER PURPOSE.

USE OF TIBCO SOFTWARE AND THIS DOCUMENT IS SUBJECT TO THE TERMS ANDCONDITIONS OF A LICENSE AGREEMENT FOUND IN EITHER A SEPARATELY EXECUTEDSOFTWARE LICENSE AGREEMENT, OR, IF THERE IS NO SUCH SEPARATE AGREEMENT, THECLICKWRAP END USER LICENSE AGREEMENT WHICH IS DISPLAYED DURING DOWNLOADOR INSTALLATION OF THE SOFTWARE (AND WHICH IS DUPLICATED IN THE LICENSE FILE)OR IF THERE IS NO SUCH SOFTWARE LICENSE AGREEMENT OR CLICKWRAP END USERLICENSE AGREEMENT, THE LICENSE(S) LOCATED IN THE “LICENSE” FILE(S) OF THESOFTWARE. USE OF THIS DOCUMENT IS SUBJECT TO THOSE TERMS AND CONDITIONS, ANDYOUR USE HEREOF SHALL CONSTITUTE ACCEPTANCE OF AND AN AGREEMENT TO BEBOUND BY THE SAME.

This document contains confidential information that is subject to U.S. and international copyright lawsand treaties. No part of this document may be reproduced in any form without the writtenauthorization of TIBCO Software Inc.

TIBCO, Two-Second Advantage, TIBCO ActiveMatrix BusinessWorks, TIBCO Runtime Agent, TIBCOAdministrator, and TIBCO Enterprise Message Service, are either registered trademarks or trademarksof TIBCO Software Inc. in the United States and/or other countries.

Enterprise Java Beans (EJB), Java Platform Enterprise Edition (Java EE), Java 2 Platform EnterpriseEdition (J2EE), and all Java-based trademarks and logos are trademarks or registered trademarks ofOracle Corporation in the U.S. and other countries.

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

THIS SOFTWARE MAY BE AVAILABLE ON MULTIPLE OPERATING SYSTEMS. HOWEVER, NOTALL OPERATING SYSTEM PLATFORMS FOR A SPECIFIC SOFTWARE VERSION ARE RELEASEDAT THE SAME TIME. SEE THE README FILE FOR THE AVAILABILITY OF THIS SOFTWAREVERSION ON A SPECIFIC OPERATING SYSTEM PLATFORM.

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

THIS DOCUMENT COULD INCLUDE TECHNICAL INACCURACIES OR TYPOGRAPHICALERRORS. CHANGES ARE PERIODICALLY ADDED TO THE INFORMATION HEREIN; THESECHANGES WILL BE INCORPORATED IN NEW EDITIONS OF THIS DOCUMENT. TIBCOSOFTWARE 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 ORINDIRECTLY, BY OTHER DOCUMENTATION WHICH ACCOMPANIES THIS SOFTWARE,INCLUDING BUT NOT LIMITED TO ANY RELEASE NOTES AND "READ ME" FILES.

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

TIBCO Software Inc. Confidential Information

2

TIBCO® Fulfillment Orchestration Suite Best Practices

Contents

Introduction to FOS Best Practices Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Purpose of the Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5

Scope of the Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

General Installation Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

Hardware Configuration Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7

Hardware Selection Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7

Hardware Sizing Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7

Fault Tolerance or Load Balancing Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7

Software Configuration Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Software Configuration Guidelines for FC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Software Configuration Guidelines for FOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Fulfillment Catalog Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11

Offer and Price Engine Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11

Order Enrichment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Other Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Product Catalog Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Best Practices for Catalog Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Product Modelling Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Functional Product Initializer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Helper Product Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Functional Coordination Helper Product . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Use Case Layer Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18

Offer and Price Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Eligibility for Offer and Price Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Order Fulfillment Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Order Management System Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Orchestrator Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Automatic Order Plan Development Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22

Transient Data Store Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Development Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24

Team Organization Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Code Organization Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Environment Organization Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Performance Tuning Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Performance Tuning Guidelines for FOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3


Performance Tuning Guidelines for Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25

Guidelines for Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Guidelines for Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Guidelines for Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27

Database Purging or Clean Up Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4


Introduction to FOS Best Practices Guide

The TIBCO Fulfillment Orchestration Suite (FOS) Best Practices Guide provides a variety of best practiceguidelines that you can utilize throughout your TIBCO FOS installation. These best practcies are basedon the experiences gained at large and small customer sites.

The TIBCO FOS best practices described in the guide include agreeing on requirements to ensure asuccessful project implementation and determining hardware and software configuration guidelines.

Architecture best practices and design considerations are also addressed so that the implementationgets started on the right foot.

The guide also addresses configuration management which involves knowing the state of all artifactsthat make up your system or project, managing the state of those artifacts, and releasing distinctversions of a system.

Performance testing, usually the last resort to catch application defects, is also covered in the guide. It islabor intensive and usually only catches coding defects. Architecture and design defects may bemissed. One method to catch some architectural defects is to simulate load testing on the applicationbefore it is deployed and to deal with performance issues before they become problems.

Purpose of the DocumentThe best practices described in the TIBCO Fulfillment Orchestration Suite Best Practices guide will assistyou with many of the configuration and implementation steps you encounter during yourimplementation.

The purpose of the document is to assist in the execution of TIBCO Fulfillment Orchestration projects,by providing recommendations and guidelines for its implementation. The content is based on theexperiences gained in the field.

Although the information provided is predominantly of a general nature, you can always adapt it to thespecific situation at hand. Recommendations should be taken in the context of the business andtechnical requirements.

● This document is not intended as a replacement for the official TIBCO product documentationprovided with your product.

● This document is also not intended as a training reference or tutorial. Basic knowledge of TIBCOFulfillment Catalog, TIBCO Fulfillment Order Management, and its supporting software isassumed.

Scope of the DocumentThe Fulfillment Orchestration Suite Best Practices Guide describes the tips, tricks, and best practices for usewith the latest Fulfillment Orchestration Suite software.

The scope of the document includes the following software:

● TIBCO® Fulfillment Order Management version 3.0.2

● TIBCO® Fulfillment Catalog version 3.0.2, based on TIBCO MDM version 8.3.2 HF11

5


General Installation Guidelines

You should be familiar with which type of product documentation to use when working withTIBCOFulfillment Orchestration Suite.

TIBCO product documentation, should always be the primary reference for installation. However, fortips, tricks, and best practices, refer to TIBCO Fulfillment Orchestration Suite Best Practices Guide whichincludes guidelines for installation and configuration for all the required supporting TIBCO software,including TIBCO Enterprise Message Service.

6


Hardware Configuration Guidelines

When selecting and configuring your hardware for the TIBCO Fulfillment Orchestration Suite you needto consider the machine type best suited for your environment, as well as the hardware sizingrequirements and load balancing recommendations.

Hardware Selection GuidelinesYou need to select certain core hardware components for TIBCO Fulfillment Order Management usingthe guidelines listed in the specific TIBCO documentation.

Use these guidelines to select key hardware components for TIBCO Fulfillment Order Management:

● The Fulfillment Order Management Orchestrator, Automatic Order Plan Development (AOPD), andOffer and Price Engine (OPE) are core components of Fulfillment Order Management.

● For Fulfillment Catalog, refer to the TIBCO Master Data Management documentation for guidelinesincluding the Installation Overview and Planning for Installation sections in the TIBCO MDMInstallation and Configuration Guide.

Hardware Sizing GuidelinesYou need to consider certain non-functional requirements when designing infrastructure topography.You also need to follow specific guidelines before making hardware recommendations to a customer.

An example of a non-functional requirement involves putting logging and operational EnterpriseMessage Service (EMS) traffic on the same EMS instance. However, this leads to delays in processingorders because the orders are blocked by non-business critical logging traffic. A better solution is tocreate separate EMS instances for logging and core EMS traffic to eliminate this blockage.

Hardware sizing is generally an outcome from preliminary performance testing. All environments aredifferent, and you cannot use a cookbook approach to a particular order management problem. TIBCOrecommends completing extensive performance testing on lab hardware before recommendingparticular hardware to a customer. These lab runs should reflect a realistic order size and load mix, aswell as an anticipated plan size. The plan should also cover pre-submit and post-submit activities, inparticular, validation and eligibility calls to Offer and Price Engine (OPE).

Fault Tolerance or Load Balancing ConsiderationsFault tolerance and load balancing recommendations vary depending on the TIBCO application you areusing.

The following recommendations apply for fault tolerance and load balancing. Also, refer to the bestpractices for EMS.

7


Fault Tolerance and Load Balancing Recommendations

Application Fault Tolerance Load Balancing

TIBCO EMS Dual server deployment withshared database state andactive-passive configuration.Managed by EMS, heartbeatsare exchanged between serverinstances to determine onfailover when to alternate theserver. Requirement for sharedstate, either SAN or database.Generally SAN isrecommended for performancereasons, but this incursadditional hardware andsoftware requirements asoutlined in EMSdocumentation.

Alternative is to use OS-levelclustering active-passive pairwith the clustering softwareguaranteeing only one EMSinstance will access the sharedstate at any one time.

Dual server deployment usingactive-active configuration,managed by EMS. Requirementfor shared state using SAN ordatabase, with SAN preferred.

Generally most customerimplementations will notrequire a load balancingconfiguration.

TIBCO Fulfillment OrderManagement System

Dual server deployment. Third-party load balancer used tosend UI client requests to theactive server.

Run in active-activeconfiguration and allowmessages to load balance fromJMS queues. Do not use SOAPover HTTP interfaces toremove the requirement for aload balancer.

TIBCO Master DataManagement

TIBCO Fulfillment Catalog

Dual server deployment, JBosscluster managing active-passivepair. Third-party load balancerused to send client requests tothe active server. Sharedstorage required to maintainstate between servers.

This is a design-timecomponent, not a high-loadapplication and it does notrequire load balancing.However, load balancing couldbe implemented using JBosscluster and active-active pair.

8


Software Configuration Guidelines

You should follow the TIBCO recommended guidelines to configure your software for TIBCOFulfillment Catalog and TIBCO Fulfillment Order Management. Planning and configuring thesecomponents correctly enhances your overall system performance.

Software Configuration Guidelines for FCIt is important to configure your TIBCO Fulfillment Catalog correctly to enhance your systemperformance. TIBCO recommends planning and completing the configuration in conjunction withappropriate performance testing and tuning.

TIBCO recommends the following best practices:

● Use MDM Configurator to create the Fulfillment Catalog enterprise.

● While using the full or partial import, use the template provided by TIBCO Fulfillment Catalog. Togenerate the template, navigate to FulfillmentCatalog Operation->Export FC data->BlankTemplate.

● When importing data (generated by another enterprise) into an enterprise, make sure that dropdown values are in sync between those two enterprises. For example, for PRODUCT repository inthe importing enterprise, the RECORD_TYPE drop-down should have all those values which werepresent in the exporting enterprise.

● Whenever any repository is modified (either an attribute is added or deleted), the correspondingdata source and Input Map must be updated before using the Full or Partial Import feature so thatthe feature works correctly.

Software Configuration Guidelines for FOMConfigure your TIBCO Fulfillment Order Management components correctly to enhance your systemperformance. Make sure you plan and complete the configuration in conjunction with appropriateperformance testing and tuning.

Configuring components of TIBCO Fulfillment Order Management essentially means determining howmany instances of each type of engine should be deployed across the number of physical serversavailable. Also, how much physical RAM should be allocated to each engine. The productdocumentation provides basic recommendations for a minimal setup in Chapter 2, "Installation andDeployment Options" in the TIBCO Order Management Fulfillment Installation and Configuration guide.

The following best practices are recommended:

1. For a typical production setup containing two physical servers, it is recommended to use thefollowing basic starting configuration (per server):

a. Two TIBCO Fulfillment Order Management - Orchestrator, Automatic Order Plan Development(AOPD), Jeopardy.

2. Set identical minimum and maximum heap sizes.

3. Set 8 GB of heap size for each Fulfillment Order Management instance.

4. Offer and Price Engine (OPE) is an optional engine. Set 2GB for OPE.

Use Configurator to perform TIBCO Fulfillment Order Management configurations.

TIBCO Offer and Price Engine

Memory utilization in the OPE engine is related to the size of the catalogue. TIBCO recommends sizingthe memory allocation for these business engines according to the catalogue size.

9


TIBCO Fulfillment Order Management agents require a maximum memory allocation of 1 GB toaccommodate the largest orders that the system should accept.

TIBCO Order Capture System

Regarding system sizing, the number of OCS instances and whether or not a load balancer is neededdepends on the number of concurrent users, the desired availability of the system (a single node systemcan be unavailable in case of crash or maintenance), and the specifications of the machine hosting OCS.

Same considerations apply to OCS database sizing. OCS only uses the database for temporary storageof the shopping cart.

10


Architecture

There are a number of architect strategies to consider when working with TIBCO Fulfillment OrderManagement.

TIBCO Fulfillment Order Management architecture involves creating an effective product catalogstrategy in addition to making smart validation choices. You should also be aware of the best practicesrelated to enrichment strategy and general recommendations.

Fulfillment Catalog StrategyYou can use TIBCO's best practices to determine how best to utilize TIBCO Fulfillment Catalog in yourbusiness environment. This requires a strategy for handling your configuration requirements anddecisions when running the TIBCO Fulfillment Catalog in either a live production system or in adeployment environment.

You can configure TIBCO Fulfillment Order Management so that the product model dynamicallypublishes via messaging from TIBCO Fulfillment Order Management (or potentially another productcatalogue system). You can also configure TIBCO Fulfillment Order Management to read the productcatalogue from off-line files.

You can make changes to the TIBCO Fulfillment Catalog in a live production system; however, youshould be aware of the implications. The following implications show the potential danger of a liveTIBCO Fulfillment Catalog instance dynamically publishing the product model to TIBCO FulfillmentOrder Management :

● If the catalogue is changed incorrectly, the production system is immediately impacted.

● TIBCO Fulfillment Order Management requires a live instance of TIBCO Fulfillment Catalog.

● New products generally mean new process components and most likely a software release would berequired anyway.

TIBCO recommends using a live TIBCO Fulfillment Catalog instance only in the developmentenvironment. All other environments, including test, pre-production, and production can use the off-line files, which are easily version controlled and tagged in conjunction with the developed code.

In summary, carefully plan how to use the TIBCO Fulfillment Catalog in your organization inconjunction with your business requirements.

Offer and Price Engine ConsiderationsYou need to make some decisions regarding your implementation approach when using Offer andPrice Engine (OPE). Depending on your business environment and the task you want to accomplish,you can use either the engine with out-of-the-box rules or a custom validation.

OPE performs validations against rules defined in the TIBCO Fulfillment Catalog.

If the OPE out-of-the-box rules do not support your required types of validation and offerings, youshould consider the following:

● How to implement the OPE rules

● Where to invoke the OPE rules

● What technology to use to build the OPE rules.

In some cases, order validation and offerings are based on simple, static rules that do not refer to anyexternal data and are based entirely on the order contents. This contrasts with catalogue-based OPEvalidation rules that are dynamically created from information in the product catalog.

If you add additional information to the order from an external installed base, you can include it in thevalidation rules and use path-based technology to implement the validation.

11


Ensure that you select the appropriate developer skill set when choosing an implementation approachfor custom validation and offerings.

Order EnrichmentWhile you are fulfilling an order you may need to reference existing data in the network inventory orcustomer installed base systems. TIBCO offers a sequence of steps you can follow to add this type ofinformation to your order.

Custom Order Enrichment

TIBCO recommends adding reference information to the order before it is validated and submitted toTIBCO Fulfillment Order Management. As a best practice, you should use a custom order enrichmentcomponent to add the necessary data information during the first step.

The custom order enrichment component is based on generic rules and retrieves all of the requiredvalidation information, order plan development, and provisioning from the source systems in one step.It then adds the information to the order before it is validated and submitted to TIBCO FulfillmentOrder Management.

User-Defined Format

You can add this information using the user-defined format (UDF) data. This format is a better optionbecause it eliminates the need for process components to complete the retrieval, which may result inless efficient behavior including redundant or fragmented database queries.

General Recommendations

If you perform validation after enrichment, remove the validation data before submitting theinformation to TIBCO Fulfillment Order Management. This process flow helps eliminate data created inthe data interface for each plan item.

TIBCO also recommends retaining any information retrieved to support future plan development. Thisincludes information referenced in attribute based decomposition rules or information required forprovisioning.

Other ConsiderationsWhen you are designing your system architecture there are a number of general recommendations andbest practices you should consider. These best practices cover end-to-end order tracking and ensurethat you do not loose any data.

OrderRef

OrderRef, an external order ID, must be unique in all TIBCO Fulfillment Order Management orders. Ifyou submit an order without a unique OrderRef, the order management system (OMS) does not treat itas a new order and attempts to amend the previous order.

If you are using a non-unique external ID to map to OrderRef or an external ID that you can use withdifferent TIBCO Fulfillment Order Management orders, TIBCO recommends adding the external ID asa header UDF in the order.

UDFs in the Order Management System have limited out-of-the-box search ability.

General Recommendations

It is important when you are designing your architecture to incorporate procedures that prevent orderdata loss. TIBCO recommends reviewing the following procedures before designing your architecturesolution:

12


● Ensure that your architecture solution includes end-to-end order tracking capability and visibilitysimilar to that used in the order system of TIBCO Fulfillment Orchestration Suite.

● Include recovery and repair capabilities in your design. For example, you need a plan for handling asituation when a fulfillment process call fails to connect to a back-end system. Having a plan inplace prevents you from having to abort the order.

● Determine the interfaces that operation needs to complete this work. Re-sending an order may notbe a viable or reasonable option.

● Include target group representatives when planning manual steps and activities.

● Validate your error and exception handling approach with other representatives in the orderprocessing chain from front-end solutions to back-end systems.

● Ensure that your solution architecture accounts for the different capabilities in each system area. Forexample, a front-end system may not be able to resubmit an order once it is submitted, while a back-end system can receive order data again without considering it an amendment.

13


Product Catalog Guidelines

When creating a product model you should consider your overall product catalog design and how touse the fulfillment catalog in your product modeling. TIBCO provides some example modeling patternsyou can use to help manage the product life cycle.

Best Practices for Catalog ModelingYou should be aware of the best practices to use when creating a product model. You need to consideryour product catalog design and how Fulfillment Catalog can play a role in your product modeling.You also need to consider how to manage the product life cycle.

Effective Product Modeling

The goal of creating a good product model is to identify correct process components and include thecorrect number and type of products to maximize reuse. TIBCO typically recommends using smallercatalogues because they improve system performance

TIBCO recommends modeling as few components as possible but as many as are needed.

Product Catalog Design

Designing a product is a delicate balance between a pure product model view versus a model thatcontains enough technical detail to ensure that you can create correct fulfillment plans for orders.

In a typical design process, a product manager enters an initial view of a product into the catalog andthe engineer then adds additional technical artifacts to the model to ensure there is enough informationto correctly drive the fulfillment of orders.

Occasionally, you need to add additional products to the catalogue which do not map to an actualTIBCO product. TIBCO refers to these products as "helper products," and you can add them to achievea specific sequence of fulfillment actions or to ensure design principles are met.

TIBCO Fulfillment Catalog

TIBCO Fulfillment Catalog can play a role in your product modeling by functioning as:

● Master for product data● User of master product data from one or more other systems or catalogues● TIBCO Master Data Management solution, integrating with both masters and users of catalogue

dataThe complexity of the last two can increase as the number of systems grows.

Integrating TIBCO Fulfillment Catalog with Other Systems

You can integrate TIBCO Fulfillment Catalog with other systems; however, you should be aware of thelevel of automation with other systems and the catalogue model capabilities.

There are a number caveats to consider when using other systems with TIBCO Fulfillment Catalog. Forexample, other systems may require data that has no natural representation in TIBCO FulfillmentCatalog, including user interface related issues. You also need to consider the order in which you wantto present the items and the arrangement of the order. For example, how do you arrange the order if achoice is required that impacts the order.

Additionally, other systems may impose restrictions on model structures for performance ormanagement reasons rather than technical or capability reasons.

These issues may require you to define certain patterns and restrictions when you model items inTIBCO Fulfillment Catalog regardless of its underlying functionality.

14


TIBCO recommends verifying that the model you are using is compatible with the TIBCO FulfillmentOrchestration Suite release version.

Product Life Cycle Management

The following information lists the expected product life cycle management processes you may need tomanage:

● Define new products and offerings.● Validate and or tests new products and offerings.● Approve new products and offerings.● Act as decision maker for retiring or replacing a product.● Build or connect the required fulfillment elements.● Validate and or test the fulfillment elements.● Approve the fulfillment elements.● Deploy changes and determine how and when changes are deployed.● Determine the dependencies for life cycle management in other integrated systems.

It is important to understand the consequences of the decisions you make during the life cycle process.The issues you may encounter during the life cycle process range from very fine to very granular andmay include the following issues:

● Adapting small, simple processes or process changes before larger changes.● Filling any architectural gaps for these processes.● Avoiding business process management modeling.-● Considering the granularity of products in the catalogue.

Product Modelling PatternsThere are a number of example modeling patterns that you can apply to your specific businessenvironment.

The following table lists and describes certain terminology used in this section.

Term Description

Functional Product A product that is ordered

Technical Product A product that the functional productdecomposes into, via a Product-Comprised-Ofrelationship (and autoprovision=true). Theseproducts do not appear on the order.

Functional Product InitializerThere are some business scenarios where you cannot use a standard TIBCO Fulfillment OrderManagement pattern. In these cases, there is a workaround pattern available to address your particularscenario.

Pattern Rationale

The standard TIBCO Fulfillment Order Management plan development specifies that for any actionordered on a parent product, plan items (such as process components) for children must be executedfirst, before the parent. This can create a problem in some scenarios because you may need to perform

15


an operation for the parent before performing operations related to the children. For example,initializing an inventory entry for the parent product which the children need to refer to.

In this case, because the process component for the parent product is always executed last, you cannotuse this pattern.

Pattern Realization

The workaround for this is to create a helper child product (functional product initializer) for thefunctional product, whose process components for any given action are always executed first in theplan for an order. The process component for the functional product initializer helper could, forexample, create an entry for the functional product in an inventory system.

To maximize reusability, this pattern could define two helper products, one for create and one forupdate, which enables you to reuse the entire product across multiple functional products directly.

Splitting by action allows maximum flexibility in specifying process components. For example, if yourequire a create and an update process component in the same action, you could use this pattern.

Helper Product LayerIn certain situations, you cannot specify certain sequences in the standard TIBCO Fulfillment OrderManagement program, and you need to use multiple back-end calls to perform a single action. Tosimplify the process TIBCO provides a layer of helper products to use as a workaround in thissituation.

Pattern Rationale

The standard TIBCO Fulfillment Orchestration Suite behavior specifies that an action ordered on aparent product results in an execution plan containing the process components for the same action forthe child products.

In some cases, you may need to use a CEASE action to implement an UPDATE action followed by aPROVIDE action. However, you cannot specify this sequence in standard TIBCO Fulfillment OrderManagement.

This example requires multiple back-end calls to perform a single action on a product.

Pattern Realization

The workaround for this situation is to provide a layer of helper products below the technical productlayer, one for each of the back-end calls.

16


In this case, TIBCO Fulfillment Orchestration Suite handles the orchestration enabling you to keep theprocess components simple and directly reuse process components. For example, if you need to updatea technical product using a CEASE action followed by a PROVIDE action, those process componentscan be directly reused by the helper products defined for those actions.

Functional Coordination Helper ProductCertain situations require activity for the functional product during the fulfillment of the technicalproduct rather than after fulfillment activities for the child products are complete. To allow the processcomponents to run in parallel, you can create a functional coordinator helper product to performactivities related to the functional product.

Pattern Rationale

In an ideal situation, process components for a product action should not assume anything about theparent product that they are comprising. However, some fulfillment scenarios, such as provisioning anaccess connection, require some activity at the functional product level during fulfillment of a lengthytechnical product.

These activities may include sending an intermediate status message to the submitting party which canonly occur at the functional product level or updating inventory associated with the functional product.

Activities related to the parent product normally occur after the fulfillment activities (processcomponents) for all of the child products are complete. However, in this case we need an activity for the

17


functional product during the execution of fulfillment of the technical product. This means that theprocess components must run in parallel.

Pattern Realization

To address this situation, you can create a functional coordinator helper product to perform any activityrelated to the functional product during the fulfillment of technical products. The sequence number ofthe functional coordinator must be the same for all technical products so they can run in parallel.

To define relationships between functional and technical product process components, you can useintermediate milestones in the catalogue. In this way, communication between functional and technicalproducts is brokered through the TIBCO Fulfillment Orchestration Suite rather than using directcommunication.

Technical products simply trigger milestones when defined events occur (for example, receiving aplanned message from the south) with no knowledge of any required functional product activity, suchas sending a notification to the sending party.

Use Case Layer PatternIn the current TIBCO Fulfillment Orchestration Suite product you can define only one sequence ofactivities for a given action. However, you can now use a new layer of helper products in the hierarchyto provide the same flexibility for combining tasks for different actions in the same use case.

Pattern Rationale

Some use case scenarios require different sequencing for different variants of the same action, forexample an update activity. However, in the current TIBCO Fulfillment Orchestration Suite product,you can define only one sequence of activities for a given action.

Pattern Realization

The solution is to use a new layer of helper products in the hierarchy, representing the use casescenario. For a given order, attribute-based decomposition is used to ensure that only one use casehelper product is included on the execution plan making them mutually exclusive.

A layer of tasks is implemented below the layer representing the point of reuse. The use case layerallows the same tasks to be combined in different sequences for the same action. There is no explicitmodeling of the technical product, only the tasks that operate on that product.

18


This pattern is an extension of the helper product layer pattern described previously and provides thesame flexibility for combining tasks for different actions in the same use case.

19


Offer and Price Engine

TIBCO Offer Configuration and Validation (OPE) offers two modes of eligibility in TIBCO FulfillmentOrchestration Suite with different configuration requirements for each mode.

Eligibility for Offer and Price EngineThe following Two models of eligibility are supported:

● Segment eligibility

● Filters

Segment Eligibility

Segment eligibility is also configured in the product catalogue. Each product is configured with one tomany segments. Eligibility is determined by specifying a list of segments on the request message. Foreach segment specified in the request, there must be an exact match on the product for it to be returned.The product may have additional segments and still be eligible. The list of products matching thespecified segments is then returned, adjusted by the specified filters. This method is suitable for allorder management environments. It also reduces the number of relationships to be configured in thecatalogue.

Filters

The use of filters whenever applicable is encouraged. Using filters have the following advantages:

● All the commercial products are not evaluated for offerings and prices.

● Increases performance, because only a limited set of offers is evaluated.

20


Order Fulfillment Guidelines

TIBCO Fulfillment Order Management requires that you follow certain guidelines when viewing andsubmitting orders. These guidelines and best practices help you achieve optimal performance in yourbusiness environment. There are also guidelines and best practices to follow when using the variousinterfaces to develop an automatic order plan.

Order Management System GuidelinesIf orders are to be viewed in OMS, the OMS services must be used to submit orders.

OMS services are slightly different than Orchestrator. Amendments are processed through theAmendOrder and CancelOrder interfaces. Submitting an amendment through SubmitOrder will resultin the amendment being ignored.

Ensure the plan fragment model has been synchronized correctly to OMS before viewing the Ganttchart. If the model is not synchronized, then this will result in an error in the web interface.

Orchestrator GuidelinesIf orders are to be viewed in OMS, then the OMS services must be used to submit orders.

Notifications have an impact on overall Orchestrator performance. If notifications are not required, theyshould be disabled through the use of global variable flags. Turning off notifications in Orchestratorwill impact the Activity Log in OMS as well. In all cases the data element of notifications should beturned off unless absolutely necessary.

Orchestrator provides data interfaces for retrieving orders and plans. Invoking these on a live systemwill have a performance impact, so they should only be used when absolutely necessary. In most casesthe same information is already available in OMS. Orchestrator provides a retry framework for processcomponents in the event of a failure. This makes use of the cache server and a timer to retry. The systemhas been designed for this, but it may be more efficient to implement retry handling internally withinthe process component instead of relying on Orchestrator to do it. This is particularly true in the case ofIPE process components.

When implementing error handling for process components, you can configure different error handlernames in the plan fragment model. By default Orchestrator specifies the error handler name asconfigured in global variables. If one is specified in the plan fragment model for a given processcomponent, then that is specified in the call to the Plan Item Failed Handler. These names have nomeaning within Orchestrator, but if necessary may be used within the Plan Item Failed Handler orsubsequent error handling framework to route errors.

Scheduler polling interval in global variables is used to configure the cache server scheduler for timedevents. This is used for time dependencies, as well as retries for feasibility, plan development, andprocess component failures. This should not be set to less than 60000 milliseconds.

There are three methods currently available for cleaning up orders within Orchestrator:

1. Shutdown the Orchestrator Cache and Agent engines and purge the backing store database usingSQL scripts. This should be done with TDS at the same time. Restart Orchestrator Cache and Agent.This will result in an outage of the system while the cleanup occurs.

2. Make use of the CleanupAtEndOfOrder option in Orchestrator which automatically purges theorder from the system when it reaches a COMPLETE, CANCELLED, or WITHDRAWN state. Theorder and plan details will still be retained within OMS, but no history will be available inOrchestrator.

3. Make use of the DeleteOrder/DeletePlan operations in Orchestrator. This will require the use of anexternal project to determine which orders to purge and then invoke these services with the list oforderIDs. This should be done during a slow period in order processing due to the performanceimpact.

21


Automatic Order Plan Development GuidelinesIf orders are to be viewed in OMS, then the OMS services must be used to submit orders.

Plan development performance is related to the size of the catalogue and the order being decomposed.Where possible reduce the size of both to improve performance.

Do not model plan fragments that do not do anything at execution time. Only plan items that do usefulwork should go into the plan.

Make use of milestones and overlapping sequencing instead of empty plan items for dependencies.

When making use of Attribute-Based Decomposition, be aware of the potential performance impact ofthe evaluation of XPath expressions (XSLT processing) in BE.

Transient Data Store GuidelinesTDS data is replicated to OMS through the use of bridges. If the data in OMS is out of date, verify thatthe correct bridges are in place for order and plan data.

TDS stores both order and plan data:

● Order data is read only.

● Plan data is read-write data.

In order to make changes to order data in TDS, the updated order should be submitted as anamendment to OMS and processed accordingly.

The process components should not make use of order data. Instead, they should use plan data.

Order data is stored in large XML CLOBs within the TDS backing store. Operations are provided toretrieve orders, but extensive use of these will cause a performance impact.

Plan data is stored in concepts. Operations are provided to retrieve plans and plan items. This is therecommended way of retrieving data within Process Components.

TDS is designed to be a pass-by-reference data cache. This means that duplicate data should not bereplicated across plan items. One plan item should be a designated master for any given UDF. If aparticular UDF is required by a plan item that doesn’t master this data, then the master plan itemshould be retrieved as well.

Where possible, process components should retrieve only data for its own plan item using theGetPlanItems interface. If the process component requires data from other plan items, it should retrievethose using the same interface at the same time if the planItemIDs of those other plan items are known.

It may be necessary for the process component to invoke GetPlanItems multiple times in order todetermine the planItemIDs of dependent plan items. Where it is possible, bundle these into the sameGetPlanItems call to reduce the number of invocations.

Retrieving the entire plan from TDS using GetPlan can be less efficient than retrieving plan items usingGetPlanItems. This is particularly the case for larger plans where a process component needs only alimited set of data. However, if it is necessary to do multiple GetPlanItems calls to determine dependentplan items, it may be more efficient to do a single GetPlan instead to get all the information. Make useof the IDs-only option to retrieve a list of IDs in the plan rather than the entire plan data.

The SetPlan operation is provided so that UDFs may be set on the plan header. It is very important notto set data on the plan items using this interface because it may potentially overwrite other plan itemdata that may be set by other process components. Setting the plan header UDF data should only bedone as a last resort. Use the plan item UDF data instead.

The SetPlanItem operation is provided to set UDF data on an individual plan item. By convention aprocess component should set plan item UDF data only on its own plan item. There is no technicalrestriction on setting data on other plan items, but this introduces a situation where there may be

22


contention for the data. This is particularly a problem with plans with parallel tracks of execution. Theconvention of setting UDF data only on its own plan item eliminates the possibility of this happening.

Where possible make use of the merge data option in SetPlanItem. Using merge means sendingthrough only the UDFs that have changed rather than the entire set of UDFs. It is only possible tomerge data if unique UDF names are implemented and configured in the TDS global variable flags. Ifmerge data is not used, then the entire set of UDFs will be replaced by the set values. In this case it isnecessary to send through all UDFs, whether or not they have been changed.

1. Shutdown the TDS Cache and Agent engines and purge the backing store database using SQLscripts. This should be done with Orchestrator at the same time. Restart TDS Cache and Agent. Thiswill result in an outage of the system while the cleanup occurs.

2. Make use of the CleanupAtEndOfOrder option in TDS which automatically purges the order fromthe system when it reaches a COMPLETE or CANCELLED state. The order and plan details will stillbe retained within OMS, but no history will be available in TDS.

3. Make use of the DeleteOrder/DeletePlan operations in TDS. This will require the use of an externalproject to determine which orders to purge and then invoke these services with the list of orderIDs.This should be done during a slow period in order processing due to the performance impact.

23


Development Guidelines

TIBCO provides development guidelines in the area of team, code, and environmental organization.These recommendations include things to consider when you first create your environment and set upyour servers as well as tips to avoid unnecessary delays in your environment. Additional informationprovides guidelines for managing your source control and creating a configuration managementstrategy.

Team Organization GuidelinesConsider carefully the management of changes to the product catalogue during development. AnyTIBCO Fulfillment Orchestration Suite project will have a single product catalogue, so changes to itneed to be managed properly in order to avoid unnecessary delays and unintended impacts. Considermaintaining centralized control over changing the product model, rather than allowing all developerson the team to make changes.

Consider also how changes to the catalogue are performed. In a development environment, where newentries often need to be added to TIBCO Fulfillment Catalog in bulk, it may be worth considering anapproach where data related to the product model is prepared outside TIBCO Fulfillment Catalog (forexample, in a spreadsheet or csv files), and then imported into the catalogue periodically beforepublishing to TIBCO Fulfillment Order Management. Care needs to be taken so that sufficientvalidation of the external data entry is performed. If this approach is adopted, it is worth investing thetime to thoroughly understand how TIBCO MDM processes imported data.

Code Organization GuidelinesImplement a configuration management strategy. This will generally mean making use of a dedicatedbuild team who will solely be responsible for promoting code between environments. This will alsorequire locking down access to environments after development so that only appropriate configurationmanagement staff has access.

Use a source code control system, such as cvs, subversion, and so on.

No developer workstation should be master of any code delivered to production.

All deliveries should be based on scripted deployments built directly against a tagged set of artifacts inthe SC system on a machine which is used for that purpose.

Typically configuration files, SQL scripts, and generated wars all are source controlled.

Source controlling dependent jars should be considered, so that version dependency failures areavoided.

Configuration files for development environments can also usefully be centrally maintained to reduceenvironment set up overheads.

Environment Organization GuidelinesIn many cases there will be a need for multiple instances of a development or test environment. Forinstance, one for developing the next release, another for bug fixing production, or perhaps otherintermediate releases that are being tested in parallel.

When creating environments, it is a good idea to define a system for assigning non-overlapping TCP/IPports, and never use the default ports provided by the software installer. Doing this will allow multipleinstances of TIBCO Fulfillment Order Management instances and multiple TIBCO Fulfillment Cataloginstances to reside on the same physical server. Of course CPU and memory are limiting factors here. Ifmultiple Oracle instances are not possible, then consider a per environment naming scheme for theschemas used by TIBCO Fulfillment Catalog and TIBCO Fulfillment Order Management.

24


Performance Tuning Guidelines

TIBCO provides performance tuning guidelines and best practices for TIBCO Fulfillment Catalog,TIBCO Fulfillment Order Management, and the infrastructure.

Performance Tuning Guidelines for FOMIn general, performance tuning is typically an activity that takes place in conjunction with performancetesting.

For OMS tuning, general guidelines can be found in the product documentation, specifically chapterfour "Tuning" in the TIBCO Fulfillment Order Management Administration guide . OMS tuning essentiallyconsists of tuning the number of listeners for the input queues for order requests, and for processingstatus notifications from fulfilment components as orders are processed.

For the BE components, general BE tuning advice is also relevant. The same applies for the BWcomponents.

Good general advice is, that while running performance testing, watch EMS queues throughout theorder test to observe a backup of messages. If queues are backing up, then consider what componentsare processing messages off those queues and increase the consumers.

For OMS, consider the following configuration settings:<ConfValue description="Minimum number of concurrent consumers for listener (default 1)" name="Minimum number of concurrent consumers for listener" propname="com.tibco.af.oms.webservice.soap.jms.concurrentConsumers" sinceVersion="1.2" visibility="Advanced"> <ConfNum default="1" value="1" /></ConfValue><ConfValue description="Maximum number of concurrent consumers for listener (default 1)" name="Maximum number of concurrent consumers for listener" propname="com.tibco.af.oms.webservice.soap.jms.maxConcurrentConsumers" sinceVersion="1.2" visibility="Advanced"> <ConfNum default="5" value="5" /></ConfValue>

Performance Tuning Guidelines for Infrastructure

Database

Database tuning is a highly specialized area, and it is recommended that DBA expertise be availablewhen running performance tests and tuning the system.

Consider using Oracle Enterprise Manager to help tune the database http://www.oracle.com/technetwork/oem/db-mgmt/db-mgmt-093445.html?ssSourceSiteId=ocomen. Learning how to createOracle ADDM reports is a good idea and a good option if OEM is not available.

Adding appropriate indexes (as recommended by these tools) can help improve performance.

Enterprise Message Service

TIBCO EMS is used as a messaging bus to integrate TIBCO Fulfillment Order Management with theexternal systems, as well for the integration between the various TIBCO Fulfillment Order Managementcomponents. Most of the tuning parameters, such as max connections, various memory settings, and soon, of TIBCO EMS are available in the tibemsd.conf file present in the configuration directory of EMS.Refer to the TIBCO EMS documentation for tuning details.

25


http://www.oracle.com/technetwork/oem/db-mgmt/db-mgmt-093445.html?ssSourceSiteId=ocomen

http://www.oracle.com/technetwork/oem/db-mgmt/db-mgmt-093445.html?ssSourceSiteId=ocomen

Guidelines for Operations

For best practices, follow these guidelines for monitoring, logging, and database purging.

Guidelines for MonitoringTIBCO provides monitoring guidelines and best practices to use on the hardware and software in yourbusiness environment.

TIBCO recommends monitoring the following properties:

Hardware

● CPU

● Memory

● Disk Space

● Selected critical processes are running

Enterprise Message Service

● Queue depth and message count

● Consumer sessions

● Presence of listeners on queues and topics

Administrator

● Process is running

● Memory usage

● Queue length of internal tasks

● Log file contents for warnings and errors

Databases

● Check database availability through JDBC ping

TIBCO Order Management, TIBCO Fulfillment Orchestration Suite, and TDS

● Processes are running

● Memory usage

● Check database dependency

● Check EMS dependency

● Check internal errors


TIBCO Fulfillment Catalog and TIBCO Master Data Management

● Process is running

● Memory usage

● Check database dependency

● Check EMS dependency

● Check internal errors

26



You can also use the Hawk Accelerator offering from CTS to implement some of these releases morequickly.

Guidelines for LoggingTIBCO Fulfillment Orchestration Suite includes a logging framework with all errors and log eventslogged to a standard EMS destination. Use this in conjunction with a logging and event handlingsystem (such as TIBCO’s Common Logging and Error handling framework) to ensure TIBCOFulfillment Orchestration Suite component logging and errors are handled in a consistent fashion.

Consider using the same framework for handling logging from custom components (such as processcomponents) as well, so that all logging is managed in a central place.

Database Purging or Clean Up Guidelines

Order Management System

OMS is provided with a purge script that can be used to clean up data about orders that are in a certainstate, in a given date range. This can be used to purge order data at regular intervals and can also berun while the system is processing new orders, thus avoiding the need for an outage.

However, purging completely deletes the data about orders and associated objects such as plans, planitems and UDFs. If any of this information needs to be kept, then consider implementing an archivingstrategy, where data is not purged, but copied to an archive. This will require some customdevelopment.

Ensure that the business requirements around logging and archiving are properly captured andanalyzed.

TDS and Orchestrator

Both these components can be configured to self-clean when an order reaches an end-state. Use thesefeatures to avoid having to cleanup TDS and Orchestrator. OMS should be seen as the database ofrecord for orders and plans, and the backing stores for Orchestrator and TDS should just be for dealingwith data about orders that are in-flight.

27


Date post:	10-Jun-2018
Category:	Documents
Upload:	vuliem
View:	214 times
Download:	0 times

TIBCO® Fulfillment Orchestration Suite Best … Fulfillment Orchestration Suite Best Practices...

Documents