Azure自动化图形Runbook-不能在Automation Account中将其他Runbook作为不同的canvas活动执行？

Question

图形编辑器UI似乎允许添加Workflow Runbook（仅；不显示Native PS），但是，这破坏了GraphRunbook的定义/执行。

当我尝试测试或发布运行手册时，在图像中收到错误。 （同样奇怪的是，此错误消息在上半部分以西班牙语显示，而在下半部分以英语显示。）

技术上还不支持自动化帐户中的其他运行手册吗？

testtwo代码：

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

    write-output "testtwo runbook output"       
}

Answer 1

您收到的错误消息是由于我们正在积极努力解决的实时网站问题。

Answer 2

我设法使它以相对违反直觉的方式工作。 （至少，与非图形工作流运行手册如何进行解析以进行依赖关系以将运行手册复制到工作人员相反，这是直觉的）。

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

---

基于Orchestrator.GraphRunbook.Model.dll（Azure自动化图形创作SDK）附带的ReadMe.docx，结合此处的学习经验 ，特别是WRT InlineScript活动（afaik本质上就是代码活动所翻译的活动），我不会期望能够在InlineScript的上下文中执行另一个Runbook，因为（来自自述文件）。

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

..对于Native PS Runbook，这意味着它们不会被复制到工作程序中。 不幸的是，我从未测试过执行的对等工作流运行手册（未在其他地方引用过，因此它们将被复制到工作程序中），部分原因是因为假设InlineScripts中的代码未针对相关的运行手册进行解析，但这也许仅用于本机引用（似乎对我来说是一个可疑的区别）？

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

但是，我希望这些运行手册在设计画布上（以及在生成的序列化模型中）被视为一等公民，而不是被锁定在脚本活动中，因为我正在研究从依依序自动CI / CD部署的定义。 （也就是说，我已经对普通脚本进行了依赖检查，这很容易理解，所以就足够了–只意味着需要更多的解析。）