TIBCO Fulfillment Order Management Best …• TIBCO® Fulfillment Order Management version 3.0.0...

TIBCO® Fulfillment OrderManagement Best Practices GuideSoftware Release 3.0.0July 2015

Important Information

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

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

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

TIBCO, Two-Second Advantage, TIBCO ActiveMatrix BusinessWorks, TIBCO Runtime Agent, TIBCO Administrator,and TIBCO Enterprise Message Service, are either registered trademarks or trademarks of TIBCO Software Inc. inthe United States and/or other countries.

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

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

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

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

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

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

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

TIBCO Software Inc. Confidential Information.

TIBCO® Fulfillment Order Management Best Practices Guide

Contents

Preface..................................................................................................7Related Documentation............................................................................................................8

Typographical Conventions......................................................................................................9

Connecting with TIBCO Resources........................................................................................10

Chapter 1 Introduction to FOS Best Practices Guide...................11Purpose of the Document......................................................................................................12

Scope of the Document..........................................................................................................13

Chapter 2 General Installation Guidelines....................................15

Chapter 3 Hardware Configuration Guidelines.............................17Hardware Selection Guidelines..............................................................................................18

Hardware Sizing Guidelines...................................................................................................19

Fault Tolerance or Load Balancing Considerations................................................................20

Chapter 4 Software Configuration Guidelines..............................21Software Configuration Guidelines for FC..............................................................................22

Software Configuration Guidelines for FOM...........................................................................23

Chapter 5 Architecture....................................................................25Fulfillment Catalog Strategy...................................................................................................26

Offer and Price Engine Considerations..................................................................................27

Order Enrichment...................................................................................................................28

Other Considerations.............................................................................................................29

Chapter 6 Product Catalog Guidelines..........................................31Best Practices for Catalog Modeling......................................................................................32

Product Modelling Patterns....................................................................................................34

Functional Product Initializer.......................................................................................34

Helper Product Layer...................................................................................................35

Functional Coordination Helper Product......................................................................36

Use Case Layer Pattern..............................................................................................37


TOC | 5

Chapter 7 Offer and Price Engine..................................................39Eligibility for Offer and Price Engine.......................................................................................40

Chapter 8 Order Fulfillment Guidelines.........................................41Order Management System Guidelines.................................................................................42

Orchestrator Guidelines.........................................................................................................43

Automatic Order Plan Development Guidelines.....................................................................44

Transient Data Store Guidelines.............................................................................................45

Chapter 9 Development Guidelines...............................................47Team Organization Guidelines...............................................................................................48

Code Organization Guidelines...............................................................................................49

Environment Organization Guidelines....................................................................................50

Chapter 10 Performance Tuning Guidelines..................................51Performance Tuning Guidelines for FOM...............................................................................52

Performance Tuning Guidelines for Infrastructure..................................................................53

Chapter 11 Guidelines for Operations...........................................55Guidelines for Monitoring.......................................................................................................56

Guidelines for Logging...........................................................................................................57

Database Purging or Clean Up Guidelines............................................................................58


6 | TOC

Preface

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


Related Documentation

This section lists documentation resources you may find useful.

• TIBCO Fulfillment Order Management Concepts and Architecture This manual describes terminology and conceptsof TIBCO® Fulfillment Order Management.

• 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 User's Guide This manual describes the features as well as all the screens.• 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.


8 | Preface

Typographical Conventions

The following typographical conventions are used in this manual:

Table 1: General Typographical Conventions

UseConvention

Many TIBCO products are installed within the same home directory. This directory isreferenced in documentation as TIBCO_HOME. The value of TIBCO_HOME depends onthe operating system. For example, on Unix systems the default value is $HOME/tibco.

TIBCO_HOME

TRA_HOME

AF_HOME TIBCO® Runtime Agent installs into a directory inside ENV_HOME. This directory isreferenced in documentation as TRA_HOME. The value of TRA_HOME depends on theoperating 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_HOMEdepends on the operating system. For example, on Unix systems the default value is$TIBCO_HOME/af/3.0.

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

