none
runbook scheduling and how to better control complicated dependcies RRS feed

  • Question

  • We are trying to use Orchestrator tool to automate our nightly jobs with dependencies.

    I understand the dependency seems all controlled by the order of the link between each activity, or /and you can also invoke another runbook in the master runbook.  We used to use control-m which is easy to setup the dependencies, just set in condition, out condition etc.

    So in runbook, if we have a case of different runbooks depend on one runbook, we will have to put them all in one mater runbook, which is hard to give a name to include all the purpose in the runbook, and also the run book could become bigger and bigger if one of the activity has different other dependencies in other category/ folder.

    What is the best practice or the good architectures that handles dependencies between runbook or activities?


    SQLFriend

    Tuesday, August 13, 2019 10:42 PM

Answers

  • I am following this rules most of the time:

    Each Runbook will to one task/process -> Easier to name the runbook

    Name of the Runbook will be the "main task" the Runbook is doing.

    A simple example:

    Runbook 1: "Create AD User" (for instance: Create User Name, Create password, Send password to someone)

    Runbook 2: "Add User in AD Groups" (for instance: different AD Groups based on criteras)

    Runbook 3: "Create Exchange Mailbox for User" (for instance: Create Mailbox, set properties, set alias, ....)

    Master-Runbook: "AD User Onboarding" -> "Create AD User" -> "Add User in AD Groups" -> "Create Exchange Mailbox for User"

    Just as an simple example!

    Hope this helps.


    Andreas Baumgarten

    • Proposed as answer by Andreas BaumgartenMVP Wednesday, August 14, 2019 7:40 PM
    • Marked as answer by msloy Wednesday, August 14, 2019 7:43 PM
    Wednesday, August 14, 2019 7:40 PM

All replies

  • Using a "Master runbook" to invoke other Runbooks in the right order and linked Activities in Runbooks are the only options you have in Orchestrator to reflect dependencies of process activities.

    This is Best Practice or Good Architecture.

    But there are some simple "spoken words":

    "A complex process will be still a complex process if it is automated by a tool."

    "A crappy process will be still crappy if he is automated by a tool." 


    Andreas Baumgarten

    Wednesday, August 14, 2019 6:21 AM
  • Any recommendation of naming convention for master runbook and child runbook.

    If a master runbook include multiple activities across some categories, what is the best way to name it?

    thanks


    SQLFriend

    Wednesday, August 14, 2019 7:28 PM
  • I am following this rules most of the time:

    Each Runbook will to one task/process -> Easier to name the runbook

    Name of the Runbook will be the "main task" the Runbook is doing.

    A simple example:

    Runbook 1: "Create AD User" (for instance: Create User Name, Create password, Send password to someone)

    Runbook 2: "Add User in AD Groups" (for instance: different AD Groups based on criteras)

    Runbook 3: "Create Exchange Mailbox for User" (for instance: Create Mailbox, set properties, set alias, ....)

    Master-Runbook: "AD User Onboarding" -> "Create AD User" -> "Add User in AD Groups" -> "Create Exchange Mailbox for User"

    Just as an simple example!

    Hope this helps.


    Andreas Baumgarten

    • Proposed as answer by Andreas BaumgartenMVP Wednesday, August 14, 2019 7:40 PM
    • Marked as answer by msloy Wednesday, August 14, 2019 7:43 PM
    Wednesday, August 14, 2019 7:40 PM