Hi Scarter,

I think data streaming service would work well here. http://<host>/fmedatastreaming/<repository>/<workspace>.fmw?<parameters>

Data Streaming Service

Or the download service too. You should be able to pass that along to a client as long as your fme is facing public. Does that help?

Thanks for that, ​@crutledge .

Can I assume that the data streaming route would also require our FME Flow to be public facing?  

Hi ​@scarter I think that is the case. Our FME Flow is http behind our firewall and we cannot share any functions outside of our internal network. We want to get there but not quite ready yet.

I did also find this good article: FMEFlow Rest API V3 Hope that helps.

It depends. If you want to give your external partners direct access to Flow, then yes, you would have to open up your firewall for requests to Flow from your external partners.

Or you could put a bus/application server in between that receives the original request from outside, then forwards it to your FME Flow, receives the answer from Flow, and directs the answer back to your external partner. 

Personally that’s the route I would take, since that also allows you to place extra authentication/authorization in front of FME Flow. This last option allows you to keep FME Flow completely behind your firewall, but does add the complication of another step to be maintained/controlled. It also depends heavily on how your systems are set up, so I would discuss this with my Sys Admins who are responsible for the firewalls and security in my organization, to see what options there are. There may be other options I’m not aware of (using Azure, AWS, stuff like that might give you other possibilities).

The first option is by far the easiest for you, especially if you foresee future expansion (either in external partners or functionality or scope), but IMHO it’s also the least secure.