Berikut adalah panduan sederhana untuk membantu pengirim merasa nyaman saat membuat webhook acara Bird dan mengonsumsi data menggunakan infrastruktur di AWS.
Bird’s webhook acara real-time adalah alat yang sangat berharga bagi pengirim untuk memiliki data yang secara otomatis didorong ke sistem mereka. Ini dapat mendorong otomatisasi lebih lanjut seperti memperbarui daftar pengiriman, memicu perjalanan email otomatis, atau mengisi dasbor internal. Meskipun data acara yang sama dapat diakses melalui Bird UI menggunakan Pencarian Acara, atau secara programatik dengan memanfaatkan Bird Events API, batasan yang ditempatkan pada jumlah rekaman yang dikembalikan dalam satu permintaan atau batasan laju yang ditempatkan pada endpoint API dapat membuat kedua metode ini menjadi pembatas untuk pengirim besar dan canggih.
Webhook acara real-time memungkinkan pengirim untuk mengonfigurasi sebuah endpoint ke mana Bird mengirimkan data tersebut, dan data tersebut dapat dikonsumsi tanpa harus menjadwalkan pekerjaan cron yang menarik data tersebut. Terdapat juga kompromi logistik ketika menarik data dibandingkan dengan menerima data, seperti harus mengidentifikasi periode waktu dan parameter yang digunakan untuk setiap permintaan API. Jika periode waktu tidak disesuaikan dengan sempurna, Anda berisiko kehilangan data, dan jika periode waktu tumpang tindih, Anda perlu menangani data rekaman duplikat. Dengan webhook real-time, data acara cukup dikirimkan ke endpoint Anda saat tersedia dalam Bird.
Meskipun manfaat menerima data acara secara real-time untuk mendorong proses otomatisasi lebih lanjut mungkin langsung dipahami oleh banyak pengirim, proses aktual untuk mengimplementasikan dan mengonsumsi webhook mungkin terasa menakutkan. Ini bisa terutama benar jika Anda tidak terbiasa dengan komponen teknis dalam menciptakan endpoint dan menangani data secara programatik. Ada layanan yang tersedia yang akan mengonsumsi data webhook Bird dan ETL ke dalam basis data Anda secara otomatis – salah satunya adalah StitchData, yang pernah kami bahas dalam blog sebelumnya. Namun, jika Anda menginginkan lebih banyak kontrol atas proses tersebut, Anda dapat dengan mudah membangun komponen sendiri. Berikut ini adalah panduan sederhana untuk membantu pengirim merasa nyaman saat membuat webhook acara Bird dan mengonsumsi data menggunakan infrastruktur dalam AWS.
Mengonfigurasi Target Endpoint Webhook
Ketika sebuah acara Bird dibuat, kami ingin data acara tersebut dialirkan secara real-time ke endpoint di AWS sehingga kami dapat mengonsumsi dan menggunakan data tersebut secara terprogram. Data akan dikirim dari Bird ke endpoint target, yang akan meneruskan payload ke fungsi lambda yang akan memproses dan menyimpan data di bucket S3. Diagram tingkat tinggi dari aliran data yang dijelaskan dapat dilihat di bawah ini:
Untuk menerapkan alur kerja ini, mari kita bangun secara terbalik dimulai dengan membuat bucket S3 tempat kami akan menyimpan data acara kami dan kemudian bekerja mundur – menambahkan setiap komponen yang mendukung apa yang telah kami bangun.
Buat Bucket S3 untuk Menyimpan Data Webhook
Sebelum membuat load balancer kami untuk menerima data, atau fungsi lambda kami untuk menyimpan data, kami perlu terlebih dahulu membuat bucket S3 di mana data akan disimpan. Untuk melakukan ini, navigasikan ke layanan S3 dalam AWS dan tekan “Create Bucket.” Anda akan diminta untuk memberikan nama pada bucket Anda dan menetapkan wilayah – pastikan untuk menggunakan wilayah yang sama dengan ALB dan fungsi lambda Anda. Ketika bucket S3 Anda dibuat, itu akan kosong – jika Anda ingin mengatur data di dalam folder, Anda dapat membuat direktori yang diinginkan sekarang, atau direktori akan dibuat saat fungsi lambda Anda menyimpan file tersebut. Dalam contoh ini, kami menamai bucket S3 kami “bird-webhooks” dan membuat folder bernama “B Event Data” untuk menyimpan data acara kami – Anda akan melihat nama-nama ini dirujuk dalam fungsi lambda kami di bawah ini.
Buat Fungsi Lambda untuk Mengonsumsi Data
Pemrosesan dan penyimpanan data yang sebenarnya akan dilakukan oleh fungsi lambda yang dipanggil oleh application load balancer (ALB) kami.
Langkah pertama adalah membuat fungsi lambda Anda dengan menavigasikan ke layanan Lambda dalam AWS dan mengklik “Create Function.” Anda akan diminta untuk memberi nama pada fungsi lambda Anda dan memilih bahasa pemrograman mana yang akan digunakan untuk menulis fungsi Anda. Untuk contoh ini, kami menggunakan Python sebagai bahasa runtime.
Sekarang kita perlu mengembangkan fungsi lambda kita. Untuk sementara, anggaplah bahwa application load balancer kami telah dikonfigurasi dan meneruskan payload webhook ke fungsi lambda kami – lambda akan menerima payload termasuk header dan body lengkap. Payload diteruskan ke fungsi lambda kami menggunakan objek “event” sebagai kamus. Anda dapat merujuk header dan body payload secara independen dengan mengakses objek “headers” dan “body” di dalam payload. Dalam contoh ini, kita akan membaca header “x-messagesystems-batch-id”, di mana ID batch adalah nilai unik yang dibuat oleh Bird untuk batch webhook, dan menggunakannya sebagai nama file saat menyimpan body sebagai flat-file di S3; namun, Anda mungkin ingin menambahkan fungsionalitas tambahan seperti pemeriksaan otentikasi atau error handling, sesuai kebutuhan.
Saat menyimpan payload ke flat-file di S3, kita perlu menentukan nama bucket S3, lokasi, dan nama file tempat data payload akan disimpan. Dalam contoh fungsi lambda kami, kami melakukannya dalam fungsi “store_batch”. Dalam contoh ini, kami akan menyimpan seluruh batch sebagai satu file, yang membantu memastikan bahwa data dikumpulkan dan disimpan sebelum koneksi HTTP antara Bird dan endpoint Anda habis. Meskipun Anda dapat menyesuaikan pengaturan waktu habis koneksi pada load balancer Anda, tidak ada jaminan bahwa koneksi tidak akan habis pada sisi transmisi (dalam hal ini Bird) atau bahwa koneksi tidak akan terputus sebelum fungsi lambda Anda selesai dieksekusi. Merupakan praktik terbaik untuk menjaga fungsi konsumen Anda seefisien mungkin dan menyimpan kegiatan pemrosesan data untuk proses hilir bila mungkin – seperti mengonversi payload dalam format JSON-batch menjadi file CSV, atau memuat data acara ke dalam database.
Penting untuk dicatat bahwa Anda mungkin perlu memperbarui izin untuk fungsi lambda Anda. Peran eksekusi Anda akan memerlukan izin PutObject dan GetObject untuk S3. Merupakan praktik terbaik untuk menegakkan prinsip hak istimewa paling sedikit, jadi saya merekomendasikan untuk menetapkan izin ini hanya untuk bucket S3 tempat payload webhook akan disimpan.
Sampel fungsi lambda konsumen kami dapat ditemukan di sini.
Catatan singkat tentang ID batch: Bird akan mengelompokkan acara ke dalam satu payload, di mana setiap batch dapat berisi 1 hingga 350 atau lebih rekaman acara. Batch akan diberikan ID batch unik, yang dapat digunakan untuk melihat status batch dengan memanfaatkan Event Webhooks API atau dalam akun Bird Anda dengan mengklik webhook stream dan memilih “Batch Status.” Jika terjadi payload webhook tidak dapat terkirim, seperti selama waktu habis koneksi, Bird akan otomatis mencoba kembali batch menggunakan ID batch yang sama. Hal ini dapat terjadi ketika fungsi lambda Anda berjalan mendekati batas waktu perjalanan pulang-pergi maksimum 10 detik dan merupakan alasan untuk mengoptimalkan fungsi konsumen agar mengurangi waktu eksekusi.
Untuk menangani semua aktivitas pemrosesan data, saya merekomendasikan untuk membuat fungsi lambda terpisah yang dieksekusi setiap kali file baru dibuat di bucket S3 – dengan cara ini, pemrosesan data dilakukan secara asinkron terhadap transmisi data, dan tidak ada risiko kehilangan data akibat koneksi terputus. Saya membahas fungsi lambda pemrosesan di bagian lain.
Buat Application Load Balancer
Untuk menerima payload webhook, kita perlu menyediakan endpoint untuk mengirim payload. Kami melakukan ini dengan membuat application load balancer dalam AWS dengan menavigasikan ke EC2 > Load Balancers dan mengklik “Create Load Balancer.” Anda akan diminta untuk memilih jenis load balancer yang ingin Anda buat – untuk ini, kami ingin membuat application load balancer. Kami perlu menggunakan application load balancer (ALB) untuk membangun konsumen kami karena event webhooks akan dikirim sebagai permintaan HTTP, dan ALB digunakan untuk merutekan permintaan HTTP dalam AWS. Kami dapat menerapkan HTTP Gateway sebagai alternatif; namun, kami menggunakan ALB untuk proyek ini karena lebih ringan dan hemat biaya dibandingkan HTTP Gateway. Penting untuk dicatat bahwa jika Anda memilih menggunakan HTTP Gateway, format acara mungkin berbeda dengan ALB, dan oleh karena itu fungsi lambda Anda perlu menangani objek permintaan sesuai.
Setelah ALB Anda dibuat, Anda akan diminta untuk memberi nama pada ALB Anda dan mengonfigurasi skema serta pengaturan akses/keamanan – karena kami berencana menerima data acara dari sumber eksternal (Bird), kami ingin ALB kami menghadap internet. Di bawah “Listeners and routing,” ALB harus mendengarkan HTTPS pada port 443, dan kami ingin membuat Target group yang mengarah ke fungsi lambda kami sehingga ALB kami akan meneruskan permintaan masuk ke fungsi lambda konsumen yang kami buat di atas. Anda juga perlu memastikan bahwa security group memiliki izin untuk menerima lalu lintas melalui port 443.
Buat Rekaman DNS untuk Load Balancer
Untuk memudahkan kita menggunakan ALB sebagai endpoint, kita akan membuat A record di DNS yang mengarah ke ALB kita. Untuk ini, kita dapat menggunakan layanan AWS Route 53 (atau penyedia DNS Anda saat ini) dan membuat A record untuk hostname yang ingin Anda gunakan untuk endpoint Anda (misalnya spevents.<your_domain>). A record harus dikonfigurasikan untuk menunjuk ke ALB yang kita buat. Jika Anda menggunakan Route 53 untuk mengelola rekaman DNS, Anda dapat merujuk ke instanse ALB secara langsung dengan mengaktifkan “Alias” dan memilih ALB; jika tidak, jika Anda menggunakan penyedia DNS eksternal, Anda harus menunjuk A record ke alamat IP publik dari instanse ALB.
Saya merekomendasikan menggunakan alat seperti Postman untuk menguji bahwa semuanya telah dikonfigurasikan dengan benar sebelum mengaktifkan webhook Bird Anda. Anda dapat membuat permintaan POST ke endpoint Anda dan mengonfirmasi bahwa respons diterima. Jika permintaan POST Anda tidak mengembalikan respons, Anda mungkin perlu memeriksa ulang apakah ALB Anda mendengarkan port yang benar.
Buat Bird Webhook
Sekarang kita siap untuk membuat webhook di Bird dan menggunakan hostname yang ditentukan oleh A record di atas sebagai endpoint target kita. Untuk membuat webhook, navigasikan ke bagian Webhooks di akun Bird Anda dan klik “Create Webhook.” Anda akan diminta untuk memberikan nama untuk webhook Anda dan memberikan URL target – target harus menjadi hostname dari A record yang Anda buat sebelumnya. Perhatikan bahwa URL target mungkin memerlukan “HTTPS://” disertakan dalam URL.
Setelah selesai, verifikasi sub-akun dan acara yang dipilih dengan benar, dan tekan “Create Webhook” untuk menyimpan konfigurasi Anda. Data acara untuk semua jenis acara yang dipilih sekarang akan mengalir ke URL target kami dan dikonsumsi oleh ALB kami untuk pemrosesan hilir.
