Open APIs

Dear colleagues, 
we are facing with very challenging question - some time ago our company suggested several services that can be switched on/off in future:) 

E.g customer decided to ago abroad and he/she added 2 services:
- free service "International roaming"  (effective NOW),
- payed service "Discount for international roaming" , but this service should be switched on (for example) 1st May and switched of 10th May 2019. 
Customer wants to save money so added a discount only for roaming period (in the future).

I studied TMF_622 "Product Ordering" - and think that this is a clearly ProductOrder with 2 OrderItems (action="add" in both OrderItems). ProductOrder as an entity will have an orderDate={NOW} , but that about date?? Unfortunately OrderItem don't have the date...
I would suggest adding "actionDate" attribute to OrderItem - so this would solve my problem.

Also this would add flexibility -  items could have different dates not necessarily equal to ProductOrder.orderDate. 

Will be very helpful for comments and suggestions.

------------------------------
Vadim Nechaev
Senior systems architect
MTS Group HQ
------------------------------

Original Message------

Dear colleagues, 
we are facing with very challenging question - some time ago our company suggested several services that can be switched on/off in future:) 

E.g customer decided to ago abroad and he/she added 2 services:
- free service "International roaming"  (effective NOW),
- payed service "Discount for international roaming" , but this service should be switched on (for example) 1st May and switched of 10th May 2019. 
Customer wants to save money so added a discount only for roaming period (in the future).

I studied TMF_622 "Product Ordering" - and think that this is a clearly ProductOrder with 2 OrderItems (action="add" in both OrderItems). ProductOrder as an entity will have an orderDate={NOW} , but that about date?? Unfortunately OrderItem don't have the date...
I would suggest adding "actionDate" attribute to OrderItem - so this would solve my problem.

Also this would add flexibility -  items could have different dates not necessarily equal to ProductOrder.orderDate. 

Will be very helpful for comments and suggestions.

------------------------------
Vadim Nechaev
Senior systems architect
MTS Group HQ
------------------------------

Hi, Koenraad

Thank you very much for your reply!
Using requestedCompletionDate attribute may be a very good idea. But i see some minor disadvantages of this approach: 

1. Suppose that we should add a service at a given date and time  (e.g 15.15). The name of attribute is "requestedCompletionDate" - i thought that this does mean that calling system requested this date as the date when processing of this order should be completed. This is not necessarily the date of the actual service start. 

So could be a time interval between finishing of the process and service start. May be i am wrong and confused by attribute name?

2. A little bit strange that customer made one order (in our CRM this is actually one order, not 3) but in business logic we got 3 orders.
Moreover, it depends: if we have the services that should be effective NOW - then we got one order; if we have services that should be effective/turned off in future - then we should group all the orders by the dates (as an SQL "group by" operator:)) and we got as much orders as how many different groups. 
I think that this grouping can complicate business logic of BSS/OSS. 

3. If we produced 3 orders instead one then i suppose that the first order is the parent and second/third are the children.  So in ProductOrder class should be a link (parent_id) to the main order, but i think there are no such an attribute. Anyway we should be able to link the main order with sub-orders. 

Thank you for your ideas/suggestions!

------------------------------
Vadim Nechaev
Senior systems architect
MTS Group HQ
------------------------------

Original Message:
Sent: Feb 25, 2019 02:55
From: Koenraad Peeters
Subject: Delayed actions and OrderItem

Hi Vadim,

Your challenge is not uncommon.

The problem is that we tend to think that all these complex customer requests must fit in one order because the customer requests them in one communication.

It is however easy to accomplish the requested scenario using 3 productOrders.