code font

Use MyCommand to start the foo process.

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

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

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

if no parameter is specified, MyCommand is enabled:

MyCommand [enable | disable]

Italic font is used in the following ways:italic font

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

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

example: MyCommand pathname

The note icon indicates information that is of special interest or importance, 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 theinformation provided in the current section to achieve a specific result.

The warning icon indicates the potential for a damaging situation, for example, dataloss or corruption if certain steps are taken or not taken.


Preface | 9

Connecting with TIBCO Resources

How to Join TIBCOmmunity

TIBCOmmunity is an online destination for TIBCO customers, partners, and resident experts—a place toshare and access the collective experience of the TIBCO community. TIBCOmmunity offers forums, blogs,and access to a variety of resources. To register, go to http://www.tibcommunity.com.

How to Access All TIBCO Documentation

After you join TIBCOmmunity, you can access the documentation for all supported product versions here:

https://docs.tibco.com.

How to Contact TIBCO Support

For comments or problems with this manual or the software it addresses, please contact TIBCO Support asfollows:• For an overview of TIBCO Support, and information about getting started with TIBCO Support, visit this

site:

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

• If you already have a valid maintenance or support contract, visit this site:

https://support.tibco.com

Entry to this site requires a username and password. If you do not have a username, you can request one.


10 | Preface

http://www.tibcommunity.com

https://docs.tibco.com

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

https://support.tibco.com

Chapter

1Introduction to FOS Best Practices Guide

The TIBCO Fulfillment Orchestration Suite (FOS) Best Practices Guide provides a vairety of best practice guidelinesyou can utilize throughout your TIBCO FOS installation. These best practcies are based on the experiences gainedat large and small customer sites.

The TIBCO FOS best practices described in the guide include agreeing on requirements to ensure a successfulproject implementation and determing hardware and software configuration guidelines.

Architecture best practices and design considerations are also addressed so that the implementation gets startedon the right foot.

The guide also addresses Configuration Management which involves knowing the state of all artifacts that makeup your system or project, managing the state of those artifacts, and releasing distinct versions of a system

Performance testing, usually the last resort to catch application defects, is also covered in the guide. It is laborintensive and usually only catches coding defects. Architecture and design defects may be missed. One method tocatch some architectural defects is to simulate load testing on the application before it is deployed and to deal withperformance issues before they become problems

Topics

• Purpose of the Document• Scope of the Document


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

The purpose of the document is to assist in the execution of TIBCO Fulfillment Orchestration projects, byproviding recommendations and guidelines for its implementation. The content is based on the experiencesgained 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 and technicalrequirements.

• 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 is assumed.


12 | Introduction to FOS Best Practices Guide

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

The scope of the document includes the following software:• TIBCO® Fulfillment Order Management version 3.0.0• TIBCO® Fulfillment Catalog version 3.0.0, based on TIBCO MDM version 8.3.2 HF5


Introduction to FOS Best Practices Guide | 13

Chapter

2General Installation Guidelines

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

TIBCO product documentation, should always be the primary reference for installation. However, for tips, tricksand best practices, refer to TIBCO Fulfillment Orchestration Suite Best Practices Guidewhich includes guidelines forinstallation and configuration for all the required supporting TIBCO software, including TIBCO Enterprise MessageService.


Chapter

3Hardware Configuration Guidelines

When selecting and configuring your hardware for the TIBCO Fulfillment Orchestration Suite you need to considerthe machine type best suited for your environment as well as the hardware sizing requirements and load balancingrecommendations.

Topics

• Hardware Selection Guidelines• Hardware Sizing Guidelines• Fault Tolerance or Load Balancing Considerations


Hardware Selection GuidelinesYou need to select certain core hardware components for TIBCO Fulfillment Order Management using theguidelines 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), and Offer

and Price Engine (OPE) are core components of Fulfillment Order Management.• For Fulfillment Catalog, refer to the TIBCO Master Data Management documentation for guidelines

