Connectivity plug-ins enhancements in 10.3.1

It is now possible for the response to an HTTP request to the HTTP server transport to be handled and created by an EPL application, instead of automatically returning an empty Accepted response. This allows the HTTP server to implement a request/response REST protocol and not just an event submission protocol. For detailed information, see Handling responses in EPL.

The following new configuration options are available for handling responses in EPL: automaticResponses and responseTimeoutMs. For more information, see Configuring the HTTP server transport.

A new metadata.requestId field is available for requests from the transport to EPL, and several new fields are available for EPL-supplied responses. For more information, see Mapping events between EPL and HTTP server requests.

The HTTP server transport now supports gzip and deflate decoding. For more information, see About the HTTP server transport.

The HTTP server transport now supports HTML form decoding and can decode multipart/form-data or application/x-www-form-urlencoded media types to a dictionary payload. For more information, see Handling HTTP form decoding.

The HTTP client transport now supports gzip and deflate decoding. HTTP client requests now set the Accept-Encoding header appropriately. For more information, see About the HTTP client transport.

The HTTP client transport now supports HTML form encoding and can encode a dictionary payload to either multipart/form-data or application/x-www-form-urlencoded media types. For more information, see Handling HTML form encoding.

The HTTP client transport now supports HTTP redirects transparently. If redirects are to be followed, set the new followRedirects configuration option to true. For more information, see Configuring the HTTP client transport.

The HTTP client transport can now transparently handle cookies for requests so that it is no longer required to handle them in EPL. If you want to enable this behavior, set the new cookieJar configuration option to true. The HTTP client then stores in memory all cookies received from the server and adds them to subsequent outgoing requests. For more information, see Configuring the HTTP client transport and Dealing with cookies.

Note:
For backwards compatibility, the new followRedirects and cookieJar configuration options are set to false by default when they are not explicitly specified in the YAML configuration file. However, for your convenience, when you add a new HTTP Client connectivity bundle in Software AG Designer, these options are already set to true in the resulting YAML configuration file.

The Cumulocity IoT transport connectivity plug-in now honors the pageSize parameter while querying for resources. This applies to all versions of the Cumulocity bundles (9.0 and 9.8+). See also the following topics:

Starting with the Cumulocity 9.8+ bundles, the Cumulocity IoT transport connectivity plug-in honors the fromDate and toDate parameters while querying for operations. See also Querying for operations.

Starting with the Cumulocity 9.8+ bundles, the value of the Cumulocity IoT transport connectivity plug-in's requestAllDevices configuration option is set to false. See also Configuring the Cumulocity IoT transport. You should now explicitly request for all available devices on startup using the com.apama.cumulocity.FindManagedObject API. For more information, see Sample EPL.

The String codec can now convert individual payload/metadata fields to a character set other than UTF-8. The following new configuration options are available for this purpose: eventTypes, fields, and encoding. For more information, see The String codec connectivity plug-in.