A standard egybérlős logikai alkalmazások és a több-bérlős logikai alkalmazások használata közötti különbségek

Az Azure Logic Apps egy felhőalapú platform, amellyel automatizált logikaialkalmazás-munkafolyamatokat hozhat létre és futtathat, amelyek integrálják az alkalmazásokat , adatokat, szolgáltatásokat és rendszereket. Ezzel a platformmal gyorsan fejleszthet nagy skálázható integrációs megoldásokat vállalati és üzleti (B2B) forgatókönyvekhez. Logikai alkalmazás-erőforrás létrehozásakor a Használat vagy a Standard üzemeltetési lehetőséget választja. Egy használatalapú logikai alkalmazás csak egy munkafolyamattal rendelkezhet, amely több-bérlős Azure Logic Appsben fut. A standard logikai alkalmazások egy vagy több munkafolyamattal is rendelkezhetnek, amelyek egybérlős Azure Logic Appsben vagy app service environment v3-ban (ASE v3) futnak.

Mielőtt kiválasztja, hogy melyik logikaialkalmazás-erőforrást szeretné létrehozni, tekintse át az alábbi útmutatót, amelyből megtudhatja, hogyan viszonyulnak egymáshoz a logikaialkalmazás-munkafolyamat-típusok. Ezután jobb döntést hozhat arról, hogy melyik logikai alkalmazás munkafolyamata és környezete felel meg legjobban a forgatókönyvnek, a megoldás követelményeinek, valamint a munkafolyamatok üzembe helyezésének és futtatásának célhelyének.

Ha még nem ismerkedik az Azure Logic Apps szolgáltatással, tekintse át, mi az az Azure Logic Apps? és mi az a logikaialkalmazás-munkafolyamat?

Logikai alkalmazás munkafolyamat-típusai és környezetei

Az alábbi táblázat összefoglalja a használati logikai alkalmazás munkafolyamata és a Standard logikai alkalmazás munkafolyamata közötti különbségeket. Azt is megtudhatja, hogy az egybérlős környezet miben különbözik a munkafolyamatok üzembe helyezéséhez, üzemeltetéséhez és futtatásához használt több-bérlős környezettől.

Üzemeltetési lehetőség	Juttatások	Erőforrás-megosztás és -használat	Díjszabási és számlázási modell	Korlátok kezelése
Fogyasztás Gazdagépkörnyezet: Több-bérlős Azure Logic Apps	– A legegyszerűbb az első lépésekhez - A használatért fizetnie kell - Teljes körűen felügyelt	Egyetlen logikai alkalmazás erőforrásának csak egy munkafolyamata lehet. A Microsoft Entra-bérlők összes logikai alkalmazása ugyanazt a feldolgozást (számítást), tárolást, hálózatot stb. Redundancia céljából a rendszer replikálja az adatokat a párosított régióban. A magas rendelkezésre állás érdekében a georedundáns tárolás (GRS) engedélyezve van.	Felhasználás (végrehajtásonkénti fizetés)	Az Azure Logic Apps kezeli ezeknek a korlátoknak az alapértelmezett értékeit, de módosíthatja ezeket az értékeket, ha ez a beállítás egy adott korlátra vonatkozik.
Standard (munkafolyamat-szolgáltatáscsomag) Gazdagépkörnyezet: Egybérlős Azure Logic Apps Megjegyzés: Ha a forgatókönyv tárolókat igényel, hozzon létre egybérlős alapú logikai alkalmazásokat az Azure Arc-kompatibilis Logic Apps használatával. További információ: Mi az Azure Arc-kompatibilis Logic Apps?	– Az egybérlős futtatókörnyezetben üzemeltetett beépített összekötők nagyobb átviteli sebesség és alacsonyabb költségek skálázása érdekében – Több vezérlési és finomhangolási képesség a futtatókörnyezet és a teljesítmény beállításai körül - Virtuális hálózatok és privát végpontok integrált támogatása. – Saját beépített összekötők létrehozása.	Egyetlen logikaialkalmazás-erőforrás több állapotalapú és állapot nélküli munkafolyamatot is tartalmazhat. Egyetlen logikai alkalmazás és bérlő munkafolyamatai ugyanazt a feldolgozást (számítást), tárolást, hálózatot stb. használják. Az adatok ugyanabban a régióban maradnak, ahol üzembe helyezi a logikai alkalmazást.	Standard, egy kiválasztott tarifacsomaggal rendelkező üzemeltetési terv alapján. Ha külső tárolót használó állapotalapú munkafolyamatokat futtat, az Azure Logic Apps futtatókörnyezete olyan tárolási tranzakciókat hajt végre, amelyek az Azure Storage díjszabását követik.	A forgatókönyv igényeinek megfelelően számos korlát alapértelmezett értékeit módosíthatja. Fontos: Egyes korlátok szigorú felső korlátokkal rendelkeznek. A Visual Studio Code-ban a logikai alkalmazás projektkonfigurációs fájljaiban az alapértelmezett korlátértékek módosításai nem jelennek meg a tervezői felületen. További információ: Az egybérlős Azure Logic Apps logikai alkalmazásainak alkalmazás- és környezeti beállításainak szerkesztése.
Standard (App Service Environment v3) Gazdagépkörnyezet: App Service Environment v3 (ASEv3) – Csak Windows-csomagok	Ugyanazokat a képességeket, mint az egybérlős , valamint a következő előnyöket: – A logikai alkalmazások teljes elkülönítése. – Több logikai alkalmazást hozhat létre és futtathat, mint az egybérlős Azure Logic Appsben. – Csak az ASE App Service-csomagért kell fizetnie, függetlenül a létrehozott és futtatott logikai alkalmazások számától. – Engedélyezheti az automatikus skálázást vagy a manuális méretezést több virtuálisgép-példány vagy egy másik App Service-csomag használatával. – Örökölje a hálózatbeállítást a kiválasztott ASEv3-ból. Ha például belső ASE-n telepít, a munkafolyamatok hozzáférhetnek az ASE-hez társított virtuális hálózat erőforrásaihoz, és belső hozzáférési pontokkal rendelkeznek. Megjegyzés: Ha egy belső ASE-n kívülről fér hozzá, futtassa a munkafolyamatok előzményeit, amelyekben az ASE nem fér hozzá a műveletbemenetekhez és kimenetekhez.	Egyetlen logikai alkalmazás több állapotalapú és állapot nélküli munkafolyamatot is tartalmazhat. Egyetlen logikai alkalmazás és bérlő munkafolyamatai ugyanazt a feldolgozást (számítást), tárolást, hálózatot stb. használják. Az adatok ugyanabban a régióban maradnak, ahol üzembe helyezi a logikai alkalmazásokat.	App Service-csomag	A forgatókönyv igényeinek megfelelően számos korlát alapértelmezett értékeit módosíthatja. Fontos: Egyes korlátok szigorú felső korlátokkal rendelkeznek. A Visual Studio Code-ban a logikai alkalmazás projektkonfigurációs fájljaiban az alapértelmezett korlátértékek módosításai nem jelennek meg a tervezői felületen. További információ: Az egybérlős Azure Logic Apps logikai alkalmazásainak alkalmazás- és környezeti beállításainak szerkesztése.

