A disabled data directive is still firing

[SteveFossey]

This is really puzzling me!

I wrote about my SalesForce integration where disabled directives were blocking the next steps:

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 …

This is the same directives and Sales Order “ecosystem” but it’s the opposite issue.

I automated the copying of PROD into DEV using PowerShell last year.

I include in my script a line to disable integration-related directives:

Invoke-Sqlcmd -ServerInstance SRV-EPI-DSQL -AbortOnError -Query "update UserIssues.ice.BpDirective set IsEnabled = '0' where DirectiveGroup = 'SalesForce2021' "

And I can confirm this is done:

I also do a final regeneration of the data model followed by a recycle app pool.

And yet when I create a quote, my event viewer registers a login (this text is output only from the data directive in question):

And that same directive cheerfully sends over the JSON payload to SalesForce!

And sure enough, with my name a clearly smoking gun, there’s the quote in Salesforce:

What the actual Frank is going on? How can a disabled directive fire?

And, anyone have any ideas on how to better disable or block directives programmatically? I’m thinking maybe unticking “enabled” does more than just setting the database field.

[jgiese.wci (Joshua Giese)]

Enable disable does have file system implications. Using code to DB update that, won’t disable/enable it.

[SteveFossey]

@jgiese.wci many thanks for pointing this out. I suppose it should be obvious but anyhow, it’s exactly right. Once I re-enabled and then disabled my directives, they don’t fire. So my approach in disabling them via powershell is not valid.

If I had time I suppose I could use a REST call from powershell but it strikes me, there are already widgets for conditions like “if this is in Production” - probably for a reason.

[jgiese.wci (Joshua Giese)]

I would use a widget to detect production or not, a no maintenance solution for the most part!

[timshuwy (Tim Shoemaker)]

I see you have the answer… but as @jgiese.wci suggested, I would also implement a standard in your BPMs to look at a place in the database to determine if this is a live or test/dev environment. There is a relatively new field in company maintenance that you can check… and if it is not true, then don’t run, or, at least make the BPM do something different in LIve vs Dev.

[jgiese.wci (Joshua Giese)]

@timshuwy

There is a relatively new field in company maintenance that you can check

Problem is in a restore from prod situation this comes along for the ride as live. The built in live flags can get screwed up when restoring from other DBs. I wish it were just in the web config “This is my production app server” tied directly to IIS. The production flag in admin console isn’t solely tied to the app server either. My understanding is for cloud customers that’s not a solution either, but having the live flag stored in the DB is only so so helpful.

[SteveFossey]

More recently I’ve been coding in a “debug mode” based on detecting this.session.AppServerURL and then taking different actions based on whether the server is A or B or the AppServer name is Production, Pilot, DEV, etc.

I wasn’t doing that back when we built this. I can see the “Is Live” flag being useful for devops teams but in this case it’s just me and the bots. And everything Dev restored from Prod.

Thanks for the help everyone!