Calling Epicor's REST API from Epicor Functions

Kinetic ERP
,
1

Hello,

I am trying to call the Epicor REST API from Epicor Functions. Has anyone ever done this before? If so, do you have code examples?

Thank you!

2

Is there any reason why you’re doing this? It is possible but just trying to understand the why?

2 Likes
3

My goal is to update the JobHead.ReqDueDate for a bunch of jobs on a schedule.
I tried updating the rows using widgets and code, but it prevents me from doing so if the jobs are Engineered and Released. I realise this might be due to some safety measure, but then I was able to push a new JobHead.ReqDueDate using the REST API without unengineering and unreleasing a job and nothing blew up.

I thought it might be a lot simpler to just push via rest instead of creating a mega function just to accomplish this task. Plus it might be super useful in the future.

4

If this method worked for you then call it using the BO



        this.CallService<Erp.Contracts.XXXSvcContract>(job =>{
        job.YOURMETHOD(ref DATASET, PARAMS);

This is a very simplifed example. Show us your code and we can help you. :trumpet::saluting_face:

1 Like
5

Appreciated! I was expecting a scolding for data corruption risks :sweat_smile:
I’ll give this a try tomorrow and see how far I get.

1 Like
6

Best practise is to use the BOs

Not calling your idea stupid or anything but why make an outbound call to the rest services for an internal process.

If you were calling an external API. Ive got plenty of snippets for Restsharp :blush:

3 Likes
7

That you know of, or yet.

I got ya fam. This is it. :wink:

As a rule, you should only modify things in Epicor via the business objects.

There are certainly exceptions to this, but unless you are super duper sure of yourself, you should steer clear, and do tracing, and mimic the way Epicor does it.

Good enough? ← Tongue in cheek, but the advice is not. You do not want to kick yourself later. Ask me how I know.

2 Likes
8

^^^ This!
I’m not sure I fully understand what you’re trying to do and why you can’t use the BOs to achieve this. I do this kind of thing all the time using the BOs.

Here’s an example of creating a new Sales Order:

Erp.Tablesets.SalesOrderTableset tsOrder = new Erp.Tablesets.SalesOrderTableset();

// get a new SO hed
try{
  this.CallService<Erp.Contracts.SalesOrderSvcContract> (boSO => {
    boSO.GetNewOrderHed(ref tsOrder);
    
    //update fields in OrderHed
    tsOrder.OrderHed[0].Company = "xxx";
    // change whatever fields here...

    boSO.Update(ref tsOrder);

  });
catch (Exception e)
{
  // handle errors or feedback e.Message
}

If you wanted to update an existing order you’d use GetByID (or one of the other GetBy BOs) instead of GetNewOrderHed.

As Kevin said, run the process manually and trace. This will give you a list of the BOs you need to call in your code.

2 Likes
9

Here is super simple example:
https://www.epiusers.help/t/lets-share-useful-functions-sharing-is-caring/100371/66

This calls from in a Function to REST using a Func hope that close enough to your request :slight_smile:

1 Like
10

Thank you very much! I’ll give the BOs another try for sure. It just seems to be a bit of a pain when using exactly the BOs that Epicor uses and then you’re missing something.

2 Likes
11

Curious, what endpoint did you use to change the reqduedate on an engineered and release job?

12

I tested using a POST:
/api/v1/Erp.BO.JobEntrySvc/JobEntries

{
  "Company": "TST1",
  "JobNum": "0122500",
  "ReqDueDate": "2024-07-27T11:57:34.027Z"
}
13

Note that @CSmith is calling another system (ECM) and not Kinetic. That is an appropriate use of REST. The REST calls are wrappers around the same painful BOs. :person_shrugging:

If your REST call is hardcoding the server, it will be possible to run this code in Pilot or Test and it will start releasing jobs in production. Doing this in functions would keep the context to the current instance. Ask me how I know.

3 Likes
14

How do you know? :smiley:

On a serious note, I am definitely looking into using functions with BO widgets. I was wondering though why REST allows me to make this change if it’s a wrapper around the BOs? Would it technically be okay then to change via REST since it wraps the BOs?

15

The wrapper around the BOs is not always perfect (it is an extra layer afterall) and the list has several examples where the REST is not as reliable as the BO itself, especially in the OData endpoints compared to the RPC endpoints. So, REST may not be throwing an error, but you can’t be certain that the result is correct. YMMV

2 Likes
16

FYI, Erp.BO.JobStatus will let you change most header-level fields on released jobs. ReqDate, Priority and Planner are all fair game. It doesn’t have access to the OOO or BOM, and I believe it will balk if you try to change something critical like the JobPart, but it’s the module to use for managing jobs mid-flight.

3 Likes
17

This is genius, thank you so much! It basically solved my problem!

While this didn’t directly answer the question I asked about REST, you solved my problem nonetheless. You get style points.
Gentleman And GIF

2 Likes
18

Too bad you can’t mark more than one post as the solution

2 Likes
19

Agree, I definitely did not give him the solution to his issue, but I did provide what he asked for. :slight_smile:

3 Likes