Random Friday thought: After we our monthly refresh of our development environment from live, the BPM’s act like they aren’t enabled. We go through each one by one in method and directives maintenance, uncheck “enabled”, save, and then re-check “enabled” (BpDirective.IsEnabled).
Why should this be needed?
The environment version hasn’t changed (10.0.700.4).
I’ll probably create an updatable BAQ to speed it up (I requested it be added to DMT too).
Have you used directive update before? Depending on how your BPMs are grouped this will work well to resolve this. Are they truly not enabled or just require that to be toggled?
That is because in version 10.0.700X the BPMs are compiled when enabled onto a DLL which is dynamically loaded at runtime. When you move / restore databases those DLLs are out of date so re-enabling them or running the Directive Update as @danbedwards suggested regenerates the DLLs and puts then back in action.
This is a legacy function from the ABL days where each BPM generated a .P file when enabled.
As of 10.1 though BPMs are compiled to ram and stored in the DB as blobs, so starting in 10.1 you don’t have to do that any more. (Unless you specifically request to generate the physicall DLLs for development reasons)
It is also worth noting that in 10.0 if you run multiple app servers you will sometime have to “enable” the BPM on both app servers or copy the DLLs over (if you are not using a shared directory) one of those “fun” things to do.
That is nice…cant wait to 10.2 !!! thanks for the info.
Pierre
Thanks guys!
@danbedwards - I haven’t tried that yet, but am right now. That’s a much easier way of doing it!
@josecgomez - We have multiple app servers. What do you mean by “enable the BPM on both app servers”? Is this something on the admin console? Or am I back to doing each one by one instead of the directives update module?
Thanks for the history, by the way! It makes it a little easier to understand Epicor’s thinking…
Use the directive update 
that saves you time. But yes you’d have to re-compile on each app server unless you set it up with the shared resources stuff. It has been a few months since I messed with this so take this last tidbit with a grain of salt.
@josecgomez - I log in to my local client, which connects to App01, and run directive update to re-compile them. Do I need to remote desktop into our other plant (halfway across the country) to App02, and do the re-compile?
I also get the following error on several of the update groups, even after manually enabling/disabling in Method Maint. Last week I did adjust the change logs in live, but left the test env as-is. What is the message telling me?
Thanks again!
Server Side Exception: Cannot set unknown member 'Ice.Lib.Bpm.Model.Actions.ChangeLogAction.PrimaryTable'.
Exception caught in: Epicor.ServiceModel
Error Detail
============
Description: Cannot set unknown member 'Ice.Lib.Bpm.Model.Actions.ChangeLogAction.PrimaryTable'.
Program: System.Xaml.dll
Method: WriteStartMember
Original Exception Type: XamlObjectWriterException
Framework Method: Transform
Framework Line Number: 0
Framework Column Number: 0
Framework Source: Transform at offset 178 in file:line:column <filename unknown>:0:0
Server Trace Stack: at System.Xaml.XamlObjectWriter.WriteStartMember(XamlMember property)
at System.Xaml.XamlServices.Transform(XamlReader xamlReader, XamlWriter xamlWriter, Boolean closeWriter)
at System.Xaml.XamlServices.Load(TextReader textReader)
at Ice.Lib.Bpm.Model.DefaultDirectivePersister.Load(String persistedInstance)
at Ice.BO.BpMethod.BpmMetaData.BpmInfoLoader.<GetMethodInfo>b__1(BpDirective row)
at System.Linq.Enumerable.WhereSelectEnumerableIterator`2.MoveNext()
at System.Linq.Enumerable.WhereEnumerableIterator`1.MoveNext()
at System.Collections.Generic.List`1..ctor(IEnumerable`1 collection)
at System.Linq.Enumerable.ToList[TSource](IEnumerable`1 source)
at Ice.BO.BpMethod.BpmMetaData.BpmInfoLoader.GetMethodInfo(String source, String methodCode)
at Ice.BO.BpMethod.Internal.CustomizationToolBase.LoadMethodInfo(BOMethod method)
at Ice.BO.BpMethod.Internal.CustomizationToolBase.TryCompileDirectives(BOMethod method, Guid[] inputDirectiveIDs)
at Ice.BO.BpMethod.Internal.CustomizationDirectiveHelper.UpdateAndValidate(IceContext db, BOMethod method, DirectiveUpdateInfo dirInfo, String company, String countryCode, String countryGroupCode, ICustomizationTool custTool)
at Ice.Services.BO.BpMethodSvc.UpdateDirectivesByMethod(String source, String methodCode, DirectiveUpdateInfo dirInfo)
at Ice.Services.BO.BpMethodSvcFacade.UpdateDirectivesByMethod(String source, String methodCode, DirectiveUpdateInfo dirInfo)
at SyncInvokeUpdateDirectivesByMethod(Object , Object[] , Object[] )
at System.ServiceModel.Dispatcher.SyncMethodInvoker.Invoke(Object instance, Object[] inputs, Object[]& outputs)
at Epicor.Hosting.OperationBoundInvoker.Invoke(Object instance, Func`2 func)
at Epicor.Hosting.Wcf.EpiOperationInvoker.Invoke(Object instance, Object[] inputs, Object[]& outputs)
at System.ServiceModel.Dispatcher.DispatchOperationRuntime.InvokeBegin(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage5(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage31(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.MessageRpc.Process(Boolean isOperationContextSet)
Client Stack Trace
==================
at Epicor.ServiceModel.Channels.ImplBase`1.ShouldRethrowNonRetryableException(Exception ex, DataSet[] dataSets)
at Ice.Proxy.BO.BpMethodImpl.UpdateDirectivesByMethod(String source, String methodCode, DirectiveUpdateInfo dirInfo)
at Ice.UI.App.BpDirectiveUpdateOperation.Transaction.ProcessDirectives(BpMethodDataSet methods, DirectiveUpdateInfo dirInfo, String statusText)Looks like an issue with change logs.You may have to re-create those specially if they were upgraded from 9
Yes you likely have to remote into your other app server and log on and re-compile directives there.
Gotcha, thanks.
I went into Data Directives Maintenance, and attempted to disable/re-enable a change log directive. Same error! We’ve been on 10.0.700.4 directly since GoLive in 2015, and didn’t convert up from 9. I’ll see if I can delete and re-create it from scratch. Hopefully that’s not needed on all 20 change logs.
Update - Epicor errors out with the same as above when I disable, re-enable, then save on a existing or new change log data directive. I’ve put in a case with EpicCare.
@josecgomez Dear Jose,
When we go through auto-uplift (either by Epicor Cloud Services or locally via upgrade workbench) from 9.05.702a to 10.1.600.16 there are some BPMs that already work in the system, and others, the ones with code, which we fetch from Solutions we’ve built before going forward. Are the ones that came through the uplift from E9 subject to this requirement to disable, enable, save, for us to have confidence they’re enabled?
Thanks
…Monty.
In 10.1 you don’t need to worry about this since the BPMs are compiled into the DB and loaded dynamically
The error I was getting went away once I copied the newer .DLL’s on the server from LIVE back onto PILOT. There’s been so many SCR’s on 10.0.700.4, and we didn’t track them very well in the beginning. Oops. 
That let me enable the change logs in Data Directives, and also do a recompile in Directive Update.
Thanks for your help, guys!