Środowisko usługi z jedną dzierżawą a wielodostępną i integracją dla Azure Logic Apps

Azure Logic Apps to oparta na chmurze platforma do tworzenia i uruchamiania zautomatyzowanych przepływów pracy aplikacji logiki, które integrują aplikacje, dane, usługi i systemy. Dzięki tej platformie można szybko opracowywać wysoce skalowalne rozwiązania integracji dla scenariuszy przedsiębiorstwa i działalności biznesowej (B2B). Aby utworzyć aplikację logiki, należy użyć typu zasobu Aplikacja logiki (Zużycie) lub typu zasobu Aplikacja logiki (Standardowa). Typ zasobu Zużycie jest uruchamiany w środowisku usługi Azure Logic Appsz wieloma dzierżawami lub w środowisku usługi integracji, a typ zasobu Standard działa w środowisku Azure Logic Apps z jedną dzierżawą.

Przed wybraniem typu zasobu do użycia zapoznaj się z tym artykułem, aby dowiedzieć się, jak typy zasobów i środowiska usług są porównywane ze sobą. Następnie możesz zdecydować, którego typu najlepiej użyć, na podstawie potrzeb scenariusza, wymagań dotyczących rozwiązań i środowiska, w którym chcesz wdrożyć, hostować i uruchamiać przepływy pracy.

Jeśli jesteś nowym użytkownikem Azure Logic Apps, zapoznaj się z następującą dokumentacją:

Typy zasobów i środowiska

Aby utworzyć przepływy pracy aplikacji logiki, należy wybrać typ zasobu aplikacji logiki na podstawie scenariusza, wymagań dotyczących rozwiązań, żądanych możliwości i środowiska, w którym chcesz uruchamiać przepływy pracy.

W poniższej tabeli krótko podsumowano różnice między typem zasobu aplikacji logiki (Standardowa) a typem zasobu Aplikacja logiki (Zużycie). Dowiesz się również, jak środowisko z jedną dzierżawą jest porównywane z wielodostępnym i integracyjnym środowiskiem usługi (ISE) do wdrażania, hostowania i uruchamiania przepływów pracy aplikacji logiki.

Typ zasobu Korzyści Udostępnianie i użycie zasobów Model cen i rozliczeń Zarządzanie limitami
Aplikacja logiki (zużycie)

Środowisko hosta: Azure Logic Apps z wieloma dzierżawami

- Najłatwiej rozpocząć

- Płatność za to, czego używasz

— W pełni zarządzane

Jedna aplikacja logiki może mieć tylko jeden przepływ pracy.

Aplikacje logiki utworzone przez klientów w wielu dzierżawach współdzielą to samo przetwarzanie (obliczenia), magazyn, sieć itd.

Zużycie (płatność za wykonanie) Azure Logic Apps zarządza wartościami domyślnymi dla tych limitów, ale niektóre z tych wartości można zmienić, jeśli ta opcja istnieje dla określonego limitu.
Aplikacja logiki (zużycie)

Środowisko hosta:
Środowisko usługi integracji (ISE)

— Enterprise skalowanie dużych obciążeń

- 20+ łączniki specyficzne dla środowiska ISE, które łączą się bezpośrednio z sieciami wirtualnymi

— Przewidywalne ceny z uwzględnionym użyciem i kontrolowanym przez klienta skalowaniem

— Dane pozostają w tym samym regionie, w którym wdrażasz środowisko ISE.

Jedna aplikacja logiki może mieć tylko jeden przepływ pracy.

Aplikacje logiki w tym samym środowisku współdzielą to samo przetwarzanie (obliczenia), magazyn, sieć itd.

ISE (naprawiono) Azure Logic Apps zarządza wartościami domyślnymi dla tych limitów, ale niektóre z tych wartości można zmienić, jeśli ta opcja istnieje dla określonego limitu.
Aplikacja logiki (Standardowa)

Środowisko hosta:
Azure Logic Apps z jedną dzierżawą

Uwaga: jeśli scenariusz wymaga kontenerów, utwórz aplikacje logiki oparte na jednej dzierżawie przy użyciu usługi Logic Apps z obsługą usługi Azure Arc. Aby uzyskać więcej informacji, zobacz Co to jest usługa Logic Apps z obsługą usługi Azure Arc?

— Uruchom polecenie przy użyciu środowiska uruchomieniowego Azure Logic Apps z jedną dzierżawą. Miejsca wdrożenia nie są obecnie obsługiwane.

- Więcej wbudowanych łączników dla większej przepływności i niższych kosztów na dużą skalę

— Większa kontrola i możliwość dostrajania wokół ustawień środowiska uruchomieniowego i wydajności

- Zintegrowana obsługa sieci wirtualnych i prywatnych punktów końcowych.

— Utwórz własne wbudowane łączniki.

— Dane pozostają w tym samym regionie, w którym wdrażasz aplikacje logiki.

Jedna aplikacja logiki może mieć wiele stanowych i bezstanowych przepływów pracy.

Przepływy pracy w jednej aplikacji logiki i dzierżawie współużytkuje to samo przetwarzanie (obliczenia), magazyn, sieć itd.

Standardowa oparta na planie hostingu z wybraną warstwą cenową.

