Open APIs

Hi all,

Is there a way that a service provider can send PONR for TMF641( service Ordering) API to the consumer.  There are no notifications available for such scenarios.

Also, if there are multiple orderItems, is there a way to send the notifications at OrderItem level for individual orderItems?

------------------------------
Rati Mehrotra
Telstra Corporation
------------------------------

Wouldn't this be a status change notification? Assuming that the order changes state after the Point of No Return (PoNR) is reached, a consumer who subscribed to these notifications would be expected to get this. Both Order and Order Item have a state attribute so an API implementation could send such a notification at both levels.

Main block is that the state is defined as an enum, and I don't think that there is an appropriate value for passing PoNR.

An alternative approach would be to add an explicit attribute (perhaps boolean) reachedPoNR, and then have an attribute change notification.

Over to you @Ludovic Robert for further comment​​.

Hope it helps

------------------------------
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.
------------------------------

Hello Rati, Jonathan

About the PONR we introduced in the latest version (coming soon) an alternative way to handle it by providing a specific operation to request an order cancel. This is a distinct resource from the service order itself. This will allow client side to request a cancel and for server side to assessif the order is canceable (if it did not yet reach the PONR).

We not have request as of now to to introduce a specific PONR attribute. I'm not sure if it should be at item or order level (perhaps both - order level calculated from item ones).  I'm sharing Jonathan proposal - Note that state are "extensible" and you can define a inProgress.PoNEReached state in your implem.

Hope it helps

Ludovic

------------------------------
Ludovic Robert
Orange
My answer are my own & don't represent necessarily my company or the TMF
------------------------------

Original Message:
Sent: May 27, 2020 02:10
From: Jonathan Goldberg
Subject: PONR for the service OrderManagement

Wouldn't this be a status change notification? Assuming that the order changes state after the Point of No Return (PoNR) is reached, a consumer who subscribed to these notifications would be expected to get this. Both Order and Order Item have a state attribute so an API implementation could send such a notification at both levels.

Main block is that the state is defined as an enum, and I don't think that there is an appropriate value for passing PoNR.

An alternative approach would be to add an explicit attribute (perhaps boolean) reachedPoNR, and then have an attribute change notification.

Over to you @Ludovic Robert for further comment​​.

Hope it helps

------------------------------
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.
------------------------------

Hi @Ludovic Robert , 

In regards to the cancel transaction introduced as part of TMF 641 v4,  its the assessment of PONR  for a request originating from the  consumer.  The scenario that we have is the provider reaches a PoNR in its fulfilment journey and want to send a PoNR notification to consumer.

The option suggested above are 

• Adding inProgress.PONR  -  This option will complicate the state machine to depict any failure in terms of InProgress.PoNR-> Failed and other states. If we follow this option, i assume that we will have to send a StateValueChangeNotification with state as inProgress.PoNR
• Adding PoNR specific attribute - This would require TMF to add this attribute in the future enhancements and provider can generate AttributeValueChangeNotification or we can also think of adding PoNR as a milestone and send  serviceOrderMilestoneNotification (future notification to be added in TMF ) to make the implementation clean.

Thanks,
Rati

------------------------------
Rati Mehrotra
Telstra Corporation
------------------------------

Original Message:
Sent: May 27, 2020 03:17
From: Ludovic Robert
Subject: PONR for the service OrderManagement

Hello Rati, Jonathan

About the PONR we introduced in the latest version (coming soon) an alternative way to handle it by providing a specific operation to request an order cancel. This is a distinct resource from the service order itself. This will allow client side to request a cancel and for server side to assessif the order is canceable (if it did not yet reach the PONR).

We not have request as of now to to introduce a specific PONR attribute. I'm not sure if it should be at item or order level (perhaps both - order level calculated from item ones).  I'm sharing Jonathan proposal - Note that state are "extensible" and you can define a inProgress.PoNEReached state in your implem.

Hope it helps

Ludovic

------------------------------
Ludovic Robert
Orange
My answer are my own & don't represent necessarily my company or the TMF
------------------------------


