I am getting the attached message when trying to save any change to bpm’s - even most basic tasks like changing from enabled to disabled. This is only happening in live, not in test and is only affecting existing method/data directives. If I try and add a new bpm within a method/table that already has a bpm I get the same error. The affected BPM’s are still working/triggering as expected within the system.
I initially thought something had changed with permissions and have spent quite a bit of time confirming IIS permissions on the appserver were ok and test and live IIS instance permissions are exactly the same. This is also happening even if I access Epicor on the app server where the bpm’s are stored and even using our domain admin account. Further testing within Epicor makes me think that there is something else going on.
In live if I go to a method/table that did not previously have a bpm on it, if I choose new, I am able to create and save a new bpm to the same directive group - with the bpm saving in the same folder in the folder that I am getting an access denied message on. Similarly if I try and edit and save these new bpm’s I am able to do so without issue. This would seem to indicate that there are no issues with IIS/file permissions on the server, just that Epicor itself cannot modify the files.
I have tried the directive update tool and it experiences the same behaviour, and it generates the same error. In case there was some kind of file locking going on I have cycled the servers/clint connections to both the application and database, on the server and all clients, all to no avail.
We are on version 10.0.7.4, and have no support agreement with Epicor. Has anyone else seen this kind of behaviour with BPM’s and if so can you please offer some suggestions as to what could possibly be going wrong and hopefully how to resolve.