Hi Santosh and Sajitha
Short answer is: yes - the expectation is that when events are raised, other software systems will consume those events and act accordingly.
Let's start with Open API
- Each Open API swagger and user guide specifies which events can be raised by an implementation of that API.
- I honestly don't know if we specify which events (if any) are mandatory, so that an event consumer can rely on these events, but at least a specific implementation is expected to documents which events it will be raising.
- The Open API says nothing about consuming of events, only about event production.
Now on to ODA
- ODA intends to define software components with well-defined functional boundaries, this is a work in progress, as I explained in my previous reply.
- The current component definitions relate to APIs exposed by and consumed by components.
- Work is in progress to extend this to events provided and consumed, for instance by flow-chart/sequence-diagram analysis. This is time-consuming so it will take a while for it to be done. For example, a sample flow currently under discussion posits that a product order state change can be consumed by a customer interaction system which as a result will send a message to the customer informing of order completion.
Hope this clarifies things.
------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
------------------------------
Original Message:
Sent: Feb 15, 2021 11:07
From: Santosh Pai
Subject: TMF-622 implementation across sub-systems in a distributed Environment
Hi TMF Experts, @Jonathan Goldberg
While the broader ODA aspects are being discussed, can you please provide your thoughts on Sajitha's earlier question:
"Following the design guidelines in TMF-630 & TMF-688, the ProductOrderStateChangeEvent is published from CRM to Order Orchestration enabling the orchestration of the ProductOrder"
As a general TMF Design Guideline, Can published Events be used by participating sub-systems to create and act upon entities?
Thanks,
------------------------------
Santosh Pai
Senior Director, Product Development
Oracle Corporation
Original Message:
Sent: Feb 15, 2021 01:01
From: Jonathan Goldberg
Subject: TMF-622 implementation across sub-systems in a distributed Environment
Hi Sajitha
Thanks for your detailed flow description. I would say the following:
- The Open API project and model say nothing (or very little) about functional or deployment architecture. You could (in principle) implement the entire collection of Open APIs over a single monolithic software unit.
- ODA, of course, has a lot to say about functional architecture, but discussions are ongoing with regard to component granularity. Indeed the jury is still out as to whether it makes sense to separate between an order capture and order handling component, due to shared responsibility for the data (product order and product). For example, does it make sense for the order to be stored in both CRM and in order handling, as you can see you have to adjust statuses in both systems. Additionally if there is a need to amend the order, where is this done - CRM or order handling?
So watch this space :)
------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
Original Message:
Sent: Feb 14, 2021 19:45
From: Sajitha Nair
Subject: TMF-622 implementation across sub-systems in a distributed Environment
Hi TMF Experts,
Requesting your inputs & insights regarding implementation of a TMF API Specification in a distributed computing environment when it is implemented across multiple sub-systems, what is the right architecture? @Jonathan Goldberg, @Ludovic Robert
Order to Cash Journey
ODA Functional Block: Core Commerce Management
- Customer browses Product Offers and adds Product Offer(s) to a Product Order
- Customer could configure one or more product offer(s) that are added to the Product Order
- Customer Submits the Product Order – after which PATCH/PUT operations are not allowed
Order Orchestration System
- Receives Product Order and begins the workflow of provisioning the order received from the CRM System – (ODA Customer Order Orchestration & distribution process)
- The preferred method of communication between CRM to this sub-component is asynchronous guaranteed delivery
- As part of this workflow the ServiceOrder is created for ODA Functional block: Production
Our Interpretation
Based on the Open API specification: TMF-622 and the ODA document: GB1022
Core Commerce ( e.g. a CRM system) does the following:
- Exposes APIs to create (POST) and update (PUT/PATCH) ProductOrders
- This is the only sub-component that is the master for TMF-622 ProductOrder resource
- This is the Order capture part of eTOM Process: Customer Order Handling of Business Process: Core Commerce Management Block
- Upon submission of the ProductOrder – an event is published for the Order Orchestration system to start processing the Order
Order Orchestration System does the following:
- Listens to a TMF-622 compliant event and begins the orchestration of the ProductOrder.
- The transition of the Customer Order into a Service Order occurs in this sub-system[ODA: Core Commerce Management to: Production] . In addition it publishes status updates to the CRM system
Questions
Are we interpreting the TMF APIs correctly in coming to the following conclusions:
- Similar to the POST operations, Events defined in TMF specs can be used to create an identical Resource (e.g. ProductOrder) in another sub-component that is not mastering that resource, but is an active participant of processing that resource
- Following the design guidelines in TMF-630 & TMF-688, the ProductOrderStateChangeEvent is published from CRM to Order Orchestration enabling the orchestration of the ProductOrder. Is this the correct?
------------------------------
Sajitha Nair
Oracle Corporation
------------------------------