Open APIs

Expand all | Collapse all

TMF641 - Order rejected or failed: how to notify the client of the reason/error

Jump to Best Answer
  • 1.  TMF641 - Order rejected or failed: how to notify the client of the reason/error

    Posted Sep 04, 2018 12:46
    Dear TMF641 committers,

    The Service Ordering spec contains notifications about state changes ('ServiceOrderStateChangeNotification') - also in the cases a ServiceOrder switches to state 'failed' or 'rejected'.
    So a client of ServiceOrder-Mangement gets this notification and therefore can see:
    • 'ok, my service order has been rejected' or
    • 'ok, my service order has failed'.

    Now my question: Is there a standard way within the notifications to pass more specific information about the reason to the client
    like
    • rejectionCode / errorCode
    • rejectionReason / errorMesage
    Would it be possible from TMF point of view, to just add those fields in the notification, so that a client gets more detailed information?

    Is there an attribute or object within the ServiceOrder itself, which would be fitting for such information?

    Thanks and Regards
    Adrian

    ------------------------------
    Adrian Ofterdinger
    Capgemini
    ------------------------------


  • 2.  RE: TMF641 - Order rejected or failed: how to notify the client of the reason/error
    Best Answer

    TM Forum Member
    Posted Sep 05, 2018 03:32
    Hi Adrian,

    Make sense and we already suggest an improvement in the joint effort between TMF and ONAP initiative.

    The proposal is to add the following structure in the serviceOrder:

      "orderMessage": [
        {
          "code": "string",
          "field": "string",
          "messageInformation": "string",
          "severity": "information",
          "correctionRequired": true
        }
      ]
    If fulfillment fails or if specific event occurred and need to be stored this structure will be use.

    It is distinct from the HTTP message you get in the POST response.

    Now to add it in the API, we need to log a change request in TMF - As serviceOrder leader I'm fully open to do it.

    My plan is also to add it in the productOrder (requested by MEF).

    Hope it helps,



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



  • 3.  RE: TMF641 - Order rejected or failed: how to notify the client of the reason/error

    Posted Sep 05, 2018 09:55
    Hi Ludovic,

    This sounds great, let`s go for it!
    This would enable the SOM to add multiple order messages - which can then be handled (or just only understood) by the service client.

    Thanks a lot
    Adrian

    ------------------------------
    Adrian Ofterdinger
    Capgemini
    ------------------------------



  • 4.  RE: TMF641 - Order rejected or failed: how to notify the client of the reason/error

    Posted Nov 27, 2018 05:21
    Hi Ludovic,

    thanks again for your answer to this topic.

    Regarding your proposed structure within the notification:

    • How can we proceed with a change request here?
    Thanks and Regards
    Adrian

    ------------------------------
    Adrian Ofterdinger
    Capgemini
    ------------------------------



  • 5.  RE: TMF641 - Order rejected or failed: how to notify the client of the reason/error

    TM Forum Member
    Posted Nov 29, 2018 03:43
    Hi Adrian,

    the Change request was presented to the APi governance team sept 19, 2018 but was not straightforwardly  approved. Members requested additional information and clarification with Note use (it's true that we have a note class that can be extended via polymorphic pattern  --> this is an interesting proposal). I've provided some UC to leverage order message Oct16th but since then the topic has not been discussed.

    One key factor for this unusual latency: the TMF API project team is working on Swagger tooling and this topic 'consumes' all our 'TMF' time.

    Best regards

    Ludovic

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



  • 6.  RE: TMF641 - Order rejected or failed: how to notify the client of the reason/error

    Posted Jan 21, 2019 06:19
    Edited by Adrian Ofterdinger Apr 11, 2019 22:49
    Hi @Ludovic Robert,

    thanks again for presenting this at the design board. Just to inform you: considering your input we found a solution for us:

    We would like to enhance Note model by

          "code": "string",
          "field": "string",
          "messageInformation": "string",
          "severity": "information",
          "correctionRequired": true
    we would as of now use the Note fields​
          "author": "string", => will be some value from system as the process which manages the order
          "date": "DateTime", => will be the time an error occurred
          "text": "string", => will be the summary consisting of code, field, severity and messageInformation
    
    So in fact in future Note in the API can be in future "enhanced" by those fields above (taken from ONAP).

    In consequence, the object "Note" can either be a system generated note or a Note coming from a human person / human task.

    What do you think?

    Thanks and Regards
    Adrian

    ------------------------------
    Adrian Ofterdinger
    Capgemini
    ------------------------------



  • 7.  RE: TMF641 - Order rejected or failed: how to notify the client of the reason/error

    TM Forum Member
    Posted Jan 21, 2019 06:46
    Please be aware that in release 18.5 we are enhancing the Note entity with a system attribute, so if you are planning to extend anyway I suggest you take this into account:
    "system": {
    "type": "string",
    "description": "Describes the system from which the action related to this note was done"
    },


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



  • 8.  RE: TMF641 - Order rejected or failed: how to notify the client of the reason/error

    Posted Mar 01, 2019 04:34
    Hi Jonathan, thanks for the hint, so we did :-)

    ------------------------------
    Adrian Ofterdinger
    Capgemini
    ------------------------------