That’s half my code base! 
I wonder if in theory the browser/AppStudio can see the internal IP? (and then you’d give the machines static IPs). Probably a giant pain even if possible though.
1 Like
Has anyone tapped the edge agent to see what kind of system info it can pull? Like it can obviously go get crystal dlls/epicor dlls in client folders and all that, why couldn’t it run a bat file or something that returns system info like this?
1 Like
That’s the crux. It cannot (will not) for security reasons.
We’re looking into that also. We were thinking if we could poll it for its environment data, we’d have what we need. Question is, with multiple agents running, how do you know which one to poll - or is it by default(somehow) the one associated with the host - but how would it know? Unless the edge agent registers with the session guid of the user…
The edge agent isn’t “special” in any real sense… There’s very little stopping you from having your own Ashworth Agent. (Its just a local web server)
I wouldn’t put any private information on it but something as simple as the work-station ID is pretty harmless
Something like this:
Runs at : Localhost:5000/GetEnv
And return the machine name
Normally having an outward facing “web server” listening for requests on LocalHost and responding to anyone who calls is a no no… But honestly the machine name is harmless. If you want to make it more robust you could make sure that the source is a specific URL (like edge agent does)
IN App studio all you have to do is make a call to this and grab the info and do with it what you wish. Maybe the Edge agent already has an endpoint which includes System Info but I couldn’t find one @Olga may be able to point us in that direction if it exists.
RowUpdate
"#_JSON.parse((() => { const x = new XMLHttpRequest(); x.open("GET", "http://localhost:5000/GetEnv", false); x.send(null); return x.responseText })()).machineName_#"
Yes you will have to install this on every workstation.
3 Likes
Well in our case a small webserver listening for requests on localhost is called Edge Agent. But no one yet requested to add local computer name functionality to it 
3 Likes
C:\ProgramData\Epicor\EdgeAgent\installproperties.txt file that’s resident on my machine has the “agentID”, “agentName” and “agentLocation” values that were specified at time of local install…can’t speak to network-install though.
There is no code in EA to return machine name to Kinetic in browser. It is trivial but was not requested yet.
You can add an idea I guess.
3 Likes
@josecgomez thanks for this. We were working this line with our own little listener - but thanks a lot for the great example and confirmation!! We were exploring a few other things like the Agent to see if we didn’t need our own app everywhere - for all those reasons - but also b/c we can’t think of any other reason for it at the moment.
1 Like
@Olga Thanks for the reminder 
There’s a new idea, building off an expired @klincecum idea awaiting approval - KIN-I-6685
3 Likes
You could also get SUUUUUPER Hacky (don’t do this) and Wedge it right into the existing edge agent
Seriusly don’t do this… but if you do… it might look like
This
Wedge EdgeApp.dll Startup class
services.AddControllers().ConfigureApplicationPartManager(delegate(ApplicationPartManager apm)
{
string path = Path.Combine(AppContext.BaseDirectory, "Plugins");
if (Directory.Exists(path ))
{
foreach (string fileI in Directory.GetFiles(path, "*.dll"))
{
try
{
Assembly assembly = Assembly.LoadFrom(fileI);
apm.ApplicationParts.Add(new AssemblyPart(assembly));
}
catch (Exception ex)
{
Console.WriteLine("Failed to load plugin: " + fileI+ ", Exception: " + ex.Message);
}
}
}
});
Then Make your own controller
Drop file in new Plugins folder..within Edge agent install location
and…
Then … #Profit
5 Likes
So happy I got to see this today
Having stayed on Classic for so long, I’m sooooo far behind!!
I never realized the EA had a plugin capability - dang. Thanks for sharing and enlightening me - and @utaylor - and many more I’m sure that will see this.
1 Like
It does not have THAT plugin capability 
Jose will have to re-add the code on each reinstallation
3 Likes
It doesn’t I added it
But its a good idea and it takes 2 lines of code so maybe someone can add it for us…
6 Likes
2 Likes
1 Like
When you login, in the BPM can you get the context of the local machine making the call?
If so, I think you see where I am going.
In the browser client, all the normal context data is available EXCEPT hostname and IP address. Without those two items, every MES station login looks exactly the same, unless we use different logins for each station. That might be what we do in the end, but it had it’s problems before - mostly around the need for various employees to have the logins in case the power went out, or it needed to be rebooted. We’re also looking at how much we can automate the login without fully kiosk-ing the machines, since they are also used for applications other than MES.
1 Like
We had a similar situation. We want a specific PC to be associated with a Resource Group for the Work Queue. I ended using a browser cookie to store the specific Resource Group that the PC would use. Here is what I came up with. Custom Styling and JavaScript
All the pieces are self contained in the Epicor environment.
It’s not a bullet proof solution as it is just a cookie and can be cleared and they could also use a different browser. And Epicor could decide to break this at any point.
But on a MES layer, you could set up button with a slide-out that’s only shown for a specific security group or users. Then set the cookie with that slide-out. Then use that value for the logic where you need. If there is an event you can hook into, like an after window load event, you can get the value or hold it in the TransView for future use.
2 Likes