使用工作流定义语言描述 Azure 逻辑应用工作流

12 分钟

使用 JSON 文档定义 Azure 逻辑应用工作流的结构和工作流。本文档包含组成逻辑应用工作流的元素的 JSON 描述，工作流定义语言架构会验证它。解释该架构的最简单方法是检查使用 Azure 门户中的工作流设计器创建的现有工作流，然后查看逻辑应用的 JSON 描述。

在示例场景中，你想要为顾问提供通用的工作流，以便他们能够适应与之合作的大学的特定需求。你想要尽可能轻松地定制和部署每个工作流，因此决定查看工作流背后的代码，即工作流定义 JSON。

工作流设计器

工作流设计器让你能够以图形方式创建和调试逻辑应用的工作流。通过设计器，开发人员还可以查看工作流底层设计，了解工作流的实现方式。下图显示了一个简单的工作流示例，该工作流通过向指定 URL 发送 HTTP GET 请求来触发。在 HTTP 响应中返回结果。在此示例中，工作流正在发回一个简单的“Hello Logic Apps Template!”消息。

关系图显示工作流设计器概述。

现在让我们看一下 JSON 模板使用的工作流定义语言。

代码视图

“代码视图”窗口显示描述工作流的 JSON 文档。在示例应用中，JSON 如下所示：

{
    "definition": {
        "$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
        "actions": {
            "Response": {
                "inputs": {
                    "body": "Hello Azure Logic Apps Template!",
                    "statusCode": 200
                },
                "kind": "Http",
                "runAfter": {},
                "type": "Response"
            }
        },
        "contentVersion": "1.0.0.0",
        "outputs": {},
        "parameters": {},
        "triggers": {
            "manual": {
                "inputs": {
                    "method": "GET",
                    "schema": {}
                },
                "kind": "Http",
                "type": "Request"
            }
        }
    }
}

请注意 definition 范围中与设计器中显示的操作和触发器相关的部分。可以编辑此文档中的 JSON 代码，以反映逻辑应用工作流功能中所需的任何更改。还可以添加更多操作，并指定工作流中的逻辑如何从一个操作运行到下一个操作。

触发器部分

triggers 部分包含触发器类型的描述以及调用方法。在此示例中，触发器是一个简单的 HTTP 触发器，它为响应 HTTP GET 请求而运行。

"triggers": {
    "manual": {
        "inputs": {
            "method": "GET",
            "schema": {}
        },
        "kind": "Http",
        "type": "Request"
    }
}

触发器必须包含以下元素：

工作流内唯一的名称。在前面的示例中，触发器的默认名称为 manual，但可以将默认名称替换为更有意义的标识符。
触发器类型。该类型指示导致触发器运行的事件。 Request 触发器为响应 HTTP 请求而运行。其他可用的触发器类型包括：
- Recurrence 用于创建根据定期计划运行的触发器。
- HttpWebhook 用于侦听终结点上的事件。
- ApiConnection 用于响应由其他 Azure 服务触发的事件，例如到达消息队列的消息、电子邮件消息等。 ApiConnection 触发器类型是通用的，可以指定进一步的详细信息、指示服务的类型以及所需的任何连接信息。
inputs 部分。本部分指定了定义触发器行为的数据。对于请求触发器，method 指示将导致触发器运行的 HTTP 请求的类型。对于 ApiConnection 触发器，inputs 部分包含有关如何连接到触发事件的资源（例如，消息队列连接字符串）的信息。如果触发器是 Request 触发器，则输入定义的 schema 部分指定了请求正文有效负载应该遵循的架构。 HTTP GET 请求没有请求正文，因此上面示例中的 schema 为空。

以下示例显示了另一个 Request 触发器的定义，用于启动工作流并接收 HTTP POST 请求。 POST 请求通常提供请求正文，其中包含要发布的数据。此示例中的请求正文包含客户名称和地址，包括街道和城市。

