A standard egybérlős logikai alkalmazások és a fogyasztási modellű több-bérlős logikai alkalmazások 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 Fogyasztás vagy a Standard üzemeltetési lehetőséget választja. Fogyasztásalapú logikai alkalmazás csak egy munkafolyamattal rendelkezhet, amely több bérlős Azure Logic Appsben fut. A standard logikai alkalmazás egy vagy több munkafolyamattal rendelkezhet, amelyek egy-bé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	Előnyök	Erőforrás-megosztás és -használat	Díjszabási és számlázási modell	Korlátok kezelése
Használat Gazdakörnyezet: Több-bérlős Azure Logic Apps	A legegyszerűbb elkezdeni - 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: Egy bérlős környezetben működő Azure Logic Apps Megjegyzés: Ha a forgatókönyv tárolókat igényel, hozzon létre egybérlős logikai alkalmazásokat az Azure Arc által támogatott Logic Apps-kel. Ha további információra van szüksége, tekintse meg a(z) Mi az Azure Arc-kompatibilis Logic Apps? című részt.	– További beépített összekötők az egybérlős futtatókörnyezetben a nagyobb átviteli sebesség és a költséghatékonyabb skálázás é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	Ugyanolyan képességek, mint az egybérlős rendszer, továbbá a következő előnyök: – 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.	Alkalmazásszolgáltatás-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 való leképezés esetén az ugyanabban a logikai alkalmazásban és bérlőben található munkafolyamatok megosztják számítási és feldolgozási erőforrásaikat, ami jobb teljesítményt eredményez a közelségük miatt. Ez a struktúra különbözik a Fogyasztás logikai alkalmazás erőforrástól, ahol a logikai alkalmazás erőforrás és a munkafolyamat között 1:1-es leképezés van.

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 – Futásidejű Mély Merülés
• Az Azure Functions bemutatása
• Az Azure Functions eseményindítói és kötései

Hordozhatóság és rugalmasság

