Perbedaan antara aplikasi logika penyewa tunggal Standar versus aplikasi logika multipenyewa Konsumsi
Azure Logic Apps adalah platform berbasis cloud untuk membuat dan menjalankan lalur kerja aplikasi otomatis yang mengintegrasikan aplikasi, data, layanan, dan sistem Anda. Dengan platform ini, Anda dapat dengan cepat mengembangkan solusi integrasi yang sangat skalabel untuk skenario perusahaan dan bisnis ke bisnis (B2B) Anda. Saat membuat sumber daya aplikasi logika, Anda memilih opsi Konsumsi atau Hosting standar . Aplikasi logika Konsumsi hanya dapat memiliki satu alur kerja yang berjalan di Azure Logic Apps multipenyewa . Aplikasi logika Standar dapat memiliki satu atau beberapa alur kerja yang berjalan di Azure Logic Apps penyewa tunggal atau Lingkungan App Service 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 |
---|---|---|---|---|
Consumption Lingkungan host: Azure Logic Apps multipenyewa |
- 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 logika 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. |
Konsumsi (bayar per eksekusi) | 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 penyewa tunggal Catatan: Jika skenario Anda memerlukan kontainer, buat aplikasi logika berbasis penyewa tunggal menggunakan Azure Logic Apps yang diaktifkan Azure Arc. Untuk informasi selengkapnya, tinjau Apa itu Logic Apps yang diaktifkan Azure Arc?? |
- Lebih banyak konektor bawaan yang dihosting pada runtime penyewa tunggal untuk throughput yang lebih tinggi dan biaya yang lebih rendah dalam skala besar - Lebih banyak kontrol dan kemampuan penyempurnaan sekeliling 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 penyewa memiliki pemrosesan (komputasi), penyimpanan, jaringan, dan sebagainya yang sama. Data tetap berada di wilayah yang sama tempat Anda menyebarkan aplikasi logika. |
Standar, berdasarkan paket hosting dengan tingkat harga yang dipilih. Jika Anda menjalankan alur kerja berstatus, 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 batasan memiliki maksimum atas yang tinggi. 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 satu penyewa. |
Standar (App Service Environment v3) Lingkungan host: App Service Environment v3 (ASEv3) - Khusus paket Windows |
Kemampuan yang sama dengan penyewa tunggal ditambah manfaat berikut: - Mengisolasi aplikasi logika Anda sepenuhnya. - Membuat dan menjalankan lebih banyak aplikasi logika daripada di 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. - Mewarisi 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, jalankan riwayat 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 penyewa memiliki pemrosesan (komputasi), penyimpanan, jaringan, dan sebagainya yang sama. Data tetap berada di wilayah yang sama dengan tempat Anda menyebarkan aplikasi logika Anda. |
Paket App Service | Anda dapat mengubah nilai default untuk banyak batasan, berdasarkan kebutuhan skenario Anda. Penting: Beberapa batasan memiliki maksimum atas yang tinggi. 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 satu penyewa. |
Aplikasi logika standar dan alur kerja
Aplikasi logika standar dan alur kerja didukung oleh runtime Azure Logic Apps penyewa tunggal yang 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 (Khusus 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 dalam aplikasi logika dan penyewa yang sama berbagi sumber daya komputasi dan pemrosesan sehingga memberikan kinerja 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:
- Azure Logic Apps Berjalan di Mana Saja - Runtime Deep Dive
- Pengantar Azure Functions
- Pemicu dan pengikatan Azure Functions
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 terhadap sumber daya yang sedang berjalan di Azure. Model multipenyewa untuk mengotomatiskan penyebaran sumber daya aplikasi logika Konsumsi didasarkan pada templat Azure Resource Manager (templat ARM), yang menggabungkan dan menangani provisi 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 bersama-sama sebagai bagian dari sumber daya atau proyek aplikasi logika Anda. Anda dapat menggunakan langkah atau tugas umum yang membangun, merakit, dan membuat zip sumber daya aplikasi logika ke dalam artefak yang siap disebar. Untuk menyebarkan infrastruktur, Anda masih dapat menggunakan templat ARM untuk menyediakan sumber daya tersebut secara terpisah bersama dengan proses dan alur lain yang Anda gunakan untuk tujuan tersebut.
Untuk menyebarkan aplikasi, salin artefak ke lingkungan host lalu mulai aplikasi untuk menjalankan alur kerja. Atau, integrasikan artefak ke dalam alur penyebaran menggunakan alat dan proses yang telah Anda ketahui dan gunakan. Dengan demikian, Anda dapat menggunakan alat yang Anda pilih sendiri, apa pun tumpukan teknologi yang Anda gunakan untuk pengembangan.
Dengan menggunakan opsi bangun dan sebar 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 digunakan untuk aplikasi umum. Anda juga memperoleh 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.
Performa
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 sehingga memberikan kinerja 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 Bus Layanan, 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. Rekan koneksi terkelola mereka disebut koneksi API, yang dibuat dan dijalankan secara terpisah sebagai sumber daya Azure yang juga harus Anda terapkan menggunakan templat ARM. Operasi bawaan dan koneksinya berjalan secara lokal dalam proses yang sama dengan yang menjalankan alur kerja Anda. Keduanya dihosting pada runtime Azure Logic Apps penyewa tunggal. Akibatnya, operasi bawaan dan koneksinya memberikan performa yang lebih baik karena kedekatannya dengan alur kerja Anda. Desain ini juga berfungsi dengan baik dengan alur penyebaran karena koneksi penyedia layanan dikemas ke dalam artefak bangunan yang sama.
Residensi 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 penyewa tunggal adalah instans khusus dari layanan Azure Logic Apps, menggunakan sumber daya khusus, dan berjalan secara terpisah dari Azure Logic Apps multipenyewa. Menjalankan alur kerja dalam instans khusus membantu mengurangi dampak yang mungkin dimiliki penyewa Azure lainnya pada performa aplikasi, juga dikenal sebagai efek "tetangga yang bising".
Azure Logic Apps penyewa tunggal juga memberikan manfaat berikut:
Alamat IP statis Anda sendiri, yang terpisah dari alamat IP statis yang dibagikan oleh aplikasi logika di Azure Logic Apps multipenyewa. Anda juga dapat menyiapkan alamat IP keluar tunggal yang bersifat 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 durasi eksekusi, penyimpanan, throughput, permintaan HTTP dan batas waktu respons, ukuran pesan, dan permintaan konektor kustom. Untuk informasi selengkapnya, tinjau Batasan dan konfigurasi untuk Azure Logic Apps.
Opsi buat, bangun, dan sebarkan
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 Azure | Aplikasi logika standar | Membuat contoh alur kerja aplikasi logika Standar di Azure Logic Apps penyewa tunggal - portal Azure |
Visual Studio Code | EkstensiAzure Logic Apps (Standar) | Membuat contoh alur kerja aplikasi logika Standar di Azure Logic Apps penyewa tunggal - Visual Studio Code |
Azure CLI | Ekstensi Logic Apps Azure CLI | az logicapp |
Azure Resource Manager | - Lokal - DevOps |
Azure Logic Apps penyewa tunggal |
Azure Logic Apps yang didukung Azure Arc | Sampel Logic Apps berbasis Azure Arc | - Apa itu Logic Apps berbasis Azure Arc? - Membuat dan menyebarkan alur kerja aplikasi logika berbasis penyewa tunggal dengan Logic Apps berbasis Azure Arc |
REST API Azure | Azure App Service REST API* Catatan: REST API aplikasi logika Standar disertakan dengan REST API Azure App Service. |
Mulai gunakan referensi Azure REST API |
Lingkungan multipenyewa
Opsi | Sumber daya dan alat | Informasi selengkapnya |
---|---|---|
Portal Azure | Aplikasi logika konsumsi | Mulai cepat: Membuat contoh alur kerja aplikasi logika Konsumsi di Azure Logic Apps multipenyewa - portal Azure |
Visual Studio Code | EkstensiAzure Logic Apps (Konsumsi) | Mulai cepat: Membuat contoh alur kerja aplikasi logika Konsumsi di Azure Logic Apps multipenyewa - Visual Studio Code |
Azure CLI | Ekstensi Logic Apps Azure CLI | - Mulai cepat: Membuat dan mengelola alur kerja aplikasi logika Konsumsi di Azure Logic Apps multipenyewa - Azure CLI - az logic |
Azure Resource Manager | Buat aplikasi logika templat ARM | Mulai cepat: Membuat dan menyebarkan alur kerja aplikasi logika Konsumsi di Azure Logic Apps multipenyewa - templat ARM |
Azure PowerShell | Modul Az.LogicApp | Mulai menggunakan Azure PowerShell |
REST API Azure | REST API Azure Logic Apps | Mulai gunakan referensi Azure REST API |
Meskipun Anda memiliki pengalaman pengembangan berbeda berdasarkan apakah Anda membuat sumber daya aplikasi logika Konsumsi atau Standar, Anda dapat menemukan dan mengakses semua aplikasi logika yang anda sebarkan di bawah langganan Azure Anda.
Misalnya, di portal 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 berstatus dan tanpa status
Dalam aplikasi logika Standar, Anda dapat membuat jenis alur kerja berikut:
Berstatus
Buat alur kerja berstatus jika Anda perlu menyimpan, meninjau, atau mereferensikan data dari peristiwa sebelumnya. Alur kerja ini menyimpan semua input, output, serta status operasi ke penyimpanan eksternal. Informasi ini memungkinkan peninjauan detail serta riwayat eksekusi alur kerja setelah setiap eksekusi selesai. Alur kerja berstatus memberikan ketahanan tinggi jika terjadi masalah. Setelah layanan dan sistem dipulihkan, Anda dapat merekonstruksi eksekusi yang terganggu dari status yang tersimpan dan menjalankan kembali alur kerja hingga selesai. Alur kerja berstatus dapat terus berjalan lebih lama daripada alur kerja tanpa status.
Secara default, alur kerja stateful di Azure Logic Apps multipenyewa dan penyewa tunggal berjalan secara asinkron. Secara default, semua tindakan berbasis HTTP di Azure Logic Apps mengikuti pola operasi asinkron standar. Pola ini menentukan bahwa setelah tindakan HTTP memanggil atau mengirim permintaan ke titik akhir, layanan, sistem, atau API yang ditentukan, penerima segera menghasilkan respons "202 DITERIMA". Kode ini mengonfirmasi bahwa penerima menerima permintaan tapi belum selesai diproses. Respons dapat menyertakan header
location
yang menentukan URL dan ID refresh yang dapat digunakan pemanggil untuk melakukan polling atau memeriksa status permintaan asinkron hingga penerima berhenti memproses dan mengembalikan respons berhasil "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.Tanpa status
Buat alur kerja tanpa status saat Anda tidak perlu menyimpan, meninjau, atau merujuk data dari peristiwa sebelumnya di penyimpanan eksternal setelah setiap proses selesai untuk ditinjau nanti. Alur kerja ini menyimpan semua input dan output untuk setiap tindakan dan statusnya hanya di memori, bukan di penyimpanan eksternal. Akibatnya, alur kerja tanpa status memiliki proses yang lebih pendek yang biasanya kurang dari 5 menit, performa yang lebih cepat dengan waktu respons yang lebih cepat, throughput yang lebih tinggi, serta biaya pengoperasian yang lebih rendah karena detail dan riwayat proses tidak disimpan di penyimpanan eksternal. Namun, jika terjadi masalah, eksekusi yang terganggu tidak dipulihkan secara otomatis sehingga pemanggil perlu mengirim ulang proses yang terganggu secara manual.
Alur kerja tanpa status memberikan performa terbaik saat menangani data atau konten seperti file, yang tidak melebihi 64 KB dalam ukuran total. Ukuran konten yang lebih besar, seperti beberapa lampiran besar, mungkin secara signifikan memperlambat performa alur kerja Anda atau bahkan menyebabkan alur kerja Anda macet karena pengecualian di luar memori. Jika alur kerja Anda mungkin harus menangani ukuran konten yang lebih besar, gunakan alur kerja berstatus sebagai gantinya.
Catatan
Dalam alur kerja tanpa status, Anda hanya dapat menggunakan pemicu push di mana Anda tidak menentukan jadwal untuk berjalan untuk 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 Permintaan, Azure Event Hubs, atau Bus Layanan. Untuk informasi selengkapnya tentang pemicu, tindakan, dan konektor yang terbatas, tidak tersedia, atau tidak didukung, lihat Kemampuan yang berubah, 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 berstatus. Sebagai gantinya, semua tindakan berbasis HTTP yang mengembalikan respons "202 DITERIMA" melanjutkan ke langkah berikutnya dalam eksekusi alur kerja. Jika respons menyertakan header
location
, alur kerja tanpa status tidak akan melakukan polling URI yang ditentukan untuk memeriksa status. Untuk mengikuti pola operasi asinkron standar, gunakan alur kerja yang dinyatakan sebagai gantinya.Untuk debugging yang lebih mudah, Anda dapat mengaktifkan riwayat eksekusi untuk alur kerja tanpa status, yang memiliki dampak pada kinerja, 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 stateful dan stateless
Berstatus | Tanpa status |
---|---|
Toko menjalankan sejarah, input, dan output | Tidak menyimpan riwayat, input, atau output yang dijalankan secara default |
Pemicu konektor terkelola tersedia dan diizinkan | Pemicu konektor terkelola tidak tersedia atau tidak diizinkan |
Mendukung pemotongan | Tidak ada dukungan untuk chunking |
Mendukung operasi asinkron | Tidak ada dukungan untuk operasi asinkron |
Edit durasi lari maks default dalam konfigurasi host | Terbaik untuk alur kerja dengan durasi maksimal di bawah 5 menit |
Menangani pesan besar | Terbaik untuk menangani pesan berukuran kecil (di bawah 64 KB) |
Perbedaan perilaku berlapis antara alur kerja berstatus dan tanpa status
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 menjelaskan pola perilaku yang dapat diikuti oleh alur kerja berlapis setelah alur kerja induk memanggil alur kerja turunan:
Pola pemungutan suara asinkron
Alur kerja induk tidak menunggu alur kerja turunan merespons panggilan awal mereka. Namun, induk terus memeriksa riwayat eksekusi turunan hingga turunan selesai berjalan. Secara default, alur kerja berstatus mengikuti pola ini, yang ideal untuk alur kerja anak jangka panjang yang mungkin melebihi batas waktu permintaan.
Pola sinkron ("aktifkan dan lupakan")
Alur kerja turunan mengakui panggilan alur kerja induk dengan segera mengembalikan respons
202 ACCEPTED
. Namun, induk tidak menunggu turunan mengembalikan hasil. Sebaliknya, induk melanjutkan ke tindakan berikutnya dalam alur kerja dan menerima hasil saat turunan selesai berjalan. Alur kerja berstatus milik turunan yang tidak menyertakan tindakan Respons selalu mengikuti pola sinkron dan memberikan riwayat eksekusi untuk Anda tinjau.Untuk mengaktifkan perilaku ini, dalam definisi JSON alur kerja, tetapkan properti
operationOptions
keDisableAsyncPattern
. Untuk informasi selengkapnya, lihat Jenis pemicu dan tindakan - Opsi operasi.Picu dan tunggu
Alur kerja tanpa status berjalan dalam memori. Jadi, saat alur kerja induk memanggil alur kerja tanpa status milik turunan, induk menunggu respons yang mengembalikan hasil dari turunan. Pola ini berfungsi mirip dengan menggunakan pemicu atau tindakan HTTP bawaan untuk memanggil alur kerja turunan. Alur kerja tanpa status anak yang tidak menyertakan tindakan Respons segera mengembalikan respons
202 ACCEPTED
, tetapi induk menunggu anak selesai sebelum melanjutkan ke tindakan berikutnya. Perilaku ini hanya berlaku untuk alur kerja tanpa status anak.
Tabel ini menentukan perilaku alur kerja turunan berdasarkan apakah induk dan turunan berstatus, tanpa status, atau merupakan jenis alur kerja campuran. Daftar setelah tabel
Alur kerja induk | Alur kerja anak | Perilaku anak |
---|---|---|
Berstatus | Berstatus | Asinkron atau sinkron dengan pengaturan "operationOptions": "DisableAsyncPattern" |
Berstatus | Tanpa status | Picu dan tunggu |
Tanpa status | Berstatus | Sinkron |
Tanpa status | Tanpa status | Picu dan tunggu |
Kapabilitas 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 ratusan konektor terkelola untuk aplikasi dan layanan Software-as-a-Service (SaaS) dan Platform-as-a-Service (PaaS) plus konektor untuk sistem lokal.
Lebih banyak konektor terkelola sekarang tersedia sebagai konektor bawaan dalam alur kerja Standar. Versi bawaan berjalan secara native pada runtime Azure Logic Apps penyewa tunggal. Sejumlah konektor bawaan juga dikenal secara formal sebagai konektor penyedia layanan. Untuk memperoleh daftarnya, lihat Konektor bawaan pada Konsumsi dan Standar.
Anda dapat membuat konektor bawaan Anda sendiri untuk layanan apa pun yang dibutuhkan menggunakan kerangka kerja ekstensibilitas Azure Logic Apps penyewa tunggal. Serupa dengan konektor bawaan seperti Azure Service Bus dan SQL Server, konektor ini menyediakan throughput yang lebih tinggi, latensi rendah, konektivitas lokal, serta berjalan secara asli dalam proses yang sama dengan runtime Azure Logic Apps penyewa tunggal. Namun, konektor bawaan kustom tidak serupa dengan konektor terkelola kustom, yang kini tidak didukung. Untuk informasi selengkapnya, tinjau Gambaran umum konektor kustom dan Buat konektor bawaan kustom untuk aplikasi logika Standard dalam Azure Logic Apps penyewa tunggal.
Anda dapat menggunakan tindakan berikut untuk Operasi Liquid dan Operasi XML tanpa akun integrasi. Operasi ini mencakup tindakan berikut:
XML: Transformasi XML dan Validasi XML
Liquid: Transformasi JSON ke JSON, Transformasi JSON ke TEKS, Transformasi XML ke JSON, dan Transformasi XML ke Teks
Catatan
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, di Artefak, yang mencakup bagian Skema dan Maps. Atau, Anda dapat menambahkan artefak ini ke folder Artefak proyek Visual Studio Code menggunakan folder Maps 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 berjalan di mana saja karena Azure Logic Apps menghasilkan Tanda Tangan Akses Bersama (SAS) string koneksi 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.
Catatan
Secara default, identitas yang ditetapkan sistem sudah diaktifkan untuk mengotentikasi 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 saat runtime. Untuk melihat pengaturan ini, pada menu aplikasi logika Anda, di bawah Pengaturan, pilih Identitas.
Anda dapat menjalankan, menguji, dan melakukan penelusuran kesalahan aplikasi logika 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.js 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 secara langsung aplikasi logika dan alur kerjanya secara langsung dari Visual Studio Code ke berbagai lingkungan hosting seperti Azure dan Azure Arc yang diaktifkan Logic Apps.
Aktifkan kemampuan pembuatan log dan penelusuran diagnostik untuk aplikasi logika Anda menggunakan Application Insights jika didukung oleh pengaturan aplikasi logika dan langganan Azure Anda.
Akses kemampuan jaringan, seperti menyambungkan dan mengintegrasikan secara pribadi dengan jaringan virtual Azure, serupa dengan Azure Functions saat Anda membuat dan menyebarkan aplikasi logika menggunakan paket Azure Functions Premium. Untuk informasi selengkapnya, tinjau dokumentasi berikut ini:
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 Standard
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 Bus Layanan, 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 penyewa tunggal, konektor bawaan dengan atribut tertentu secara informal dikenal 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 Standard.
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 Bus Layanan, 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 ini telah berubah, atau 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 Jendela Geser, Azure App Service, dan Azure API Management. Untuk memulai alur kerja dengan atau tanpa status, gunakan pemicu bawaan seperti pemicu Permintaan, Pusat Aktivitas, atau Bus Layanan. Pemicu pengulangan tersedia untuk alur kerja berstatus, bukan alur kerja tanpa status. Di perancang, pemicu dan tindakan bawaan muncul dengan label Dalam Aplikasi , sementara pemicu dan tindakan konektor terkelola muncul dengan label Bersama .
Alur kerja tanpa status hanya dapat menggunakan pemicu pendorongan di mana Anda tidak menentukan jadwal untuk berjalan untuk 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 Permintaan, Azure Event Hubs, atau Bus Layanan. Meskipun Anda dapat mengaktifkan konektor terkelola untuk alur kerja tanpa status, galeri konektor tidak menampilkan pemicu polling konektor terkelola yang ingin Anda tambahkan.
Catatan
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 fungsi Azure sekarang menjadi Operasi Azure Functions - Panggil 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 tindakan fungsi dalam tampilan kode atau file workflow.jspada menggunakan Visual Studio Code, tindakan ini merujuk ke fungsi menggunakan referensi
connectionName
. Versi ini mengabstraksi informasi fungsi sebagai koneksi, yang dapat Anda temukan di file connections.js proyek aplikasi logis Anda, yang tersedia setelah Anda membuat koneksi di Visual Studio Code.Catatan
Dalam versi penyewa tunggal, tindakan fungsi hanya mendukung autentikasi string kueri. Pratinjau Azure Logic Apps mendapatkan kunci default dari fungsi saat membuat koneksi, menyimpan kunci itu di pengaturan aplikasi Anda, dan menggunakan kunci untuk autentikasi saat memanggil fungsi.
Seperti dalam model multipenyewa, jika Anda memperbarui kunci ini, misalnya, melalui pengalaman Azure Functions di portal, tindakan 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.
Nama tindakan Inline Code bawaan diganti menjadi Inline Code Operations, yang tidak lagi memerlukan akun integrasi, dan telah memperbarui batas.
Tindakan bawaan, Azure Logic Apps - Memilih alur kerja Logic Apps sekarang menjadi Operasi Alur Kerja - Memanggil alur kerja di aplikasi alur kerja ini.
Konektor Gmail saat ini tidak didukung.
Konektor kustom terkelola saat ini tidak didukung. Namun, Anda dapat membuat operasi bawaan kustom saat menggunakan Visual Studio Code. Untuk informasi selengkapnya, lihat Membuat alur kerja berbasis penyewa tunggal menggunakan Visual Studio Code.
Alur kerja aplikasi logika Standar hanya dapat memiliki satu pemicu dan tidak mendukung beberapa pemicu.
Autentikasi: Jenis autentikasi berikut saat ini tidak tersedia untuk alur kerja Standar :
Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth) untuk panggilan masuk ke pemicu berbasis permintaan, seperti pemicu Permintaan dan pemicu HTTP Webhook.
Autentikasi identitas terkelola: Dukungan identitas terkelola yang ditetapkan sistem dan ditetapkan pengguna tersedia. Secara default, identitas terkelola yang ditetapkan sistem diaktifkan secara otomatis. Namun, sebagian besar konektor berbasis penyedia layanan bawaan saat ini tidak mendukung pemilihan identitas terkelola yang ditetapkan pengguna untuk autentikasi.
Transformasi XML: Hanya XSLT 1.0 yang saat ini didukung.
Penelusuran kesalahan titik henti di Visual Studio Code: Meskipun Anda dapat menambahkan dan menggunakan titik henti di dalam file workflow.js untuk alur kerja, titik henti saat ini 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 aplikasi logika Standar, riwayat pemicu dan riwayat eksekusi di portal Azure muncul di tingkat alur kerja, bukan tingkat sumber daya aplikasi logika. Untuk informasi selengkapnya, lihat Membuat alur kerja berbasis penyewa tunggal menggunakan portal Microsoft Azure.
Pencadangan dan pemulihan untuk riwayat eksekusi alur kerja: Aplikasi logika standar saat ini tidak mendukung pencadangan dan pemulihan untuk riwayat eksekusi alur kerja.
Templat terraform: Anda tidak dapat menggunakan templat ini dengan sumber daya aplikasi logika Standar untuk penyebaran infrastruktur lengkap. Untuk informasi selengkapnya, lihat Apa itu Terraform di Azure?
Azure API Management: Saat ini Anda tidak dapat mengimpor sumber daya aplikasi logika Standar ke Azure API Management. Namun, Anda dapat mengimpor sumber daya aplikasi logika Konsumsi .
Izin lalu lintas jaringan dan firewall yang ketat
Apabila lingkungan Anda mempunyai persyaratan jaringan atau firewall ketat yang membatasi lalu lintas, Anda harus mengizinkan akses untuk setiap pemicu atau koneksi tindakan di alur kerja aplikasi logika Anda. Anda bisa mengizinkan lalu lintas dari tag layanan dan menggunakan tingkat pembatasan atau kebijakan yang sama seperti 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:
- Izin firewall untuk aplikasi logika penyewa tunggal - portal Microsoft Azure
- Izin firewall untuk aplikasi logika penyewa tunggal - Visual Studio Code
Langkah berikutnya
- Buat alur kerja berbasis penyewa tunggal di portal Microsoft Azure
- Buat alur kerja berbasis penyewa tunggal di Visual Studio Code
Kami ingin mendengar tentang pengalaman Anda dengan Azure Logic Apps penyewa tunggal!
- Untuk bug atau masalah, buat masalah Anda di GitHub.
- Jika ada pertanyaan, permintaan, komentar, dan umpan balik lainnya, gunakan formulir umpan balik ini.