CloudStreams 10.15 | Usage Notes | CloudStreams Development
 
CloudStreams Development
*Swagger/OpenAPI 2.0 unsupported capabilities are as follows:
*CloudStreams does not support form-encoded parameters.
*The request/response schema with nested references adds the extra root in the signature and is not accepted by the backend. Hence, the OpenAPI specification with nested references may not work as expected with CloudStreams.
*CloudStreams does not support any additional properties in a JSON Schema specification. 
*OpenAPI 3.0 unsupported capabilities are as follows:
*CloudStreams does not parse the composed schema objects (allOf, anyOf, oneOf, and so on) from OpenAPI specification. For every composed schema object CloudStreams encounters while parsing the specification, the parser adds an empty object to the document(signature).Workaround: While executing the cloud operation for a given resource with a composed schema object in the signature, add the required fields under the empty object.
*CloudStreams skips parsing the Links from the OpenAPI specification. These links do not impact the usage of resources.
*CloudStreams does not have the provision to support the callback capability from OpenAPI specification. Hence, all the resources associated with callback are skipped. Once the parsing is completed, the list of resources that are skipped is shown in the warnings dialog.
*The request/response schema with nested references adds the extra root in the signature and is not accepted by the backend. Hence, the OpenAPI specification with nested references may not work as expected with CloudStreams.
*CloudStreams does not support form-encoded parameters.
*CloudStreams Provider projects developed using the older plug-in, that is, v9.12 and earlier, cannot be migrated or upgraded to the v10.2 plug-in. You must create new projects.
*While creating a connector, if the connector ID contains dots (.), nested or hierarchical folders will be created. For example, if the connector ID is a.b.c.d.e.f.g, nested folders will be created named as a, b, c, d, e, f, and g. It is recommended to have as less dots as possible in the connector ID in order to have a smaller hierarchical structure in the Package Navigator view in the Service Development perspective.
*While creating a connector using a Swagger file, authentication schemes are not parsed. You must add the authentication schemes after creating the connector.
*You will not be able to delete a provider package if it is published. You must first unpublish the provider package and then delete it.
*You will not be able to update the Resource Group reference if a provider package is published. You must first unpublish the provider package and then update the Resource Group reference.
*GET, PUT, POST, DELETE, and PATCH are the only methods supported while creating a REST resource. If you are creating a connector using a Swagger file, any other method available in the Swagger file will not be supported.
*To view the newly added assets, you must refresh the package from the Package Navigator view in the Service Development perspective.
*To import a Provider folder, if the Provider package is created on a different server, you must have access rights on that server.
*To import a published Provider package, nsName must follow the following namespace convention: <connector_id>.<service_name>. If this convention is not followed, the Provider package can still be imported, but a few functionalities might not work after import.
*Assignment from services is not removed from the Connector XML file when the service is deleted from a perspective other than CloudStreams Development. When Rest elements such as Parameters, Headers, Body, and Connection properties have assignments from a service and the service is deleted from a perspective other than CloudStreams Development, the user interface and the Connector XML file still show the assignments. These assignments will have to be removed (Unassign) manually.
*Adding or deleting a user will not reflect automatically on the “Run As User” list for a “Service Invocation” configuration on the “Event” tab of an already open listener node. The listener node must be closed and reopened to reflect the updated user list. Additionally, if the “Service Invocation” action has been configured to be applied on the incoming events and the configured “Run As User” user has been deleted, then the “Run As User” value has to be manually reconfigured.