AEM Forms Cloud | FMD not creating Schema properly using YAML configs

[vabs95]

Hi Everyone,

I am facing an issue with the FDM regarding the swagger configuration.

I want to have a flat structure JSON Model request for the API and it is working fine in the Swagger Editor (Version 2) but for some reason when I use this YAML to create a FDM it encapsulates the flat json into a parent object.

Expected (Working in Swagger Editor 2.0):

{
  "created": "2023-01-19T12:01:16.734Z",
  "noteAdministration": "xyz",
  "noteCustomer": "abc",
  "origin": "Homepage",
  "person": {
    "firstname": "abc",
    "lastname": "xyz"
  },
  "productId": "0000"
}

Generated (By FDM):

{
  "lead": {
    "created": "2023-01-19T12:01:16.734Z",
    "noteAdministration": "xyz",
    "noteCustomer": "abc",
    "origin": "Homepage",
    "person": {
      "firstname": "abc",
      "lastname": "xyz"
    },
    "productId": "0000"
  }
}

Notice that "lead" key has been added at the top of the JSON. This shouldn't be there.

This is the swagger config I'm using as a datasource to create FDM:

swagger: '2.0'
info:
  version: '1.0'
  title: LEAD 
host: test-lead-url
basePath: /api
securityDefinitions:
  Bearer:
    type: apiKey
    name: Authorization 
    in: header
    description: Passes the Access-Token to the service call.
schemes:
- https
consumes:
- application/json
produces:
- application/json
paths:
  /leads:
    post:
      summary: Creates new lead. 
      operationId: createLead
      deprecated: false
      produces:
      - application/json
      consumes:
      - application/json
      parameters:
      - name: body
        in: body
        required: true
        description: ''
        schema:
          $ref: '#/definitions/Lead'
      responses:
        '201':
          description: Created
          headers: {}
        '500':
          description: Internal server error
          headers: {}
      security:
        - Bearer: []

definitions:
  Lead:
    title: Lead
    type: object
    properties:
      created:
        type: string
        format: date-time
      noteAdministration:
        type: string
      noteCustomer:
        type: string
      origin:
        type: string
      person:
        $ref: '#/definitions/Person'
      productId:
        type: string
    required:
    - created
    - person
    - productId
  Person:
    title: Person
    type: object
    properties:
      firstname:
        type: string
      lastName:
        type: string
    required:
    - firstName
    - lastName

Not sure if there is some issue in the YAML or in the FDM itself. Could anyone pls help with this!

Pulkit_Jain_

   

Mayank_Gandhi

[Pulkit_Jain_]

@vabs95 

I believe this issue was raised with support earlier, and I have seen some discussion on this. Did you review the latest response/video provided on this one? 

Given the requirement, rewriting all the YAML configs is the plausible solution.

[vabs95]

@Pulkit_Jain_ 

Thanks for the response. I have already reviewed the solution provided by support and dropped few comments on top of that too. 

So the solution from support is to use formdata(x-www-form-urlencoded) instead of JSON(application/json) in POST request to achieve the nested hierarchy without any parent node at the start. 

This solution has some issues from my point of view:

1. Although it gives a flat hierarchy but nested object is not supported. 
2. If we use x-www-form-urlencoded then we have to rewrite all PROD ready Backend APIs also to support it 
3. We have to modify YAML to reflect all the changes of the API. 

Now my question would be, is there a better solution or this is the only way around it?

Does FDM not support Swagger 2.0 fully as this issue is not mentioned anywhere in the documentation?

[Pulkit_Jain_]

@vabs95 

Thanks for your feedback!

We will take this up with the product team for further perusal. 

FDM does support Swagger 2.0 (whole 3.0 is not supported), but this is a specific requirement and thus may have to be reviewed.

[vabs95 · Accepted solution]

Update on the issue:

The issue can be handled via workaround by implementing "IPreProcessor" interface and overriding "preprocess" method. You can add logic to customise the request payload before initiating an HTTP request.