Azure自动化图形Runbook - 无法在自动化帐户中执行其他Runbook作为不同的画布活动？

Question

图形编辑器UI似乎允许添加Workflow Runbooks（仅限;不显示Native PS），但这会破坏GraphRunbook定义/执行。

当我尝试测试或发布Runbook时，我收到图像中的错误。 （同样奇怪的是，这个错误信息已经在第一部分的西班牙语和下半部分的英语组合中呈现。）

自动化帐户中的其他Runbook是否在技术上不受支持..

testtwo代码：

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

    write-output "testtwo runbook output"       
}

Answer 1

您收到的错误消息来自我们当前正在积极解决的实时网站问题。

Answer 2

我设法以相对反直觉的方式使用它。 （至少，对于如何解析非图形工作流程表以执行依赖关系以将Runbook复制到工作人员而言，反直觉）。

我没有将Runbook添加到画布，而只是在MyCodeActivity的代码编辑器配置中将调用添加到另一个Runbook。

基于与Orchestrator.GraphRunbook.Model.dll（Azure自动化图形创作SDK）捆绑在一起的ReadMe.docx，结合the learning experience here，特别是WRT InlineScript活动（其中，afaik基本上是代码活动翻译的内容） to），我不希望能够在InlineScript的上下文中执行另一个Runbook，因为（来自自述文件）..

  

执行引擎会将提供的块视为黑盒子，   并且不会尝试分析其内容，除非是   基本语法检查。

..在Native PS Runbook的情况下，意味着它们不会被复制到工作者。不幸的是，我从来没有测试过执行的同行工作流程表（没有在别处引用，所以它们会被复制到工作者），部分原因是假设InlineScripts中的代码没有被解析为依赖的Runbook，但也许这只是对于Native引用（似乎对我来说是一个可疑的区别）？

无论如何，以上似乎是一种解决方法。

但是，我希望Runbook在设计画布上（以及在生成的序列化模型中）被视为一等公民，而不是被锁在脚本活动中，因为我正在努力捕获依赖项超出依赖顺序的自动化CI / CD部署定义。 （也就是说，我已经对正常脚本的依赖性检查进行了粗略的传递，所以这应该足够 - 只是意味着更多的解析。）