Open APIs

 View Only

  • 1.  TMF639 Resource Inventory Management - New Resource

    Posted Aug 24, 2023 08:16

    Hi fellow TMForum members,

    I have a couple of questions regarding creating of the new resources. According to spec, a resource can either be Logical or Physical. Apart from common properties, logical resource additionally has a Value property, while physical resource has ManufactureDate, PowerState, SerialNumber and VersionNumber. The model used for POST operation, Resource_Create, however, doesn't have any of the specific properties, only the common ones, so if we were to POST resource with PowerState property, it would be lost during deserialization.

    1. What should we do in this case? Should we manually extend Resource_Create model, or should we inherit from it two additional models, LogicalResource_Create and PhysicalResource_Create?
    2. If latter is the case, what should we use as a discriminator property? According to spec, @baseType is either LogicalResource or PhysicalResource, while @type is the concrete resource type, i.e. MSISDN, so I guess @baseType would be the way to go.

    Thanks in advance,

    Regards



    ------------------------------
    Nebojsa Peric
    TO BE VERIFIED
    ------------------------------


  • 2.  RE: TMF639 Resource Inventory Management - New Resource

    Posted Aug 27, 2023 03:17

    Hi Nebojsa

    The discriminator to be used in this case is @type . Indeed in v5 APIs @type becomes a mandatory property since it is used explicitly as discriminator.

    You are correct that there is a challenge here, it is apparent also in PaymentMethod API and other places where we define operations at base-class level.

    As far as I understand, the idea is that you use the POST operation defined on the base class, but you nevertheless pass in a payload that matches the subclass schema. But I don't know exactly how code generators treat this situation.



    ------------------------------
    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: TMF639 Resource Inventory Management - New Resource

    Posted Aug 28, 2023 04:00

    Hey Jonathan, thanks for the response!

    The thing is, it's a bit challenging to use @type as the discriminator here, at least when we look at sample payloads in the spec. The @type there is set to MSISDN, or Equipment, while @baseType in this case is set to LogicalResource or PhysicalResource.

    In TMF720, we have a couple of nice examples of inheritance, i.e. EmailMedium and PhoneMedium as DigitalIdentityContactMedium specializations. Once we set @type as discriminator here, code generators play really nicely and generate the proper inheritance model. With this approach JSON payloads are deserialized in proper subclass models. Without the inheritance setup, base models would have to have all the properties, from all the subclasses (like RefOrValue entities do), which is obviously not the case with Resource, thus any extra data is lost during the deserialization.

    I guess we will have to stick to some custom deserialization workaround for the time being.

    Do you know if there is any v5 release roadmap available?

    Thanks a lot!



    ------------------------------
    Nebojsa Peric
    TO BE VERIFIED
    ------------------------------

    Original Message


Related Content