Różnice między aplikacjami logicznymi w standardowym, jednoosobowym trybie dzierżawy a aplikacjami logicznymi w trybie zużycia z wieloma dzierżawcami

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ę gospodarowania w warstwie Użycia lub Standardowa. Aplikacja logiki konsumcyjnej może mieć tylko jeden przepływ pracy uruchamiany w środowisku wielodostępu Azure Logic Apps. Standardowa aplikacja logiczna może zawierać jeden lub wiele przepływów pracy, które działają w jednodzierżawowym rozwiązaniu Azure Logic Apps 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 Consumption a przepływem pracy aplikacji logiki Standard. Dowiesz się również, jak środowisko jednokontekstowe różni się od środowiska multitenantowego w kontekście 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 Logic w ramach dzierżaw Microsoft Entra współdzielą takie same przetwarzanie, magazynowanie, sieć itd. Dla zapewnienia niezawodności 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: Azure Logic Apps w trybie jednodzierżawowym 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 jednego dzierżawcy w celu zwiększenia wydajności i obniżenia kosztów przy dużej skali — 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 Logic i dzierżawcy współużytkują te same zasoby przetwarzania, przechowywania, sieci 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 Azure Logic Apps w środowisku pojedynczego dzierżawcy.
Standard (App Service Environment v3) Środowisko hosta: App Service Environment v3 (ASEv3) — tylko plany systemu Windows	Te same możliwości jak dzierżawa jednostanowiskowa plus następujące korzyści: — W pełni izoluj aplikacje logiki. — Tworzenie i uruchamianie większej liczby aplikacji automatyzacji niż w wersji jednosesyjnej Azure Logic Apps. — 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, historie uruchomień przepływów pracy w tym środowisku ASE nie mogą uzyskać dostępu do wejść i wyjść akcji.	Jedna aplikacja logiki może mieć wiele stanowych i bezstanowych przepływów pracy. Przepływy robocze w jednej aplikacji logicznej i dzierżawczej współużytkują te same zasoby przetwarzania (obliczeniowe), przechowywania, sieciowe 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 jednodzierżawowej usłudze Azure Logic Apps.

Standardowa aplikacja logiki i przepływ pracy

Aplikacja logiki Standard i przepływ pracy są obsługiwane przez nowe środowisko uruchomieniowe usługi Azure Logic Apps w konfiguracji 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. Projekt ten zapewnia przenośność, elastyczność i lepszą wydajność przepływów pracy aplikacji logicznych oraz dziedziczone możliwości i korzyści z platformy Azure Functions i ekosystemu usługi Azure App Service. Można na przykład tworzyć, wdrażać i uruchamiać aplikacje logiki oparte na jednym dzierżawcy oraz ich przepływy pracy w środowisku Azure App Service w wersji 3 (V3) tylko dla planów Windows.

Aplikacja logiki w wersji Standard wprowadza strukturę zasobów, która może hostować wiele workflowów, podobnie jak Azure Functions może hostować wiele funkcji. Dzięki mapowaniu od jednego do wielu przepływy pracy w tej samej aplikacji logicznej i tenant współużytkują zasoby obliczeniowe i przetwarzania, co zapewnia lepszą wydajność dzięki ich bliskości. 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. Więcej informacji na temat środowiska uruchomieniowego usługi Azure Logic Apps na potrzeby pojedynczego klienta oraz rozszerzalności usługi Azure Functions znajdziesz w poniższej dokumentacji:

• 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 logicznej i przepływu pracy można wdrożyć i uruchomić przepływ pracy w innych środowiskach, takich jak środowisko Azure App Service w wersji 3 (dotyczy tylko planów 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ć jednodzierżawowe aplikacje logiczne obsługiwane przez 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ą znaczące ulepszenia i istotne korzyści w porównaniu z modelem wielodostępnym, który wymaga pracy na istniejącym uruchomionym zasobie na platformie Azure. Model wielodostępny do automatyzacji wdrażania zasobów aplikacji logiki Consumption jest oparty na szablonach Azure Resource Manager (szablonach 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 dla jednolitych dzierżaw Azure Logic Apps oraz swoje przepływy pracy razem jako element swojego 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 Azure Resource Manager (ARM) do tworzenia tych zasobów osobno, wraz z innymi procesami i potokami stosowanymi do tych celów.

Aby wdrożyć aplikację, skopiuj artefakty do środowiska hosta, a potem uruchom aplikacje, aby uruchomić przepływy pracy. Możesz też zintegrować artefakty z potokami wdrażania, korzystając z 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 logicznej można tworzyć i uruchamiać wiele przepływów pracy w tym samym pojedynczym zasobie aplikacji logicznej i dzierżawie. Dzięki temu mapowaniu od jednego do wielu, te przepływy pracy współdzielą zasoby, takie jak moc obliczeniowa, przetwarzanie, przechowywanie danych i sieć, co przekłada się na 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 zarządzanych połączeń nazywane są połączeniami interfejsu API, które są tworzone i uruchamiane oddzielnie jako zasoby Azure, które również trzeba wdrożyć za pomocą szablonów 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 pojedynczym dzierżawcą. 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.

Lokalizacja danych

Standardowe zasoby aplikacji logiki są hostowane w jednotenantowej usłudze Azure Logic Apps, 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.

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

Azure Logic Apps dla pojedynczego dzierżawcy 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 wychodzący 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 uruchamiania, przechowywania, przepływności, limitu czasu na żądanie HTTP i jego odpowiedź, rozmiarów wiadomości 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 jednolokatorskie

Opcja	Zasoby i narzędzia	Więcej informacji
Azure Portal	Standardowa aplikacja logiki	Utwórz przykładowy standardowy przepływ pracy aplikacji logiki w pojedynczym środowisku Azure Logic Apps - portal Azure
Visual Studio Code	Rozszerzenie usługi Azure Logic Apps (Standardowa)	Utwórz przykładowy standardowy przepływ logiki aplikacji w Azure Logic Apps w środowisku jedno-dzierżawnym — Visual Studio Code
Azure CLI	Rozszerzenie CLI platformy Azure Logic Apps	az logicapp
Azure Resource Manager	- Lokalny - DevOps	Pojedynczo-dzierżawcza usługa Azure Logic Apps
Logic Apps z obsługą Azure Arc	Przykład Logic Apps z obsługą 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 REST API usługi Azure App Service* Uwaga: interfejs API REST standardowej aplikacji Logic Apps jest dołączony do interfejsu API REST usługi Azure App Service.	Rozpocznij z dokumentacją interfejsu API REST platformy Azure

Środowisko wielodostępne

Opcja	Zasoby i narzędzia	Więcej informacji
Azure Portal	Aplikacja logiki zużycia	Szybki start: Tworzenie przykładowego przepływu pracy aplikacji logiki na planie konsumpcyjnym w wielodostępnym środowisku Azure Logic Apps – Portal Azure
Visual Studio Code	Rozszerzenie Azure Logic Apps (Zużycie)	Szybki start: tworzenie przykładowego przepływu pracy aplikacji logiki użycia w usłudze Azure Logic Apps wielodostępnej — Visual Studio Code
Interfejs wiersza polecenia platformy Azure	Rozszerzenie interfejsu wiersza polecenia 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	Utwórz szablon ARM aplikacji logicznej	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	Rozpocznij korzystanie z dokumentacji interfejsu API REST platformy Azure

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

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

Stanowe i bezstanowe przepływy pracy

W logicznej aplikacji Standard 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 dane umożliwiają przeglądanie szczegółów przebiegu przepływu pracy i historii 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ą nadal działać 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.

• Bezstanowy

  Utwórz bezstanowy przepływ pracy, gdy nie potrzebujesz przechowywać, przeglądać ani odwoływać się do danych z poprzednich zdarzeń w magazynie zewnętrznym po zakończeniu każdego przebiegu, aby móc je później analizować. 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ć jedynie wyzwalaczy typu push, gdzie nie określasz harmonogramu dla uruchomienia swojego przepływu pracy. Te wyzwalacze oparte na webhookach oczekują na wystąpienie zdarzenia lub dostępność danych. Na przykład wyzwalacz cykliczny jest dostępny tylko w przypadku stanowych przepływów pracy. Aby rozpocząć przepływ pracy, wybierz wyzwalacz typu push, taki jak wyzwalacz żądania, wyzwalacz Event Hubs lub wyzwalacz 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 sprawdzać 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, stanowego lub bezstanowego, aby zaimplementować go w momencie 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 w zachowaniu zagnieżdżonym 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 mogą mieć zagnieżdżone przepływy pracy po tym, jak nadrzędny przepływ pracy wywoła podrzę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że nadrzędny proces stale sprawdza historię uruchomienia procesu podrzędnego, aż do momentu, gdy proces podrzędny zakończy działanie. Domyślnie przepływy pracy stanowe są zgodne z tym wzorcem, co jest idealnym rozwiązaniem dla długotrwałych podrzędnych przepływów pracy, które mogą przekraczać limity czasu żądania.

• Wzorzec synchroniczny ("fire and forget" - odpal i zapomnij)

  Podrzędny przepływ pracy potwierdza wywołanie nadrzędnego przepływu pracy, natychmiast zwracając 202 ACCEPTED odpowiedź. Jednak rodzic nie czeka, aż dziecko 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. Pomocnicze stanowe przepływy pracy, które nie zawierają akcji Odpowiedź, zawsze działają według wzorca synchronicznego i oferują historię przebiegu do wglądu.

  Aby włączyć to zachowanie, ustaw atrybut operationOptions na DisableAsyncPattern w definicji JSON przepływu pracy. 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 podrzędny przepływ pracy bezstanowy, nadrzędny przepływ pracy czeka na odpowiedź zwracającą wyniki z przepływu pracy 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 odpowiedzi, natychmiast zwracają 202 ACCEPTED odpowiedź, ale proces nadrzędny czeka na zakończenie działania podrzędnego, zanim przejdzie do kolejnej akcji. Te zachowania dotyczą tylko bezstanowych podprocesów przepływów pracy.

W poniższej tabeli przedstawiono, jak zachowuje się podrzędny przepływ pracy w zależności od tego, czy elementy nadrzędny i podrzędny są stanowe, bezstanowe, czy też są mieszanymi typami przepływów pracy. Lista za tabelą

Nadrzędny przepływ pracy	Podrzędny przepływ pracy	Zachowanie dziecka
Stanowe	Stanowe	Asynchroniczna lub synchroniczna z ustawieniem "operationOptions": "DisableAsyncPattern"
Stanowe	Bezstanowa	Wyzwól i czekaj
Bezstanowa	Stanowe	Synchroniczny
Bezstanowa	Bezstanowa	Wyzwalanie i oczekiwanie

Inne możliwości modelu jednokrotnego dzierżawcy

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

• Twórz aplikacje logiczne i ich przepływy pracy, korzystając z ponad 1400 zarządzanych łączników dla oprogramowania jako usługi (SaaS) i platformy jako usługi (PaaS), a także łą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 określane jako łączniki dostawców usług. Aby zapoznać się z listą, sprawdź wbudowane łączniki w Zużyciu i Standardzie.

  • Możesz utworzyć własne niestandardowe wbudowane łączniki dla dowolnej potrzebnej usługi, korzystając z frameworku rozszerzalności jednolitej dzierżawy usługi Azure Logic Apps. 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 różnią się od niestandardowych łączników zarządzanych, które nie są obecnie obsługiwane. Aby uzyskać więcej informacji, zobacz Omówienie łączników niestandardowych i Tworzenie niestandardowych wbudowanych łączników dla standardowych aplikacji logiki w ramach jednego dzierżawcy usługi Azure Logic Apps.

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

    • XML: Przekształcanie XML, Walidacja XML, Tworzenie XML przy użyciu schematu i Analizowanie XML przy użyciu schematu

    • Liquid: przekształcenie JSON w JSON, przekształcenie JSON na tekst, przekształcenie XML w JSON i przekształcenie 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 przesłać w portalu Azure z menu zasobów aplikacji logiki, w sekcji Artefakty, która zawiera 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 logicznej.

  • Standardowe przepływy pracy aplikacji logiki mogą być wyzwalane z dowolnego miejsca, ponieważ usługa Azure Logic Apps generuje ciągi połączeń 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, 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 parametrów 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ą obecnie obsługiwane tylko w przypadku akcji, 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 oraz wdrażanie aplikacji logiki i ich przepływów pracy w Visual Studio Code do różnych środowisk hostingu, takich jak Azure i Azure Arc z włączoną obsługą Logic Apps.

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

• Uzyskaj dostęp do funkcji sieciowych, takich jak połączenie i prywatna integracja z sieciami wirtualnymi platformy Azure, podobnie jak w przypadku 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 wykorzystywanych przez poszczególne przepływy pracy w aplikacji logiki Standard. W tym zadaniu wykonaj te same kroki dla Consumption logic app ale na poziomie przepływu pracy, a nie na poziomie zasobu aplikacji logiki.

Wbudowane łączniki dla standardu

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

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 Konsumpcja nie ma tych samych wbudowanych wersji łącznika, dostępne są inne wbudowane łączniki, takie jak Azure API Management i usługi aplikacyjne Azure.

W jedno-dzierżawczej usłudze Azure Logic Apps 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 ciągu 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 listą wbudowanych łączników dla przepływów pracy aplikacji logiki w warstwie Standardowa.

Ważne

Upewnij się, że poprawnie skonfigurujesz i przetestujesz dowolny wyzwalacz oparty na dostawcy usług, aby potwierdzić prawidłowe działanie. Nieudany wyzwalacz oparty na dostawcy usług może spowodować niepotrzebne skalowanie, co może znacznie zwiększyć koszty fakturowania. Na przykład typowym błędem jest ustawienie wyzwalacza bez udzielenia aplikacji logiki uprawnień lub dostępu do miejsca docelowego, takiego jak kolejka w Azure Service Bus, kontener w 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 przepływów pracy w warstwie Standard niektóre wbudowane wyzwalacze i akcje są obecnie niedostępne, takie jak operacje usługi Azure App Service. Aby uruchomić stanowy lub bezstanowy przepływ pracy, użyj wbudowanego wyzwalacza, takiego jak wyzwalacz Request, Event Hubs lub Service Bus. Wyzwalacz cykliczny jest dostępny dla stanowych przepływów pracy, ale nie dla bezstanowych przepływów pracy. W projektancie wbudowane wyzwalacze i akcje są wyświetlane z etykietą W aplikacji, podczas gdy wyzwalacze i akcje zarządzane przez łącznik są wyświetlane z etykietą Udostępnione.

  Bezstanowe przepływy pracy mogą używać wyłącznie wyzwalaczy typu push, gdzie nie określa się harmonogramu uruchamiania przepływu pracy. Te wyzwalacze oparte na webhookach oczekują na wystąpienie zdarzenia lub aż dane staną się dostępne. Na przykład wyzwalacz cykliczny jest dostępny tylko dla stanowych przepływów pracy. Aby uruchomić przepływ pracy, wybierz wyzwalacz typu push, taki jak żądanie, wyzwalacz Event Hubs lub wyzwalacz 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 łącznikazarzą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 dla akcji funkcji w widoku kodu lub plik workflow.json przy użyciu programu Visual Studio Code, akcja odnosi się do funkcji za pomocą odniesienia connectionName. Ta wersja przedstawia informacje o funkcji jako połączenie, które można znaleźć w pliku connections.json projektu aplikacji logiki, dostępnym po stworzeniu połączenia w programie Visual Studio Code.

      Uwaga

      W modelu z jednym najemcą działanie funkcji obsługuje tylko uwierzytelnianie za pomocą 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żeli odnowisz ten klucz, na przykład korzystając ze środowiska usługi Azure Functions w portalu, wówczas akcja funkcji przestaje działać 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 – wybierz przepływ pracy aplikacji logiki to teraz Operacje przepływu pracy – wywołaj przepływ pracy w tej aplikacji przepływu pracy.

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

• Authentication

  • Niektóre wyzwalacze oparte na żądaniach, które obsługują połączenia przychodzące, takie jak wyzwalacz żądania, obecnie nie obsługują Open Authorization (Microsoft Entra ID OAuth), podczas gdy inne, takie jak wyzwalacz webhook HTTP, mają 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 wyzwalania i uruchamiania: Dla Standardowego przepływu pracy aplikacji logicznej, historia wyzwalania i uruchamiania w portalu Azure jest wyświetlana na poziomie przepływu pracy, a nie na poziomie zasobu aplikacji logicznej. Aby uzyskać więcej informacji, zobacz Tworzenie przepływów pracy opartych na jednej dzierżawie za pomocą portalu Azure.

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

Ścisłe zasady ruchu sieciowego i zapory sieciowej

Jeśli w Twoim środowisku obowiązują ścisłe wymagania sieciowe lub zapory ograniczające ruch, musisz zezwolić na dostęp do połączeń wyzwalaczy lub akcji w ramach przepływów pracy. Opcjonalnie możesz zezwolić na ruch z tagów usługowych i używać tego samego poziomu ograniczeń lub zasad co usługa 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:

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

Następne kroki

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

Chcemy również poznać Twoje doświadczenia z Azure Logic Apps w modelu pojedynczego dzierżawcy!

• 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.