Open APIs

 View Only
  • 1.  LifecycleStatus value in json data of Conformance tests

    TM Forum Member
    Posted May 27, 2019 07:59
    Hello TMForum members,

    We have been investigating the lifecycleStatus and transitions between each statuses about "Product Catalog Management". We found Lifecycle Management Model in TMF620_Product_Catalog_Management_API_REST_Specification_R17.5.0.pdf (Page 9). This tells us first status is In study.

    But at the other end, TMF620B_Product_Catalog_Management_Conformance_Profile_R17.5.0.pdf document has json test data which has "ACTIVE" or "RETIRED" statuses. (We think of this could be important because of CTK - certificate.)

    First question is what should be the creation of catalog management item (catalog, category, offering) lifecycleStatus?

    Second we would like to ask if there is any document that tells details of lifecycleStatus types?

    Thanks

    ------------------------------
    memet harun ozer
    PiA Bilisim Hizmetleri Ltd.
    ------------------------------


  • 2.  RE: LifecycleStatus value in json data of Conformance tests

    TM Forum Member
    Posted May 30, 2019 09:36
    Hi
    As a general rule, we had placed in many of the published specification documents a statement to the effect that lifecycle statuses of managed entities are ILLUSTRATIVE rather than NORMATIVE. For example in Product Ordering Management (TMF622):
    Note that an implementation can enrich or remove or otherwise change the states. The diagram is not a normative part of the standards. The state machine specifying the typical state change transitions is provided below.

    However this has not been applied consistently across all the published specs.
    I refer you to @Henrique Rodrigues who is responsible for dealing with conformance kits, maybe he can assist.

    Hope it helps

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



  • 3.  RE: LifecycleStatus value in json data of Conformance tests

    TM Forum Member
    Posted Jun 03, 2019 03:23
    Thank you @Jonathan Goldberg​ for the mention.

    @memet harun ozer, on the CTK for Product Ordering, lifeCycleStatus is an optional attribute, so there is no test involving lifeCycleStatus besides the first Post, with lifeCycleStatus = "Active" as in the Conformance Profile.

    Hope this helps.

    Best Regards,

    ------------------------------
    Henrique Rodrigues
    TM Forum
    ------------------------------



  • 4.  RE: LifecycleStatus value in json data of Conformance tests

    TM Forum Member
    Posted Jun 03, 2019 08:47
    Thank you Henrique,

    Here is the example I mentioned about Product Offering (not Product Ordering):

    TC_ProdOff_N3 – Create new single Product Offering with prices included
    • Send a POST message to /{apiRoot}/productOffering/ with the following contents in the BODY
    {
    "name": "<anytext>",
    "description": "<anytext>",
    "isBundle": false,
    "lifecycleStatus": "Retired",
    "validFor":
    {
    "startDateTime": "<any value with correct datetime format>",
    "endDateTime": "<any value with correct datetime format>"
    },
    ...
    TMF620B_Product_Catalog_Management_Conformance_Profile_R17.5.0.pdf, page:58-59

    So, should we implement this for the certificate in this way?

    ------------------------------
    memet harun ozer
    PiA Bili?im Hizmetleri Ltd.
    ------------------------------



  • 5.  RE: LifecycleStatus value in json data of Conformance tests

    TM Forum Member
    Posted Jun 04, 2019 04:16
    By coincidence, we discussed the issue of states yesterday in an Open API team meeting.
    @Pierre Gauthier, the chief architect for the Open API team, gave clear guidance that states defined​ as part of an API specification are mandatory, so as to meet the aims of the API program for inter-operability. So, although the transitions between states (as shown in the diagram) are ILLUSTRATIVE, the states themselves should be NORMATIVE.
    Hope it helps

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



  • 6.  RE: LifecycleStatus value in json data of Conformance tests

    TM Forum Member
    Posted Jun 12, 2019 03:35
    Hi,

    Do we need to comply with all enumarations (list of values like statuses, types, etc.) as stated in Open API documentations?

    Thanks.

    ------------------------------
    Serafettin Acir
    ETIYA
    ------------------------------



  • 7.  RE: LifecycleStatus value in json data of Conformance tests

    TM Forum Member
    Posted Jun 19, 2019 12:14
    Hi

    As per the directive given by @pierre gauthier, the values of enums included in Open API specifications are NORMATIVE, and need to be supported. You are of course free to extend​ an enum to add additional values.

    Hope it helps

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



  • 8.  RE: LifecycleStatus value in json data of Conformance tests

    TM Forum Member
    Posted Dec 03, 2019 10:51
    Hello,

    Taking about lifeCycle status:into account that lifeCycleStatus is an optional element, I have two questions:

    1)  Suppose that lifecycleStatus is suppressed in a POST addressing a Catalog where lifeCyclestatus is implemented in backend.
    What should be the expected lifecyclestatus of the element in this case?

    2) Suppose that the element is in ACTIVE status. 
    Should we allow a delete message to remove such element in a in-production environment?

    Thanks!

    ------------------------------
    Marcos Donato da Silva
    Ericsson Inc.
    ------------------------------



  • 9.  RE: LifecycleStatus value in json data of Conformance tests

    TM Forum Member
    Posted Dec 04, 2019 06:17
    Hi Marcos

    1) Simply speaking, if the status is not supplied as part of the POST, I would expect the entity to be created with the first status in the state diagram. Admittedly the spec documents don't generally make that clear, perhaps there is what to improve here. In any case, I would suggest that a specific implementation of an API should document its behavior in cases where the Open API spec is silent, so that a consumer will know what to expect.

    2) Case-by-case basis, and would depend on the specific implementation of the API, as well as other business logic and authorization. For instance, if a Product Offering was Active, but I know (by queries or other mechanisms) that it is not in fact being used at all, maybe I would allow it to be deleted.

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