Przewodnik dokumentacji schematu dla języka definicji przepływu pracy w usłudze Azure Logic Apps
Podczas tworzenia aplikacji logiki w usłudze Azure Logic Apps aplikacja logiki ma podstawową definicję przepływu pracy, która opisuje rzeczywistą logikę działającą w aplikacji logiki. Ta definicja przepływu pracy używa formatu JSON i jest zgodna ze strukturą zweryfikowaną przez schemat języka definicji przepływu pracy. Ta dokumentacja zawiera omówienie tej struktury i sposobu, w jaki schemat definiuje atrybuty w definicji przepływu pracy.
Struktura definicji przepływu pracy
Definicja przepływu pracy zawsze zawiera wyzwalacz do tworzenia wystąpienia aplikacji logiki oraz co najmniej jedną akcję uruchamianą po wyzwoleniu wyzwalacza.
Oto struktura wysokiego poziomu definicji przepływu pracy:
"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>" }
}
| Atrybut | Wymagania | opis |
|---|---|---|
definition |
Tak | Element początkowy definicji przepływu pracy |
$schema |
Tylko wtedy, gdy zewnętrznie odwołuje się do definicji przepływu pracy | Lokalizacja pliku schematu JSON opisującego wersję języka definicji przepływu pracy, którą można znaleźć tutaj: https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json |
actions |
Nie. | Definicje co najmniej jednej akcji do wykonania w czasie wykonywania przepływu pracy. Aby uzyskać więcej informacji, zobacz Wyzwalacze i akcje. Maksymalna liczba akcji: 250 |
contentVersion |
Nie. | Numer wersji definicji przepływu pracy, który jest domyślnie "1.0.0.0". Aby pomóc zidentyfikować i potwierdzić poprawną definicję podczas wdrażania przepływu pracy, określ wartość do użycia. |
outputs |
Nie. | Definicje danych wyjściowych, które mają zostać zwrócone z przebiegu przepływu pracy. Aby uzyskać więcej informacji, zobacz Dane wyjściowe. Maksymalna liczba danych wyjściowych: 10 |
parameters |
Nie. | Definicje co najmniej jednego parametru, które przekazują wartości do użycia w środowisku uruchomieniowym aplikacji logiki. Aby uzyskać więcej informacji, zobacz Parametry. Maksymalna liczba parametrów: 50 |
staticResults |
Nie. | Definicje co najmniej jednego statycznego wyniku zwracanego przez akcje jako pozorne dane wyjściowe, gdy w tych akcjach są włączone wyniki statyczne. W każdej definicji runtimeConfiguration.staticResult.name akcji atrybut odwołuje się do odpowiedniej definicji wewnątrz staticResults. Aby uzyskać więcej informacji, zobacz Wyniki statyczne. |
triggers |
Nie. | Definicje co najmniej jednego wyzwalacza, który tworzy wystąpienie przepływu pracy. Można zdefiniować więcej niż jeden wyzwalacz, ale tylko za pomocą języka definicji przepływu pracy, a nie wizualnie za pośrednictwem projektanta przepływu pracy. Aby uzyskać więcej informacji, zobacz Wyzwalacze i akcje. Maksymalna liczba wyzwalaczy: 10 |
Wyzwalacze i akcje
W definicji triggers przepływu pracy sekcje i actions definiują wywołania wykonywane podczas wykonywania przepływu pracy. Aby uzyskać informacje o składni i więcej informacji na temat tych sekcji, zobacz Wyzwalacze i akcje przepływu pracy.
Parametry
Cykl życia wdrożenia zwykle ma różne środowiska programowania, testowania, przemieszczania i produkcji. Podczas wdrażania aplikacji logiki w różnych środowiskach prawdopodobnie chcesz użyć różnych wartości, takich jak parametry połączenia, na podstawie potrzeb związanych z wdrożeniem. Możesz też mieć wartości, które mają być używane ponownie w całej aplikacji logiki bez trwałego kodowania lub które często się zmieniają. W sekcji definicji parameters przepływu pracy można zdefiniować lub edytować parametry dla wartości używanych przez aplikację logiki w czasie wykonywania. Należy najpierw zdefiniować te parametry, zanim będzie można odwoływać się do tych parametrów w innej części definicji przepływu pracy.
Oto ogólna struktura definicji parametrów:
"parameters": {
"<parameter-name>": {
"type": "<parameter-type>",
"defaultValue": <default-parameter-value>,
"allowedValues": [ <array-with-permitted-parameter-values> ],
"metadata": {
"description": "<parameter-description>"
}
}
},
| Atrybut | Wymagania | Pisz | Opis |
|---|---|---|---|
| <nazwa-parametru> | Tak | String | Nazwa parametru, który chcesz zdefiniować |
| <typ parametru> | Tak | int, float, string, bool, array, object, securestring, secureobject Uwaga: w przypadku wszystkich haseł, kluczy i wpisów tajnych użyj securestring typów lub secureobject , ponieważ GET operacja nie zwraca tych typów. Aby uzyskać więcej informacji na temat zabezpieczania parametrów, zobacz Zalecenia dotyczące zabezpieczeń dotyczące akcji i parametrów wejściowych. |
Typ parametru |
| <default-parameter-value> | Tak | Tak samo jak type |
Domyślna wartość parametru, która ma być używana, jeśli nie określono żadnej wartości, gdy wystąpi wystąpienie przepływu pracy. Atrybut defaultValue jest wymagany, aby aplikacja logiki Projektant mogła poprawnie wyświetlić parametr, ale można określić pustą wartość. |
| <array-with-permitted-parameter-values> | Nie. | Tablica | Tablica z wartościami, które parametr może zaakceptować |
| <opis parametru> | Nie. | Obiekt JSON | Wszelkie inne szczegóły parametru, takie jak opis parametru |
Następnie utwórz szablon usługi Azure Resource Manager dla definicji przepływu pracy, zdefiniuj parametry szablonu, które akceptują żądane wartości we wdrożeniu, zastąp wartości zakodowane na stałe odwołaniami do parametrów szablonu lub definicji przepływu pracy zgodnie z potrzebami i zapisz wartości do użycia we wdrożeniu w osobnym pliku parametrów. Dzięki temu można łatwiej zmienić te wartości za pomocą pliku parametrów bez konieczności aktualizowania i ponownego wdrażania aplikacji logiki. Aby uzyskać informacje poufne lub muszą być zabezpieczone, takie jak nazwy użytkowników, hasła i wpisy tajne, możesz przechowywać te wartości w usłudze Azure Key Vault i pobrać te wartości z magazynu kluczy. Aby uzyskać więcej informacji i przykładów dotyczących definiowania parametrów na poziomach definicji szablonu i przepływu pracy, zobacz Omówienie: Automatyzowanie wdrażania aplikacji logiki za pomocą szablonów usługi Azure Resource Manager.
Wyniki statyczne
W atrybucie zdefiniuj staticResults makiet outputs akcji i status że akcja jest zwracana po włączeniu statycznego ustawienia wyniku akcji. W definicji runtimeConfiguration.staticResult.name akcji atrybut odwołuje się do nazwy statycznej definicji wyniku wewnątrz staticResults. Dowiedz się, jak przetestować przepływy pracy aplikacji logiki przy użyciu pozornych danych, konfigurując wyniki statyczne.
"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": { "<...>" }
}
| Atrybut | Wymagania | Pisz | Opis |
|---|---|---|---|
| <static-result-definition-name> | Tak | String | Nazwa statycznej definicji wyniku, do którego może odwoływać się definicja akcji za pośrednictwem runtimeConfiguration.staticResult obiektu. Aby uzyskać więcej informacji, zobacz Ustawienia konfiguracji środowiska uruchomieniowego. Możesz użyć dowolnej unikatowej nazwy. Domyślnie ta unikatowa nazwa jest dołączana z liczbą, która jest zwiększana w razie potrzeby. |
| <zwracane atrybuty wyjściowe i wartości> | Tak | Różne wartości | Wymagania dotyczące tych atrybutów różnią się w zależności od różnych warunków. Na przykład gdy status atrybut ma Succeededwartość , outputs atrybut zawiera atrybuty i wartości zwracane jako pozorne dane wyjściowe przez akcję. status Jeśli parametr to Failed, outputs atrybut zawiera errors atrybut, który jest tablicą z co najmniej jednym obiektem błędu, które zawierają informacje o błędziemessage. |
| <wartości nagłówka> | Nie. | JSON | Wszystkie wartości nagłówka zwracane przez akcję |
| <zwrócony kod stanu> | Tak | String | Kod stanu zwrócony przez akcję |
| <action-status> | Tak | String | Stan akcji, na przykład lub SucceededFailed |
Na przykład w tej definicji akcji HTTP atrybut odwołuje się HTTP0 do atrybutustaticResults, runtimeConfiguration.staticResult.name w którym zdefiniowano pozorne dane wyjściowe akcji. Atrybut runtimeConfiguration.staticResult.staticResultOptions określa, że ustawienie statycznego wyniku znajduje się Enabled w akcji HTTP.
"actions": {
"HTTP": {
"inputs": {
"method": "GET",
"uri": "https://www.microsoft.com"
},
"runAfter": {},
"runtimeConfiguration": {
"staticResult": {
"name": "HTTP0",
"staticResultOptions": "Enabled"
}
},
"type": "Http"
}
},
Akcja HTTP zwraca dane wyjściowe w definicji wewnątrz HTTP0staticResults. W tym przykładzie dla kodu stanu pozorne dane wyjściowe to OK. W przypadku wartości nagłówka dane wyjściowe pozorne to "Content-Type": "application/JSON". W przypadku stanu akcji pozorne dane wyjściowe to Succeeded.
"definition": {
"$schema": "<...>",
"actions": { "<...>" },
"contentVersion": "<...>",
"outputs": { "<...>" },
"parameters": { "<...>" },
"staticResults": {
"HTTP0": {
"outputs": {
"headers": {
"Content-Type": "application/JSON"
},
"statusCode": "OK"
},
"status": "Succeeded"
}
},
"triggers": { "<...>" }
},
Wyrażenia
W formacie JSON można mieć wartości literału, które istnieją w czasie projektowania, na przykład:
"customerName": "Sophia Owen",
"rainbowColors": ["red", "orange", "yellow", "green", "blue", "indigo", "violet"],
"rainbowColorsCount": 7
Możesz również mieć wartości, które nie istnieją do czasu wykonywania. Aby przedstawić te wartości, możesz użyć wyrażeń, które są oceniane w czasie wykonywania. Wyrażenie to sekwencja, która może zawierać co najmniej jedną funkcję, operatory, zmienne, jawne wartości lub stałe. W definicji przepływu pracy można użyć wyrażenia w dowolnym miejscu w wartości ciągu JSON, prefiksując wyrażenie za pomocą znaku at-sign (@). Podczas obliczania wyrażenia reprezentującego wartość JSON treść wyrażenia jest wyodrębniona przez usunięcie znaku @ i zawsze powoduje wyświetlenie innej wartości JSON.
Na przykład dla wcześniej zdefiniowanej customerName właściwości można pobrać wartość właściwości przy użyciu funkcji parameters() w wyrażeniu accountName i przypisać tę wartość do właściwości:
"customerName": "Sophia Owen",
"accountName": "@parameters('customerName')"
Interpolacja ciągów umożliwia również używanie wielu wyrażeń wewnątrz ciągów, które są owinięte znakiem @ i nawiasami klamrowymi ({}). Oto składnia:
@{ "<expression1>", "<expression2>" }
Wynik jest zawsze ciągiem, dzięki czemu ta funkcja jest podobna do concat() funkcji, na przykład:
"customerName": "First name: @{parameters('firstName')} Last name: @{parameters('lastName')}"
Jeśli masz ciąg literału rozpoczynający się znakiem @, przedrostek znaku @ z innym znakiem @ jako znakiem ucieczki: @@
W poniższych przykładach pokazano, jak są oceniane wyrażenia:
| Wartość JSON | Result |
|---|---|
| "Sophia Owen" | Zwróć następujące znaki: "Sophia Owen" |
| "array[1]" | Zwróć następujące znaki: "array[1]" |
| "@@" | Zwraca te znaki jako ciąg jednoznaczny: "@" |
| " @" | Zwróć te znaki jako dwuznaczny ciąg: " @" |
W tych przykładach załóżmy, że definiujesz wartość "myBirthMonth" równą "Styczeń" i "myAge" równą liczbie 42:
"myBirthMonth": "January",
"myAge": 42
W poniższych przykładach pokazano, jak są oceniane następujące wyrażenia:
| Wyrażenie JSON | Result |
|---|---|
| "@parameters('myBirthMonth')" | Zwróć ten ciąg: "Styczeń" |
| "@{parameters('myBirthMonth')}" | Zwróć ten ciąg: "Styczeń" |
| "@parameters('myAge')" | Zwróć tę liczbę: 42 |
| "@{parameters('myAge')}" | Zwróć tę liczbę jako ciąg: "42" |
| "Mój wiek to @{parameters('myAge')}" | Zwróć ten ciąg: "Mój wiek to 42" |
| "@concat('Mój wiek to ', ciąg('myAge')))" | Zwróć ten ciąg: "Mój wiek to 42" |
| "Mój wiek to @@{parameters('myAge')}" | Zwróć ten ciąg, który zawiera wyrażenie: "Mój wiek to @{parameters('myAge')}' |
Gdy pracujesz wizualnie w projektancie przepływu pracy, możesz tworzyć wyrażenia przy użyciu edytora wyrażeń, na przykład:
Gdy skończysz, wyrażenie zostanie wyświetlone dla odpowiedniej właściwości w definicji przepływu pracy, na przykład searchQuery właściwość tutaj:
"Search_tweets": {
"inputs": {
"host": {
"connection": {
"name": "@parameters('$connections')['twitter']['connectionId']"
}
}
},
"method": "get",
"path": "/searchtweets",
"queries": {
"maxResults": 20,
"searchQuery": "Azure @{concat('firstName','', 'LastName')}"
}
},
Dane wyjściowe
W sekcji zdefiniuj dane, które przepływ pracy może zwrócić po zakończeniu outputs działania. Aby na przykład śledzić określony stan lub wartość z każdego przebiegu, określ, że dane wyjściowe przepływu pracy zwracają te dane.
Uwaga
W przypadku odpowiadania na żądania przychodzące z interfejsu API REST usługi nie używaj polecenia outputs. Zamiast tego użyj Response typu akcji.
Aby uzyskać więcej informacji, zobacz Wyzwalacze i akcje przepływu pracy.
Oto ogólna struktura definicji danych wyjściowych:
"outputs": {
"<key-name>": {
"type": "<key-type>",
"value": "<key-value>"
}
}
| Atrybut | Wymagania | Pisz | Opis |
|---|---|---|---|
| <key-name> | Tak | String | Nazwa klucza dla wartości zwracanej danych wyjściowych |
| <typ klucza> | Tak | int, float, string, securestring, bool, array, JSON object | Typ wartości zwracanej danych wyjściowych |
| <klucz-wartość> | Tak | Tak samo jak <typ klucza> | Zwracana wartość danych wyjściowych |
Aby pobrać dane wyjściowe z przebiegu przepływu pracy, przejrzyj historię uruchamiania i szczegóły aplikacji logiki w witrynie Azure Portal lub użyj interfejsu API REST przepływu pracy. Możesz również przekazać dane wyjściowe do systemów zewnętrznych, na przykład usługi Power BI, aby można było tworzyć pulpity nawigacyjne.
Operatory
W wyrażeniach i funkcjach operatory wykonują określone zadania, takie jak odwołanie do właściwości lub wartość w tablicy.
| Operator | Zadanie |
|---|---|
' |
Aby użyć literału ciągu jako danych wejściowych lub w wyrażeniach i funkcjach, zawijaj ciąg tylko za pomocą pojedynczych cudzysłowów, na przykład '<myString>'. Nie używaj podwójnych cudzysłowów (""), które powodują konflikt z formatowaniem JSON wokół całego wyrażenia. Na przykład: .Tak: length('Hello') Nie: length("Hello") W przypadku przekazywania tablic lub liczb nie potrzebujesz znaków interpunkcyjnych opakowujących. Na przykład: . Tak: length([1, 2, 3]) Nie: length("[1, 2, 3]") |
[] |
Aby odwołać się do wartości w określonej pozycji (indeks) w tablicy lub wewnątrz obiektu JSON, użyj nawiasów kwadratowych, na przykład: - Aby uzyskać drugi element w tablicy: myArray[1] - Aby uzyskać dostęp do właściwości wewnątrz obiektu JSON: Przykład 1: setProperty(<object>, '<parent-property>', addProperty(<object>['<parent-property>'], '<child-property>', <value>) Przykład 2: lastIndexOf(triggerBody()?['subject'],'some string') |
. |
Aby odwołać się do właściwości w obiekcie, użyj operatora kropki. Aby na przykład pobrać name właściwość dla customer obiektu JSON: "@parameters('customer').name" |
? |
Aby odwołać się do właściwości null w obiekcie bez błędu środowiska uruchomieniowego, użyj operatora znaku zapytania. Aby na przykład obsłużyć dane wyjściowe o wartości null z wyzwalacza, możesz użyć następującego wyrażenia: @coalesce(trigger().outputs?.body?.<someProperty>, '<property-default-value>') |
Funkcje
Niektóre wyrażenia pobierają wartości z akcji środowiska uruchomieniowego, które mogą jeszcze nie istnieć, gdy definicja przepływu pracy zacznie działać. Aby odwołać się do tych wartości lub pracować z tymi wartościami w wyrażeniach, możesz użyć funkcji , które udostępnia język definicji przepływu pracy.
Następne kroki
- Dowiedz się więcej o akcjach i wyzwalaczach języka definicji przepływu pracy
- Dowiedz się więcej o programowym tworzeniu aplikacji logiki i zarządzaniu nimi za pomocą interfejsu API REST przepływu pracy