Open APIs

Hello community,

TMF622, TMF641, TMF652: When an Order is received with requestedStartDate in the future, it should be deferred to the requested time.
The Order requester should receive normal 201 (Created).

Question 1:

Which state should be used for deferred Orders?

The "acknowledged" state can't help to separate deferred Orders for a special report.
The "pending" state looks the most suitable, but is described as "... used when an order is currently in a waiting stage for an action/activity to be completed before the order can progress further".

If "pending" is the correct answer, then description should probably be updated in all 3 APIs.

Or maybe a new "scheduled" or "deferred" state would be more appropriate here.

Question 2:

In case if the correct state is "Pending", which state should be returned to requester in synchronous 201 (Created) response?

a. "pending"

b. "acknowledged" and then orderStateChange notification with "pending"

Question 3:

What if a delayed Order has been scheduled for a long time, and when the time has come, the Order can no longer be processed due to some changes (inventory, catalog, relatedParty, etc.)? Should this order be "failed" without any additional information? I mean, 'orderStateChange' notification can't help with the details.

Question 4:

Is this attribute expected on order items in further updates after this and this discussions?

------------------------------
Igor Veliev
Netcracker Technology
------------------------------

Hello Igor,
For 1. you have a couple of options - from my understanding you can extend TMF core state lifecycle. As you mention you can add a whole new state in your implem but also you can extend provided ones. It is possible for example to have acknowledged.scheduled state (& substate). This pattern allow by the way in GET operation to specifically look for scheduled order (or have all 'acknowledged ').

for 2. I tend to think to always provide consistent lifecycle to the client side. If you stick to TMF one you probably have to go with b.

for 3. First we have to align productOrder lifecycle with serviceOrder one. We should be able to move to rejected from acknowledged. Once done that if you use the proposal based on  acknowledged.scheduled then you can switch to rejected - if you use pending.scheduled you can go to failed. For me it depends on your requirement.
One additionnal point : please take a look on the service order v4.1 enhancements... we introduced jeopardy/mileStone/errorMessage features and this is probably a good idea to have these also in product order moving to next release - thought ?

For 4....will need additional time to take a look.

Hope it helps

Ludovic

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

Thanks for the quick reply, Ludovic

>> One additionnal point : please take a look on the service order v4.1 enhancements... we introduced jeopardy/mileStone/errorMessage features and this is probably a good idea to have these also in product order moving to next release - thought ?

I couldn't find any details about the innovations of the service ordering 4.1, unfortunately, but I certainly share your opinion of having jeopardy/mileStone/ErrorMessage features in the product ordering too.

I see your point in possible ways of scheduled orders handling, but it seems to me that the TMF API could well recommend states to support scheduled orders and related acknowledge response behavior, in order to avoid possible discrepancies between vendors of neighboring systems, such as CPQ and OM.

------------------------------
Igor Veliev
Netcracker Technology
------------------------------

Original Message:
Sent: Jan 26, 2021 03:01
From: Ludovic Robert
Subject: requestedStartDate related questions: state, items, etc.

Hello Igor,
For 1. you have a couple of options - from my understanding you can extend TMF core state lifecycle. As you mention you can add a whole new state in your implem but also you can extend provided ones. It is possible for example to have acknowledged.scheduled state (& substate). This pattern allow by the way in GET operation to specifically look for scheduled order (or have all 'acknowledged ').

for 2. I tend to think to always provide consistent lifecycle to the client side. If you stick to TMF one you probably have to go with b.

for 3. First we have to align productOrder lifecycle with serviceOrder one. We should be able to move to rejected from acknowledged. Once done that if you use the proposal based on  acknowledged.scheduled then you can switch to rejected - if you use pending.scheduled you can go to failed. For me it depends on your requirement.
One additionnal point : please take a look on the service order v4.1 enhancements... we introduced jeopardy/mileStone/errorMessage features and this is probably a good idea to have these also in product order moving to next release - thought ?

For 4....will need additional time to take a look.

Hope it helps

Ludovic

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

Hi Igor,
I checked ... currently serviceOrder v4.1 is in internal team review. It is available in the TMF API project for members.

For the second topic this is a broader discussion. We're working to defined extension rules to allow API specialization (Design context Schema) depending on the context. Part of this is to define some guidance/rule about 'core' state & transition and extension pattern.

Hope it helps,
Ludovic

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

Original Message:
Sent: Jan 26, 2021 05:42
From: Igor Veliev
Subject: requestedStartDate related questions: state, items, etc.

Thanks for the quick reply, Ludovic