Jeśli uruchamiasz stanowe przepływy pracy, które korzystają z magazynu zewnętrznego, środowisko uruchomieniowe Azure Logic Apps wykonuje transakcje magazynu zgodne z cennikami usługi Azure Storage.

Możesz zmienić wartości domyślne dla wielu limitów w zależności od potrzeb scenariusza.

Ważne: Niektóre limity mają twarde górne maksimum. W Visual Studio Code zmiany wprowadzone w domyślnych wartościach limitu w plikach konfiguracji projektu aplikacji logiki nie będą wyświetlane w środowisku projektanta. Aby uzyskać więcej informacji, zobacz Edytowanie ustawień aplikacji i środowiska dla aplikacji logiki w Azure Logic Apps z jedną dzierżawą.

Aplikacja logiki (Standardowa)

Środowisko hosta:
App Service Environment v3 (ASEv3) — tylko plany Windows

Te same możliwości co pojedyncza dzierżawa oraz następujące korzyści:

— W pełni izoluj aplikacje logiki.

— Tworzenie i uruchamianie większej liczby aplikacji logiki niż w Azure Logic Apps z jedną dzierżawą.

— Płacisz tylko za plan App Service środowiska ASE, niezależnie od liczby tworzonych i uruchamianych aplikacji logiki.

— Umożliwia skalowanie automatyczne lub ręczne skalowanie przy użyciu większej liczby wystąpień maszyn wirtualnych lub innego planu App Service.

— Dane pozostają w tym samym regionie, w którym wdrażasz aplikacje logiki.

— Dziedzicz konfigurację sieci z wybranego środowiska ASEv3. Na przykład po wdrożeniu w wewnętrznym środowisku ASE przepływy pracy mogą uzyskiwać dostęp do zasobów w sieci wirtualnej skojarzonej ze środowiskaMI ASE i mieć wewnętrzne punkty dostępu.

Uwaga: jeśli dostęp jest uzyskiwany spoza wewnętrznego środowiska ASE, historie uruchamiania przepływów pracy w tym środowisku ASE nie mogą uzyskać dostępu do danych wejściowych i wyjściowych akcji.

Jedna aplikacja logiki może mieć wiele stanowych i bezstanowych przepływów pracy.

Przepływy pracy w jednej aplikacji logiki i dzierżawie współużytkuje to samo przetwarzanie (obliczenia), magazyn, sieć itd.

Plan usługi App Service Możesz zmienić wartości domyślne dla wielu limitów w zależności od potrzeb scenariusza.

Ważne: Niektóre limity mają twarde górne maksimum. W Visual Studio Code zmiany wprowadzone w domyślnych wartościach limitu w plikach konfiguracji projektu aplikacji logiki nie będą wyświetlane w środowisku projektanta. Aby uzyskać więcej informacji, zobacz Edytowanie ustawień aplikacji i środowiska dla aplikacji logiki w Azure Logic Apps z jedną dzierżawą.

Zasób aplikacji logiki (Standardowa)

Typ zasobu aplikacji logiki (Standardowa) jest obsługiwany przez przeprojektowane środowisko uruchomieniowe Azure Logic Apps z jedną dzierżawą. To środowisko uruchomieniowe używa modelu rozszerzalności Azure Functions i jest hostowane jako rozszerzenie w środowisku uruchomieniowym Azure Functions. Ten projekt zapewnia przenośność, elastyczność i większą wydajność przepływów pracy aplikacji logiki oraz inne możliwości i korzyści dziedziczone z platformy Azure Functions i ekosystemu Azure App Service. Można na przykład tworzyć, wdrażać i uruchamiać aplikacje logiki oparte na jednej dzierżawie oraz ich przepływy pracy w środowisku Azure App Service w wersji 3 (tylko plany Windows).

Typ zasobu Standard wprowadza strukturę zasobów, która może hostować wiele przepływów pracy, podobnie jak aplikacja funkcji platformy Azure może hostować wiele funkcji. Dzięki mapowaniu od 1 do wielu przepływy pracy w tej samej aplikacji logiki i dzierżawie współużytkują zasoby obliczeniowe i przetwarzane, zapewniając lepszą wydajność ze względu na ich bliskość. Ta struktura różni się od zasobu aplikacji logiki (Zużycie), w którym istnieje mapowanie od 1 do 1 między zasobem aplikacji logiki a przepływem pracy.

Aby dowiedzieć się więcej na temat przenośności, elastyczności i ulepszeń wydajności, przejdź do poniższych sekcji. Aby uzyskać więcej informacji na temat środowiska uruchomieniowego Azure Logic Apps z jedną dzierżawą i rozszerzalności Azure Functions, zapoznaj się z następującą dokumentacją:

Przenośność i elastyczność

Podczas tworzenia aplikacji logiki przy użyciu typu zasobu Aplikacja logiki (Standardowa) można wdrażać i uruchamiać przepływy pracy w innych środowiskach, takich jak środowisko Azure App Service w wersji 3 (tylko plany Windows). Jeśli używasz Visual Studio Code z rozszerzeniem Azure Logic Apps (Standardowa), możesz lokalnie opracowywać, kompilować i uruchamiać przepływy pracy w środowisku projektowym bez konieczności wdrażania na platformie Azure. Jeśli twój scenariusz wymaga kontenerów, utwórz aplikacje logiki oparte na jednej dzierżawie przy użyciu usługi Logic Apps z obsługą usługi Azure Arc. Aby uzyskać więcej informacji, zobacz Co to jest usługa Logic Apps z obsługą usługi Azure Arc?

