Can you elaborate on your use case here? 

Currently, there is nothing like this in CData Arc - a REST connector can be used to create HTTP client connections, but it is stateless much like POSTman. 

There is also a TCP Server connector which can host a generic TCP server connection:

CData Arc - TCP Server Connector | Version 23.4.8839

But this isn’t quite like a stateless client. While there is nothing like this in our development timeline, we can review your use case and determine if we have something in our development roadmap that can be used here.

Hi James,

We have a fleet of portable data acquisition boxes distributed throughout our plant.  They are connected to Wi-Fi and have a WebSocket interface on ws://xxx.xxx.xxx.xxx:4000/.  Each unit is on a static IP.

The WebSocket interface supports a simple get/set query in JSON format.

An example query is a get for ‘information’:

{
"type":"get",
"group":"thirdPartyAPI",
"data":{
"field":"information",
"value": null
},
"messageID": "a0a3fd19-965c-45ea-ba17-9a4d399ed769"
}

We get the response:

{"type":"get",

"group":"thirdPartyAPI",

"data":{"field":"information","value":{"model":"DAQUnit","serialNumber":1234567890,"channelLabels":L"0.3","0.5","1.0","3.0","5.0","10.0"],"instrumentName":null}},

"messageID":"a0a3fd19-965c-45ea-ba17-9a4d399ed769"}

With Arc’s capabilities and ability to easily handle and convert JSON, we could setup a central query/convert/collect scheme that would operate 7/24.

I’ve passed this along to our development team to consider as a new feature in future releases of CData Arc. 

The closest thing that we have now is the ability to call external processes in the operating system environment and output the results of the stdout and stderr channels: 

https://cdn.cdata.com/help/AZJ/mft/op_SysExecute.html

If you had a command line process that would poll data from a websocket, you could use this operation with receive automation to retrieve new responses from the socket and push them as messages into a flow.