Perbedaan antara aplikasi logika standar penyewa tunggal versus aplikasi logika konsumen multipenyewa

2025-06-09

Azure Logic Apps adalah platform berbasis cloud untuk membuat dan menjalankan alur kerja aplikasi logika otomatis yang mengintegrasikan aplikasi, data, layanan, dan sistem Anda. Dengan platform ini, Anda dapat dengan cepat mengembangkan solusi integrasi yang sangat dapat diskalakan untuk skenario perusahaan dan bisnis-ke-bisnis (B2B) Anda. Saat membuat sumber daya aplikasi logika, Anda memilih opsi Konsumsi atau Hosting standar . aplikasi Consumption logic hanya dapat memiliki satu alur kerja yang berjalan di Azure Logic Apps multitenant. Aplikasi Logika Standar dapat memiliki satu atau beberapa alur kerja yang berjalan di Azure Logic Apps single-tenant atau Lingkungan Layanan Aplikasi v3 (ASE v3).

Sebelum Anda memilih sumber daya aplikasi logika mana yang akan dibuat, tinjau panduan berikut untuk mempelajari bagaimana jenis alur kerja aplikasi logika dibandingkan satu sama lain. Anda kemudian dapat membuat pilihan yang lebih baik tentang alur kerja dan lingkungan aplikasi logika mana yang paling sesuai dengan skenario, persyaratan solusi, dan tujuan tempat Anda ingin menyebarkan dan menjalankan alur kerja Anda.

Jika Anda baru menggunakan Azure Logic Apps, tinjau Apa itu Azure Logic Apps? dan Apa itu alur kerja aplikasi logika?.

Jenis dan lingkungan alur kerja aplikasi logika

Tabel berikut ini meringkas perbedaan antara alur kerja aplikasi logika Konsumsi dan alur kerja aplikasi logika Standar . Anda juga mempelajari bagaimana lingkungan penyewa tunggal berbeda dari lingkungan multipenyewa untuk menyebarkan, menghosting, dan menjalankan alur kerja Anda.

Opsi Hosting	Keuntungan	Pembagian dan penggunaan sumber daya	Model harga dan tagihan	Manajemen batas
Konsumsi Lingkungan host: Multipenyewa Azure Logic Apps	- Paling mudah untuk memulai - Membayar untuk apa yang Anda gunakan - Dikelola sepenuhnya	Satu sumber daya aplikasi logika hanya dapat memiliki satu alur kerja. Semua aplikasi logik di seluruh penyewa Microsoft Entra berbagi pemrosesan (komputasi), penyimpanan, jaringan, dan sebagainya yang sama. Untuk tujuan redundansi, data direplikasi di wilayah yang dipasangkan. Untuk ketersediaan yang tinggi, penyimpanan geo-redundan (GRS) diaktifkan.	Pemakaian (bayar per penggunaan)	Azure Logic Apps mengelola nilai default untuk batas ini, tetapi Anda dapat mengubah beberapa nilai ini jika opsi tersebut ada untuk batas tertentu.
Standar (Paket Layanan Alur Kerja) Lingkungan host: Azure Logic Apps tenan tunggal Catatan: Jika skenario Anda memerlukan kontainer, buat aplikasi logika berbasis penyewa tunggal menggunakan Logic Apps dengan dukungan Azure Arc. Untuk informasi selengkapnya, tinjau Apa itu Logic Apps dengan dukungan Azure Arc?	- Lebih banyak konektor bawaan dihosting pada runtime penyewa tunggal untuk meningkatkan throughput dan mengurangi biaya dalam skala besar. - Lebih banyak kontrol dan kemampuan penyempurnaan terkait runtime dan pengaturan performa - Dukungan terintegrasi untuk jaringan virtual dan titik akhir privat. - Buat konektor bawaan Anda sendiri.	Satu sumber daya aplikasi logika dapat memiliki beberapa alur kerja stateful dan stateless . Alur kerja dalam satu aplikasi logika dan satu tenant memiliki pemrosesan (komputasi), penyimpanan, jaringan, dan sebagainya yang sama. Data tetap berada di wilayah yang sama di mana Anda menyebarkan aplikasi logika.	Standar, berdasarkan paket hosting dengan tingkat harga yang dipilih. Jika Anda menjalankan alur kerja stateful , yang menggunakan penyimpanan eksternal, runtime Azure Logic Apps membuat transaksi penyimpanan yang mengikuti harga Azure Storage.	Anda dapat mengubah nilai default untuk banyak batasan, berdasarkan kebutuhan skenario Anda. Penting: Beberapa batas memiliki batas maksimum yang ketat. Di Visual Studio Code, perubahan yang Anda lakukan pada nilai batas default dalam file konfigurasi proyek aplikasi logika Anda tidak akan ditampilkan di pengalaman perancang. Untuk informasi selengkapnya, lihat Mengedit pengaturan aplikasi dan lingkungan untuk aplikasi logika di Azure Logic Apps tenant tunggal.
Standar (App Service Environment v3) Lingkungan host: App Service Environment v3 (ASEv3) - Khusus paket Windows	Memiliki kemampuan yang sama dengan penyewa tunggal, ditambah dengan manfaat berikut: - Mengisolasi aplikasi logika Anda sepenuhnya. - Buat dan jalankan lebih banyak aplikasi Logic dibandingkan dengan Azure Logic Apps penyewa tunggal. - Membayar hanya untuk paket App Service ASE, berapa pun jumlah aplikasi logika yang Anda buat dan jalankan. - Dapat mengaktifkan penskalaan otomatis atau penskalaan manual dengan lebih banyak instans mesin virtual atau paket App Service yang berbeda. - Mengadopsi pengaturan jaringan dari ASEv3 yang dipilih. Misalnya, saat Anda menyebarkan ke ASE internal, alur kerja dapat mengakses sumber daya di jaringan virtual yang terkait dengan ASE dan memiliki titik akses internal. Catatan: Jika diakses dari luar ASE internal, riwayat pengerjaan untuk alur kerja di ASE tersebut tidak dapat mengakses input dan output tindakan.	Satu aplikasi logika dapat memiliki beberapa alur kerja berstatus dan tidak berstatus. Alur kerja dalam satu aplikasi logika dan satu tenant memiliki pemrosesan (komputasi), penyimpanan, jaringan, dan sebagainya yang sama. Data tetap berada di wilayah yang sama dengan tempat Anda menyebarkan aplikasi logika Anda.	Rencana Layanan Aplikasi	Anda dapat mengubah nilai default untuk banyak batasan, berdasarkan kebutuhan skenario Anda. Penting: Beberapa batas memiliki batas maksimum yang ketat. Di Visual Studio Code, perubahan yang Anda lakukan pada nilai batas default dalam file konfigurasi proyek aplikasi logika Anda tidak akan ditampilkan di pengalaman perancang. Untuk informasi selengkapnya, lihat Mengedit pengaturan aplikasi dan lingkungan untuk aplikasi logika di Azure Logic Apps tenant tunggal.