"mypostrequest": {
   "type": "Request",
   "kind": "Http",
   "inputs": {
      "method": "POST",
      "schema": {
         "type": "object",
         "properties": {
            "customerName": {
               "type": "String"
            },
            "customerAddress": { 
               "type": "Object",
               "properties": {
                  "streetAddress": {
                     "type": "string"
                  },
                  "city": {
                     "type": "string"
                  }
               }
            }
         }
      }
   }
}

触发器还可以指定条件。触发器仅在满足这些条件时才会触发。可在可选的“条件”部分中定义条件。例如，你可能希望仅在请求正文指定城市为 mypostrequest 时才运行上面示例中的 New York 触发器：

"mypostrequest": {
   "type": "Request",
   "kind": "Http",
   "inputs": {
      ...
   }
   "conditions": [
      {
        "expression": "@equals(triggerOutputs()['body']['customerAddress']['city'], 'New York')"
      }
   ]
}

操作部分

逻辑应用的 actions 部分定义工作流的逻辑和结构。该部分包含一系列操作。操作是用于构建工作流的构建基块。操作采用输入并生成输出，这些输出将传递到工作流中的下一个操作。下表列出了不同的可用操作类型：

操作	说明
`ApiConnection`	向特定服务发送 HTTP 请求。通过此操作类型，可以将逻辑应用工作流与 Azure 功能（如 Azure 服务总线、Azure 事件网格等）集成在一起。该操作需要输入，其中包括用于访问服务的连接字符串，以及调用服务所需的任何其他信息和参数。
`Compose`	将多个输入和表达式组合到单个输出中。
`Function`	支持调用 Azure 函数。
`HTTP`	将 HTTP 请求发送到 HTTP 终结点，而不是 Azure 服务。
`Join`	将一组数据项作为输入，并生成包含由指定分隔符分隔的这些项的字符串。
`Parse`	使用指定的架构将 JSON 文档解析为一组标记。
`Query`	使用指定的条件筛选输入数组中的项。
`Response`	创建对 HTTP 请求的响应。
`Table`	从 JSON 对象数组生成 HTML 表。
`Terminate`	立即取消工作流。
`Wait`	在指定时间间隔内或在发生超时前暂停工作流。
`Workflow`	运行另一个逻辑应用工作流。
`Condition`	一组操作类型（`Foreach`、`If`、`Switch` 和 `Until`），可用于在工作流中实现编程控制流。可以遍历集合中的项，根据输入参数的值进行决策，并循环直到满足某个条件。
`InitializeVariable`, `IncrementVariable`, `DecrementVariable`, 和 `SetVariable`	定义、初始化、分配和修改可在工作流中的操作项之间传递的变量。

与触发器类似，每个操作在工作流中必须具有唯一的名称。在以下示例中，默认操作名称为 Response，但可以使用有效且更有意义的标识符。操作必须有一个 inputs 部分，用于指定操作所依据的数据。在“响应”操作中，可以指定要在响应消息中返回的表达式数据以及 HTTP 状态代码。

在我们基本的工作流定义中，该操作会生成一个 HTTP 响应，其中正文是一条简短的消息。

"actions": {
    "Response": {
        "inputs": {
            "body": "Hello Azure Logic Apps Template!",
            "statusCode": 200
        },
        "kind": "Http",
        "runAfter": {},
        "type": "Response"
    }
}

runAfter 部分指示操作在工作流序列中的运行位置。上面的示例中只有一个操作，所以它始终在触发器触发时运行。如果工作流有多个操作，则可在此部分中指定操作的名称和该操作的状态。如果 runAfter 操作以指定的状态完成，则该操作会运行。以下代码展示了一个示例。操作 mySecondAction 在 myFirstAction 之后运行，但前提是 myFirstAction 完成且状态为 Succeeded：

"actions": {
    "mySecondAction": {
        "inputs": {
            ...
        },
        "runAfter": {
            "myFirstAction": [
                "Succeeded"
            ]
        },
        "type": ...
    },
    "myFirstAction": {
        "inputs": {
            ...
        },
        "runAfter": {},
        "type": ...
    }
}