• PO1
• item 1 : action: add, ProductOffering: International roaming
• returns orderDate: {now}, ProductId: A
• PO2 (requestedCompletionDate: 1st May)
• item 1 : action: add, ProductOffering: Discount for roaming, dependsOn ProductId A
• returns orderDate: {now}, expectedCompletionDate: 1st May, ProductId B
• PO3 (requestedCompletionDate: 10th May
• item 1 : action: delete, ProductId: B
• returns orderDate: {now}, expectedCompletionDate: 10th May, ProductId B

Using this model you have one productOrder for each action with an associated completion date required. It also makes sure that order handling stays straight forward and can be purely catalog driven.

This also has an added advantage to agility. It now becomes possible to define an SMS message 'Day Roamer ON' and 'Day Roamer OFF' that generate PO2 and PO3.

Your CRM only needs to create PO1 and PO2 & PO3 can be triggered by the customer using the SMS (or a Portal for that matter) for self service.

Regards

Koen Peeters

koen.peeters@ciminko.lu

Original Message------

Dear colleagues,
we are facing with very challenging question - some time ago our company suggested several services that can be switched on/off in future:)

E.g customer decided to ago abroad and he/she added 2 services:
- free service "International roaming"  (effective NOW),
- payed service "Discount for international roaming" , but this service should be switched on (for example) 1st May and switched of 10th May 2019.
Customer wants to save money so added a discount only for roaming period (in the future).

I studied TMF_622 "Product Ordering" - and think that this is a clearly ProductOrder with 2 OrderItems (action="add" in both OrderItems). ProductOrder as an entity will have an orderDate={NOW} , but that about date?? Unfortunately OrderItem don't have the date...
I would suggest adding "actionDate" attribute to OrderItem - so this would solve my problem.

Also this would add flexibility -  items could have different dates not necessarily equal to ProductOrder.orderDate.

Will be very helpful for comments and suggestions.

------------------------------
Vadim Nechaev
Senior systems architect
MTS Group HQ
------------------------------

I personally believe that the ProductOrder should represent the end-customer's view of the transaction - from her perspective she made a single request with multiple items. This could certainly be decomposed into multiple ServiceOrders (if this makes sense from the telco's perspective).
Therefore I would support adding a requestedCompletionDate to the OrderItem sub-resource.
Adding @Ludovic Robert who leads this API.​

------------------------------
Jonathan Goldberg
Amdocs Management Limited
------------------------------

Original Message:
Sent: Feb 25, 2019 11:09
From: Vadim Nechaev
Subject: Delayed actions and OrderItem

Hi, Koenraad

Thank you very much for your reply!
Using requestedCompletionDate attribute may be a very good idea. But i see some minor disadvantages of this approach:

1. Suppose that we should add a service at a given date and time  (e.g 15.15). The name of attribute is "requestedCompletionDate" - i thought that this does mean that calling system requested this date as the date when processing of this order should be completed. This is not necessarily the date of the actual service start.

So could be a time interval between finishing of the process and service start. May be i am wrong and confused by attribute name?

2. A little bit strange that customer made one order (in our CRM this is actually one order, not 3) but in business logic we got 3 orders.
Moreover, it depends: if we have the services that should be effective NOW - then we got one order; if we have services that should be effective/turned off in future - then we should group all the orders by the dates (as an SQL "group by" operator:)) and we got as much orders as how many different groups.
I think that this grouping can complicate business logic of BSS/OSS.

3. If we produced 3 orders instead one then i suppose that the first order is the parent and second/third are the children.  So in ProductOrder class should be a link (parent_id) to the main order, but i think there are no such an attribute. Anyway we should be able to link the main order with sub-orders.

Thank you for your ideas/suggestions!

------------------------------
Vadim Nechaev
Senior systems architect
MTS Group HQ

Original Message:
Sent: Feb 25, 2019 02:55
From: Koenraad Peeters
Subject: Delayed actions and OrderItem

Hi Vadim,

Your challenge is not uncommon.

The problem is that we tend to think that all these complex customer requests must fit in one order because the customer requests them in one communication.

It is however easy to accomplish the requested scenario using 3 productOrders.