Te możliwości zapewniają znaczne ulepszenia i znaczne korzyści w porównaniu z modelem wielodostępnym, który wymaga opracowania w odniesieniu do istniejącego działającego zasobu na platformie Azure. Ponadto model wielodostępny do automatyzacji wdrażania zasobów aplikacji logiki (Zużycie) jest całkowicie oparty na szablonach usługi Azure Resource Manager (szablonach usługi ARM), które łączą i obsługują aprowizowanie zasobów dla aplikacji i infrastruktury.

W przypadku typu zasobu Aplikacja logiki (Standardowa) wdrożenie staje się łatwiejsze, ponieważ można oddzielić wdrożenie aplikacji od wdrożenia infrastruktury. Możesz spakować środowisko uruchomieniowe Azure Logic Apps z jedną dzierżawą i przepływy pracy w ramach aplikacji logiki. Możesz użyć ogólnych kroków lub zadań, które kompilują, składają i pakują zasoby aplikacji logiki do gotowych do wdrożenia artefaktów. Aby wdrożyć infrastrukturę, można nadal używać szablonów usługi ARM do oddzielnej aprowizacji tych zasobów wraz z innymi procesami i potokami używanymi do tych celów.

Aby wdrożyć aplikację, skopiuj artefakty do środowiska hosta, a następnie uruchom aplikacje, aby uruchamiać przepływy pracy. Możesz też zintegrować artefakty z potokami wdrażania przy użyciu narzędzi i procesów, które już znasz i których używasz. W ten sposób można wdrażać przy użyciu własnych wybranych narzędzi niezależnie od stosu technologii używanego do programowania.

Korzystając ze standardowych opcji kompilacji i wdrażania, można skoncentrować się na tworzeniu aplikacji niezależnie od wdrożenia infrastruktury. W związku z tym uzyskasz bardziej ogólny model projektu, w którym można zastosować wiele podobnych lub tych samych opcji wdrażania, które są używane dla aplikacji ogólnej. Możesz również korzystać z bardziej spójnego środowiska tworzenia potoków wdrażania wokół projektów aplikacji oraz uruchamiania wymaganych testów i walidacji przed opublikowaniem w środowisku produkcyjnym.

Wydajność

Za pomocą typu zasobu Aplikacja logiki (Standardowa) można utworzyć i uruchomić wiele przepływów pracy w tej samej pojedynczej aplikacji logiki i dzierżawie. Dzięki temu mapowaniu od 1 do wielu te przepływy pracy współdzielą zasoby, takie jak obliczenia, przetwarzanie, magazyn i sieć, zapewniając lepszą wydajność ze względu na ich bliskość.

Typ zasobu aplikacji logiki (Standardowa) i środowisko uruchomieniowe Azure Logic Apps z jedną dzierżawą zapewniają kolejną znaczącą poprawę dzięki udostępnieniu bardziej popularnych łączników zarządzanych jako operacje wbudowane. Na przykład możesz użyć wbudowanych operacji dla Azure Service Bus, Azure Event Hubs, SQL i innych. W międzyczasie wersje łącznika zarządzanego są nadal dostępne i nadal działają.

W przypadku korzystania z nowych wbudowanych operacji tworzy się połączenia nazywane połączeniami wbudowanymi lub połączeniami dostawcy usług. Ich odpowiedniki połączeń zarządzanych są nazywane połączeniami interfejsu API, które są tworzone i uruchamiane oddzielnie jako zasoby platformy Azure, które również należy wdrożyć przy użyciu szablonów usługi ARM. Wbudowane operacje i ich połączenia są uruchamiane lokalnie w tym samym procesie, który uruchamia przepływy pracy. Oba są hostowane w środowisku uruchomieniowym Azure Logic Apps z jedną dzierżawą. W rezultacie wbudowane operacje i ich połączenia zapewniają lepszą wydajność ze względu na bliskość przepływów pracy. Ten projekt działa również dobrze w przypadku potoków wdrażania, ponieważ połączenia dostawcy usług są pakowane w ten sam artefakt kompilacji.

Rezydencja danych

Zasoby aplikacji logiki utworzone przy użyciu typu zasobu aplikacja logiki (Standardowa) są hostowane w Azure Logic Apps z jedną dzierżawą, która nie przechowuje, przetwarza ani replikuje danych poza regionem, w którym wdrażasz te zasoby aplikacji logiki, co oznacza, że dane w przepływach pracy aplikacji logiki pozostają w tym samym regionie, w którym tworzysz i wdrażasz swoje zasoby nadrzędne.

Opcje tworzenia, kompilowania i wdrażania

Aby utworzyć aplikację logiki na podstawie żądanego środowiska, masz wiele opcji, na przykład:

Środowisko z jedną dzierżawą

Opcja Zasoby i narzędzia Więcej informacji
Azure Portal Typ zasobu aplikacji logiki (Standardowa) Tworzenie przepływów pracy integracji dla usługi Logic Apps z jedną dzierżawą — Azure Portal
Visual Studio Code rozszerzenie Azure Logic Apps (Standardowa) Tworzenie przepływów pracy integracji dla usługi Logic Apps z jedną dzierżawą — Visual Studio Code
Interfejs wiersza polecenia platformy Azure Rozszerzenie interfejsu wiersza polecenia platformy Azure usługi Logic Apps Jeszcze niedostępne