Aplikasi logika standar dan alur kerja

Aplikasi logika Standar dan alur kerja didukung oleh runtime Azure Logic Apps penyewa tunggal yang telah didesain ulang. Runtime ini menggunakan model ekstensibilitas Azure Functions dan dihosting sebagai ekstensi pada runtime Azure Functions. Desain ini memberikan portabilitas, fleksibilitas, dan performa lebih untuk alur kerja aplikasi logika Anda ditambah kemampuan dan manfaat lain yang diwarisi dari platform Azure Functions dan ekosistem Azure App Service. Misalnya, Anda dapat membuat, menyebarkan, dan menjalankan aplikasi logika berbasis penyewa tunggal dan alur kerjanya di Azure App Service Environment v3 (hanya paket Windows).

Aplikasi logika Standar memperkenalkan struktur sumber daya yang dapat menghosting beberapa alur kerja, mirip dengan bagaimana aplikasi fungsi Azure dapat menghosting beberapa fungsi. Dengan pemetaan 1-ke-banyak, alur kerja di aplikasi logika yang sama dan penyewa berbagi sumber daya komputasi dan pemrosesan, memberikan performa yang lebih baik karena kedekatannya. Struktur ini berbeda dari sumber daya aplikasi logika Konsumsi tempat Anda memiliki pemetaan 1-ke-1 antara sumber daya aplikasi logika dan alur kerja.

Untuk mempelajari selengkapnya tentang portabilitas, fleksibilitas, dan peningkatan performa, lanjutkan meninjau bagian berikut. Untuk informasi selengkapnya tentang runtime Azure Logic Apps penyewa tunggal dan ekstensibilitas Azure Functions, tinjau dokumentasi berikut:

Portabilitas dan fleksibilitas

Saat membuat aplikasi logika dan alur kerja Standar , Anda dapat menyebarkan dan menjalankan alur kerja di lingkungan lain, seperti Azure App Service Environment v3 (hanya paket Windows). Jika Anda menggunakan Visual Studio Code dengan ekstensi Azure Logic Apps (Standar), Anda dapat mengembangkan, membangun, dan menjalankan alur kerja secara lokal di lingkungan pengembangan tanpa harus menyebarkan ke Azure. Jika skenario Anda memerlukan kontainer, Anda dapat membuat aplikasi logika penyewa tunggal menggunakan Logic Apps dengan dukungan Azure Arc. Untuk informasi selengkapnya, lihat Apa itu Logic Apps dengan dukungan Azure Arc?

Kemampuan ini memberikan peningkatan besar dan manfaat yang substansial dibandingkan dengan model multipenyewa, yang mengharuskan Anda untuk mengembangkan menggunakan sumber daya yang sudah berjalan di Azure. Model multitenancy untuk mengotomatiskan penyebaran sumber daya aplikasi logika Konsumsi didasarkan pada templat Azure Resource Manager (templat ARM), yang menggabungkan dan menangani penyediaan sumber daya untuk aplikasi dan infrastruktur.

Dengan sumber daya aplikasi logika Standar , penyebaran menjadi lebih mudah karena Anda dapat memisahkan penyebaran aplikasi dari penyebaran infrastruktur. Anda dapat mengemas runtime Azure Logic Apps penyewa tunggal dan alur kerja Anda menjadi satu sebagai bagian dari sumber daya atau proyek aplikasi logika Anda. Anda dapat menggunakan langkah atau tugas umum yang membangun, merakit, dan meng-zip sumber daya aplikasi logika Anda ke dalam artefak yang siap disebarkan. Untuk menyebarkan infrastruktur, Anda masih dapat menggunakan templat ARM untuk membuat sumber daya tersebut secara terpisah bersama dengan proses dan alur lain yang Anda gunakan untuk tujuan tersebut.

