Różnice między standardowymi aplikacjami logiki z jedną dzierżawą a użyciem wielodostępnych aplikacji logiki

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 dla przedsiębiorstw i firm (B2B). Podczas tworzenia zasobu aplikacji logiki należy wybrać opcję Użycie lub Hosting w warstwie Standardowa. Aplikacja logiki Zużycie może mieć tylko jeden przepływ pracy uruchamiany w wielodostępnej usłudze Azure Logic Apps. Aplikacja logiki w warstwie Standardowa może mieć jeden lub wiele przepływów pracy uruchamianych w usłudze Azure Logic Apps z jedną dzierżawą lub w środowisku App Service Environment w wersji 3 (ASE v3).

Przed wybraniem zasobu aplikacji logiki do utworzenia zapoznaj się z poniższym przewodnikiem, aby dowiedzieć się, jak typy przepływów pracy aplikacji logiki są porównywane ze sobą. Następnie możesz lepiej wybrać przepływ pracy aplikacji logiki i środowisko najlepiej dopasowane do scenariusza, wymagań dotyczących rozwiązań i miejsca docelowego, w którym chcesz wdrożyć i uruchomić przepływy pracy.

Jeśli dopiero zaczynasz korzystać z usługi Azure Logic Apps, zapoznaj się z tematem Co to jest usługa Azure Logic Apps? i Co to jest przepływ pracy aplikacji logiki?.

Typy i środowiska przepływów pracy aplikacji logiki

W poniższej tabeli przedstawiono podsumowanie różnic między przepływem pracy aplikacji logiki Zużycie a przepływem pracy standardowej aplikacji logiki. Dowiesz się również, jak środowisko z jedną dzierżawą różni się od środowiska wielodostępnego do wdrażania, hostowania i uruchamiania przepływów pracy.

Opcja hostingu	Świadczenia	Udostępnianie i użycie zasobów	Model cen i rozliczeń	Zarządzanie limitami
Zużycie Środowisko hosta: wielodostępna usługa Azure Logic Apps	- Najłatwiej rozpocząć - Zapłać za to, czego używasz — W pełni zarządzane	Pojedynczy zasób aplikacji logiki może mieć tylko jeden przepływ pracy. Wszystkie aplikacje logiki w dzierżawach firmy Microsoft Entra współdzielą takie same przetwarzanie (obliczenia), magazyn, sieć itd. W celach nadmiarowych dane są replikowane w sparowanym regionie. W przypadku wysokiej dostępności magazyn geograficznie nadmiarowy (GRS) jest włączony.	Użycie (płatność za wykonanie)	Usługa Azure Logic Apps zarządza wartościami domyślnymi dla tych limitów, ale możesz zmienić niektóre z tych wartości, jeśli ta opcja istnieje dla określonego limitu.
Standardowa (plan usługi przepływu pracy) Środowisko hosta: Usługa 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?	— Więcej wbudowanych łączników hostowanych w środowisku uruchomieniowym z jedną dzierżawą w celu zwiększenia 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.	Pojedynczy zasób aplikacji 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. Dane pozostają w tym samym regionie, w którym wdrażasz aplikację logiki.	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 usługi Azure Logic Apps wykonuje transakcje magazynu zgodne z cennikiem 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 programie 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 usłudze Azure Logic Apps z jedną dzierżawą.
Standardowa (App Service Environment w wersji 3) Środowisko hosta: App Service Environment v3 (ASEv3) — tylko plany systemu 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 usłudze Azure Logic Apps z jedną dzierżawą. — Płacisz tylko za plan usługi 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 usługi App Service. — Dziedzicz konfigurację sieci z wybranego środowiska ASEv3. Na przykład podczas wdrażania 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, uruchamianie historii przepływów pracy w tym środowisku ASE nie może 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. Dane pozostają w tym samym regionie, w którym wdrażasz aplikacje logiki.	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 programie 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 usłudze Azure Logic Apps z jedną dzierżawą.