including the Installation Overview and Planning for Installation sections in the TIBCO Collaborative InformationManager Installation and Configuration Guide.


18 | Hardware Configuration Guidelines

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

An example of a non-functional requirement involves putting logging and operational Enterprise MessageService (EMS) traffic on the same EMS instance. However, this leads to delays in processing orders becausethe orders are blocked by non-business critical logging traffic. A better solution is to create separate EMSinstances for logging and core EMS traffic to eliminate this blockage.

Hardware sizing is generally an outcome from preliminary performance testing. All environments are differentand you cannot use a cookbook approach to a particular order management problem. TIBCO recommendscompleting extensive performance testing on lab hardware before recommending particular hardware to acustomer. These lab runs should reflect a realistic order size and load mix, as well as an anticipated plan size.The plan should also cover pre-submit and post-submit activities, in particular, validation and eligibility callsto Offer and Price Engine (OPE).


Hardware Configuration Guidelines | 19

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 best practicesfor EMS.

Table 2: Fault Tolerance and Load Balancing Recommendations

Load BalancingFault ToleranceApplication

Dual server deployment usingactive-active configuration,

Dual server deployment withshared database state and

TIBCO EMS

managed by EMS. Requirement foractive-passive configuration.shared state using SAN ordatabase, with SAN preferred.

Managed by EMS, heartbeats areexchanged between serverinstances to determine on failover Generally most customer

implementations will not require aload balancing configuration.

when to alternate the server.Requirement for shared state, eitherSAN or database. Generally SANis recommended for performancereasons, but this incurs additionalhardware and softwarerequirements as outlined in EMSdocumentation.

Alternative is to use OS-levelclustering active-passive pair withthe clustering softwareguaranteeing only one EMSinstance will access the shared stateat any one time.

Run in active-active configurationand allow messages to load balance

Dual server deployment.Third-party load balancer used to

TIBCO Fulfillment OrderManagement System

from JMS queues. Do not use SOAPsend UI client requests to the activeserver. over HTTP interfaces to remove the

requirement for a load balancer.

This is a design-time component,not a high-load application and it

Dual server deployment, JBosscluster managing active-passive

TIBCO Master Data Management

TIBCO Fulfillment Catalog does not require load balancing.pair. Third-party load balancerHowever, load balancing could beused to send client requests to theimplemented using JBoss clusterand active-active pair.

active server. Shared storagerequired to maintain state betweenservers.


20 | Hardware Configuration Guidelines

Chapter

4Software Configuration Guidelines

You should follow the TIBCO recommended guidelines to configure your software for TIBCO Fulfillment Catalogand TIBCO Fulfillment Order Management. Planning and configuring these components correctly will enhanceyour overall system performance.

Topics

• Software Configuration Guidelines for FC• Software Configuration Guidelines for FOM


Software Configuration Guidelines for FCIt is important to configure your TIBCO Fulfillment Catalog correctly to enhance your system performance.TIBCO recommends planning and completing the configuration in conjunction with appropriate performancetesting and tuning.

TIBCO recommends the following best practices:• Use MDM configurator to create Fulfillment Catalog enterprise.• While using the full or partial import, use the template provided by TIBCO Fulfillment Catalog. The

template can be generated by going to FulfillmentCatalog Operation->Export FC data->Blank Template.• When importing data (that is generated by another enterprise) into an enterprise, make sure that drop

down values are in sync between those two enterprises. For example, for PRODUCT repository in theimporting enterprise, the RECORD_TYPE drop-down should have all those values which were presentin the exporting enterprise.

• Whenever any repository is modified (either an attribute is added or deleted), the corresponding datasource and Input Map must be updated before using the Full or Partial Import feature in order that thefeature works correctly.


22 | Software Configuration Guidelines

Software Configuration Guidelines for FOMIt is important to configure your TIBCO Fulfillment Order Management components correctly to enhanceyour system performance. TIBCO recommends planning and completing the configuration in conjunctionwith appropriate performance testing and tuning.