Untuk memasang aplikasi, salin berkas ke lingkungan penghosting lalu jalankan aplikasi Anda untuk menjalankan alur kerja. Atau, integrasikan artefak Anda ke dalam alur penyebaran menggunakan alat dan proses yang sudah Anda ketahui dan gunakan. Dengan demikian, Anda dapat menyebarkan menggunakan alat pilihan Anda sendiri, apa pun tumpukan teknologi yang Anda gunakan untuk pengembangan.

Dengan menggunakan opsi build dan deploy standar, Anda dapat fokus pada pengembangan aplikasi secara terpisah dari penyebaran infrastruktur. Akibatnya, Anda mendapatkan model proyek yang lebih umum di mana Anda dapat menerapkan banyak opsi penyebaran serupa atau sama yang Anda gunakan untuk aplikasi generik. Anda juga mendapat manfaat dari pengalaman yang lebih konsisten saat membuat alur penyebaran untuk aplikasi Anda dan saat Menjalankan pengujian dan validasi yang diperlukan sebelum menerbitkan ke produksi.

Penampilan

Dengan aplikasi logika Standar , Anda dapat membuat dan menjalankan beberapa alur kerja dalam satu sumber daya dan penyewa aplikasi logika yang sama. Dengan pemetaan 1-ke-banyak ini, alur kerja ini berbagi sumber daya, seperti komputasi, pemrosesan, penyimpanan, dan jaringan, memberikan performa yang lebih baik karena kedekatannya.

Sumber daya aplikasi logika Standar dan runtime Azure Logic Apps penyewa tunggal memberikan peningkatan signifikan lainnya dengan membuat konektor terkelola yang lebih populer tersedia sebagai operasi konektor bawaan. Misalnya, Anda dapat menggunakan operasi konektor bawaan untuk Azure Service Bus, Azure Event Hubs, SQL Server, dan lainnya. Sementara itu, versi konektor terkelola masih tersedia dan terus berfungsi.

Saat Anda menggunakan operasi konektor bawaan baru, Anda membuat koneksi yang disebut koneksi bawaan atau koneksi penyedia layanan. Mitra koneksi terkelola mereka disebut koneksi API, yang dibuat dan dijalankan secara terpisah sebagai sumber daya Azure yang juga harus Anda sebarkan dengan menggunakan templat ARM. Operasi bawaan dan koneksinya berjalan secara lokal dalam proses yang sama yang menjalankan alur kerja Anda. Keduanya berbasis pada runtime Azure Logic Apps penyewa tunggal. Akibatnya, operasi bawaan dan koneksinya memberikan performa yang lebih baik karena kedekatan dengan alur kerja Anda. Desain ini juga berfungsi dengan baik dengan alur penyebaran karena koneksi penyedia layanan dipaketkan ke dalam artefak build yang sama.

Lokasi Penyimpanan Data

Sumber daya aplikasi logika standar dihosting di Azure Logic Apps penyewa tunggal, yang tidak menyimpan, memproses, atau mereplikasi data di luar wilayah tempat Anda menyebarkan sumber daya aplikasi logika ini, yang berarti bahwa data dalam alur kerja Anda tetap berada di wilayah yang sama tempat Anda membuat dan menyebarkan sumber daya induknya.

Akses langsung ke sumber daya di jaringan virtual Azure

Alur kerja yang berjalan di Azure Logic Apps penyewa tunggal dapat langsung mengakses sumber daya aman seperti komputer virtual (VM), layanan lain, dan sistem yang ada di jaringan virtual Azure.

Azure Logic Apps Single-tenant adalah instans khusus dari layanan Azure Logic Apps, menggunakan sumber daya yang telah dialokasikan khusus, dan beroperasi secara terpisah dari Azure Logic Apps Multitenant. Menjalankan alur kerja dalam instans khusus membantu mengurangi efek yang mungkin dimiliki penyewa Azure lainnya pada performa aplikasi, juga dikenal sebagai efek "tetangga yang bising".

Azure Logic Apps satu penyewa juga memberikan manfaat berikut:

Alamat IP statis milik Anda sendiri, yang terpisah dari alamat IP statis yang dibagikan oleh Azure Logic Apps pada lingkungan multipenyewa. Anda juga dapat menyiapkan satu alamat IP keluar publik, statis, dan dapat diprediksi untuk berkomunikasi dengan sistem tujuan. Dengan begitu, Anda tidak perlu menyiapkan bukaan firewall tambahan di sistem tujuan tersebut.
Peningkatan batas pada durasi eksekusi, retensi penyimpanan, throughput, batas waktu habis permintaan dan respons HTTP, ukuran pesan, dan permintaan pada konektor kustom. Untuk informasi selengkapnya, tinjau Batasan dan konfigurasi untuk Azure Logic Apps.

Membuat, membangun, dan menyebarkan opsi

Untuk membuat sumber daya aplikasi logika berdasarkan lingkungan yang Anda inginkan, Anda memiliki beberapa opsi, misalnya:

Lingkungan penyewa tunggal