Standardowa aplikacja logiki i przepływ pracy

Aplikacja logiki w warstwie Standardowa i przepływ pracy są obsługiwane przez przeprojektowane środowisko uruchomieniowe usługi Azure Logic Apps z jedną dzierżawą. To środowisko uruchomieniowe używa modelu rozszerzalności usługi Azure Functions i jest hostowane jako rozszerzenie w środowisku uruchomieniowym usługi 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 usługi aplikacja systemu Azure 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 usługi aplikacja systemu Azure w wersji 3 (tylko plany systemu Windows).

Aplikacja logiki w warstwie Standardowa 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 przetwarzania, 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, kontynuuj przeglądanie poniższych sekcji. Aby uzyskać więcej informacji na temat środowiska uruchomieniowego usługi Azure Logic Apps z jedną dzierżawą i rozszerzalności usługi Azure Functions, zapoznaj się z następującą dokumentacją:

• Usługa Azure Logic Apps uruchomiona w dowolnym miejscu — szczegółowe omówienie środowiska uruchomieniowego
• Wprowadzenie do usługi Azure Functions
• Wyzwalacze i powiązania usługi Azure Functions

Przenośność i elastyczność

Podczas tworzenia standardowej aplikacji logiki i przepływu pracy można wdrożyć i uruchomić przepływ pracy w innych środowiskach, takich jak środowisko usługi aplikacja systemu Azure w wersji 3 (tylko plany systemu Windows). Jeśli używasz programu Visual Studio Code z rozszerzeniem usługi Azure Logic Apps (Standard), możesz lokalnie opracowywać, kompilować i uruchamiać przepływ pracy w środowisku projektowym bez konieczności wdrażania na platformie Azure. Jeśli twój scenariusz wymaga kontenerów, możesz utworzyć aplikacje logiki z jedną dzierżawą 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 istniejącego zasobu uruchomionego na platformie Azure. Model wielodostępny do automatyzacji wdrażania zasobów aplikacji logiki Zużycie jest oparty na szablonach usługi Azure Resource Manager (szablonach usługi ARM), które łączą i obsługują aprowizację zasobów dla aplikacji i infrastruktury.

W przypadku zasobu aplikacji logiki w warstwie Standardowa wdrożenie staje się łatwiejsze, ponieważ można oddzielić wdrażanie aplikacji od wdrożenia infrastruktury. Możesz spakować środowisko uruchomieniowe usługi Azure Logic Apps z jedną dzierżawą i przepływy pracy w ramach zasobu lub projektu aplikacji logiki. Możesz użyć ogólnych kroków lub zadań, które kompilują, składają i spakują 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 oddzielnego aprowizowania 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 wdrożyć 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 podczas kompilowania potoków wdrażania dla aplikacji oraz uruchamiania wymaganych testów i walidacji przed opublikowaniem w środowisku produkcyjnym.

Wydajność

Za pomocą standardowej aplikacji logiki można tworzyć i uruchamiać wiele przepływów pracy w tym samym zasobie i dzierżawie aplikacji logiki. 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ść.

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

W przypadku korzystania z nowych wbudowanych operacji łącznika można tworzyć 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 usługi 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.

Przechowywanie danych

Standardowe zasoby aplikacji logiki są hostowane w usłudze 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 pozostają w tym samym regionie, w którym tworzysz i wdrażasz ich zasoby nadrzędne.

Bezpośredni dostęp do zasobów w sieciach wirtualnych platformy Azure

Przepływy pracy uruchamiane w jednej dzierżawie usługi Azure Logic Apps mogą uzyskiwać bezpośredni dostęp do zabezpieczonych zasobów, takich jak maszyny wirtualne, inne usługi i systemy istniejące w sieci wirtualnej platformy Azure.

