You only need the remote Integration Agent because the Etlworks cloud instance cannot access the data behind the company's firewall.
That been said, you still need to create connections, formats and flows using Etlworks web UI, you just cannot run flows directly in the Etlworks cloud instance and will be scheduling flows to run in the remote agent.
Creating connections and formats
Remote Integration Agent does not support listeners.
If you are connecting to the database or app running locally, behind the firewall, use connection parameters, such as URL that point to the local resources.
You will not be able to test the local connections.
Just like with the connections and formats create flows using Etlworks Web UI.
If Etlworks Integrator is able to access the database, API or file it can pull the metadata, such as table's names, columns, data types, etc. from the data source. It helps with the mapping since you can use the map source and destination objects and columns by selecting them from the drop-down.
When the data source is not available, for example when the connection points to the local database, you can still use the mapping interface, you just cannot access the actual tables in columns and need to enter them manually in the mapping screen.
We suggest the following workarounds.
Mapping if the local resource is a database
The only available workaround is to create a "dummy" database with the same tables and columns as in the actual on-premise database but available on the Internet. Once you are done with the mapping you can switch the connection back to the local database.
Mapping if the local resource is a file or a web service
If a file or a web service is not accessible from the cloud instance you can always create a template when configuring a format.
Running and testing flows
For obvious reason, you can not run a flow that requires access to the local resource directly in the Etlworks cloud instance.