Open APIs

Dears,

We are implementing the Amend Product Order.

Regarding the patch operation for amending:

We see in the documentation today two possibilities:

1. Update a Product Order using application json (optional)
   Here we have two questions:
   (i)  Here we don't see any reference in the swagger/yaml openAPI spec to use this option, is that correct?
   (ii) Can we technically update multiple elements/attributes one single same patch operation?
   
   
2. Update a Product Order using merge-patch (mandatory)
   This is supported/described in the swagger/Yaml openAPI spec.

Additionally, in the state lifecycle diagram there are no dedicated states "Assessing Amendment", "Amendment pending" and "Amended" like we have for the cancel operation.
According to us it would be logical to have these 3 states and also foresee the asynchronous event possibility to respond (so not the Acknowledge of the request).
The evaluation if the requested detailed amend is possible, supported (could be complex), not beyond a PONR, if a lower OSS layer has a problem orchestration plan wise, could take more time.
Hence, our two other questions here are:

1. Would you agree that these 3 dedicated states & asynchronous feedback possibility, more similar to the cancel operation, are mandatory or advised to correctly implement the amend operation. Idea to add in v6?
2. Can we use the productOrderAttributeValueChangeEvent to respond to the Amend request ( using the extending the state model ) for this?
   Logical transition being (positive case): InProgress->Assessing Amendment->Amendment Pending->Amended->InProgress ?

Thanks in advance for your feedback.

Kind regards,
Peter Broucke
 

It depends if you require a state publishing / tracking mechanism for the amend request itself - if you do not, then a PATCH on the product order will result in a synchronous response showing success or failure.  But if you have more complex state transitions, you can look at the Task Resource pattern in TMF630.  The CancelProductOrder in TMF622 is a realization of this pattern.  You can use the Task Resource pattern to create a shepherd for your order amendment.

---

Dears,

We are implementing the Amend Product Order.

Regarding the patch operation for amending:

We see in the documentation today two possibilities:

1. Update a Product Order using application json (optional)
   Here we have two questions:
   (i)  Here we don't see any reference in the swagger/yaml openAPI spec to use this option, is that correct?
   (ii) Can we technically update multiple elements/attributes one single same patch operation?
   
   
2. Update a Product Order using merge-patch (mandatory)
   This is supported/described in the swagger/Yaml openAPI spec.

Additionally, in the state lifecycle diagram there are no dedicated states "Assessing Amendment", "Amendment pending" and "Amended" like we have for the cancel operation.
According to us it would be logical to have these 3 states and also foresee the asynchronous event possibility to respond (so not the Acknowledge of the request).
The evaluation if the requested detailed amend is possible, supported (could be complex), not beyond a PONR, if a lower OSS layer has a problem orchestration plan wise, could take more time.
Hence, our two other questions here are:

1. Would you agree that these 3 dedicated states & asynchronous feedback possibility, more similar to the cancel operation, are mandatory or advised to correctly implement the amend operation. Idea to add in v6?
2. Can we use the productOrderAttributeValueChangeEvent to respond to the Amend request ( using the extending the state model ) for this?
   Logical transition being (positive case): InProgress->Assessing Amendment->Amendment Pending->Amended->InProgress ?

Thanks in advance for your feedback.

Kind regards,
Peter Broucke
 

Hi

I understand that one of the need would be to have a task (REST resource) like /amendProductOrder and the accordingly states. Why not, I write a JIRA for future version of the specification, with also the idea to have a /submitProductOrder.

Patch with application/json is described in v5 (I see it in the OAS).

Yes you can update several attributes at same time with a PATCH application/json, but not several resources (to my knowledge).

For me the event is not an answer to a request, so the API client must subscribe to the event, then it will receive the event when for instance the state will have changed, but it may have no relationship with a request. 

It depends if you require a state publishing / tracking mechanism for the amend request itself - if you do not, then a PATCH on the product order will result in a synchronous response showing success or failure.  But if you have more complex state transitions, you can look at the Task Resource pattern in TMF630.  The CancelProductOrder in TMF622 is a realization of this pattern.  You can use the Task Resource pattern to create a shepherd for your order amendment.

---

Dears,

We are implementing the Amend Product Order.

Regarding the patch operation for amending:

We see in the documentation today two possibilities:

1. Update a Product Order using application json (optional)
   Here we have two questions:
   (i)  Here we don't see any reference in the swagger/yaml openAPI spec to use this option, is that correct?
   (ii) Can we technically update multiple elements/attributes one single same patch operation?
   
   
2. Update a Product Order using merge-patch (mandatory)
   This is supported/described in the swagger/Yaml openAPI spec.

Additionally, in the state lifecycle diagram there are no dedicated states "Assessing Amendment", "Amendment pending" and "Amended" like we have for the cancel operation.
According to us it would be logical to have these 3 states and also foresee the asynchronous event possibility to respond (so not the Acknowledge of the request).
The evaluation if the requested detailed amend is possible, supported (could be complex), not beyond a PONR, if a lower OSS layer has a problem orchestration plan wise, could take more time.
Hence, our two other questions here are:

1. Would you agree that these 3 dedicated states & asynchronous feedback possibility, more similar to the cancel operation, are mandatory or advised to correctly implement the amend operation. Idea to add in v6?
2. Can we use the productOrderAttributeValueChangeEvent to respond to the Amend request ( using the extending the state model ) for this?
   Logical transition being (positive case): InProgress->Assessing Amendment->Amendment Pending->Amended->InProgress ?