Usługa Azure Logic Apps z jedną dzierżawą to dedykowane wystąpienie usługi Azure Logic Apps, korzysta z dedykowanych zasobów i działa oddzielnie od wielodostępnej usługi Azure Logic Apps. Uruchamianie przepływów pracy w dedykowanym wystąpieniu pomaga zmniejszyć wpływ innych dzierżaw platformy Azure na wydajność aplikacji, znany również jako efekt "hałaśliwych sąsiadów".

Usługa Azure Logic Apps z jedną dzierżawą zapewnia również następujące korzyści:

• Własne statyczne adresy IP, które są oddzielone od statycznych adresów IP udostępnianych przez aplikacje logiki w wielodostępnej usłudze Azure Logic Apps. Można również skonfigurować pojedynczy publiczny, statyczny i przewidywalny adres IP ruchu wychodzącego w celu komunikowania się z systemami docelowymi. W ten sposób nie trzeba konfigurować dodatkowych otworów zapory w tych systemach docelowych.

• Zwiększone limity czasu trwania przebiegu, przechowywania magazynu, przepływności, limitów czasu żądań HTTP i odpowiedzi, rozmiarów komunikatów i żądań łącznika niestandardowego. Aby uzyskać więcej informacji, zobacz Limity i konfiguracja usługi Azure Logic Apps.

Opcje tworzenia, kompilowania i wdrażania

Aby utworzyć zasób aplikacji 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	Standardowa aplikacja logiki	Tworzenie przykładowego standardowego przepływu pracy aplikacji logiki w usłudze Azure Logic Apps z jedną dzierżawą — Azure Portal
Visual Studio Code	Rozszerzenie usługi Azure Logic Apps (Standardowa)	Tworzenie przykładowego przepływu pracy standardowej aplikacji logiki w usłudze Azure Logic Apps z jedną dzierżawą — Visual Studio Code
Interfejs wiersza polecenia platformy Azure	Rozszerzenie interfejsu wiersza polecenia platformy Azure usługi Logic Apps	az logicapp
Azure Resource Manager	- Lokalny - DevOps	Usługa Azure Logic Apps z jedną dzierżawą
Usługa Logic Apps z obsługą usługi Azure Arc	Przykład usługi Logic Apps z obsługą usługi Azure Arc	- Co to jest usługa Logic Apps z obsługą usługi Azure Arc? - Tworzenie i wdrażanie przepływów pracy aplikacji logiki opartej na jednej dzierżawie za pomocą usługi Logic Apps z obsługą usługi Azure Arc
Interfejs API REST platformy Azure	interfejs API REST usługi aplikacja systemu Azure* Uwaga: interfejs API REST standardowej aplikacji logiki jest dołączony do interfejsu API REST usługi aplikacja systemu Azure.	Wprowadzenie do dokumentacji interfejsu API REST platformy Azure

Środowisko wielodostępne

Opcja	Zasoby i narzędzia	Więcej informacji
Azure Portal	Aplikacja logiki użycia	Szybki start: tworzenie przykładowego przepływu pracy aplikacji logiki zużycie w wielodostępnej usłudze Azure Logic Apps — Azure Portal
Visual Studio Code	Rozszerzenie azure Logic Apps (Zużycie)	Szybki start: tworzenie przykładowego przepływu pracy aplikacji logiki zużycie w wielodostępnej usłudze Azure Logic Apps — 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 aplikacji logiki zużycie i zarządzanie nimi w wielodostępnej usłudze Azure Logic Apps — interfejs wiersza polecenia platformy Azure - az logic
Azure Resource Manager	Tworzenie szablonu usługi ARM aplikacji logiki	Szybki start: tworzenie i wdrażanie przepływów pracy aplikacji logiki Zużycie w wielodostępnej usłudze Azure Logic Apps — szablon usługi ARM
Azure PowerShell	Moduł Az.LogicApp	Rozpoczynanie pracy z programem Azure PowerShell
Interfejs API REST platformy Azure	Azure Logic Apps REST API	Wprowadzenie do dokumentacji interfejsu API REST platformy Azure

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

