Architecture

TIBCO Order Management is made of several components. Each component has a particular role.

The major components of TIBCO Order Management include:

Orchestrator: The Orchestrator exposes SOAP over HTTP, SOAP over JMS, and RESTful API services that can be used to submit the orders. The Orchestrator sends a request for plan development to AOPD for each incoming order. It invokes micro-level process plan fragments to initiate tasks within the operator's operational ecosystem, enabling appropriate actions in a variety of back-end systems (for example, billing systems, network systems, scheduling systems). The orchestrator tracks statuses and manages exceptions. The orchestrator has its own database.
Automatic Order Plan Development (AOPD): AOPD is stateless, it does not have any database. It develops the plan as per the incoming order. There are various rules that AOPD considers while generating the plan. Valid orders accepted by the Order Management System are decomposed into their individual products, services, and resources. An optimized order plan workflow process is then generated based on those basic building blocks to ensure an accurate order fulfillment. Optimization based on product rules and customer inventory is used to arrive at the final order plan.
Jeopardy: It monitors the orders or plans that come into the system. It sends out notifications on EMS channels whenever any plans or orders miss their timelines.
Authentication: This microservice implements OAuth2 specifications and generates a OAuth2 JWT (JSON Web Token). This microservice supports GRANT-TYPE as PASSWORD. User authentication is managed by this microservice and user authorization is managed by all the Order Management microservices. The generated token is used to access the resources exposed by any API from Order Management microservices. The following are some of the features of the authentication service:

Tenant Registration: Register a tenant, set the identity provider type to any one of the following: Oracle, PostgreSQL, LDAP, or External. Separate databases are created for each registered tenant’s user.

If you set the identity provider as "Oracle" or "PostgreSQL", then you have to create separate databases for each tenant. When you have set the identity provider as "LDAP", all the users and their roles are maintained in some Directory service. When you have set the identity provider as "External", it means that you do not have to use the Order Management's Authentication service for user authentication and token generation. As of now, we support Microsoft Azure Active-Directory as an external authentication service. Even when you have set the identity provider as "External", the tenant information is still stored in the Order Management's Authentication service relational database.

Note:

Authentication service is a primary service that does not depend on any other service to start.
The Order Management System UI and Configurator UI require the authentication service to always be up and running. The credentials entered on the UI by users are validated by the authentication service. On successful validation, tokens are generated. These tokens are then used by the Order Management System UI and Configurator UI to initiate the login process.

Data Service: Data Service is used to add, update, or modify the User-Defined Fields at the plan and plan items level. This is helpful when you do not want to perform an order amendment and want to update UDFs. There are two types of data services.
- Set plan or set plan items: This service is used to add, update, or modify the User-Defined Fields at the set plan or set plan items level.
- Get plan or get plan items: Through this service, a user receives the updated User-Defined Fields at the get plan or get plan items level.
Catalog Service: This microservice supports catalog loading using JMS channels and the RESTFul API.

The catalog created in the TIBCO® Product and Service Catalog is published over EMS topics. A bridge is created on the topic and the messages are listened on queues. You can configure the listeners for the Catalog service. For HTTP, a load balancer can be used for scaling.

You can publish over HTTP for online models and can also use a catalog client for offline models.

Catalog Client is a sample microservice provided along with TIBCO® Order Management. Catalog Client publishes catalogs through JMS or HTTP. To achieve better performance while loading a catalog in Order Management, the catalog-client reads an offline published catalog file and publishes it to the catalog service over the JMS or RESTful interface.

For example: One product model catalog contains the ProductModels XML tag, this contains multiple ProductModel XML tags. Catalog service can read the ProductModels XML and republish each of the ProductModel to its own JMS or RESTful interface. This behavior of a catalog service enables it to tackle the excess load on an instance and redistribute the load in the cluster of multiple catalog service instances.

There are multiple APIs exposed for the Catalog services. For more information, see the "Catalog Services API samples" section in the TIBCO® Order Management Web Services Guide.

Configurator: It exposes APIs to add, view, update, and delete configurations for all the services except Authorization, Configurator, and Configurator UI microservices.
Configurator UI: User Interface to perform all the operations exposed by Configurator microservice.
TM Forum Adapter Service: TM Forum Adapter is an implementation for the TMF622 API specification. It acts as a bridge between the TM Forum specification and the TIBCO Order Management system. TM Forum Adapter Service exposes REST over HTTP/HTTPS services, which can be used to query productOrder. TM Forum Adapter Service captures the productOrder and submits it to the Order Management System as an order request.

There are additional components, which are explained in more detail in theTIBCO Order Management User Guide. Here are a few of those additional components:

Order Management System User Interface (OMSUI): Provides operators a GUI to manage and track orders. Archival service persists order data and operators can use OMSUI to search, view, track, and trace orders. The users can act on order or order lines such as bulk action, amendment action. For any plan item in an error state, you can take corrective actions.
Common Logging: All TIBCO Order Management components report to a common logging component for the ease of maintenance and operations management of the system.
Archival Service: It acts as the data backup for the orchestrator and it uses EMS messages to achieve this. For every status change in the order, the Orchestrator sends an EMS message. Archival receives that message and save the required information in a database. After the order reaches its final state, it gets entire order information (such as order data, plan data, audit data) and saves it in the database. It exposes REST HTTP GET services to read this information. The Order Management System UI contacts Archival to get the information it requires.
Broker Service: The Broker service enhances the reliability and availability of the orchestrator instances. In the event of an instance failure, the Broker service redirects orders from the failed instance to all other active instances, ensuring seamless operation and minimal disruption to users.
Each the orchestrator instance registers itself with the Broker service when it starts up. Subsequently, instances regularly send status updates to the Broker service. The Broker service monitors the health of every instance through this ping mechanism.

TIBCO Order Management Architecture