Standard logikai alkalmazás és munkafolyamat

A Standard logikai alkalmazást és munkafolyamatot az újratervezett egybérlős Azure Logic Apps-futtatókörnyezet működteti. Ez a futtatókörnyezet az Azure Functions bővíthetőségi modelljét használja, és az Azure Functions-futtatókörnyezet bővítményeként üzemel. Ez a kialakítás hordozhatóságot, rugalmasságot és nagyobb teljesítményt biztosít a logikai alkalmazás munkafolyamataihoz, valamint az Azure Functions platformtól és a Azure-alkalmazás szolgáltatás ökoszisztémájától örökölt egyéb képességeket és előnyöket. Létrehozhat, telepíthet és futtathat például egybérlős alapú logikai alkalmazásokat és azok munkafolyamatait Azure-alkalmazás Service Environment v3-ban (csak Windows-csomagok esetén).

A Standard logikai alkalmazás egy olyan erőforrásstruktúrát vezet be, amely több munkafolyamatot is üzemeltethet, hasonlóan ahhoz, ahogyan egy Azure-függvényalkalmazás több függvényt is üzemeltethet. Az 1-a-többhöz leképezéssel az ugyanabban a logikai alkalmazásban és a bérlőben lévő munkafolyamatok számítási és feldolgozási erőforrásokat osztanak meg, így jobb teljesítményt nyújtanak a közelségük miatt. Ez a struktúra eltér a Használat logikai alkalmazás erőforrástól, ahol 1–1 leképezéssel rendelkezik a logikai alkalmazás erőforrása és a munkafolyamat között.

Ha többet szeretne megtudni a hordozhatóságról, a rugalmasságról és a teljesítmény javításáról, tekintse át a következő szakaszokat. Az egybérlős Azure Logic Apps-futtatókörnyezetről és az Azure Functions bővíthetőségéről az alábbi dokumentációban talál további információt:

• Bárhol futó Azure Logic Apps – Runtime Deep Dive
• Az Azure Functions bemutatása
• Az Azure Functions eseményindítói és kötései

Hordozhatóság és rugalmasság

Standard logikai alkalmazás és munkafolyamat létrehozásakor a munkafolyamatot más környezetekben is üzembe helyezheti és futtathatja, például Azure-alkalmazás Service Environment v3 -ban (csak Windows-csomagok esetén). Ha a Visual Studio Code-ot az Azure Logic Apps (Standard) bővítménysel használja, helyileg fejlesztheti, fejlesztheti és futtathatja a munkafolyamatot a fejlesztői környezetben anélkül, hogy üzembe kellene helyeznie az Azure-ban. Ha a forgatókönyv tárolókat igényel, létrehozhat egyetlen bérlői logikai alkalmazásokat az Azure Arc-kompatibilis Logic Apps használatával. További információ: Mi az Azure Arc-kompatibilis Logic Apps?

Ezek a képességek jelentős fejlesztéseket és jelentős előnyöket biztosítanak a több-bérlős modellhez képest, ami megköveteli, hogy az Azure-ban egy meglévő futó erőforráson dolgozzon. A használati logikai alkalmazások erőforrás-üzembe helyezésének automatizálására szolgáló több-bérlős modell az Azure Resource Manager-sablonokon (ARM-sablonokon) alapul, amelyek az alkalmazások és az infrastruktúra erőforrás-kiépítését egyesítik és kezelik.

A Standard logikai alkalmazás erőforrásával egyszerűbbé válik az üzembe helyezés, mivel elkülönítheti az alkalmazástelepítést az infrastruktúra üzembe helyezésétől. Az egybérlős Azure Logic Apps-futtatókörnyezetet és a munkafolyamatokat a logikai alkalmazás erőforrásának vagy projektjének részeként csomagolhatja össze. Általános lépéseket vagy feladatokat használhat, amelyek a logikai alkalmazás erőforrásait kész üzembe helyezésre kész összetevőkbe építik, szerelik össze és tömörítik. Az infrastruktúra üzembe helyezéséhez továbbra is használhat ARM-sablonokat az erőforrások külön-külön történő kiépítéséhez, valamint az ilyen célokra használt egyéb folyamatokkal és folyamatokkal együtt.

Az alkalmazás üzembe helyezéséhez másolja az összetevőket a gazdakörnyezetbe, majd indítsa el az alkalmazásokat a munkafolyamatok futtatásához. Vagy integrálhatja az összetevőket az üzembehelyezési folyamatokba a már ismert és használt eszközökkel és folyamatokkal. Így üzembe helyezheti a saját választott eszközeit, függetlenül a fejlesztéshez használt technológiai veremtől.