Na przykład w witrynie Azure Portal na stronie Aplikacje logiki są wyświetlane zasoby aplikacji logiki Zużycie i Standardowa. W programie Visual Studio Code wdrożone aplikacje logiki są wyświetlane w ramach subskrypcji platformy Azure, ale aplikacje logiki Zużycie są wyświetlane w oknie platformy Azure w ramach rozszerzenia Azure Logic Apps (Zużycie), a aplikacje logiki w warstwie Standardowa są wyświetlane w sekcji Zasoby.

Stanowe i bezstanowe przepływy pracy

W aplikacji logiki w warstwie Standardowa można utworzyć następujące typy przepływów pracy:

• 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ą wszystkie dane wejściowe, wyjściowe i stany operacji w magazynie zewnętrznym. Te informacje sprawiają, że przeglądanie szczegółów i historii przebiegu przepływu pracy jest możliwe po zakończeniu każdego przebiegu. Stanowe przepływy pracy zapewniają wysoką odporność, jeśli wystąpi awaria. Po przywróceniu usług i systemów można odtworzyć przerwane przebiegi ze stanu zapisanego i ponownie uruchomić przepływy pracy do ukończenia. Stanowe przepływy pracy mogą działać znacznie dłużej niż bezstanowe przepływy pracy.

  Domyślnie przepływy pracy stanowe zarówno w wielodostępnych, jak i jednodostępnych aplikacjach Azure Logic Apps są uruchamiane asynchronicznie. Wszystkie akcje oparte na protokole HTTP są zgodne ze standardowym wzorcem operacji asynchronicznych. Po wywołaniu akcji HTTP lub wysłaniu żądania do punktu końcowego, usługi, systemu lub interfejsu API odbiorca żądania natychmiast zwraca odpowiedź "ZAAKCEPTOWANE" 202. 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 Asynchroniczne integracje mikrousług wymusza autonomię mikrousług.

• Bezstanowej

  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 oraz ich stany 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 zwykle kończą się w ciągu 5 minut lub mniej, szybciej działają z krótszym czasem odpowiedzi, wyższą przepływnością i niższymi kosztami działania, ponieważ magazyn zewnętrzny nie zapisuje szczegółów i historii przebiegu przepływu pracy. Jeśli jednak wystąpi awaria, przerwane przebiegi nie zostaną automatycznie przywrócone, dlatego obiekt wywołujący musi ręcznie ponownie przesłać przerwane przebiegi.

  Przepływ pracy bezstanowy zapewnia najlepszą wydajność w przypadku obsługi danych lub zawartości, które nie przekraczają 64 KB całkowitego rozmiaru, takiego jak plik. 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.

  Uwaga

  W bezstanowych przepływach pracy można używać tylko wyzwalaczy wypychania, w których nie określasz harmonogramu uruchamiania dla przepływu pracy. Te wyzwalacze oparte na elementach webhook oczekują na wystąpienie zdarzenia lub dane, które staną się dostępne. Na przykład wyzwalacz Cykl jest dostępny tylko dla stanowych przepływów pracy. Aby uruchomić przepływ pracy, wybierz wyzwalacz wypychania, taki jak żądanie, usługa Event Hubs lub wyzwalacz usługi Service Bus. Aby uzyskać więcej informacji na temat ograniczonych, niedostępnych lub nieobsługiwanych wyzwalaczy, akcji i łączników, zobacz Zmienione, ograniczone, niedostępne lub nieobsługiwane funkcje.

  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 ZAAKCEPTOWANE" , kontynuują kolejny krok wykonywania przepływu pracy. Jeśli odpowiedź zawiera location nagłówek, bezstanowy przepływ pracy 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 pewien wpływ na wydajność, a następnie wyłączyć historię uruchamiania po zakończeniu. Aby uzyskać więcej informacji, zobacz Tworzenie przepływów pracy opartych na jednej dzierżawie w programie Visual Studio Code lub Tworzenie przepływów pracy opartych na jednej dzierżawie w witrynie Azure Portal.

