Open APIs

 View Only
Expand all | Collapse all

TMf 641 - Information Required Event

  • 1.  TMf 641 - Information Required Event

    TM Forum Member
    Posted Sep 25, 2020 08:18
    Hi

    Looking at the Service Ordering Management API User Guide for v20.5 it states

    'The Pending state is used when an order/item is currently in a waiting stage for an action/activity to be completed before the order/item can progress further, pending order amend or cancel assessment. In situations where Access Seeker action is required, an "information required" notification will be issued on transition into this state. '

    Looking at the JSON body for the event it states
    { "eventId":"00001", "eventTime":"2015-11-16T16:42:25-04:00", "eventType":"ServiceOrderInformationRequiredEvent", "event": { "serviceOrder" : {-- SEE ServiceOrder RESOURCE SAMPLE --} } }

    How does the Service Order defined within the event - "event": { "serviceOrder" : {-- SEE ServiceOrder RESOURCE SAMPLE --} }  communicate what information is required so that the information can be procured and the service order patched moving the service Order from Pending to InProgress. It would be useful to be able to send a 'code' that indicates what information is required. 

    Thoughts on how this can be implemented



    ------------------------------
    Lance
    ------------------------------


  • 2.  RE: TMf 641 - Information Required Event

    TM Forum Member
    Posted Sep 29, 2020 02:48
    Hello Lance,

    Specifically in the structure of the event 'xxxInformationRequired' and 'xxxAttributeValueChangeEvent' you'll find an attribute fieldPath: The path identifying the object field concerned by this notification. This will allow you to specify the path to the field requiring some information (something like this for example if we are waiting  service characteristic valued for service order item 2 ..."fieldPath": "serviceOrder/456/serviceOrderItem/2/service/serviceCharacteristic/3").

    Hope it helps,
    Ludovic


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



  • 3.  RE: TMf 641 - Information Required Event

    TM Forum Member
    Posted Sep 29, 2020 04:33
    Hello Ludovic

    Thank you very much for the response. That has definitely addressed my question.

    Regards
    Lance

    ------------------------------
    Lancy Mendonca
    ------------------------------



  • 4.  RE: TMf 641 - Information Required Event

    TM Forum Member
    Posted Feb 03, 2021 18:07
    Hi Ludovic

    Thanks for providing the response on field path. Noticed that the field path is a string and so can be used to flag that multiple fields have been updated or mutiple information is needed as part of the AttributeChange and InformationRequiredEvent. I could use some form of separator to separate the multiple field paths I assume

    ------------------------------
    Lancy Mendonca
    ------------------------------



  • 5.  RE: TMf 641 - Information Required Event

    TM Forum Member
    Posted Mar 09, 2021 22:04
    Hi @Ludovic Robert,

    There was two fields for resourceType and filedPath in 641 ​v3( as shown below) , but in 641 v4 there is only fieldPath. Was there some decision made for removing the resourcePath in v4?

    Thanks for your support.
    Rati Mehrotra
    @Uma Lakshman​​

    ------------------------------
    Rati Mehrotra
    Telstra Corporation
    ------------------------------



  • 6.  RE: TMf 641 - Information Required Event

    TM Forum Member
    Posted Mar 10, 2021 03:28
    Hello Rati,
    This is an already identify  defect (see https://projects.tmforum.org/jira/browse/AP-2240 )
    resourceType and filedPath attributes must be present in xxxxxAttributeValueChange & xxxxxInformationRequired notification structure.

    I will check internally in our team progress on this Jira.

    Thanks for the head up.
    Ludovic

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



  • 7.  RE: TMf 641 - Information Required Event

    TM Forum Member
    Posted Mar 10, 2021 04:55
    Thanks @Ludovic Robert, appreciate your quick response ​

    ------------------------------
    Rati Mehrotra
    Telstra Corporation
    ------------------------------



  • 8.  RE: TMf 641 - Information Required Event

    TM Forum Member
    Posted Nov 19, 2021 11:05

    Hey @Ludovic Robert, do you know if this has got fixed as it seems that the swagger and user guide still doesnt contain this?

    On another point where by there is more than one field which requires an update how is this communicated by the information required event?​



    ------------------------------
    David Whitfield
    TalkTalk Group
    ------------------------------



  • 9.  RE: TMf 641 - Information Required Event

    TM Forum Member
    Posted Mar 04, 2022 07:52

    Hey @Ludovic Robert any thoughts on this at all?​

    My other consideration since i first posted this question is that we have decided to extend TMF and do an early implementation of the Amend Task based resource. Since our thoughts were that an information required event would require that to be submitted (which could involve a new additional characterisitc) i'm not sure how this would be communicated by this event?

    Obviously where there might be more than 1 is still i think the open point on how this would be communicated



    ------------------------------
    David Whitfield
    TalkTalk Group
    ------------------------------



  • 10.  RE: TMf 641 - Information Required Event

    TM Forum Member
    Posted Mar 04, 2022 08:50
    Hello David,

    We're working on the event with the V5 upgrade. Once this design done we'll upgrade all API. 
    Of course the event will be able to identify several attributes requiring value.

    Do not took it as granted as we're still working on it but to provide you a glimpse ... this is what you can have (example on quote api but same pattern will apply):
    {
      "correlationId": "qs1-k33",
      "description": "QuoteInformationRequiredEvent illustration",
      "domain": "Commercial",
      "eventId": "966",
      "eventTime": "2021-09-27T07:43:59.059Z",
      "eventType": "QuoteInformationRequiredEvent",
      "priority": "1",
      "timeOcurred": "2021-09-27T07:43:59.059Z",
      "title": "QuoteInformationRequiredEvent",
      "event": {
        "quote": {
          "id": "5252",
          "href": "https://host:port/quoteManagement/v4/quote/5252",
          "@type": "EntityRef",
          "@referredtype": "Quote"
        },
        "informationRequired": {
          "informationRequiredPath": [
            {
              "op": "add",
              "path": "agreement.id"
            },
            {
              "op": "add",
              "path": "contactMedium"
            }
          ]
        }
      },
      "reportingSystem": {
        "id": "123",
        "name": "CRM app",
        "@type": "ReportingResource",
        "@referredType": "LogicalResource"
      },
      "source": {
        "id": "123",
        "name": "CRM app",
        "@type": "ReportingResource",
        "@referredType": "LogicalResource"
      },
      "@baseType": "Event",
      "@type": "QuoteInformationRequiredEvent"
    }​

    The informationRequired is an array of operation and path. Here in the example a agreement id and a complete contact medium structure is missing.

    Hope it helps.

    Ludovic

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



  • 11.  RE: TMf 641 - Information Required Event

    TM Forum Member
    Posted Mar 04, 2022 09:47
    This is really helpful @Ludovic Robert :-) and based on the extended field set for an event i first saw in TMF688 makes total sense, do have a couple of follow ups :-)

    source and reporting system seem to suggest the same thing and to be honest after looking at the 688 spec we had come to the conclusion that both werent needed. Do you know what the difference is meant to be?

    Whilst i totally get that the model shown can support the need for addition schema based attributes as shown above. How for example would it be used to specify that a new characteristic named "someFollowUpData" needed to be submitted?

    Do i assume that the client needs to know that the way in which to submit the extra information is by using the POST /amendServiceOrders​ endpoint implicitly and they dont find that out from the event?

    thanks for you help like always

    Dave

    ------------------------------
    David Whitfield
    TalkTalk Group
    ------------------------------



  • 12.  RE: TMf 641 - Information Required Event

    TM Forum Member
    Posted Mar 04, 2022 11:16
    David,
    For the reporting and source I think they can differ it you have an event store centralizing your events. The source will be the app where the event 'really' occurred (for example here the CRM) and the reporting could be a Event store app.
    For additional attribute, it depends on which attribute but could be tough. For a new characteristic I guess you could provide add operation and then something like path=quoteItem.product.characteristic.value?characteristicName=someFollowUpData. Perhaps someone will have a better idea than mine.

    For the client, if you want to provide it information of next step(s) I will use hypermedia with _links structure to explicit how next step could be done (PATCH or AMEND). This is described in one of the TMF630 part.

    Have a great week end,
    Ludovic


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



  • 13.  RE: TMf 641 - Information Required Event

    TM Forum Member
    Posted Mar 07, 2022 06:27
    really helpful, thanks @Ludovic Robert

    ------------------------------
    David Whitfield
    TalkTalk Group
    ------------------------------