Thanks in advance for your feedback.

Kind regards,
Peter Broucke
 

It looks to me indeed like a good idea to have such JIRA for a future version of the specification with this.
Thanks.

Hi

I understand that one of the need would be to have a task (REST resource) like /amendProductOrder and the accordingly states. Why not, I write a JIRA for future version of the specification, with also the idea to have a /submitProductOrder.

Patch with application/json is described in v5 (I see it in the OAS).

Yes you can update several attributes at same time with a PATCH application/json, but not several resources (to my knowledge).

For me the event is not an answer to a request, so the API client must subscribe to the event, then it will receive the event when for instance the state will have changed, but it may have no relationship with a request. 

It depends if you require a state publishing / tracking mechanism for the amend request itself - if you do not, then a PATCH on the product order will result in a synchronous response showing success or failure.  But if you have more complex state transitions, you can look at the Task Resource pattern in TMF630.  The CancelProductOrder in TMF622 is a realization of this pattern.  You can use the Task Resource pattern to create a shepherd for your order amendment.

---

Dears,

We are implementing the Amend Product Order.

Regarding the patch operation for amending:

We see in the documentation today two possibilities:

1. Update a Product Order using application json (optional)
   Here we have two questions:
   (i)  Here we don't see any reference in the swagger/yaml openAPI spec to use this option, is that correct?
   (ii) Can we technically update multiple elements/attributes one single same patch operation?
   
   
2. Update a Product Order using merge-patch (mandatory)
   This is supported/described in the swagger/Yaml openAPI spec.

Additionally, in the state lifecycle diagram there are no dedicated states "Assessing Amendment", "Amendment pending" and "Amended" like we have for the cancel operation.
According to us it would be logical to have these 3 states and also foresee the asynchronous event possibility to respond (so not the Acknowledge of the request).
The evaluation if the requested detailed amend is possible, supported (could be complex), not beyond a PONR, if a lower OSS layer has a problem orchestration plan wise, could take more time.
Hence, our two other questions here are:

1. Would you agree that these 3 dedicated states & asynchronous feedback possibility, more similar to the cancel operation, are mandatory or advised to correctly implement the amend operation. Idea to add in v6?
2. Can we use the productOrderAttributeValueChangeEvent to respond to the Amend request ( using the extending the state model ) for this?
   Logical transition being (positive case): InProgress->Assessing Amendment->Amendment Pending->Amended->InProgress ?

Thanks in advance for your feedback.

Kind regards,
Peter Broucke
 

The wholesale broadband Workgroup is currently evaluating a proposal from the FIT workgroup in Germany that has identified several amend productOrder use cases and created proposals for 2 or 3 different Amend Tasks.

Some of the identified use cases include:

• changing ProductOffering (upgrade/downgrade)
• changing Appointment (impacting ProductOrder orchestration)
• changing Resources (e.g. new phonenumber instead of porting)

The complexity of these use cases make a synchronous PATCH not feasible.

Let's allign on the content of the Jira request to cover this detail.

Regards

It looks to me indeed like a good idea to have such JIRA for a future version of the specification with this.
Thanks.

Hi

I understand that one of the need would be to have a task (REST resource) like /amendProductOrder and the accordingly states. Why not, I write a JIRA for future version of the specification, with also the idea to have a /submitProductOrder.

Patch with application/json is described in v5 (I see it in the OAS).

Yes you can update several attributes at same time with a PATCH application/json, but not several resources (to my knowledge).

For me the event is not an answer to a request, so the API client must subscribe to the event, then it will receive the event when for instance the state will have changed, but it may have no relationship with a request. 

It depends if you require a state publishing / tracking mechanism for the amend request itself - if you do not, then a PATCH on the product order will result in a synchronous response showing success or failure.  But if you have more complex state transitions, you can look at the Task Resource pattern in TMF630.  The CancelProductOrder in TMF622 is a realization of this pattern.  You can use the Task Resource pattern to create a shepherd for your order amendment.

---

Dears,

We are implementing the Amend Product Order.

Regarding the patch operation for amending:

We see in the documentation today two possibilities:

1. Update a Product Order using application json (optional)
   Here we have two questions:
   (i)  Here we don't see any reference in the swagger/yaml openAPI spec to use this option, is that correct?
   (ii) Can we technically update multiple elements/attributes one single same patch operation?
   
   
2. Update a Product Order using merge-patch (mandatory)
   This is supported/described in the swagger/Yaml openAPI spec.

Additionally, in the state lifecycle diagram there are no dedicated states "Assessing Amendment", "Amendment pending" and "Amended" like we have for the cancel operation.
According to us it would be logical to have these 3 states and also foresee the asynchronous event possibility to respond (so not the Acknowledge of the request).
The evaluation if the requested detailed amend is possible, supported (could be complex), not beyond a PONR, if a lower OSS layer has a problem orchestration plan wise, could take more time.
Hence, our two other questions here are:

1. Would you agree that these 3 dedicated states & asynchronous feedback possibility, more similar to the cancel operation, are mandatory or advised to correctly implement the amend operation. Idea to add in v6?
2. Can we use the productOrderAttributeValueChangeEvent to respond to the Amend request ( using the extending the state model ) for this?
   Logical transition being (positive case): InProgress->Assessing Amendment->Amendment Pending->Amended->InProgress ?

Thanks in advance for your feedback.

Kind regards,
Peter Broucke