Ważne

Musisz zdecydować o typie przepływu pracy , stanowym lub bezstanowym, aby zaimplementować go w czasie tworzenia. Zmiany typu przepływu pracy po utworzeniu powoduje błędy środowiska uruchomieniowego.

Podsumowanie różnic między stanowymi i bezstanowymi przepływami pracy

Stanowe	Bezstanowa
Przechowuje historię uruchamiania, dane wejściowe i wyjściowe	Domyślnie nie przechowuje historii uruchamiania, danych wejściowych ani danych wyjściowych
Dostępne i dozwolone są wyzwalacze łącznika zarządzanego	Wyzwalacze łącznika zarządzanego są niedostępne lub niedozwolone
Obsługuje fragmentowanie	Brak obsługi fragmentowania
Obsługuje operacje asynchroniczne	Brak obsługi operacji asynchronicznych
Edytuj domyślny maksymalny czas trwania przebiegu w konfiguracji hosta	Najlepsze dla przepływów pracy z maksymalnym czasem trwania poniżej 5 minut
Obsługuje duże komunikaty	Najlepiej obsługiwać małe rozmiary komunikatów (poniżej 64 KB)

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

Można wywołać przepływ pracy z innych przepływów pracy, które istnieją w tej samej aplikacji logiki w warstwie Standardowa, za pomocą wyzwalacza żądania, wyzwalacza elementu webhook HTTP lub wyzwalaczy łącznika zarządzanego, które mają typ apiConnectionWebhook i mogą odbierać żądania HTTPS.

Na poniższej liście opisano wzorce zachowania, które zagnieżdżone przepływy pracy mogą być wykonywane po wywołaniu podrzędnego przepływu pracy przez nadrzędny przepływ pracy:

• Wzorzec sondowania asynchronicznego

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

• Wzorzec synchroniczny ("fire and forget")

  Podrzędny przepływ pracy potwierdza wywołanie nadrzędnego przepływu pracy, natychmiast zwracając 202 ACCEPTED odpowiedź. Jednak element nadrzędny nie czeka, aż element podrzędny zwróci wyniki. Zamiast tego element nadrzędny kontynuuje kolejną akcję w przepływie pracy i otrzymuje wyniki po zakończeniu działania elementu podrzędnego. Podrzędne stanowe przepływy pracy, które nie zawierają akcji Odpowiedź, zawsze są zgodne ze wzorcem synchronicznym i zapewniają historię uruchamiania 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

  Bezstanowe przepływy pracy działają w pamięci. Dlatego gdy nadrzędny przepływ pracy wywołuje przepływ pracy bezstanowy podrzędny, 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.

W poniższej tabeli przedstawiono zachowanie podrzędnego przepływu pracy na podstawie tego, czy element nadrzędny i podrzędny są stanowe, bezstanowe lub są mieszanymi typami przepływów pracy. Lista po tabeli

Nadrzędny przepływ pracy	Podrzędny przepływ pracy	Zachowanie podrzędne
Stanowe	Stanowe	Asynchroniczna lub synchroniczna z ustawieniem "operationOptions": "DisableAsyncPattern"
Stanowe	Bezstanowa	Wyzwalanie i oczekiwanie
Bezstanowa	Stanowe	Synchronous
Bezstanowa	Bezstanowa	Wyzwalanie i oczekiwanie

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

Model z jedną dzierżawą i standardowa aplikacja logiki obejmują wiele bieżących i nowych funkcji, na przykład:

• Twórz aplikacje logiki i ich przepływy pracy z ponad 1400 łączników zarządzanych dla oprogramowania jako usługi (SaaS) i platformy jako usługi (PaaS) oraz łączników dla systemów lokalnych.

  • Więcej łączników zarządzanych jest teraz dostępnych jako wbudowane łączniki w standardowych przepływach pracy. Wbudowane wersje działają natywnie w środowisku uruchomieniowym usługi Azure Logic Apps z jedną dzierżawą. Niektóre wbudowane łączniki są również nieformalnie znane jako łączniki dostawcy usług. Aby zapoznać się z listą, zapoznaj się z wbudowanymi łącznikami w temacie Zużycie i Standardowa.

  • Możesz utworzyć własne niestandardowe wbudowane łączniki dla dowolnej potrzebnej usługi przy użyciu platformy rozszerzalności usługi Azure Logic Apps z jedną dzierżawą. Podobnie jak w przypadku wbudowanych łączników, takich jak Azure Service Bus i SQL Server, niestandardowe wbudowane łączniki zapewniają większą przepływność, małe opóźnienia i łączność lokalną, ponieważ działają w tym samym procesie co środowisko uruchomieniowe z jedną dzierżawą. Niestandardowe wbudowane łączniki nie są jednak podobne do niestandardowych łączników zarządzanych, które nie są obecnie obsługiwane. Aby uzyskać więcej informacji, zobacz Omówienie łącznika niestandardowego i Tworzenie niestandardowych wbudowanych łączników dla standardowych aplikacji logiki w usłudze Azure Logic Apps z jedną dzierżawą.

  • W przypadku operacji Liquid Operations i XML bez konta integracji można użyć następujących akcji. Te operacje obejmują następujące akcje:

    • XML: Przekształcanie kodu XML, walidacji XML, redagowanie XML przy użyciu schematu i analizowanie kodu XML przy użyciu schematu

    • 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żywać tych akcji w standardowych przepływach pracy, musisz mieć mapy Liquid, mapy XML lub schematy XML. Te artefakty można przekazać w witrynie Azure Portal z menu zasobów aplikacji logiki w obszarze Artefakty, które obejmują sekcje Schematy i Mapy. Możesz też dodać te artefakty do folderu Artifacts projektu programu 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 tej samej aplikacji logiki.

  • Standardowe przepływy pracy aplikacji logiki mogą być wyzwalane z dowolnego miejsca, ponieważ usługa Azure Logic Apps generuje sygnaturę dostępu współdzielonego (SAS) parametry połączenia, 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, dzięki czemu można łatwo przechowywać te wartości w usłudze Azure Key Vault podczas wdrażania na platformie Azure.

  • Standardowe przepływy pracy aplikacji logiki obsługują włączanie tożsamości zarządzanej przypisanej przez system i wielu tożsamości zarządzanych przypisanych przez użytkownika jednocześnie, chociaż można wybrać tylko jedną tożsamość do użycia jednocześnie. Chociaż wbudowane łączniki oparte na dostawcy usług obsługują tożsamość przypisaną przez system, obecnie nie obsługują wybierania tożsamości zarządzanych przypisanych przez użytkownika do uwierzytelniania, z wyjątkiem programu SQL Server i łączników HTTP.

    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 parametry połączenia używanych podczas tworzenia połączenia. Jeśli wyłączysz tę tożsamość, 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ść.

• Możesz lokalnie uruchamiać, testować i debugować aplikacje logiki oraz ich przepływy pracy w środowisku programistycznym programu Visual Studio Code.

  Przed uruchomieniem i przetestowaniem aplikacji logiki można ułatwić debugowanie, dodając punkty przerwania i używając ich 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 programie Visual Studio Code.

• Bezpośrednie publikowanie lub wdrażanie aplikacji logiki i ich przepływów pracy z programu Visual Studio Code w różnych środowiskach hostingu, takich jak Azure i Azure Arc z obsługą usługi Logic Apps.