Opsi	Sumber daya dan alat	Informasi selengkapnya
Portal Microsoft Azure	Standard Logic App	Membuat contoh alur kerja aplikasi logika Standar di Azure Logic Apps penyewa tunggal - portal Microsoft Azure
Visual Studio Code	Ekstensi Azure Logic Apps (Standar)	Membuat contoh alur kerja aplikasi logika Standar di Azure Logic Apps penyewa tunggal - Visual Studio Code
Azure CLI (antarmuka baris perintah Azure)	Ekstensi Azure CLI Logic Apps	az logicapp
Manajer Sumber Daya Azure	- Lokal - DevOps	Azure Logic Apps penyewa tunggal
Logic Apps dengan dukungan Azure Arc	Sampel Logic Apps dengan dukungan Azure Arc	- Apa itu Logic Apps dengan dukungan Azure Arc? - Membuat dan menyebarkan alur kerja aplikasi logika berbasis penyewa tunggal dengan Logic Apps dengan dukungan Azure Arc
Azure REST API	Azure App Service REST API* Catatan: REST API aplikasi logika Standar disertakan dengan REST API Azure App Service.	Mulai menggunakan referensi Azure REST API

Lingkungan multipenyewa

Opsi	Sumber daya dan alat	Informasi selengkapnya
Portal Microsoft Azure	Aplikasi logika konsumsi	Mulai cepat: Membuat contoh alur kerja aplikasi logika Konsumsi di Azure Logic Apps multipenyewa - portal Microsoft Azure
Visual Studio Code	Ekstensi Azure Logic Apps (Konsumsi)	Mulai cepat: Membuat contoh alur kerja aplikasi logika Konsumsi di Azure Logic Apps multipenyewa - Visual Studio Code
Azure CLI (antarmuka baris perintah Azure)	Ekstensi Azure CLI Logic Apps	- Mulai cepat: Membuat dan mengelola alur kerja aplikasi logika Konsumsi di Azure Logic Apps multipenyewa - Azure CLI - logika az
Manajer Sumber Daya Azure	Membuat aplikasi logika Templat ARM	Panduan cepat: Membuat dan menerapkan workflow aplikasi logika konsumsi dalam lingkungan Azure Logic Apps multitenan - Template ARM
Azure PowerShell	Modul Az.LogicApp	Mulai menggunakan Azure PowerShell
Azure REST API	Azure Logic Apps REST API	Mulai menggunakan referensi Azure REST API

Meskipun pengalaman pengembangan Anda berbeda berdasarkan apakah Anda membuat sumber daya aplikasi logika Konsumsi atau Standar , Anda dapat menemukan dan mengakses semua aplikasi logika yang disebarkan di bawah langganan Azure Anda.

Misalnya, di portal Microsoft Azure, halaman Aplikasi logika menampilkan sumber daya aplikasi logika Konsumsi dan Standar . Di Visual Studio Code, aplikasi logika yang disebarkan muncul di bawah langganan Azure Anda, tetapi aplikasi logika Konsumsi muncul di jendela Azure di bawah ekstensi Azure Logic Apps (Konsumsi), sementara aplikasi logika Standar muncul di bawah bagian Sumber Daya .

Alur kerja berbasis status dan tanpa status

Dalam aplikasi logika Standar , Anda dapat membuat jenis alur kerja berikut:

Stateful

Buat alur kerja stateful saat Anda perlu menyimpan, meninjau, atau merujuk data dari kejadian sebelumnya. Alur kerja ini menyimpan semua input, output, dan status operasi ke penyimpanan eksternal. Informasi ini membuat peninjauan detail dan riwayat proses alur kerja menjadi mungkin setelah setiap proses selesai. Alur kerja stateful memberikan ketahanan tinggi jika terjadi pemadaman. Setelah layanan dan sistem dipulihkan, Anda dapat merekontruksi ulang proses yang terganggu dari titik penyimpanan awal dan menjalankan ulang alur kerja hingga selesai. Alur kerja stateful dapat terus berjalan lebih lama dari alur kerja tanpa status.

Secara default, alur kerja berstatus di Azure Logic Apps baik pada lingkungan multipenyewa maupun penyewa tunggal berjalan secara asinkron. Semua tindakan berbasis HTTP mengikuti pola operasi asinkron standar. Setelah tindakan HTTP memanggil atau mengirim permintaan ke titik akhir, layanan, sistem, atau API, penerima permintaan segera mengembalikan respons "202 DITERIMA" . Kode ini mengonfirmasi bahwa penerima menerima permintaan tetapi belum selesai diproses. Respons dapat menyertakan location header yang menentukan URI dan ID refresh yang dapat digunakan pemanggil untuk melakukan polling atau memeriksa status permintaan asinkron hingga penerima berhenti memproses dan mengembalikan respons keberhasilan "200 OK" atau respons non-202 lainnya. Namun, pemanggil tidak perlu menunggu permintaan selesai diproses dan dapat terus menjalankan tindakan berikutnya. Untuk informasi selengkapnya, lihat Integrasi layanan mikro asinkron memberlakukan otonomi layanan mikro.
Stateless

Buat alur kerja tanpa status saat Anda tidak perlu menyimpan, meninjau, atau mereferensikan data dari peristiwa sebelumnya di penyimpanan eksternal setelah setiap eksekusi selesai untuk ditinjau nanti. Alur kerja ini menyimpan semua input dan output untuk setiap tindakan dan statusnya hanya dalam memori, bukan di penyimpanan eksternal. Akibatnya, alur kerja tanpa status memiliki eksekusi yang lebih pendek yang biasanya selesai dalam 5 menit atau kurang, performa yang lebih cepat dengan waktu respons yang lebih cepat, throughput yang lebih tinggi, dan mengurangi biaya berjalan karena penyimpanan eksternal tidak menyimpan detail dan riwayat eksekusi alur kerja. Namun, jika pemadaman terjadi, eksekusi yang terganggu tidak dipulihkan secara otomatis, sehingga pemanggil perlu mengirim ulang eksekusi yang terganggu secara manual.

