Azure Automation Graphical Runbook - Can't Execute other Runbooks in Automation Account as distinct canvas Activities?

Question

The graphical editor UI appears to allow adding Workflow Runbooks (only; Native PS do not appear), however, this breaks the GraphRunbook definition/execution.

When I try to either Test or Publish the runbook, I receive the error in the image. (Also strange, this error message has been rendering in a combination of Spanish for the first part, and English for the second half.)

Are other runbooks in the Automation Account technically not supported.. yet?

testtwo code:

workflow testtwo
{
    [outputtype([string])]
    [cmdletbinding()]
    param()

    write-output "testtwo runbook output"       
}

Answer 1

The error message you are getting is from a live site issue that we are currently actively working to resolve.

Answer 2

I've managed to get this to work in a relatively counter-intuitive manner. (At least, counter-intuitive to how non-graph Workflow runbooks are parsed for dependency execution to copy runbooks to workers).

Rather than add the Runbook to the canvas, I simply added the call to the other runbook in the code editor configuration for MyCodeActivity.

---

Based on the ReadMe.docx bundled with Orchestrator.GraphRunbook.Model.dll (Azure Automation Graphical Authoring SDK), combined with the learning experience here, specifically WRT InlineScript activities (which, afaik is essentially what the Code Activity is translated to), I would not expect to be able to execute another runbook from within the context of InlineScript because (from the ReadMe)..

the execution engine will treat the provided block as a black box, and will make no attempts to analyze its content, except for the very basic syntax check.

.. which in the case of Native PS runbooks, means they don't get copied to the worker. Unfortunately I never tested executing peer workflow runbooks (that weren't referenced elsewhere so they would be copied to the worker), partly because the assumption was that code inside InlineScripts is not parsed for dependent runbooks, but maybe that's only for Native references (seems a dubious distinction to me)?

Anyway, the above appears to be a workaround.

However, I was hoping that the runbooks would be treated as first-class-citizens on the design canvas (and in the resulting serialized model) rather than being locked up inside a script activity, because I'm working on fishing dependencies out of the definition for automated CI/CD deployment in dependency order. (That said, I've already got a rough pass at the dependency checking for normal scripts, so that should suffice - just means more parsing.)