• PO1
• item 1 : action: add, ProductOffering: International roaming
• returns orderDate: {now}, ProductId: A
• PO2 (requestedCompletionDate: 1st May)
• item 1 : action: add, ProductOffering: Discount for roaming, dependsOn ProductId A
• returns orderDate: {now}, expectedCompletionDate: 1st May, ProductId B
• PO3 (requestedCompletionDate: 10th May
• item 1 : action: delete, ProductId: B
• returns orderDate: {now}, expectedCompletionDate: 10th May, ProductId B

Using this model you have one productOrder for each action with an associated completion date required. It also makes sure that order handling stays straight forward and can be purely catalog driven.

This also has an added advantage to agility. It now becomes possible to define an SMS message 'Day Roamer ON' and 'Day Roamer OFF' that generate PO2 and PO3.

Your CRM only needs to create PO1 and PO2 & PO3 can be triggered by the customer using the SMS (or a Portal for that matter) for self service.

Regards

Koen Peeters

koen.peeters@ciminko.lu

Original Message------

Dear colleagues,
we are facing with very challenging question - some time ago our company suggested several services that can be switched on/off in future:)

E.g customer decided to ago abroad and he/she added 2 services:
- free service "International roaming"  (effective NOW),
- payed service "Discount for international roaming" , but this service should be switched on (for example) 1st May and switched of 10th May 2019.
Customer wants to save money so added a discount only for roaming period (in the future).

I studied TMF_622 "Product Ordering" - and think that this is a clearly ProductOrder with 2 OrderItems (action="add" in both OrderItems). ProductOrder as an entity will have an orderDate={NOW} , but that about date?? Unfortunately OrderItem don't have the date...
I would suggest adding "actionDate" attribute to OrderItem - so this would solve my problem.

Also this would add flexibility -  items could have different dates not necessarily equal to ProductOrder.orderDate.

Will be very helpful for comments and suggestions.

------------------------------
Vadim Nechaev
Senior systems architect
MTS Group HQ
------------------------------

Hello

This is not one date to be added at item level but three:

• requestedCompletionDate
• expectedCompletionDate
• completionDate

Perhaps requestedStartDate should follow the same.

And then if we have these dates at both level what is the understanding if they are filled at both level ? Do we need to have explicit rules ?

Safer option is to log a JIRA and discuss this in API gouvernance meeting.

Best regards
Ludovic

------------------------------
Ludovic Robert
Orange
------------------------------

Original Message:
Sent: Feb 26, 2019 04:33
From: Jonathan Goldberg
Subject: Delayed actions and OrderItem

I personally believe that the ProductOrder should represent the end-customer's view of the transaction - from her perspective she made a single request with multiple items. This could certainly be decomposed into multiple ServiceOrders (if this makes sense from the telco's perspective).
Therefore I would support adding a requestedCompletionDate to the OrderItem sub-resource.
Adding @Ludovic Robert who leads this API.​

------------------------------
Jonathan Goldberg
Amdocs Management Limited

Original Message:
Sent: Feb 25, 2019 11:09
From: Vadim Nechaev
Subject: Delayed actions and OrderItem

Hi, Koenraad

Thank you very much for your reply!
Using requestedCompletionDate attribute may be a very good idea. But i see some minor disadvantages of this approach:

1. Suppose that we should add a service at a given date and time  (e.g 15.15). The name of attribute is "requestedCompletionDate" - i thought that this does mean that calling system requested this date as the date when processing of this order should be completed. This is not necessarily the date of the actual service start.

So could be a time interval between finishing of the process and service start. May be i am wrong and confused by attribute name?

2. A little bit strange that customer made one order (in our CRM this is actually one order, not 3) but in business logic we got 3 orders.
Moreover, it depends: if we have the services that should be effective NOW - then we got one order; if we have services that should be effective/turned off in future - then we should group all the orders by the dates (as an SQL "group by" operator:)) and we got as much orders as how many different groups.
I think that this grouping can complicate business logic of BSS/OSS.

3. If we produced 3 orders instead one then i suppose that the first order is the parent and second/third are the children.  So in ProductOrder class should be a link (parent_id) to the main order, but i think there are no such an attribute. Anyway we should be able to link the main order with sub-orders.

Thank you for your ideas/suggestions!

------------------------------
Vadim Nechaev
Senior systems architect
MTS Group HQ

Original Message:
Sent: Feb 25, 2019 02:55
From: Koenraad Peeters
Subject: Delayed actions and OrderItem

Hi Vadim,

Your challenge is not uncommon.

The problem is that we tend to think that all these complex customer requests must fit in one order because the customer requests them in one communication.

