Hub tugas dalam Fungsi Tahan Lama (Azure Functions)

Artikel
05/05/2023

Hub tugas di Durable Functions adalah representasi status aplikasi saat ini dalam penyimpanan, termasuk semua pekerjaan yang tertunda. Saat aplikasi fungsi berjalan, kemajuan fungsi orkestrasi, aktivitas, serta entitasnya terus disimpan di hub tugas. Akibatnya, dapat dipastikan bahwa aplikasi dapat melanjutkan pemrosesan terakhir sebelum berhenti jika aplikasi perlu dihidupkan ulang setelah dihentikan sementara atau terganggu karena beberapa alasan. Selain itu, disimpannya kemajuan tersebut bertujuan agar aplikasi fungsi dapat menskalakan pekerja komputasi secara dinamis.

Diagram yang menunjukkan konsep aplikasi fungsi dan konsep hub tugas.

Secara konseptual, hub tugas menyimpan informasi berikut:

Status instans semua instans orkestrasi dan entitas.
Pesan yang akan diproses, termasuk
- setiap pesan aktivitas yang merupakan aktivitas yang menunggu untuk dijalankan.
- setiap pesan instans yang menunggu untuk dikirimkan ke instans.

Perbedaan antara pesan aktivitas dan instans adalah bahwa pesan aktivitas tidak memiliki status (stateless) sehingga dapat diproses di mana saja, sementara pesan instans perlu dikirimkan ke instans berstatus (stateful) tertentu (orkestrasi atau entitas), yang diidentifikasi oleh ID instansnya.

Secara internal, setiap penyedia penyimpanan dapat menggunakan organisasi yang berbeda untuk mewakili status dan pesan instans. Sebagai contohnya, pesan disimpan di Azure Storage Queues oleh penyedia Azure Storage, tetapi dalam tabel relasional, pesan disimpan oleh penyedia MSSQL. Perbedaan ini tidak masalah jika kaitannya adalah dengan desain aplikasi, tetapi perbedaan yang lainnya mungkin dapat memengaruhi karakteristik performa. Kami membahasnya di bagian Representasi dalam penyimpanan di bawah ini.

Item pekerjaan

Pesan aktivitas dan pesan instans di hub tugas mewakili pekerjaan yang harus diproses oleh aplikasi fungsi. Saat aplikasi fungsi berjalan, aplikasi tersebut terus mengambil item kerja dari hub tugas. Setiap item kerja memproses satu atau beberapa pesan. Kami membedakan dua jenis item kerja:

Item kerja aktivitas: Menjalankan fungsi aktivitas untuk memproses pesan aktivitas.
Item kerja orkestrator: Menjlankan orkestrator atau fungsi entitas untuk memproses satu atau beberapa pesan instans.

Pekerja dapat memproses beberapa item kerja secara bersamaan sesuai dengan konfigurasi batas konkurensi per pekerja.

Setelah pekerja menyelesaikan item kerja, pekerja tersebut akan menerapkan efek kembali ke hub tugas. Efek ini bervariasi menurut jenis fungsi yang dijalankan:

Fungsi aktivitas yang telah selesai membuat pesan instans berisi hasil yang ditujukan kepada instans orkestrator induk.
Fungsi orkestrator yang telah selesai memperbarui status dan riwayat orkestrasi, serta dapat membuat pesan baru.
Fungsi entitas yang telah selesai memperbarui status entitas, dan juga dapat membuat pesan instans baru.

Untuk orkestrasi, setiap item kerja mewakili satu episode eksekusi orkestrasi tersebut. Episode dimulai ketika ada pesan baru yang akan diproses oleh orkestrator. Pesan seperti itu dapat menunjukkan bahwa orkestrasi harus dimulai, atau mungkin menunjukkan bahwa aktivitas, panggilan entitas, timer, atau suborkestrasi telah selesai atau, bisa saja mewakili kejadian eksternal. Pesan memicu item kerja, sehingga orkestrator dapat memproses hasilnya dan melanjutkan episode berikutnya. Episode tersebut berakhir ketika orkestrator selesai atau mencapai titik saat orkestrator harus menunggu pesan baru.

Contoh eksekusi

Pertimbangkan orkestrasi fan-out-fan-in yang memulai dua aktivitas secara paralel, dan menunggu hingga keduanya selesai:

[FunctionName("Example")]
public static async Task Run([OrchestrationTrigger] IDurableOrchestrationContext context)
{
    Task t1 = context.CallActivityAsync<int>("MyActivity", 1);
    Task t2 = context.CallActivityAsync<int>("MyActivity", 2);
    await Task.WhenAll(t1, t2);
}

module.exports = df.orchestrator(function*(context){
    const tasks = [];
    tasks.push(context.df.callActivity("MyActivity", 1));
    tasks.push(context.df.callActivity("MyActivity", 2));
    yield context.df.Task.all(tasks);
});

def orchestrator_function(context: df.DurableOrchestrationContext):
    tasks = []
    tasks.append(context.call_activity("MyActivity", 1))
    tasks.append(context.call_activity("MyActivity", 2))
    yield context.task_all(tasks)

param($Context)

$Tasks = @()

$Tasks += Invoke-DurableActivity -FunctionName 'MyActivity' -Input 1 -NoWait
$Tasks += Invoke-DurableActivity -FunctionName 'MyActivity' -Input 2 -NoWait

Wait-DurableTask -Task $Tasks

@FunctionName("Example")
public void exampleOrchestrator(
        @DurableOrchestrationTrigger(name = "ctx") TaskOrchestrationContext ctx) {
    Task<Void> t1 = ctx.callActivity("MyActivity", 1);
    Task<Void> t2 = ctx.callActivity("MyActivity", 2);
    ctx.allOf(List.of(t1, t2)).await();
}

Setelah orkestrasi ini dimulai oleh klien, orkestrasi ini diproses oleh aplikasi fungsi sebagai urutan item kerja. Setiap item kerja yang selesai memperbarui status hub tugas saat menerapkan. Berikut langkah-langkahnya:

Klien meminta untuk memulai orkestrasi baru dengan instance-id "123". Setelah klien menyelesaikan permintaan ini, hub tugas berisi tempat penampung untuk status orkestrasi dan pesan instans:

Label ExecutionStarted adalah salah satu dari banyak jenis kejadian riwayat yang mengidentifikasi berbagai jenis pesan dan kejadian yang berpartisipasi dalam riwayat orkestrasi.
Pekerja menjalankan item kerja orkestrator untuk memproses pesan ExecutionStarted. Pekerja ini memanggil fungsi orkestrator yang mulai menjalankan kode orkestrasi. Kode ini menjadwalkan dua aktivitas dan kemudian berhenti menjalankan saat menunggu hasilnya. Setelah pekerja menerapkan item kerja ini, hub tugas akan berisi

Status runtime bahasa umum sekarang Running, dua pesan TaskScheduled baru ditambahkan, dan riwayat sekarang berisi lima kejadian OrchestratorStarted, ExecutionStarted, TaskScheduled, TaskScheduled, OrchestratorCompleted. Kejadian ini mewakili episode pertama dari eksekusi orkestrasi ini.
Pekerja menjalankan item kerja aktivitas untuk memproses salah satu pesan TaskScheduled. Pekerja memanggil fungsi aktivitas dengan input "2". Ketika fungsi aktivitas selesai, fungsi tersebut akan membuat TaskCompleted pesan yang berisi hasilnya. Setelah pekerja menerapkan item kerja ini, hub tugas akan berisi
Pekerja menjalankan item kerja orkestrator untuk memproses pesan TaskCompleted. Jika orkestrasi masih di-cache dalam memori, orkestrasi dapat melanjutkan eksekusi. Jika tidak, pertama, pekerja akan memutar ulang riwayat untuk memulihkan status orkestrasi saat ini. Kemudian melanjutkan orkestrasi lalu memberikan hasil aktivitas. Setelah menerima hasil ini, orkestrasi masih menunggu hasil aktivitas yang lain, sehingga sekali lagi menghentikan proses eksekusi. Setelah pekerja menerapkan item kerja ini, hub tugas akan berisi

Riwayat orkestrasi sekarang berisi tiga kejadian OrchestratorStarted, TaskCompleted, OrchestratorCompleted. Kejadian ini mewakili episode kedua dari eksekusi orkestrasi ini.
Pekerja menjalankan item kerja aktivitas untuk memproses pesan TaskScheduled yang tersisa. Pekerja memanggil fungsi aktivitas dengan input "1". Setelah pekerja menerapkan item kerja ini, hub tugas akan berisi
Pekerja menjalankan item kerja orkestrator lain untuk memproses pesan TaskCompleted. Setelah menerima hasil kedua ini, orkestrasi selesai. Setelah pekerja menerapkan item kerja ini, hub tugas akan berisi

