Open APIs

Hello community,

We are currently designing a TMF688-based Event Management component that would be used by our SOM layer (to create & listen events). One of the use-cases we are now deeply analyzing is about the provisioning of a BB Internet connectivity service on a specific customer site. During the service activation of the multiple RFS, there are some services that should be set in pending mode until there is an on-site visit to do some technical activities.  When a specific site activity is completed on the field services (for example: PON fiber installation by a field expert), the RFS flow (for example: Access Network configuration) can proceed to the final activation and the RFS service is consequently set to active. Our idea to manage this pending situation at SOM layer is to wait for a TMF688 event that is created by Field Services Management as soon as the expected on-site activity is concluded. The SOM layer will have specific tasks on the flow manager that stop the RFS provisioning  and it can only continue when the even is received.
 
Now, the question is about the kind of TMF688 event that should be triggered by Field Services. Note that TMF688 specifies an Event resource containing an Event field that can be set as "any". 
We see two options to model such kind of event:

1. Re-use TMF701 TaskFlow class into this Event field. As we are dealing with field services, we could imagine that there is a BPMN process for coordinating the technical experts activities when installing an access line or device on customer premises. For specific TaskFlow instances of the field services ProcessFlow, there would be an event to SOM Layer informing that a task changed the State to "Completed".
2. Create our own model into the Event field. In this case, we would define a new JSON schema & type specific for our field-services events. When looking to page 9 of TMF688 API User Guide, in the Event Data Model from Event Taxonomy, I only see reference to TMF API existing resources and their corresponding notifications. From this page, I am afraid that the user-specific modelling on the events can only be done for extending existing TMF resources (as seen in the "Extended Alarm Event" case from the diagram). So, I would like to understand if this option of creating our own JSON schema directly on the Event field is even possible to consider.

Our current preference for this implementation would be to take option 1 and re-use TMF701 taskFlow resource model embed in the Event field. Would like to have your thoughts about the two options and if both are aligned with the TMF688 as we don't want to "abuse" of the standard API definition.

Thanks for your help.

------------------------------
Carlos Portela
Prodapt Solutions
------------------------------

Hi Carlos,

Events are really usefull to implement a fulfilment using choreography where the next task starts when a previous one is completed.
Lifecycle status changes are perfect for this approach.
We are using the TMF639 Resource API for the event creation.
The lifecycleStatus as defined in the previous version of Resource API is perfectly suited for that. (planning, installing, operating, retiring)

As resource we define whatever resource that needs installing (e.g. a PON splitter in a streetcabinet).

The ResourceStateChangedNotification is used to trigger activities:

• lifecycleState='installing' -> When a process sets the resource to "installing" this is picked up by the field services application to send out service engineers.
• lifecycleState='operating' -> When the field engineer sets the status to operating he indicates that the resource is now ready for use. He could be using a mobile app to change this status. This state change is picked up by the SOM workflow that continues the activation of RFS.

I hope this approach helps you forward.

Regards


------------------------------
Koen Peeters
Ciminko Luxembourg
------------------------------

Hello Carlos

If I read the question

"Now, the question is about the kind of TMF688 event that should be triggered by Field Services."

Field Services do you consider them to be an Engaged party?  I would say that field services manages the state of work orders and work for Techs in the field. That work  relate to other business entities such as CFS,RFS and Resources.   The SOM flow  u describe seems to be dependent  on the state of work of a technician before it can continue its flow.  So I think perhaps you should look for a work complete or work order milestone change.  

The resource event change is possible if you are bounding yourself to a resource order  or inventory domain. The question here is which domain initiates the  dispatch? Eg: if SOM order , initiates a resource order that results in a field dispatch for work. Then you could follow the trail upwards. Change of state of Work will result in change of state of resource order which will result in change of state of SOM order.   

Hopes this  helps.




------------------------------
Bozidar Pasagic
Bell Canada
------------------------------

Koen, Bozidar,

Thanks for sharing your ideas. 

We've thought about the resource-level notifications but it was concluded that we dont have the entire granular view of resources in our SOM layer. Thus, resource-related events will be very difficult to handle. Additionally, there are some events that should be seen as actions/tasks (for example: call customer, validate building network room) that do not always fit or reflect on resource state changes.

I agree with Bozidar that we are dealing here more with work order related activities and they could be mapped with milestones. If we map to a TMF OpenAPI resource, should we consider a work order as a Service Order from TMF641?
In this case, I would imagine that SOM would call a WorkOrder Manager, using TMF641, to trigger some field services that would initiate multiple milestones seen as technician activities. As soon as each technician activity is completed, we would get in SOM a milestone-related notification to learn the progress of my field service request. 
Is it also what you were imagining Bozidar?

Regards

------------------------------
Carlos Portela
Prodapt Solutions
------------------------------

Original Message:
Sent: Jul 16, 2021 12:13
From: Bozidar Pasagic
Subject: TMF688 use-case with Field Services

Hello Carlos

If I read the question

"Now, the question is about the kind of TMF688 event that should be triggered by Field Services."

Field Services do you consider them to be an Engaged party?  I would say that field services manages the state of work orders and work for Techs in the field. That work  relate to other business entities such as CFS,RFS and Resources.   The SOM flow  u describe seems to be dependent  on the state of work of a technician before it can continue its flow.  So I think perhaps you should look for a work complete or work order milestone change.

The resource event change is possible if you are bounding yourself to a resource order  or inventory domain. The question here is which domain initiates the  dispatch? Eg: if SOM order , initiates a resource order that results in a field dispatch for work. Then you could follow the trail upwards. Change of state of Work will result in change of state of resource order which will result in change of state of SOM order.

Hopes this  helps.




------------------------------
Bozidar Pasagic
Bell Canada
------------------------------