It is however easy to accomplish the requested scenario using 3 productOrders.

• PO1
• item 1 : action: add, ProductOffering: International roaming
• returns orderDate: {now}, ProductId: A
• PO2 (requestedCompletionDate: 1st May)
• item 1 : action: add, ProductOffering: Discount for roaming, dependsOn ProductId A
• returns orderDate: {now}, expectedCompletionDate: 1st May, ProductId B
• PO3 (requestedCompletionDate: 10th May
• item 1 : action: delete, ProductId: B
• returns orderDate: {now}, expectedCompletionDate: 10th May, ProductId B

Using this model you have one productOrder for each action with an associated completion date required. It also makes sure that order handling stays straight forward and can be purely catalog driven.

This also has an added advantage to agility. It now becomes possible to define an SMS message 'Day Roamer ON' and 'Day Roamer OFF' that generate PO2 and PO3.

Your CRM only needs to create PO1 and PO2 & PO3 can be triggered by the customer using the SMS (or a Portal for that matter) for self service.

Regards

Koen Peeters

koen.peeters@ciminko.lu

Original Message------

Dear colleagues,
we are facing with very challenging question - some time ago our company suggested several services that can be switched on/off in future:)

E.g customer decided to ago abroad and he/she added 2 services:
- free service "International roaming"  (effective NOW),
- payed service "Discount for international roaming" , but this service should be switched on (for example) 1st May and switched of 10th May 2019.
Customer wants to save money so added a discount only for roaming period (in the future).

I studied TMF_622 "Product Ordering" - and think that this is a clearly ProductOrder with 2 OrderItems (action="add" in both OrderItems). ProductOrder as an entity will have an orderDate={NOW} , but that about date?? Unfortunately OrderItem don't have the date...
I would suggest adding "actionDate" attribute to OrderItem - so this would solve my problem.

Also this would add flexibility -  items could have different dates not necessarily equal to ProductOrder.orderDate.

Will be very helpful for comments and suggestions.

------------------------------
Vadim Nechaev
Senior systems architect
MTS Group HQ
------------------------------

Dear colleagues, 
thank you for suggestions and activity!

I suppose that attributes on item level are more specific - so they should override same attributes on ProductOrder level.

------------------------------
Vadim Nechaev
Senior systems architect
MTS Group HQ
------------------------------

Original Message:
Sent: Feb 26, 2019 11:00
From: Ludovic Robert
Subject: Delayed actions and OrderItem

Hello

This is not one date to be added at item level but three:

• requestedCompletionDate
• expectedCompletionDate
• completionDate

Perhaps requestedStartDate should follow the same.

And then if we have these dates at both level what is the understanding if they are filled at both level ? Do we need to have explicit rules ?

Safer option is to log a JIRA and discuss this in API gouvernance meeting.

Best regards
Ludovic

------------------------------
Ludovic Robert
Orange

Original Message:
Sent: Feb 26, 2019 04:33
From: Jonathan Goldberg
Subject: Delayed actions and OrderItem

I personally believe that the ProductOrder should represent the end-customer's view of the transaction - from her perspective she made a single request with multiple items. This could certainly be decomposed into multiple ServiceOrders (if this makes sense from the telco's perspective).
Therefore I would support adding a requestedCompletionDate to the OrderItem sub-resource.
Adding @Ludovic Robert who leads this API.​

------------------------------
Jonathan Goldberg
Amdocs Management Limited

Original Message:
Sent: Feb 25, 2019 11:09
From: Vadim Nechaev
Subject: Delayed actions and OrderItem

Hi, Koenraad

Thank you very much for your reply!
Using requestedCompletionDate attribute may be a very good idea. But i see some minor disadvantages of this approach:

1. Suppose that we should add a service at a given date and time  (e.g 15.15). The name of attribute is "requestedCompletionDate" - i thought that this does mean that calling system requested this date as the date when processing of this order should be completed. This is not necessarily the date of the actual service start.

So could be a time interval between finishing of the process and service start. May be i am wrong and confused by attribute name?

