Guia de referência de esquema para a Linguagem de Definição de Fluxo de Trabalho nos Aplicativos Lógicos do Azure

Quando você cria um aplicativo lógico nos Aplicativos Lógicos do Azure, seu aplicativo lógico tem uma definição de fluxo de trabalho subjacente que descreve a lógica real que é executada em seu aplicativo lógico. Essa definição de fluxo de trabalho usa JSON e segue uma estrutura validada pelo esquema da Linguagem de Definição de Fluxo de Trabalho. Esta referência fornece uma visão geral sobre essa estrutura e como o esquema define atributos em sua definição de fluxo de trabalho.

Estrutura de definição do fluxo de trabalho

Uma definição de fluxo de trabalho sempre inclui um gatilho para instanciar seu aplicativo lógico, além de uma ou mais ações que são executadas após o disparo de gatilho.

Aqui está a estrutura de alto nível para uma definição de fluxo de trabalho:

"definition": {
  "$schema": "<workflow-definition-language-schema-version>",
  "actions": { "<workflow-action-definitions>" },
  "contentVersion": "<workflow-definition-version-number>",
  "outputs": { "<workflow-output-definitions>" },
  "parameters": { "<workflow-parameter-definitions>" },
  "staticResults": { "<static-results-definitions>" },
  "triggers": { "<workflow-trigger-definitions>" }
}

Acionadores e ações

Em uma definição de fluxo de trabalho, as triggers seções e actions definem as chamadas que acontecem durante a execução do fluxo de trabalho. Para obter sintaxe e mais informações sobre essas seções, consulte Acionadores e ações de fluxo de trabalho.

Parâmetros

O ciclo de vida da implantação geralmente tem ambientes diferentes para desenvolvimento, teste, preparação e produção. Ao implantar aplicativos lógicos em vários ambientes, você provavelmente deseja usar valores diferentes, como cadeias de conexão, com base em suas necessidades de implantação. Ou, você pode ter valores que deseja reutilizar em todo o seu aplicativo lógico sem hardcoding ou que mudam com frequência. Na seção de definição de parameters fluxo de trabalho, você pode definir ou editar parâmetros para os valores que seu aplicativo lógico usa em tempo de execução. Você deve definir esses parâmetros primeiro antes de poder fazer referência a esses parâmetros em outro lugar na definição do fluxo de trabalho.

Aqui está a estrutura geral para uma definição de parâmetro:

"parameters": {
   "<parameter-name>": {
      "type": "<parameter-type>",
      "defaultValue": <default-parameter-value>,
      "allowedValues": [ <array-with-permitted-parameter-values> ],
      "metadata": {
         "description": "<parameter-description>"
      }
   }
},

Em seguida, crie um modelo do Azure Resource Manager para sua definição de fluxo de trabalho, defina parâmetros de modelo que aceitem os valores desejados na implantação, substitua valores codificados por referências a parâmetros de definição de modelo ou fluxo de trabalho, conforme apropriado, e armazene os valores a serem usados na implantação em um arquivo de parâmetro separado. Dessa forma, você pode alterar esses valores mais facilmente por meio do arquivo de parâmetros sem precisar atualizar e reimplantar seu aplicativo lógico. Para obter informações confidenciais ou que devem ser protegidas, como nomes de usuário, senhas e segredos, você pode armazenar esses valores no Cofre de Chaves do Azure e fazer com que seu arquivo de parâmetros recupere esses valores do cofre de chaves. Para obter mais informações e exemplos sobre como definir parâmetros nos níveis de definição de modelo e fluxo de trabalho, consulte Visão geral: automatizar a implantação de aplicativos lógicos com modelos do Azure Resource Manager.

Resultados estáticos

No atributo, defina o staticResults simulado outputs de uma ação e status que a ação retorne quando a configuração de resultado estático da ação estiver ativada. Na definição da ação, o runtimeConfiguration.staticResult.name atributo faz referência ao nome da definição de resultado estático dentro do staticResults. Saiba como você pode testar fluxos de trabalho de aplicativos lógicos com dados fictícios configurando resultados estáticos.

"definition": {
   "$schema": "<...>",
   "actions": { "<...>" },
   "contentVersion": "<...>",
   "outputs": { "<...>" },
   "parameters": { "<...>" },
   "staticResults": {
      "<static-result-definition-name>": {
         "outputs": {
            <output-attributes-and-values-returned>,
            "headers": { <header-values> },
            "statusCode": "<status-code-returned>"
         },
         "status": "<action-status>"
      }
   },
   "triggers": { "<...>" }
}

Por exemplo, nesta definição de ação HTTP, o runtimeConfiguration.staticResult.name atributo faz referência HTTP0 dentro do staticResults atributo onde as saídas fictícias para a ação são definidas. O runtimeConfiguration.staticResult.staticResultOptions atributo especifica que a configuração de resultado estático está Enabled na ação HTTP.