A standard buildelési és üzembe helyezési lehetőségek használatával az alkalmazásfejlesztésre összpontosíthat az infrastruktúra üzembe helyezésétől elkülönítve. Ennek eredményeképpen egy általánosabb projektmodellt kap, amelyben számos hasonló vagy ugyanazokat az üzembehelyezési beállításokat alkalmazhatja, amelyeket egy általános alkalmazáshoz használ. A konzisztensebb felhasználói élmény akkor is előnyös, ha üzembehelyezési folyamatokat hoz létre az alkalmazásokhoz, és amikor futtatja a szükséges teszteket és érvényesítéseket az éles környezetben való közzététel előtt.

Teljesítmény

Standard logikai alkalmazásokkal több munkafolyamatot is létrehozhat és futtathat ugyanabban az egyetlen logikaialkalmazás-erőforrásban és -bérlőben. Ezzel az egy-a-többhöz leképezéssel ezek a munkafolyamatok erőforrásokat osztanak meg, például számítást, feldolgozást, tárolást és hálózatot, így jobb teljesítményt nyújtanak a közelségük miatt.

A standard logikaialkalmazás-erőforrás és az egybérlős Azure Logic Apps-futtatókörnyezet további jelentős előrelépést jelent azáltal, hogy a népszerűbb felügyelt összekötőket beépített összekötőműveletként teszi elérhetővé. Használhat például beépített összekötőműveleteket az Azure Service Bushoz, az Azure Event Hubshoz, az SQL Serverhez és másokhoz. Eközben a felügyelt összekötő verziói továbbra is elérhetők, és továbbra is működnek.

Az új beépített összekötőműveletek használatakor beépített kapcsolatoknak vagy szolgáltatói kapcsolatoknak nevezett kapcsolatokat hoz létre. A felügyelt kapcsolatpartnereket API-kapcsolatoknak nevezzük, amelyek külön jönnek létre és futnak Azure-erőforrásokként, amelyeket aztán ARM-sablonok használatával kell üzembe helyezni. A beépített műveletek és kapcsolataik helyileg futnak ugyanabban a folyamatban, amely a munkafolyamatokat futtatja. Mindkettőt az egybérlős Azure Logic Apps-futtatókörnyezet üzemelteti. Ennek eredményeképpen a beépített műveletek és kapcsolataik jobb teljesítményt nyújtanak a munkafolyamatok közelsége miatt. Ez a kialakítás az üzembe helyezési folyamatokkal is jól működik, mert a szolgáltatói kapcsolatok ugyanabba a buildösszetevőbe vannak csomagolva.

Adattárolási hely

A standard logikaialkalmazás-erőforrások az egybérlős Azure Logic Appsben vannak üzemeltetve, amely nem tárol, dolgoz fel vagy replikál adatokat azon a régión kívül, ahol ezeket a logikai alkalmazás-erőforrásokat telepíti, vagyis a munkafolyamatokban lévő adatok ugyanabban a régióban maradnak, ahol a szülőerőforrásokat létrehozza és üzembe helyezi.

Közvetlen hozzáférés az azure-beli virtuális hálózatok erőforrásaihoz

Az egybérlős Azure Logic Appsben futó munkafolyamatok közvetlenül hozzáférhetnek a biztonságos erőforrásokhoz, például virtuális gépekhez, egyéb szolgáltatásokhoz és rendszerekhez, amelyek egy Azure-beli virtuális hálózaton léteznek.

Az egybérlős Azure Logic Apps az Azure Logic Apps szolgáltatás dedikált példánya, dedikált erőforrásokat használ, és külön fut a több-bérlős Azure Logic Appstől. A munkafolyamatok dedikált példányban való futtatása segít csökkenteni a többi Azure-bérlő alkalmazásteljesítményre gyakorolt hatását, más néven a "zajos szomszédok" effektust.

Az egybérlős Azure Logic Apps a következő előnyöket is biztosítja:

• Saját statikus IP-címei, amelyek különböznek a több-bérlős Azure Logic Apps logikai alkalmazásai által megosztott statikus IP-címektől. Egyetlen nyilvános, statikus és kiszámítható kimenő IP-címet is beállíthat a célrendszerekkel való kommunikációhoz. Így nem kell további tűzfalnyílásokat beállítania ezeken a célrendszereken.

• A futtatás időtartama, a tárterület megőrzése, az átviteli sebesség, a HTTP-kérések és a válaszidőkorlátok, az üzenetméretek és az egyéni összekötő-kérelmek korlátozása. További információkért tekintse át az Azure Logic Apps korlátait és konfigurációját.

Létrehozási, létrehozási és üzembe helyezési beállítások

Ha a kívánt környezet alapján szeretne logikaialkalmazás-erőforrást létrehozni, több lehetőség közül választhat, például:

Egybérlős környezet

Lehetőség	Erőforrások és eszközök	További információ
Azure Portal	Standard logikai alkalmazás	Példa standard logikai alkalmazás munkafolyamatának létrehozása egybérlős Azure Logic Appsben – Azure Portal
Visual Studio Code	Azure Logic Apps (Standard) bővítmény	Példa Standard logikai alkalmazás munkafolyamatának létrehozása egybérlős Azure Logic Appsben – Visual Studio Code
Azure CLI	Logic Apps Azure CLI-bővítmény	az logicapp
Azure Resource Manager	- Helyi - DevOps	Egybérlős Azure Logic Apps
Azure Arc-kompatibilis Logic Apps	Azure Arc-kompatibilis Logic Apps-minta	- Mi az Az Azure Arc-kompatibilis Logic Apps? - Egybérlős alapú logikaialkalmazás-munkafolyamatok létrehozása és üzembe helyezése az Azure Arc-kompatibilis Logic Apps használatával
Azure REST API	Azure-alkalmazás Service REST API* Megjegyzés: A STANDARD logikai alkalmazás REST API része a Azure-alkalmazás Service REST API-nak.	Az Azure REST API-referencia használatának első lépései

Több-bérlős környezet

