التالي هو دليل بسيط لمساعدة المرسلين على الشعور بالراحة عند إنشاء webhook لأحداث Bird واستهلاك البيانات باستخدام البنية التحتية داخل AWS.
تُعتبر webhooks للأحداث من Bird في الوقت الفعلي أداة قيّمة للغاية للمرسلين للحصول على البيانات تلقائيًا نحو أنظمتهم. يمكن أن يقود هذا إلى أتمتة الأنظمة اللاحقة مثل تحديث قوائم المراسلة، وإطلاق رحلات البريد الإلكتروني الآلية، أو ملء لوحات القيادة الداخلية. بينما يمكن الوصول إلى نفس بيانات الحدث عبر واجهة المستخدم لBird باستخدام بحث الأحداث، أو برمجيًا باستخدام API الأحداث من Bird، فإن القيود المفروضة على عدد السجلات المعادة في طلب واحد أو حدود المعدل المفروضة على النهاية للعناصر يمكن أن تجعل كلتا الطريقتين مقيِّدتين بالنسبة للمرسلين الكبار والمتطورين.
تمكن webhooks للأحداث في الوقت الفعلي المرسل من تكوين نقطة نهاية حيث تقوم Bird بنقل البيانات إليها، ويمكن استهلاك البيانات دون الحاجة إلى جدولة وظائف cron التي تسحب البيانات. هناك أيضًا مقايضات لوجستية عند سحب البيانات مقارنة بالحصول على البيانات المرسلة إليك، مثل الاضطرار إلى تحديد الفترة الزمنية والمعايير التي يجب استخدامها لكل طلب API. إذا لم تتطابق الفترات الزمنية بدقة فقد تخاطر بفقدان البيانات، وإذا تداخلت الفترات الزمنية فستحتاج إلى التعامل مع سجلات البيانات المكررة. باستخدام webhooks في الوقت الفعلي، يتم ببساطة دفع بيانات الحدث إلى نقطة النهاية الخاصة بك حالما تتوفر داخل Bird.
بينما قد يتم فهم فوائد تلقي بيانات الأحداث في الوقت الفعلي لتحريك عمليات أتمتة الأنظمة اللاحقة على الفور من قبل العديد من المرسلين، قد تكون عملية تنفيذ واستهلاك webhooks مثيرة للتحدي. يمكن أن يكون هذا صحيحًا بشكل خاص إذا لم تكن لديك فكرة عن المكونات الفنية لإنشاء نقطة نهاية ومعالجة البيانات برمجيًا. هناك خدمات متاحة ستستهلك بيانات webhook من Bird وETL إلى قاعدة البيانات الخاصة بك تلقائيًا – على سبيل المثال StitchData، الذي تحدثنا عنه في مدونات سابقة. ومع ذلك، إذا كنت ترغب في مزيد من التحكم في العملية يمكنك بسهولة بناء المكونات بنفسك. فيما يلي دليل بسيط لمساعدة المرسلين على الشعور بالراحة عند إنشاء webhook للأحداث من Bird واستهلاك البيانات باستخدام البنية التحتية داخل AWS.
تكوين وجهة نقطة نهاية Webhook
عند إنشاء حدث Bird، نريد أن يتم بث بيانات الحدث في الوقت الفعلي إلى نقطة نهاية في AWS حتى نتمكن من استهلاك واستخدام تلك البيانات برمجيًا. سيتم إرسال البيانات من Bird إلى نقطة نهاية مستهدفة، والتي ستقوم بإرسال الحمولة إلى دالة لامدا التي ستعالج البيانات وتخزنها في دلو S3. يمكن رؤية مخطط عالي المستوى لتدفق البيانات الموضح أدناه:
لتنفيذ سير العمل هذا، دعونا نبنيها فعليًا بالترتيب العكسي بدءًا من إنشاء دلو S3 حيث سنخزن بيانات الحدث ثم نعمل للخلف - إضافة كل مكون يغذي في ما قمنا ببنائه.
إنشاء دلو S3 لتخزين بيانات الويب هوك
قبل إنشاء موازن التحميل الخاص بنا لقبول البيانات، أو دالة لامدا لتخزين البيانات، نحتاج أولاً إلى إنشاء دلو S3 حيث ستتم تخزين البيانات. بينما يوفر S3 تخزينًا ممتازًا لبيانات الويب هوك، يجب على المؤسسات التي تستخدم قواعد بيانات PostgreSQL لمعالجة الأحداث أيضًا تنفيذ إجراءات النسخ الاحتياطي والاستعادة المناسبة لحماية بياناتها المنظمة جنبًا إلى جنب مع استراتيجية التخزين عبر S3. للقيام بذلك، انتقل إلى خدمة S3 داخل AWS واضغط على 'إنشاء دلو'. سيتم مطالبك بتعيين اسم لدلوك وتحديد المنطقة - تأكد من استخدام نفس المنطقة مثل ALB و دالة لامدا الخاصة بك. عندما يتم إنشاء دلوك S3 الخاص بك، سيكون فارغًا - إذا كنت ترغب في تنظيم البيانات داخل مجلد، يمكنك إما إنشاء الدليل المقصود الآن، أو سيتم إنشاء الدليل عندما تقوم دالة لامدا الخاصة بك بتخزين الملف. في هذا المثال، سمينا دلوك S3 الخاص بنا بـ 'bird-webhooks' وأنشأنا مجلدًا باسم 'B Event Data' لتخزين بيانات الحدث - سترى هذه الأسماء مذكورة في دالة لامدا الخاصة بنا أدناه.
إنشاء دالة لامدا لاستهلاك البيانات
سيتم تنفيذ المعالجة الفعلية وتخزين البيانات بواسطة دالة لامدا التي تفعيلها موازن التحميل الخاص بالتطبيق (ALB).
الخطوة الأولى هي إنشاء دالة لامدا الخاصة بك عن طريق الانتقال إلى خدمة لامدا داخل AWS والنقر على 'إنشاء دالة'. سيتم مطالبتك بتعيين اسم لدالة لامدا الخاصة بك وتحديد أي لغة برمجة لكتابة دالتك بها. في هذا المثال، نستخدم Python كلغة تشغيل.
الآن نحن بحاجة إلى تطوير دالة لامدا الخاصة بنا. للحظة، دعونا نفترض أن موازن التحميل الخاص بالتطبيق قد تم تكوينه ويرسل حمولة الويب هوك إلى دالة لامدا الخاصة بنا - ستستقبل دالة لامدا حمولة تشمل العناوين والجسم بالكامل. يتم تمرير الحمولة إلى دالة لامدا الخاصة بنا باستخدام الكائن
