CloudStreams 10.15 | Usage Notes | CloudStreams Server
 
CloudStreams Server
*If Integration Server Microservices Runtime (MSR) docker image is built excluding the Web Services Stack, then CloudStreams does not work.
*CloudStreams provides a provision to call any Integration Server service in the start-up sequence.
*CloudStreams REST resource supports only one type of message builder and formatter for all response codes.
*CloudStreams does not support the RPC/encoded style WSDL.
*CloudStreams does not support the RPC/literal style WSDL.
*CloudStreams does not support sharing of Connector Virtual Services, Virtual Services, and Policies across nodes in a clustered setup. These artifacts should be manually deployed to a clustered node on need basis.
*CloudStreams SOAP services support sending an attachment through MTOM as a base64 encoded input. The support to wrap an attachment as a XOPObject type and sending large attachments is not supported.
*For SOAP based connectors, if the WSDL has multiple bindings for a given service, CloudStreams does not support changing multiple URLs dynamically to connect to the service endpoint.
*webMethods Mediator and CloudStreams products are not compatible. The products must be installed on separate webMethods Integration Server instances.
*While enabling a CloudStreams connector listener, if there are connectivity issues such as network and proxy issues while connecting to the streaming API endpoint, the listener automatically goes into retry mode and attempts to connect to the API endpoint until the configured connection timeout is exhausted. The connector listener inherits the timeouts (Connection TimeOut and Socket Read Timeout) from the connector connection. In case the timeout is set to a large value, the update to the connector listener “enabled” status takes quite a while to reflect in the Integration Server Administrator. This may convey an impression to the user that nothing is happening. To confirm the processing, the user should check the server logs with “Streaming” logging component configured to Debug or above, or alternatively reduce the timeout values to speed up the “enabled” status update for the connector listener.
*If you disable a CloudStreams connector listener, a disconnect call is sent to the streaming provider. However, in the server logs, a META_CONNECT event is observed soon after the META_DISCONNECT event. This is because when a disconnect call is sent to the streaming provider, the provider server also wakes up the long poll that may be outstanding and replies with a connect message that may reach the client after the disconnect reply message. This is expected behavior.
*In a clustered set up, if a Terracotta server is down or unavailable for some reason, CloudStreams connector listeners will continue to function in a manner like a standalone set up.
*CloudStreams connector listener runtime error events will be handled by an error handler service, and an (optional) callback back service will be invoked with output of the error handler service to take further action based on the error handler result.