Lehetőség	Erőforrások és eszközök	További információ
Azure Portal	Használati logikai alkalmazás	Rövid útmutató: Példa fogyasztási logikai alkalmazás munkafolyamatának létrehozása több-bérlős Azure Logic Appsben – Azure Portal
Visual Studio Code	Azure Logic Apps (Consumption) bővítmény	Rövid útmutató: Példa fogyasztási logikai alkalmazás munkafolyamatának létrehozása több-bérlős Azure Logic Appsben – Visual Studio Code
Azure CLI	Logic Apps Azure CLI-bővítmény	- Rövid útmutató: Használati logikai alkalmazás munkafolyamatainak létrehozása és kezelése több-bérlős Azure Logic Appsben – Azure CLI - az logic
Azure Resource Manager	Logikai alkalmazás ARM-sablon létrehozása	Rövid útmutató: Használati logikai alkalmazás munkafolyamatainak létrehozása és üzembe helyezése több-bérlős Azure Logic Appsben – ARM-sablon
Azure PowerShell	Az.LogicApp modul	Ismerkedés az Azure PowerShell szolgáltatással
Azure REST API	Azure Logic Apps REST API	Az Azure REST API-referencia használatának első lépései

Bár a fejlesztési élmények eltérnek attól függően, hogy használatalapú vagy standard logikai alkalmazás-erőforrásokat hoz létre, az Azure-előfizetésében megtalálja és elérheti az összes üzembe helyezett logikai alkalmazást.

Az Azure Portalon például a Logic Apps lap a Használat és a Standard logikai alkalmazás erőforrásait is megjeleníti. A Visual Studio Code-ban az üzembe helyezett logikai alkalmazások az Azure-előfizetés alatt jelennek meg, a Használat logikai alkalmazások azonban az Azure-ablakban, az Azure Logic Apps (Consumption) bővítmény alatt, míg a Standard logikai alkalmazások az Erőforrások szakaszban jelennek meg.

Állapotalapú és állapot nélküli munkafolyamatok

Egy Standard logikai alkalmazásban a következő munkafolyamat-típusokat hozhatja létre:

• Állapotalapú

  Állapotalapú munkafolyamatot hozhat létre, ha a korábbi események adatainak megőrzésére, áttekintésére vagy hivatkozására van szüksége. Ezek a munkafolyamatok az összes művelet bemenetét, kimenetét és állapotát külső tárolóba mentik. Ezek az információk lehetővé teszik a munkafolyamat futtatási részleteinek és előzményeinek áttekintését az egyes futtatások befejezése után. Az állapotalapú munkafolyamatok nagy rugalmasságot biztosítanak, ha leállás történik. A szolgáltatások és rendszerek visszaállítása után rekonstruálhatja a megszakított futtatásokat a mentett állapotból, és újrafuttathatja a munkafolyamatokat a befejezésig. Az állapotalapú munkafolyamatok tovább futhatnak, mint az állapot nélküli munkafolyamatok.

  Alapértelmezés szerint az állapotalapú munkafolyamatok a több-bérlős és az egybérlős Azure Logic Appsben is aszinkron módon futnak. Minden HTTP-alapú művelet a szabványos aszinkron műveleti mintát követi. Miután egy HTTP-művelet meghív vagy kérést küld egy végpontnak, szolgáltatásnak, rendszernek vagy API-nak, a kérés fogadója azonnal "202 ACCEPTED" választ ad vissza. Ez a kód megerősíti, hogy a fogadó elfogadta a kérést, de még nem fejezte be a feldolgozást. A válasz tartalmazhat egy location fejlécet, amely megadja az URI-t és egy frissítési azonosítót, amellyel a hívó lekérdezheti vagy ellenőrizheti az aszinkron kérés állapotát, amíg a fogadó le nem állítja a feldolgozást, és visszaad egy "200 OK" sikeres választ vagy más, nem 202-től eltérő választ. A hívónak azonban nem kell megvárnia a kérés feldolgozásának befejezését, és továbbra is futtathatja a következő műveletet. További információ: Aszinkron mikroszolgáltatás-integráció kényszeríti a mikroszolgáltatások autonómiáját.

• Hontalan

  Állapot nélküli munkafolyamatot hozhat létre, ha nem kell megőriznie, áttekintenie vagy hivatkoznia az előző események adatait a külső tárolóban, miután az egyes futtatások befejeződnek a későbbi felülvizsgálathoz. Ezek a munkafolyamatok az egyes műveletek összes bemenetét és kimenetét és állapotát csak a memóriába mentik, külső tárolóba nem. Ennek eredményeképpen az állapot nélküli munkafolyamatok rövidebb futtatásokkal rendelkeznek, amelyek általában 5 perc vagy annál rövidebb idő alatt fejeződnek be, gyorsabb teljesítménnyel, gyorsabb válaszidővel, nagyobb átviteli sebességgel és alacsonyabb üzemeltetési költségekkel, mivel a külső tároló nem menti a munkafolyamat futtatási adatait és előzményeit. Ha azonban leállások történnek, a megszakított futtatások nem lesznek automatikusan visszaállítva, ezért a hívónak manuálisan újra kell küldenie a megszakított futtatásokat.

  Az állapot nélküli munkafolyamatok a legjobb teljesítményt nyújtják olyan adatok vagy tartalmak kezelésekor, amelyek teljes mérete nem haladja meg a 64 KB-ot, például egy fájl. A nagyobb tartalomméretek, például több nagy melléklet jelentősen lelassíthatják a munkafolyamat teljesítményét, vagy akár a munkafolyamat memóriakivételek miatti összeomlását is okozhatják. Ha a munkafolyamatnak nagyobb tartalomméreteket kell kezelnie, használjon inkább állapotalapú munkafolyamatot.

  Feljegyzés

  Állapot nélküli munkafolyamatokban csak olyan leküldéses eseményindítókat használhat, ahol nem ad meg ütemezést a munkafolyamat futtatásához. Ezek a webhook-alapú eseményindítók megvárják, amíg egy esemény bekövetkezik, vagy az adatok elérhetővé válnak. Az Ismétlődés eseményindító például csak állapotalapú munkafolyamatokhoz érhető el. A munkafolyamat elindításához válasszon ki egy leküldéses eseményindítót, például a Kérés, az Event Hubs vagy a Service Bus eseményindítót. A korlátozott, nem elérhető vagy nem támogatott eseményindítókról, műveletekről és összekötőkről további információt a Módosított, korlátozott, nem elérhető vagy nem támogatott képességek című témakörben talál.

  Az állapot nélküli munkafolyamatok csak szinkron módon futnak, így nem használják az állapotalapú munkafolyamatok által használt szabványos aszinkron műveleti mintát . Ehelyett minden OLYAN HTTP-alapú művelet, amely "202 ELFOGADVA" választ ad vissza, a munkafolyamat végrehajtásának következő lépésére folytatódik. Ha a válasz fejlécet location tartalmaz, egy állapot nélküli munkafolyamat nem kérdezi le a megadott URI-t az állapot ellenőrzéséhez. A szabványos aszinkron műveleti minta követéséhez használjon inkább állapotalapú munkafolyamatot.

  A könnyebb hibakeresés érdekében engedélyezheti az állapot nélküli munkafolyamatok futtatási előzményeit, amelyek hatással vannak a teljesítményre, majd ha végzett, letilthatja a futtatási előzményeket. További információ: Egybérlős alapú munkafolyamatok létrehozása a Visual Studio Code-ban vagy egybérlős alapú munkafolyamatok létrehozása az Azure Portalon.

