Opisywanie przepływu pracy usługi Azure Logic Apps przy użyciu języka definicji przepływu pracy
Strukturę i przepływ pracy przepływu pracy aplikacji logiki platformy Azure definiuje się przy użyciu dokumentu JSON. Ten dokument zawiera opis JSON elementów, które tworzą przepływ pracy aplikacji logiki, a schemat języka definicji przepływu pracy weryfikuje go. Najprostszym sposobem wyjaśnienia schematu jest sprawdzenie istniejącego przepływu pracy utworzonego przy użyciu projektanta przepływu pracy w witrynie Azure Portal, a następnie wyświetlenie opisu JSON aplikacji logiki.
W przykładowym scenariuszu chcesz udostępnić konsultantom typowe przepływy pracy, które mogą dostosować do konkretnych potrzeb uniwersytetów, z którymi pracują. Zależy Ci na tym, aby dostosowywanie i wdrażanie przepływów pracy było jak najłatwiejsze, dlatego chcesz przyjrzeć się kodowi, na którym bazuje ten przepływ pracy, czyli plikowi JSON definicji przepływu pracy.
Projektant przepływów pracy
Projektant przepływu pracy umożliwia graficzne tworzenie i debugowanie przepływu pracy dla przepływu pracy aplikacji logiki. Projektant pozwala również deweloperom przyjrzeć się pod maską przepływu pracy, aby zobaczyć, jak jest zaimplementowany. Na poniższej ilustracji przedstawiono przykład prostego przepływu pracy, który jest wyzwalany przez wysłanie żądania HTTP GET do określonego adresu URL. Wynik jest zwracany w odpowiedzi HTTP. W tym przykładzie przepływ pracy wysyła prosty komunikat Hello Logic Apps Template! .
Teraz przyjrzyjmy się językowi definicji przepływu pracy używanego przez szablon JSON.
Widok kodu
W oknie Widok kodu zostanie wyświetlony dokument JSON opisujący przepływ pracy. W przykładowej aplikacji kod JSON wygląda następująco:
{
"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"
}
}
}
}
Zwróć uwagę na definition sekcje w zakresie, które odnoszą się do akcji i wyzwalaczy wyświetlanych w projektancie. Kod JSON można edytować w tym dokumencie, aby odzwierciedlał wszelkie zmiany wymagane w funkcji przepływu pracy aplikacji logiki. Możesz również dodać kolejne akcje i określić sposób uruchamiania logiki w przepływie pracy z jednej akcji do następnej.
Sekcja wyzwalaczy
Sekcja triggers zawiera opis typu wyzwalacza i sposób jego wywołania. W tym przykładzie wyzwalacz jest prostym wyzwalaczem HTTP, który jest uruchamiany w odpowiedzi na żądanie HTTP GET.
"triggers": {
"manual": {
"inputs": {
"method": "GET",
"schema": {}
},
"kind": "Http",
"type": "Request"
}
}
Wyzwalacz musi zawierać następujące elementy:
Unikatowa nazwa wewnątrz przepływu pracy. W poprzednim przykładzie domyślna nazwa wyzwalacza to
manual, ale możesz zastąpić nazwę domyślną bardziej zrozumiałym identyfikatorem.Typ wyzwalacza. Typ wskazuje zdarzenie, które powoduje uruchomienie wyzwalacza. Wyzwalacz
Requestjest uruchamiany w odpowiedzi na żądanie HTTP. Inne dostępne typy wyzwalaczy to m.in.:Recurrencew celu utworzenia wyzwalacza uruchamianego zgodnie z harmonogramem cyklicznym.HttpWebhookdo nasłuchiwania zdarzeń w punkcie końcowym.ApiConnectionw przypadku reagowania na zdarzenia wyzwalane przez inne usługi platformy Azure, takie jak komunikat przychodzący do kolejki wiadomości, wiadomość e-mail itd. Typ wyzwalacza ApiConnection jest uogólniony i określasz dalsze szczegóły wskazujące typ usługi i wszelkie wymagane informacje o połączeniu.
Sekcja
inputs. Ta sekcja określa dane, które definiują zachowanie wyzwalacza. W przypadku wyzwalacza żądanie wskazuje typ żądania HTTP,methodktóry powoduje uruchomienie wyzwalacza. W przypadkuApiConnectionwyzwalaczainputssekcja zawiera informacje o sposobie nawiązywania połączenia z zasobem wyzwalającym zdarzenie (na przykład kolejka komunikatów parametry połączenia). Jeśli wyzwalacz jest wyzwalaczemRequest, sekcja definicjischemadanych wejściowych określa schemat, z którego powinien być zgodny ładunek treści żądania. Żądania HTTP GET nie mają treści żądania, więcschemawartość jest pusta w poprzednim przykładzie.
W poniższym przykładzie przedstawiono definicję innego Request wyzwalacza, który uruchamia przepływ pracy i odbiera żądania HTTP POST. Żądanie POST zwykle zawiera treść żądania zawierającą dane do opublikowania. Treść żądania w tym przykładzie zawiera nazwę i adres klienta (składający się z ulicy i miasta).
"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"
}
}
}
}
}
}
}
Wyzwalacz może również określać warunki. Wyzwalacz zostanie uruchomiony tylko wtedy, kiedy warunki zostaną spełnione. Warunki definiuje się w opcjonalnej sekcji conditions (warunki). Na przykład możesz chcieć uruchomić mypostrequest wyzwalacz (pokazany w poprzednim przykładzie), tylko wtedy, gdy treść żądania określa miasto New York:
"mypostrequest": {
"type": "Request",
"kind": "Http",
"inputs": {
...
}
"conditions": [
{
"expression": "@equals(triggerOutputs()['body']['customerAddress']['city'], 'New York')"
}
]
}
Sekcja akcji
Sekcja aplikacji actions logiki definiuje logikę i strukturę przepływu pracy. Sekcja zawiera serię akcji. Akcja to podstawowy blok konstrukcyjny do konstruowania przepływów pracy. Akcje podejmują dane wejściowe i generują dane wyjściowe, które są przekazywane do następnej akcji w przepływie pracy. W poniższej tabeli wymieniono różne dostępne typy akcji:
| Akcja | opis |
|---|---|
ApiConnection |
Wysyła żądanie HTTP do określonej usługi. Ten typ akcji umożliwia integrację przepływu pracy aplikacji logiki z funkcjami platformy Azure, takimi jak Azure Service Bus, Azure Event Grid i inne. Ta akcja wymaga danych wejściowych, które zawierają parametry połączenia umożliwiające uzyskanie dostępu do usługi, oraz wszelkie dodatkowe informacje i parametry wymagane do wywołania usługi. |
Compose |
Łączy wiele danych wejściowych i wyrażeń w jedne dane wyjściowe. |
Function |
Umożliwia wywołanie funkcji platformy Azure. |
HTTP |
Wysyła żądanie HTTP do punktu końcowego HTTP, a nie do usługi platformy Azure. |
Join |
Pobiera tablicę elementów danych jako dane wejściowe i generuje ciąg zawierający te elementy oddzielone określonym ogranicznikiem. |
Parse |
Analizuje dokument JSON w zestawie tokenów przy użyciu określonego schematu. |
Query |
Filtruje elementy w tablicy wejściowej przy użyciu określonego warunku. |
Response |
Tworzy odpowiedź na żądanie HTTP. |
Table |
Generuje tabelę HTML z tablicy obiektów JSON. |
Terminate |
Natychmiast anuluje przepływ pracy. |
Wait |
Wstrzymuje przepływ pracy dla określonego interwału lub do momentu przekroczenia limitu czasu. |
Workflow |
Uruchamia inny przepływ pracy aplikacji logiki. |
Condition |
Zestaw typów akcji (Foreach, If, Switchi Until), który umożliwia implementowanie programowego przepływu sterowania w przepływie pracy. Można wykonać iterację po elementach w kolekcji, podejmować decyzje na podstawie wartości parametrów wejściowych oraz pozostać w pętli, dopóki nie zostanie spełniony określony warunek. |
InitializeVariable,IncrementVariable,DecrementVariable,SetVariable |
Definiuje, inicjuje, przypisuje i modyfikuje zmienne, które można przekazywać między elementami akcji w przepływie pracy. |
Podobnie jak wyzwalacz, każda akcja musi mieć unikatową nazwę w przepływie pracy. W poniższym przykładzie domyślną nazwą akcji jest Response, ale można użyć prawidłowego i bardziej znaczącego identyfikatora. Akcja musi zawierać sekcję określającą inputs dane, na których działa akcja. W akcji Odpowiedź można określić dane wyrażenia, które ma być zwracane w komunikacie odpowiedzi, wraz z kodem stanu HTTP.
W naszej podstawowej definicji przepływu pracy akcja generuje odpowiedź HTTP, w której treść jest krótkim komunikatem.
"actions": {
"Response": {
"inputs": {
"body": "Hello Azure Logic Apps Template!",
"statusCode": 200
},
"kind": "Http",
"runAfter": {},
"type": "Response"
}
}
Sekcja runAfter wskazuje, gdzie akcja jest uruchamiana w sekwencji przepływu pracy. W poprzednim przykładzie jest tylko jedna akcja, dlatego jest ona uruchamiana zawsze po aktywowaniu wyzwalacza. Jeśli przepływ pracy miał wiele akcji, możesz określić nazwę akcji i stan tej akcji w tej sekcji. Akcja jest uruchamiana, runAfter jeśli akcja zostanie ukończona z określonym stanem. Poniższy kod przedstawia przykład. Akcja mySecondAction jest uruchamiana po myFirstActionoperacji , ale tylko wtedy, gdy myFirstAction kończy się stanem Succeeded:
"actions": {
"mySecondAction": {
"inputs": {
...
},
"runAfter": {
"myFirstAction": [
"Succeeded"
]
},
"type": ...
},
"myFirstAction": {
"inputs": {
...
},
"runAfter": {},
"type": ...
}
}
Sekcja danych wyjściowych
outputs Użyj sekcji , aby zdefiniować dane, które przepływ pracy może zwrócić po zakończeniu działania. Możesz śledzić określony stan lub dane dla każdego przebiegu przepływu pracy. Dane wyjściowe z każdego uruchomienia przepływu pracy można sprawdzić przy użyciu historii uruchamiania usługi Azure Logic Apps, która jest dostępna w witrynie Azure Portal lub interfejsie API REST przepływu pracy.
Format outputs sekcji wygląda następująco:
"outputs": {
"<key-name>": {
"type": "<key-type>",
"value": "<key-value>"
}
}
Wyrażenia przepływu pracy
Możesz użyć wyrażenia przepływu pracy zamiast dowolnej stałej wartości, zmiennej lub stałej. Wyrażenie można również umieścić w dowolnym miejscu w wartości ciągu JSON, prefiksując wyrażenie za pomocą znaku at (@). W wyrażeniu można na przykład użyć funkcji @parameters, aby pobrać wartość nazwanego parametru (parametry opisano w następnej sekcji).
"customerFullName": "Bill Frost",
"accountName": "@parameters('customerName')"
Usługa Azure Logic Apps udostępnia wbudowane funkcje, których można użyć do tworzenia złożonych wyrażeń:
- Funkcje ciągów: w przypadku łączenia lub dzielenia ciągów konwertowanie znaków między wielkimi i małymi literami oraz wyszukiwanie podciągów.
- Funkcje kolekcji: w celu wykrywania, czy kolekcja zawiera elementy pasujące do określonego wzorca, pobieranie elementów z kolekcji i łączenie kolekcji.
- Funkcje porównania logicznego: aby wykryć, czy operandy są takie same, różne, liczbowo większe lub liczbowo mniejsze od siebie.
- Funkcje konwersji: zmiana typu lub formatu danych.
- Funkcje matematyczne: takie jak
add, ,subdivimul, oraz kilka innych. - Funkcje daty i godziny: w przypadku analizowania i przetwarzania dat i godzin.
- Funkcje przepływu pracy: aby pobrać informacje o danych przekazanych do akcji przepływu pracy. Na przykład
parameterfunkcja (wcześniej pokazana) pobiera wartość nazwanego parametru, abodyfunkcja (pokazana wcześniej) zwraca dane generowane przez akcję. - Funkcje manipulowania kodami JSON i XML: do analizowania i przetwarzania dokumentów JSON i XML.
Zmienne można zdefiniować w inputs sekcji InitializeVariable akcji i manipulować tymi zmiennymi przy użyciu wyrażeń. Odczytywanie wartości zmiennej variables przy użyciu funkcji . W poniższym przykładzie użyto InitializeVariable akcji w celu utworzenia zmiennej całkowitej o nazwie myIntegerVariable i zainicjowania jej do 99. W tym przykładzie pokazano Condition również akcję z typem If . Warunek używa wyrażenia do testowania myIntegerVariable wartości zmiennej, a jeśli pasuje do wartości 100, warunek używa akcji HTTP do wykonania żądania 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"
}
}
Sekcja Parametry
Sekcja parameters umożliwia sparametryzowanie przepływu pracy. W czasie wykonywania możesz podać wartości dla każdego z tych parametrów. Możesz odwoływać się do parametrów w dowolnym miejscu przepływu pracy, w którym można użyć stałej lub wyrażenia.
Możesz dodać definicję parametrów z wartością domyślną. Wartości domyślna jest używana, kiedy w czasie wykonywania nie zostanie podana wartość dla parametru. W poniższym przykładzie pokazano, jak zdefiniować parametr o nazwie cityParam. Parametr jest używany wewnątrz warunku mypostrequest akcji. Wykonuje akcję tylko wtedy, gdy dokument żądania zawiera miasto pasujące do wartości parametru. Domyślna wartość parametru to 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"
}
}
}
}