Open APIs

 View Only
  • 1.  Revision/Amend on orders

    TM Forum Member
    Posted Oct 28, 2019 08:42
    ​Hi,

    I was wondering on how we can hold/handle order revision numbers through the API. If i have an order submitted, and the order goes through few amendments, for e.g change in bandwidth, different pricing sub-offering selected etc, it would be useful to mailtain a order history to see what changes were done to the original order.
    Is there a field where i can capture the order revision number? I could not find anything in TMF622 as well.

    ------------------------------
    Sachin Bhaskaran
    Infosys
    ------------------------------


  • 2.  RE: Revision/Amend on orders

    TM Forum Member
    Posted Oct 28, 2019 11:22
    Hi Sachin
    This is an excellent question. It really centers round the implementation question - do you modify the original order in-place for amendment, or perhaps alternatively you hold the original order from progressing and create a new order that amends the original order.

    In any case you can extend the published model in a compatible way by adding a version or revision number if this meets your needs.

    Would be interesting to hear what @Ludovic Robert (the lead for TMF622) thinks about this.

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



  • 3.  RE: Revision/Amend on orders

    TM Forum Member
    Posted Oct 29, 2019 00:54
    ​Hi @Jonathan Goldberg,

    Thanks for your comments. I will wait and see @Ludovic Robert's view on the same as well to understand whether there are any plans to bring in the revision number formally in the API definitions. As you mentioned, from implementation perspective, we would definitely need to capture the revision number to build logic around how to handle the revisions.
    I have another query as well. While going through TMF641 example payloads i am a little confused. Looking at the snippet of example payload from TMF641 R18.5.1 

    "orderItem": [ { "id": "1", "action": "add", "state": "acknowledged", "service": { "@type": "vCPE", "@schemaLocation": "http//my.schemas/vCpe.schema.json", "state": "active", "serviceType": "CFS", "serviceCharacteristic": [ { "name": "vCPE_IP",


    ​​The orderItem holds all the services and ServiceCharacteristics hold the chracteristics values. But looking at the the resource model, the model defines it as ServiceOrderItem (paylaod has it as OrderItem) and Characterisic (payload has it as ServiceCharacteristic). How do we depict what the payload is supposed to contain? I had initially assumed it would ServiceOrderItem and Characterisic instead of OrderItem and ServiceCharacterisic.

    Could you let me know your view/comments of the same?

    ------------------------------
    Sachin Bhaskaran
    Infosys
    ------------------------------



  • 4.  RE: Revision/Amend on orders

    TM Forum Member
    Posted Oct 29, 2019 05:25
    Hi Sachin

    In JSON payloads we see attribute names (the "key" in JSON schema), we don't see data types.
    For example, in the ServiceOrder schema we declare the contained order items as:
    "orderItem":  {
            "type": "array",
            "minItems" : 1,
            "description": "A list of service order items to be processed by this order",
            "items":  {
                        "$ref": "ServiceOrderItem.schema.json#/definitions/ServiceOrderItem"
             }
    }, 
    In other words, the attribute of ServiceOrder named orderItem is an array of ServiceOrderItem .
    So in the JSON payload for a ServiceOrder we would expect to see something like:
    "id": "myserviceOrderID232344535",
    "orderItem":
    [
           {
                   "id": "myserviceOrderItemID3554634555"
           },
           {
                   "id": "myserviceOrderItemID35546345566"
           }
    ]

    We generally name the attribute as the same as the data type (but with lower case first letter), but there are exceptions, especially when we are trying to correct the model on the one hand but not to break compatibility with previous versions.

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