Środowisko z wieloma dzierżawami

Opcja Zasoby i narzędzia Więcej informacji
Azure Portal Typ zasobu aplikacji logiki (Zużycie) Szybki start: tworzenie przepływów pracy integracji w Azure Logic Apps z wieloma dzierżawami — Azure Portal
Visual Studio Code rozszerzenie Azure Logic Apps (Zużycie) Szybki start: tworzenie przepływów pracy integracji w Azure Logic Apps z wieloma dzierżawami — Visual Studio Code
Interfejs wiersza polecenia platformy Azure Rozszerzenie interfejsu wiersza polecenia platformy Azure usługi Logic Apps - Szybki start: tworzenie przepływów pracy integracji i zarządzanie nimi w Azure Logic Apps z wieloma dzierżawami — interfejs wiersza polecenia platformy Azure

- az logic

Azure Resource Manager Tworzenie aplikacji logiki Szablon usługi ARM Szybki start: tworzenie i wdrażanie przepływów pracy integracji w Azure Logic Apps z wieloma dzierżawami — szablon usługi ARM
Azure PowerShell Moduł Az.LogicApp Rozpoczynanie pracy z programem Azure PowerShell
Interfejs API REST platformy Azure interfejs API REST Azure Logic Apps dokumentacja interfejsu API REST platformy Azure Wprowadzenie

Środowisko usługi integracji

Opcja Zasoby i narzędzia Więcej informacji
Azure Portal Typ zasobu aplikacji logiki (Zużycie) z istniejącym zasobem ISE Tak samo jak w przewodniku Szybki start: tworzenie przepływów pracy integracji w Azure Logic Apps z wieloma dzierżawami — Azure Portal, ale wybranie środowiska ISE, a nie regionu z wieloma dzierżawami.

Mimo że środowiska programistyczne różnią się w zależności od tego, czy tworzysz zasoby aplikacji logiki Consumption czy Standard , możesz znaleźć i uzyskać dostęp do wszystkich wdrożonych aplikacji logiki w ramach subskrypcji platformy Azure.

Na przykład na Azure Portal na stronie Aplikacje logiki są wyświetlane typy zasobów Aplikacji logiki Zużycie i Standardowa. W Visual Studio Code wdrożone aplikacje logiki są wyświetlane w ramach subskrypcji platformy Azure, ale są pogrupowane według użytego rozszerzenia, a mianowicie Azure: Logic Apps (Consumption) i Azure: Logic Apps (Standard).

Stanowe i bezstanowe przepływy pracy

