Starting on Monday, the OData endpoint in the title does not properly decode part numbers with a “/” in them. It returns a 500 with a correlation ID (which doesn’t appear in the appserverlogs either, so I can’t troubleshoot.)
Has anyone else seen this? I found another post from long ago with this issue, and the user was able to use the $filter properties to set the PartNum to search instead of using the PartNum field. That is not working either. Due to this, our EDI middleware cannot process any orders containing parts with a “/” in it. We’ve tried pre-encoding everything (i.e. %2F instead of /), too - nothing works.
My fear is that in anticipation of the move the Linux containers, Epicor changed how paths are decoded and not only didn’t tell us, they didn’t fully test (imagine!).
Starting this past Monday, we also couldn’t get to the Swagger page for v1 of the API. I have multiple tickets in, but the glacial pace of getting anyone to respond is driving me nuts.
Thanks for the suggestion, Mark. I believe the Parts OData endpoint is a wrapper for GetRows. I have tried the RPC version and it does work. I also tried the v2 version of the OData endpoint and it fails.
I’m just curious if someone is on 2025.2.10 in Cloud and has a part# in the system with a slash in it. I can’t determine if this is a me issue or a system issue.
Good suggestion - we did not get a hotfix over the weekend, however there was nginx maintenance done in production over this past weekend. I’m not sure if that could be the culprit for the failed call to PartSvc. I think it likely IS the culprit for another ticket I have in - I can’t access v1 of the API Swagger page.
Gabe’s tool hasn’t been finding the ID’s. I’m thinking it’s maybe because I have between10-20 log files being created per day. I don’t know if it’s built to search through all of that.
I just hate weird part numbers.