Alur kerja stateless memberikan performa terbaik saat menangani data atau konten yang tidak melebihi ukuran total 64 KB, seperti file. Ukuran konten yang lebih besar, seperti beberapa lampiran besar, mungkin secara signifikan memperlambat performa alur kerja Anda atau bahkan menyebabkan alur kerja Anda mengalami crash karena pengecualian di luar memori. Jika alur kerja Anda mungkin harus menangani ukuran konten yang lebih besar, gunakan alur kerja stateful sebagai gantinya.

Nota

Dalam alur kerja stateless, Anda hanya dapat menggunakan pemicu push di mana Anda tidak menentukan jadwal untuk menjalankan alur kerja Anda. Pemicu berbasis webhook ini menunggu peristiwa terjadi atau data tersedia. Misalnya, pemicu Pengulangan hanya tersedia untuk alur kerja stateful. Untuk memulai alur kerja Anda, pilih pemicu push seperti pemicu Request, Event Hubs, atau Service Bus. Untuk informasi selengkapnya tentang pemicu, tindakan, dan konektor terbatas, tidak tersedia, atau tidak didukung, lihat Kemampuan yang diubah, terbatas, tidak tersedia, atau tidak didukung.

Alur kerja tanpa status hanya berjalan secara sinkron, sehingga tidak menggunakan pola operasi asinkron standar yang digunakan oleh alur kerja stateful. Sebagai gantinya, semua tindakan berbasis HTTP yang mengembalikan respons "202 DITERIMA" berlanjut ke langkah berikutnya dalam eksekusi alur kerja. Jika respons menyertakan location header, alur kerja tanpa status tidak akan melakukan polling URI yang ditentukan untuk memeriksa status. Untuk mengikuti pola operasi asinkron standar, gunakan alur kerja stateful sebagai gantinya.

Untuk penelusuran kesalahan yang lebih mudah, Anda dapat mengaktifkan riwayat eksekusi untuk alur kerja tanpa status, yang memiliki beberapa efek pada performa, lalu menonaktifkan riwayat eksekusi saat Anda selesai. Untuk informasi selengkapnya, lihat Membuat alur kerja berbasis penyewa tunggal di Visual Studio Code atau Membuat alur kerja berbasis penyewa tunggal di portal Microsoft Azure.

Penting

Anda harus memutuskan jenis alur kerja, baik stateful atau stateless, untuk diterapkan pada waktu pembuatan. Perubahan pada jenis alur kerja setelah pembuatan menghasilkan kesalahan runtime.

Ringkasan perbedaan antara alur kerja berbasis state dan tanpa state

Memiliki Status	Tanpa Negara
Menyimpan riwayat eksekusi, input, dan output	Tidak menyimpan riwayat eksekusi, input, atau output secara default
Pemicu konektor terkelola tersedia dan diizinkan	Pemicu konektor terkelola tidak tersedia atau tidak diizinkan
Mendukung penggugusan	Tidak ada dukungan untuk pemotongan
Mendukung operasi asinkron	Tidak ada dukungan untuk operasi asinkron
Mengedit durasi eksekusi maks default dalam konfigurasi host	Terbaik untuk alur kerja dengan durasi maksimum di bawah 5 menit
Menangani pesan besar	Terbaik untuk menangani ukuran pesan kecil (di bawah 64 KB)

Perbedaan perilaku berlapis antara alur kerja stateful dan stateless

Anda dapat membuat alur kerja dapat dipanggil dari alur kerja lain yang ada di aplikasi logika Standar yang sama dengan menggunakan pemicu Permintaan, pemicu HTTP Webhook, atau pemicu konektor terkelola yang memiliki jenis ApiConnectionWebhook dan dapat menerima permintaan HTTPS.

Daftar berikut ini menjelaskan pola perilaku yang dapat diikuti alur kerja berlapis setelah alur kerja induk memanggil alur kerja anak:

Pola poling asinkron

Alur kerja induk tidak menunggu alur kerja anak merespons panggilan awal mereka. Namun, induk terus memantau riwayat eksekusi anak sampai anak selesai menjalankan proses. Secara default, alur kerja stateful mengikuti pola ini, yang ideal untuk alur kerja anak yang berjalan lama yang mungkin melebihi batas waktu habis permintaan.
Pola sinkron ("luncur dan lupakan")

Alur kerja anak mengakui panggilan alur kerja induk dengan segera mengembalikan 202 ACCEPTED respons. Namun, orang tua tidak menunggu anaknya mengembalikan hasil. Sebagai gantinya, induk melanjutkan ke tindakan berikutnya dalam alur kerja dan menerima hasil ketika anak selesai berjalan. Alur kerja berstatus turunan yang tidak menyertakan tindakan Respons selalu mengikuti pola sinkron dan menyediakan riwayat pelaksanaan untuk Anda periksa.

Untuk mengaktifkan perilaku ini, dalam definisi JSON alur kerja, atur properti ke operationOptionsDisableAsyncPattern. Untuk informasi selengkapnya, lihat Pemicu dan jenis tindakan - Opsi operasi.
Pemicu dan tunggu

