Open APIs

 View Only

  • 1.  How to handle updates to a resource with a large number of related entities

    TM Forum Member
    Posted Feb 13, 2024 10:39

    Hi All,

    We have certain entities like Sales Accounts that may be related to a large number of other entities like Organisations. When any of those relationships change i.e. a new Organisation gets added/removed to/from the Sales Account , we have to send a notification to all interested applications.

    In some cases, this results in a massive payload as we sent the entire resource with all the related entities. This is causing us problems and hence we feel that we should only send the related entities where the relationship is  changing rather than all entities.

    To achieve this, we were thinking of adding an action field against every related entity in the payload to indicate if the entity relationship was added, removed or changed.

    1) Does this approach of only sending the related entities seem sensible in order to reduce the payload?

    2) If yes, are there any other options apart from adding an action field?

    3) Where could the action field sit in the payload? One option is below 

    "relatedParty": [
            {
                "action":"delete"
                "@referredType": "organization",
                "href": "https://api.business.bt.com/tmf/party/v4/organization/E09749794",
                "id": "E09749794",
                "name": "BT Internal",
                "role": "internal"
            },
            {
                "action":"add"
                "@referredType": "groupServiceAccount",
                "href": "https://api.business.bt.com/tmf-api/partyRoleManagement/v4/groupServiceAccount/G7854349",
                "id": "G785439",
                "name": "ABCD GLOBAL ACC1",
                "role": "groupServiceAccount"
            }
        ]



    ------------------------------
    Milind Bhagwat
    BT Group plc
    ------------------------------


  • 2.  RE: How to handle updates to a resource with a large number of related entities

    Posted Feb 14, 2024 04:44

    Hi,

    This attribute could  set a precedent and each consumer of this API could ask for additional attributes in the related party based on their needs. If the consuming application is going to use href to read more data from the source, then I think adding additional attributes would not be required.  If you are following the pattern for event carried state transfer then the action would be at the event level and each changed resource would have a event of its own.



    ------------------------------
    Krishnaji Kubal
    Hutchison 3G UK
    ------------------------------

    Original Message


  • 3.  RE: How to handle updates to a resource with a large number of related entities

    TM Forum Member
    Posted Feb 14, 2024 04:44

    Hi Milind,

    I agree with you that size of payload can create problems. Particularly event-driven systems don't perform well with large payloads.

    A solution to this problem, without extending the data model, is described in TMF630_REST_API_Design_Guidelines_Part_5_v4.0.pdf. It uses an json-patch extension use operations on array elements. The TMF630 solution only works for PATCH operations though and the guidelines still expect the full payload in the response message. Since this approach is defined in TMF630 the solution stays within the standard and is easier to enforce on vendors.

    Another solution is to use compact payloads by converting JSON payloads into Avro or Protobuf. Both formats translate JSON objects in a binary format taking about half the size. Code generation based on a schema is supported by both systems. This approach is going a bit beyond the current TMF Open API guidelines. We experimented a bit with this approach. To our experience translating swagger in the Avro or Protobuf schema's is not yet fully automatic. I expect tooling to get better over time.

    regards



    ------------------------------
    Koen Peeters
    OryxGateway FZ LLC
    ------------------------------

    Original Message