Introducing the all-new TIBCO Community site!

For current users, please click "Sign In" to reset your password and access the enhanced features. If you're a first-time visitor, we extend a warm welcome—click "Sign Up" to become a part of the TIBCO Community!

If you're seeking alternative community sites, explore ibi, Jaspersoft, and Spotfire.

Jump to content
  • Order Management Concepts for Telco and Media


    Manoj Chaurasia

    In order to be able to use TIBCO Fulfillment OrchestrationTM Suite (FOS) to its maximum extent, you need to understand the following important concepts, which are commonly used in order management in the Telecommunications and Media / Entertainment distribution industries.

    • Order

    Typically, an order lists products or services that need to be fulfilled. External systems may submit updates to the order as amendments, but the components within TIBCO Fulfillment Order Management may not change an order. In the context of TIBCO® Fulfillment Order Management, an order is composed of one or more order line(s). Each order line corresponds to a requested product. Fulfillment Order Management creates an execution plan for each order received. The plan is computed using a product model that is stored in a Product Catalog. The plan is composed of one or more plan item(s).

    More ...

    • Characteristics

    As a feature, a characteristic is a distinct capability of a product, e.g., features of a mobile device may include: SMS, Voice, LTE, Wireless Headset, etc. They can also include chargeable or non-chargeable, i.e., for billing purposes, a device that provides SMS capability may need an SMS-capable billing plan.

    For instance, a characteristic is a feature that can be measured, such as an SMS package that has a value of 500, 1000, or any configurable number.

    As an input, a characteristic requires values that need to be captured during order fulfillment, such as a phone number to be allocated to the mobile device, or an address to be associated with a business internet connection product.

    More ...

    • Product

    A product is modeled in a fulfillment catalog. Orders are composed of order lines, with each order line corresponding to a particular product that is requested by a customer. For each product that a customer orders, a series of plan items must be completed in order for that product to be provided. The link between the product and the plan item is maintained in the fulfillment catalog. The rules defining how different products depend on one another are also maintained in the fulfillment catalog. This then translates into dependencies between plan items in the overall execution plan.

    • Plan

    A plan represents the tasks to be completed to reach the fulfillment goal. An order only ever has one plan associated with it, and one plan is only ever associated with a single order. To fulfill an order, a series of tasks must be executed in a defined sequence and to a defined schedule. Sequencing and scheduling are modeled by dependencies between tasks. Once all dependencies for a task have been satisfied, then that task may be executed, with the net result being the order is fulfilled by following the required steps in the correct order.

    Within FOM, the series of tasks is represented by a plan (modeled as an object). The plan defines how to fulfill an order as a series of tasks, or plan items. Plan items are the smallest units of work recognized within this software; however, they may be composed of a series of sub-tasks that actually implement the work required. This can take the form of automated back-end system invocations, manual tasks, or any other unit of work that may be required.

    More ...

    • Plan Fragment

    A plan fragment is an abstraction of a Process Component that contains configuration information that the Orchestrator requires in order to handle errors and SLA notifications. Plan fragments are optional. If no plan fragment is defined for a particular Process Component then Orchestrator will use engine defaults to handle errors and no SLA notifications will occur.

    More ...

    • Plan Development

    During order plan development, Orchestrator calls out to AOPD to design the plan of action to fulfill an order. AOPD will analyze the order and the Product Catalog and determine what plan items must be executed and in what order in order to fulfill an order.

    More ...

    • Lifecycles

    Every single one of the objects listed on this page has its own lifecycle. See the diagrams to review the different states in their lifecycles.

    • Sequences

    Here are several ladder diagrams to illustrate the flow of events.


    User Feedback

    Recommended Comments

    There are no comments to display.


×
×
  • Create New...