We are trying to integrate an outside application with Epicor via API calls. I’m assuming that we need to open Epicor to be outward facing for this to happen.
The best way to do this would probably be to create an inhouse outward facing app that could consume the call from outside and then call the api inside.
BUT, no time to do it the right way 
Any other suggestions on a quick and dirty best way to allow an outside app to use Epicor API’s?
Not necessarily.
You can use an intermediary like Azure Relay.
I plan to put out an example soon.
When you go to API Key Maintenance, you setup everything you need for the API right there. The calls that are available can be fine tuned using the access scope. As long as you use the right credentials in your API call, it shouldn’t matter what third party app you call from.
I could be
I missed this part, but yes, something like a minimal api is an option.
Just make sure you secure it properly.
The quick and dirty (and secure) way is probably Automation Studio. No ports to open.
We’re on-prem so we aren’t outward facing. For the access scope stuff I thought (could be wrong) that it is just a way to limit what someone will see when they use an API key you provide.
Right, some middleware software with an “agent” facilitating network traffic so that you don’t have INBOUND traffic coming into your appserver is ideal. Or if you can pull from Epicor instead of pushing from external application, you avoid the problem.
If the external application has a static IP, sometimes folks will just whitelist that IP to allow inbound traffic through the firewall and that is sometimes good enough. It seems that these days static IPs are not as common though with these 3rd party apps which may be running on serverless architecture.
A newer ish variation of the whitelist approach is to implement MTLS Certificates with an Azure Application gateway, which means traffic only gets through if the calling client sends the right MTLS certificate. Of course, someone can still get their hands on it…
I’m curious to hear more on this one… sounds similar to how Automation Studio Agent would facilitate the network connection without all the overhead of Automation Studio?
But if you’re going with any sort of whitelist approach I would double down on your erp security – Service Security, user accounts with strong passwords, API access scopes, etc… I am often baffled by Cloud customers (with their erp on the open internet) who aren’t securing every inch of Epicor…
I was gonna wait until I released my tool, but I can probably just rip out a simple example.
That’s a layer 7 security tool, but with an open port, people could do a Denial of Service attack and bring your ERP to its knees. Having a relay like Kevin and Tom (or Automation Studio) can be a buffer against those kinds of attacks. Also, you’re not relying only on the security that Microsoft offers to repel other IIS attacks.
I’m not an expert like most of the guys here but we’re also on-prem and we have REST integrations with external apps. We’re using a serverless Azure function which acts like a middleman. External apps call the function in Azure, then the function calls Epicor API’s. Epicor’s side, we have firewall rules that accept only calls coming from the function’s IP. Function’s side, we use an SSL cert for the REST calls which matches Epicor’s cert.
Interesting. I’ll have to look at that option. If you would be willing to share a little more about how you are doing that would be awesome.
Curious as to why you choose Azure Functions over Azure Relay? I’m looking into both these options. Just wondering if there is a gotcha in either one.
Azure Relay seems more robust.
Sorry, I was away for a few days. So this started as side project, something like ‘I wonder if I can do this’. Azure functions were the most appealing to me at that time and it was also recommended by a consultant back then. I don’t think Azure Relay was in discussion and I am not familiar with it. I would say if you think it’s better for you then do it.
As for how the function works, you create a plan and then the function (HTTP Trigger). You have tons as options there - we’re using something like pay-as-you-go (bandwidth, hard drive space, etc.). As I mentioned, the external app calls the Azure function, then the function calls Epicor. We have between 1-10 calls per hour so it’s a small usage. No major issues so far and I’ve been using it for a few years. There is not much you need to do to maintain either, just keep an eye on the Azure logs and update the SSL cert when it expires.
Soon is a relative word 
Done →
Allow lists are good, but IP addresses are not ports (80, 443. etc.)
My understanding of the OPA (and most agents like it) is that they open a connection OUT to Workato servers, and all communication is handled through the agent. Workato never opens a port on your firewall - unless I misunderstood what they are doing.