No, the ECOGroup field is empty.
Something to keep in mind with undo checkout, whenever you undo checkout, it reverts back to it’s previous ops and materials, but the revision is now unapproved, so you have to go into part maintenance and approve it to be able to use it.
1 Like
Hi Brandon,
The final goal is to be able to “mimick” a rollback in EWB while working on it through the REST API. For this workflow, the customer wants a Part Revision created each time, so I’m never working on an existing Revision.
I’ve tried many workflows in the Epicor UI over the week-end, trying to find the perfect combination of steps, with the goal of replicating them in REST, but I was never able to get to a point where I could simply delete an ECOGroup, and see all the changes in it “disappear”. which is what a rollback would typically do.
As you mentioned, undoing the checkout, even if the new Part Revision was created in the context of the EWB, does not delete the Revision object, but rather leaves it as an “empty shell”, almost an orphan within the system. One now has to decide to either delete it, or re-use it.
I was (am still) hoping to find a way to rollback ALL changes in case anything goes wrong during EWB operations, such as InsertMaterialList, until the ApproveAndCheckInAll method is called in REST.
For the moment, I catch any errors that might happen during code execution after the EWB CheckOut, and explicitely delete the Part Revision created for that specific occasion.
I’d rather the Part Revision deletion was implicit, so I’m really wondering how this workflow should be handled. I’m sure I’m not the only one doing this kind of things in code, though I’ve been known to always trip onto those edge cases 
Thanks, and have a nice day.
I don’t know anything about the code aspects of doing it, but if I was just trying to roll back what you were doing in epicor, I would do undo checkout, then delete the revision that you created, then delete the ECO group. Since you have to add the revision before you add it to the ECO group, it would make sense that the revision is still out there even if you were able to delete the ECO group.
OK, I tried what I remembered and am getting the same behavior you’re seeing. I had to do a Clear All Ion the tree) to remove all operations and materials and then delete the Rev, just like you did.
So thinking out loud, maybe you can set the revision to a string like “*** ROLLBACK ***” and run a BPM to do the work above? Haven’t tried it but that might work.
Mark W.
Brandon,
Actually, In EWB, there is an entry in the Actions menu to “Add Revision” either before or after creating the ECOGroup. If you call it before creating the ECOGroup, the ECOGroup will be created as part of the wrokflow.
In either case, the Revision is displayed under the ECOGroup, which may have lead me to believe that doing so was “encompassed” by the ECOGroup “container”. It seems clear now that this is not the case, and that the newly created Revision is added to the Part no matter what.
WHat you described about the manual steps you’d take is exactly what I’m doing in code, but this is not “transactional”. At any step, you can have a network error etc., and you must manually finish the job.
In code, this is usually frowned upon.
Thanks
Hi Mark,
Thanks for confirming.
Now, just showing more “green”, I’ll have to read on BPMs, what they are, what they do, and how they might be of help.
Of course, if you feel like giving some hints… 
Cheers
I’m starting to think that @Aaron_Moreng’s first suggestion might be the way to go. You would use REST to load one of the UD tables with all of the rev information (with materials and operations). Use a field to indicate stage: “Loaded”, “Verified”, and “Success”. Use the stage to trigger actions to move to the next stage (see the BPM conditions).
The ICE User’s guide will show you how to call C# code from a BPM although there may be ways to call Business Objects without code. There’s probably an example by @josecgomez out here somewhere.
Now you have full traceability of what was loaded whether or not it was successful. It moves the logic back into Epicor and not stuck in your load program, which is cleaner.
Mark W.
Hi Aaron,
I’ve been busy with other things, but I’m now back to my Epicor REST API stuff, and I’d like to better understand the workflow you described.
-
When you say you “use a model”, are you talking about a user-defined REST model in Epicor?
-
When you say you “write the data to one location”, where is that? In UD tables in Epicor, or in some other DB (MS SQL for example)? This would definitely provide me with the “application level” transactional model I’m looking for.
-
When you say “another system pulls the data from that location”, which other system are you referring to? An Epicor instance?
-
Finally, when you say “queuing the data elsewhere and then polling it”, is the polling done in Epicor as well? Like some kind of business rule? I’d need a bit more information if you can, or at least the proper naming of what I’m looking for. Nomenclature is sometimes all that’s standing in the way
Thanks a lot for your time and help.
Hey, I’ll try to answer to the best of my knowledge but I didn’t read this entire thread so bear with me
- when I say model, I was referring to an architecture model of the system, just a high level overview.
- I write mine to a UD table in Epicor because it’s easy and you don’t have to deal with connecting to another database. You certainly could but that’s up to you.
- Another system, in my case, is a separate program like a windows service or a cron running on a linux machine. Really any program that can handle executing a task on a schedule.
- queuing the data = writing to the UD table, polling the data = separate program/service/whatever being told to go read that table and do something with the info in it. I have not done polling in Epicor because I think scheduling custom tasks is near impossible (at least for me).