Configuring components of TIBCO Fulfillment Order Management essentially means determining how manyinstances of each type of engine should be deployed across the number of physical servers available. Also,how much physical RAM should be allocated to each engine. The product documentation provides basicrecommendations for a minimal setup in Chapter 2,Installation and Deployment Options in the TIBCO OrderManagement Fulfillment Installation and Configuration .

TIBCO recommends the following best practices:1. For a typical production setup containing two physical servers, TIBCO recommends the following 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.

TIBCO Offer and Price Engine

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

TIBCO Fulfillment Order Management agents require a maximum memory allocation of 1 GB to accommodatethe 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 needed dependson the number of concurrent users, the desired availability of the system (a single node system can beunavailable 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 storage of theshopping cart.


Software Configuration Guidelines | 23

Chapter

5Architecture

There are a number of architecting strategies to consider when working with TIBCO Fulfillment Order Management.

TIBCO Fulfillment Order Management. architecture involves creating an effective Product Catalog strategy inaddition to making smart validation choices. You should also be aware of the best practices related to enrichmentstrategy and general recommendations.

Topics

• Fulfillment Catalog Strategy• Offer and Price Engine Considerations• Order Enrichment• Other Considerations


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 and decisionswhen running the TIBCO Fulfillment Catalog in either a live production system or in a deploymentenvironment.

You can configure TIBCO Fulfillment Order Management so that the product model dynamically publishesvia messaging from TIBCO Fulfillment Order Management (or potentially another product catalogue system).You can also configure TIBCO Fulfillment Order Management to read the product catalogue from off-linefiles.

You can make changes to the TIBCO Fulfillment Catalog in a live production system however, you shouldbe aware of the implications. The following implications show the potential danger of a live TIBCO FulfillmentCatalog instance dynamically publishing the product model to TIBCO Fulfillment Order 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 be

required anyway.

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

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


26 | Architecture

Offer and Price Engine ConsiderationsYou need to make some decisions regarding your implementation approach when using Offer and PriceEngine (OPE). Depending on your business environment and the task you want to accomplish, you can useeither 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 out-of-the-box OPE rules do not support your required types of validation and offerings, you shouldconsider the following:• How to implement the OPE rules• Where to invoke the OPE rules• What technology you use to build the OPE rules.

In some cases order validation and offerings are based on simple, static rules that do not refer to any externaldata and are based entirely on the order contents. This contrasts with catalogue-based OPE validation rulesthat 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.

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


Architecture | 27

Order EnrichmentWhile you are fulfilling an order you may need to reference existing data in the network inventory or customerinstalled base systems. TIBCO offers a sequence of steps you can follow to add this type of information toyour order.

Custom Order Enrichment

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

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

User-Defined Format

You can add this information using the user-defined format (UDF) data. This format is a better option becauseit eliminates the need for process components to complete the retrieval, which may result in less efficientbehavior including redundant or fragmented database queries.

General Recommendations

If you perform validation after enrichment, remove the validation data before submitting the information toTIBCO Fulfillment Order Management. This process flow helps eliminate data created in the data interfacefor 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.


28 | Architecture

Other ConsiderationsWhen you are designing your system architecture there are a number of general recommendations and bestpractices you should consider. These best practices cover end-to-end order tracking and ensure that you donot loose any data.

OrderRef

OrderRef, an external order ID, must be unique in all TIBCO Fulfillment Order Management orders. If yousubmit an order without a unique OrderRef, the Order Management System does not treat it as a new orderand 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 with differentTIBCO Fulfillment Order Management orders, TIBCO recommends adding the external ID as a header UDFin the order.

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

General Recommendations

It is important when you are designing your architecture to incorporate procedures that prevent order dataloss. TIBCO recommends reviewing the following procedures before when designing your architecturesolution:• Ensure that your architecture solution includes end-to-end order tracking capability and visibility similar

to that used in the TIBCO Fulfillment Order System.• Include recovery and repair capabilities in your design. For example, you need a plan for handling a

situation when a fulfillment process call fails to connect to a back-end system. Having a plan in placeeliminates prevents you from having to abort the order.

• Determine the interfaces that operation needs to complete this work. Re-sending an order may not be aviable 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 order processing

chain from front-end solutions to back-end systems.• Ensure that your solution architecture accounts for the different capabilities in each system area. For

example, a front-end system may not be able to resubmit an order once it is submitted, while a back-endsystem can receive order data again without considering it an amendment.


Architecture | 29

Chapter

6Product Catalog Guidelines

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

Topics

• Best Practices for Catalog Modeling• Product Modelling Patterns


Best Practices for Catalog ModelingYou should be aware of the best practices to use when creating a product model. You need to consider yourproduct catalog design of your and how Fulfillment Catalog can play a role in your product modeling. Youalso 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 the correctnumber and type of products to maximize reuse. TIBCO typically recommends using smaller cataloguesbecause 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 that containsenough technical detail to ensure that you can create correct fulfilment plans for orders.

In a typical design process, a product manager enters an initial view of a product into the catalog and theengineer then adds additional technical artifacts to the model to ensure there is enough information to correctlydrive the fulfilment of orders.

Occasionally, you need to add additional products to the catalogue which do not map to an actual TIBCOproduct. TIBCO refers to these products as Helper Products and you can add them to achieve a specificsequence of fulfilment 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 data

The complexity of the latter 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 the levelof 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 Fulfillment Catalogincluding user interface related issues. You also need to consider the order in which you want to present theitems and the arrangement of the order. For example, how do you arrange the order if a choice is requiredthat impacts the order.

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

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

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


32 | Product Catalog Guidelines

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. Theissues you may encounter during the life cycle process range from very fine to very granular and may include:• Adapt small, simple processes or process changes before larger changes.• Fill any architectural gaps for these processes.• Avoid business process management modeling.-• Consider the granularity of products in the catalogue.


Product Catalog Guidelines | 33

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

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

DescriptionTerm

A product that is orderedFunctional Product

A product that the functional product decomposesinto, via a Product-Comprised-Of relationship (and

Technical Product

autoprovision=true). These products do no appearon the order.

Functional Product InitializerThere are some business scenarios where you cannot use a standard TIBCO Fulfillment Order Managementpattern. In these cases there is a workaround pattern available to address your particular scenario.

Pattern Rationale

Standard TIBCO Fulfillment Order Management plan development specifies that for any action ordered ona parent product, plan items (such as process components) for children must be executed first, before theparent. This can create a problem in some scenarios because you may need to perform an operation for theparent before performing operations related to the children. For example, initializing an inventory entry forthe 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 cannot usethis pattern.

Pattern Realization

The workaround for this is to create a helper child product ( Functional Product Initializer) for the Functionalproduct, whose process components for any given action are always executed first in the plan for an order.The process component for the Functional Product Initializer helper could for example, create an entry forthe Functional product in an inventory system.

To maximize reusability, this pattern could define two helper products, one for create and one for updatewhich 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 you requirea 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. To simplifythe process TIBCO provides a layer of Helper products to use as a workaround in this situation.

Pattern Rationale

Standard TIBCO Fulfillment Orchestration Suite behavior specifies that an action ordered on a parent product,results in an execution plan containing the process components for the same action for the child products.

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

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 product layer,one for each of the back-end calls.

In this case, the 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 update atechnical product using a CEASE action followed by a PROVIDE action, those process components can bedirectly 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 Technical Productrather than after fulfilment activities for the child products are complete. To allow the process componentsto run in parallel, you can create a Functional Coordinator helper product to perform activities related to theFunctional product.

Pattern Rationale

In an ideal situation, process components for a product action should not assume anything about the parentproduct that they are comprising. However, some fulfilment scenarios such as provisioning an accessconnection, require some activity at the Functional product level during fulfilment of a lengthy technicalproduct.

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

Activities related to the parent product normally occur after fulfilment activities (process components) forall of the child products are complete. However, in this case we need activity for the Functional productduring the execution of fulfillment of the Technical product. This means that the process components mustrun 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 fulfilment of Technical products. The sequence number of theFunctional 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 a plannedmessage from the south) with no knowledge of any required Functional product activity, such as sending anotification to the sending party.