Fontos

Az állapotalapú vagy állapot nélküli munkafolyamat-típust kell választania a létrehozáskor történő implementáláshoz. A munkafolyamat-típus létrehozás utáni módosítása futásidejű hibákat eredményez.

Az állapotalapú és az állapot nélküli munkafolyamatok közötti különbségek összegzése

Állapotalapú	Állapot nélküli alkalmazások és szolgáltatások
Az áruházak futtatási előzményei, bemenetei és kimenetei	Alapértelmezés szerint nem tárolja a futtatási előzményeket, bemeneteket és kimeneteket
A felügyelt összekötő-eseményindítók elérhetők és engedélyezettek	A felügyelt összekötő-eseményindítók nem érhetők el vagy nem engedélyezettek
Támogatja az adattömb-készítést	Az adattömb-készítés nem támogatott
Támogatja az aszinkron műveleteket	Az aszinkron műveletek nem támogatottak
Az alapértelmezett maximális futtatási időtartam szerkesztése a gazdagép konfigurációjában	5 percnél rövidebb maximális időtartamú munkafolyamatok esetén a legjobb
Nagy üzenetek kezelése	Kis méretű (64 KB alatti) üzenetméretek kezelésére ideális

Beágyazott viselkedésbeli különbségek az állapotalapú és az állapot nélküli munkafolyamatok között

A munkafolyamatokat meghívhatóvá teheti más munkafolyamatokból, amelyek ugyanabban a Standard logikai alkalmazásban léteznek a Kérelem eseményindító, a HTTP Webhook-eseményindító vagy az ApiConnectionWebhook típusú felügyelt összekötő-eseményindítók használatával, amelyek HTTPS-kéréseket fogadhatnak.

Az alábbi lista azokat a viselkedési mintákat ismerteti, amelyeket a beágyazott munkafolyamatok követhetnek, miután egy szülő munkafolyamat meghív egy gyermek munkafolyamatot:

• Aszinkron lekérdezési minta

  A szülő munkafolyamat nem várja meg, hogy a gyermek munkafolyamat válaszoljon a kezdeti hívásra. A szülő azonban folyamatosan ellenőrzi a gyermek futási előzményeit, amíg a gyermek nem fut. Alapértelmezés szerint az állapotalapú munkafolyamatok ezt a mintát követik, amely ideális olyan hosszú ideig futó gyermek munkafolyamatokhoz, amelyek túlléphetik a kérelmek időtúllépési korlátait.

• Szinkron minta ("tűz és felejtés")

  A gyermek munkafolyamat egy válasz azonnali visszaadásával 202 ACCEPTED nyugtázza a szülő munkafolyamat hívását. A szülő azonban nem várja meg, hogy a gyermek eredményeket ad vissza. Ehelyett a szülő folytatja a munkafolyamat következő műveletét, és megkapja az eredményeket, amikor a gyermek fut. A válaszműveleteket nem tartalmazó alárendelt állapotalapú munkafolyamatok mindig a szinkron mintát követik, és áttekintésre szolgáló futtatási előzményeket biztosítanak.

  A viselkedés engedélyezéséhez a munkafolyamat JSON-definíciójában állítsa a tulajdonságot a operationOptions következőre DisableAsyncPattern: . További információ: Eseményindító és művelettípusok – Műveleti beállítások.

• Eseményindító és várakozás

  Állapot nélküli munkafolyamatok futnak a memóriában. Így amikor egy szülő-munkafolyamat állapot nélküli gyermek munkafolyamatot hív meg, a szülő megvár egy választ, amely visszaadja a gyermek eredményeit. Ez a minta ugyanúgy működik, mint a beépített HTTP-eseményindító vagy -művelet használata gyermek munkafolyamat meghívására. A válaszműveletet nem tartalmazó gyermekállapot nélküli munkafolyamatok azonnal választ adnak vissza 202 ACCEPTED , de a szülő megvárja, amíg a gyermek befejeződik, mielőtt továbblép a következő műveletre. Ezek a viselkedések csak a gyermek állapot nélküli munkafolyamatokra vonatkoznak.

Az alábbi táblázat a gyermek munkafolyamat viselkedését határozza meg annak alapján, hogy a szülő és a gyermek állapotalapú, állapot nélküli vagy vegyes munkafolyamat-típusok-e. A táblázat utáni lista

Szülő munkafolyamat	Gyermek munkafolyamat	Gyermek viselkedése
Állapotalapú	Állapotalapú	Aszinkron vagy szinkron a beállítással "operationOptions": "DisableAsyncPattern"
Állapotalapú	Állapot nélküli alkalmazások és szolgáltatások	Eseményindító és várakozás
Állapot nélküli alkalmazások és szolgáltatások	Állapotalapú	Szinkron
Állapot nélküli alkalmazások és szolgáltatások	Állapot nélküli alkalmazások és szolgáltatások	Eseményindító és várakozás

Az egybérlős modell egyéb képességei

Az egybérlős modell és a Standard logikai alkalmazás számos jelenlegi és új képességet tartalmaz, például:

• Logikai alkalmazásokat és azok munkafolyamatait több száz felügyelt összekötőből hozhatja létre a Szolgáltatott szoftver (SaaS) és a Szolgáltatásként (PaaS) alkalmazásokhoz és szolgáltatásokhoz, valamint a helyszíni rendszerek összekötőihez.

  • Mostantól több felügyelt összekötő érhető el beépített összekötőként a Standard munkafolyamatokban. A beépített verziók natív módon futnak az egybérlős Azure Logic Apps-futtatókörnyezetben. Egyes beépített összekötők informálisan szolgáltatói összekötőkként is ismertek. A lista megtekintéséhez tekintse át a Beépített összekötőket a Használat és a Standard területen.

  • Az egybérlős Azure Logic Apps bővíthetőségi keretrendszerrel létrehozhatja saját egyéni beépített összekötőit minden olyan szolgáltatáshoz, amelyre szüksége van. Az olyan beépített összekötőkhöz hasonlóan, mint az Azure Service Bus és az SQL Server, az egyéni beépített összekötők nagyobb átviteli sebességet, alacsony késést és helyi kapcsolatot biztosítanak, mivel ugyanazon a folyamaton futnak, mint az egybérlős futtatókörnyezet. Az egyéni beépített összekötők azonban nem hasonlítanak az egyéni felügyelt összekötőkhöz, amelyek jelenleg nem támogatottak. További információkért tekintse át az egyéni összekötők áttekintését , és hozzon létre egyéni beépített összekötőket standard logikai alkalmazásokhoz az egybérlős Azure Logic Appsben.

  • Az alábbi műveleteket használhatja a Liquid Operationshez és az XML-műveletekhez integrációs fiók nélkül. Ezek a műveletek a következő műveleteket tartalmazzák:

    • XML: XML és XML-ellenőrzés átalakítása

    • Folyékony: JSON átalakítása JSON-ra, JSON átalakítása szöveggé, XML átalakítása JSON-ra, xml átalakítása szöveggé

    Feljegyzés

    Ha ezeket a műveleteket standard munkafolyamatokban szeretné használni, folyékony leképezésekkel, XML-leképezésekkel vagy XML-sémákkal kell rendelkeznie. Ezeket az összetevőket feltöltheti az Azure Portalra a logikai alkalmazás erőforrásmenüjében, az Összetevők területen, amely tartalmazza a Sémák és térképek szakaszokat. Ezeket az összetevőket hozzáadhatja a Visual Studio Code-projekt Artifacts mappájához a megfelelő Térképek és séma mappák használatával. Ezeket az összetevőket ezután több munkafolyamatban is használhatja ugyanazon a logikai alkalmazásban.

  • A szabványos logikaialkalmazás-munkafolyamatok bárhol futtathatók, mert az Azure Logic Apps közös hozzáférésű jogosultságkód (SAS) kapcsolati sztring hoz létre, amelyeket ezek a logikai alkalmazások a kérések felhőkapcsolati futtatókörnyezeti végpontra való küldéséhez használhatnak. Az Azure Logic Apps más alkalmazásbeállításokkal menti ezeket a kapcsolati sztring, így ezeket az értékeket egyszerűen tárolhatja az Azure Key Vaultban az Azure-ban való üzembe helyezéskor.

  • A szabványos logikai alkalmazás-munkafolyamatok támogatják a rendszer által hozzárendelt felügyelt identitás és több felhasználó által hozzárendelt felügyelt identitás egyidejű engedélyezését, bár egyszerre csak egy identitást választhat ki. Míg a beépített, szolgáltatóalapú összekötők támogatják a rendszer által hozzárendelt identitás használatát, a legtöbben jelenleg nem támogatják a felhasználó által hozzárendelt felügyelt identitások kiválasztását a hitelesítéshez, kivéve az SQL Servert és a HTTP-összekötőket.

    Feljegyzés

    Alapértelmezés szerint a rendszer által hozzárendelt identitás már engedélyezve van a kapcsolatok futásidőben történő hitelesítéséhez. Ez az identitás eltér a kapcsolat létrehozásakor használt hitelesítési hitelesítő adatoktól vagy kapcsolati sztring. Ha letiltja ezt az identitást, a kapcsolatok futásidőben nem működnek. A beállítás megtekintéséhez a logikai alkalmazás menüjében válassza az Identitás lehetőséget a Beállítások területen.

• A Visual Studio Code fejlesztői környezetében helyileg futtathatja, tesztelheti és hibakereséssel végezheti el a logikai alkalmazásokat és azok munkafolyamatait.

  A logikai alkalmazás futtatása és tesztelése előtt egyszerűbbé teheti a hibakeresést, ha töréspontokat ad hozzá és használ a workflow.json fájlban egy munkafolyamathoz. A töréspontok azonban jelenleg csak a műveletekhez támogatottak, az eseményindítókhoz nem. További információ: Egybérlős munkafolyamatok létrehozása a Visual Studio Code-ban.

• Közvetlenül közzéteheti vagy üzembe helyezheti a logikai alkalmazásokat és munkafolyamataikat a Visual Studio Code-ból különböző üzemeltetési környezetekben, például az Azure-ban és az Azure Arc-kompatibilis Logic Appsben.

• Ha az Azure-előfizetés és a logikai alkalmazás beállításai támogatják, engedélyezze a diagnosztikai naplózási és nyomkövetési képességeket a logikai alkalmazáshoz az Application Insights használatával.

• Az Azure Functions Premium-csomaggal létrehozott és üzembe helyezhető logikai alkalmazásokhoz hasonló hálózati képességek, például privát csatlakozás és integrálás az Azure-beli virtuális hálózatokkal. További információkért tekintse át a következő dokumentációt:

  • Az Azure Functions hálózatkezelési lehetőségei

  • Bárhol futó Azure Logic Apps – Hálózatkezelési lehetőségek az Azure Logic Appsszel

• A standard logikai alkalmazásokban az egyes munkafolyamatok által használt felügyelt kapcsolatok hozzáférési kulcsainak újragenerálása. Ebben a feladatban ugyanazokat a lépéseket kell követnie egy Használat logikai alkalmazás esetében, de a munkafolyamat szintjén, nem a logikai alkalmazás erőforrásszintjén.

Beépített összekötők a Standardhoz

A standard munkafolyamatok számos olyan beépített összekötőt használhatnak, mint a használati munkafolyamatok, de nem mindegyiket. A standard munkafolyamatok viszont számos olyan beépített összekötővel rendelkeznek, amelyek nem érhetők el a használatalapú munkafolyamatokban.

Egy standard munkafolyamat például felügyelt összekötőkkel és beépített összekötőkkel rendelkezik az Azure Blobhoz, az Azure Cosmos DB-hez, az Azure Event Hubshoz, az Azure Service Bushoz, a DB2-hez, az FTP-hez, az MQ-hoz, az SFTP-hez, az SQL Serverhez és másokhoz. Bár a Használat munkafolyamat nem rendelkezik ugyanezekkel a beépített összekötő-verziókkal, más beépített összekötők, például az Azure API Management és a Azure-alkalmazás Services is elérhetők.

Az egybérlős Azure Logic Appsben a speciális attribútumokkal rendelkező beépített összekötőket nem hivatalos néven szolgáltatóknak nevezzük. Egyes beépített összekötők csak egyetlen módszert támogatnak a mögöttes szolgáltatáshoz való csatlakozás hitelesítéséhez. Más beépített összekötők is választhatnak, például kapcsolati sztring, Microsoft Entra-azonosítót vagy felügyelt identitást használhatnak. Minden beépített összekötő ugyanabban a folyamatban fut, mint az újratervezett Azure Logic Apps-futtatókörnyezet. További információkért tekintse át a Standard logikai alkalmazás munkafolyamatainak beépített összekötőlistáját.

Fontos

Győződjön meg arról, hogy megfelelően állítja be és teszteli a szolgáltatói eseményindítót a sikeres művelet megerősítéséhez. A sikertelen szolgáltatói eseményindítók szükségtelen skálázást okozhatnak, ami jelentősen növelheti a számlázási költségeket. Gyakori hiba például egy eseményindító beállítása anélkül, hogy engedélyt ad a logikai alkalmazásnak, vagy hozzáférést a célhoz, például egy Service Bus-üzenetsorhoz, egy Azure Storage-blobtárolóhoz stb. Emellett győződjön meg arról, hogy mindig figyeli az ilyen eseményindítókat, hogy azonnal észlelhesse és kijavíthassa a problémákat.

Módosított, korlátozott, nem elérhető vagy nem támogatott képességek

A Standard logikai alkalmazás munkafolyamata esetében ezek a képességek megváltoztak, vagy jelenleg korlátozottak, nem érhetők el vagy nem támogatottak:

• Eseményindítók és műveletek: A beépített triggerek és műveletek natív módon futnak az Azure Logic Appsben, míg a felügyelt összekötők üzemeltetése és futtatása megosztott erőforrások használatával történik az Azure-ban. Standard munkafolyamatok esetén egyes beépített eseményindítók és műveletek jelenleg nem érhetők el, például a Sliding Window, a Azure-alkalmazás Service és az Azure API Management. Állapotalapú vagy állapot nélküli munkafolyamat elindításához használjon beépített eseményindítót, például a Kérés, az Event Hubs vagy a Service Bus-eseményindítót. Az Ismétlődés eseményindító állapotalapú munkafolyamatokhoz érhető el, állapot nélküli munkafolyamatokhoz azonban nem. A tervezőben a beépített eseményindítók és műveletek az alkalmazáson belüli címkével jelennek meg, míg a felügyelt összekötő eseményindítói és műveletei a megosztott címkével jelennek meg.

  Az állapot nélküli munkafolyamatok csak olyan leküldéses eseményindítókat használhatnak , ahol nem ad meg ütemezést a munkafolyamat futtatásához. Ezek a webhook-alapú eseményindítók megvárják, amíg egy esemény bekövetkezik, vagy az adatok elérhetővé válnak. Az Ismétlődés eseményindító például csak állapotalapú munkafolyamatokhoz érhető el. A munkafolyamat elindításához válasszon ki egy leküldéses eseményindítót, például a Kérés, az Event Hubs vagy a Service Bus eseményindítót. Bár a felügyelt összekötők állapot nélküli munkafolyamatokhoz is engedélyezhetők, az összekötőgyűjtemény nem jeleníti meg a hozzáadni kívánt felügyelt összekötő-lekérdezési eseményindítókat.

  Feljegyzés

  Ha helyileg szeretne futtatni a Visual Studio Code-ban, a webhook-alapú triggerek és műveletek további beállításokat igényelnek. További információ: Egybérlős munkafolyamatok létrehozása a Visual Studio Code-ban.

  • Az alábbi eseményindítók és műveletek módosultak, vagy jelenleg korlátozottak, nem támogatottak vagy nem érhetők el:

    • Az Azure Functions beépített művelete – Az Azure-függvény kiválasztása mostantól Azure Functions-műveletek – Azure-függvény meghívása. Ez a művelet jelenleg csak a HTTP Trigger sablonból létrehozott függvények esetében működik.

      Az Azure Portalon kiválaszthat egy HTTP-triggerfüggvényt, amelyet a felhasználói felületen keresztüli kapcsolat létrehozásával érhet el. Ha kódnézetben vizsgálja meg a függvényművelet JSON-definícióját vagy a Workflow.json-fájlt a Visual Studio Code használatával, a művelet hivatkozással connectionName hivatkozik a függvényre. Ez a verzió kapcsolatként absztrakciót biztosít a függvény adataihoz, amelyeket a logikaialkalmazás-projekt connections.json fájljában talál, amely a Visual Studio Code-ban való kapcsolat létrehozása után érhető el.

      Feljegyzés

      Az egybérlős modellben a függvényművelet csak a lekérdezési sztring hitelesítését támogatja. Az Azure Logic Apps a kapcsolat létrehozásakor lekéri a függvény alapértelmezett kulcsát, tárolja a kulcsot az alkalmazás beállításai között, és a függvény hívásakor a kulcsot használja a hitelesítéshez.

      A több-bérlős modellhez hasonlóan, ha megújítja ezt a kulcsot, például az Azure Functions portálon keresztül, a függvényművelet az érvénytelen kulcs miatt már nem működik. A probléma megoldásához újra létre kell hoznia a meghívni kívánt függvényhez való kapcsolatot, vagy frissítenie kell az alkalmazás beállításait az új kulccsal.

    • A beépített művelet (Inline Code) neve beágyazott kódműveletek, már nem igényel integrációs fiókot, és frissített korlátokkal rendelkezik.

    • Az Azure Logic Apps beépített művelete – A logikai alkalmazás munkafolyamatának kiválasztása mostantól munkafolyamat-műveletek – Munkafolyamat meghívása ebben a munkafolyamat-alkalmazásban.

    • A Gmail-összekötő jelenleg nem támogatott.

    • Az egyéni felügyelt összekötők jelenleg nem támogatottak. A Visual Studio Code használatakor azonban létrehozhat egyéni beépített műveleteket. További információ: Egybérlős alapú munkafolyamatok létrehozása a Visual Studio Code használatával.

    • A standard logikai alkalmazás munkafolyamatai csak egy eseményindítóval rendelkezhetnek, és nem támogatnak több eseményindítót.