2. A little bit strange that customer made one order (in our CRM this is actually one order, not 3) but in business logic we got 3 orders.
Moreover, it depends: if we have the services that should be effective NOW - then we got one order; if we have services that should be effective/turned off in future - then we should group all the orders by the dates (as an SQL "group by" operator:)) and we got as much orders as how many different groups.
I think that this grouping can complicate business logic of BSS/OSS.

3. If we produced 3 orders instead one then i suppose that the first order is the parent and second/third are the children.  So in ProductOrder class should be a link (parent_id) to the main order, but i think there are no such an attribute. Anyway we should be able to link the main order with sub-orders.

Thank you for your ideas/suggestions!

------------------------------
Vadim Nechaev
Senior systems architect
MTS Group HQ

Original Message:
Sent: Feb 25, 2019 02:55
From: Koenraad Peeters
Subject: Delayed actions and OrderItem

Hi Vadim,

Your challenge is not uncommon.

The problem is that we tend to think that all these complex customer requests must fit in one order because the customer requests them in one communication.

It is however easy to accomplish the requested scenario using 3 productOrders.

• PO1
• item 1 : action: add, ProductOffering: International roaming
• returns orderDate: {now}, ProductId: A
• PO2 (requestedCompletionDate: 1st May)
• item 1 : action: add, ProductOffering: Discount for roaming, dependsOn ProductId A
• returns orderDate: {now}, expectedCompletionDate: 1st May, ProductId B
• PO3 (requestedCompletionDate: 10th May
• item 1 : action: delete, ProductId: B
• returns orderDate: {now}, expectedCompletionDate: 10th May, ProductId B

Using this model you have one productOrder for each action with an associated completion date required. It also makes sure that order handling stays straight forward and can be purely catalog driven.

This also has an added advantage to agility. It now becomes possible to define an SMS message 'Day Roamer ON' and 'Day Roamer OFF' that generate PO2 and PO3.

Your CRM only needs to create PO1 and PO2 & PO3 can be triggered by the customer using the SMS (or a Portal for that matter) for self service.

Regards

Koen Peeters

koen.peeters@ciminko.lu

Original Message------

Dear colleagues,
we are facing with very challenging question - some time ago our company suggested several services that can be switched on/off in future:)

E.g customer decided to ago abroad and he/she added 2 services:
- free service "International roaming"  (effective NOW),
- payed service "Discount for international roaming" , but this service should be switched on (for example) 1st May and switched of 10th May 2019.
Customer wants to save money so added a discount only for roaming period (in the future).

I studied TMF_622 "Product Ordering" - and think that this is a clearly ProductOrder with 2 OrderItems (action="add" in both OrderItems). ProductOrder as an entity will have an orderDate={NOW} , but that about date?? Unfortunately OrderItem don't have the date...
I would suggest adding "actionDate" attribute to OrderItem - so this would solve my problem.

Also this would add flexibility -  items could have different dates not necessarily equal to ProductOrder.orderDate.

Will be very helpful for comments and suggestions.

------------------------------
Vadim Nechaev
Senior systems architect
MTS Group HQ
------------------------------

Hi Jonathan,

I think there is a general problem here: Your opinion is very valid (product orders represent end customer's) view. But there may be other, equally valid views. E.g. the shopping cart may reflect this, and the product order might be the API of the "core commerce" domain taking ODA terms a little literally. 
Or the same API might be exposed by the order fulfillment system.

I think this is an architectural decision that depends on the context. I also think this question can only be resolved defining a "bounded context" as in Domain-Driven Design which specifies the actual semantics of the API, not just the interface as current APIs. 

This semantics needs to be taken by the implementer of the API, e.g. a product vendor or an enterprise etc. If this shall be standardized (as e.g. aimed at in the ODA), different contexts should be defined clarifying the semantics. So the same API format can be used as an interface to levels at different granularities. 

I am sure that this does not increase but decrease the complexity because it reflects the architectural reality more closely.

just my two cents,

Andreas

------------------------------
Andreas Schlueter
NTT DATA CORPORATION
------------------------------

Original Message:
Sent: Feb 26, 2019 04:33
From: Jonathan Goldberg
Subject: Delayed actions and OrderItem

I personally believe that the ProductOrder should represent the end-customer's view of the transaction - from her perspective she made a single request with multiple items. This could certainly be decomposed into multiple ServiceOrders (if this makes sense from the telco's perspective).
Therefore I would support adding a requestedCompletionDate to the OrderItem sub-resource.
Adding @Ludovic Robert who leads this API.​

