Tier3 Products (877) 258 8411

Adventures with BPMs and the Propath

admin
04 / 01 / 2013

My background is in science, and I love experiments that expand my knowledge of a system. I had a hunch there was more than met the eye with BPMs and I wanted to understand how they really worked; I’d seen a few instances of unexpected behavior when databases were backed-up and restored that I wanted to more thoroughly investigate. Here’s my experiment, the results are interesting:

Step 1: I created a BPM on Customer.Update, pre-processing, with no conditions that simply showed “message 1″ as an informational message. There were no other BPMs on the Customer object at this time.

The result was that in the BPMExec\TrainingBPM\bo folder (under Epicor905\) there was a Customer directory created with both a Customer.p and a Customer.r file. If I disabled the BPM, these files were deleted. If I added another BPM to a different method (still on the Customer business object) the file size grew, but no new files were created. I was actually able to open up the Customer.p file in notepad and see the code in human-readable form, as it turns out all the BPMs for the Customer business object were put together in this one file. The .r file was the non-human-readable compiled progress file. This is expected, ABL needs to be compiled to run.

Step 2: I copied out the Customer folder that was created in the BPMExec\TrainingBPM\bo folder, and then disabled the BPM. Next, I copied the Customer folder with the Customer.p and Customer.r files back into the BPMExec\TrainingBPM\bo folder.

Now this gets interesting. The BPM is marked as disabled inside of Epicor, the checkbox is off; however, I manually copied the files back in as if it were enabled. When I tested updating a customer, guess what? My disabled BPM fired! My “message 1″ prompt was right there on the screen! It is therefore possible to have a disconnect between the database and the execution files. This explains some of the strange behavior I had seen with BPMs before related to backup/restores. The BPMExec folder is totally independent from the database representation of method/data directives and it’s simply the presence of the file with the business object name that causes them to be activated. So if I took my “Live” database and restored it to the “Test” database slot and had different BPMs previously in “Test” those BPMs would be what fired, not the ones from “Live”. To get around this you just copy down the appropriate database folder under the BPMExec directory as part of the restore procedure.

Step 3: Digging deeper – I opened up Open Edge and looked at the Propath settings for my primary appserver (for the Training appservers). Here’s what I found listed:

  • E:\Epicor\Epicor905\custom
  • E:\Epicor\Epicor905\bpmExec\TrainingBPM
  • E:\Epicor\Epicor905\CSG\Training\server
  • E:\Epicor\Epicor905\CSG\Training
  • E:\Epicor\Epicor905\Server
  • E:\Epicor\Epicor905

So my BPMExec\TrainingBPM folder is listed here, but what about the other ones? Ever curious, I set up another test ;-)

Step 4: I still had my “message 1″ bpm files copied to my desktop, so I deleted that BPM and created a second one on Customer.Update (again pre-processing, no conditions) and this time I made an info message with “message 2″ in the body. I saved this, and then copied the Customer.p and Customer.r files from the BPMExec\TrainingBPM\bo folder as well.

Step 5: Seeing that the Epicor\Epicor905\custom directory comes before the BPMExec\TrainingBPM folder I copied my “message 1″ .r and .p files there. I kept true to the other file path convention, so the full path was E:\Epicor\Epicor905\Custom\bo\Customer\Customer.p, Customer.r . My “message 2″ BPM was still enabled in the database, and those files were still in the BPMExec folder.

So what happened? When I tested by updating a customer I got “message 1″, but not “message 2″! I can safely hypothesize that the order of listed directories in the Propath actually determine the business object files that are grabbed for execution by the appserver and if found, the files “downstream” are ignored. Since I had Customer.p and .r files in the E:\Epicor\Epicor905\Custom\bo\Customer\ that took precedence over the Customer.p and .r files in E:\Epicor\Epicor905\bpmExec\TrainingBPM.

Step 6: Just to be sure, I removed my Customer directory and “message 1″ files from the  E:\Epicor\Epicor905\Custom\bo\ folder and put them into the E:\Epicor\Epicor905\CSG\Training\bo\Customer folder (again staying true to the file path conventions).  My “message 2″ BPM was still enabled, and those files were still present in the BPMExec folder.

love consistent data. Thankfully, Epicor worked as expected, and now when I updated a customer I got “message 2″. Since the BPMExec folder is before the CSG folder in the Propath this makes total sense. Perfect!

Step 7: I left the files in the E:\Epicor\Epicor905\CSG\Training\bo\Customer folder but I disabled my “message 2″ BPM in the database.  By disabling this I have no method directives on Customer as far as I can see in the database, but of course I know my secret .p and .r files are still in the CSG folder waiting…

Success! When I updated my customer I got the “message 1″ BPM, again as expected since these files are still evaluated by the Propath and there was nothing before them to activate first. Hypothesis confirmed :-)

What’s the moral of this amazing story? There is more going on than meets the eye… for instance the first directory in the Propath does not differentiate by database slot, so I have to assume that files placed there will be evaluated for all databases (more tests, science!). Likewise if I were to ever migrate a database from one server to another for testing (not just database slots) I would have to be very aware of copying out these files as well if they existed; otherwise, nothing would work as intended. With a few other tests I found that this applies to all custom ABL code, updatable BAQ’s and data-directives both have files stored in the BPMExec directory though with different sub-folders and naming conventions. This is not a surprise, but it is important to note. This also makes sense why these types of objects need to be completely recompiled after a service pack, the external files haven’t been touched so their source-code version would be different than the newly applied service pack against the database.

For more information on this, and other, topics please email info@alttechsolutions.com .