API Record not found

Been working on a call where an integration just suddenly stopped working. This is a multi company environment and it really seems like something is off with REST.
Certain calls just stopped working, In testing, I was able to GET all day long with manager, but most POSTs or PATCH is met with a 500 error.

I got down to doing very simple things like creating a simple receipt which works fine, but then I can not delete.

Checking on the event log on the APP SERVER, I see the event below for each attempt that failed.

What makes this even more strange, is there has been no issues doing the same PUT / DELETE test with another company (same app server)

Epicor.RESTApi.ErrorHandling.ApiException: Record not found.

at Epicor.RESTApi.DataSources.IceServiceCaller.UpdateItem(TypeData typeData, ContextInfo context, IceTableset updExtDs) in C:_Releases\ICE\3.1.600.25\Source\Framework\Epicor.RESTApi\DataSources\IceServiceCaller.cs:line 151
at Epicor.RESTApi.ODataHelpers.v3.DataSourceProvider.Delete(TypeMapping typeMapping, ContextInfo context, String[] keys, IEdmEntityType entityType) in C:_Releases\ICE\3.1.600.25\Source\Framework\Epicor.RESTApi\ODataHelpers\v3\DataSourceProvider.cs:line 288
at System.Web.Http.Controllers.ReflectedHttpActionDescriptor.ActionExecutor.<>c__DisplayClassc.b__6(Object instance, Object[] methodParameters)
at System.Web.Http.Controllers.ReflectedHttpActionDescriptor.ExecuteAsync(HttpControllerContext controllerContext, IDictionary`2 arguments, CancellationToken cancellationToken)
— End of stack trace from previous location where exception was thrown —
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Web.Http.Controllers.ApiControllerActionInvoker.d__0.MoveNext()
— End of stack trace from previous location where exception was thrown —
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Web.Http.Filters.ActionFilterAttribute.d__5.MoveNext()
— End of stack trace from previous location where exception was thrown —
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Web.Http.Filters.ActionFilterAttribute.d__5.MoveNext()
— End of stack trace from previous location where exception was thrown —
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Web.Http.Filters.ActionFilterAttribute.d__0.MoveNext()
— End of stack trace from previous location where exception was thrown —
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Web.Http.Controllers.ActionFilterResult.d__2.MoveNext()
— End of stack trace from previous location where exception was thrown —
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Web.Http.Filters.AuthorizationFilterAttribute.d__2.MoveNext()
— End of stack trace from previous location where exception was thrown —
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Web.Http.Dispatcher.HttpControllerDispatcher.d__1.MoveNext()
— End of stack trace from previous location where exception was thrown —
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Web.Http.Dispatcher.HttpControllerDispatcher.d__1.MoveNext()
— End of stack trace from previous location where exception was thrown —
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Web.Http.HttpServer.d__0.MoveNext()

So without changing anything they just stopped working?

When you say most fail, are these always the same calls? or the same call sometimes fail and sometimes it doesn’t?

Can you post an example of a call that fails, including the endpoint and json?

What exact version of the erp you are on?

Right. Nothing in the environment has changed AFAIK
Consistent failure on what I’ve tried (nothing intermittent)

I can run a wide open GET, but cant filter to the company in issue

What makes it strange is I can POST a simple header record, for example Erp.BO.ReceiptSvc/Receipts
{
“Company”: “COM1”,
“VendorNum”: 1550,
“PackSlip”: “TEST2”
}

but I can not add details OR delete it without getting a (500 Internal server error. Server is unable to process the request.)

Again, If I do this for the other company in the same environment, using the same accounts. it works.

I’ll also add.

All the GET requests I’ve tried work, unless I try to throw a filter. then I’m back to 500 land.

Are you using the swagger page to test or your own client?

What do you mean you cannot filter?
The company being used in the call is going to be whatever is the last company the user logged on to the ERP client, or whatever is sent in the CallSettings custom header.
You cannot work cross company simply changing the Company value inside the json.

Calls you have the ability to filter.
I’m testing this in another environment.
(as long as the user has both companies assigned)

Swagger.

You should not be getting results from multiple companies as far as I know, so filtering on the Company field doesn’t do anything.

So any endpoint works as long as you don’t filter by Company?

You have to pass the Company for V1 rest in the CallSettings Header

1 Like

I’ll admit I dont play too much with API

But the other multi company environments I’m able to filter GET requests from both sides no issues.
The affected one no, if I filter to the company acting up, I get the 500

This does give me an idea just to spin up a new service account and assign it to the ONE company.

1 Like

Unless its a Cross Company BAQ you shouldn’t get cross company results in V1 of REST without passing in the Company header or changing the company in your session.

2 Likes