Hi
If two headerfields in an OpenAPI 3 contract is defined this way. (ACMEAPI-UserId-Type first and then ACMEAPI-UserId second).
The second field get lost in the request.yaml file inside the War file. (In here WEB-INF\operations\exampleEndpoint_GET\get\)
- name: ACMEAPI-UserId-Type in: header required: true schema: type: string description: Specifies the type of user ID. - name: ACMEAPI-UserId in: header required: true schema: type: string description: Identifier for the user.The Cobol request copy (API00Q01.cpy) is ok and contains both mentioned fields.
Current workaround is to reverse the order of these two fields so the shortest one comes first in the OPENAPI 3 contract.
Attatched is a short openapi 3 contract i used to reproduce this bug.
openapi: 3.0.0info: title: ACME API description: An example API specification with custom headers and request/response fields. version: 1.0.0paths: /exampleEndpoint: get: summary: Example endpoint with custom headers and request/response fields description: This endpoint demonstrates custom headers and fields. parameters: - name: ACMEAPI-Trace-Id in: header required: true schema: type: string description: Unique trace ID for tracking requests. - name: ACMEAPI-UserId-Type in: header required: true schema: type: string description: Specifies the type of user ID. - name: ACMEAPI-UserId in: header required: true schema: type: string description: Identifier for the user. - name: Customer-Id in: query required: true schema: type: string description: Unique identifier for the customer. responses: '200': description: Successful response content: application/json: schema: type: object properties: Customer-Id: type: string description: Unique identifier for the customer. Customer-Name: type: string description: Name of the customer.
Hello Tore, Thank you for raising this question. We have been able to recreate the behaviour you are seeing and can confirm this is a bug. Please can I ask that you open a CASE https://www.ibm.com/mysupport