I have a Data Directive on both XFileAttch and XFileRef, each of which does nothing other than throwing an exception. What I was expecting to happen is that the Exception is thrown and the attachment doesn’t get attached. What actually happens is the Exception is thrown, and the file gets attached. I thought that Exceptions stopped/cancelled the transaction…I assume I am incorrect with that?
In regards to the BPM itself, I will add the logic to actually have it check for the necessary items once I figure out how to cancel it first
This is possible with a Method Directive. By the time the system is writing to the XFile tables, the doc is already on its way to the repository. If you run your logic at an earlier step in the process, you can halt the process.
Looking through my own system, I placed a pre-processing BPM on Ice.BO.Attachment.FileExists that checks for a DocType on the attachment and denies it if missing. I did this because we have older attachments without a classification that I was leaving in place, but wanted to classify documents going forward. FileExists fires before anything is uploaded or written to the DB. Halting that prevents writing to the DB.
EDIT: I also apparently needed to place a separate BPM that does basically the same thing on Ice.BO.Attachment.UploadFile to stop the upload itself.
Note that, as a general rule, you should always look to method BPM’s before trying data directives. DB rollbacks are more expensive than catching it earlier in the process.
THAT is what I was missing! I forgot all about the option to look for System BO’s rather than Product. Hell, I am going to have to rethink my entire life in Epicor with that little trinket of knowledge!
I take back my previous statement…while what you said makes 100% perfect sense, it does not seem to work that way for me.
For some reason, when I attach a file (either via drag/drop or clicking the “Add” button on a menu), no BPMs trigger that pertain to attachments. The only BPM that seems to get triggered is Erp.Proxy.BO.SalesOrderImpl, which fires 3 times. Once for the method GetNewOrderHedAttch, once for MasterUpdate, and the last for CheckComplianceOrderFail.
Unfortunately, GetNewOrderHedAttch is fired after the file is attached, so in this situation it would not work for me.
So I went into PO Entry and checked to see if any relevant BPM’s fired from that menu, and there was not. I had 3 POImpl’s get triggered, GetNePOHeaderAttch, CheckBeforeUpdate, and Update. Nothing else was triggered according to the tracelog.
I don’t see the system call FileExists or UploadFile in my trace log either, but it clearly does so since the BPM’s on them fire. I believe I actually had to decompile dll’s and just add a bunch of BPM’s that sent a message to the user when they fired. It was not easy to figure out what events fired in what order. I never got the solution I wanted (a single cutoff point), hence the stops on two separate BPM’s.
The only method in the Attachment class that I see called out in the trace is DocStarUploadFile. It shows up right before GetNewOrderHedAttch and the Update methods. Since you don’t mention that, I presume you’re using a different file storage solution. What are you using?
The ultimate goal here is that I want a BPM to fire where I can check the path of the file to see if drive letter (first character in the string) is either a P or S (our two shared/network drives) or, failing that, if the first 2 characters are \, indicating a UNC path. Basically, making sure that the file will be accessible for all users and not something on the users local machine.
If it is on the local machine then roll back the transaction and tell the user to try again.
The checks, error message, etc., are all simple enough…I just cant find the right BPM for it.
That would make sense. You’re not actually moving any files. We used to use File System to push everything to a dedicated file server. Wouldn’t that fix your issues too?
