I want to begin experimenting with invoking Epicor APIs via the REST interface from perl. Can someone please provide info on header key-value pairs? For example,
Thank you.
All this is documented on the REST info in the epicor help, the REST novel on this site and the REST API help URI (also pointed out in the rest novel)
Look in experts corner or search the site
-Jose
Which version does the REST info appear in the Epicor help? I did not find it in 101.500.36.
Thank you,
Darrell
REST was a Technical Preview in 10.1.500 and official in 10.1.600+, so I would expect the help updated then.
And if you haven’t checked it out, the REST Novel: https://epiusers.help/t/rest-overview-novel/36260
Mark W.
<HUGE Safe Harbor here as this is for education in general to understand background of how E10 is put together and to be used for diagnostics purposes. If you call up for support on an aspect of this, you are likely to get limited to no help. Also beyond a few areas, this is possible (likely) to change!>
Scared off everyone now? Good, now on to the details.
I spent some time looking thru where we are at the moment. NOTE - this is a dump against an internal 10.2.300 build but I think these are all live in 10.2.200 (see safe harbor up top, right?).
First, many may be asking - what’s a header? Logically it’s just a string variable that is a two way pipe on every call client to server and server to client. Http, heck Tcp, has this ability so E10 simply leverages it to pass some data around to do it’s work without polluting every method call.
So here they are:
Let’s go thru some items in here…
First, note a fair amount of reserved ones. I am calling them reserved from my point of view (see the safe harbor above). I don’t see the value of exposing them when we have better ways to deal with log traces for example.
Next, let’s iterate thru the rest these quickly top to bottom-
License - This is used to tell the server which license type the client would prefer to consume. Note the way I stated that. Biz Logic from Marketing is obviously in charge and has final say 
The Guid value is the equivalent of what you see in Admin Console Sessions. These values are what you see in your lic files is you want to look up the values:
CallSettings - I wish this had been named Session Override or something similarly badly named. These values override what you usually think of in Session as you navigate thru the software. Note that not all Session variables are visible and exposed. Some for good reasons, some because no one has asked for it. We are adding more of these as we find the need internally on projects like Mobile CRM.
ContextHeader - The BPM payloads you see in BPM all the time
AuthTokenHeader - The authentication token obtained from the legacy ERP token server
AzureADToken - The authentication token obtained from Azure AD
OnBehalfOfToken - The name this agent is acting on behalf of. For example, this could be a call from the Task Agent that is printing a report for someone else. ‘On Behalf of’ another user. The agent account running this needs the ‘impersonation’ right in User Maintenance.
SessionInfo - This is the Guid that points at the server side ‘Session’ data stored in the app server to hold the state of the client to server ‘session saga’ information. EmployeeID, Workstation, User, license consumed and so on. Since not everything is exposed via ContextHeader above, you sometimes need to start a server session, grab the ID and have the server track the state of your navigation thru the software.
There you go, brain dump done. Questions?
This type of authentication is called “Basic HTTP Authentication”
Here is one of many explanations how it works - https://sendgrid.com/blog/magic-behind-basic-http-authentication/
Thanks Olga for pointing out the missed questions…
You need to decide how you are going to handle AUTHENTICATION of clients. There is a variety of options based upon the different use cases. They vary based on the access to the server you use so it’s not that there are bad and good as much as - where you are coming from you have access to ‘x’.
From a REST client, you probably would be best with a Token Authentication. Either Azure AD or the ERP 10 versions both perform the same role - authenticate to the Token provider, stash the token in a safe spot in the browser and send on each server call. We have seen that used a lot with OnBehalfOf in some integration scenarios. An outside system authenticates as ‘TheOutSideSystemAgentAccount’ - an ERP 10 user by that name with Impersonation rights. Then the call into E10 sends over the ‘OnBehalfOf’ as the actual user that wants the work done so all changes look like they are done by that user.
a small update
in version 10.2.700x (starting from .400 I believe) the
{“Company”:""} no longer works and is ignored by API
On V2 the company is part of the URL
Yes, but in some cases, it has no effect. I.e.
/{currentCompany}/Ice.BO.AdminSessionSvc/GetFilteredSessionList ran as a manager returns ALL sessions from ALL companies in the same DB… If this worked as a filter to return only sessions from a current company it would be great, but it does not. Maybe I am understanding this wrong…
Well that business object is cross company
It depends on the BO if you want to filter you can use the oData filters
Filters are working only with real SQL columns, i don’t think it is the case with AdminSession.