• Włącz funkcje rejestrowania i śledzenia diagnostyki dla aplikacji logiki przy użyciu usługi Application Insights , jeśli są obsługiwane przez ustawienia subskrypcji platformy Azure i aplikacji logiki.

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

  • Opcje sieciowe usługi Azure Functions

  • Azure Logic Apps Running Anywhere — możliwości sieci w usłudze Azure Logic Apps

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

Wbudowane łączniki dla standardu

Przepływ pracy w warstwie Standardowa może używać wielu z tych samych wbudowanych łączników co przepływ pracy Zużycie, ale nie wszystkie. Na odwrót przepływ pracy w warstwie Standardowa zawiera wiele wbudowanych łączników, które nie są dostępne w przepływie pracy Zużycie.

Na przykład standardowy przepływ pracy zawiera zarówno zarządzane łączniki, jak i wbudowane łączniki dla usług Azure Blob, Azure Cosmos DB, Azure Event Hubs, Azure Service Bus, DB2, FTP, MQ, SFTP, SQL Server i innych. Mimo że przepływ pracy Zużycie nie ma tych samych wbudowanych wersji łącznika, dostępne są inne wbudowane łączniki, takie jak Usługa Azure API Management i usługi aplikacja systemu Azure.

W usłudze Azure Logic Apps z jedną dzierżawą wbudowane łączniki z określonymi atrybutami są nieformalnie znane jako dostawcy usług. Niektóre wbudowane łączniki obsługują tylko jeden sposób uwierzytelniania połączenia z podstawową usługą. Inne wbudowane łączniki mogą oferować wybór, na przykład przy użyciu parametry połączenia, identyfikatora Entra firmy Microsoft lub tożsamości zarządzanej. Wszystkie wbudowane łączniki działają w tym samym procesie co przeprojektowane środowisko uruchomieniowe usługi Azure Logic Apps. Aby uzyskać więcej informacji, zapoznaj się z wbudowaną listą łączników dla przepływów pracy aplikacji logiki w warstwie Standardowa.

Ważne

Upewnij się, że poprawnie skonfigurować i przetestować dowolny wyzwalacz oparty na dostawcy usług, aby potwierdzić pomyślną operację. Wyzwalacz oparty na dostawcy usług nieudanych może spowodować niepotrzebne skalowanie, co może znacznie zwiększyć koszty rozliczeń. Na przykład typowym błędem jest ustawienie wyzwalacza bez udzielenia aplikacji logiki uprawnień lub dostępu do miejsca docelowego, takiego jak kolejka usługi Service Bus, kontener obiektów blob usługi Azure Storage itd. Upewnij się również, że takie wyzwalacze są monitorowane przez cały czas, dzięki czemu można szybko wykryć i rozwiązać wszelkie problemy.

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

W przypadku przepływu pracy aplikacji logiki w warstwie Standardowa następujące możliwości są różne, obecnie ograniczone, niedostępne lub nieobsługiwane:

• Wyzwalacze i akcje: wbudowane wyzwalacze i akcje są uruchamiane natywnie w usłudze Azure Logic Apps, podczas gdy łączniki zarządzane są hostowane i uruchamiane przy użyciu udostępnionych zasobów na platformie Azure. W przypadku standardowych przepływów pracy niektóre wbudowane wyzwalacze i akcje są obecnie niedostępne, takie jak okno przewijania i operacje usługi aplikacja systemu Azure. Aby uruchomić stanowy lub bezstanowy przepływ pracy, użyj wbudowanego wyzwalacza, takiego jak wyzwalacz Request, Event Hubs lub Service Bus. Wyzwalacz Cykl jest dostępny dla stanowych przepływów pracy, ale nie bezstanowych przepływów pracy. W projektancie są wyświetlane wbudowane wyzwalacze i akcje z etykietą W aplikacji , a wyzwalacze i akcje zarządzane łącznika są wyświetlane z etykietą Udostępnione .

  Bezstanowe przepływy pracy mogą używać tylko wyzwalaczy wypychania, w których nie określono harmonogramu uruchamiania dla przepływu pracy. Te wyzwalacze oparte na elementach webhook oczekują na wystąpienie zdarzenia lub dane, które staną się dostępne. Na przykład wyzwalacz Cykl jest dostępny tylko dla stanowych przepływów pracy. Aby uruchomić przepływ pracy, wybierz wyzwalacz wypychania, taki jak żądanie, usługa Event Hubs lub wyzwalacz usługi Service Bus. Mimo że można włączyć łączniki zarządzane dla bezstanowych przepływów pracy, galeria łączników nie wyświetla żadnych wyzwalaczy sondowania łącznika zarządzanego, które mają zostać dodane.

  Uwaga

  Aby uruchomić lokalnie w programie 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 programie Visual Studio Code.

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

    • Wbudowana akcja usługi Azure Functions — wybieranie funkcji platformy Azure to teraz operacje usługi Azure Functions — wywoływanie funkcji platformy Azure. Ta akcja obecnie działa tylko dla funkcji utworzonych na podstawie szablonu wyzwalacza HTTP.

      W witrynie 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 plik workflow.json przy użyciu programu 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 programie Visual Studio Code.

      Uwaga

      W modelu z jedną dzierżawą akcja funkcji obsługuje tylko uwierzytelnianie ciągu zapytania. Usługa 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 usługi 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, Wbudowany kod, ma zmienioną nazwę Operacje wbudowanego kodu, nie wymaga już konta integracji i ma zaktualizowane limity.

    • Wbudowana akcja azure Logic Apps — wybieranie przepływu pracy aplikacji logiki to teraz Operacje przepływu pracy — wywoływanie przepływu pracy w tej aplikacji przepływu pracy.

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

    • Przepływ pracy w warstwie Standardowa może mieć tylko jeden wyzwalacz i nie obsługuje wielu wyzwalaczy.

• Authentication

  • Niektóre wyzwalacze oparte na żądaniach obsługujące wywołania przychodzące, takie jak wyzwalacz żądania, obecnie nie obsługują uwierzytelniania Open Authentication (Microsoft Entra ID OAuth), podczas gdy inne, takie jak wyzwalacz elementu webhook HTTP, obsługują tę obsługę.

  • Niektóre wbudowane łączniki oparte na dostawcy usług obecnie nie obsługują wybierania tożsamości zarządzanej przypisanej przez użytkownika do uwierzytelniania. Jednak obsługa tożsamości zarządzanej przypisanej przez system i przypisanej przez użytkownika jest ogólnie dostępna. Domyślnie tożsamość zarządzana przypisana przez system jest automatycznie włączona.

• Debugowanie punktu przerwania w programie Visual Studio Code: chociaż można dodawać i używać punktów przerwania wewnątrz 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 programie Visual Studio Code.

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

• Szablony programu Terraform: nie można używać tych szablonów z zasobem standardowej aplikacji logiki do pełnego wdrożenia infrastruktury. Aby uzyskać więcej informacji, zobacz Co to jest narzędzie Terraform na platformie Azure?

Ś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 dowolnego wyzwalacza lub akcji połączeń 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 usługa aplikacja systemu Azure. 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:

• Uprawnienia zapory dla aplikacji logiki z jedną dzierżawą — Azure Portal
• Uprawnienia zapory dla aplikacji logiki z jedną dzierżawą — Visual Studio Code

Następne kroki

• Tworzenie przepływów pracy opartych na jednej dzierżawie w witrynie Azure Portal
• Tworzenie przepływów pracy opartych na jednej dzierżawie w programie Visual Studio Code

Chcemy również poznać Twoje doświadczenia z usługą Azure Logic Apps z jedną dzierżawą!

• W przypadku usterek lub problemów utwórz problemy w usłudze GitHub.
• W przypadku pytań, żądań, komentarzy i innych opinii użyj tego formularza opinii.