------------------------------
Jonathan Goldberg
Amdocs Management Limited

Original Message:
Sent: Feb 25, 2019 11:09
From: Vadim Nechaev
Subject: Delayed actions and OrderItem

Hi, Koenraad

Thank you very much for your reply!
Using requestedCompletionDate attribute may be a very good idea. But i see some minor disadvantages of this approach:

1. Suppose that we should add a service at a given date and time  (e.g 15.15). The name of attribute is "requestedCompletionDate" - i thought that this does mean that calling system requested this date as the date when processing of this order should be completed. This is not necessarily the date of the actual service start.

So could be a time interval between finishing of the process and service start. May be i am wrong and confused by attribute name?

2. A little bit strange that customer made one order (in our CRM this is actually one order, not 3) but in business logic we got 3 orders.
Moreover, it depends: if we have the services that should be effective NOW - then we got one order; if we have services that should be effective/turned off in future - then we should group all the orders by the dates (as an SQL "group by" operator:)) and we got as much orders as how many different groups.
I think that this grouping can complicate business logic of BSS/OSS.

3. If we produced 3 orders instead one then i suppose that the first order is the parent and second/third are the children.  So in ProductOrder class should be a link (parent_id) to the main order, but i think there are no such an attribute. Anyway we should be able to link the main order with sub-orders.

Thank you for your ideas/suggestions!

------------------------------
Vadim Nechaev
Senior systems architect
MTS Group HQ

Original Message:
Sent: Feb 25, 2019 02:55
From: Koenraad Peeters
Subject: Delayed actions and OrderItem

Hi Vadim,

Your challenge is not uncommon.

The problem is that we tend to think that all these complex customer requests must fit in one order because the customer requests them in one communication.

It is however easy to accomplish the requested scenario using 3 productOrders.

• PO1
• item 1 : action: add, ProductOffering: International roaming
• returns orderDate: {now}, ProductId: A
• PO2 (requestedCompletionDate: 1st May)
• item 1 : action: add, ProductOffering: Discount for roaming, dependsOn ProductId A
• returns orderDate: {now}, expectedCompletionDate: 1st May, ProductId B
• PO3 (requestedCompletionDate: 10th May
• item 1 : action: delete, ProductId: B
• returns orderDate: {now}, expectedCompletionDate: 10th May, ProductId B

Using this model you have one productOrder for each action with an associated completion date required. It also makes sure that order handling stays straight forward and can be purely catalog driven.

This also has an added advantage to agility. It now becomes possible to define an SMS message 'Day Roamer ON' and 'Day Roamer OFF' that generate PO2 and PO3.

Your CRM only needs to create PO1 and PO2 & PO3 can be triggered by the customer using the SMS (or a Portal for that matter) for self service.

Regards

Koen Peeters

koen.peeters@ciminko.lu

Original Message------

Dear colleagues,
we are facing with very challenging question - some time ago our company suggested several services that can be switched on/off in future:)

E.g customer decided to ago abroad and he/she added 2 services:
- free service "International roaming"  (effective NOW),
- payed service "Discount for international roaming" , but this service should be switched on (for example) 1st May and switched of 10th May 2019.
Customer wants to save money so added a discount only for roaming period (in the future).

I studied TMF_622 "Product Ordering" - and think that this is a clearly ProductOrder with 2 OrderItems (action="add" in both OrderItems). ProductOrder as an entity will have an orderDate={NOW} , but that about date?? Unfortunately OrderItem don't have the date...
I would suggest adding "actionDate" attribute to OrderItem - so this would solve my problem.

Also this would add flexibility -  items could have different dates not necessarily equal to ProductOrder.orderDate.

Will be very helpful for comments and suggestions.

------------------------------
Vadim Nechaev
Senior systems architect
MTS Group HQ
------------------------------