I’m working on my first project with Epicor Functions. Following the user guide, I’m making a call to the function via the Client Customization. I have run into a gotcha. So passing the session object to the RestClient, as described in the documentation, doesn’t explicitly set the base url that the RestClient is using.
var restClient = new RestClientBuilder()
.SetDefaultApiKey(ApiKey)
.UseSession(this.oTrans.CoreSession)
.Build();
Debuging the customization and viewing the error via VS, I’ve found that the RestClient is using the fully qualified server name, https://myserver.mydomain.local, to make the calls.
This functionality produces a couple problems. One, if you don’t have the IIS website binding set to match myserver.mydomain.local, you will get a 404 error. If you use an alias, like say myserver-a, as the IIS website binding(fully qualified or not), you will get a 404 error from the RestClient.
The Epicor Client Application itself doesn’t care if the binding is fully qualified or using an alias. It still connects and works as expected.
As far as I can tell, the RestClient is relying on the IIS binding to match the fully qualified name of the server. I find it odd that the App Server URL in the Session(which comes from the .config file), is not same base url that the RestClient is actually using.
I don’t know if this is an intended functionality or maybe there is a specific reason for this but I’m letting everyone know of this gotcha if they start playing around with calling Epicor Functions from the client and get a 404 error.
That’s weird and inconvenient. You certainly don’t have to use the RestClient to interact with Functions though as any rest client will work, but that’s definitely less convenient than using the OOTB RestClient
Originally, when I started, I was having problems with cert trust. The cert had a subject of myaliaservername.mydomain.local with myaliaservername as an alternate subject name. So I had our cert person add myactualserver.mydomain.local and myactualserver to alternates.
That got me past SSL cert trust issue, then I ran into the 404 error. After debugging and trying a few other things, I then changed the IIS binding host name to match what the RestClient was using and it was fine after that.
We really haven’t had to touch the SSL and IIS stuff through all the upgrades so it just threw me off that the RestClient would have different requirements than the client application.
(and I’ll note that this was on a test server with an alias, our production servers don’t have aliases but we currently don’t use FQDN in the sys config or the IIS binding on those servers so we have some things to look at before fully utilizing the RestClient in Production)
Do you know if the Kinetic apps are using the RestClient? I know we’ve tested a few of the forms and they work, now I’m curious how they are different if they are using the same framework.
RestClient is modified in 10.2.600.10 as it was not working for SSO environment. How do you manage API Keys between the test and live environment as we need to change in the customization?
Yes, I believe RestClient is used in Kinetic apps.
I’ve been wondering this too and have come to the conclusion that the API key(s) need to be generated in Live before working on the customization in test environment. I assume when the database is restored from live, the api key is available.
I kind of wish there was a way not to use a key(or not require a key) when the RestClient is used in a Epicor client customization. I get that external programs should use it. My opinion is that if you pass the RestClient a session object, that should suffice. I don’t particularly like the idea of having to store the key in each customization code.
This is not only an Epicor issue. Google, Microsoft, AWS, etc. all use API keys. Here’s Google’s suggestion for developers:
The best practice for this is a secrets manager. Azure Key Vault, Hashicorp’s Vault, and AWS Secrets Manager all do this for you. I don’t know anything about the future Epicor Identity system coming out but it too may have this kind of capability. Basically, once you’ve proven who you are, you are given access to the secrets (API-Keys, connection strings, whatever) and then your app fills them in. The advantage here is you’re NOT embedding these into your application and you can safely renew keys without recompiling apps. Most of these systems also provide for local caching so you don’t have to make the call hundreds of times a day. Here’s AWS’s explanation of their Secrets Manager.
Eventually, there will be no .Net customizations so I’m not sure how much effort Epicor would put into adding this capability.
So I’m running in this issue as well. I did change my sysconfig to be the FQDN, but that isn’t what the RestClient is reading from. In fact I do not know what the RestClient is reading from because it seems to be unrelated to the Host Name in IIS bound to 443.
We have a wildcard CA cert applied to this port, so I would assume that it would accept the value but I have not a clue where the RestClient is reading the value from.
In debugging I can see it’s getting this from somewhere, but it’s not clear where from:
Ok it was the homepage url that was screwing me.
Since that is not a setting that is user controlled (I think) does that just mean we have to overwrite it every time we deploy?
That is user controlled (kind of) it is generated from the server side when you create the AppServer
It will match the name / url you are using in your server.
So I assume this is referring to the Epicor App Server name established in the EAC.
When I renamed the server on there to the FQDN, it “works” but it does not change the deployment server name. Furthermore, it does not allow the existing deployment to be altered, as the server name in the deployment now does not match the server name in EAC. The option instead of “Deploy” is now “Refresh” and throws an error when clicked.
I thought then I could just create a new deployment under the server with the FQDN name, but it shows a message that “That action is only available when the Admin Console is running on the server”, which is clearly is since I’m on that server
Starting to think it would just be easier to alter the sysconfig before deploying to users