Status runtime bahasa umum sekarang adalah Completed, dan riwayat orkestrasi sekarang berisi empat kejadian OrchestratorStarted, TaskCompleted, ExecutionCompleted, OrchestratorCompleted. Kejadian ini mewakili episode ketiga dan merupakan episode terakhir dari eksekusi orkestrasi ini.

Riwayat akhir eksekusi orkestrasi ini kemudian berisi 12 kejadian OrchestratorStarted, ExecutionStarted, TaskScheduled, TaskScheduled, OrchestratorCompleted, OrchestratorStarted, TaskCompleted, OrchestratorCompleted, OrchestratorStarted, TaskCompleted, ExecutionCompleted, OrchestratorCompleted.

Catatan

Jadwal yang ditampilkan bukanlah satu-satunya jadwal karena ada banyak kemungkinan jadwal yang sedikit berbeda. Sebagai contohnya, jika aktivitas kedua selesai lebih awal, kedua pesan instans TaskCompleted dapat diproses oleh satu item kerja. Dalam hal ini, riwayat eksekusi sedikit lebih pendek karena hanya ada dua episode yang berisi 10 kejadian berikut: OrchestratorStarted, ExecutionStarted, TaskScheduled, TaskScheduled, OrchestratorCompleted, OrchestratorStarted, TaskCompleted, TaskCompleted, ExecutionCompleted, OrchestratorCompleted.

Manajemen hub tugas

Selanjutnya, mari kita lihat lebih dekat mengenai bagaimana hub tugas dibuat atau dihapus, cara menggunakan hub tugas dengan benar saat menjalankan beberapa aplikasi fungsi, serta bagaimana konten hub tugas dapat diperiksa.

Pembuatan dan penghapusan

Hub tugas kosong dengan semua sumber daya yang diperlukan dibuat secara otomatis di penyimpanan saat aplikasi fungsi dimulai pertama kali.

Jika Anda menggunakan penyedia Azure Storage default, Anda tidak memerlukan konfigurasi tambahan. Jika tidak, ikuti instruksi untuk mengonfigurasi penyedia penyimpanan untuk memastikan bahwa penyedia penyimpanan dapat menyediakan dan mengakses sumber daya penyimpanan yang diperlukan untuk hub tugas dengan benar.

Catatan

Hub tugas tidak dihapus secara otomatis saat Anda menghentikan atau menghapus aplikasi fungsi. Anda harus menghapus hub tugas, kontennya, atau akun penyimpanan tempat hub tugas secara manual jika Anda tidak lagi berniat menyimpan data tersebut.

Tip

Dalam skenario pengembangan, Anda mungkin perlu sering menghidupkan ulang dari keadaan yang bersih. Untuk melakukannya dengan cepat, Anda cukup mengubah nama hub tugas yang dikonfigurasi. Tindakan ini akan memaksa pembuatan hub tugas baru yang kosong saat Anda menghidupkan ulang aplikasi. Pahamilah bahwa data lama tidak dihapus dalam kasus ini.

Beberapa aplikasi fungsi

Jika beberapa aplikasi fungsi berbagi akun penyimpanan, setiap aplikasi fungsi harus dikonfigurasi dengan nama hub tugas terpisah. Persyaratan ini juga berlaku untuk slot penahapan: setiap slot penahapan harus dikonfigurasi menggunakan nama hub tugas yang unik. Satu akun penyimpanan bisa memuat beberapa hub tugas. Pembatasan ini umumnya berlaku untuk penyedia penyimpanan lain juga.

Diagram berikut mengilustrasikan satu aplikasi hub tugas per aplikasi fungsi di akun penyimpanan Azure Storage bersama dan khusus.

Diagram memperlihatkan akun penyimpanan bersama dan khusus.

Catatan

Pengecualian untuk aturan berbagi hub tugas adalah jika Anda mengonfigurasi aplikasi untuk pemulihan bencana regional. Lihat artikel pemulihan bencana dan distribusi geografis untuk informasi lebih lanjut.

Pemeriksaan konten

Ada beberapa cara umum untuk memeriksa konten hub tugas:

Dalam aplikasi fungsi, objek klien menyediakan metode untuk mengkueri penyimpanan instans. Untuk mempelajari lebih lanjut jenis kueri yang didukung, lihat artikel Manajemen Instans.
Demikian pula, API HTTP menawarkan permintaan REST untuk mengkueri status orkestrasi dan entitas. Lihat Referensi API HTTP yang berisi detail lebih lanjut.
Alat Durable Functions Monitor dapat memeriksa hub tugas serta menawarkan berbagai opsi tampilan visual.

Untuk beberapa penyedia penyimpanan, alat tersebut juga dapat digunakan untuk memeriksa hub tugas dengan langsung masuk ke penyimpanan yang mendasar:

Jika menggunakan penyedia Azure Storage, status instans disimpan di Tabel Instans dan Tabel Riwayat yang dapat diperiksa dengan menggunakan alat seperti Azure Storage Explorer.
Jika menggunakan penyedia penyimpanan MSSQL, kueri dan alat SQL dapat digunakan untuk memeriksa konten hub tugas di dalam database.

Representasi dalam penyimpanan

Setiap penyedia penyimpanan menggunakan organisasi internal yang berbeda untuk mewakili hub tugas dalam penyimpanan. Meskipun Anda tidak perlu memahami organisasi ini, pemahaman akan organisasi akan membantu memecahkan masalah terkait aplikasi fungsi atau saat Anda mencoba memastikan target performa, skalabilitas, atau biaya. Demikianlah penjelasan singkat kami terkait penyedia penyimpanan dan cara data diatur dalam penyimpanan. Untuk informasi lebih lanjut mengenai berbagai opsi penyedia penyimpanan dan bagaimana perbandingannya, lihat Penyedia penyimpanan Durable Functions.

Penyedia Microsoft Azure Storage

Penyedia Azure Storage mewakili hub tugas dalam penyimpanan dengan menggunakan komponen berikut:

Dua Tabel Azure menyimpan status instans.
Satu Azure Queue menyimpan pesan aktivitas.
Satu atau beberapa Azure Queue menyimpan pesan instans. Setiap antrean kontrol ini mewakili partisi dengan subset dari semua pesan instans berdasarkan hash ID instans yang ditetapkan.
Beberapa kontainer blob tambahan yang digunakan untuk menyewa blob dan/atau pesan berukuran besar.

Sebagai contohnya, hub tugas bernama xyz dengan PartitionCount = 4 berisi antrean dan tabel berikut:

Diagram yang menunjukkan organisasi penyimpanan penyedia Azure Storage untuk 4 antrean kontrol.

Berikutnya, kami akan menjelaskan komponen-komponen ini sekaligus dengan perannya secara lebih rinci.

Untuk informasi lebih lanjut mengenai bagaimana hub tugas diwakili oleh penyedia Azure Storage, lihat dokumentasi penyedia Azure Storage.

Penyedia penyimpanan Netherite

Netherite mempartisi semua status hub tugas ke sejumlah partisi tertentu. Di penyimpanan, sumber daya berikut digunakan:

Satu kontainer blob Azure Storage yang berisi semua blob dan dikelompokkan menurut partisinya.
Satu Tabel Azure yang berisi metrik yang diterbitkan terkait partisi.
Namespace layanan Azure Event Hubs untuk mengirimkan pesan antar partisi.

Sebagai contohnya, hub tugas bernama mytaskhub dengan PartitionCount = 32 diwakili dalam penyimpanan sebagai berikut:

Diagram yang menunjukkan organisasi penyimpanan Netherite untuk 32 partisi.

Catatan

Semua status hub tugas disimpan di dalam kontainer blob x-storage. Tabel DurableTaskPartitions dan namespace layanan EventHubs berisi data yang redundan karena jika kontennya hilang, data tersebut dapat dipulihkan secara otomatis. Oleh karena itu, Anda tidak perlu mengonfigurasi namespace layanan Azure Event Hubs untuk menyimpan pesan setelah melewati waktu kedaluwarsa default.

Netherite menggunakan mekanisme sumber kejadian yang berdasarkan log dan titik pemeriksaan untuk mewakili status partisi saat ini. Blob blok dan blob halaman digunakan. Membaca format ini dari penyimpanan secara langsung tidak mungkin dilakukan, sehingga aplikasi fungsi harus berjalan saat mengkueri penyimpanan instans.

