There is no general setting to unschedule workflows on demand.
Depending on how you start the workflows in production, there may be a "dirty" trick. This requires that you don't start workflows via the PowerCenter scheduler but via a third-party scheduler (such as Autosys, UC4, Tidal, and all the other products):
Define a second workflow in PROD which has the same name as the Integration Service in DEV. This Integration Service is never enabled, it just exists. This means that whenever you deploy a workflow from DEV to PROD it remains assigned to the Integration Service but will never run due to the PowerCenter scheduler because this Integration Service does not run.
Of course this is possible solely if you start all workflows via some pmcmd script because you can extend these pmcmd scripts to start those workflows on some particular Integration Service.
Honestly I don't have a clue whether this would work. I've never tried it myself yet, so it might well be that this ridiculous idea doesn't work at all.
The problem with "pmcmd unscheduleWorkflow" is that this removal of the scheduled execution is only valid until the Integration Service restarts the next time. That's the big difference between "pmcmd unscheduleWorkflow" and unscheduling a workflow in the Workflow Monitor on one side and unscheduling a workflow (resp. setting it to Run On Demand) in the Workflow Manager; only this latter task (in the WF Manager) will be saved to the repository, making sure that the workflow cannot be run when the Integration Service restarts.
From this point of view I don't see any other way but to edit the workflows in production in order to unschedule them UNLESS you're working with an external scheduler (see above) AND my dirty trick works.
You can disable the workflow, so it won't run on the integration service initialization. Below are the steps:
Workflow -->edit --> General tab
Runtime Options --> check disabled.
But this de-scheduling cannot be automated. And as of my understanding Alyssa wants to have these workflows unscheduled automatically.
Please correct me if I'm wrong.
The way we've done this is to have a separate workflow configured to run on service startup, which runs a script which checks to see which environment it's on, and if it's not in production, runs pmcmd unschedule commands for every workflow that we want to unschedule.
Okay,, but will it allow the wf to run on its scheduled time if we run pmcmd unschedule commands? Like if the wf is scheduled to run at 11pm and the services are restarted at 10pm. So the wf should not run at 10pm though it should continue to run at 11pm.
Ideally the workflow should only run at its schedule and not when the service is restarted. I think the option 'run on integration service initialization' is questionable, but then there is no other way to schedule using inbuilt scheduler.
Please correct me, if I am mistaken.
Thanks for your post.
Alyssa's issue was that her scheduled workflows would automatically schedule themselves in Dev every time the Integration Service is restarted. In this case, a script that runs on service startup that inspects the environment to determine if it is Dev or Prod, and in Dev unschedules your workflows, will work. We use this same procedure.
If the issue is that you have scheduled workflows that are running on service startup as well as at the scheduled time, then make sure the "Run on Integration Service initialization" option is unticked. There's no need to have this set if you just want them to run on a steady schedule.
Not sure if this will help, but this is may be a solution (very crude description here) -
1) Dummy workflow scheduled at start of Integration service which creates a dummy flat file
2) All workflows in dev/production environment have a reusable mapping/session which checks for the existence of this file. If the file exists, the workflows stop.
3) When you move your code to production, all you have to do is disable the dummy workflow (scheduled on start of IS), thereby never creating the dummy flat file.
Let me know if it makes sense