Alur kerja tanpa status berjalan dalam memori. Jadi, ketika alur kerja induk memanggil alur kerja tanpa status anak, induk menunggu respons yang mengembalikan hasil dari anak. Pola ini berfungsi sama dengan menggunakan pemicu atau tindakan HTTP bawaan untuk memanggil alur kerja anak. Alur kerja stateless anak yang tidak menyertakan tindakan Respons akan segera mengembalikan respons 202 ACCEPTED, tetapi induk akan menunggu hingga anak selesai sebelum melanjutkan ke tindakan berikutnya. Perilaku ini hanya berlaku untuk alur kerja tanpa status anak.

Tabel berikut mengidentifikasi perilaku alur kerja anak berdasarkan apakah alur kerja induk dan anak bersifat stateful, stateless, atau adalah tipe alur kerja campuran. Daftar setelah tabel

Alur kerja induk	Alur kerja anak	Perilaku anak
Memiliki Status	Memiliki Status	Asinkron atau sinkron dengan pengaturan `"operationOptions": "DisableAsyncPattern"`
Memiliki Status	Tanpa Negara	Pemicu dan tunggu
Tanpa Negara	Memiliki Status	Sinkronis
Tanpa Negara	Tanpa Negara	Pemicu dan tunggu

Kemampuan model penyewa tunggal lainnya

Model penyewa tunggal dan aplikasi logika Standar mencakup banyak kemampuan saat ini dan baru, misalnya:

Buat aplikasi logika dan alur kerjanya dari 1.400+ konektor terkelola untuk aplikasi dan layanan Software-as-a-Service (SaaS) dan Platform-as-a-Service (PaaS) ditambah konektor untuk sistem lokal.
- Lebih banyak konektor terkelola sekarang tersedia sebagai konektor bawaan dalam alur kerja Standar. Versi tertanam berjalan secara native pada runtime penyewa tunggal Azure Logic Apps. Beberapa konektor bawaan juga secara informal dikenal sebagai konektor penyedia layanan. Untuk daftar, tinjau Konektor bawaan di Konsumsi dan Standar.
- Anda dapat membuat konektor bawaan yang dapat disesuaikan Anda sendiri untuk layanan apa pun yang Anda butuhkan dengan menggunakan kerangka kerja ekstensibilitas arsitektur penyewa tunggal Azure Logic Apps. Mirip dengan konektor bawaan seperti Azure Service Bus dan SQL Server, konektor bawaan kustom menyediakan throughput yang lebih tinggi, latensi rendah, dan konektivitas lokal karena berjalan dalam proses yang sama dengan runtime penyewa tunggal. Namun, konektor bawaan kustom tidak mirip dengan konektor terkelola kustom, yang saat ini tidak didukung. Untuk informasi selengkapnya, tinjau Gambaran umum konektor kustom dan Buat konektor built-in kustom untuk aplikasi logika Standar di Azure Logic Apps tunggal-tenant.
- Anda dapat menggunakan tindakan berikut untuk Operasi Liquid dan Operasi XML tanpa akun integrasi. Operasi ini mencakup tindakan berikut:
  - XML: Mengubah XML, Validasi XML, menyusun XML dengan skema, dan penguraian XML dengan skema
  - Liquid: Mengubah JSON Ke JSON, Mengubah JSON Ke TEXT, Mengubah XML Ke JSON, dan Mengubah XML Menjadi Teks
  Nota
  
  Untuk menggunakan tindakan ini dalam alur kerja Standar, Anda harus memiliki peta Liquid, peta XML, atau skema XML. Anda dapat mengunggah artefak ini di portal Microsoft Azure dari menu sumber daya aplikasi logika Anda, di bawah Artefak, yang mencakup bagian Skema dan Peta . Atau, Anda dapat menambahkan artefak ini ke folder Artefak proyek Visual Studio Code menggunakan folder Peta dan Skema masing-masing. Anda kemudian dapat menggunakan artefak ini di beberapa alur kerja dalam aplikasi logika yang sama .
- Alur kerja aplikasi logika standar dapat dipicu dari mana saja karena Azure Logic Apps menghasilkan string koneksi Tanda Tangan Akses Bersama (SAS) yang dapat digunakan aplikasi logika ini untuk mengirim permintaan ke titik akhir runtime koneksi cloud. Azure Logic Apps menyimpan string koneksi ini dengan pengaturan aplikasi lain sehingga Anda dapat dengan mudah menyimpan nilai-nilai ini di Azure Key Vault saat Anda menyebarkan di Azure.
- Alur kerja aplikasi logika standar mendukung pengaktifan identitas terkelola yang ditetapkan sistem dan beberapa identitas terkelola yang ditetapkan pengguna secara bersamaan, meskipun Anda hanya dapat memilih satu identitas untuk digunakan pada satu waktu. Meskipun konektor berbasis penyedia layanan bawaan mendukung penggunaan identitas yang ditetapkan sistem, sebagian besar saat ini tidak mendukung pemilihan identitas terkelola yang ditetapkan pengguna untuk autentikasi, kecuali untuk SQL Server dan konektor HTTP.
  
  Nota
  
  Secara default, identitas yang ditetapkan sistem sudah diaktifkan untuk mengautentikasi koneksi pada waktu proses. Identitas ini berbeda dari info masuk autentikasi atau string koneksi yang digunakan saat membuat koneksi. Jika Anda menonaktifkan identitas ini, koneksi tidak akan berfungsi pada waktu proses. Untuk melihat pengaturan ini, pada menu aplikasi logika Anda, di bawah Pengaturan, pilih Identitas.
Anda dapat menjalankan, menguji, dan men-debug aplikasi logika anda secara lokal dan alur kerjanya di lingkungan pengembangan Visual Studio Code.

