Open APIs

Expand all | Collapse all

TMF629 Documentation vs Conformance Inconsistency

  • 1.  TMF629 Documentation vs Conformance Inconsistency

    TM Forum Member
    Posted 7 days ago
    I am currently working in the implementation of TMF629 OpenAPI using the official documentation (TMF629_Customer_Management_Specification_API_REST_R19.0.0.pdf) from the following page https://projects.tmforum.org/wiki/display/API/Open+API+Table, but I am facing problems when running the CTK (Conformant Toolkit).

    The OpenAPI swagger file clearly specifies the following two mandatory params:
    [ "engagedParty", "name" ],
    This makes sense according to the documentation diagrams and also to the documentation Create Customer section which specifies clearly which are the two mandatory fields:

    But in that same documentation just a few lines after it show an example request body which does not fulfill the mandatory fields:

    As you can see there "name" and "relatedParty" are used as a sample request instead of "name" and "engagedParty", also that same request body is the one used by the CTK when running the Customer postman calls to create a customer.

    My API is failing because it needs to have an engagedParty instead of relatedParty.

    Has anybody faced this kind of problem, and if so how should I proceed? how can I get the CTK changed so that it follows the documentation?

    Thanks

    ------------------------------
    Eduardo Sanchez
    MATRIXX Software
    ------------------------------


  • 2.  RE: TMF629 Documentation vs Conformance Inconsistency

    TM Forum Member
    Posted 6 days ago
    Hi Eduardo,

        I agree with you about the inconsistency in the documentation, but in this case I believe that the inconsistency is in the examples, which has relatedParty instead of  engagedParty, but when talking about the CTK,  the mandatory attributes are engagedParty and name as you can see on the schema, then in this case it seems that there is no need to change it.



    Best regards,
    Adinan Sousa

    ------------------------------
    Adinan Sousa
    Ericsson Inc.
    ------------------------------



  • 3.  RE: TMF629 Documentation vs Conformance Inconsistency

    TM Forum Member
    Posted 2 days ago
    Hi Adinan,

    You are right, the problem was not caused by the relatedParty since the CTK-Customer-4.0.0 postman collection was sending engagedParty.

    The problem is on a header, the swagger.json spec available in the TMF website and used to generate the OpenAPI server specifies that the server should produce and consume "application/json;charset=utf-8":
    consumes: [
       "application/json;charset=utf-8"
    ],
    produces: [
       "application/json;charset=utf-8"
    ],​
    Therefor the server created using this OpenAPI spec produces and consumes "application/json;charset=utf-8" but then the CTK is not sending that format, instead it sends: "application/json" which is not interpreted as the same thing:
    "request": {
       "method": "POST",
       "header": [
         {
    	"key": "Accept",
    	"value": "application/json"
         },...​

    When the CTK request with header Accept: "application/json" is received the server responds with a "406 Not Acceptable" error response.
    So there are two options, manually change the swagger.json to:

    consumes: [
       "application/json"
    ],
    produces: [
       "application/json"
    ],​

    or change the conformance toolkit to send "application/json;charset=utf-8", both of these resources are produced and released by TMF and ideally should not be changed, so I am not sure how to proceed.

    Any suggestions?




    ------------------------------
    Eduardo Sanchez
    MATRIXX Software
    ------------------------------



  • 4.  RE: TMF629 Documentation vs Conformance Inconsistency

    TM Forum Member
    Posted 2 days ago
    Hi Eduardo,

        Would not be redundant to designate the encoding (utf-8), since that utf-8 is the default encoding value, then I am not sure why the server responds with 406 error in this case, because at the end application/json and application/json; charset=utf-8 would be the same in this case .

    Best regards,
    Adinan Sousa


    ------------------------------
    Adinan Sousa
    Ericsson Inc.
    ------------------------------