Untuk informasi lebih lanjut mengenai hub tugas untuk penyedia penyimpanan Netherite, lihat Informasi Hub Tugas untuk penyedia penyimpanan Netherite.

Penyedia penyimpanan MSSQL

Semua data hub tugas disimpan dalam satu database hubungan dan menggunakan beberapa tabel:

Tabeldt.Instances dan dt.History menyimpan status instans.
Tabel dt.NewEvents menyimpan pesan instans.
Tabel dt.NewTasksmenyimpan pesan aktivitas.

Diagram yang menunjukkan organisasi penyimpanan MSSQL.

Untuk mengaktifkan beberapa hub tugas agar berdampingan secara independen dalam database yang sama, setiap tabel akan menyertakan kolom TaskHub sebagai bagian dari kunci primernya. Tidak seperti dua penyedia lainnya, penyedia MSSQL tidak memiliki konsep partisi.

Untuk informasi lebih lanjut mengenai hub tugas untuk penyedia penyimpanan MSSQL, lihat Informasi Hub Tugas untuk penyedia penyimpanan Microsoft SQL (MSSQL).

Nama hub tugas

Hub tugas diidentifikasi dengan nama yang sesuai dengan aturan berikut:

Hanya memuat karakter alfanumerik
Dimulai dengan huruf
Memiliki panjang minimum 3 karakter, panjang maksimum 45 karakter

Nama hub tugas dideklarasikan dalam file host.json, seperti diperlihatkan dalam contoh berikut:

host.json (Fungsi 2.0)

{
  "version": "2.0",
  "extensions": {
    "durableTask": {
      "hubName": "MyTaskHub"
    }
  }
}

host.json (Fungsi 1.x)

{
  "durableTask": {
    "hubName": "MyTaskHub"
  }
}

Hub tugas juga dapat dikonfigurasi menggunakan pengaturan aplikasi, seperti diperlihatkan dalam contoh file host.json berikut:

host.json (Fungsi 1.0)

{
  "durableTask": {
    "hubName": "%MyTaskHub%"
  }
}

host.json (Fungsi 2.0)

{
  "version": "2.0",
  "extensions": {
    "durableTask": {
      "hubName": "%MyTaskHub%"
    }
  }
}

Nama hub tugas akan diatur ke nilai pengaturan aplikasi MyTaskHub. local.settings.json berikut menunjukkan cara menentukan pengaturan MyTaskHub sebagai samplehubname:

{
  "IsEncrypted": false,
  "Values": {
    "MyTaskHub" : "samplehubname"
  }
}

Catatan

Saat menggunakan slot penyebaran, hal ini adalah praktik terbaik untuk mengonfigurasi nama hub tugas menggunakan pengaturan aplikasi. Jika Anda ingin memastikan bahwa slot tertentu selalu menggunakan hub tugas tertentu, harap gunakan pengaturan aplikasi "slot-sticky".

Selain menggunakan host.json, nama hub tugas juga dapat dikonfigurasi dalam metadata pengikatan klien orkestrasi. Ini berguna jika Anda perlu mengakses orkestrasi atau entitas yang terdapat di aplikasi fungsi terpisah. Kode berikut menunjukkan cara menulis fungsi yang menggunakan pengikatan klien orkestrasi untuk berfungsi dengan hub tugas yang dikonfigurasi sebagai Pengaturan Aplikasi:

[FunctionName("HttpStart")]
public static async Task<HttpResponseMessage> Run(
    [HttpTrigger(AuthorizationLevel.Function, methods: "post", Route = "orchestrators/{functionName}")] HttpRequestMessage req,
    [DurableClient(TaskHub = "%MyTaskHub%")] IDurableOrchestrationClient starter,
    string functionName,
    ILogger log)
{
    // Function input comes from the request content.
    object eventData = await req.Content.ReadAsAsync<object>();
    string instanceId = await starter.StartNewAsync(functionName, eventData);

    log.LogInformation($"Started orchestration with ID = '{instanceId}'.");

    return starter.CreateCheckStatusResponse(req, instanceId);
}

Catatan

Contoh sebelumnya adalah untuk Durable Functions 2.x. Untuk Durable Functions 1.x, Anda harus menggunakan DurableOrchestrationContext dan bukan IDurableOrchestrationContext. Untuk informasi selengkapnya tentang perbedaan antara versi, lihat artikel Versi Durable Functions.

