إنشاء واستقبال Webhooks من Bird
Bird
27/01/2022
البريد الإلكتروني
1 min read
النقاط الرئيسية
تتيح عمليات webhook الخاصة بحدث Bird في الوقت الفعلي للمرسلين استقبال بيانات الأحداث على الفور - بدون استطلاع، بدون وظائف cron، وبدون صداع حدود المعدل.
تزيل عمليات الـ webhook التعقيد في إدارة نوافذ الوقت، ومنع الأحداث الفائتة ومعالجة السجلات المكررة.
مثالي للأتمتة النهائية: تحديث القوائم، بدء الرحلات، إثراء لوحات التحكم، أو مزامنة الأنظمة الداخلية.
يأخذ البرنامج التعليمي المرسلين خلال بناء مسار كامل لاستخراج البيانات على AWS: تخزين S3، معالجة Lambda، وموازن تحميل التطبيقات.
يعمل S3 كطبقة التخزين المركزية لعمليات تحميل webhook، حيث يتم كتابة كل دفعة كملف JSON مسطح.
تتعامل دوال Lambda مع كل من استخراج البيانات (تخزين الدفعات الخام) والتحويل (تحويل JSON إلى CSV).
يقوم Bird بتجميع الأحداث - كل دفعة webhook تشمل معرف فريد
x-messagesystems-batch-id، مما يتيح عمليات فحص إعادة اللعب وإزالة التكرار.يجب أن تظل Lambda المستهلكة فعالة نظرًا لأن Bird يعيد محاولة الدفعات إذا لم يستجب النقطة النهائية في غضون ~10 ثوانٍ.
يوصى باستخدام AWS ALB (مقابل API Gateway) من أجل البساطة، والفعالية من حيث التكلفة، والتعامل المباشر مع طلبات HTTP POST.
يتم تكوين DNS (Route 53 أو مزود خارجي) لتعيين اسم مضيف ودود إلى نقطة نهاية ALB.
بعد الإعداد، يقوم Bird بدفع بيانات الحدث بشكل مباشر وموثوق إلى مسار AWS الخاص بك لمعالجة غير متزامنة.
يغطي الدليل أيضًا أفضل الممارسات: أذونات IAM الأقل امتيازًا، قيود التخزين المؤقت، تجنب المُحفِّزات المتكررة، وتنظيم تدفقات العمل متعددة الاستخدامات.
أبرز الأسئلة والأجوبة
ما هو الهدف الرئيسي من روابط الويب للأحداث في الوقت الفعلي من Bird؟
لدفع بيانات الحدث مباشرة إلى نقطة نهاية المُرسل في الوقت الفعلي، مما يتيح الأتمتة الفورية دون استقصاء أو استدعاءات API محدودة بالمعدل.
لماذا تعتبر webhooks أفضل من سحب البيانات عبر API للمرسلين الكبار؟
نظرًا لأن سحوبات API تتطلب إدارة نافذة زمنية، وتخاطر بوجود فجوات في البيانات أو تكرارات، وقد تصل إلى حدود المعدل — فإن الويب هوكس تقضي على كل ذلك من خلال دفع البيانات بشكل مستمر.
ما هي خدمات AWS المستخدمة في خط أنابيب استقبال الويب هوك الموصى به؟
أمازون S3 (التخزين)، AWS Lambda (المعالجة)، و Application Load Balancer (مستمع HTTP)، واختيارياً Route 53 (DNS).
كيف تقوم Bird بمعالجة بيانات الأحداث؟
تُرسل Bird عدة أحداث معًا في حمولة، يتم تخصيص معرف دفعة فريد لها (x-messagesystems-batch-id) للتتبع، وإعادة المحاولة، وإزالة التكرار.
ما الذي يُفعِّل دالة Lambda الخاصة بالمستهلك؟
يقوم جهاز ALB بتمرير طلبات POST الواردة من الويب هوك مباشرةً إلى Lambda، الذي يستخرج الحمولة ويكتبها إلى S3.
لماذا يتم تخزين دفعة الويب هوك الخام في S3 قبل معالجتها؟
لضمان إدخال سريع (<10 ثوانٍ) حتى لا ينقطع الاتصال، ولفصل معالجة الأثقل إلى خط معالجة غير متزامن منفصل.
ماذا تفعل الدالة الثانية Lambda؟
يتم تشغيله بواسطة كائنات S3 جديدة، يتحقق من صحة JSON، ويحوله إلى CSV، ويكتب الناتج المعالج إلى حاوية S3 منفصلة.
لماذا تستخدم حاوية S3 منفصلة لملفات CSV المعالجة؟
لتجنب تشغيل العمليات المتكررة (كتابة ملف جديد معالج مرة أخرى في نفس الحاوية سيؤدي إلى تكرار تشغيل Lambda بلا نهاية).
ما الأذونات التي تتطلبها وظائف Lambda؟
يحتاج مستخدم Lambda إلى أذونات S3 PutObject؛ يحتاج Lambda المعالج إلى GetObject لحاوية المصدر وPutObject لحاوية الوجهة.
لماذا يُوصى باستخدام AWS ALB بدلاً من API Gateway؟
تعتبر ALBs أرخص وأبسط ومثالية لتمرير HTTPS POST بشكل مباشر؛ قد يقوم API Gateway بتغيير تنسيق الحمولة وزيادة التعقيد.
كيف يقوم المرسلون بتكوين الويب هوك في Bird؟
بتوفير نقطة النهاية HTTPS (سجل DNS لـ ALB)، واختيار حساب فرعي، واختيار الأحداث، وحفظ تكوين الويب هوك.
ما هي الخيارات المتاحة لتخزين أو تحليل البيانات المعالجة؟
تحميل إلى قواعد البيانات (PostgreSQL, DynamoDB, RDS)، أو إدخالها في أنظمة ETL، أو الاستعلام مباشرة باستخدام أدوات مثل Athena.
التالي هو دليل بسيط لمساعدة المرسلين على الشعور بالراحة عند إنشاء webhook لأحداث Bird واستهلاك البيانات باستخدام البنية التحتية داخل AWS.
تعتبر إشعارات الويب للأحداث في الوقت الفعلي من Bird أداة قيمة للغاية للمستخدمين ليتم دفع البيانات تلقائيًا إلى أنظمتهم. يمكن أن يحفز هذا الأتمتة التالية مثل تحديث قوائم البريد، أو بدء رحلات البريد الإلكتروني التلقائية، أو تعبئة لوحات تحكم داخلية. بينما يمكن الوصول إلى نفس بيانات الحدث عبر واجهة Bird باستخدام البحث عن الأحداث، أو برمجيًا باستخدام Events API الخاصة بـBird، يمكن أن تكون الحدود المفروضة على عدد السجلات المسترجعة في طلب واحد أو حدود السرعة على واجهة API المقيدة للطرفين للمستخدمين الكبار والمتقدمين.
تُمكّن إشعارات الويب في الوقت الفعلي المُرسل من تكوين نقطة نهاية حيث تنقل Bird البيانات إليها، ويمكن استهلاك البيانات دون الحاجة لتحديد وظائف cron التي تسحب البيانات. هناك أيضًا مقايضات لوجستية عند سحب البيانات بدلاً من دفع البيانات إليك، مثل الحاجة إلى تحديد الفترة الزمنية والمعلمات للاستخدام لكل طلب API. إذا لم تتوافق الفترات الزمنية تمامًا فإنك تخاطر بفقدان البيانات، وإذا تداخلت الفترات الزمنية فإنك تحتاج إلى التعامل مع السجلات المكررة. مع إشعارات الويب في الوقت الفعلي، يتم دفع بيانات الأحداث ببساطة إلى نقطة النهاية الخاصة بك عند توفرها في Bird.
بينما قد يتم فهم فوائد تلقي بيانات الأحداث في الوقت الفعلي لتحفيز عمليات الأتمتة التالية بوضوح من قبل العديد من المستخدمين، قد تكون عملية تنفيذ واستهلاك إشعارات الويب مرهبة. قد يكون هذا صحيحًا بشكل خاص إذا لم تكن مألوفًا بالمكونات التقنية لإنشاء نقطة نهاية والتعامل مع البيانات برمجيًا. هناك خدمات متاحة ستستهلك بيانات إشعارات الويب من Bird وتنفذ ETL إلى قاعدة بياناتك تلقائيًا - مثال على ذلك هو StitchData، الذي تحدثنا عنه في مدونة في الماضي. ومع ذلك، إذا كنت ترغب في مزيد من التحكم في العملية يمكنك بناء المكونات بنفسك بسهولة. النص التالي هو دليل بسيط لمساعدة المستخدمين على الشعور بالراحة عند إنشاء إشعار الويب لفعاليات Bird واستهلاك البيانات باستخدام البنية التحتية في AWS.
تعتبر إشعارات الويب للأحداث في الوقت الفعلي من Bird أداة قيمة للغاية للمستخدمين ليتم دفع البيانات تلقائيًا إلى أنظمتهم. يمكن أن يحفز هذا الأتمتة التالية مثل تحديث قوائم البريد، أو بدء رحلات البريد الإلكتروني التلقائية، أو تعبئة لوحات تحكم داخلية. بينما يمكن الوصول إلى نفس بيانات الحدث عبر واجهة Bird باستخدام البحث عن الأحداث، أو برمجيًا باستخدام Events API الخاصة بـBird، يمكن أن تكون الحدود المفروضة على عدد السجلات المسترجعة في طلب واحد أو حدود السرعة على واجهة API المقيدة للطرفين للمستخدمين الكبار والمتقدمين.
تُمكّن إشعارات الويب في الوقت الفعلي المُرسل من تكوين نقطة نهاية حيث تنقل Bird البيانات إليها، ويمكن استهلاك البيانات دون الحاجة لتحديد وظائف cron التي تسحب البيانات. هناك أيضًا مقايضات لوجستية عند سحب البيانات بدلاً من دفع البيانات إليك، مثل الحاجة إلى تحديد الفترة الزمنية والمعلمات للاستخدام لكل طلب API. إذا لم تتوافق الفترات الزمنية تمامًا فإنك تخاطر بفقدان البيانات، وإذا تداخلت الفترات الزمنية فإنك تحتاج إلى التعامل مع السجلات المكررة. مع إشعارات الويب في الوقت الفعلي، يتم دفع بيانات الأحداث ببساطة إلى نقطة النهاية الخاصة بك عند توفرها في Bird.
بينما قد يتم فهم فوائد تلقي بيانات الأحداث في الوقت الفعلي لتحفيز عمليات الأتمتة التالية بوضوح من قبل العديد من المستخدمين، قد تكون عملية تنفيذ واستهلاك إشعارات الويب مرهبة. قد يكون هذا صحيحًا بشكل خاص إذا لم تكن مألوفًا بالمكونات التقنية لإنشاء نقطة نهاية والتعامل مع البيانات برمجيًا. هناك خدمات متاحة ستستهلك بيانات إشعارات الويب من Bird وتنفذ ETL إلى قاعدة بياناتك تلقائيًا - مثال على ذلك هو StitchData، الذي تحدثنا عنه في مدونة في الماضي. ومع ذلك، إذا كنت ترغب في مزيد من التحكم في العملية يمكنك بناء المكونات بنفسك بسهولة. النص التالي هو دليل بسيط لمساعدة المستخدمين على الشعور بالراحة عند إنشاء إشعار الويب لفعاليات Bird واستهلاك البيانات باستخدام البنية التحتية في AWS.
تعتبر إشعارات الويب للأحداث في الوقت الفعلي من Bird أداة قيمة للغاية للمستخدمين ليتم دفع البيانات تلقائيًا إلى أنظمتهم. يمكن أن يحفز هذا الأتمتة التالية مثل تحديث قوائم البريد، أو بدء رحلات البريد الإلكتروني التلقائية، أو تعبئة لوحات تحكم داخلية. بينما يمكن الوصول إلى نفس بيانات الحدث عبر واجهة Bird باستخدام البحث عن الأحداث، أو برمجيًا باستخدام Events API الخاصة بـBird، يمكن أن تكون الحدود المفروضة على عدد السجلات المسترجعة في طلب واحد أو حدود السرعة على واجهة API المقيدة للطرفين للمستخدمين الكبار والمتقدمين.
تُمكّن إشعارات الويب في الوقت الفعلي المُرسل من تكوين نقطة نهاية حيث تنقل Bird البيانات إليها، ويمكن استهلاك البيانات دون الحاجة لتحديد وظائف cron التي تسحب البيانات. هناك أيضًا مقايضات لوجستية عند سحب البيانات بدلاً من دفع البيانات إليك، مثل الحاجة إلى تحديد الفترة الزمنية والمعلمات للاستخدام لكل طلب API. إذا لم تتوافق الفترات الزمنية تمامًا فإنك تخاطر بفقدان البيانات، وإذا تداخلت الفترات الزمنية فإنك تحتاج إلى التعامل مع السجلات المكررة. مع إشعارات الويب في الوقت الفعلي، يتم دفع بيانات الأحداث ببساطة إلى نقطة النهاية الخاصة بك عند توفرها في Bird.
بينما قد يتم فهم فوائد تلقي بيانات الأحداث في الوقت الفعلي لتحفيز عمليات الأتمتة التالية بوضوح من قبل العديد من المستخدمين، قد تكون عملية تنفيذ واستهلاك إشعارات الويب مرهبة. قد يكون هذا صحيحًا بشكل خاص إذا لم تكن مألوفًا بالمكونات التقنية لإنشاء نقطة نهاية والتعامل مع البيانات برمجيًا. هناك خدمات متاحة ستستهلك بيانات إشعارات الويب من Bird وتنفذ ETL إلى قاعدة بياناتك تلقائيًا - مثال على ذلك هو StitchData، الذي تحدثنا عنه في مدونة في الماضي. ومع ذلك، إذا كنت ترغب في مزيد من التحكم في العملية يمكنك بناء المكونات بنفسك بسهولة. النص التالي هو دليل بسيط لمساعدة المستخدمين على الشعور بالراحة عند إنشاء إشعار الويب لفعاليات Bird واستهلاك البيانات باستخدام البنية التحتية في AWS.
تكوين وجهة نقطة نهاية Webhook
عند إنشاء حدث من Bird، نريد أن يتم بث بيانات ذلك الحدث في الوقت الفعلي إلى نقطة نهاية في AWS حتى نتمكن من استهلاك واستخدام تلك البيانات برمجيًا. ستُرسل البيانات من Bird إلى نقطة نهاية مستهدفة، والتي ستحوّل الحمولة إلى دالة Lambda التي ستقوم بمعالجة وتخزين البيانات في دلو S3. يمكن رؤية مخطط على مستوى عالٍ لتدفق البيانات الموصوفة أدناه:
لتنفيذ هذا سير العمل، دعونا نبنيها فعليًا بترتيب عكسي بدءًا بإنشاء دلو S3 حيث سنقوم بتخزين بيانات الحدث لدينا ثم العمل بطريقة عكسية - بإضافة كل مكون يغذي ما قمنا ببنائه.
عند إنشاء حدث من Bird، نريد أن يتم بث بيانات ذلك الحدث في الوقت الفعلي إلى نقطة نهاية في AWS حتى نتمكن من استهلاك واستخدام تلك البيانات برمجيًا. ستُرسل البيانات من Bird إلى نقطة نهاية مستهدفة، والتي ستحوّل الحمولة إلى دالة Lambda التي ستقوم بمعالجة وتخزين البيانات في دلو S3. يمكن رؤية مخطط على مستوى عالٍ لتدفق البيانات الموصوفة أدناه:
لتنفيذ هذا سير العمل، دعونا نبنيها فعليًا بترتيب عكسي بدءًا بإنشاء دلو S3 حيث سنقوم بتخزين بيانات الحدث لدينا ثم العمل بطريقة عكسية - بإضافة كل مكون يغذي ما قمنا ببنائه.
عند إنشاء حدث من Bird، نريد أن يتم بث بيانات ذلك الحدث في الوقت الفعلي إلى نقطة نهاية في AWS حتى نتمكن من استهلاك واستخدام تلك البيانات برمجيًا. ستُرسل البيانات من Bird إلى نقطة نهاية مستهدفة، والتي ستحوّل الحمولة إلى دالة Lambda التي ستقوم بمعالجة وتخزين البيانات في دلو S3. يمكن رؤية مخطط على مستوى عالٍ لتدفق البيانات الموصوفة أدناه:
لتنفيذ هذا سير العمل، دعونا نبنيها فعليًا بترتيب عكسي بدءًا بإنشاء دلو S3 حيث سنقوم بتخزين بيانات الحدث لدينا ثم العمل بطريقة عكسية - بإضافة كل مكون يغذي ما قمنا ببنائه.
قم بإنشاء حاوية S3 لتخزين بيانات Webhook
قبل إنشاء موزع التحميل الخاص بنا لقبول البيانات، أو وظيفة lambda الخاصة بنا لتخزين البيانات، نحتاج أولاً إلى إنشاء S3 bucket الخاص بنا حيث سيتم تخزين البيانات. بينما توفر S3 تخزينًا ممتازًا لبيانات webhook، يجب على المنظمات التي تستخدم أيضًا قواعد بيانات PostgreSQL لمعالجة الأحداث تنفيذ إجراءات النسخ الاحتياطي والاستعادة بشكل صحيح لحماية بياناتها المنظمة إلى جانب استراتيجيتها لتخزين S3. للقيام بذلك، انتقل إلى خدمة S3 داخل AWS واضغط على "إنشاء دلو". سيتم تحفيزك لتعيين اسم لدلوك وتعيين المنطقة – تأكد من استخدام نفس المنطقة مثل ALB ووظيفة lambda الخاصة بك. عندما يتم إنشاء S3 bucket الخاص بك، سيكون فارغًا – إذا كنت ترغب في تنظيم البيانات داخل مجلد، يمكنك إما إنشاء الدليل المحدد الآن، أو سيتم إنشاء الدليل عندما تقوم وظيفة lambda الخاصة بك بتخزين الملف. في هذا المثال، أسمينا S3 bucket الخاص بنا "bird-webhooks" وأنشأنا مجلدًا باسم "B Event Data" لتخزين بيانات الحدث لدينا – سترى هذه الأسماء مشار إليها في وظيفة lambda أدناه.
قبل إنشاء موزع التحميل الخاص بنا لقبول البيانات، أو وظيفة lambda الخاصة بنا لتخزين البيانات، نحتاج أولاً إلى إنشاء S3 bucket الخاص بنا حيث سيتم تخزين البيانات. بينما توفر S3 تخزينًا ممتازًا لبيانات webhook، يجب على المنظمات التي تستخدم أيضًا قواعد بيانات PostgreSQL لمعالجة الأحداث تنفيذ إجراءات النسخ الاحتياطي والاستعادة بشكل صحيح لحماية بياناتها المنظمة إلى جانب استراتيجيتها لتخزين S3. للقيام بذلك، انتقل إلى خدمة S3 داخل AWS واضغط على "إنشاء دلو". سيتم تحفيزك لتعيين اسم لدلوك وتعيين المنطقة – تأكد من استخدام نفس المنطقة مثل ALB ووظيفة lambda الخاصة بك. عندما يتم إنشاء S3 bucket الخاص بك، سيكون فارغًا – إذا كنت ترغب في تنظيم البيانات داخل مجلد، يمكنك إما إنشاء الدليل المحدد الآن، أو سيتم إنشاء الدليل عندما تقوم وظيفة lambda الخاصة بك بتخزين الملف. في هذا المثال، أسمينا S3 bucket الخاص بنا "bird-webhooks" وأنشأنا مجلدًا باسم "B Event Data" لتخزين بيانات الحدث لدينا – سترى هذه الأسماء مشار إليها في وظيفة lambda أدناه.
قبل إنشاء موزع التحميل الخاص بنا لقبول البيانات، أو وظيفة lambda الخاصة بنا لتخزين البيانات، نحتاج أولاً إلى إنشاء S3 bucket الخاص بنا حيث سيتم تخزين البيانات. بينما توفر S3 تخزينًا ممتازًا لبيانات webhook، يجب على المنظمات التي تستخدم أيضًا قواعد بيانات PostgreSQL لمعالجة الأحداث تنفيذ إجراءات النسخ الاحتياطي والاستعادة بشكل صحيح لحماية بياناتها المنظمة إلى جانب استراتيجيتها لتخزين S3. للقيام بذلك، انتقل إلى خدمة S3 داخل AWS واضغط على "إنشاء دلو". سيتم تحفيزك لتعيين اسم لدلوك وتعيين المنطقة – تأكد من استخدام نفس المنطقة مثل ALB ووظيفة lambda الخاصة بك. عندما يتم إنشاء S3 bucket الخاص بك، سيكون فارغًا – إذا كنت ترغب في تنظيم البيانات داخل مجلد، يمكنك إما إنشاء الدليل المحدد الآن، أو سيتم إنشاء الدليل عندما تقوم وظيفة lambda الخاصة بك بتخزين الملف. في هذا المثال، أسمينا S3 bucket الخاص بنا "bird-webhooks" وأنشأنا مجلدًا باسم "B Event Data" لتخزين بيانات الحدث لدينا – سترى هذه الأسماء مشار إليها في وظيفة lambda أدناه.
إنشاء وظيفة Lambda لاستهلاك البيانات
سيتم تنفيذ المعالجة الفعلية وتخزين البيانات بواسطة وظيفة لامبدا يتم استدعاؤها بواسطة جهاز توزيع تحميل التطبيق الخاص بنا (ALB).
الخطوة الأولى هي إنشاء وظيفة لامبدا الخاصة بك عن طريق التنقل إلى خدمة لامبدا داخل AWS والنقر على "إنشاء وظيفة". ستتم مطالبتك بتعيين اسم لوظيفة لامبدا الخاصة بك واختيار لغة البرمجة التي ستكتب بها وظيفتك. في هذا المثال، نستخدم لغة بايثون كلغة وقت التشغيل.
الآن نحتاج إلى تطوير وظيفة لامبدا الخاصة بنا. للحظة، دعونا نفترض أن جهاز توزيع تحميل التطبيق الخاص بنا قد تم تكوينه ويرسل حمولة الويب إلى وظيفة لامبدا الخاصة بنا - ستتلقى لامبدا حمولة تشمل العناوين والجسم بالكامل. يتم تمرير الحمولة إلى وظيفة لامبدا الخاصة بنا باستخدام كائن "event" كقاموس. يمكنك الرجوع إلى العناوين والجسم للحمولة بشكل مستقل عن طريق الوصول إلى كائنات "headers" و"body" داخل الحمولة. في هذا المثال، سنقوم ببساطة بقراءة العنوان "x-messagesystems-batch-id"، حيث يتم إنشاء معرف الدفعة خصيصًا بواسطة Bird للدفعة، واستخدامه كاسم الملف عند تخزين الجسم كملف مسطح في S3؛ ومع ذلك، قد ترغب في إضافة وظائف إضافية مثل التحقق من الهوية أو معالجة الأخطاء، حسب الحاجة.
عند تخزين الحمولة في ملف مسطح على S3، سنحتاج إلى تحديد اسم دلو S3، الموقع، واسم الملف الذي سيتم تخزين بيانات الحمولة فيه. في وظيفة لامبدا النموذجية الخاصة بنا، نقوم بذلك داخل وظيفة "store_batch". في هذا المثال، سنقوم بتخزين الدفعة كاملة كملف واحد، مما يساعد على ضمان جمع وتخزين البيانات قبل انتهاء الاتصال HTTP بين Bird ونقطة النهاية الخاصة بك. بينما يمكنك ضبط إعدادات مهلة الاتصال على جهاز توزيع التحميل، لا توجد ضمانات بأن الاتصال لن ينتهي على جانب النقل (في هذه الحالة Bird) أو أن الاتصال لن يتم إنهاؤه قبل انتهاء وظيفة لامبدا الخاصة بك لتنفيذ. يعتبر من الممارسات الأفضل أن تحافظ على وظيفة المستهلك الخاصة بك فعالة قدر الإمكان وتحتفظ بأنشطة معالجة البيانات للعمليات اللاحقة حيثما كان ممكنًا - مثل تحويل الحمولة المصممة بصيغة JSON إلى ملف CSV، أو تحميل بيانات الحدث في قاعدة بيانات.
من المهم ملاحظة أنك قد تحتاج إلى تحديث الأذونات لوظيفة لامبدا الخاصة بك. ستحتاج دور التنفيذ الخاص بك إلى أذونات PutObject وGetObject لـ S3. من الممارسات الأفضل تطبيق مبدأ أقل امتياز، لذا أوصي بتعيين هذه الأذونات فقط لدلو S3 الذي ستخزن فيه حمولات الويب.
يمكن العثور على نموذج من وظيفة لامبدا المستهلك الخاصة بنا هنا.
كملاحظة سريعة حول معرف الدفعة: ستقوم Bird بتجميع الأحداث في حمولة واحدة، حيث قد تحتوي كل دفعة على 1 إلى 350 أو أكثر من سجلات الأحداث. سيتم إعطاء الدفعة معرف دفعة فريد، الذي يمكن استخدامه لعرض حالة الدفعة من خلال الاستفادة من واجهة برمجة التطبيقات لويب هوك الحدث أو داخل حساب Bird الخاص بك بالنقر على تدفق الويب هوك واختيار "حالة الدفعة". في حال عدم القدرة على تسليم حمولة الويب، مثل أثناء انتهاء مهلة الاتصال، ستقوم Bird تلقائيًا بإعادة محاولة الدفعة باستخدام نفس معرف الدفعة. يمكن أن يحدث هذا عندما تكون وظيفة لامبدا الخاصة بك قريبة من وقت الرحلة القصوى البالغ 10 ثوانٍ وسبب ذلك هو تحسين وظيفة المستهلك للحد من وقت التنفيذ.
لتنفيذ جميع أنشطة معالجة البيانات، أوصي بإنشاء وظيفة لامبدا منفصلة يتم تنفيذها كلما تم إنشاء ملف جديد في دلو S3 - بهذه الطريقة، يتم تنفيذ معالجة البيانات بشكل غير متزامن مع نقل البيانات، ولا يوجد خطر لفقدان البيانات بسبب اتصال تم إنهاؤه. أناقش وظيفة معالجة لامبدا في قسم لاحق.
سيتم تنفيذ المعالجة الفعلية وتخزين البيانات بواسطة وظيفة لامبدا يتم استدعاؤها بواسطة جهاز توزيع تحميل التطبيق الخاص بنا (ALB).
الخطوة الأولى هي إنشاء وظيفة لامبدا الخاصة بك عن طريق التنقل إلى خدمة لامبدا داخل AWS والنقر على "إنشاء وظيفة". ستتم مطالبتك بتعيين اسم لوظيفة لامبدا الخاصة بك واختيار لغة البرمجة التي ستكتب بها وظيفتك. في هذا المثال، نستخدم لغة بايثون كلغة وقت التشغيل.
الآن نحتاج إلى تطوير وظيفة لامبدا الخاصة بنا. للحظة، دعونا نفترض أن جهاز توزيع تحميل التطبيق الخاص بنا قد تم تكوينه ويرسل حمولة الويب إلى وظيفة لامبدا الخاصة بنا - ستتلقى لامبدا حمولة تشمل العناوين والجسم بالكامل. يتم تمرير الحمولة إلى وظيفة لامبدا الخاصة بنا باستخدام كائن "event" كقاموس. يمكنك الرجوع إلى العناوين والجسم للحمولة بشكل مستقل عن طريق الوصول إلى كائنات "headers" و"body" داخل الحمولة. في هذا المثال، سنقوم ببساطة بقراءة العنوان "x-messagesystems-batch-id"، حيث يتم إنشاء معرف الدفعة خصيصًا بواسطة Bird للدفعة، واستخدامه كاسم الملف عند تخزين الجسم كملف مسطح في S3؛ ومع ذلك، قد ترغب في إضافة وظائف إضافية مثل التحقق من الهوية أو معالجة الأخطاء، حسب الحاجة.
عند تخزين الحمولة في ملف مسطح على S3، سنحتاج إلى تحديد اسم دلو S3، الموقع، واسم الملف الذي سيتم تخزين بيانات الحمولة فيه. في وظيفة لامبدا النموذجية الخاصة بنا، نقوم بذلك داخل وظيفة "store_batch". في هذا المثال، سنقوم بتخزين الدفعة كاملة كملف واحد، مما يساعد على ضمان جمع وتخزين البيانات قبل انتهاء الاتصال HTTP بين Bird ونقطة النهاية الخاصة بك. بينما يمكنك ضبط إعدادات مهلة الاتصال على جهاز توزيع التحميل، لا توجد ضمانات بأن الاتصال لن ينتهي على جانب النقل (في هذه الحالة Bird) أو أن الاتصال لن يتم إنهاؤه قبل انتهاء وظيفة لامبدا الخاصة بك لتنفيذ. يعتبر من الممارسات الأفضل أن تحافظ على وظيفة المستهلك الخاصة بك فعالة قدر الإمكان وتحتفظ بأنشطة معالجة البيانات للعمليات اللاحقة حيثما كان ممكنًا - مثل تحويل الحمولة المصممة بصيغة JSON إلى ملف CSV، أو تحميل بيانات الحدث في قاعدة بيانات.
من المهم ملاحظة أنك قد تحتاج إلى تحديث الأذونات لوظيفة لامبدا الخاصة بك. ستحتاج دور التنفيذ الخاص بك إلى أذونات PutObject وGetObject لـ S3. من الممارسات الأفضل تطبيق مبدأ أقل امتياز، لذا أوصي بتعيين هذه الأذونات فقط لدلو S3 الذي ستخزن فيه حمولات الويب.
يمكن العثور على نموذج من وظيفة لامبدا المستهلك الخاصة بنا هنا.
كملاحظة سريعة حول معرف الدفعة: ستقوم Bird بتجميع الأحداث في حمولة واحدة، حيث قد تحتوي كل دفعة على 1 إلى 350 أو أكثر من سجلات الأحداث. سيتم إعطاء الدفعة معرف دفعة فريد، الذي يمكن استخدامه لعرض حالة الدفعة من خلال الاستفادة من واجهة برمجة التطبيقات لويب هوك الحدث أو داخل حساب Bird الخاص بك بالنقر على تدفق الويب هوك واختيار "حالة الدفعة". في حال عدم القدرة على تسليم حمولة الويب، مثل أثناء انتهاء مهلة الاتصال، ستقوم Bird تلقائيًا بإعادة محاولة الدفعة باستخدام نفس معرف الدفعة. يمكن أن يحدث هذا عندما تكون وظيفة لامبدا الخاصة بك قريبة من وقت الرحلة القصوى البالغ 10 ثوانٍ وسبب ذلك هو تحسين وظيفة المستهلك للحد من وقت التنفيذ.
لتنفيذ جميع أنشطة معالجة البيانات، أوصي بإنشاء وظيفة لامبدا منفصلة يتم تنفيذها كلما تم إنشاء ملف جديد في دلو S3 - بهذه الطريقة، يتم تنفيذ معالجة البيانات بشكل غير متزامن مع نقل البيانات، ولا يوجد خطر لفقدان البيانات بسبب اتصال تم إنهاؤه. أناقش وظيفة معالجة لامبدا في قسم لاحق.
سيتم تنفيذ المعالجة الفعلية وتخزين البيانات بواسطة وظيفة لامبدا يتم استدعاؤها بواسطة جهاز توزيع تحميل التطبيق الخاص بنا (ALB).
الخطوة الأولى هي إنشاء وظيفة لامبدا الخاصة بك عن طريق التنقل إلى خدمة لامبدا داخل AWS والنقر على "إنشاء وظيفة". ستتم مطالبتك بتعيين اسم لوظيفة لامبدا الخاصة بك واختيار لغة البرمجة التي ستكتب بها وظيفتك. في هذا المثال، نستخدم لغة بايثون كلغة وقت التشغيل.
الآن نحتاج إلى تطوير وظيفة لامبدا الخاصة بنا. للحظة، دعونا نفترض أن جهاز توزيع تحميل التطبيق الخاص بنا قد تم تكوينه ويرسل حمولة الويب إلى وظيفة لامبدا الخاصة بنا - ستتلقى لامبدا حمولة تشمل العناوين والجسم بالكامل. يتم تمرير الحمولة إلى وظيفة لامبدا الخاصة بنا باستخدام كائن "event" كقاموس. يمكنك الرجوع إلى العناوين والجسم للحمولة بشكل مستقل عن طريق الوصول إلى كائنات "headers" و"body" داخل الحمولة. في هذا المثال، سنقوم ببساطة بقراءة العنوان "x-messagesystems-batch-id"، حيث يتم إنشاء معرف الدفعة خصيصًا بواسطة Bird للدفعة، واستخدامه كاسم الملف عند تخزين الجسم كملف مسطح في S3؛ ومع ذلك، قد ترغب في إضافة وظائف إضافية مثل التحقق من الهوية أو معالجة الأخطاء، حسب الحاجة.
عند تخزين الحمولة في ملف مسطح على S3، سنحتاج إلى تحديد اسم دلو S3، الموقع، واسم الملف الذي سيتم تخزين بيانات الحمولة فيه. في وظيفة لامبدا النموذجية الخاصة بنا، نقوم بذلك داخل وظيفة "store_batch". في هذا المثال، سنقوم بتخزين الدفعة كاملة كملف واحد، مما يساعد على ضمان جمع وتخزين البيانات قبل انتهاء الاتصال HTTP بين Bird ونقطة النهاية الخاصة بك. بينما يمكنك ضبط إعدادات مهلة الاتصال على جهاز توزيع التحميل، لا توجد ضمانات بأن الاتصال لن ينتهي على جانب النقل (في هذه الحالة Bird) أو أن الاتصال لن يتم إنهاؤه قبل انتهاء وظيفة لامبدا الخاصة بك لتنفيذ. يعتبر من الممارسات الأفضل أن تحافظ على وظيفة المستهلك الخاصة بك فعالة قدر الإمكان وتحتفظ بأنشطة معالجة البيانات للعمليات اللاحقة حيثما كان ممكنًا - مثل تحويل الحمولة المصممة بصيغة JSON إلى ملف CSV، أو تحميل بيانات الحدث في قاعدة بيانات.
من المهم ملاحظة أنك قد تحتاج إلى تحديث الأذونات لوظيفة لامبدا الخاصة بك. ستحتاج دور التنفيذ الخاص بك إلى أذونات PutObject وGetObject لـ S3. من الممارسات الأفضل تطبيق مبدأ أقل امتياز، لذا أوصي بتعيين هذه الأذونات فقط لدلو S3 الذي ستخزن فيه حمولات الويب.
يمكن العثور على نموذج من وظيفة لامبدا المستهلك الخاصة بنا هنا.
كملاحظة سريعة حول معرف الدفعة: ستقوم Bird بتجميع الأحداث في حمولة واحدة، حيث قد تحتوي كل دفعة على 1 إلى 350 أو أكثر من سجلات الأحداث. سيتم إعطاء الدفعة معرف دفعة فريد، الذي يمكن استخدامه لعرض حالة الدفعة من خلال الاستفادة من واجهة برمجة التطبيقات لويب هوك الحدث أو داخل حساب Bird الخاص بك بالنقر على تدفق الويب هوك واختيار "حالة الدفعة". في حال عدم القدرة على تسليم حمولة الويب، مثل أثناء انتهاء مهلة الاتصال، ستقوم Bird تلقائيًا بإعادة محاولة الدفعة باستخدام نفس معرف الدفعة. يمكن أن يحدث هذا عندما تكون وظيفة لامبدا الخاصة بك قريبة من وقت الرحلة القصوى البالغ 10 ثوانٍ وسبب ذلك هو تحسين وظيفة المستهلك للحد من وقت التنفيذ.
لتنفيذ جميع أنشطة معالجة البيانات، أوصي بإنشاء وظيفة لامبدا منفصلة يتم تنفيذها كلما تم إنشاء ملف جديد في دلو S3 - بهذه الطريقة، يتم تنفيذ معالجة البيانات بشكل غير متزامن مع نقل البيانات، ولا يوجد خطر لفقدان البيانات بسبب اتصال تم إنهاؤه. أناقش وظيفة معالجة لامبدا في قسم لاحق.
إنشاء موازن تحميل التطبيقات
للحصول على حمولة webhook، نحتاج إلى توفير نقطة نهاية لإرسال الحمولة إليها. نقوم بذلك عن طريق إنشاء موزع تحميل التطبيقات داخل AWS عن طريق الانتقال إلى EC2 > Load Balancers والنقر على "Create Load Balancer." سيتم مطالبتك باختيار نوع موزع التحميل الذي ترغب في إنشائه – لهذا الغرض، نريد إنشاء موزع تحميل تطبيقات. نحتاج إلى استخدام موزع تحميل التطبيقات (ALB) لبناء مستهلكنا لأن رسائل event webhook سيتم إرسالها كطلب HTTP، وتُستخدم موزعات تحميل التطبيقات لتوجيه طلبات HTTP داخل AWS. يمكننا تنفيذ بوابة HTTP كبديل؛ ومع ذلك، نستخدم ALB لهذا المشروع لأنه أكثر خفة في الوزن وفعالية من حيث التكلفة من بوابة HTTP. من المهم أن نلاحظ أنه إذا اخترت استخدام بوابة HTTP، قد يختلف شكل الحدث عن ALB، وبالتالي سيتعين على دالة lambda التعامل مع كائن الطلب وفقًا لذلك.
بمجرد إنشاء ALB الخاص بك، ستتم مطالبتك بتعيين اسم لـ ALB وتكوين المخطط وإعدادات الوصول/الأمان – نظرًا لأننا نخطط لاستقبال بيانات الأحداث من مصدر خارجي (Bird)، سنرغب في أن يكون ALB موجهًا للإنترنت. تحت "Listeners and routing," يجب أن يستمع ALB إلى HTTPS على المنفذ 443، ونريد إنشاء مجموعة هدف تشير إلى دالة lambda الخاصة بنا حتى يقوم ALB بإرسال الطلبات الواردة إلى دالة lambda المستهلك التي أنشأناها أعلاه. تحتاج أيضًا إلى التأكد من أن مجموعة الأمان لديها إذن بقبول الحركة عبر المنفذ 443.
للحصول على حمولة webhook، نحتاج إلى توفير نقطة نهاية لإرسال الحمولة إليها. نقوم بذلك عن طريق إنشاء موزع تحميل التطبيقات داخل AWS عن طريق الانتقال إلى EC2 > Load Balancers والنقر على "Create Load Balancer." سيتم مطالبتك باختيار نوع موزع التحميل الذي ترغب في إنشائه – لهذا الغرض، نريد إنشاء موزع تحميل تطبيقات. نحتاج إلى استخدام موزع تحميل التطبيقات (ALB) لبناء مستهلكنا لأن رسائل event webhook سيتم إرسالها كطلب HTTP، وتُستخدم موزعات تحميل التطبيقات لتوجيه طلبات HTTP داخل AWS. يمكننا تنفيذ بوابة HTTP كبديل؛ ومع ذلك، نستخدم ALB لهذا المشروع لأنه أكثر خفة في الوزن وفعالية من حيث التكلفة من بوابة HTTP. من المهم أن نلاحظ أنه إذا اخترت استخدام بوابة HTTP، قد يختلف شكل الحدث عن ALB، وبالتالي سيتعين على دالة lambda التعامل مع كائن الطلب وفقًا لذلك.
بمجرد إنشاء ALB الخاص بك، ستتم مطالبتك بتعيين اسم لـ ALB وتكوين المخطط وإعدادات الوصول/الأمان – نظرًا لأننا نخطط لاستقبال بيانات الأحداث من مصدر خارجي (Bird)، سنرغب في أن يكون ALB موجهًا للإنترنت. تحت "Listeners and routing," يجب أن يستمع ALB إلى HTTPS على المنفذ 443، ونريد إنشاء مجموعة هدف تشير إلى دالة lambda الخاصة بنا حتى يقوم ALB بإرسال الطلبات الواردة إلى دالة lambda المستهلك التي أنشأناها أعلاه. تحتاج أيضًا إلى التأكد من أن مجموعة الأمان لديها إذن بقبول الحركة عبر المنفذ 443.
للحصول على حمولة webhook، نحتاج إلى توفير نقطة نهاية لإرسال الحمولة إليها. نقوم بذلك عن طريق إنشاء موزع تحميل التطبيقات داخل AWS عن طريق الانتقال إلى EC2 > Load Balancers والنقر على "Create Load Balancer." سيتم مطالبتك باختيار نوع موزع التحميل الذي ترغب في إنشائه – لهذا الغرض، نريد إنشاء موزع تحميل تطبيقات. نحتاج إلى استخدام موزع تحميل التطبيقات (ALB) لبناء مستهلكنا لأن رسائل event webhook سيتم إرسالها كطلب HTTP، وتُستخدم موزعات تحميل التطبيقات لتوجيه طلبات HTTP داخل AWS. يمكننا تنفيذ بوابة HTTP كبديل؛ ومع ذلك، نستخدم ALB لهذا المشروع لأنه أكثر خفة في الوزن وفعالية من حيث التكلفة من بوابة HTTP. من المهم أن نلاحظ أنه إذا اخترت استخدام بوابة HTTP، قد يختلف شكل الحدث عن ALB، وبالتالي سيتعين على دالة lambda التعامل مع كائن الطلب وفقًا لذلك.
بمجرد إنشاء ALB الخاص بك، ستتم مطالبتك بتعيين اسم لـ ALB وتكوين المخطط وإعدادات الوصول/الأمان – نظرًا لأننا نخطط لاستقبال بيانات الأحداث من مصدر خارجي (Bird)، سنرغب في أن يكون ALB موجهًا للإنترنت. تحت "Listeners and routing," يجب أن يستمع ALB إلى HTTPS على المنفذ 443، ونريد إنشاء مجموعة هدف تشير إلى دالة lambda الخاصة بنا حتى يقوم ALB بإرسال الطلبات الواردة إلى دالة lambda المستهلك التي أنشأناها أعلاه. تحتاج أيضًا إلى التأكد من أن مجموعة الأمان لديها إذن بقبول الحركة عبر المنفذ 443.
إنشاء سجل DNS لموازن التحميل
لتسهيل استخدامنا لـ ALB كنقطة نهاية، سننشئ سجلاً A في DNS يشير إلى ALB. لهذا، يمكننا استخدام خدمة AWS Route 53 (أو مزود DNS الحالي لديك) وإنشاء سجل A لاسم المضيف الذي ترغب في استخدامه كنقطة نهاية (مثل spevents.<your_domain>). عند العمل مع DNS على نطاق واسع في AWS، كن على علم بأن هناك حدود DNS غير موثقة يمكن أن تؤثر على التطبيقات ذات الحجم الكبير، خاصة تلك التي تتعامل مع كميات كبيرة من حركة المرور الخارجة مثل أنظمة تسليم البريد الإلكتروني. يجب تكوين سجل A للإشارة إلى ALB الذي أنشأناه. إذا كنت تستخدم Route 53 لإدارة سجلات DNS، فيمكنك الإشارة مباشرة إلى مثيل ALB من خلال تفعيل "Alias" واختيار ALB؛ بخلاف ذلك، إذا كنت تستخدم مزود DNS خارجي، فيجب عليك توجيه سجل A إلى عنوان IP العام لمثيل ALB.
أوصي باستخدام أداة مثل Postman لاختبار أن كل شيء قد تم تكوينه بشكل صحيح قبل تمكين Webhook الخاص بـ Bird. يمكنك تقديم طلب POST إلى نقطة النهاية الخاصة بك وتأكيد تلقي الرد. إذا لم يُرجع طلب POST الخاص بك ردًا، فقد تحتاج إلى التحقق مرة أخرى من أن ALB الخاص بك يستمع إلى المنفذ الصحيح.
لتسهيل استخدامنا لـ ALB كنقطة نهاية، سننشئ سجلاً A في DNS يشير إلى ALB. لهذا، يمكننا استخدام خدمة AWS Route 53 (أو مزود DNS الحالي لديك) وإنشاء سجل A لاسم المضيف الذي ترغب في استخدامه كنقطة نهاية (مثل spevents.<your_domain>). عند العمل مع DNS على نطاق واسع في AWS، كن على علم بأن هناك حدود DNS غير موثقة يمكن أن تؤثر على التطبيقات ذات الحجم الكبير، خاصة تلك التي تتعامل مع كميات كبيرة من حركة المرور الخارجة مثل أنظمة تسليم البريد الإلكتروني. يجب تكوين سجل A للإشارة إلى ALB الذي أنشأناه. إذا كنت تستخدم Route 53 لإدارة سجلات DNS، فيمكنك الإشارة مباشرة إلى مثيل ALB من خلال تفعيل "Alias" واختيار ALB؛ بخلاف ذلك، إذا كنت تستخدم مزود DNS خارجي، فيجب عليك توجيه سجل A إلى عنوان IP العام لمثيل ALB.
أوصي باستخدام أداة مثل Postman لاختبار أن كل شيء قد تم تكوينه بشكل صحيح قبل تمكين Webhook الخاص بـ Bird. يمكنك تقديم طلب POST إلى نقطة النهاية الخاصة بك وتأكيد تلقي الرد. إذا لم يُرجع طلب POST الخاص بك ردًا، فقد تحتاج إلى التحقق مرة أخرى من أن ALB الخاص بك يستمع إلى المنفذ الصحيح.
لتسهيل استخدامنا لـ ALB كنقطة نهاية، سننشئ سجلاً A في DNS يشير إلى ALB. لهذا، يمكننا استخدام خدمة AWS Route 53 (أو مزود DNS الحالي لديك) وإنشاء سجل A لاسم المضيف الذي ترغب في استخدامه كنقطة نهاية (مثل spevents.<your_domain>). عند العمل مع DNS على نطاق واسع في AWS، كن على علم بأن هناك حدود DNS غير موثقة يمكن أن تؤثر على التطبيقات ذات الحجم الكبير، خاصة تلك التي تتعامل مع كميات كبيرة من حركة المرور الخارجة مثل أنظمة تسليم البريد الإلكتروني. يجب تكوين سجل A للإشارة إلى ALB الذي أنشأناه. إذا كنت تستخدم Route 53 لإدارة سجلات DNS، فيمكنك الإشارة مباشرة إلى مثيل ALB من خلال تفعيل "Alias" واختيار ALB؛ بخلاف ذلك، إذا كنت تستخدم مزود DNS خارجي، فيجب عليك توجيه سجل A إلى عنوان IP العام لمثيل ALB.
أوصي باستخدام أداة مثل Postman لاختبار أن كل شيء قد تم تكوينه بشكل صحيح قبل تمكين Webhook الخاص بـ Bird. يمكنك تقديم طلب POST إلى نقطة النهاية الخاصة بك وتأكيد تلقي الرد. إذا لم يُرجع طلب POST الخاص بك ردًا، فقد تحتاج إلى التحقق مرة أخرى من أن ALB الخاص بك يستمع إلى المنفذ الصحيح.
إنشاء Webhook لـ Bird
الآن نحن جاهزون لإنشاء webhook في Bird واستخدام اسم المضيف المحدد بواسطة سجل A أعلاه كنقطة نهاية مستهدفة لدينا. لإنشاء الويب هوك، قم بالانتقال إلى قسم الويب هوك داخل حساب Bird الخاص بك وانقر على "Create Webhook". سيُطلب منك تعيين اسم لويب هوك الخاص بك وتقديم عنوان URL مستهدف - يجب أن يكون الهدف هو اسم المضيف لسجل A الذي قمت بإنشائه سابقًا. لاحظ أن عنوان URL المستهدف قد يتطلب تضمين "HTTPS://" في عنوان URL.
بمجرد الانتهاء، تحقق من تحديد الحساب الفرعي والأحداث الصحيحة، واضغط على "Create Webhook" لحفظ تكوينك. ستكون بيانات الحدث لجميع أنواع الأحداث المحددة الآن تنقل إلى عنوان URL المستهدف لدينا ويتم استهلاكها بواسطة ALB للمعالجة التبادلية.
الآن نحن جاهزون لإنشاء webhook في Bird واستخدام اسم المضيف المحدد بواسطة سجل A أعلاه كنقطة نهاية مستهدفة لدينا. لإنشاء الويب هوك، قم بالانتقال إلى قسم الويب هوك داخل حساب Bird الخاص بك وانقر على "Create Webhook". سيُطلب منك تعيين اسم لويب هوك الخاص بك وتقديم عنوان URL مستهدف - يجب أن يكون الهدف هو اسم المضيف لسجل A الذي قمت بإنشائه سابقًا. لاحظ أن عنوان URL المستهدف قد يتطلب تضمين "HTTPS://" في عنوان URL.
بمجرد الانتهاء، تحقق من تحديد الحساب الفرعي والأحداث الصحيحة، واضغط على "Create Webhook" لحفظ تكوينك. ستكون بيانات الحدث لجميع أنواع الأحداث المحددة الآن تنقل إلى عنوان URL المستهدف لدينا ويتم استهلاكها بواسطة ALB للمعالجة التبادلية.
الآن نحن جاهزون لإنشاء webhook في Bird واستخدام اسم المضيف المحدد بواسطة سجل A أعلاه كنقطة نهاية مستهدفة لدينا. لإنشاء الويب هوك، قم بالانتقال إلى قسم الويب هوك داخل حساب Bird الخاص بك وانقر على "Create Webhook". سيُطلب منك تعيين اسم لويب هوك الخاص بك وتقديم عنوان URL مستهدف - يجب أن يكون الهدف هو اسم المضيف لسجل A الذي قمت بإنشائه سابقًا. لاحظ أن عنوان URL المستهدف قد يتطلب تضمين "HTTPS://" في عنوان URL.
بمجرد الانتهاء، تحقق من تحديد الحساب الفرعي والأحداث الصحيحة، واضغط على "Create Webhook" لحفظ تكوينك. ستكون بيانات الحدث لجميع أنواع الأحداث المحددة الآن تنقل إلى عنوان URL المستهدف لدينا ويتم استهلاكها بواسطة ALB للمعالجة التبادلية.
معالجة بيانات حدث Webhook
اعتمادًا على الغرض المقصود من تخزين بيانات حدث Bird، قد يتم تلبية متطلباتك ببساطة عن طريق تخزين الحمولة JSON كملف مسطح. قد يكون لديك أيضًا عملية ETL متقدمة قادرة على استهلاك وتحميل البيانات بتنسيق JSON. في كلتا الحالتين، قد تتمكن من استخدام الملف المسطح الذي أنشأته عملية lambda الخاصة بنا كما هو موضّح أعلاه.
بدلاً من ذلك، قد تحتاج إلى تحويل البيانات - مثل التحويل من JSON إلى تنسيق CSV - أو تحميل البيانات مباشرة في قاعدة بيانات. في هذا المثال، سنقوم بإنشاء وظيفة lambda بسيطة لتحويل بيانات webhook من تنسيق JSON الأصلي إلى ملف CSV يمكن تحميله في قاعدة بيانات.
اعتمادًا على الغرض المقصود من تخزين بيانات حدث Bird، قد يتم تلبية متطلباتك ببساطة عن طريق تخزين الحمولة JSON كملف مسطح. قد يكون لديك أيضًا عملية ETL متقدمة قادرة على استهلاك وتحميل البيانات بتنسيق JSON. في كلتا الحالتين، قد تتمكن من استخدام الملف المسطح الذي أنشأته عملية lambda الخاصة بنا كما هو موضّح أعلاه.
بدلاً من ذلك، قد تحتاج إلى تحويل البيانات - مثل التحويل من JSON إلى تنسيق CSV - أو تحميل البيانات مباشرة في قاعدة بيانات. في هذا المثال، سنقوم بإنشاء وظيفة lambda بسيطة لتحويل بيانات webhook من تنسيق JSON الأصلي إلى ملف CSV يمكن تحميله في قاعدة بيانات.
اعتمادًا على الغرض المقصود من تخزين بيانات حدث Bird، قد يتم تلبية متطلباتك ببساطة عن طريق تخزين الحمولة JSON كملف مسطح. قد يكون لديك أيضًا عملية ETL متقدمة قادرة على استهلاك وتحميل البيانات بتنسيق JSON. في كلتا الحالتين، قد تتمكن من استخدام الملف المسطح الذي أنشأته عملية lambda الخاصة بنا كما هو موضّح أعلاه.
بدلاً من ذلك، قد تحتاج إلى تحويل البيانات - مثل التحويل من JSON إلى تنسيق CSV - أو تحميل البيانات مباشرة في قاعدة بيانات. في هذا المثال، سنقوم بإنشاء وظيفة lambda بسيطة لتحويل بيانات webhook من تنسيق JSON الأصلي إلى ملف CSV يمكن تحميله في قاعدة بيانات.
إنشاء وظيفة لامبدا لمعالجة البيانات
كما هو الحال مع دالة lambda لاستهلاك بيانات webhook، نحتاج إلى إنشاء دالة lambda جديدة عن طريق التنقل إلى خدمة Lambda ضمن AWS والضغط على “Create Function.” ستتم تفعيل هذه الدالة الجديدة عندما يتم إنشاء ملف جديد في دلو S3 الخاص بنا - ستقوم بقراءة البيانات وتحويلها إلى ملف CSV جديد.
تقبل دالة lambda معلومات الملف كحدث. في دالة lambda النموذجية، ستلاحظ أن لدينا أولاً سلسلة من الفحوصات للتحقق من أن البيانات كاملة ومنسقة كما هو متوقع. بعد ذلك، نقوم بتحويل JSON payload إلى ملف CSV باستخدام مكتبة “csv” والكتابة إلى ملف مؤقت. يمكن لدوال Lambda فقط كتابة الملفات المحلية إلى دليل “/tmp” لذلك نقوم بإنشاء ملف CSV مؤقت ونسميه بالتسمية <batch_id>.csv. السبب في استخدام batch_id هنا هو ببساطة لضمان أن أي عمليات متوازية تعمل نتيجة لتلقي العديد من webhook payloads لن تتداخل مع بعضها البعض، حيث سيكون لكل batch_id webhook مسمى مميز.
بمجرد تحويل البيانات بالكامل إلى CSV، نقرأ بيانات CSV كتيار بايت، نحذف الملف المؤقت، ونحفظ بيانات CSV كملف جديد على S3. من المهم ملاحظة أن دلو S3 مختلف مطلوب للإخراج، وإلا فقد نخاطر بإنشاء حلقة متكررة يمكن أن تؤدي إلى زيادة استخدام lambda وزيادة التكاليف. سنحتاج إلى تحديد دلو S3 والموقع الذي نريد أن يتم تخزين ملف CSV فيه ضمن دالة lambda الخاصة بنا. اتبع نفس الإجراءات كما في السابق لإنشاء دلو S3 جديد لتخزين ملف CSV الخاص بنا.
لاحظ أن دليل tmp محدود بمساحة قدرها 512 ميجابايت، لذلك من المهم أن يتم حذف الملف المؤقت بعد ذلك لتوفير مساحة كافية للتنفيذات المستقبلية. السبب في استخدام ملف مؤقت، بدلاً من الكتابة مباشرة إلى S3، هو لتبسيط الاتصال بـ S3 عن طريق وجود طلب واحد.
مثل دالة lambda التي تستهلكها، قد تحتاج إلى تحديث الأذونات لدالة lambda العملية الخاصة بك. تتطلب هذه الدالة lambda أن يكون لدورها التنفيذي حقوق GetObject للدلو S3 المدخل، وحقوق كل من PutObject وGetObject للدلو S3 المخرجات.
يمكن العثور على عينة من دالة lambda الخاصة بالمعالجة هنا.
كما هو الحال مع دالة lambda لاستهلاك بيانات webhook، نحتاج إلى إنشاء دالة lambda جديدة عن طريق التنقل إلى خدمة Lambda ضمن AWS والضغط على “Create Function.” ستتم تفعيل هذه الدالة الجديدة عندما يتم إنشاء ملف جديد في دلو S3 الخاص بنا - ستقوم بقراءة البيانات وتحويلها إلى ملف CSV جديد.
تقبل دالة lambda معلومات الملف كحدث. في دالة lambda النموذجية، ستلاحظ أن لدينا أولاً سلسلة من الفحوصات للتحقق من أن البيانات كاملة ومنسقة كما هو متوقع. بعد ذلك، نقوم بتحويل JSON payload إلى ملف CSV باستخدام مكتبة “csv” والكتابة إلى ملف مؤقت. يمكن لدوال Lambda فقط كتابة الملفات المحلية إلى دليل “/tmp” لذلك نقوم بإنشاء ملف CSV مؤقت ونسميه بالتسمية <batch_id>.csv. السبب في استخدام batch_id هنا هو ببساطة لضمان أن أي عمليات متوازية تعمل نتيجة لتلقي العديد من webhook payloads لن تتداخل مع بعضها البعض، حيث سيكون لكل batch_id webhook مسمى مميز.
بمجرد تحويل البيانات بالكامل إلى CSV، نقرأ بيانات CSV كتيار بايت، نحذف الملف المؤقت، ونحفظ بيانات CSV كملف جديد على S3. من المهم ملاحظة أن دلو S3 مختلف مطلوب للإخراج، وإلا فقد نخاطر بإنشاء حلقة متكررة يمكن أن تؤدي إلى زيادة استخدام lambda وزيادة التكاليف. سنحتاج إلى تحديد دلو S3 والموقع الذي نريد أن يتم تخزين ملف CSV فيه ضمن دالة lambda الخاصة بنا. اتبع نفس الإجراءات كما في السابق لإنشاء دلو S3 جديد لتخزين ملف CSV الخاص بنا.
لاحظ أن دليل tmp محدود بمساحة قدرها 512 ميجابايت، لذلك من المهم أن يتم حذف الملف المؤقت بعد ذلك لتوفير مساحة كافية للتنفيذات المستقبلية. السبب في استخدام ملف مؤقت، بدلاً من الكتابة مباشرة إلى S3، هو لتبسيط الاتصال بـ S3 عن طريق وجود طلب واحد.
مثل دالة lambda التي تستهلكها، قد تحتاج إلى تحديث الأذونات لدالة lambda العملية الخاصة بك. تتطلب هذه الدالة lambda أن يكون لدورها التنفيذي حقوق GetObject للدلو S3 المدخل، وحقوق كل من PutObject وGetObject للدلو S3 المخرجات.
يمكن العثور على عينة من دالة lambda الخاصة بالمعالجة هنا.
كما هو الحال مع دالة lambda لاستهلاك بيانات webhook، نحتاج إلى إنشاء دالة lambda جديدة عن طريق التنقل إلى خدمة Lambda ضمن AWS والضغط على “Create Function.” ستتم تفعيل هذه الدالة الجديدة عندما يتم إنشاء ملف جديد في دلو S3 الخاص بنا - ستقوم بقراءة البيانات وتحويلها إلى ملف CSV جديد.
تقبل دالة lambda معلومات الملف كحدث. في دالة lambda النموذجية، ستلاحظ أن لدينا أولاً سلسلة من الفحوصات للتحقق من أن البيانات كاملة ومنسقة كما هو متوقع. بعد ذلك، نقوم بتحويل JSON payload إلى ملف CSV باستخدام مكتبة “csv” والكتابة إلى ملف مؤقت. يمكن لدوال Lambda فقط كتابة الملفات المحلية إلى دليل “/tmp” لذلك نقوم بإنشاء ملف CSV مؤقت ونسميه بالتسمية <batch_id>.csv. السبب في استخدام batch_id هنا هو ببساطة لضمان أن أي عمليات متوازية تعمل نتيجة لتلقي العديد من webhook payloads لن تتداخل مع بعضها البعض، حيث سيكون لكل batch_id webhook مسمى مميز.
بمجرد تحويل البيانات بالكامل إلى CSV، نقرأ بيانات CSV كتيار بايت، نحذف الملف المؤقت، ونحفظ بيانات CSV كملف جديد على S3. من المهم ملاحظة أن دلو S3 مختلف مطلوب للإخراج، وإلا فقد نخاطر بإنشاء حلقة متكررة يمكن أن تؤدي إلى زيادة استخدام lambda وزيادة التكاليف. سنحتاج إلى تحديد دلو S3 والموقع الذي نريد أن يتم تخزين ملف CSV فيه ضمن دالة lambda الخاصة بنا. اتبع نفس الإجراءات كما في السابق لإنشاء دلو S3 جديد لتخزين ملف CSV الخاص بنا.
لاحظ أن دليل tmp محدود بمساحة قدرها 512 ميجابايت، لذلك من المهم أن يتم حذف الملف المؤقت بعد ذلك لتوفير مساحة كافية للتنفيذات المستقبلية. السبب في استخدام ملف مؤقت، بدلاً من الكتابة مباشرة إلى S3، هو لتبسيط الاتصال بـ S3 عن طريق وجود طلب واحد.
مثل دالة lambda التي تستهلكها، قد تحتاج إلى تحديث الأذونات لدالة lambda العملية الخاصة بك. تتطلب هذه الدالة lambda أن يكون لدورها التنفيذي حقوق GetObject للدلو S3 المدخل، وحقوق كل من PutObject وGetObject للدلو S3 المخرجات.
يمكن العثور على عينة من دالة lambda الخاصة بالمعالجة هنا.
تهيئة Lambda للتنفيذ عند تخزين بيانات جديدة على S3
الآن بعد أن تم إنشاء دالة لامدا لتحويل الملف من JSON إلى CSV، نحتاج إلى تكوينها لتعمل عند إنشاء ملف جديد في دلو S3 الخاص بنا. للقيام بذلك، نحتاج إلى إضافة مُشغل إلى دالة لامدا الخاصة بنا عن طريق فتح دالة لامدا الخاصة بنا والنقر فوق "إضافة مُشغل" في أعلى الصفحة. حدد "S3" وقدم اسم دلو S3 حيث يتم تخزين حمولة webhook الخام. لديك أيضًا الخيار لتحديد بادئة الملف و/أو لاحقة لتصفية الملفات. بمجرد تكوين الإعدادات، يمكنك إضافة المُشغل بالنقر فوق "إضافة" في أسفل الصفحة. الآن ستقوم دالة لامدا للمعالجة بتنفيذ كلما تمت إضافة ملف جديد إلى دلو S3 الخاص بك.
الآن بعد أن تم إنشاء دالة لامدا لتحويل الملف من JSON إلى CSV، نحتاج إلى تكوينها لتعمل عند إنشاء ملف جديد في دلو S3 الخاص بنا. للقيام بذلك، نحتاج إلى إضافة مُشغل إلى دالة لامدا الخاصة بنا عن طريق فتح دالة لامدا الخاصة بنا والنقر فوق "إضافة مُشغل" في أعلى الصفحة. حدد "S3" وقدم اسم دلو S3 حيث يتم تخزين حمولة webhook الخام. لديك أيضًا الخيار لتحديد بادئة الملف و/أو لاحقة لتصفية الملفات. بمجرد تكوين الإعدادات، يمكنك إضافة المُشغل بالنقر فوق "إضافة" في أسفل الصفحة. الآن ستقوم دالة لامدا للمعالجة بتنفيذ كلما تمت إضافة ملف جديد إلى دلو S3 الخاص بك.
الآن بعد أن تم إنشاء دالة لامدا لتحويل الملف من JSON إلى CSV، نحتاج إلى تكوينها لتعمل عند إنشاء ملف جديد في دلو S3 الخاص بنا. للقيام بذلك، نحتاج إلى إضافة مُشغل إلى دالة لامدا الخاصة بنا عن طريق فتح دالة لامدا الخاصة بنا والنقر فوق "إضافة مُشغل" في أعلى الصفحة. حدد "S3" وقدم اسم دلو S3 حيث يتم تخزين حمولة webhook الخام. لديك أيضًا الخيار لتحديد بادئة الملف و/أو لاحقة لتصفية الملفات. بمجرد تكوين الإعدادات، يمكنك إضافة المُشغل بالنقر فوق "إضافة" في أسفل الصفحة. الآن ستقوم دالة لامدا للمعالجة بتنفيذ كلما تمت إضافة ملف جديد إلى دلو S3 الخاص بك.
تحميل البيانات إلى قاعدة البيانات
في هذا المثال، لن أغطي تحميل البيانات إلى قاعدة بيانات بالتفصيل، ولكن إذا كنت تتبع هذا المثال فلديك بعض الخيارات:
قم بتحميل البيانات مباشرة إلى قاعدة البيانات الخاصة بك ضمن دالة المعالجة lambda الخاصة بك
استخدم ملف الـ CSV الخاص بك باستخدام عملية ETL المقررة
سواء كنت تستخدم خدمة قاعدة بيانات AWS، مثل RDS أو DynamoDB، أو لديك قاعدة بيانات PostgreSQL الخاصة بك (أو شبيهة بها)، يمكنك الاتصال بخدمة قاعدة البيانات الخاصة بك مباشرة من دالة المعالجة lambda الخاصة بك. على سبيل المثال، بالطريقة التي استخدمنا بها خدمة S3 باستخدام “boto3” في دالة lambda الخاصة بنا، يمكنك أيضًا استخدام “boto3” لاستدعاء RDS أو DynamoDB. يمكن أيضًا استخدام خدمة Athena التابعة لـ AWS لقراءة ملفات البيانات مباشرة من الملفات المسطحة والوصول إلى البيانات باستخدام لغة استعلام مشابهة لـ SQL. أوصي بالرجوع إلى الوثائق المتعلقة بالخدمة التي تستخدمها للحصول على مزيد من المعلومات حول كيفية القيام بذلك بشكل أفضل في بيئتك.
وبالمثل، هناك العديد من الخدمات المتاحة التي يمكن أن تساعد في استخدام ملفات CSV وتحميل البيانات في قاعدة بيانات. قد يكون لديك بالفعل عملية ETL مقررة يمكنك الاستفادة منها.
نأمل أن تكون هذه الإرشادات مفيدة لك - إرسال سعيد!
في هذا المثال، لن أغطي تحميل البيانات إلى قاعدة بيانات بالتفصيل، ولكن إذا كنت تتبع هذا المثال فلديك بعض الخيارات:
قم بتحميل البيانات مباشرة إلى قاعدة البيانات الخاصة بك ضمن دالة المعالجة lambda الخاصة بك
استخدم ملف الـ CSV الخاص بك باستخدام عملية ETL المقررة
سواء كنت تستخدم خدمة قاعدة بيانات AWS، مثل RDS أو DynamoDB، أو لديك قاعدة بيانات PostgreSQL الخاصة بك (أو شبيهة بها)، يمكنك الاتصال بخدمة قاعدة البيانات الخاصة بك مباشرة من دالة المعالجة lambda الخاصة بك. على سبيل المثال، بالطريقة التي استخدمنا بها خدمة S3 باستخدام “boto3” في دالة lambda الخاصة بنا، يمكنك أيضًا استخدام “boto3” لاستدعاء RDS أو DynamoDB. يمكن أيضًا استخدام خدمة Athena التابعة لـ AWS لقراءة ملفات البيانات مباشرة من الملفات المسطحة والوصول إلى البيانات باستخدام لغة استعلام مشابهة لـ SQL. أوصي بالرجوع إلى الوثائق المتعلقة بالخدمة التي تستخدمها للحصول على مزيد من المعلومات حول كيفية القيام بذلك بشكل أفضل في بيئتك.
وبالمثل، هناك العديد من الخدمات المتاحة التي يمكن أن تساعد في استخدام ملفات CSV وتحميل البيانات في قاعدة بيانات. قد يكون لديك بالفعل عملية ETL مقررة يمكنك الاستفادة منها.
نأمل أن تكون هذه الإرشادات مفيدة لك - إرسال سعيد!
في هذا المثال، لن أغطي تحميل البيانات إلى قاعدة بيانات بالتفصيل، ولكن إذا كنت تتبع هذا المثال فلديك بعض الخيارات:
قم بتحميل البيانات مباشرة إلى قاعدة البيانات الخاصة بك ضمن دالة المعالجة lambda الخاصة بك
استخدم ملف الـ CSV الخاص بك باستخدام عملية ETL المقررة
سواء كنت تستخدم خدمة قاعدة بيانات AWS، مثل RDS أو DynamoDB، أو لديك قاعدة بيانات PostgreSQL الخاصة بك (أو شبيهة بها)، يمكنك الاتصال بخدمة قاعدة البيانات الخاصة بك مباشرة من دالة المعالجة lambda الخاصة بك. على سبيل المثال، بالطريقة التي استخدمنا بها خدمة S3 باستخدام “boto3” في دالة lambda الخاصة بنا، يمكنك أيضًا استخدام “boto3” لاستدعاء RDS أو DynamoDB. يمكن أيضًا استخدام خدمة Athena التابعة لـ AWS لقراءة ملفات البيانات مباشرة من الملفات المسطحة والوصول إلى البيانات باستخدام لغة استعلام مشابهة لـ SQL. أوصي بالرجوع إلى الوثائق المتعلقة بالخدمة التي تستخدمها للحصول على مزيد من المعلومات حول كيفية القيام بذلك بشكل أفضل في بيئتك.
وبالمثل، هناك العديد من الخدمات المتاحة التي يمكن أن تساعد في استخدام ملفات CSV وتحميل البيانات في قاعدة بيانات. قد يكون لديك بالفعل عملية ETL مقررة يمكنك الاستفادة منها.
نأمل أن تكون هذه الإرشادات مفيدة لك - إرسال سعيد!