"actions": {
   "HTTP": {
      "inputs": {
         "method": "GET",
         "uri": "https://www.microsoft.com"
      },
      "runAfter": {},
      "runtimeConfiguration": {
         "staticResult": {
            "name": "HTTP0",
            "staticResultOptions": "Enabled"
         }
      },
      "type": "Http"
   }
},

A ação HTTP retorna as saídas na definição dentro do HTTP0 staticResults. Neste exemplo, para o código de status, a saída simulada é OK. Para valores de cabeçalho, a saída simulada é "Content-Type": "application/JSON". Para o status da ação, a saída simulada é Succeeded.

"definition": {
   "$schema": "<...>",
   "actions": { "<...>" },
   "contentVersion": "<...>",
   "outputs": { "<...>" },
   "parameters": { "<...>" },
   "staticResults": {
      "HTTP0": {
         "outputs": {
            "headers": {
               "Content-Type": "application/JSON"
            },
            "statusCode": "OK"
         },
         "status": "Succeeded"
      }
   },
   "triggers": { "<...>" }
},

Expressões

Com JSON, você pode ter valores literais que existem em tempo de design, por exemplo:

"customerName": "Sophia Owen",
"rainbowColors": ["red", "orange", "yellow", "green", "blue", "indigo", "violet"],
"rainbowColorsCount": 7

Você também pode ter valores que não existem até o tempo de execução. Para representar esses valores, você pode usar expressões, que são avaliadas em tempo de execução. Uma expressão é uma sequência que pode conter uma ou mais funções, operadores, variáveis, valores explícitos ou constantes. Em sua definição de fluxo de trabalho, você pode usar uma expressão em qualquer lugar em um valor de cadeia de caracteres JSON prefixando a expressão com o at-sign (@). Ao avaliar uma expressão que representa um valor JSON, o corpo da expressão é extraído removendo o caractere @ e sempre resulta em outro valor JSON.

Por exemplo, para a propriedade definida customerName anteriormente, você pode obter o valor da propriedade usando a função parameters() em uma expressão e atribuir esse valor à accountName propriedade:

"customerName": "Sophia Owen",
"accountName": "@parameters('customerName')"

A interpolação de cadeias de caracteres também permite que você use várias expressões dentro de cadeias de caracteres que são encapsuladas pelo caractere @ e chaves ({}). Aqui está a sintaxe:

@{ "<expression1>", "<expression2>" }

O resultado é sempre uma cadeia de caracteres, tornando esta capacidade semelhante à concat() função, por exemplo:

"customerName": "First name: @{parameters('firstName')} Last name: @{parameters('lastName')}"

Se você tiver uma cadeia de caracteres literal que comece com o caractere @, prefixe o caractere @ com outro caractere @ como um caractere de escape: @@

Estes exemplos mostram como as expressões são avaliadas:

Para estes exemplos, suponha que você defina "myBirthMonth" igual a "January" e "myAge" igual ao número 42:

"myBirthMonth": "January",
"myAge": 42

Estes exemplos mostram como as seguintes expressões são avaliadas:

Ao trabalhar visualmente no designer de fluxo de trabalho, você pode criar expressões usando o editor de expressões, por exemplo:

Quando terminar, a expressão aparecerá para a propriedade correspondente em sua definição de fluxo de trabalho, por exemplo, a searchQuery propriedade aqui:

"Search_tweets": {
  "inputs": {
    "host": {
      "connection": {
        "name": "@parameters('$connections')['x']['connectionId']"
      }
    }
  },
  "method": "get",
  "path": "/searchtweets",
  "queries": {
    "maxResults": 20,
    "searchQuery": "Azure @{concat('firstName','', 'LastName')}"
  }
},

Saídas

Na seção , defina os dados que seu fluxo de trabalho pode retornar quando terminar a outputs execução. Por exemplo, para controlar um status ou valor específico de cada execução, especifique que a saída do fluxo de trabalho retorna esses dados.

Aqui está a estrutura geral para uma definição de saída:

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

Para obter a saída de uma execução de fluxo de trabalho, revise o histórico de execução e os detalhes do seu aplicativo lógico no portal do Azure ou use a API REST do Fluxo de Trabalho. Você também pode passar a saída para sistemas externos, por exemplo, o Power BI para que possa criar painéis.

Operadores

Em expressões e funções, os operadores executam tarefas específicas, como fazer referência a uma propriedade ou a um valor em uma matriz.

Funções

Algumas expressões obtêm seus valores de ações de tempo de execução que podem ainda não existir quando a definição do fluxo de trabalho começar a ser executada. Para fazer referência ou trabalhar com esses valores em expressões, você pode usar funções fornecidas pela Linguagem de Definição de Fluxo de Trabalho.

Próximos passos

• Saiba mais sobre ações e gatilhos da linguagem de definição de fluxo de trabalho
• Saiba mais sobre como criar e gerenciar aplicativos lógicos de forma programática com a API REST do fluxo de trabalho