Amikor létrehoz egy Standard logikai alkalmazást és munkafolyamatot, a munkafolyamatot más környezetekben is üzembe helyezheti és futtathatja, például az Azure alkalmazásszolgáltatási környezet v3-ban (csak Windows-tervek 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, az Azure Arc-kompatibilis Logic Apps használatával létrehozhat egybérlős logikai alkalmazásokat. 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. Az Használat 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-telepí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, hogy külön hozza létre ezeket az erőforrásokat más, az adott célokra használt 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 más Azure-bérlők 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őtartamára, a tárhelymegőrzésre, az átviteli sebességre, a HTTP-kérésekre és a válaszidőre, az üzenetméretekre és az egyéni összekötőkre vonatkozó kérelmekre vonatkozó korlátozások megnőttek. 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 (Az Azure parancssori felülete)	Logic Apps Azure CLI-bővítmény	az logicapp
Azure Resource Manager	- Helyi - DevOps	Egybérlős Azure Logic Apps
Azure Arc-engedélyezett Logic Apps	Egy Logic Apps minta, amelyet az Azure Arc lehetővé tesz	- Mi 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 App 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öbbfelhasználós környezet

Lehetőség	Erőforrások és eszközök	További információ
Azure Portal	Fogyasztási 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 (Az Azure parancssori felülete)	Logic Apps Azure CLI-bővítmény	- Rövid útmutató: Fogyasztási logikai alkalmazások 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 portálon például a Logic Apps lap a Használati és a Standard logikai alkalmazáserőforrásokat is megjeleníti. A Visual Studio Code-ban az üzembe helyezett logikai alkalmazások az Azure-előfizetés alatt jelennek meg, de a Consumption logikai alkalmazások az Azure ablakban az Azure Logic Apps (Consumption) bővítmény alatt jelennek meg, míg a Standard logikai alkalmazások az Erőforrások szakaszban találhatók.

Á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 fejeződött be a feldolgozás. 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

Állapotmegőrző	Állapot nélküli
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	A darabolá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 módosítása 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 be nem fejezi a futást. 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 gyermekmunkafolyamat azonnal visszaküld egy 202 ACCEPTED választ, ezzel nyugtázva 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 modellt követik, és áttekintésre szolgáló futtatási előzményeket biztosítanak.

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

• Indító, várakozás

  Állapot nélküli munkafolyamatok futnak a memóriában. Amikor tehát egy szülő munkafolyamat egy állapotmentes gyermekmunkafolyamatot hív meg, a szülő megvárja, hogy visszakapja 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
Állapotmegőrző	Állapotmegőrző	Aszinkron vagy szinkron a "operationOptions": "DisableAsyncPattern" beállítás szerint
Állapotmegőrző	Állapot nélküli	Indító, várakozás
Állapot nélküli	Állapotmegőrző	Szinkron
Állapot nélküli	Állapot nélküli	Indító, 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 munkafolyamataikat több mint 1400 felügyelt összekötőből hozhatja létre a szolgáltatott szoftver (SaaS) és a szolgáltatásként nyújtott platform (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ó összekötőkként is ismertek. A lista megtekintéséhez tekintse át a fogyasztási és standard beépített összekötőket.

  • Az egybérlős Azure Logic Apps bővíthetőségi keretrendszerrel létrehozhatja saját személyre szabott beépített kapcsolókat minden szükséges szolgáltatáshoz. 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 átalakítása, XML-ellenőrzés, XML-összeállítás sémával, XML-elemzés sémával

    • Liquid: 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 standard logikaialkalmazás-munkafolyamatok bárhonnan aktiválható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 használhatnak a kérések felhőkapcsolati futtatókörnyezeti végpontjára való küldéséhez. Az Azure Logic Apps más egyéb alkalmazásbeállításokkal menti ezeket a kapcsolati karakterláncokat, így ezeket az értékeket egyszerűen tárolhatja az Azure Key Vaultban az Azure-beli üzembe helyezés esetén.

  • 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 különbözik attól a hitelesítési hitelesítő adatoktól vagy kapcsolati összetevőtől, amelyeket a kapcsolat létrehozásához használ. 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óért lásd: 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 Fogyasztási munkafolyamat nem rendelkezik ugyanazokkal a beépített kapcsoló verziókkal, más beépített összekötők, például az Azure API Management és az Azure App 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 választási lehetőséget kínálhatnak, például kapcsolati sztring, Microsoft Entra-azonosító vagy felügyelt identitás használatával. 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 a következő képességek eltérőek, 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 Azure-alkalmazás szolgáltatásműveletek. Á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. Az összekötőgyűjteményben a beépített szűrő kiválasztásakor beépített eseményindítók és műveletek jelennek meg, míg a felügyelt összekötő eseményindítói és műveletei a Megosztott szűrő kiválasztásakor 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óért lásd: 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ó a függvény információit kapcsolati formában absztrahálja, amelyeket a logikai alkalmazás projekt connections.json fájljában talál meg, ami a kapcsolat létrehozása után érhető el a Visual Studio Code-ban.

      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, Azure Logic Apps - Válassza ki a logikai alkalmazás munkafolyamatát mostantól Munkafolyamat-műveletek - Munkafolyamat meghívása ebben az alkalmazásban.

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

• Hitelesítés

  • Egyes bejövő hívásokat kezelő kérésalapú eseményindítók( például a Kérés eseményindító) jelenleg nem támogatják a Microsoft Entra ID Open Authenticationt (Microsoft Entra ID OAuth), míg mások, például a HTTP Webhook eseményindító ezt a támogatást élvezik.

  • Egyes beépített, szolgáltatóalapú összekötők jelenleg nem támogatják a felhasználó által hozzárendelt felügyelt identitás kiválasztását a hitelesítéshez. Általában azonban a rendszer által hozzárendelt és a felhasználó által hozzárendelt felügyelt identitások is támogatottak. Alapértelmezés szerint a rendszer által hozzárendelt felügyelt identitás automatikusan engedélyezve van.

• 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óért lásd: 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: Egy standard logikai alkalmazás munkafolyamata 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 központú munkafolyamatok létrehozása az Azure Portalon.

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

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
• Egyfelhasználós alapú 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.