Properti hub tugas dalam file function.json diatur melalui Pengaturan Aplikasi:

{
    "name": "input",
    "taskHub": "%MyTaskHub%",
    "type": "durableClient",
    "direction": "in"
}

Catatan

Contoh ini menargetkan Durable Functions version 2.x. Di versi 1.x, gunakan orchestrationClient bukan durableClient.

Properti hub tugas dalam file function.json diatur melalui Pengaturan Aplikasi:

{
    "name": "input",
    "taskHub": "%MyTaskHub%",
    "type": "durableClient",
    "direction": "in"
}

Catatan

Contoh ini menargetkan Durable Functions version 2.x. Di versi 1.x, gunakan orchestrationClient bukan durableClient.

Properti hub tugas dalam file function.json diatur melalui Pengaturan Aplikasi:

{
    "name": "input",
    "taskHub": "%MyTaskHub%",
    "type": "durableClient",
    "direction": "in"
}

Catatan

Contoh ini menargetkan Durable Functions version 2.x. Di versi 1.x, gunakan orchestrationClient bukan durableClient.

@FunctionName("HttpStart")
public HttpResponseMessage httpStart(
        @HttpTrigger(name = "req", route = "orchestrators/{functionName}") HttpRequestMessage<?> req,
        @DurableClientInput(name = "durableContext", taskHub = "%MyTaskHub%") DurableClientContext durableContext,
        @BindingName("functionName") String functionName,
        final ExecutionContext context) {

    DurableTaskClient client = durableContext.getClient();
    String instanceId = client.scheduleNewOrchestrationInstance(functionName);
    context.getLogger().info("Created new Java orchestration with instance ID = " + instanceId);
    return durableContext.createCheckStatusResponse(req, instanceId);
}

Catatan

Mengonfigurasi nama hub tugas dalam metadata pengikatan klien hanya diperlukan saat Anda menggunakan satu aplikasi fungsi untuk mengakses orkestrasi dan entitas di aplikasi fungsi lain. Jika fungsi klien didefinisikan dalam aplikasi fungsi yang sama dengan orkestrasi dan entitas, Anda harus menghindari menentukan nama hub tugas dalam metadata yang mengikat. Secara default, semua pengikatan klien mendapatkan metadata hub tugas nya dari host.json.

Nama hub tugas harus dimulai dengan huruf dan hanya terdiri atas huruf dan angka. Jika tidak ditentukan, nama hub tugas default akan digunakan seperti diperlihatkan dalam tabel berikut:

Versi ekstensi yang tahan lama	Nama hub tugas default
2.x	Saat diterapkan di Microsoft Azure, nama hub tugas berasal dari nama aplikasi fungsi. Saat berfungsi di luar Microsoft Azure, nama hub tugas default adalah `TestHubName` .
1.x	Nama hub tugas default untuk semua lingkungan adalah `DurableFunctionsHub`.

Untuk informasi selengkapnya tentang perbedaan antara versi ekstensi, lihat artikel versi Fungsi Tahan Lama.

Catatan

Namanya adalah apa yang membedakan satu hub tugas dari hub lain ketika ada beberapa hub tugas di akun penyimpanan bersama. Jika memiliki beberapa aplikasi fungsi yang berbagi akun penyimpanan bersama, Anda harus secara eksplisit mengonfigurasi nama yang berbeda untuk setiap hub tugas di file host.json. Jika tidak, beberapa aplikasi fungsi akan bersaing satu sama lain untuk pesan, yang dapat mengakibatkan perilaku tidak terdefinisi, termasuk orkestrasi yang secara tak terduga "terjebak" di status Pending atau Running.

Langkah berikutnya

Pelajari cara menangani penerapan versi orkestrasi

Hub tugas dalam Fungsi Tahan Lama (Azure Functions)

Item pekerjaan

Contoh eksekusi

Manajemen hub tugas

Pembuatan dan penghapusan

Beberapa aplikasi fungsi

Pemeriksaan konten

Representasi dalam penyimpanan

Penyedia Microsoft Azure Storage

Penyedia penyimpanan Netherite

Penyedia penyimpanan MSSQL

Nama hub tugas

host.json (Fungsi 2.0)

host.json (Fungsi 1.x)

host.json (Fungsi 1.0)

host.json (Fungsi 2.0)

Langkah berikutnya

Sumber Daya Tambahan: