TIBCO Fulfillment Order Management Best Practices Guide. Software Release January 2016

Transcription

1 TIBCO Fulfillment Order Management Best Practices Guide Software Release January 2016

2

3 Important Information SOME TIBCO SOFTWARE EMBEDS OR BUNDLES OTHER TIBCO SOFTWARE. USE OF SUCH EMBEDDED OR BUNDLED TIBCO SOFTWARE IS SOLELY TO ENABLE THE FUNCTIONALITY (OR PROVIDE LIMITED ADD-ON FUNCTIONALITY) OF THE LICENSED TIBCO SOFTWARE. THE EMBEDDED OR BUNDLED SOFTWARE IS NOT LICENSED TO BE USED OR ACCESSED BY ANY OTHER TIBCO SOFTWARE OR FOR ANY OTHER PURPOSE. USE OF TIBCO SOFTWARE AND THIS DOCUMENT IS SUBJECT TO THE TERMS AND CONDITIONS OF A LICENSE AGREEMENT FOUND IN EITHER A SEPARATELY EXECUTED SOFTWARE LICENSE AGREEMENT, OR, IF THERE IS NO SUCH SEPARATE AGREEMENT, THE CLICKWRAP END USER LICENSE AGREEMENT WHICH IS DISPLAYED DURING DOWNLOAD OR INSTALLATION OF THE SOFTWARE (AND WHICH IS DUPLICATED IN LICENSE.PDF) OR IF THERE IS NO SUCH SOFTWARE LICENSE AGREEMENT OR CLICKWRAP END USER LICENSE AGREEMENT, THE LICENSE(S) LOCATED IN THE LICENSE FILE(S) OF THE SOFTWARE. USE OF THIS DOCUMENT IS SUBJECT TO THOSE TERMS AND CONDITIONS, AND YOUR USE HEREOF SHALL CONSTITUTE ACCEPTANCE OF AND AN AGREEMENT TO BE BOUND BY THE SAME. This document contains confidential information that is subject to U.S. and international copyright laws and treaties. No part of this document may be reproduced in any form without the written authorization of TIBCO Software Inc. TIBCO, Two-Second Advantage, TIBCO ActiveMatrix BusinessWorks, TIBCO Runtime Agent, TIBCO Administrator, and TIBCO Enterprise Message Service, are either registered trademarks or trademarks of TIBCO Software Inc. in the United States and/or other countries. EJB, Java EE, J2EE, and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries. All other product and company names and marks mentioned in this document are the property of their respective owners and are mentioned for identification purposes only. THIS SOFTWARE MAY BE AVAILABLE ON MULTIPLE OPERATING SYSTEMS. HOWEVER, NOT ALL OPERATING SYSTEM PLATFORMS FOR A SPECIFIC SOFTWARE VERSION ARE RELEASED AT THE SAME TIME. SEE THE README FILE FOR THE AVAILABILITY OF THIS SOFTWARE VERSION ON A SPECIFIC OPERATING SYSTEM PLATFORM. THIS DOCUMENT IS PROVIDED AS IS WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. THIS DOCUMENT COULD INCLUDE TECHNICAL INACCURACIES OR TYPOGRAPHICAL ERRORS. CHANGES ARE PERIODICALLYADDED TO THE INFORMATION HEREIN; THESE CHANGES WILL BE INCORPORATED IN NEW EDITIONS OF THIS DOCUMENT. TIBCO SOFTWARE INC. MAY MAKE IMPROVEMENTS AND/OR CHANGES IN THE PRODUCT(S) AND/OR THE PROGRAM(S) DESCRIBED IN THIS DOCUMENT AT ANY TIME. THE CONTENTS OF THIS DOCUMENT MAY BE MODIFIED AND/OR QUALIFIED, DIRECTLY OR INDIRECTLY, BY OTHER DOCUMENTATION WHICH ACCOMPANIES THIS SOFTWARE, INCLUDING BUT NOT LIMITED TO ANY RELEASE NOTES AND "READ ME" FILES. Copyright TIBCO Software Inc. ALL RIGHTS RESERVED. TIBCO Software Inc. Confidential Information.

4

5 TOC 5 Contents Preface...7 Related Documentation...8 Typographical Conventions...9 TIBCO Resources...10 Chapter 1 Introduction to FOS Best Practices Guide...11 Purpose of the Document...12 Scope of the Document...13 Chapter 2 General Installation Guidelines...15 Chapter 3 Hardware Configuration Guidelines...17 Hardware Selection Guidelines...18 Hardware Sizing Guidelines...19 Fault Tolerance or Load Balancing Considerations...20 Chapter 4 Software Configuration Guidelines...21 Software Configuration Guidelines for FC...22 Software Configuration Guidelines for FOM...23 Chapter 5 Architecture...25 Fulfillment Catalog Strategy...26 Offer and Price Engine Considerations...27 Order Enrichment...28 Other Considerations...29 Chapter 6 Product Catalog Guidelines...31 Best 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

6 6 TOC Chapter 7 Offer and Price Engine...39 Eligibility for Offer and Price Engine...40 Chapter 8 Order Fulfillment Guidelines...41 Order Management System Guidelines...42 Orchestrator Guidelines...43 Automatic Order Plan Development Guidelines...44 Transient Data Store Guidelines...45 Chapter 9 Development Guidelines...47 Team Organization Guidelines...48 Code Organization Guidelines...49 Environment Organization Guidelines...50 Chapter 10 Performance Tuning Guidelines...51 Performance Tuning Guidelines for FOM...52 Performance Tuning Guidelines for Infrastructure...53 Chapter 11 Guidelines for Operations...55 Guidelines for Monitoring...56 Guidelines for Logging...57 Database Purging or Clean Up Guidelines...58

7 Preface The preface contains information about documentation related to the current document, typographical conventions, and information on how to contact TIBCO support.

8 8 Preface Related Documentation This section lists documentation resources you may find useful. TIBCO Fulfillment Order Management Concepts and Architecture This manual describes terminology and concepts of 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.

9 Preface 9 Typographical Conventions The following typographical conventions are used in this manual: Table 1: General Typographical Conventions Convention TIBCO_HOME TRA_HOME AF_HOME Use Many TIBCO products are installed within the same home directory. This directory is referenced in documentation as TIBCO_HOME. The value of TIBCO_HOME depends on the operating system. For example, on Unix systems the default value is $HOME/tibco. TIBCO Runtime Agent installs into a directory inside ENV_HOME. This directory is referenced in documentation as TRA_HOME. The value of TRA_HOME depends on the operating system. For example, on Unix systems the default value is $TIBCO_HOME/tra. TIBCO Fulfillment Order Management installs into a directory inside ENV_HOME. This directory is referenced in documentation as AF_HOME. The value of AF_HOME depends on the operating system. For example, on Unix systems the default value is $TIBCO_HOME/af/3.0. code font Code font identifies commands, code examples, filenames, pathnames, and output displayed in a command window. For example: Use MyCommand to start the foo process. bold code font Bold code font is used in the following ways: In procedures, to indicate what a user types. For example: Type admin. In large code samples, to indicate the parts of the sample that are of particular interest. In command syntax, to indicate the default parameter for a command. For example, if no parameter is specified, MyCommand is enabled: MyCommand [enable disable] italic font Italic font is used in the following ways: To indicate a document title. For example: See TIBCO BusinessWorks Concepts. To introduce new terms For example: A portal page may contain several portlets. Portlets are mini-applications that run in a portal. To indicate a variable in a command or code syntax that you must replace. For example: MyCommand pathname The note icon indicates information that is of special interest or importance, for example, an additional action required only in certain circumstances. The tip icon indicates an idea that could be useful, for example, a way to apply the information provided in the current section to achieve a specific result. The warning icon indicates the potential for a damaging situation, for example, data loss or corruption if certain steps are taken or not taken.

10 10 Preface TIBCO Resources How to Join TIBCOmmunity TIBCOmmunity is an online destination for TIBCO customers, partners, and resident experts a place to share and access the collective experience of the TIBCO community. TIBCOmmunity offers forums, blogs, and access to a variety of resources. To register, go to How to Access All TIBCO Documentation After you join TIBCOmmunity, you can access the documentation for all supported product versions here: How to Contact TIBCO Support For comments or problems with this manual or the software it addresses, please contact TIBCO Support as follows: For an overview of TIBCO Support, and information about getting started with TIBCO Support, visit this site: If you already have a valid maintenance or support contract, visit this site: Entry to this site requires a username and password. If you do not have a username, you can request one.

11 Chapter 1 Introduction to FOS Best Practices Guide The TIBCO Fulfillment Orchestration Suite (FOS) Best Practices Guide provides a vairety of best practice guidelines you can utilize throughout your TIBCO FOS installation. These best practcies are based on the experiences gained at large and small customer sites. The TIBCO FOS best practices described in the guide include agreeing on requirements to ensure a successful project implementation and determing hardware and software configuration guidelines. Architecture best practices and design considerations are also addressed so that the implementation gets started on the right foot. The guide also addresses Configuration Management which involves knowing the state of all artifacts that make up 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 labor intensive and usually only catches coding defects. Architecture and design defects may be missed. One method to catch some architectural defects is to simulate load testing on the application before it is deployed and to deal with performance issues before they become problems Topics Purpose of the Document Scope of the Document

12 12 Introduction to FOS Best Practices Guide Purpose of the Document The best practices described in the TIBCO Fulfillment Orchestration Suite Best Practices guide will assist you with 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, by providing recommendations and guidelines for its implementation. The content is based on the experiences gained in the field. Although the information provided is predominantly of a general nature, you can always adapt it to the specific situation at hand. Recommendations should be taken in the context of the business and technical requirements. This document is not intended as a replacement for the official TIBCO product documentation provided with your product. This document is also not intended as a training reference or tutorial. Basic knowledge of TIBCO Fulfillment Catalog, TIBCO Fulfillment Order Management and its supporting software is assumed.

13 Introduction to FOS Best Practices Guide 13 Scope of the Document The Fulfillment Orchestration Suite Best Practices Guide describes the tips, tricks and best practices for use with the latest Fulfillment Orchestration Suite software. The scope of the document includes the following software: TIBCO Fulfillment Order Management version TIBCO Fulfillment Catalog version 3.0.1, based on TIBCO MDM version HF9

14

15 Chapter 2 General Installation Guidelines You should be familiar with which type of product documentation to use when working withtibco Fulfillment Orchestration Suite. TIBCO product documentation, should always be the primary reference for installation. However, for tips, tricks and best practices, refer to TIBCO Fulfillment Orchestration Suite Best Practices Guidewhich includes guidelines for installation and configuration for all the required supporting TIBCO software, including TIBCO Enterprise Message Service.

16

17 Chapter 3 Hardware Configuration Guidelines When selecting and configuring your hardware for the TIBCO Fulfillment Orchestration Suite you need to consider the machine type best suited for your environment as well as the hardware sizing requirements and load balancing recommendations. Topics Hardware Selection Guidelines Hardware Sizing Guidelines Fault Tolerance or Load Balancing Considerations

18 18 Hardware Configuration Guidelines Hardware Selection Guidelines You need to select certain core hardware components for TIBCO Fulfillment Order Management using the 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), 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 Information Manager Installation and Configuration Guide.

19 Hardware Configuration Guidelines 19 Hardware Sizing Guidelines You 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 Enterprise Message Service (EMS) traffic on the same EMS instance. However, this leads to delays in processing orders because the orders are blocked by non-business critical logging traffic. A better solution is to create 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 are different and you cannot use a cookbook approach to a particular order management problem. TIBCO recommends completing extensive performance testing on lab hardware before recommending particular hardware to a customer. 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 calls to Offer and Price Engine (OPE).

20 20 Hardware Configuration Guidelines Fault Tolerance or Load Balancing Considerations Fault tolerance and load balancing recommendations vary depending on the TIBCO application you are using. The following recommendations apply for Fault Tolerance and Load Balancing. Also refer to best practices for EMS. Table 2: Fault Tolerance and Load Balancing Recommendations Application Fault Tolerance Load Balancing TIBCO EMS TIBCO Fulfillment Order Management System TIBCO Master Data Management TIBCO Fulfillment Catalog Dual server deployment with shared database state and active-passive configuration. Managed by EMS, heartbeats are exchanged between server instances to determine on failover when to alternate the server. Requirement for shared state, either SAN or database. Generally SAN is recommended for performance reasons, but this incurs additional hardware and software requirements as outlined in EMS documentation. Alternative is to use OS-level clustering active-passive pair with the clustering software guaranteeing only one EMS instance will access the shared state at any one time. Dual server deployment. Third-party load balancer used to send UI client requests to the active server. Dual server deployment using active-active configuration, managed by EMS. Requirement for shared state using SAN or database, with SAN preferred. Generally most customer implementations will not require a load balancing configuration. Run in active-active configuration and allow messages to load balance from JMS queues. Do not use SOAP over HTTP interfaces to remove the requirement for a load balancer. Dual server deployment, JBoss cluster managing active-passive This is a design-time component, not a high-load application and it pair. Third-party load balancer does not require load balancing. used to send client requests to the However, load balancing could be active server. Shared storage implemented using JBoss cluster required to maintain state between and active-active pair. servers.

21 Chapter 4 Software Configuration Guidelines You should follow the TIBCO recommended guidelines to configure your software for TIBCO Fulfillment Catalog and TIBCO Fulfillment Order Management. Planning and configuring these components correctly enhances your overall system performance. Topics Software Configuration Guidelines for FC Software Configuration Guidelines for FOM

22 22 Software Configuration Guidelines Software Configuration Guidelines for FC It 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 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. To generate the template, navigate to FulfillmentCatalog Operation->Export FC data->blank Template. When importing data (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 the importing enterprise, the RECORD_TYPE drop-down should have all those values which were present in the exporting enterprise. Whenever any repository is modified (either an attribute is added or deleted), the corresponding data source and Input Map must be updated before using the Full or Partial Import feature so that the feature works correctly.

23 Software Configuration Guidelines 23 Software Configuration Guidelines for FOM Configure your TIBCO Fulfillment Order Management components correctly to enhance your system performance. Make sure you plan and complete the configuration in conjunction with appropriate performance testing and tuning. Configuring components of TIBCO Fulfillment Order Management essentially means determining how many instances 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 basic recommendations for a minimal setup in Chapter 2, "Installation and Deployment 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 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 the memory allocation for these business engines according to the catalogue size. TIBCO Fulfillment Order Management agents require a maximum memory allocation of 1 GB to accommodate 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 needed depends on the number of concurrent users, the desired availability of the system (a single node system can 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 storage of the shopping cart.

24

25 Chapter 5 Architecture 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 in addition to making smart validation choices. You should also be aware of the best practices related to enrichment strategy and general recommendations. Topics Fulfillment Catalog Strategy Offer and Price Engine Considerations Order Enrichment Other Considerations

26 26 Architecture Fulfillment Catalog Strategy You can use TIBCO's best practices to determine how best to utilize TIBCO Fulfillment Catalog in your business environment. This requires a strategy for handling your configuration requirements and decisions when running the TIBCO Fulfillment Catalog in either a live production system or in a deployment environment. You can configure TIBCO Fulfillment Order Management so that the product model dynamically publishes via 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-line files. You can make changes to the TIBCO Fulfillment Catalog in a live production system however, you should be aware of the implications. The following implications show the potential danger of a live TIBCO Fulfillment Catalog 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 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 in conjunction with your business requirements.

27 Architecture 27 Offer and Price Engine Considerations You need to make some decisions regarding your implementation approach when using Offer and Price 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 out-of-the-box OPE rules do not support your required types of validation and offerings, you should consider 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 external data and are based entirely on the order contents. This contrasts with catalogue-based OPE validation 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 the validation rules and use path-based technology to implement the validation. Ensure that you select the appropriate developer skill set when choosing an implementation approach for custom validation and offerings.

28 28 Architecture Order Enrichment While you are fulfilling an order you may need to reference existing data in the network inventory or customer installed base systems. TIBCO offers a sequence of steps you can follow to add this type of information to your order. Custom Order Enrichment TIBCO recommends adding reference information to the order before it is validated and submitted to TIBCO Fulfillment Order Management. As a best practice, you should use a custom order enrichment component 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 required validation 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 Fulfillment Order Management. User-Defined Format You can add this information using the user-defined format (UDF) data. This format is a better option because it eliminates the need for process components to complete the retrieval, which may result in less efficient behavior including redundant or fragmented database queries. General Recommendations If you perform validation after enrichment, remove the validation data before submitting the information to TIBCO Fulfillment Order Management. This process flow helps eliminate data created in the data interface for each plan item. TIBCO also recommends retaining any information retrieved to support future plan development. This includes information referenced in attribute based decomposition rules or information required for provisioning.

29 Architecture 29 Other Considerations When you are designing your system architecture there are a number of general recommendations and best practices you should consider. These best practices cover end-to-end order tracking and ensure that you do not loose any data. OrderRef OrderRef, an external order ID, must be unique in all TIBCO Fulfillment Order Management orders. If you submit an order without a unique OrderRef, the Order Management System does not treat it as 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 with different TIBCO Fulfillment Order Management orders, TIBCO recommends adding the external ID as a header UDF in 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 data loss. TIBCO recommends reviewing the following procedures before when designing your architecture solution: 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 place eliminates 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 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 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-end system can receive order data again without considering it an amendment.

30

31 Chapter 6 Product Catalog Guidelines When creating a product model you should consider your overall product catalog design and how to use the fulfillment catalog in your product modeling. TIBCO provides some example modeling patterns you can use to help manage the product life cycle. Topics Best Practices for Catalog Modeling Product Modelling Patterns

32 32 Product Catalog Guidelines Best Practices for Catalog Modeling You should be aware of the best practices to use when creating a product model. You need to consider your product catalog design of your 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 the correct number and type of products to maximize reuse. TIBCO typically recommends using smaller catalogues 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 that contains enough 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 the engineer then adds additional technical artifacts to the model to ensure there is enough information to correctly drive the fulfilment of orders. Occasionally, you need to add additional products to the catalogue which do not map to an actual TIBCO product. TIBCO refers to these products as Helper Products and you can add them to achieve a specific sequence 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 level 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. For example, other systems may require data that has no natural representation in TIBCO Fulfillment Catalog including user interface related issues. You also need to consider the order in which you want to present the items and the arrangement of the order. For example, how do you arrange the order if a choice is required that impacts the order. Additionally, other systems may impose restrictions on model structures for performance or management reasons rather than technical or capability reasons. These issues may require you to define certain patterns and restrictions when you model items in TIBCO Fulfillment Catalog regardless of its underlying functionality. TIBCO recommends verifying that the model you are using is compatible with the TIBCO Fulfillment Orchestration Suite release version.

33 Product Catalog Guidelines 33 Product Life Cycle Management The following information lists the expected product life cycle management processes you may need to manage: 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 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.

34 34 Product Catalog Guidelines Product Modelling Patterns There 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. Term Functional Product Technical Product Description A product that is ordered A product that the functional product decomposes into, via a Product-Comprised-Of relationship (and autoprovision=true). These products do no appear on the order. Functional Product Initializer There are some business scenarios where you cannot use a standard TIBCO Fulfillment Order Management pattern. 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 on a parent product, plan items (such as process components) for children must be executed first, before the parent. This can create a problem in some scenarios because you may need to perform 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 cannot use this pattern. Pattern Realization The workaround for this is to create a helper child product ( Functional Product Initializer) for the Functional product, 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 for the Functional product in an inventory system. To maximize reusability, this pattern could define two helper products, one for create and one for update 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 you require a create and an update process component in the same action you could use this pattern.

35 Product Catalog Guidelines 35 Helper Product Layer In certain situations you cannot specify certain sequences in the standard TIBCO Fulfillment Order Management program and you need to use multiple back-end calls to perform a single action. To simplify the 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 PROVIDE action. 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 the process components simple, and directly reuse process components. For example, if you need to update a technical product using a CEASE action followed by a PROVIDE action, those process components can be directly reused by the Helper products defined for those actions.

36 36 Product Catalog Guidelines Functional Coordination Helper Product Certain situations require activity for the Functional product during the fulfillment of the Technical Product rather than after fulfilment activities for the child products are complete. To allow the process components to run in parallel, you can create a Functional Coordinator helper product to perform activities related to the Functional product. Pattern Rationale In an ideal situation, process components for a product action should not assume anything about the parent product that they are comprising. However, some fulfilment scenarios such as provisioning an access connection, require some activity at the Functional product level during fulfilment of a lengthy technical product. These activities may include sending an intermediate status message to the submitting party which can only occur 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) for all of the child products are complete. However, in this case we need activity for the Functional product during the execution of fulfillment of the Technical product. This means that the process components must run in parallel.

37 Product Catalog Guidelines 37 Pattern Realization To address this situation, you can create a Functional Coordinator helper product to perform any activity related to the Functional product during the fulfilment of Technical products. The sequence number of the 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 use intermediate milestones in the catalogue. In this way, communication between Functional and Technical products is brokered through the TIBCO Fulfillment Orchestration Suite rather than using direct communication. Technical products simply trigger milestones when defined events occur (for example, receiving a planned message from the south) with no knowledge of any required Functional product activity, such as sending a notification to the sending party. Use Case Layer Pattern In the current TIBCO Fulfillment Orchestration Suite product you can define only one sequence of activities for a given action. However, you can now use a new layer of helper products in the hierarchy to 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, for example an Update. 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 case scenario. For a given order, attribute-based decomposition is used to ensure that only one use case helper 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 layer allows the same tasks to be combined in different sequences for the same action. There is no explicit modeling of the 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 same flexibility for combining tasks for different actions in the same use case.

38 38 Product Catalog Guidelines

39 Chapter 7 Offer and Price Engine TIBCO Offer Configuration and Validation (OPE) offers two modes of eligibility in TIBCO Fulfillment Orchestration Suite with different configuration requirements for each mode. Topics Eligibility for Offer and Price Engine

40 40 Offer and Price Engine Eligibility for Offer and Price Engine 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 to many segments. Eligibility is determined by specifying a list of segments on the request message. For each 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 the specified segments is then returned, 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 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.

41 Chapter 8 Order Fulfillment Guidelines TIBCO Order Management requires that you follow certain guidelines when viewing and submitting orders. These guidelines and best practices help you achieve optimal performance in your business environment. There are also guidelines 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

42 42 Order Fulfillment 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 and CancelOrder interfaces. Submitting an amendment through SubmitOrder will result in the amendment being ignored. Ensure the plan fragment model has been synchronized correctly to OMS before viewing the Gantt chart. If the model is not synchronized then this will result in an error in the web interface.

43 Order Fulfillment Guidelines 43 Orchestrator Guidelines If 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 they should be disabled through the use of global variable flags. Note that turning off notifications in Orchestrator will impact the Activity Log in OMS as well. In all cases the data element of notifications should be turned off unless absolutely necessary. Orchestrator provides data interfaces for retrieving orders and plans. Invoking these on a live system will have a performance impact so should only be used when absolutely necessary. In most cases the same information is already available in OMS.Orchestrator provides a retry framework for Process Components in the event of a failure. This makes use of the cache server and a timer to retry. The system has been designed for this, but it may be more efficient to implement retry handling internally within the Process Component instead 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 handler names in the plan fragment model. By default Orchestrator specifies the error handler name as configured in global variables. If one is specified in the plan fragment model for a given Process Component then that will 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 framework to 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 Component failures. This should not be set to less than 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 will result in an outage of the system while the cleanup occurs. 2. Make use of the CleanupAtEndOfOrder option in Orchestrator which automatically purges the order from the system when it reaches COMPLETE, CANCELLED, or WITHDRAWN state. The order and plan details 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 external project 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.

44 44 Order Fulfillment Guidelines Automatic Order Plan Development Guidelines If 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 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 useful work 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 of the evaluation of XPath expressions (XSLT processing) in BE.

45 Order Fulfillment Guidelines 45 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 that the 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 to OMS 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 retrieve 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 the recommended 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 replicated across plan items. One plan item should be designated master for any given UDF. If a particular UDF is required 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 GetPlanItems interface. If the Process Component requires data from other plan items, it should retrieve those 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 to determine the planitemids of dependent plan items. Where possible bundle these into the same GetPlanItems call to reduce the number of invocations. Retrieving the entire plan from TDS using GetPlan can be less efficient than retrieving plan items using GetPlanItems. This is particularly the case for larger plans where a Process Component needs only a limited set of data. However, if it is necessary to do multiple GetPlanItems calls to determine dependent plan items it may be more efficient to do a single GetPlan instead to get all the information. Make use of the IDs-only option 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 data on the plan items using this interface because it may potentially overwrite other plan item data that may be set by other Process Components. Setting plan header UDF data should only be done as a last resort. Use plan item UDF data instead. SetPlanItem operation is provided to set UDF data on an individual plan item. By convention a Process Component should set plan item UDF data only on its own plan item. There is no technical restriction on setting 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 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 sending through only the UDFs that have changed rather than the entire set of UDFs. It is only possible to merge data if unique UDF names are implemented and configured in the TDS global variable flags. If merge data is not used, then the 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 result in an outage of the system while the cleanup occurs.

46 46 Order Fulfillment Guidelines 2. Make use of the CleanupAtEndOfOrder option in TDS which automatically purges the order from the system when it reaches COMPLETE or CANCELLED state. The order and plan details will still be 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 external project 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.

47 Chapter 9 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 up your servers as well as tips to avoid unnecessary delays in your environment. Additional information provides guidelines for managing your source control and creating a configuration management strategy. Topics Team Organization Guidelines Code Organization Guidelines Environment Organization Guidelines