Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Durable Functions memiliki beberapa fitur yang memudahkan untuk menggabungkan orkestrasi dan entitas yang tahan lama ke dalam alur kerja HTTP. Artikel ini menjelaskan rinci tentang beberapa fitur tersebut.
Mengekspos API HTTP
Orkestrasi dan entitas dapat dipanggil dan dikelola menggunakan permintaan HTTP. Ekstensi Durable Functions mengekspos API HTTP bawaan. Ekstensi ini juga menyediakan API untuk berinteraksi dengan orkestrasi dan entitas dari dalam fungsi yang dipicu oleh HTTP.
API HTTP bawaan
Ekstensi Durable Functions secara otomatis menambahkan sekumpulan API HTTP ke host Azure Functions. Dengan API ini, Anda dapat berinteraksi dengan serta mengelola orkestrasi dan entitas tanpa menulis kode.
API HTTP bawaan berikut didukung.
- Memulai orkestrasi baru
- Instans orkestrasi kueri
- Mengakhiri instance orkestrasi
- Mengirim peristiwa eksternal ke orkestrasi
- Menghapus menyeluruh riwayat orkestrasi
- Mengirim peristiwa operasi ke entitas
- Mendapatkan status entitas
- Mengkueri daftar entitas
Lihat artikel HTTP API untuk deskripsi lengkap tentang semua API HTTP bawaan yang diekspos oleh ekstensi Durable Functions.
Penemuan URL API HTTP
Binding klien orkestrasi mengekspose API yang dapat menghasilkan payload respons HTTP yang lebih memudahkan. Contohnya, ini dapat membuat respons yang memuat tautan ke API manajemen untuk instans orkestrasi tertentu. Contoh berikut menunjukkan fungsi pemicu HTTP yang menunjukkan cara menggunakan API untuk instans orkestrasi baru:
Tip
Jika Anda memiliki beberapa fungsi starter yang dipicu HTTP di aplikasi fungsi yang sama, konfigurasikan yang unik route untuk setiap fungsi untuk menghindari konflik rute. Menggunakan rute berparameter seperti orchestrators/{functionName} (seperti yang ditunjukkan dalam beberapa contoh sebelumnya) memungkinkan satu fungsi starter HTTP memulai orkestrator apa pun berdasarkan nama, yang seringkali merupakan pendekatan paling sederhana.
Memulai fungsi orkestrator dengan menggunakan fungsi pemicu HTTP yang ditunjukkan sebelumnya dapat dilakukan menggunakan klien HTTP. Perintah cURL berikut memulai fungsi orkestrator bernama DoWork:
curl -X POST https://localhost:7071/orchestrators/DoWork -H "Content-Length: 0" -i
Selanjutnya adalah contoh respons untuk orkestrasi yang memiliki abc123 sebagai ID-nya. Beberapa detail telah dihapus karena kejelasan.
HTTP/1.1 202 Accepted
Content-Type: application/json; charset=utf-8
Location: http://localhost:7071/runtime/webhooks/durabletask/instances/abc123?code=XXX
Retry-After: 10
{
"id": "abc123",
"purgeHistoryDeleteUri": "http://localhost:7071/runtime/webhooks/durabletask/instances/abc123?code=XXX",
"sendEventPostUri": "http://localhost:7071/runtime/webhooks/durabletask/instances/abc123/raiseEvent/{eventName}?code=XXX",
"statusQueryGetUri": "http://localhost:7071/runtime/webhooks/durabletask/instances/abc123?code=XXX",
"terminatePostUri": "http://localhost:7071/runtime/webhooks/durabletask/instances/abc123/terminate?reason={text}&code=XXX"
}
Dalam contoh sebelumnya, setiap bidang yang berakhiran Uri sesuai dengan API HTTP bawaan. Anda dapat menggunakan API ini untuk mengelola instans orkestrasi target.
Note
Format URL webhook bergantung pada versi host Azure Functions yang Anda jalankan. Contoh sebelumnya adalah untuk host Azure Functions 2.0.
Untuk deskripsi semua API HTTP bawaan, lihat referensi API HTTP.
Pelacakan operasi asinkron
Respons HTTP yang disebutkan sebelumnya dirancang untuk membantu menerapkan API asinkron HTTP yang berjalan lama dengan Durable Functions. Pola ini terkadang disebut sebagai pola konsumen polling. Alur klien/server berfungsi sebagai berikut:
- Klien mengeluarkan permintaan HTTP untuk memulai proses yang berjalan lama seperti fungsi orkestrator.
- Pemicu HTTP target mengembalikan respons HTTP 202 dengan header Lokasi yang memiliki nilai "statusQueryGetUri".
- Client melakukan polling URL pada Location header. Klien terus melihat respons HTTP 202 dengan header Lokasi.
- Ketika instans selesai atau gagal, titik akhir di header Lokasi mengembalikan HTTP 200.
Protokol ini memungkinkan koordinasi proses yang memakan waktu lama dengan klien eksternal atau layanan yang dapat melakukan polling endpoint HTTP dan mengikuti header 'lokasi'. Implementasi klien dan server dari pola ini dibangun ke dalam API HTTP Durable Functions.
Note
Secara default, semua tindakan berbasis HTTP yang disediakan oleh Azure Logic Apps mendukung pola operasi asinkron standar. Kemampuan ini memungkinkan penyematan fungsi yang tahan lama dan dapat berjalan dalam jangka panjang sebagai bagian dari alur kerja Azure Logic Apps. Anda dapat menemukan detail selengkapnya tentang dukungan Logic Apps untuk pola HTTP asinkron di dokumentasi tindakan dan pemicu alur kerja Azure Logic Apps.
Note
Interaksi dengan orkestrasi dapat dilakukan dari jenis fungsi apa pun, bukan hanya fungsi yang dipicu HTTP.
Untuk informasi selengkapnya tentang cara mengelola orkestrasi dan entitas menggunakan API klien, lihat artikel Manajemen instans.
Memanfaatkan API HTTP
Seperti yang dijelaskan dalam batasan kode orkestrator, fungsi orkestrator tidak dapat melakukan I/O secara langsung. Sebaliknya, mereka biasanya memanggil aktivitas yang melakukan operasi I/O.
Dimulai dengan Durable Functions 2.0, orkestrasi dapat secara langsung mengkonsumsi API HTTP dengan menggunakan pemicu pengikatan orchestration.
Contoh kode berikut menunjukkan fungsi orkestrator yang mengirimkan permintaan HTTP ke luar.
[FunctionName(nameof(CheckSiteAvailable))]
public static async Task CheckSiteAvailable(
[OrchestrationTrigger] IDurableOrchestrationContext context)
{
Uri url = context.GetInput<Uri>();
// Makes an HTTP GET request to the specified endpoint
DurableHttpResponse response =
await context.CallHttpAsync(HttpMethod.Get, url);
if (response.StatusCode >= 400)
{
// handling of error codes goes here
}
}
Note
Anda mungkin bertanya-tanya mengapa fitur ini menggunakan DurableHttpRequest dan DurableHttpResponse sebagai gantinya dari .NET HttpRequestMessage bawaan dan HttpResponseMessage.
Pilihan desain ini disengaja. Alasan utamanya adalah bahwa jenis kustom membantu memastikan pengguna tidak membuat asumsi salah tentang perilaku yang didukung dari klien HTTP internal. Jenis khusus untuk Durable Functions juga memungkinkan untuk menyederhanakan desain API. Mereka juga dapat dengan lebih mudah membuat fitur khusus yang tersedia seperti integrasi identitas terkelola dan pola konsumen polling.
Dengan menggunakan tindakan “panggil HTTP”, Anda dapat melakukan tindakan berikut dalam fungsi orkestrator:
- Panggil API HTTP langsung dari fungsi orkestrasi, dengan beberapa batasan yang disebutkan kemudian.
- Mendukung secara otomatis pola pencarian status HTTP 202 di sisi klien.
- Gunakan Azure Identitas Terkelola untuk melakukan panggilan HTTP resmi ke titik akhir Azure lainnya.
Kemampuan untuk menggunakan API HTTP langsung dari fungsi orkestrator dimaksudkan sebagai kenyamanan untuk serangkaian skenario umum tertentu. Anda dapat menerapkan semua fitur ini sendiri menggunakan fungsi aktivitas. Dalam banyak kasus, fungsi aktivitas dapat memberikan lebih banyak fleksibilitas kepada Anda.
Penanganan HTTP 202 (.NET saja)
API "panggil HTTP" dapat secara otomatis mengimplementasikan pola konsumen polling pada sisi klien. Jika API yang dipanggil mengembalikan respons HTTP 202 dengan header Location, fungsi orkestrator secara otomatis memeriksa resource pada header Location hingga menerima respons selain dari 202. Respons ini akan menjadi respons yang dikembalikan ke kode fungsi orkestrator.
[FunctionName(nameof(CheckSiteAvailabilityWithPolling))]
public static async Task CheckSiteAvailabilityWithPolling(
[OrchestrationTrigger] IDurableOrchestrationContext context)
{
Uri url = context.GetInput<Uri>();
// HTTP automatic polling on 202 response is enabled by default in .NET in-process.
DurableHttpResponse response =
await context.CallHttpAsync(HttpMethod.Get, url);
}
Note
- Fungsi orkestrator juga secara asli mendukung pola konsumen polling sisi server, seperti yang dijelaskan dalam pelacakan operasi Asinkron. Dukungan ini berarti bahwa orkestrasi dalam satu aplikasi fungsi dapat mudah mengoordinasikan fungsi orkestrator di aplikasi fungsi lain. Ini mirip dengan konsep sub-orkestrasi , tetapi dengan dukungan untuk komunikasi lintas aplikasi. Dukungan ini sangat berguna untuk pengembangan aplikasi bergaya microservice.
- Pola polling HTTP bawaan saat ini hanya tersedia di host .NET.
- Pola polling diaktifkan secara default dalam .NET in-process tetapi dinonaktifkan secara default di .NET Isolated. Jika Anda ingin mengaktifkannya di .NET Terisolasi, lihat kode sampel dan atur argumen asinkronousPatternEnabled ke true.
- Pola polling otomatis HTTP didukung di Durable Functions .NET Isolated mulai dari versi v1.5.0 atau yang lebih baru.
Identitas yang dikelola
Durable Functions secara asli mendukung panggilan ke API yang menerima token Microsoft Entra untuk otorisasi. Dukungan ini menggunakan identitas terkelola Azure untuk memperoleh token ini.
Kode berikut adalah contoh fungsi orkestrator. Fungsi ini melakukan panggilan terautentikasi untuk memulai ulang mesin virtual dengan menggunakan Azure Resource Manager virtual machines REST API.
[FunctionName("RestartVm")]
public static async Task RunOrchestrator(
[OrchestrationTrigger] IDurableOrchestrationContext context)
{
string subscriptionId = "mySubId";
string resourceGroup = "myRG";
string vmName = "myVM";
string apiVersion = "2019-03-01";
// Automatically fetches an Azure AD token for resource = https://management.core.windows.net/.default
// and attaches it to the outgoing Azure Resource Manager API call.
var restartRequest = new DurableHttpRequest(
HttpMethod.Post,
new Uri($"https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}/providers/Microsoft.Compute/virtualMachines/{vmName}/restart?api-version={apiVersion}"),
tokenSource: new ManagedIdentityTokenSource("https://management.core.windows.net/.default"));
DurableHttpResponse restartResponse = await context.CallHttpAsync(restartRequest);
if (restartResponse.StatusCode != HttpStatusCode.OK)
{
throw new ArgumentException($"Failed to restart VM: {restartResponse.StatusCode}: {restartResponse.Content}");
}
}
Dalam contoh sebelumnya, parameter tokenSource dikonfigurasi untuk memperoleh token Microsoft Entra untuk Azure Resource Manager. Token diidentifikasi melalui URI sumber daya https://management.core.windows.net/.default. Contohnya mengasumsikan bahwa aplikasi fungsi saat ini berjalan secara lokal atau disebarkan sebagai aplikasi fungsi dengan identitas terkelola. Identitas lokal atau identitas terkelola diasumsikan memiliki izin untuk mengelola VM dalam grup myRGsumber daya yang ditentukan .
Pada runtime, sumber token yang dikonfigurasi secara otomatis mengembalikan token akses OAuth 2.0. Sumber kemudian menambahkan token sebagai token "bearer" ke header Autorisasi dari permintaan yang keluar. Model ini adalah peningkatan untuk menambahkan header otorisasi secara manual ke permintaan HTTP karena alasan berikut:
- Refresh token ditangani secara otomatis. Anda tidak perlu khawatir tentang token yang kedaluwarsa.
- Token tidak pernah disimpan dalam keadaan orkestrasi yang stabil dan tahan lama.
- Anda tidak perlu menulis kode untuk mengelola akuisisi token.
Anda dapat menemukan contoh yang lebih lengkap dalam sampel C# RestartVMs precompiled.
Identitas terkelola tidak terbatas pada manajemen sumber daya Azure. Anda dapat menggunakan identitas terkelola untuk mengakses API apa pun yang menerima token pembawa Microsoft Entra, termasuk layanan Azure dari Microsoft dan aplikasi web dari mitra. Aplikasi web mitra bahkan dapat menjadi aplikasi fungsi lain. Untuk daftar layanan Azure dari Microsoft yang mendukung autentikasi dengan Microsoft Entra ID, lihat layanan Azure yang mendukung autentikasi Microsoft Entra.
Keterbatasan
Dukungan bawaan untuk memanggil API HTTP adalah fitur yang nyaman. Tidak cocok untuk semua skenario.
Permintaan HTTP yang dikirim oleh fungsi orkestrator dan responsnya diserialisasikan dan disimpan sebagai pesan di penyedia penyimpanan Durable Functions. Perilaku antrean persisten ini memastikan panggilan HTTP dapat diandalkan dan aman untuk pemutaran ulang orkestrasi. Namun, perilaku mengantrekan persisten juga memiliki keterbatasan:
- Setiap permintaan HTTP melibatkan latensi tambahan jika dibandingkan dengan klien HTTP asli.
- Bergantung pada penyedia penyimpanan yang dikonfigurasi, pesan permintaan atau respons besar dapat secara signifikan menurunkan performa orkestrasi. Misalnya, saat menggunakan Azure Storage, payload HTTP yang terlalu besar untuk dimasukkan ke dalam pesan dalam Azure Queue dikompresi dan disimpan dalam Azure Blob Storage.
- Aliran, berbentuk potongan, dan payload biner tidak didukung.
- Kemampuan untuk menyesuaikan perilaku klien HTTP terbatas.
Jika salah satu batasan ini dapat memengaruhi kasus penggunaan Anda, pertimbangkan untuk menggunakan fungsi aktivitas dan pustaka klien HTTP khusus bahasa untuk melakukan panggilan HTTP keluar.
Ekstensibilitas (hanya .NET dalam proses)
Menyesuaikan perilaku klien HTTP internal orkestrasi dimungkinkan menggunakan injeksi dependensi Azure Functions .NET untuk pekerja dalam proses. Kemampuan ini dapat berguna untuk membuat perubahan perilaku kecil. Hal ini juga dapat berguna untuk pengujian unit klien HTTP dengan menyuntikkan objek tiruan.
Contoh berikut menunjukkan menggunakan injeksi dependensi untuk menonaktifkan validasi sertifikat TLS/SSL untuk fungsi orkestrator yang memanggil titik akhir HTTP eksternal.
public class Startup : FunctionsStartup
{
public override void Configure(IFunctionsHostBuilder builder)
{
// Register own factory
builder.Services.AddSingleton<
IDurableHttpMessageHandlerFactory,
MyDurableHttpMessageHandlerFactory>();
}
}
public class MyDurableHttpMessageHandlerFactory : IDurableHttpMessageHandlerFactory
{
public HttpMessageHandler CreateHttpMessageHandler()
{
// Disable TLS/SSL certificate validation (not recommended in production!)
return new HttpClientHandler
{
ServerCertificateCustomValidationCallback =
HttpClientHandler.DangerousAcceptAnyServerCertificateValidator,
};
}
}