>> One additionnal point : please take a look on the service order v4.1 enhancements... we introduced jeopardy/mileStone/errorMessage features and this is probably a good idea to have these also in product order moving to next release - thought ?

I couldn't find any details about the innovations of the service ordering 4.1, unfortunately, but I certainly share your opinion of having jeopardy/mileStone/ErrorMessage features in the product ordering too.

I see your point in possible ways of scheduled orders handling, but it seems to me that the TMF API could well recommend states to support scheduled orders and related acknowledge response behavior, in order to avoid possible discrepancies between vendors of neighboring systems, such as CPQ and OM.

------------------------------
Igor Veliev
Netcracker Technology
------------------------------


Original Message:
Sent: Jan 26, 2021 03:01
From: Ludovic Robert
Subject: requestedStartDate related questions: state, items, etc.

Hello Igor,
For 1. you have a couple of options - from my understanding you can extend TMF core state lifecycle. As you mention you can add a whole new state in your implem but also you can extend provided ones. It is possible for example to have acknowledged.scheduled state (& substate). This pattern allow by the way in GET operation to specifically look for scheduled order (or have all 'acknowledged ').

for 2. I tend to think to always provide consistent lifecycle to the client side. If you stick to TMF one you probably have to go with b.

for 3. First we have to align productOrder lifecycle with serviceOrder one. We should be able to move to rejected from acknowledged. Once done that if you use the proposal based on  acknowledged.scheduled then you can switch to rejected - if you use pending.scheduled you can go to failed. For me it depends on your requirement.
One additionnal point : please take a look on the service order v4.1 enhancements... we introduced jeopardy/mileStone/errorMessage features and this is probably a good idea to have these also in product order moving to next release - thought ?

For 4....will need additional time to take a look.

Hope it helps

Ludovic

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

Hi Igor,

I guess you have already evaluated the option of using a compound condition for generating the report about deferred orders:
        state=Acknowledged and ​requestedStartDate > now

What is the drawback in that approach? Can you please share your view?

Regards,

------------------------------
Şanver Narin
PiA-TEAM INC.
------------------------------

Original Message:
Sent: Jan 27, 2021 04:47
From: Ludovic Robert
Subject: requestedStartDate related questions: state, items, etc.

Hi Igor,
I checked ... currently serviceOrder v4.1 is in internal team review. It is available in the TMF API project for members.

For the second topic this is a broader discussion. We're working to defined extension rules to allow API specialization (Design context Schema) depending on the context. Part of this is to define some guidance/rule about 'core' state & transition and extension pattern.

Hope it helps,
Ludovic

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


Original Message:
Sent: Jan 26, 2021 05:42
From: Igor Veliev
Subject: requestedStartDate related questions: state, items, etc.

Thanks for the quick reply, Ludovic

>> One additionnal point : please take a look on the service order v4.1 enhancements... we introduced jeopardy/mileStone/errorMessage features and this is probably a good idea to have these also in product order moving to next release - thought ?

I couldn't find any details about the innovations of the service ordering 4.1, unfortunately, but I certainly share your opinion of having jeopardy/mileStone/ErrorMessage features in the product ordering too.

I see your point in possible ways of scheduled orders handling, but it seems to me that the TMF API could well recommend states to support scheduled orders and related acknowledge response behavior, in order to avoid possible discrepancies between vendors of neighboring systems, such as CPQ and OM.

------------------------------
Igor Veliev
Netcracker Technology


Original Message:
Sent: Jan 26, 2021 03:01
From: Ludovic Robert
Subject: requestedStartDate related questions: state, items, etc.

Hello Igor,
For 1. you have a couple of options - from my understanding you can extend TMF core state lifecycle. As you mention you can add a whole new state in your implem but also you can extend provided ones. It is possible for example to have acknowledged.scheduled state (& substate). This pattern allow by the way in GET operation to specifically look for scheduled order (or have all 'acknowledged ').

for 2. I tend to think to always provide consistent lifecycle to the client side. If you stick to TMF one you probably have to go with b.

for 3. First we have to align productOrder lifecycle with serviceOrder one. We should be able to move to rejected from acknowledged. Once done that if you use the proposal based on  acknowledged.scheduled then you can switch to rejected - if you use pending.scheduled you can go to failed. For me it depends on your requirement.
One additionnal point : please take a look on the service order v4.1 enhancements... we introduced jeopardy/mileStone/errorMessage features and this is probably a good idea to have these also in product order moving to next release - thought ?

For 4....will need additional time to take a look.

Hope it helps

Ludovic

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