BPM revision numbering was reset

Epicor ERP 10
1

The source for method directive BPMs is stored in C:\inetpub\wwwroot\{environment}\Server\BPM\Sources\BO\{service}.{method}\{revision}\. Every time you modify any BPM on a method, a new revision folder is created.

Sometime between 6/20 and 6/23, the revision counters on many of our BPMs started over at 1. I don’t think we modified any BPMs that day, let alone so many of them, but there are a bunch of revision 1 folders dated 6/23. BPMs that we have modified since that date are being assigned revisions 2, 3, etc. This means that the history of old revisions is being lost. (I made a backup.) Even stranger, I found one BPM with a revision number folder named 1.2019.06.23.08.39.42. It should have been 2.

Has anyone ever seen this before?

2

The weirdly named revision folder definitely seems to have something to do with it. Its name is obviously a timestamp, and it’s one second before a whole bunch of other BPMs had their revision 1s overwritten:

$ find ./ -name '1' -printf '%TD %TT %p\n'
04/26/18 17:16:01.4145020000 ./ARInvoice.GetList/1
06/23/19 08:39:43.5343128000 ./Customer.GetNewCustomer/1
06/23/19 08:39:44.2374599000 ./Customer.GetNewShipTo/1
06/23/19 08:39:44.7531049000 ./Customer.Update/1
06/23/19 08:39:45.1593650000 ./CustShip.GetHeadOrderInfo/1
06/23/19 08:39:45.6906342000 ./CustShip.UpdateMaster/1
06/23/19 08:39:46.3000261000 ./JobEntry.Update/1
06/23/19 08:39:46.7531684000 ./MiscShip.GetNewMscShpHd/1
06/23/19 08:39:47.0344248000 ./MiscShip.Update/1
07/17/18 08:16:58.1664688000 ./Part.GetNewPart/1
06/23/19 08:39:48.6126037000 ./Part.Update/1
06/23/19 08:39:49.5813807000 ./PO.ChangeVendor/1
06/23/19 08:39:49.9407676000 ./PO.Update/1
06/23/19 08:39:50.3626561000 ./Quote.ChangePartNum/1
06/23/19 08:39:50.8224266000 ./Quote.Update/1
06/23/19 08:39:51.2911952000 ./SalesOrder.ChangeCustomer/1
06/23/19 08:39:51.6349549000 ./SalesOrder.ChangePartNum/1
06/23/19 08:39:51.9474654000 ./SalesOrder.ChangePartNumMaster/1
06/23/19 08:39:52.2912235000 ./SalesOrder.ChangeSoldToContact/1
06/23/19 08:39:52.4791227000 ./SalesOrder.DeleteByID/1
06/23/19 08:39:53.0260125000 ./SalesOrder.GetByID/1
06/23/19 08:39:53.7499078000 ./SalesOrder.GetNewOrderHed/1
06/23/19 08:39:54.0624177000 ./SalesOrder.MasterUpdate/1
06/23/19 08:39:54.4061800000 ./SalesOrder.ReopenOrder/1
06/23/19 08:39:55.3447817000 ./SalesOrder.Update/1
3

I don’t have suggestions, but I did take a look at my own BPM revisions. A couple of them have the oddly named folders. They didn’t overwrite anything:

07/13/17 07:35 ./15
07/13/17 07:38 ./16
07/13/17 07:39 ./16.2017.07.13.07.39.41
07/13/17 07:40 ./16.2017.07.13.07.40.11
07/13/17 08:28 ./17

That BPM is up to number 29 and they’re still all in order.

4

@Ashley Do any of your other BPMs have a revision 16 with a timestamp a few seconds after 2017/07/13 07:40:11?

5

No, none of the others got that high. Have you looked in BPM/Builds/BO though? I have a folder there for each of the oddly named ones in BPM/Source/BO, and they all have an error log.

6

My BPM/Builds/BO is empty.

7

I played with this a little in my test environment. The folders with the timestamp are created when the folder that Epicor wants to use for the next revision already exists. If you go into a BPM source tree with revisions 1-5 and create a folder named 6, the next folder Epicor creates will be named 6.{timestamp}. Apparently this happens a lot. I’ll play around more and see if it has something to do with deploying solutions from one environment to another.

8

The picture gets more complicated if I look at those folders in my dev environment…One method that sees a lot of changes goes from 23 to 80, then starts over at 15, and starts timestamping when it reaches 23 again. And the error logs in Builds are clearly compilation errors normally seen when trying to save a directive with custom code. Do you have anything in BPM/Builds/BO for your test environment?

9

I created and tracked to a new solution, then created a new BPM on a method that had never had any BPM, and revised it twice to create revision 3. Then I built the solution and installed it in another environment. The solution actually contained the data for revision 3, but the target environment named it revision 1.

Still pondering how this might be related…