Use Case Layer PatternIn the current TIBCO Fulfillment Orchestration Suite product you can define only one sequence of activitiesfor a given action. However, you can now use a new layer of helper products in the hierarchy to provide thesame 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, for examplean Update. However, in the current TIBCO Fulfillment Orchestration Suite product you can define only onesequence 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 case scenario. Fora given order, attribute-based decomposition is used to ensure that only one use case helper product isincluded 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 layer allowsthe same tasks to be combined in different sequences for the same action. There is no explicit modeling ofthe Technical Product, only the tasks that operate on that product.

This pattern is an extension of the Helper Product Layer pattern described previously and provides the sameflexibility for combining tasks for different actions in the same use case.





Chapter

7Offer and Price Engine

TIBCO Offer Configuration and Validation (OPE) offers two modes of eligibility in TIBCO Fulfillment OrchestrationSuite with different configuration requirements for each mode. There are a number of best practices related to OPE.

Topics

• Eligibility for Offer and Price Engine


Eligibility for Offer and Price Engine

Two models of eligibility are supported:1. Segment eligibility2. Filters

Segment Eligibility

Segment eligibility is also configured in the product catalogue. Each product is configured with one to manysegments. Eligibility is determined by specifying a list of segments on the request message. For each segmentspecified in the request, there must be an exact match on the product for it to be returned. The product mayhave additional segments and still be eligible. The list of products matching the specified segments is thenreturned, adjusted by the specified filters.• This method is suitable for all order management environments• Reduces the number of relationships to be configured in the catalogue

Filters

The use of filters when ever applicable are encouraged. Using filters have the following advantages:• All the commercial products are not evaluated for offerings and prices.• Increases performance as only a limited set of offers is evaluated.


40 | Offer and Price Engine

Chapter

8Order Fulfillment Guidelines

TIBCO Order Management requires that you follow certain guidelines when viewing and submitting orders. Theseguidelines and best practices help you achieve optimal performance in your business environment. There are alsoguidelines and best practices to follow when using the various interfaces to develop an Automatic Order Plan.

Topics

• Order Management System Guidelines• Orchestrator Guidelines• Automatic Order Plan Development Guidelines• Transient Data Store Guidelines


Order Management System Guidelines

If orders are to be viewed in OMS then the OMS services must be used to submit orders.

OMS services are slightly different than Orchestrator. Amendments are processed through AmendOrder andCancelOrder interfaces. Submitting an amendment through SubmitOrder will result in the amendment beingignored.

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


42 | Order Fulfillment Guidelines

Orchestrator Guidelines


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

Orchestrator provides data interfaces for retrieving orders and plans. Invoking these on a live system willhave a performance impact so should only be used when absolutely necessary. In most cases the sameinformation is already available in OMS.Orchestrator provides a retry framework for Process Componentsin the event of a failure. This makes use of the cache server and a timer to retry. The system has been designedfor this, but it may be more efficient to implement retry handling internally within the Process Componentinstead of relying on Orchestrator to do it. This is particularly true in the case of IPE Process Components.

When implementing error handling for Process Components it is possible to configure different error handlernames in the plan fragment model. By default Orchestrator specifies the error handler name as configuredin global variables. If one is specified in the plan fragment model for a given Process Component then thatwill be specified in the call to the Plan Item Failed Handler. These names have no meaning within Orchestrator,but if necessary may be used within the Plan Item Failed Handler or subsequent error handling frameworkto route errors.

Scheduler polling interval in global variables is used to configure the cache server scheduler for timed events.This is used for time dependencies, as well as retries for Feasibility, Plan Development, and Process Componentfailures. This should not be set to less than 60000 msec.

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

scripts. This should be done with TDS at the same time. Restart Orchestrator Cache and Agent. This willresult in an outage of the system while the cleanup occurs.