Za pomocą typu zasobu Aplikacja logiki (Standardowa) można utworzyć te typy przepływów pracy w tej samej aplikacji logiki:

  • Stanowe

    Utwórz stanowy przepływ pracy, gdy musisz przechowywać, przeglądać lub odwoływać się do danych z poprzednich zdarzeń. Te przepływy pracy zapisują i przesyłają wszystkie dane wejściowe i wyjściowe dla każdej akcji oraz ich stanów do magazynu zewnętrznego, co sprawia, że przeglądanie szczegółów przebiegu i historii jest możliwe po zakończeniu każdego przebiegu. Stanowe przepływy pracy zapewniają wysoką odporność w przypadku awarii. Po przywróceniu usług i systemów można odtworzyć przerwane przebiegi z zapisanego stanu i ponownie uruchomić przepływy pracy do ukończenia. Stanowe przepływy pracy mogą nadal działać dłużej niż bezstanowe przepływy pracy.

    Domyślnie przepływy pracy stanowe w Azure Logic Apps wielodostępnych i z jedną dzierżawą są uruchamiane asynchronicznie. Wszystkie akcje oparte na protokole HTTP są zgodne ze standardowym wzorcem operacji asynchronicznych. Ten wzorzec określa, że po wywołaniu akcji HTTP lub wysłaniu żądania do punktu końcowego, usługi, systemu lub interfejsu API odbiornik natychmiast zwraca odpowiedź "202 ACCEPTED". Ten kod potwierdza, że odbiorca zaakceptował żądanie, ale nie zakończył przetwarzania. Odpowiedź może zawierać location nagłówek, który określa identyfikator URI i identyfikator odświeżania, którego obiekt wywołujący może użyć do sondowania lub sprawdzenia stanu żądania asynchronicznego, dopóki odbiorca nie przestanie przetwarzać i zwraca odpowiedź powodzenia "200 OK" lub inną odpowiedź inną niż 202. Jednak obiekt wywołujący nie musi czekać na zakończenie przetwarzania żądania i może kontynuować wykonywanie następnej akcji. Aby uzyskać więcej informacji, zobacz Asynchroniczna integracja mikrousług wymusza autonomię mikrousług.

  • Bezstanowe

    Utwórz bezstanowy przepływ pracy, gdy nie musisz przechowywać, przeglądać ani odwoływać się do danych z poprzednich zdarzeń w magazynie zewnętrznym po zakończeniu każdego przebiegu w celu późniejszego przeglądu. Te przepływy pracy zapisują wszystkie dane wejściowe i wyjściowe dla każdej akcji i ich stanów tylko w pamięci, a nie w magazynie zewnętrznym. W związku z tym przepływy pracy bezstanowe mają krótsze przebiegi, które są zwykle krótsze niż 5 minut, szybsze działanie z krótszymi czasami odpowiedzi, wyższą przepływnością i niższymi kosztami działania, ponieważ szczegóły przebiegu i historia nie są zapisywane w magazynie zewnętrznym. Jeśli jednak wystąpi awaria, przerwane przebiegi nie zostaną automatycznie przywrócone, więc obiekt wywołujący musi ręcznie ponownie przesłać przerwane przebiegi.

    Ważne

    Przepływ pracy bezstanowy zapewnia najlepszą wydajność podczas obsługi danych lub zawartości, takich jak plik, który nie przekracza 64 KB całkowitego rozmiaru. Większe rozmiary zawartości, takie jak wiele dużych załączników, mogą znacznie spowolnić wydajność przepływu pracy, a nawet spowodować awarię przepływu pracy z powodu wyjątków braku pamięci. Jeśli przepływ pracy może być musiał obsługiwać większe rozmiary zawartości, zamiast tego użyj stanowego przepływu pracy.

    Przepływy pracy bezstanowe są uruchamiane tylko synchronicznie, więc nie używają standardowego wzorca operacji asynchronicznej używanego przez stanowe przepływy pracy. Zamiast tego wszystkie akcje oparte na protokole HTTP, które zwracają odpowiedź "202 ACCEPTED" , przejdź do następnego kroku wykonywania przepływu pracy. Jeśli odpowiedź zawiera location nagłówek, przepływ pracy bezstanowy nie będzie sondować określonego identyfikatora URI w celu sprawdzenia stanu. Aby postępować zgodnie ze standardowym wzorcem operacji asynchronicznych, zamiast tego użyj stanowego przepływu pracy.

    Aby ułatwić debugowanie, możesz włączyć historię uruchamiania dla bezstanowego przepływu pracy, który ma wpływ na wydajność, a następnie wyłączyć historię uruchamiania po zakończeniu pracy. Aby uzyskać więcej informacji, zobacz Tworzenie przepływów pracy opartych na jednej dzierżawie w Visual Studio Code lub Tworzenie przepływów pracy opartych na jednej dzierżawie w Azure Portal.

    Uwaga

    Przepływy pracy bezstanowe obsługują obecnie tylko akcjedla łączników zarządzanych, które są wdrażane na platformie Azure, a nie wyzwalacze. Aby uruchomić przepływ pracy, wybierz wbudowany wyzwalacz żądania, usługi Event Hubs lub Service Bus. Te wyzwalacze są uruchamiane natywnie w środowisku uruchomieniowym Azure Logic Apps. Aby uzyskać więcej informacji na temat ograniczonych, niedostępnych lub nieobsługiwanych wyzwalaczy, akcji i łączników, zobacz Zmieniono, ograniczone, niedostępne lub nieobsługiwane możliwości.

Różnice między stanowymi i bezstanowymi przepływami pracy

Bezstanowe Stanowe
Domyślnie nie przechowuje historii uruchamiania, danych wejściowych ani danych wyjściowych Przechowuje historię uruchamiania, dane wejściowe i wyjściowe
Wyzwalacze łącznika zarządzanego są niedostępne lub niedozwolone Dostępne i dozwolone są wyzwalacze łącznika zarządzanego
Brak obsługi fragmentów Obsługuje fragmentowanie
Brak obsługi operacji asynchronicznych Obsługuje operacje asynchroniczne
Najlepsze dla przepływów pracy z maksymalnym czasem trwania poniżej 5 minut Edytowanie domyślnego maksymalnego czasu trwania przebiegu w konfiguracji hosta
Najlepsze do obsługi małych rozmiarów komunikatów (poniżej 64K) Obsługuje duże komunikaty

Zagnieżdżone różnice między stanowymi i bezstanowymi przepływami pracy

Przepływ pracy można wywołać z innych przepływów pracy, które istnieją w tym samym zasobie aplikacji logiki (Standardowa) przy użyciu wyzwalacza żądania, wyzwalacza elementuwebhook HTTP lub wyzwalaczy łącznika zarządzanego, które mają typ ApiConnectionWebhook i mogą odbierać żądania HTTPS.