输出部分

使用 outputs 部分定义工作流在完成运行后可以返回的数据。你可以为每次运行工作流跟踪特定的状态或数据。可以使用 Azure 逻辑应用运行历史记录来检查工作流每次运行的输出，该运行历史记录可在 Azure 门户或工作流 REST API 中获得。

outputs 部分的格式如下：

"outputs": {
  "<key-name>": {
    "type": "<key-type>",
    "value": "<key-value>"
  }
}

工作流表达式

可以使用工作流表达式代替任何固定值、变量或常量。也可以通过在表达式的前面加上 @ 符号前缀在 JSON 字符串值中的任何位置使用表达式。例如，可在表达式中使用函数来检索命名参数的值（参数将在下一节中介绍）@parameters。

"customerFullName": "Bill Frost",
"accountName": "@parameters('customerName')"

Azure 逻辑应用提供了内置函数，可用于创建复杂表达式：

字符串函数：用于连接或拆分字符串、在大写和小写之间转换字符，以及搜索子字符串。
集合函数：用于检测集合是否包含与特定模式匹配的项、从集合中检索项以及组合集合。
逻辑比较函数：用于检测操作数是否相同、不同、数值大于或数值小于彼此。
转换函数：用于更改数据的类型或格式。
数学函数：例如 add、sub、div 和 mul 等。
日期和时间函数：用于分析和处理日期和时间。
工作流函数：用于检索有关传递给工作流操作的数据的信息。例如，parameter 函数（如前文所示）获取命名参数的值，body 函数（如前文所示）返回操作生成的数据。
JSON 和 XML 操作函数：用于分析和处理 JSON 和 XML 文档。

可以在 inputs 操作的 InitializeVariable 部分中定义变量，并可以使用表达式来操作这些变量。使用 variables 函数读取变量的值。以下示例使用 InitializeVariable 操作创建名为 myIntegerVariable 的整数变量，并将其初始化为 99。此示例还演示了类型为 Condition 的 If 操作。该条件使用表达式来测试 myIntegerVariable 变量值，如果它与值 100 匹配，则条件会使用 HTTP 操作来执行 GET 请求。

"actions": {
    "Condition": {
        "actions": {
            "HTTP": {
                "inputs": {
                    "method": "GET",
                    "uri": "http://dummyurl.com"
                },
                "runAfter": {},
                "type": "Http"
            }
        },
        "expression": {
            "equals": [
                "@variables('myIntegerVariable')",
                100
            ]
        }        ,
        "runAfter": {
            "Initialize": [
                "Succeeded"
            ]
        },
        "type": "If"
    },
    "Initialize": {
        "inputs": {
            "variables": [
                {
                    "name": "myIntegerVariable",
                    "type": "Integer",
                    "value": 99
                }
            ]
        },
        "runAfter": {},
        "type": "InitializeVariable"
    }
}

参数部分

使用 parameters 部分可以参数化工作流。在运行时，可以为每个参数提供值。可在工作流中任何使用常量或表达式的地方引用参数。

可以使用默认值添加参数定义。如果在运行时未提供参数值，则使用默认值。下面的示例演示如何定义名为 cityParam 的参数。该参数在 mypostrequest 操作的条件内使用。仅当请求文档包含与参数值匹配的城市时，它才会执行该操作。默认参数值为 New York：


    "definition": {
        "$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
        "actions": {
            ...
        },
        "contentVersion": "1.0.0.0",
        "outputs": {},
        "parameters": {
            "cityParam": {
                "defaultValue": "New York",
                "type": "String"
            }
        },
        "triggers": {
            "mypostrequest": {
                "conditions": [
                    {
                        "expression": "@equals(triggerOutputs()['body']['customerAddress']['city'], parameters('cityParam'))"
                    }
                ],
                "inputs": {
                    ...
                },
                "kind": "Http",
                "type": "Request"
            }
        }
    }
}