Original Message:
Sent: May 27, 2020 02:10
From: Jonathan Goldberg
Subject: PONR for the service OrderManagement

Wouldn't this be a status change notification? Assuming that the order changes state after the Point of No Return (PoNR) is reached, a consumer who subscribed to these notifications would be expected to get this. Both Order and Order Item have a state attribute so an API implementation could send such a notification at both levels.

Main block is that the state is defined as an enum, and I don't think that there is an appropriate value for passing PoNR.

An alternative approach would be to add an explicit attribute (perhaps boolean) reachedPoNR, and then have an attribute change notification.

Over to you @Ludovic Robert for further comment​​.

Hope it helps

------------------------------
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.

Hi Rati

Both options could be studied & both seems to be valid (I'm note sure option 1 complexify the state engine if we considere inProgress.PoNR as a inProgress substatus). I will raise a Jira to discuss this point with the TMF team. If you did not mind i will copy you last entry for this Jira :)

To be honest, speaking from myself (and not as TMF API team member),   I'm not confortable to add any of them in the standard API because both options could be added per implem (without breaking API compliance). Adding this feature will enforce a way to manage PONR - we have here already 2 options on the table (and for state options 2 flavors: state item or/and order) - I always prefere to keep some flexibility and provide options.... but as I said this is only my view and I will raise the Jira to have a team assessment.

Hope it helps

------------------------------
Ludovic Robert
Orange
My answer are my own & don't represent necessarily my company or the TMF
------------------------------

Original Message:
Sent: May 28, 2020 02:08
From: Rati Mehrotra
Subject: PONR for the service OrderManagement

Hi @Ludovic Robert ,

In regards to the cancel transaction introduced as part of TMF 641 v4,  its the assessment of PONR  for a request originating from the  consumer.  The scenario that we have is the provider reaches a PoNR in its fulfilment journey and want to send a PoNR notification to consumer.

The option suggested above are

• Adding inProgress.PONR  -  This option will complicate the state machine to depict any failure in terms of InProgress.PoNR-> Failed and other states. If we follow this option, i assume that we will have to send a StateValueChangeNotification with state as inProgress.PoNR
• Adding PoNR specific attribute - This would require TMF to add this attribute in the future enhancements and provider can generate AttributeValueChangeNotification or we can also think of adding PoNR as a milestone and send  serviceOrderMilestoneNotification (future notification to be added in TMF ) to make the implementation clean.

Thanks,
Rati

------------------------------
Rati Mehrotra
Telstra Corporation
------------------------------


Original Message:
Sent: May 27, 2020 03:17
From: Ludovic Robert
Subject: PONR for the service OrderManagement

Hello Rati, Jonathan

About the PONR we introduced in the latest version (coming soon) an alternative way to handle it by providing a specific operation to request an order cancel. This is a distinct resource from the service order itself. This will allow client side to request a cancel and for server side to assessif the order is canceable (if it did not yet reach the PONR).

We not have request as of now to to introduce a specific PONR attribute. I'm not sure if it should be at item or order level (perhaps both - order level calculated from item ones).  I'm sharing Jonathan proposal - Note that state are "extensible" and you can define a inProgress.PoNEReached state in your implem.

Hope it helps

Ludovic

------------------------------
Ludovic Robert
Orange
My answer are my own & don't represent necessarily my company or the TMF


Original Message:
Sent: May 27, 2020 02:10
From: Jonathan Goldberg
Subject: PONR for the service OrderManagement

Wouldn't this be a status change notification? Assuming that the order changes state after the Point of No Return (PoNR) is reached, a consumer who subscribed to these notifications would be expected to get this. Both Order and Order Item have a state attribute so an API implementation could send such a notification at both levels.

Main block is that the state is defined as an enum, and I don't think that there is an appropriate value for passing PoNR.

An alternative approach would be to add an explicit attribute (perhaps boolean) reachedPoNR, and then have an attribute change notification.

Over to you @Ludovic Robert for further comment​​.

Hope it helps

------------------------------
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.

Hi @Ludovic Robert
is there any discussion happened on the JIRA item of PONR and did we get any conclusion ?
​

------------------------------
Prateek Mathur
Infosys
------------------------------

Original Message:
Sent: May 28, 2020 02:24
From: Ludovic Robert
Subject: PONR for the service OrderManagement

Hi Rati

Both options could be studied & both seems to be valid (I'm note sure option 1 complexify the state engine if we considere inProgress.PoNR as a inProgress substatus). I will raise a Jira to discuss this point with the TMF team. If you did not mind i will copy you last entry for this Jira :)

To be honest, speaking from myself (and not as TMF API team member),   I'm not confortable to add any of them in the standard API because both options could be added per implem (without breaking API compliance). Adding this feature will enforce a way to manage PONR - we have here already 2 options on the table (and for state options 2 flavors: state item or/and order) - I always prefere to keep some flexibility and provide options.... but as I said this is only my view and I will raise the Jira to have a team assessment.

Hope it helps

------------------------------
Ludovic Robert
Orange
My answer are my own & don't represent necessarily my company or the TMF
------------------------------


Original Message:
Sent: May 28, 2020 02:08
From: Rati Mehrotra
Subject: PONR for the service OrderManagement

Hi @Ludovic Robert ,

In regards to the cancel transaction introduced as part of TMF 641 v4,  its the assessment of PONR  for a request originating from the  consumer.  The scenario that we have is the provider reaches a PoNR in its fulfilment journey and want to send a PoNR notification to consumer.

The option suggested above are

• Adding inProgress.PONR  -  This option will complicate the state machine to depict any failure in terms of InProgress.PoNR-> Failed and other states. If we follow this option, i assume that we will have to send a StateValueChangeNotification with state as inProgress.PoNR
• Adding PoNR specific attribute - This would require TMF to add this attribute in the future enhancements and provider can generate AttributeValueChangeNotification or we can also think of adding PoNR as a milestone and send  serviceOrderMilestoneNotification (future notification to be added in TMF ) to make the implementation clean.

Thanks,
Rati

------------------------------
Rati Mehrotra
Telstra Corporation


Original Message:
Sent: May 27, 2020 03:17
From: Ludovic Robert
Subject: PONR for the service OrderManagement

Hello Rati, Jonathan

About the PONR we introduced in the latest version (coming soon) an alternative way to handle it by providing a specific operation to request an order cancel. This is a distinct resource from the service order itself. This will allow client side to request a cancel and for server side to assessif the order is canceable (if it did not yet reach the PONR).

We not have request as of now to to introduce a specific PONR attribute. I'm not sure if it should be at item or order level (perhaps both - order level calculated from item ones).  I'm sharing Jonathan proposal - Note that state are "extensible" and you can define a inProgress.PoNEReached state in your implem.

Hope it helps

Ludovic

------------------------------
Ludovic Robert
Orange
My answer are my own & don't represent necessarily my company or the TMF


Original Message:
Sent: May 27, 2020 02:10
From: Jonathan Goldberg
Subject: PONR for the service OrderManagement

Wouldn't this be a status change notification? Assuming that the order changes state after the Point of No Return (PoNR) is reached, a consumer who subscribed to these notifications would be expected to get this. Both Order and Order Item have a state attribute so an API implementation could send such a notification at both levels.

Main block is that the state is defined as an enum, and I don't think that there is an appropriate value for passing PoNR.

An alternative approach would be to add an explicit attribute (perhaps boolean) reachedPoNR, and then have an attribute change notification.

Over to you @Ludovic Robert for further comment​​.

Hope it helps

------------------------------
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.

Hi there,

Can we not use Service Restriction,  We can introduce a new value for Service State called PONR.

Also, I feel PONR should be dedicated service call  when we initiate the Amend, and this info should not be persisted anywhere in the calling system

Regards
Samarth

------------------------------
samarth devadas
Tata Consultancy Services
------------------------------

Original Message:
Sent: May 28, 2020 02:08
From: Rati Mehrotra
Subject: PONR for the service OrderManagement

Hi @Ludovic Robert ,

In regards to the cancel transaction introduced as part of TMF 641 v4,  its the assessment of PONR  for a request originating from the  consumer.  The scenario that we have is the provider reaches a PoNR in its fulfilment journey and want to send a PoNR notification to consumer.

The option suggested above are

• Adding inProgress.PONR  -  This option will complicate the state machine to depict any failure in terms of InProgress.PoNR-> Failed and other states. If we follow this option, i assume that we will have to send a StateValueChangeNotification with state as inProgress.PoNR
• Adding PoNR specific attribute - This would require TMF to add this attribute in the future enhancements and provider can generate AttributeValueChangeNotification or we can also think of adding PoNR as a milestone and send  serviceOrderMilestoneNotification (future notification to be added in TMF ) to make the implementation clean.

Thanks,
Rati

------------------------------
Rati Mehrotra
Telstra Corporation
------------------------------


Original Message:
Sent: May 27, 2020 03:17
From: Ludovic Robert
Subject: PONR for the service OrderManagement

Hello Rati, Jonathan

About the PONR we introduced in the latest version (coming soon) an alternative way to handle it by providing a specific operation to request an order cancel. This is a distinct resource from the service order itself. This will allow client side to request a cancel and for server side to assessif the order is canceable (if it did not yet reach the PONR).

We not have request as of now to to introduce a specific PONR attribute. I'm not sure if it should be at item or order level (perhaps both - order level calculated from item ones).  I'm sharing Jonathan proposal - Note that state are "extensible" and you can define a inProgress.PoNEReached state in your implem.

Hope it helps

Ludovic

------------------------------
Ludovic Robert
Orange
My answer are my own & don't represent necessarily my company or the TMF


Original Message:
Sent: May 27, 2020 02:10
From: Jonathan Goldberg
Subject: PONR for the service OrderManagement

Wouldn't this be a status change notification? Assuming that the order changes state after the Point of No Return (PoNR) is reached, a consumer who subscribed to these notifications would be expected to get this. Both Order and Order Item have a state attribute so an API implementation could send such a notification at both levels.

Main block is that the state is defined as an enum, and I don't think that there is an appropriate value for passing PoNR.

An alternative approach would be to add an explicit attribute (perhaps boolean) reachedPoNR, and then have an attribute change notification.

Over to you @Ludovic Robert for further comment​​.

Hope it helps

------------------------------
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.

@Rati Mehrotra How did you finally implemented it and do you got any challenge?
​

------------------------------
Prateek Mathur
Infosys
------------------------------

Original Message:
Sent: May 28, 2020 02:08
From: Rati Mehrotra
Subject: PONR for the service OrderManagement

Hi @Ludovic Robert ,

In regards to the cancel transaction introduced as part of TMF 641 v4,  its the assessment of PONR  for a request originating from the  consumer.  The scenario that we have is the provider reaches a PoNR in its fulfilment journey and want to send a PoNR notification to consumer.

The option suggested above are

• Adding inProgress.PONR  -  This option will complicate the state machine to depict any failure in terms of InProgress.PoNR-> Failed and other states. If we follow this option, i assume that we will have to send a StateValueChangeNotification with state as inProgress.PoNR
• Adding PoNR specific attribute - This would require TMF to add this attribute in the future enhancements and provider can generate AttributeValueChangeNotification or we can also think of adding PoNR as a milestone and send  serviceOrderMilestoneNotification (future notification to be added in TMF ) to make the implementation clean.

Thanks,
Rati

------------------------------
Rati Mehrotra
Telstra Corporation
------------------------------


Original Message:
Sent: May 27, 2020 03:17
From: Ludovic Robert
Subject: PONR for the service OrderManagement

Hello Rati, Jonathan

About the PONR we introduced in the latest version (coming soon) an alternative way to handle it by providing a specific operation to request an order cancel. This is a distinct resource from the service order itself. This will allow client side to request a cancel and for server side to assessif the order is canceable (if it did not yet reach the PONR).

We not have request as of now to to introduce a specific PONR attribute. I'm not sure if it should be at item or order level (perhaps both - order level calculated from item ones).  I'm sharing Jonathan proposal - Note that state are "extensible" and you can define a inProgress.PoNEReached state in your implem.

Hope it helps

Ludovic

------------------------------
Ludovic Robert
Orange
My answer are my own & don't represent necessarily my company or the TMF


Original Message:
Sent: May 27, 2020 02:10
From: Jonathan Goldberg
Subject: PONR for the service OrderManagement

Wouldn't this be a status change notification? Assuming that the order changes state after the Point of No Return (PoNR) is reached, a consumer who subscribed to these notifications would be expected to get this. Both Order and Order Item have a state attribute so an API implementation could send such a notification at both levels.

Main block is that the state is defined as an enum, and I don't think that there is an appropriate value for passing PoNR.

An alternative approach would be to add an explicit attribute (perhaps boolean) reachedPoNR, and then have an attribute change notification.

Over to you @Ludovic Robert for further comment​​.

Hope it helps

------------------------------
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.

Hi Prateek, 

We are using the notification ServiceOrderMilestoneEvent  to inform  consumers that PoNR is reached. 

Thanks
Rati

------------------------------
Rati Mehrotra
Telstra Corporation
------------------------------

Original Message:
Sent: Jan 15, 2022 07:38
From: Prateek Mathur
Subject: PONR for the service OrderManagement

@Rati Mehrotra How did you finally implemented it and do you got any challenge?
​

------------------------------
Prateek Mathur
Infosys
------------------------------


Original Message:
Sent: May 28, 2020 02:08
From: Rati Mehrotra
Subject: PONR for the service OrderManagement

Hi @Ludovic Robert ,

In regards to the cancel transaction introduced as part of TMF 641 v4,  its the assessment of PONR  for a request originating from the  consumer.  The scenario that we have is the provider reaches a PoNR in its fulfilment journey and want to send a PoNR notification to consumer.

The option suggested above are

• Adding inProgress.PONR  -  This option will complicate the state machine to depict any failure in terms of InProgress.PoNR-> Failed and other states. If we follow this option, i assume that we will have to send a StateValueChangeNotification with state as inProgress.PoNR
• Adding PoNR specific attribute - This would require TMF to add this attribute in the future enhancements and provider can generate AttributeValueChangeNotification or we can also think of adding PoNR as a milestone and send  serviceOrderMilestoneNotification (future notification to be added in TMF ) to make the implementation clean.

Thanks,
Rati

------------------------------
Rati Mehrotra
Telstra Corporation


Original Message:
Sent: May 27, 2020 03:17
From: Ludovic Robert
Subject: PONR for the service OrderManagement

Hello Rati, Jonathan

About the PONR we introduced in the latest version (coming soon) an alternative way to handle it by providing a specific operation to request an order cancel. This is a distinct resource from the service order itself. This will allow client side to request a cancel and for server side to assessif the order is canceable (if it did not yet reach the PONR).

We not have request as of now to to introduce a specific PONR attribute. I'm not sure if it should be at item or order level (perhaps both - order level calculated from item ones).  I'm sharing Jonathan proposal - Note that state are "extensible" and you can define a inProgress.PoNEReached state in your implem.

Hope it helps

Ludovic

------------------------------
Ludovic Robert
Orange
My answer are my own & don't represent necessarily my company or the TMF


Original Message:
Sent: May 27, 2020 02:10
From: Jonathan Goldberg
Subject: PONR for the service OrderManagement

Wouldn't this be a status change notification? Assuming that the order changes state after the Point of No Return (PoNR) is reached, a consumer who subscribed to these notifications would be expected to get this. Both Order and Order Item have a state attribute so an API implementation could send such a notification at both levels.

Main block is that the state is defined as an enum, and I don't think that there is an appropriate value for passing PoNR.

An alternative approach would be to add an explicit attribute (perhaps boolean) reachedPoNR, and then have an attribute change notification.

Over to you @Ludovic Robert for further comment​​.

Hope it helps

------------------------------
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.

@Rati, thanks then did you introduce any new attribute called PONR  or some date field where you pushed the PONR date.​or did you extended milestone type to pass the PONR Date? or did you just pass the milestone status flag only like inprogress.PONR ?

------------------------------
Prateek Mathur
Infosys
------------------------------

Original Message:
Sent: Jan 16, 2022 18:25
From: Rati Mehrotra
Subject: PONR for the service OrderManagement

Hi Prateek,

We are using the notification ServiceOrderMilestoneEvent  to inform  consumers that PoNR is reached.

Thanks
Rati

------------------------------
Rati Mehrotra
Telstra Corporation
------------------------------


Original Message:
Sent: Jan 15, 2022 07:38
From: Prateek Mathur
Subject: PONR for the service OrderManagement

@Rati Mehrotra How did you finally implemented it and do you got any challenge?
​

------------------------------
Prateek Mathur
Infosys


Original Message:
Sent: May 28, 2020 02:08
From: Rati Mehrotra
Subject: PONR for the service OrderManagement

Hi @Ludovic Robert ,

In regards to the cancel transaction introduced as part of TMF 641 v4,  its the assessment of PONR  for a request originating from the  consumer.  The scenario that we have is the provider reaches a PoNR in its fulfilment journey and want to send a PoNR notification to consumer.

The option suggested above are

• Adding inProgress.PONR  -  This option will complicate the state machine to depict any failure in terms of InProgress.PoNR-> Failed and other states. If we follow this option, i assume that we will have to send a StateValueChangeNotification with state as inProgress.PoNR
• Adding PoNR specific attribute - This would require TMF to add this attribute in the future enhancements and provider can generate AttributeValueChangeNotification or we can also think of adding PoNR as a milestone and send  serviceOrderMilestoneNotification (future notification to be added in TMF ) to make the implementation clean.

Thanks,
Rati

------------------------------
Rati Mehrotra
Telstra Corporation


Original Message:
Sent: May 27, 2020 03:17
From: Ludovic Robert
Subject: PONR for the service OrderManagement

Hello Rati, Jonathan

About the PONR we introduced in the latest version (coming soon) an alternative way to handle it by providing a specific operation to request an order cancel. This is a distinct resource from the service order itself. This will allow client side to request a cancel and for server side to assessif the order is canceable (if it did not yet reach the PONR).

We not have request as of now to to introduce a specific PONR attribute. I'm not sure if it should be at item or order level (perhaps both - order level calculated from item ones).  I'm sharing Jonathan proposal - Note that state are "extensible" and you can define a inProgress.PoNEReached state in your implem.

Hope it helps

Ludovic

------------------------------
Ludovic Robert
Orange
My answer are my own & don't represent necessarily my company or the TMF


Original Message:
Sent: May 27, 2020 02:10
From: Jonathan Goldberg
Subject: PONR for the service OrderManagement

Wouldn't this be a status change notification? Assuming that the order changes state after the Point of No Return (PoNR) is reached, a consumer who subscribed to these notifications would be expected to get this. Both Order and Order Item have a state attribute so an API implementation could send such a notification at both levels.

Main block is that the state is defined as an enum, and I don't think that there is an appropriate value for passing PoNR.

An alternative approach would be to add an explicit attribute (perhaps boolean) reachedPoNR, and then have an attribute change notification.

Over to you @Ludovic Robert for further comment​​.

Hope it helps

------------------------------
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.

Hi Rati,

Thanks for sharing that you're using the ServiceOrderMilestoneEvent when a service order reaches the Point of No Return (PoNR).

Could you provide details the following:

1.  How do you define the milestone that represents PoNR? Is it a specific name or code in the event payload?
2. What logic or conditions do you use to determine that PoNR has been reached?
3. How do consumers (like OM systems) interpret this milestone? Do you use any standard or custom field to indicate PoNR explicitly?
4. In case the milestone event is missed, is there any other mechanism to check PoNR status?

Thanks

Irfak Ahmad

Amdocs

------------------------------
Irfak Ahmad
Amdocs Management Limited
------------------------------

Original Message:
Sent: Jan 16, 2022 18:25
From: Rati Mehrotra
Subject: PONR for the service OrderManagement

Hi Prateek, 

We are using the notification ServiceOrderMilestoneEvent  to inform  consumers that PoNR is reached. 

Thanks
Rati

------------------------------
Rati Mehrotra
Telstra Corporation
------------------------------


Original Message:
Sent: Jan 15, 2022 07:38
From: Prateek Mathur
Subject: PONR for the service OrderManagement

@Rati Mehrotra How did you finally implemented it and do you got any challenge?
​

------------------------------
Prateek Mathur
Infosys


Original Message:
Sent: May 28, 2020 02:08
From: Rati Mehrotra
Subject: PONR for the service OrderManagement

Hi @Ludovic Robert ,

In regards to the cancel transaction introduced as part of TMF 641 v4,  its the assessment of PONR  for a request originating from the  consumer.  The scenario that we have is the provider reaches a PoNR in its fulfilment journey and want to send a PoNR notification to consumer.

The option suggested above are

• Adding inProgress.PONR  -  This option will complicate the state machine to depict any failure in terms of InProgress.PoNR-> Failed and other states. If we follow this option, i assume that we will have to send a StateValueChangeNotification with state as inProgress.PoNR
• Adding PoNR specific attribute - This would require TMF to add this attribute in the future enhancements and provider can generate AttributeValueChangeNotification or we can also think of adding PoNR as a milestone and send  serviceOrderMilestoneNotification (future notification to be added in TMF ) to make the implementation clean.

Thanks,
Rati

------------------------------
Rati Mehrotra
Telstra Corporation


Original Message:
Sent: May 27, 2020 03:17
From: Ludovic Robert
Subject: PONR for the service OrderManagement

Hello Rati, Jonathan

About the PONR we introduced in the latest version (coming soon) an alternative way to handle it by providing a specific operation to request an order cancel. This is a distinct resource from the service order itself. This will allow client side to request a cancel and for server side to assessif the order is canceable (if it did not yet reach the PONR).

We not have request as of now to to introduce a specific PONR attribute. I'm not sure if it should be at item or order level (perhaps both - order level calculated from item ones).  I'm sharing Jonathan proposal - Note that state are "extensible" and you can define a inProgress.PoNEReached state in your implem.

Hope it helps

Ludovic

------------------------------
Ludovic Robert
Orange
My answer are my own & don't represent necessarily my company or the TMF


Original Message:
Sent: May 27, 2020 02:10
From: Jonathan Goldberg
Subject: PONR for the service OrderManagement

Wouldn't this be a status change notification? Assuming that the order changes state after the Point of No Return (PoNR) is reached, a consumer who subscribed to these notifications would be expected to get this. Both Order and Order Item have a state attribute so an API implementation could send such a notification at both levels.

Main block is that the state is defined as an enum, and I don't think that there is an appropriate value for passing PoNR.

An alternative approach would be to add an explicit attribute (perhaps boolean) reachedPoNR, and then have an attribute change notification.

Over to you @Ludovic Robert for further comment​​.

Hope it helps

------------------------------
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.

Wouldn't it be enough to have at Service Order level rather than service order item level?

------------------------------
Srikanth Minnam
Qvantel Oy
------------------------------

Original Message:
Sent: May 27, 2020 02:10
From: Jonathan Goldberg
Subject: PONR for the service OrderManagement

Wouldn't this be a status change notification? Assuming that the order changes state after the Point of No Return (PoNR) is reached, a consumer who subscribed to these notifications would be expected to get this. Both Order and Order Item have a state attribute so an API implementation could send such a notification at both levels.

Main block is that the state is defined as an enum, and I don't think that there is an appropriate value for passing PoNR.

An alternative approach would be to add an explicit attribute (perhaps boolean) reachedPoNR, and then have an attribute change notification.

Over to you @Ludovic Robert for further comment​​.

Hope it helps

------------------------------
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.
------------------------------