Poniżej przedstawiono wzorce zachowania, które zagnieżdżone przepływy pracy mogą być przestrzegane po wywołaniu podrzędnego przepływu pracy przez nadrzędny przepływ pracy:

  • Wzorzec sondowania asynchronicznego

    Element nadrzędny nie czeka na odpowiedź na początkowe wywołanie, ale stale sprawdza historię uruchamiania dziecka do momentu zakończenia działania elementu podrzędnego. Domyślnie stanowe przepływy pracy są zgodne z tym wzorcem, co jest idealne dla długotrwałych przepływów pracy podrzędnych, które mogą przekraczać limity limitu czasu żądania.

  • Wzorzec synchroniczny ("ogień i zapomnij")

    Element podrzędny potwierdza wywołanie, natychmiast zwracając odpowiedź, a element nadrzędny kontynuuje następną 202 ACCEPTED akcję bez oczekiwania na wyniki z elementu podrzędnego. Zamiast tego element nadrzędny otrzymuje wyniki po zakończeniu działania elementu podrzędnego. Podrzędne przepływy pracy stanowe, które nie zawierają akcji Odpowiedź, zawsze są zgodne ze wzorcem synchronicznym. W przypadku podrzędnych przepływów pracy stanowych historia uruchamiania jest dostępna do przejrzenia.

    Aby włączyć to zachowanie, w definicji JSON przepływu pracy ustaw operationOptions właściwość na DisableAsyncPattern. Aby uzyskać więcej informacji, zobacz Wyzwalacz i typy akcji — opcje operacji.

  • Wyzwalanie i oczekiwanie

    W przypadku przepływu pracy bezstanowego podrzędnego element nadrzędny czeka na odpowiedź zwracającą wyniki z elementu podrzędnego. Ten wzorzec działa podobnie do używania wbudowanego wyzwalacza HTTP lub akcji w celu wywołania podrzędnego przepływu pracy. Przepływy pracy bezstanowe podrzędne, które nie zawierają akcji Odpowiedź natychmiast zwracają 202 ACCEPTED odpowiedź, ale element nadrzędny czeka na zakończenie działania podrzędnego przed kontynuowaniem następnej akcji. Te zachowania dotyczą tylko podrzędnych przepływów pracy bezstanowych.

Ta tabela określa zachowanie podrzędnego przepływu pracy na podstawie tego, czy element nadrzędny i podrzędny są stanowe, bezstanowe lub są mieszanymi typami przepływu pracy:

Nadrzędny przepływ pracy Podrzędny przepływ pracy Zachowanie podrzędne
Stanowe Stanowe Asynchroniczne lub synchroniczne z "operationOptions": "DisableAsyncPattern" ustawieniem
Stanowe Bezstanowe Wyzwalanie i oczekiwanie
Bezstanowe Stanowe Synchronous
Bezstanowe Bezstanowe Wyzwalanie i oczekiwanie

Inne możliwości modelu z jedną dzierżawą

Model z jedną dzierżawą i typ zasobu aplikacji logiki (Standardowa) obejmują wiele bieżących i nowych możliwości, na przykład:

  • Twórz aplikacje logiki i ich przepływy pracy na podstawie 400+ zarządzanych łączników dla oprogramowania jako usługi (SaaS) i aplikacji i usług typu platforma jako usługa (PaaS) oraz łączników dla systemów lokalnych.

    • Więcej zarządzanych łączników jest teraz dostępnych jako wbudowane operacje i działa podobnie do innych wbudowanych operacji, takich jak Azure Functions. Wbudowane operacje są uruchamiane natywnie w środowisku uruchomieniowym Azure Logic Apps z jedną dzierżawą. Na przykład nowe wbudowane operacje obejmują Azure Service Bus, Azure Event Hubs, SQL Server, MQ, DB2 i IBM Host File.

      Uwaga

      W przypadku wbudowanej wersji SQL Server tylko akcja Wykonaj zapytanie może bezpośrednio łączyć się z sieciami wirtualnymi platformy Azure bez korzystania z lokalnej bramy danych.

    • Możesz utworzyć własne wbudowane łączniki dla dowolnej potrzebnej usługi przy użyciu platformy rozszerzalności Azure Logic Apps z jedną dzierżawą. Podobnie jak w przypadku wbudowanych operacji, takich jak Azure Service Bus i SQL Server, ale w przeciwieństwie do niestandardowych łączników zarządzanych, które nie są obecnie obsługiwane, niestandardowe wbudowane łączniki zapewniają większą przepływność, małe opóźnienia i łączność lokalną, ponieważ są uruchamiane w tym samym procesie co środowisko uruchomieniowe z jedną dzierżawą.

      Funkcja tworzenia jest obecnie dostępna tylko w Visual Studio Code, ale nie jest domyślnie włączona. Aby utworzyć te łączniki, przełącz projekt na podstawie pakietów rozszerzeń (Node.js) na NuGet oparte na pakietach (.NET). Aby uzyskać więcej informacji, zobacz Azure Logic Apps Running Anywhere — wbudowana rozszerzalność łącznika.

    • Możesz użyć następujących akcji dla operacji Liquid Operations i OPERACJI XML bez konta integracji. Te operacje obejmują następujące akcje:

      • XML: Przekształcanie poprawnościXML i XML

      • Liquid: przekształcanie formatu JSON w format JSON, przekształcanie formatu JSON na tekst, przekształcanie kodu XML w format JSON i przekształcanie kodu XML na tekst

      Uwaga

      Aby użyć tych akcji w Azure Logic Apps z jedną dzierżawą (Standardowa), musisz mieć mapy Liquid, mapy XML lub schematy XML. Te artefakty można przekazać w Azure Portal z menu zasobów aplikacji logiki w obszarze Artifacts, w tym sekcje Schematy i Mapy. Możesz też dodać te artefakty do folderu Artifacts projektu Visual Studio Code przy użyciu odpowiednich folderów Mapy i Schematy. Następnie możesz użyć tych artefaktów w wielu przepływach pracy w ramach tego samego zasobu aplikacji logiki.

    • Zasoby aplikacji logiki (Standardowa) mogą działać w dowolnym miejscu, ponieważ Azure Logic Apps generuje parametry połączenia sygnatury dostępu współdzielonego (SAS), których te aplikacje logiki mogą używać do wysyłania żądań do punktu końcowego środowiska uruchomieniowego połączenia w chmurze. usługa Azure Logic Apps zapisuje te parametry połączenia z innymi ustawieniami aplikacji, aby można było łatwo przechowywać te wartości na platformie Azure Key Vault podczas wdrażania na platformie Azure.

    • Typ zasobu aplikacji logiki (Standardowa) obsługuje tożsamość zarządzaną przypisaną przez system i wiele tożsamości zarządzanych przypisanych przez użytkownika w tym samym czasie, chociaż nadal można wybrać tylko jedną tożsamość do użycia w dowolnym momencie.

      Uwaga

      Domyślnie tożsamość przypisana przez system jest już włączona do uwierzytelniania połączeń w czasie wykonywania. Ta tożsamość różni się od poświadczeń uwierzytelniania lub parametrów połączenia używanych podczas tworzenia połączenia. Jeśli ta tożsamość zostanie wyłączona, połączenia nie będą działać w czasie wykonywania. Aby wyświetlić to ustawienie, w menu aplikacji logiki w obszarze Ustawienia wybierz pozycję Tożsamość.

  • Aplikacje logiki i ich przepływy pracy można uruchamiać lokalnie, testować i debugować w środowisku deweloperów Visual Studio Code.

    Przed uruchomieniem i przetestowaniem aplikacji logiki możesz ułatwić debugowanie, dodając i używając punktów przerwania w pliku workflow.json dla przepływu pracy. Jednak punkty przerwania są obsługiwane tylko w przypadku akcji w tej chwili, a nie wyzwalaczy. Aby uzyskać więcej informacji, zobacz Tworzenie przepływów pracy opartych na jednej dzierżawie w Visual Studio Code.

  • Bezpośrednio publikuj lub wdrażaj aplikacje logiki oraz ich przepływy pracy z Visual Studio Code do różnych środowisk hostingu, takich jak Azure i Azure Arc z włączoną usługą Logic Apps.

  • Włącz funkcje rejestrowania i śledzenia diagnostyki dla aplikacji logiki przy użyciu Szczegółowe informacje aplikacji, jeśli są obsługiwane przez ustawienia subskrypcji platformy Azure i aplikacji logiki.

  • Uzyskiwanie dostępu do funkcji sieciowych, takich jak łączenie i integrowanie prywatnie z sieciami wirtualnymi platformy Azure, podobnie jak Azure Functions podczas tworzenia i wdrażania aplikacji logiki przy użyciu planu Azure Functions Premium. Aby uzyskać więcej informacji, zapoznaj się z następującą dokumentacją:

  • Wygeneruj ponownie klucze dostępu dla połączeń zarządzanych używanych przez poszczególne przepływy pracy w zasobie aplikacji logiki (Standardowa). W tym zadaniu wykonaj te same kroki dla zasobu usługi Logic Apps (zużycie), ale na poziomie indywidualnego przepływu pracy, a nie na poziomie zasobu aplikacji logiki.

