Open APIs

Expand all | Collapse all

Delayed actions and OrderItem

  • 1.  Delayed actions and OrderItem

    Posted Feb 22, 2019 06:09
    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

  • 2.  RE: Delayed actions and OrderItem

    TM Forum Member
    Posted Feb 25, 2019 07:22
    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.


  • 3.  RE: Delayed actions and OrderItem

    Posted Feb 25, 2019 12:02
    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

  • 4.  RE: Delayed actions and OrderItem

    TM Forum Member
    Posted Feb 26, 2019 05:02
    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

  • 5.  RE: Delayed actions and OrderItem

    TM Forum Member
    Posted Feb 26, 2019 11:20

    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 Robert

  • 6.  RE: Delayed actions and OrderItem

    Posted Feb 27, 2019 06:43
    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

  • 7.  RE: Delayed actions and OrderItem

    TM Forum Member
    Posted Feb 27, 2019 06:43
    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 Schlueter