• Hitelesítés: A standard munkafolyamatok esetében jelenleg a következő hitelesítési típusok nem érhetők el:

  • A Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth) a kérelemalapú eseményindítókra irányuló bejövő hívásokhoz, például a Kérelem eseményindítóhoz és a HTTP Webhook-eseményindítóhoz.

  • Felügyelt identitás hitelesítése: A rendszer által hozzárendelt és a felhasználó által hozzárendelt felügyelt identitás támogatása is elérhető. Alapértelmezés szerint a rendszer által hozzárendelt felügyelt identitás automatikusan engedélyezve van. A legtöbb beépített, szolgáltatóalapú összekötő azonban jelenleg nem támogatja a felhasználó által hozzárendelt felügyelt identitások kiválasztását a hitelesítéshez.

• XML-átalakítás: Jelenleg csak az XSLT 1.0 támogatott.

• Töréspontok hibakeresése a Visual Studio Code-ban: Bár a workflow.json fájlban lévő töréspontokat hozzáadhat és használhat egy munkafolyamathoz, a töréspontok csak az adott pillanatban végzett műveletekhez támogatottak, az eseményindítókhoz nem. További információ: Egybérlős munkafolyamatok létrehozása a Visual Studio Code-ban.

• Eseményindítók előzményei és futtatási előzményei: Standard logikai alkalmazások esetén a triggerelőzmények és a futtatási előzmények az Azure Portalon a munkafolyamat szintjén jelennek meg, nem pedig a logikai alkalmazás erőforrásszintjén. További információ: Egybérlős alapú munkafolyamatok létrehozása az Azure Portalon.

• Munkafolyamat-futtatási előzmények biztonsági mentése és visszaállítása: A standard logikai alkalmazások jelenleg nem támogatják a munkafolyamat-futtatási előzmények biztonsági mentését és visszaállítását.

• Terraform-sablonok: Ezeket a sablonokat nem használhatja standard logikai alkalmazás-erőforrással az infrastruktúra teljes üzembe helyezéséhez. További információ: Mi a Terraform az Azure-ban?

• Azure API Management: Jelenleg nem importálhat standard logikaialkalmazás-erőforrást az Azure API Managementbe. A Consumption logikai alkalmazás erőforrását azonban importálhatja.

Szigorú hálózati és tűzfalforgalmi engedélyek

Ha a környezet szigorú hálózati követelményekkel vagy tűzfalak használatával korlátozza a forgalmat, engedélyeznie kell a munkafolyamatok eseményindítóinak vagy műveleti kapcsolatainak elérését. Igény szerint engedélyezheti a szolgáltatáscímkékből érkező forgalmat, és ugyanazokat a korlátozásokat vagy szabályzatokat használhatja, mint Azure-alkalmazás Szolgáltatás. Emellett meg kell keresnie és használnia kell a teljes tartományneveket (FQDN-eket) a kapcsolatokhoz. További információkért tekintse át a következő dokumentáció megfelelő szakaszait:

• Tűzfalengedélyek egybérlős logikai alkalmazásokhoz – Azure Portal
• Tűzfalengedélyek egybérlős logikai alkalmazásokhoz – Visual Studio Code

Következő lépések

• Egybérlős alapú munkafolyamatok létrehozása az Azure Portalon
• Egy-bérlős munkafolyamatok létrehozása a Visual Studio Code-ban

Az egybérlős Azure Logic Apps szolgáltatással kapcsolatos tapasztalatairól is szeretnénk hallani!

• Hibák vagy problémák esetén hozza létre a problémákat a GitHubon.
• Kérdésekkel, kérésekkel, megjegyzésekkel és egyéb visszajelzésekkel kapcsolatban használja ezt a visszajelzési űrlapot.