Can a disabled data directive stop the next thing in line from executing?

We have a fairly complex Salesorder ecosystem, with a UI script and a whole barnyard of directives to allow us to enter all orders in one site, have them directed to the correct site based on proximity to customer, manufacturing location and current inventory, and do the same for web-based orders, among other things. The whole shebang runs and updates the order and releases when the user checks “Ready to fulfill”

I’m at the end of several months building a sync to salesforce, about to flip the switch this weekend. I’ve been jumping the gun a little, installing components without activating them, seeing as I finished piloting early.

I installed UD columns on Monday and imported my UIs today, verifying and validating without adding them to the menu. All seemed well.

Then I imported a data directive on OrderHed. It will run last of 4 in-transaction directives and is fairly simple:

  • IF there’s a new ttOrderHed row AND Ready-to-fulfil has been changed from true to false;
    * THEN set the OrderIsSynced_c field to False
    * THEN set the ForceSync_c field to False

Pretty basic, all done with widgets, and as you can imagine it’s just one little piece of the puzzle allowing Epicor to talk to Salesforce when it’s supposed to and not when it isnt.

I imported it, checked it wasn’t “outdated”, disabled it and saved changes. I had already piloted the change twice and tested both the old and the new UI with it in place.

A few hours later Order Entry found that all orders since then had unfirm releases. I checked and sure enough, creating an order and ticking Ready To Fulfill didn’t cause all the magic stuff to happen. I went through all the BPMs first visually then in Ice.BPDirectives, then comparing Ice.BPDirectives with the same table in my automatic dev environment from last night. No joy.

Then I deleted the already-disabled BPM, and behold and lo everything works again.

I can imagine best practice wouldn’t leave disabled BPMs lying around, but we don’t enforce that - sometimes you want to turn something off, and sometimes you only have BPMs for month-end tasks or the like.

Anyone come across this before? Bug or feature?

1 Like

I’ve had BPMS get stuck where I need to do a regen with refreshed sigs or a delete and recreate. I have had them do it out of the blue too where they just stopped working when other BPMS in the same BO are created saved.

1 Like

They should fire if disabled but I’ve heard of strange behavior. If you delete the imported BPM do you still have the issue?

That said, I usually make sure BPMs are disabled BEFORE I export them from Test/Dev database that way they import to LIVE in disabled state. Maybe something you could try for pre-go-live?

1 Like

Yes, that’s the thing that bugged me - disabled, not firing - but nothing else worked until I deleted it.

Good point - this was not thusly exported.

Then it maybe something like @jgiese.wci mentioned. Try disabling the BPM in your dev database them export/import it. See if that lets you pre-deploy to LIVE

That did cross my mind. In my deploys I do usually regenerate after every solution install, but the system didn’t prompt so I “assumed”…

I’ll try to replicate the behaviour in a fresh DEV before going live.

@Randy and @jgiese.wci looks like you’re both correct, I definitely want to package solutions with BPMs disabled, and the thing that nailed the execution issue it was regenerating after importing the solution.

Thanks for all the input.

1 Like