Zmienione, ograniczone, niedostępne lub nieobsługiwane możliwości

W przypadku zasobu aplikacji logiki (w warstwie Standardowa) te możliwości uległy zmianie lub są one obecnie ograniczone, niedostępne lub nieobsługiwane:

  • Wyzwalacze i akcje: wbudowane wyzwalacze i akcje są uruchamiane natywnie w Azure Logic Apps, podczas gdy zarządzane łączniki są hostowane i uruchamiane na platformie Azure. Niektóre wbudowane wyzwalacze i akcje są niedostępne, takie jak okno przewijania, usługa Batch, usługi aplikacja systemu Azure i usługa Azure API Management. Aby uruchomić stanowy lub bezstanowy przepływ pracy, użyj wbudowanego wyzwalacza Cykl, Żądanie, HTTP, HTTP, Http Webhook, Event Hubs lub Service Bus. W projektancie wbudowane wyzwalacze i akcje są wyświetlane na karcie Wbudowane .

    W przypadku stanowychprzepływów pracy wyzwalacze i akcje łącznika zarządzanego są wyświetlane na karcie Azure , z wyjątkiem niedostępnych operacji wymienionych poniżej. W przypadku przepływów pracy bezstanowych karta platformy Azure nie jest wyświetlana, gdy chcesz wybrać wyzwalacz. Można wybrać tylko akcje łącznika zarządzanego, a nie wyzwalacze. Mimo że można włączyć zarządzane łączniki hostowane na platformie Azure dla bezstanowych przepływów pracy, projektant nie wyświetla żadnych wyzwalaczy łącznika zarządzanego, które można dodać.

    Uwaga

    Aby uruchamiać je lokalnie w Visual Studio Code, wyzwalacze i akcje oparte na elementach webhook wymagają dodatkowej konfiguracji. Aby uzyskać więcej informacji, zobacz Tworzenie przepływów pracy opartych na jednej dzierżawie w Visual Studio Code.

    • Te wyzwalacze i akcje zostały zmienione lub są obecnie ograniczone, nieobsługiwane lub niedostępne:

      • Wyzwalacze lokalnej bramy danych są niedostępne, ale dostępne akcje bramy.

      • Wbudowana akcja, Azure Functions — wybieranie funkcji platformy Azure to teraz Operacje funkcji platformy Azure — wywoływanie funkcji platformy Azure. Ta akcja obecnie działa tylko w przypadku funkcji utworzonych na podstawie szablonu wyzwalacza HTTP .

        W Azure Portal możesz wybrać funkcję wyzwalacza HTTP, do której można uzyskać dostęp, tworząc połączenie za pośrednictwem środowiska użytkownika. Jeśli sprawdzisz definicję JSON akcji funkcji w widoku kodu lub w pliku workflow.json przy użyciu Visual Studio Code, akcja odwołuje się do funkcji przy użyciu connectionName odwołania. Ta wersja tworzy abstrakcję informacji funkcji jako połączenia, które można znaleźć w pliku connections.json projektu aplikacji logiki, który jest dostępny po utworzeniu połączenia w Visual Studio Code.

        Uwaga

        W modelu z jedną dzierżawą akcja funkcji obsługuje tylko uwierzytelnianie ciągu zapytania. Azure Logic Apps pobiera klucz domyślny z funkcji podczas nawiązywania połączenia, przechowuje ten klucz w ustawieniach aplikacji i używa klucza do uwierzytelniania podczas wywoływania funkcji.

        Podobnie jak w modelu wielodostępnym, jeśli odnowisz ten klucz, na przykład za pośrednictwem środowiska Azure Functions w portalu, akcja funkcji nie działa już z powodu nieprawidłowego klucza. Aby rozwiązać ten problem, należy ponownie utworzyć połączenie z funkcją, którą chcesz wywołać lub zaktualizować ustawienia aplikacji przy użyciu nowego klucza.

      • Wbudowana akcja Kodu wbudowanego nosi nazwę Operacje wbudowanego kodu, nie wymaga już konta integracji i ma zaktualizowane limity.

      • Wbudowana akcja, Azure Logic Apps — wybierz przepływ pracy aplikacji logiki to teraz Operacje przepływu pracy — Wywołaj przepływ pracy w tej aplikacji przepływu pracy.

      • Niektóre wyzwalacze i akcje dla kont integracji są niedostępne, na przykład akcje AS2 (V2) i akcje RosettaNet.

      • Łącznik usługi Gmail nie jest obecnie obsługiwany.

      • Łączniki zarządzane niestandardowe nie są obecnie obsługiwane. Można jednak tworzyć niestandardowe operacje wbudowane podczas korzystania z Visual Studio Code. Aby uzyskać więcej informacji, zobacz Tworzenie przepływów pracy opartych na jednej dzierżawie przy użyciu Visual Studio Code.

  • Uwierzytelnianie: następujące typy uwierzytelniania są obecnie niedostępne dla typu zasobu Aplikacja logiki (Standardowa):

    • Azure Active Directory Open Authentication (Azure AD OAuth) dla wywołań przychodzących do wyzwalaczy opartych na żądaniach, takich jak wyzwalacz żądania i wyzwalacz elementu webhook HTTP.

    • Tożsamość zarządzana przypisana przez użytkownika. Obecnie dostępna i automatycznie włączona jest tylko tożsamość zarządzana przypisana przez system.

  • Przekształcanie XML: obsługa odwoływania się do zestawów z map jest obecnie niedostępna. Ponadto obecnie obsługiwana jest tylko wersja XSLT 1.0.

  • Debugowanie punktu przerwania w Visual Studio Code: chociaż można dodawać i używać punktów przerwania w pliku workflow.json dla przepływu pracy, punkty przerwania są obsługiwane tylko w przypadku akcji w tej chwili, a nie wyzwalaczy. Aby uzyskać więcej informacji, zobacz Tworzenie przepływów pracy opartych na jednej dzierżawie w Visual Studio Code.

  • Historia wyzwalaczy i historia uruchamiania: dla typu zasobu aplikacji logiki (Standardowa) historia wyzwalacza i historia uruchamiania w Azure Portal są wyświetlane na poziomie przepływu pracy, a nie na poziomie aplikacji logiki. Aby uzyskać więcej informacji, zobacz Tworzenie przepływów pracy opartych na jednej dzierżawie przy użyciu Azure Portal.

  • Kontrolka Powiększenia: kontrolka powiększenia jest obecnie niedostępna w projektancie.

  • Cele wdrożenia: nie można wdrożyć typu zasobu Aplikacji logiki (Standardowa) w środowisku usługi integracji (ISE) ani w miejscach wdrożenia platformy Azure.

  • Azure API Management: obecnie nie można zaimportować typu zasobu aplikacji logiki (Standardowa) do usługi Azure API Management. Można jednak zaimportować typ zasobu Aplikacja logiki (Zużycie).

Ścisłe uprawnienia ruchu sieciowego i zapory

Jeśli środowisko ma ścisłe wymagania sieciowe lub zapory ograniczające ruch, musisz zezwolić na dostęp do wszystkich połączeń wyzwalacza lub akcji w przepływach pracy. Opcjonalnie możesz zezwolić na ruch z tagów usług i używać tego samego poziomu ograniczeń lub zasad co Azure App Service. Należy również znaleźć i użyć w pełni kwalifikowanych nazw domen (FQDN) dla połączeń. Aby uzyskać więcej informacji, zapoznaj się z odpowiednimi sekcjami w następującej dokumentacji:

Następne kroki

Chcielibyśmy również poznać Twoje doświadczenia z Azure Logic Apps z jedną dzierżawą!