Sebelum menjalankan dan menguji aplikasi logika, Anda dapat mempermudah penelusuran kesalahan dengan menambahkan dan menggunakan titik henti di dalam file workflow.json untuk alur kerja. Namun, titik henti saat ini hanya didukung untuk tindakan, bukan pemicu. Untuk informasi selengkapnya, lihat Membuat alur kerja berbasis penyewa tunggal di Visual Studio Code.
Publikasikan atau sebarkan aplikasi logika secara langsung dan alur kerjanya dari Visual Studio Code ke berbagai lingkungan hosting seperti Logic Apps dengan dukungan Azure dan Azure Arc.
Aktifkan kemampuan pengelogan dan pelacakan diagnostik untuk aplikasi logika Anda dengan menggunakan Application Insights saat didukung oleh pengaturan aplikasi logika dan langganan Azure Anda.
Akses kemampuan jaringan, seperti menyambungkan dan mengintegrasikan secara privat dengan jaringan virtual Azure, mirip dengan Azure Functions saat Anda membuat dan menyebarkan aplikasi logika menggunakan paket Azure Functions Premium. Untuk informasi selengkapnya, tinjau dokumentasi berikut ini:
- Opsi jaringan Azure Functions
- Azure Logic Apps Berjalan di Mana Saja - Opsi Jaringan dengan Azure Logic Apps
Meregenerasi kunci akses untuk koneksi terkelola yang digunakan oleh alur kerja individual di aplikasi logika Standar . Untuk tugas ini, ikuti langkah yang sama untuk aplikasi logika Konsumsi tetapi pada tingkat alur kerja, bukan tingkat sumber daya aplikasi logika.

Konektor bawaan untuk Standar

Alur kerja Standar dapat menggunakan banyak konektor bawaan yang sama sebagai alur kerja Konsumsi, tetapi tidak semua. Sebaliknya, alur kerja Standar memiliki banyak konektor bawaan yang tidak tersedia dalam alur kerja Konsumsi.

Misalnya, alur kerja Standar memiliki konektor terkelola dan konektor bawaan untuk Azure Blob, Azure Cosmos DB, Azure Event Hubs, Azure Service Bus, DB2, FTP, MQ, SFTP, SQL Server, dan lainnya. Meskipun alur kerja Konsumsi tidak memiliki versi konektor bawaan yang sama ini, konektor bawaan lainnya seperti Azure API Management dan Azure App Services tersedia.

Dalam Azure Logic Apps untuk penyewa tunggal, konektor bawaan dengan atribut tertentu dikenal secara informal sebagai penyedia layanan. Beberapa konektor bawaan hanya mendukung satu cara untuk mengautentikasi koneksi ke layanan yang mendasar. Konektor bawaan lainnya dapat menawarkan pilihan, seperti menggunakan string koneksi, ID Microsoft Entra, atau identitas terkelola. Semua konektor bawaan berjalan dalam proses yang sama dengan runtime Azure Logic Apps yang didesain ulang. Untuk informasi selengkapnya, tinjau daftar konektor bawaan untuk alur kerja aplikasi logika Standar.

Penting

Pastikan untuk menyiapkan dan menguji pemicu berbasis penyedia layanan dengan benar untuk mengonfirmasi keberhasilan operasi. Pemicu berbasis penyedia layanan yang gagal dapat menciptakan penskalaan yang tidak perlu, yang dapat secara dramatis meningkatkan biaya penagihan Anda. Misalnya, kesalahan umum adalah mengatur pemicu tanpa memberikan izin atau akses aplikasi logika Anda ke tujuan, seperti antrean Service Bus, kontainer blob Azure Storage, dan sebagainya. Selain itu, pastikan Anda memantau pemicu tersebut setiap saat sehingga Anda dapat segera mendeteksi dan memperbaiki masalah apa pun.

Kemampuan yang diubah, terbatas, tidak tersedia, atau tidak didukung

Untuk alur kerja aplikasi logika Standar , kemampuan berikut berbeda, saat ini terbatas, tidak tersedia, atau tidak didukung:

Pemicu dan tindakan: Pemicu dan tindakan bawaan berjalan secara asli di Azure Logic Apps, sementara konektor terkelola dihosting dan dijalankan menggunakan sumber daya bersama di Azure. Untuk alur kerja Standar, beberapa pemicu dan tindakan bawaan saat ini tidak tersedia, seperti operasi Azure App Service. Untuk memulai alur kerja stateful atau stateless, gunakan pemicu bawaan seperti pemicu Request, Event Hubs, atau Service Bus. Pemicu Pengulangan tersedia untuk alur kerja yang bersifat stateful, tetapi tidak untuk alur kerja yang bersifat stateless. Di galeri konektor, pemicu dan tindakan bawaan muncul saat Anda memilih filter Bawaan , sementara pemicu dan tindakan konektor terkelola muncul saat Anda memilih filter Bersama .

Alur kerja tanpa status hanya dapat menggunakan pemicu push di mana Anda tidak menentukan jadwal untuk menjalankan alur kerja Anda. Pemicu berbasis webhook ini menunggu peristiwa terjadi atau data tersedia. Misalnya, pemicu Pengulangan hanya tersedia untuk alur kerja stateful. Untuk memulai alur kerja Anda, pilih pemicu push seperti pemicu Request, Event Hubs, atau Service Bus. Meskipun Anda dapat mengaktifkan konektor terkelola untuk alur kerja tanpa status, galeri konektor tidak menampilkan pemicu polling konektor terkelola yang ingin Anda tambahkan.

