Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Menyiapkan Aliran Dinamis
Aliran Dinamis memanggil titik akhir HTTPS Anda sendiri saat runtime untuk mengambil konten layar dan memutuskan navigasi. Aliran Statis menentukan semua layar di Flow JSON. Aliran Dinamis malah menggunakan data_exchange tindakan untuk meminta data dari titik akhir Anda setiap kali pengguna menavigasi antar layar. Ini memungkinkan pengalaman yang dipersonalisasi dan berbasis data seperti menunjukkan kepada pengguna pesanan terbuka mereka, memvalidasi sisi server input, atau percabangan berdasarkan keputusan backend.
Ketika pengguna berinteraksi dengan Dynamic Flow, Meta memanggil titik akhir Anda secara langsung dengan permintaan terenkripsi. Titik akhir Anda mendekripsi permintaan, menjalankan logika bisnis Anda, mengenkripsi respons, dan mengembalikannya ke Meta. Permintaan dan respons terenkripsi melewati langsung antara Meta dan titik AWS akhir Anda, sehingga Social Pesan Pengguna Akhir tidak pernah memiliki akses ke konten yang didekripsi dari pertukaran ini. AWS Social Pesan Pengguna Akhir mengelola bidang kontrol: membuat dan memperbarui Alur, mengunggah kunci publik enkripsi, dan mengirimkan webhook kesehatan Flow.
Untuk mengatur Aliran Dinamis, Anda menyelesaikan langkah-langkah berikut:
Menyebarkan titik akhir HTTPS.
Unggah kunci publik bisnis untuk enkripsi.
Buat Flow dengan URI titik akhir Anda.
Lampirkan aplikasi Meta Anda untuk verifikasi permintaan.
Publikasikan Alur.
Langkah 1: Menyebarkan titik akhir HTTPS
Titik akhir Anda harus memenuhi persyaratan berikut:
URL HTTPS yang dapat diakses publik dengan sertifikat TLS yang valid.
Merespons dalam 10 detik. Meta memberlakukan batas waktu yang sulit dan memantau latensi p90. Titik akhir yang secara konsisten melebihi ambang latensi atau kesalahan pengembalian dapat dibatasi atau diblokir.
Menerima permintaan POST yang berisi muatan JSON terenkripsi.
Mengembalikan respons terenkripsi sebagai
text/plain(dikodekan base64).
Anda dapat menggunakan opsi komputasi apa pun yang menyediakan URL HTTPS publik. Pendekatan umum meliputi:
AWS Lambda fungsi URL — Fungsi tunggal dengan titik akhir HTTPS bawaan. Atur jenis otorisasi ke
NONEkarena Meta tidak menggunakan. Anda mengotentikasi permintaan menggunakan pasangan kunci enkripsi bisnis yang Anda konfigurasikanLangkah 2: Unggah kunci publik bisnis.Amazon API Gateway dengan Lambda — Menyediakan kontrol tambahan seperti kebijakan sumber daya untuk membatasi IP sumber, AWS WAF aturan, dan pelambatan.
Elastic Load Balancing dengan target Lambda — Berguna saat Anda ingin menggabungkan dengan infrastruktur beban seimbang yang ada.
Server HTTPS lainnya (kontainer, instans Amazon EC2, atau layanan eksternal).
Titik akhir Anda harus menerapkan kontrak pertukaran data Meta, yang menangani jenis permintaan berikut:
Pemeriksaan kesehatan — Meta mengirimkan
pingpermintaan berkala untuk memverifikasi titik akhir Anda tersedia. Tanggapi dengan{"data": {"status": "active"}}.INIT — Dikirim saat pengguna membuka Flow. Kembalikan layar awal dan datanya.
data_exchange — Dikirim setiap kali pengguna mengirimkan layar. Kembalikan layar berikutnya dan datanya.
KEMBALI — Dikirim saat pengguna menavigasi kembali ke layar sebelumnya.
Untuk panduan implementasi titik akhir lengkap, termasuk contoh kode enkripsi dan dekripsi dalam berbagai bahasa, lihat Menerapkan titik akhir Flow Anda
Langkah 2: Unggah kunci publik bisnis
Meta mengenkripsi semua permintaan pertukaran data end-to-end menggunakan kunci publik RSA (Rivest-Shamir-Adleman) Anda. Titik akhir Anda mendekripsi permintaan menggunakan kunci pribadi yang sesuai. AWS Social Pesan Pengguna Akhir mengunggah kunci publik ke Meta atas nama Anda tetapi tidak pernah mengakses atau menyimpan kunci pribadi.
Gunakan PutWhatsAppBusinessPublicKey API untuk mengunggah kunci publik untuk nomor telepon. Anda harus memberikan salah satu dari berikut ini:
PEM-encoded Kunci publik RSA — Menyediakan kunci secara langsung. Titik akhir Anda memegang kunci pribadi yang sesuai untuk dekripsi.
AWS Key Management Service kunci ARN — Menyediakan ARN dari kunci RSA-2048 KMS asimetris. AWS Social Pesan Pengguna Akhir hanya membaca setengah publik yang menggunakan
kms:GetPublicKeydan mengunggahnya ke Meta. Kunci pribadi tidak pernah pergi AWS KMS. Titik akhir Anda digunakankms:Decryptuntuk mendekripsi permintaan saat runtime.
Menyediakan keduanya atau tidak keduanya mengembalikanInvalidParametersException.
Modus PEM
Buat pasangan kunci RSA dan unggah kunci publik:
# Generate a key pair openssl genrsa -out private.pem 2048 openssl rsa -in private.pem -pubout -out public.pem # Upload the public key aws social-messaging put-whatsapp-business-public-key \ --origination-phone-number-id{PHONE_NUMBER_ID}\ --business-public-key "$(cat public.pem)"
Simpan kunci pribadi dengan aman dan sediakan ke titik akhir Anda untuk dekripsi.
AWS KMS Modus
Buat kunci KMS RSA asimetris dan unggah ARN-nya:
# Create the KMS key KMS_KEY_ARN=$(aws kms create-key \ --key-spec RSA_2048 \ --key-usage ENCRYPT_DECRYPT \ --description "WhatsApp Dynamic Flow encryption key" \ --query KeyMetadata.Arn --output text) # Upload the KMS key ARN aws social-messaging put-whatsapp-business-public-key \ --origination-phone-number-id{PHONE_NUMBER_ID}\ --kms-key-arn$KMS_KEY_ARN
Kebijakan kunci KMS harus memberikan izin berikut:
kms:GetPublicKeykepada kepalasocial-messaging.amazonaws.com.rproxy.govskope.calayanan. Hal ini memungkinkan AWS End User Messaging Social untuk membaca kunci publik dan mengunggahnya ke Meta.kms:Decryptke peran eksekusi titik akhir Anda. Hal ini memungkinkan titik akhir Anda untuk mendekripsi permintaan pertukaran data yang masuk. AWS Social Pesan Pengguna Akhir tidak pernahkms:Decryptmemanggil kunci ini.
Memverifikasi kunci
Gunakan GetWhatsAppBusinessPublicKey API untuk memverifikasi kunci yang disimpan dan memeriksa status penandatanganan Meta:
aws social-messaging get-whatsapp-business-public-key \ --origination-phone-number-id{PHONE_NUMBER_ID}
Respons termasuk PEM yang disimpan dan status penandatanganan Meta (VALIDatauMISMATCH). MISMATCHStatus menunjukkan bahwa kunci yang disimpan tidak sesuai dengan yang diharapkan Meta. Unggah kunci baru jika Anda melihat status ini.
Langkah 3: Buat Alur dengan titik akhir
Saat membuat Dynamic Flow, berikan --endpoint-uri parameter dengan URL titik akhir HTTPS Anda. Flow JSON juga harus mendeklarasikandata_api_version, yang memberitahu Meta untuk memanggil titik akhir Anda selama sesi Flow.
aws social-messaging create-whatsapp-flow \ --id{WABA_ID}\ --flow-name "my_dynamic_flow" \ --categories '["OTHER"]' \ --flow-json fileb://flow.json\ --endpoint-uri "https://your-endpoint.example.com/flow"
Anda juga dapat menambahkan atau mengubah titik akhir pada ALUR DRAFT yang ada menggunakanUpdateWhatsAppFlow:
aws social-messaging update-whatsapp-flow \ --id{WABA_ID}\ --flow-id{FLOW_ID}\ --endpoint-uri "https://your-endpoint.example.com/flow"
catatan
Saat Anda menerbitkan Aliran Dinamis, Meta melakukan pemeriksaan kesehatan sinkron terhadap titik akhir Anda. Jika titik akhir tidak merespons atau mengembalikan kesalahan, operasi publikasi gagal dengan kesalahan Meta seperti 131000 (“verifikasi bahwa titik akhir tersedia dan bahwa Anda telah menerapkan pemeriksaan kesehatan”). Kunci publik bisnis yang hilang atau tidak valid juga dapat menyebabkan kesalahan ini. Sebelum menerbitkan, pastikan bahwa titik akhir Anda digunakan dan menanggapi ping permintaan, dan bahwa Anda telah mengunggah kunci publik bisnis yang valid (lihatLangkah 2: Unggah kunci publik bisnis).
Untuk memverifikasi versi endpoint dan data API yang dikonfigurasi untuk Flow, gunakanGetWhatsAppFlow:
aws social-messaging get-whatsapp-flow \ --id{WABA_ID}\ --flow-id{FLOW_ID}
Tanggapan termasuk endpointUri saat Meta memegangnya, yang di dataApiVersion deklarasikan dalam Flow JSON, dan yang saat ini dilampirkanapplication.
Langkah 4: Lampirkan aplikasi Meta Anda untuk verifikasi permintaan
Secara default, saat Anda membuat Flow melalui AWS Social Pesan Pengguna Akhir, itu terkait dengan aplikasi Meta layanan. Untuk memverifikasi bahwa permintaan pertukaran data ke titik akhir Anda berasal dari Meta, lampirkan aplikasi Meta Anda sendiri ke Flow. Tanpa aplikasi Anda sendiri yang dilampirkan, verifikasi asal permintaan tidak mungkin dilakukan. Melampirkan aplikasi Anda memberi Anda akses ke rahasia aplikasi yang diperlukan untuk memverifikasi header X-Hub-Signature-256 HMAC yang disertakan Meta pada setiap permintaan.
aws social-messaging update-whatsapp-flow \ --id{WABA_ID}\ --flow-id{FLOW_ID}\ --meta-app-id "{YOUR_META_APP_ID}"
Aplikasi Meta harus dimiliki oleh bisnis yang sama yang memiliki Akun WhatsApp Bisnis (WABA).
penting
Melampirkan aplikasi Meta Anda sendiri adalah operasi satu arah. Setelah Anda melampirkan aplikasi, aplikasi layanan tidak dapat dilampirkan kembali. Ini tidak mempengaruhi fungsionalitas Flow. Hanya Flow baru yang mengatur ulang asosiasi aplikasi.
Anda dapat mengatur --endpoint-uri dan --meta-app-id dalam panggilan yang sama atau dalam panggilan terpisah. Kedua bidang tersebut independen.
Setelah melampirkan aplikasi Anda, verifikasi konfigurasi dengan menelepon GetWhatsAppFlow dan memeriksa application bidang dalam respons. Itu application.id harus cocok dengan ID aplikasi Meta yang Anda berikan.
Mengamankan titik akhir Anda
Karena Meta memanggil titik akhir Anda secara langsung, pertimbangkan praktik keamanan berikut:
-
Verifikasi tanda tangan permintaan — Jika Anda melampirkan aplikasi Meta Anda sendiri (Langkah 4), gunakan rahasia aplikasi untuk memverifikasi
X-Hub-Signature-256HMAC-SHA256 header pada setiap permintaan. Ini menegaskan permintaan berasal dari Meta. Kembalikan status HTTP 432 jika verifikasi gagal. -
Validasi token aliran — Hasilkan fitur unik yang tidak dapat diprediksi
flow_tokenuntuk setiap sesi Flow saat mengirim Flow ke pengguna. Titik akhir Anda menerima token di dalam payload terenkripsi dan harus memvalidasinya terhadap sesi aktif. Tolak permintaan dengan token yang tidak diketahui, kedaluwarsa, atau sudah selesai. Ini mencegah permintaan yang tidak sah atau diputar ulang mencapai logika bisnis Anda. -
Menangani pemeriksaan kesehatan tanpa validasi token — Meta mengirimkan
pingpermintaan berkala untuk memantau kesehatan titik akhir. Permintaan ini tidak mengandung aflow_token. Tanggapi pemeriksaan kesehatan tanpa memerlukan validasi token, karena menolaknya akan menurunkan skor ketersediaan titik akhir Anda. -
Kembalikan kode status yang sesuai — Kembalikan 421 jika titik akhir Anda tidak dapat mendekripsi permintaan (Meta mengubah kunci publik dan mencoba lagi). Kembalikan 427 jika tidak
flow_tokenvalid (Meta menonaktifkan tombol Flow untuk sesi itu).
Menulis JSON Aliran Dinamis
Dynamic Flow JSON berbeda dari JSON Flow statis dalam dua cara:
Bidang tingkat atas
data_api_versiondiperlukan. Ini memberitahu Meta untuk memanggil titik akhir Anda selama sesi Flow. Nilai yang didukung adalah"3.0"dan"4.0"(disarankan).Footer layar menggunakan
data_exchangetindakan alih-alihnavigate. Setiapdata_exchangetindakan mengirimkan data formulir ke titik akhir Anda, yang mengembalikan layar berikutnya dan isinya.
Contoh berikut menunjukkan Dynamic Flow JSON minimal dengan dua layar. Layar pertama mengumpulkan nama pengguna dan mengirimkannya ke titik akhir. Titik akhir mengembalikan salam yang dipersonalisasi di layar kedua.
{ "version": "6.0", "data_api_version": "3.0", "routing_model": { "INPUT": ["RESULT"], "RESULT": [] }, "screens": [ { "id": "INPUT", "title": "Welcome", "data": { "greeting": { "type": "string", "__example__": "Tell us your name" } }, "layout": { "type": "SingleColumnLayout", "children": [ { "type": "TextBody", "text": "${data.greeting}" }, { "type": "Form", "name": "input_form", "children": [ { "type": "TextInput", "name": "user_name", "label": "Your name", "input-type": "text", "required": true }, { "type": "Footer", "label": "Submit", "on-click-action": { "name": "data_exchange", "payload": { "user_name": "${form.user_name}" } } } ] } ] } }, { "id": "RESULT", "title": "Hello", "terminal": true, "data": { "message": { "type": "string", "__example__": "Hello, World!" } }, "layout": { "type": "SingleColumnLayout", "children": [ { "type": "TextBody", "text": "${data.message}" }, { "type": "Footer", "label": "Done", "on-click-action": { "name": "complete", "payload": {} } } ] } } ] }
Untuk referensi skema Flow JSON lengkap, lihat Flow JSON
End-to-end contoh
Contoh berikut menunjukkan urutan lengkap panggilan API untuk mengatur dan menerbitkan Aliran Dinamis:
# 1. Upload the business public key (KMS mode) aws social-messaging put-whatsapp-business-public-key \ --origination-phone-number-id{PHONE_NUMBER_ID}\ --kms-key-arn{KMS_KEY_ARN}# 2. Create the Dynamic Flow with an endpoint FLOW_ID=$(aws social-messaging create-whatsapp-flow \ --id{WABA_ID}\ --flow-name "my_dynamic_flow" \ --categories '["OTHER"]' \ --flow-json fileb://flow.json\ --endpoint-uri "https://your-endpoint.example.com/flow" \ --query flowId --output text) # 3. Attach your Meta app for signature verification aws social-messaging update-whatsapp-flow \ --id{WABA_ID}\ --flow-id $FLOW_ID \ --meta-app-id "{YOUR_META_APP_ID}" # 4. Publish the Flow aws social-messaging publish-whatsapp-flow \ --id{WABA_ID}\ --flow-id $FLOW_ID # 5. Verify the configuration aws social-messaging get-whatsapp-flow \ --id{WABA_ID}\ --flow-id $FLOW_ID
Setelah penerbitan, Flow tersedia untuk digunakan dalam pesan template. Untuk informasi selengkapnya tentang mengirim Alur, lihatMengirim WhatsApp Arus ke pengguna.