2. Make use of the CleanupAtEndOfOrder option in Orchestrator which automatically purges the orderfrom the system when it reaches COMPLETE, CANCELLED, or WITHDRAWN state. The order and plandetails will still be retained within OMS, but no history will be available in Orchestrator.

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


Order Fulfillment Guidelines | 43

Automatic Order Plan Development Guidelines


Plan development performance is related to the size of the catalogue and order being decomposed. Wherepossible 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 useful workshould 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 of theevaluation of XPath expressions (XSLT processing) in BE.



Transient Data Store Guidelines

TDS data is replicated to OMS through the use of bridges. If the data in OMS is out of date then 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 an amendment toOMS and processed accordingly.

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 to retrieveorders, 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 shouldn’t be replicatedacross plan items. One plan item should be designated master for any given UDF. If a particular UDF isrequired by a plan item that doesn’t master this data, then the master plan item should be retrieved as well.

Where possible, Process Components should retrieve only data for its own plan item using the GetPlanItemsinterface. If the Process Component requires data from other plan items, it should retrieve those using thesame 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 to determinethe planItemIDs of dependent plan items. Where possible bundle these into the same GetPlanItems call toreduce 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 a limitedset of data. However, if it is necessary to do multiple GetPlanItems calls to determine dependent plan itemsit may be more efficient to do a single GetPlan instead to get all the information. Make use of the IDs-onlyoption to retrieve a list of IDs in the plan rather than the entire plan data.

SetPlan operation is provided so that UDFs may be set on the plan header. It is very important not to set dataon the plan items using this interface because it may potentially overwrite other plan item data that may beset by other Process Components. Setting plan header UDF data should only be done as a last resort. Useplan item UDF data instead.

SetPlanItem operation is provided to set UDF data on an individual plan item. By convention a ProcessComponent should set plan item UDF data only on its own plan item. There is no technical restriction onsetting data on other plan items, but this introduces a situation where there may be contention for the data.This is particularly a problem is plans with parallel tracks of execution. The convention of setting UDF dataonly 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 sending through onlythe UDFs that have changed rather than the entire set of UDFs. It is only possible to merge data if uniqueUDF names are implemented and configured in the TDS global variable flags. If merge data is not used, thenthe entire set of UDFs will be replaced by the set values. In this case it is necessary 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 SQL scripts.

This should be done with Orchestrator at the same time. Restart TDS Cache and Agent. This will resultin an outage of the system while the cleanup occurs.


Order Fulfillment Guidelines | 45

2. Make use of the CleanupAtEndOfOrder option in TDS which automatically purges the order from thesystem when it reaches COMPLETE or CANCELLED state. The order and plan details will still be retainedwithin 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 external projectto determine which orders to purge and then invoke these services with the list of orderIDs. This shouldbe done during a slow period in order processing due to the performance impact.



Chapter

9Development Guidelines

TIBCO provides development guidelines in the area of team, code, and environmental organization. Theserecommendations include things to consider when you first create your environment and set up your servers aswell as tips to avoid unnecessary delays in your environment. Additional information provides guidelines formanaging your source control and creating a configuration management strategy.

Topics

• Team Organization Guidelines• Code Organization Guidelines• Environment Organization Guidelines


Team Organization Guidelines

Consider carefully the management of changes to the product catalogue during development. Any FOSproject will have a single product catalogue, so changes to it need to be managed properly, in order to avoidunnecessary delays and unintended impacts. Consider maintaining centralized control over changing theproduct model, rather than allowing all developers on the team to make changes.

Consider also how changes to the catalogue are performed. In a development environment, where new entriesoften need to be added to FC in bulk, it may be worth considering an approach where data related to theproduct model is prepared outside FC (e.g. in a spreadsheet, csv files), and then imported into the catalogueperiodically, before publishing to FOM. Care needs to be taken that sufficient validation of the external dataentry is performed. If this approach is adopted, it is worth investing the time to thoroughly understand howMDM processes imported data.