Nota

Untuk berjalan secara lokal di Visual Studio Code, pemicu dan tindakan berbasis webhook memerlukan penyiapan tambahan. Untuk informasi selengkapnya, lihat Membuat alur kerja berbasis penyewa tunggal di Visual Studio Code.
- Pemicu dan tindakan berikut telah berubah atau saat ini terbatas, tidak didukung, atau tidak tersedia:
  - Tindakan bawaan, Azure Functions - Pilih sebuah fungsi Azure sekarang menjadi Operasi Azure Functions - Panggil sebuah fungsi Azure. Tindakan ini saat ini hanya berfungsi untuk fungsi yang dibuat dari templat Pemicu HTTP .
    
    Di portal Microsoft Azure, Anda dapat memilih fungsi pemicu HTTP yang dapat Anda akses dengan membuat koneksi melalui pengalaman pengguna. Jika Anda memeriksa definisi JSON dari tindakan fungsi dalam tampilan kode atau file workflow.json menggunakan Visual Studio Code, tindakan tersebut mengacu pada fungsi dengan menggunakan referensi connectionName. Versi ini mengabstraksi informasi fungsi sebagai koneksi, yang dapat Anda temukan di file connections.json proyek aplikasi logika Anda, yang tersedia setelah Anda membuat koneksi di Visual Studio Code.
    
    Nota
    
    Dalam model penyewa tunggal, tindakan fungsi hanya mendukung autentikasi string kueri. Azure Logic Apps mendapatkan kunci default dari fungsi saat membuat koneksi, menyimpan kunci tersebut di pengaturan aplikasi Anda, dan menggunakan kunci untuk autentikasi saat memanggil fungsi.
    
    Seperti dalam model multipenyewa, jika Anda memperbarui kunci ini, misalnya, melalui antarmuka Azure Functions di portal, aksi fungsi tidak lagi berfungsi karena kunci yang tidak valid. Untuk memperbaiki masalah ini, Anda perlu membuat ulang koneksi ke fungsi yang ingin Anda panggil atau perbarui pengaturan aplikasi Anda dengan kunci baru.
  - Tindakan bawaan, Kode Sebaris, diganti namanya menjadi Operasi Kode Sebaris, tidak lagi memerlukan akun integrasi, dan memiliki batas yang diperbarui.
  - Tindakan bawaan, Azure Logic Apps - Pilih alur kerja Aplikasi Logika sekarang adalah Operasi Alur Kerja - Memanggil alur kerja di aplikasi alur kerja ini.
  - Alur kerja Standar hanya dapat memiliki satu pemicu dan tidak mendukung beberapa pemicu.
Autentikasi
- Beberapa pemicu berbasis permintaan yang menangani panggilan masuk, seperti pemicu Permintaan, saat ini tidak mendukung Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth), sementara yang lain seperti pemicu HTTP Webhook memiliki dukungan ini.
- Beberapa konektor berbasis penyedia layanan bawaan saat ini tidak mendukung pemilihan identitas terkelola yang ditetapkan pengguna untuk autentikasi. Namun, dukungan identitas terkelola yang ditetapkan sistem dan yang ditetapkan pengguna tersedia secara umum. Secara default, identitas terkelola yang ditetapkan sistem diaktifkan secara otomatis.
Penelusuran kesalahan titik henti di Visual Studio Code: Meskipun Anda dapat menambahkan dan menggunakan titik henti di dalam file workflow.json untuk alur kerja, saat ini titik henti hanya didukung untuk tindakan, bukan pemicu. Untuk informasi selengkapnya, lihat Membuat alur kerja berbasis penyewa tunggal di Visual Studio Code.
Riwayat pemicu dan riwayat eksekusi: Untuk alur kerja aplikasi logika Standar , riwayat pemicu dan riwayat eksekusi di portal Microsoft Azure muncul di tingkat alur kerja, bukan tingkat sumber daya aplikasi logika. Untuk informasi selengkapnya, tinjau Membuat alur kerja berbasis penyewa tunggal menggunakan portal Microsoft Azure.
Templat Terraform: Anda tidak dapat menggunakan templat ini dengan sumber daya aplikasi logika Standar untuk penerapan infrastruktur secara lengkap. Untuk informasi selengkapnya, lihat Apa itu Terraform di Azure?

Izin lalu lintas jaringan dan firewall yang ketat

Jika lingkungan Anda memiliki persyaratan jaringan atau firewall ketat yang membatasi lalu lintas, Anda harus mengizinkan akses untuk pemicu atau koneksi tindakan apa pun di alur kerja Anda. Anda dapat secara opsional mengizinkan lalu lintas dari tag layanan dan menggunakan tingkat pembatasan atau kebijakan yang sama dengan Azure App Service. Anda juga perlu menemukan dan menggunakan nama domain yang sepenuhnya memenuhi syarat (FQDN) bagi koneksi Anda. Untuk informasi selengkapnya, tinjau bagian yang sesuai pada dokumentasi berikut:

Langkah selanjutnya

Kami juga ingin mendengar tentang pengalaman Anda dengan Azure Logic Apps khusus!

Untuk bug atau masalah, buat masalah Anda di GitHub.
Untuk pertanyaan, permintaan, komentar, dan umpan balik lainnya, gunakan formulir umpan balik ini.