Kinetic ERP Rest API Client in .NET (not .net framework)

[Mostefa (Mostefa Kamal)]

Hello EpiUsers,
I am trying to migrate the old code using wcf implementations in our .net framework 4.8 solution to a .NET 8 solution. I thought I would find easily a REST Client that is generated using Swagger/Swashbuckle/OpenAPI among the assemblies but the only dll I found is in .net framework 4.8

I also found a nuget package in .net core but it is not official and deprecated as it has critical bugs and is no longer maintained.

I would love to make the migration as quick and smooth as possible but it seems like there is no rest client dll in .NET (not .net framework) out there that I can just grab and start using.

I was wondering if it is easy to generate that client myself using the dlls in the server or if the Epicor support can generate one for .NET.

[Mostefa (Mostefa Kamal)]

It is funny how life is. It looks likes Nuget Search from Visual Studio didn’t show me all. Right after my initial post, I tried again in nuget.org website and it seems like there are some librairies that could respond to the expressed need.

Does anyone use any of these?

[josecgomez]

We actively maintain this one

Epicor Rest Helper (Nuget) Updated V2

@jgiese.wci and I with contributions from @A9G-Data-Droid Updates Version 2.2.0.1 Fixes sync freesing issues Thanks @A9G-Data-Droid Added multi mapper object| Added GetEnvironment| Replaced Dictionary<string,string> with MultiMap<string,string> this allows duplicate “keys” which is necessary for some epicor calls. Added GetEnvironment() and GetEnvironmentAsync() calls using EpicorRestSharedClasses; MultiMap<string, string> parms = new MultiMap<string, string>(); parms.Add("CompanyList", "C…

Works fine… what issue are you having?

[Mostefa (Mostefa Kamal)]

Hello @josecgomez ! Thanks for you quick reply, I have searched in the forum too but didb’t see this amazing post!!! I was using key words like Api Rest and Client…

Well, there is no issue now

[josecgomez]

@Mostefa

Well, there is no issue now

let us know if you run into issues there are a lot of examples of how to use it in that original post.

[josecgomez]

For posterity we also have one for:

Node:

Epicor Rest Helper for Node (npm) V1

@jgiese.wci and I just published a similar helper library to the C# Nuget or Angular NPM package It can be found here This library helps make Epicor calls from a node application. All the documentation for it is in the NPM Site. Let us know if you run into issues

Angular:

Epicor Rest Helper for Angular (NPM ) V1

@jgiese.wci and I just published a similar helper library to the C# Nuget that can be used with Angular. It can be found here All the documentation for it is in the NPM Site. Let us know if you run into issues Version 1.0.13 – Angular 11 Version >= 1.1.0 – Angular 12 Version >= 1.1.6 – Angular 13

And somewhere @jgiese.wci has one for Python?

[Mostefa (Mostefa Kamal)]

Sure I will. I’ll be using mostly API to interact with:

• Customer
• ChangeLog
• Memo
• Job
• Pc
• Quote
• SalesOrder
• Ud
• UserFile
• Vendor

[klincecum (Kevin Lincecum)]

I suggest you don’t.

Unless it’s simple stuff, use the API to interact with Functions.

[Mark_Wonsil]

I will add the BAQ endpoint for some things as well.

[Mostefa (Mostefa Kamal)]

@klincecum Its mostly simple stuff. The most complex think I do is modifying a gigantic JobAssembly. Should I worry?

[Mark_Wonsil]

Think about upgrades and how tightly this portal is dependent on the raw APIs. Any changes in Kinetic may force you to changes in your client. If you can encapsulate the functionality in Functions/BAQs, you can escape most of this.

Also, you will reduce the number of calls over the wire drastically.

[Mostefa (Mostefa Kamal)]

I hear you and it makes sens. However, if I interact with Order for instance to change it’s status (firming it) or modify a BoM. How likely are those endpoints be affected?

[klincecum (Kevin Lincecum)]

Probably minimal.

Just keep it in mind when developing.

Anything moderately complex or working with more than one method is probably better to do in a function.

[Mark_Wonsil]

@Mostefa

How likely are those endpoints be affected?

One never knows.

What’s the advantage to making more calls than fewer? Of adding more logic to the client to shape the data of those calls into a format decent to display to the customer? Moreover, the client is insecure. Any extra data that comes to the client won’t be protected.

YMMV.

[bmanners (brett manners)]

I would also vote for putting all your logic in a function and calling the function via the RestAPI.

We have a DotNet 6 ASP.Net core website that interacts with Epicor. It is currently using a Swagger generated API / wrapper to call the Epicor Rest endpoints. We migrated this from the wcf bo’s a few years back. I found that the swagger generated client was fairly easy to swap out the wcf calls. But the swagger client was very hard to generate - had to download the spec from Epicor server, put that into an app that generates the client, set a bunch of setting to make sure it generated the right code… it was a fragile process and I want to move away from that. We are slowly moving sections of the website to Blazor and using functions in Epicor for all the business logic.

The Epicor way of updating data is very chatty. By using functions you can make a single call to the function and all the chit chat can happen in the function on the server. This gives you lower latency and during upgrades you don’t have to recompile and re-deploy your client app, just update the function if the BO Api has changed.

Brett

[Mostefa (Mostefa Kamal)]

@Mark_Wonsil @klincecum @bmanners
I appreciate all the insightful responses you’ve provided. I’ll definitely keep your advice in mind and inform the client about potential challenges with future updates. Given the time constraints, I’ll likely opt for the quickest solution for now, with a plan to gradually transition to internal functions.

[Mark_Wonsil]

I understand. This is a popular path for many companies:

• Make it quickly.
• Now, make it faster.
• Oh , make it secure.

Hopefully the client understands they may be exposing sensitive data, especially if this is external facing. A few years ago, the State of Missouri’s web page pulled in too much data into the client - including SSN’s that were visible to anyone who uses the Dev Tools. I’m much less concerned about poor performance and upgradability than security. There is no security at the client - both the browser and our customers.

[Ernie (Ernie Lowell)]

@Mark_Wonsil

• Make it quickly.
• Now, make it faster.
• Oh , make it secure.

This is the thing about Best Practice. It’s a Best Practice for a reason. It’s not a Required Practice… but learning from the mistakes of others…