48 | Development Guidelines

Code Organization Guidelines

Implement a configuration management strategy. This will generally mean making use of a dedicated buildteam who will solely be responsible for promoting code between environments. This will also require lockingdown access to environments after Development so that only appropriate configuration management staffhave access.

Use a source code control system, like 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 in theSC system, on a machine which is used for that purpose.

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

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

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


Development Guidelines | 49

Environment Organization Guidelines

In many cases, there will be a need for multiple instances of a development or test environment. For instance,one for developing the next release, another for bug fixing production, or perhaps other intermediate releasesthat 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 FOM instances, and multiple FC instances to reside on the same physical server. Of course CPU,disk and memory are limiting factors here. If multiple Oracle instances are not possible, then consider a perenvironment naming scheme for the schemas used by TIBCO Fulfillment Catalog and TIBCO FulfillmentOrder Management.


50 | Development Guidelines

Chapter

10Performance Tuning Guidelines

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

Topics

• Performance Tuning Guidelines for FOM• Performance Tuning Guidelines for Infrastructure


Performance Tuning Guidelines for FOM

In general, performance tuning is typically an activity that takes place in conjunction with performancetesting. For a discussion on performance testing please see section 15.7.

For OMS tuning, general guidelines can be found in the product documentation, specifically chapter four"Tuning" in the TIBCO Fulfillment Order Management Administration guide . OMS tuning essentially consistsof tuning the number of listeners for the input queues for order requests, and for processing status notificationsfrom fulfilment components as orders are processed.

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

As mentioned also in section 15.7, good general advice is, that while running performance testing, watchEMS queues throughout the order test to observer backup of messages. If queues are backing up then considerwhat components are 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>


52 | Performance Tuning Guidelines

Performance Tuning Guidelines for Infrastructure

Database

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

Consider using Oracle Enterprise Manager to help tune the databasehttp://www.oracle.com/technetwork/oem/db-mgmt/db-mgmt-093445.html?ssSourceSiteId=ocomen.Learning how to create Oracle 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 the externalsystems, as well for the integration between the various TIBCO Fulfillment Order Management components.Most of the tuning parameters such as max connections, various memory settings, and so on, of TIBCO EMSare available in tibemsd.conf file present in the configuration directory of EMS. Refer to the TIBCO EMSdocumentation for tuning details.


Performance Tuning Guidelines | 53

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

Chapter

11Guidelines for Operations

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

Topics

• Guidelines for Monitoring• Guidelines for Logging• Database Purging or Clean Up Guidelines


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• Log file contents for warnings and errors

TIBCO Fulfillment Catalog and TIBCO Master Data Management

• Process is running• Memory usage• Check database dependency• Check EMS dependency• Check internal errors• Log file contents for warnings and errors

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


56 | Guidelines for Operations

Guidelines for Logging

TIBCO Fulfillment Orchestration Suite includes a logging framework, in which all errors and log events arelogged to a standard EMS destination. Use this, in conjunction with a logging and event handling system(such as TIBCO’s Common Logging and Error handling framework), to ensure TIBCO Fulfillment OrchestrationSuite 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.


Guidelines for Operations | 57

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 certain state,in a given date range. This can be used to purge order data at regular intervals, and can also be run whilethe 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, plan itemsand UDF’s. If any of this information needs to be kept, then consider implementing an archiving strategy,where data is not purged, but copied to an archive. This will require some custom development though.

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

TDS and Orchestrator

Both these components can be configured to self-clean when an order reaches an end-state. Use these featuresto avoid having to cleanup TDS and Orchestrator. OMS should be seen as the database of record for ordersand plans, and the backing stores for Orchestrator and TDS should just be for dealing with data about ordersthat are in-flight.


58 | Guidelines for Operations

Date post:	25-May-2020
Category:	Documents
Upload:	others
View:	10 times
Download:	0 times

TIBCO Fulfillment Order Management Best …• TIBCO® Fulfillment Order Management version 3.0.0...

Documents