PRODUCT: IBM BPM v8.6
We have a YAML file (valid according to editor.swagger.io) with a definition for an object called "StatusMessage" (see below).
When we import this YAML to WebPD, the StatusMessage object is discovered correctly, but the "type" property has a type of "typeType" in the StatusMessage BO instead of a type of "string" (which is what the YAML specificies).
Has anyone else encountered a similar issue consuming a Swagger 2.0 definition for an external REST operation? We know that "type" is a reserved word for Swagger but apparently it is still OK to use a reservered word as a property name.
Something else that is sort of related - BPM discovers string($date-time) properties as Time objects in BPM...which seems kind of strange right? We know Swagger doesn't have a true "date" object, but why wouldn't BPM put string($date) and string($date-time) into just Date objects?
YAML Sample
StatusMessage:
type: object
properties:
type:
description: >-
Identifies the class of the message.Allowed values are
INFORMATION,WARNING and ERROR.
enum:
- INFORMATION
- WARNING
- ERROR
type: string
code:
description: A code identifies the result of processing.
type: string
subCode:
description: >-
The sub-code further identifies the result of processing
within the more general category provided by code.
type: string
Answer by jtm_wf (221) | Dec 27, 2018 at 06:28 PM
If anyone is curious it looks like the culprit was the source system we were calling. The YAML had each enum in ALL CAPS but the source system wasn't following its own API spec and was trying to send camel-case values. So the fact that the parameter was discovered as typeType didn't really seem to matter. We were able to work around this with the JavaScript REST option but once the source system fixed their end, the out-of-the-box connector has been working just fine.