One thing that you might notice is that there is a scripting engine inside of Arc that has functionality that doesn’t always appear to be directly connected with any of the connectors inside the application, and that is because the engine that CData Arc is built atop is older than the application itself.

The HTTPReceive operation is one of those remnants of the earlier engine, and it’s not an operation that can be called from the Script connector, because it is one that relies on a server context to be available like an ASP.NET script. 

Unfortunately, there are no scripting examples for httpReceive because there is no connector in Arc where this operation is intended to function. You can create .rst and .rsb resources in Arc that serve as custom endpoints in the application, but you have to work outside of the administration console to create such custom endpoints - this operation would write incoming files directly to the file system instead of receiving them as messages in the application.

If you are looking for functionality to receive files via HTTP POST to the application, please make use of the Webhook connector, instead, which is intended for the receipt of XML and JSON file data.

Hi James,

Thanks for the quick response on this query. This would have fit our objective, to receive a file into the CData Arc server. Unfortunately the Webhook can only take an xml payload, it can’t simply receive a file into a folder in the server. The next option for us is to have our development team to write a java api to upload the file to a designated directory for each customer based on the credentials then have CData Arc pickup from that point.

Hi @RandyM 
It might also be helpful to look at our MFT connectors (like AS2, SFTP, etc.) in tandem with File Connector for securely transferring the files to a specific directory with the right user authentication. This might be the easiest way to get to what you are looking to do.

Hi @Ankit Singh

Yes, we are considering all possible connections as we have to adapt to what is available at each of our customers by default. This makes it easier for each customer to integrate our services to their respective processes, specially those that have systems run by international organizations and those that don’t have internal IT to build connectivity. We do have clients using AS3, another is looking at GCS, while another requires us to give them an API for sending files to us. Thus we have built a transport layer which has a flow for each data source feeding input files to our data capture and mapping flows.