I'm looking for best practices on structuring jobs that may be used by multiple proejcts. For example an orders job may be used by Product Team and Finance. Currently the way we have our folders stuctured it is difficult to prioritize one project over another. There are times when I want to hold all projects unil Finance is done, but I need a couple of jobs out of Prod Development. Setting up dependencies and holding some jobs while letting others run then changing this when another group has priority or all groups have the same prirotiy becomes difficult to manage.
What I would like to do is have these types of jobs exist in all needed project folders. Whichever group has priority should run the job and the other projects that need it should have their copy of the job become completed noramlly at the same time. Kind of like a job Synonym.
Another way may be to setup an extra folder 'Common Jobs' that has a second job with dependencies to all the orignal jobs in each folder. In the dependencies tab I select at least one dependency must be met. All successor jobs in each folder will have the common object job as a dependnecy. If it has been met, successors take off. If not the first project to check will run the jobs.
Maybe I'm making it too complicated. Any other users have common jobs and chaging project prioritzation schedules?
Cisco Workload Automation (formerly known as TES) Customer Advisory Community
Hi Manny - Have you investigated using Job Classes and/or Queues to do the "holding" and "releasing". If I am understanding you, I think those will help you and cause you less headache than having multiple copies of jobs or multiple job dependencies.
I agree with Michelle, if i were you i would try using the resources and queues.. also i would recommend using Variables to lock the your "Common" job group when its being running for some instance and then make the last job within that group to reset (unlock) the variabel so the next iteration/project/occurence can be released automatically without your/operator's manual intervention.
This document explains the logic to develop Tidal Enterprise
Orchestrator workflow to automate the process of creating vCenter
Resource Pool* vSphere Power CLI must be installed either on the TEO
server or vCenter* vMA can also be used to achieve the same...
IntorductionCisco Process Orcehstrator (CPO) ships with the webservices
adapter that can be used to make Web Service API call to REST or SOAP
based applications. Before a sample workflow to make SOAP API calls
using CPO, lets understand some of the fundam...