Expand my Community achievements bar.

SOLVED

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

Avatar

Level 2

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!

 
Topics

Topics help categorize Community content and increase your ability to discover relevant content.

1 Accepted Solution

Avatar

Correct answer by
Level 2

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. 

View solution in original post

4 Replies

Avatar

Employee Advisor

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

Avatar

Level 2

@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?

Avatar

Employee Advisor

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

Avatar

Correct answer by
Level 2

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.