Open APIs

Hi Community,

I'm looking to gather insights and standard industry usage patterns regarding the usage of TMF641 (Service Ordering Management API) when handling service disconnect/cease scenarios. Specifically, I'd love to hear how other teams and organizations handle the following two areas.

1. Necessity of Characteristics: When creating a cease order (serviceOrderItem.action = 'delete'), do you mandate the characteristic array under service? As per MEF, passing only service.id (and minimal identifying context) should be sufficient, since the target service instance already exists in the inventory with its allocated characteristics. Can client systems send empty/omitted characteristic arrays, or does the API backend/validation engine enforce sending characteristics on a delete action?
   
   
2. PATCH /serviceOrder behavior when POST omitted characteristics: If the initial POST to create the cease order is kept lean (omitting the characteristic block entirely), what information are you typically sending in a subsequent PATCH request for that order?

Thanks in advance for sharing your expertise!

Bests,

Molay

------------------------------
Molay Dutta
Deutsche Glasfaser Management GmbH
------------------------------

Hi Molay,

1. From my experience, in most cases, it isn't necessary to send service characteristics when deactivating (deleting) a service. Generally, the API does not require or enforce the presence of characteristics for the deletion action.
However, I have seen a client request that characteristics be included with a "delete" action when they want to set specific values before the service is deactivated on the network. These are specific, less common scenarios rather than the standard approach. 

2. Modifying (patching) in-flight orders can be complex, and what is allowed to be changed often depends on the current stage of order processing. Different stages might call for different validations, so you should consider your specific use case when making modifications.

Regards,
Plamen

------------------------------
Plamen Stanoev
Ericsson Inc.
------------------------------