I’m searching information about doing “transactions” in the Epicor 10 REST API.
What I mean here by transaction is the equivalent of ODBC or SQL transactions where you can rollback a series of calls to the API in case something went wrong, or commit them if everything went well.
I’ve searched the Epicor ERP REST Implementation 10.2.200 document, and I couldn’t find any information on this topic.
In the world of REST, which is pretty much stateless and disconnected, is it even possible to call multiple services endpoints/methods, and “commit” those calls at a later stage?
If not, how is this handled so that writes are “ATOMIC”?
So the way I handle this with my integrations is to basically use a model where I write the data to one location during the transaction and another system pulls the data from that location. Like you said, RESTful architecture is not designed for “transactions” in the way that a SQL transaction is handled.
In the model I described above, you are minimizing your risk for a transaction not committing because you’re queuing the data elsewhere and then polling it with another system. Then, your REST API comes into to play when actually consuming data.
If you have an actual problem to solve, it might be good to explain it and then come up with a good solution while utilizing the REST api.
What @Aaron_Moreng said. For who @Bart_Elia calls, RESTafarians (people who strictly follow the architectural style Roy Fielding defined), a REST call is atomic. REST is not WEB-RPC. Using hypertext as a procedure to change state in a system is a different mindset than many of us are used to but it does simplify a lot of other things when dealing with web transactions.
The Electrical Engineering team uploads the machine’s BOM to Epicor through an Add-In of their engineering software. This is the code I’m working on. It used to be that under Vantage, we would use ODBC transactions.
The customer’s workflow requires the creation of a new PartRev every time a new release/revision of the electrical BOM is done. They don’t want to modify the existing PartRev, they want a new one created.
I think I’ve nailed down how to make the actual BOM upload “transactional” within the EWB, but the creation of the PartRev itself, which must be done before checking out the part in the EWB, is unfortunately not part of that transaction.
I’m looking for a clean way to make sure that if anything goes wrong when I do the EWB CheckIn, then the PartRev should also be “reverted” (in this case it means deleted).
Otherwise, I end up with PartRevs that are created, but become empty shells.
Maybe there is a EWB specific method that would allow all those steps to be done atomically?
Yes, it is my understanding that a REST call is in itself atomic, but since I’m not in control of what the service endpoints do, I must figure out a way to implement the atomicity myself, if at all possible.
I guess the saying that “you can’t teach an old dog new tricks” has a ring of truth in my case I’m sure I’ll figure something out, but I want to stand on the shoulder of giants rather than reinvent the wheel.
Forgive all the “proverbs”, I felt they applied well
I think you already know how to solve this problem. Breaking it down into it’s simplest components and steps is what I would do. The workflow checks and balances would need to be defined, but the calls themselves are simple and atomic.
Think of the REST API as a vehicle without knowledge of the “state” of anything. It’s simply a vehicle to pass data between entities over HTTP. It’s up to the developer to decide when and what to call, so your complex logic would need to be handled internally.
One could utilize the API in such a way as to create your own RPC by exposing a BAQ and then calling custom code within the execution of the BAQ. But, if it were me, I’d probably not opt for that route unless necessary.
Since you’re always creating a new Rev, you don’t have to check out the previous Rev. EWB allows you to create a new Rev as well (See Action menu).
Although, if the company only allows one approved rev, you’ll need to unapprove the previous Rev. which you might be able to do with a BPM on the CheckIn method.
This sounds interesting. Allow me to pick your brain a little bit more.
So, if I understand what you said, I could checkout the Part only, and only then create the new PartRev? I was under the impression that I had to specify the Revision Number when calling Erp.BO.EngWorkBenchSvc/ExpressPartCheckOut
Then, at the end of the BOM upload process, calling Erp.BO.EngWorkBenchSvc/ApproveAndCheckInAll would also “wrap” the PartRev creation?
I tried a few things, and here are my observations:
You can’t Checkout a Part. You have to Checkout a PartRev. If a Part has no PartRev, you can’t check it out.
After creating a PartRev and checking it out, I can indeed create yet a new PartRev, but even if I Undo Checkout, that new PartRev remains in the system.
It seems like I’ll have to either use a “flag” to mark that PartRev as “unused”, or manually delete it in case the Check-In fails.
Might be easier. In EWB, do a “New Part Revision” on the Actions Menu. You’ll need to assign a Part, Rev, Effective, etc. No Checkout required since you’re not changing any existing Rev.
You MAY need to unapprove the current Rev upon check-in though depending on the companies policies.Check-Out was doing that for you.
While unlikely to get errors checking in, you can check for success afterwards with another call.
Please bear with me, I’m admitedly very green at this.
In EWB, I have this:
When I call this “New Revision” menu point, it does go through the motion of creating the PartRev.
Then I also have this:
It may be where I’m misunderstanding what Epicor’s EWB does. In my mind, undoing a checkout should throw away the changes I made to the part while it was checked out.
Unfortunately, the PartRev still remains after Undo Checkout. So it seems the two actions are really not meant to be “atomic”.
In our current REST call to Erp.BO.EngWorkBenchSvc/ApproveAndCheckInAll, we check if the HttpStatusCode is “OK” (we’re using C# and the HttpRequestMessage class). If the HttpStatusCode is not “OK”, then we throw an exception, which allows us to then call EngWorkBenchSvc/UndoCheckOut inside the catch block.
In my mind, UndoCheckOut gets rid of any Part Materials added while we were checked out, but apparently, it doesn’t get rid of the PartRev.
I’m really sorry if I’m completely off track here, and I want to say that I REALLY appreciate your time and help. If we were sitting next to one another, you’d already have a glass of your preferred poison in hand
So, at this point, it seems there is really no way to “undo” the PartRev creation atomically. I’ll have to either delete it within my catch block, of flag it as “unused” or whatever so that when I call my routine again, I don’t need to create a new PartRev. I’m just not sure which of those two paths will not lead me down the cliff
You would only do an Undo Check Out to an existing Rev and was checked out. In this case, you are not checking out an existing Rev so no need to do an Undo Check Out.
If you delete the group once finished, any Rev not checked in successfully would be deleted along with the group. The ECO Group is a copy of the files (Rev, PartMtl, PartOper, etc.) and they only get moved to the new home upon Check In. So you can Check In a Rev that you never Checked Out if it is a new Rev. Check In is atomic in this respect.
I’ll have to manually test the use case, but as luck would have it, my Dev server just crashed. Actually, the MS SQL backend went offline for whatever reason.
Grrrrr… I wanted to work on this over the week-end, and now I fear what the IT guys will tell me…
When I think about it, this is a general practice in Epicor. Don’t want new AP invoices to post? Delete the group. Don’t want GL entries to post? Delete the group. And so on.
I tested the scenario (server is back online), but I’m getting the following error in the Epicor UI:
In the EWB, I created an ECOGroup. I then created a Part Revision, as we discussed earlier, by going to the Action > Revision > New Revision menu point.
This asked me to select a Part, and assign a Revision number, as expected. Just for testing purposes, I then added a Material to my Part Revision.
Now, as suggested, I try to directly delete the ECOGroup, but I get the above error message. I may be missing a step?
This Revsion “6” is the one I just created, but that Part has another Revision “0” visible in the Part Maintenance.
Now I can’t simply delete the “lucm” group. Should I “Undo Checkout” on Revision 6 first? Seems to me this “saves” the Revision and it becomes visible in Part Maintenance.
I’m sure I’ll figure something out, but I want to stand on the shoulder of giants rather than reinvent the wheel.
