أحداث واجهة برمجة تطبيقات البيع الآلي: معالجة التحديثات المتأخرة والمكررة دون احتساب المبيعات مرتين
رؤى WEIMI / تكامل البيانات
لا ينبغي أن يؤدي تلقي حدث ما مرتين إلى عمليتي بيع.
حدد هوية المعاملة وتوقيت الحدث والتسوية قبل ربط بيانات البيع بنظام التقارير الخاص بك.
هوية
ما هي المعاملة التي يصفها هذا التحديث؟
طلب
متى وقع الحدث ومتى وصل؟
مصالحة
كيف سيتم العثور على السجلات المفقودة أو غير المتناسقة؟
وافق على عقد البيانات وقم بتحديث القواعد قبل استيراد الأحداث إلى التقارير؛ فعملية تسليم الرسائل والنشاط التجاري هما عددان مختلفان.
01 / ملاحظات المشتري
ابدأ بعقد الحدث الفعلي الخاص بالمزود
قد توفر منصة البيع الآلي إشعارات بالأحداث، وتقارير دورية، أو واجهة استعلام. تأكد من الخدمات التي تدعمها المنصة المقترحة واطلع على وثائقها. لا تفترض أن وجود واجهة برمجة تطبيقات (API) يشمل روابط الويب، أو ضمان الطلبات، أو سجل بيانات كامل.
استفسر عن الأحداث التجارية المتاحة ومعنى كل منها. فعملية إنشاء الطلب، وتفويض الدفع، والتسليم الفعلي، والتسوية النهائية، كلها مراحل مختلفة. ولا ينبغي لنظام التقارير أن يحسب كل مرحلة كعملية بيع منفصلة.
يُحدد هذا الدليل أسئلة تصميم التكامل. ولا يدّعي أن منصة WEIMI معينة توفر حقول الأحداث أو ضمانات التسليم المذكورة هنا. تحقق من الواجهة الفعلية قبل بناء أي شيء حولها.
02 / ملاحظات المشتري
استخدم هوية معاملات ثابتة لسجلات الأعمال
يحتاج النظام المُستقبِل إلى مرجع موثوق يربط التحديثات المتعلقة بنفس المعاملة. استفسر عما إذا كان المصدر يُوفّر مُعرّفًا فريدًا للمعاملة، وكيف يتم تحديد نطاق هذا التفرّد. قد يتطلب مُعرّف الخزانة بالإضافة إلى تسلسل محلي معالجة مختلفة عن المرجع الفريد عالميًا.
يجب فصل هوية الأحداث حيثما توفرها واجهة المستخدم. قد تنتمي عدة أحداث إلى معاملة واحدة، وقد يمثل التسليم المتكرر الحدث نفسه. ينبغي لفريق التكامل تحديد قواعد قاعدة البيانات باستخدام العقد الفعلي بدلاً من التخمين بناءً على قيم نموذجية.
لا تستخدم اسم المنتج وسعره وتاريخ الشراء فقط كمفتاح فريد دون تقييم المخاطر. فقد يشتري عميلان نفس المنتج بنفس السعر في وقت متقارب. وقد يؤدي استخدام طريقة تقريبية إلى دمج عمليات شراء مشروعة أو إنشاء عمليات مكررة.
03 / ملاحظات المشتري
ميّز وقت الحدث عن وقت الاستلام
قد يصل التحديث بعد وقت تنفيذ الإجراء التجاري الذي يصفه. سجّل الطوابع الزمنية ذات الصلة التي توفرها واجهة المستخدم، بالإضافة إلى وقت استلام النظام للرسالة. استخدم معالجة واضحة للمناطق الزمنية لضمان بقاء التقارير قابلة للفهم في مختلف المواقع.
لا ينبغي اعتبار التحديث المتأخر عملية بيع جديدة تلقائيًا في الساعة الحالية إذا كان الهدف من المقياس هو تحديد وقت حدوث عمليات الشراء. حدد قاعدة الإبلاغ وكيف تؤثر البيانات المتأخرة على فترة سابقة.
إذا لم يُحدد المصدر التوقيت المطلوب لإعداد التقرير، فاذكر هذا القيد. لا تُصنّف مخطط وقت الاستلام على أنه وقت شراء العميل بدقة دون دليل. تبدأ دقة التقارير بفهم معنى الحقول المتاحة.
04 / ملاحظات المشتري
معالجة التحديثات المتكررة وفقًا للعقد
قد تعيد بعض واجهات المستخدم إرسال الإشعارات أو إرجاع السجلات التي سبق الاطلاع عليها في استعلام سابق. ينبغي على النظام المُستقبِل استخدام قواعد الهوية والحالة الموثقة لتجنب احتساب النشاط التجاري نفسه مرتين. تأكد من سلوك المُزوّد بدلاً من افتراض أن كل رسالة جديدة.
بالنسبة للمعاملة الافتراضية T42، يجب أن يؤدي استلام تحديث مكتمل مرتين إلى بقاء معاملة مكتملة واحدة في عرض الأعمال عندما تمثل كلتا الرسالتين نفس الحدث أو الحالة. مع ذلك، يجب أن يحتفظ النظام بمعلومات تشخيصية كافية للتحقيق في مشاكل التسليم.
لا تخلط بين تجاهل البيانات المكررة وتجاهل التصحيحات اللاحقة. قد يؤدي تحديث لاحق صحيح إلى تغيير نتيجة المعاملة أو إضافة تعديل ذي صلة. يحتاج التكامل إلى طريقة محددة لتطبيق التغييرات مع الاحتفاظ بسجل مناسب.
05 / ملاحظات المشتري
لا تدع ترتيب الوصول يطغى على الأدلة الأقوى
قد يتطلب الأمر تفسير التحديثات باستخدام معلومات التسلسل أو قواعد الحالة التي يحددها المزوّد. استفسر عما إذا كان الترتيب مضمونًا وكيف يعرض النظام التصحيحات. فبدون هذه التفاصيل، قد تؤدي رسالة متأخرة في مرحلة سابقة إلى ظهور معاملة مكتملة معلقة مرة أخرى.
أنشئ مراجعة لانتقالات الحالة مع فريق التكامل. حدد الانتقالات المسموح بها، والحالات غير المحسومة، ومصدر الصلاحية عند اختلاف السجلات. تجنب وضع قاعدة عامة مفادها أن كل حالة أكبر عدديًا أو وصول لاحق صحيحة دائمًا.
إذا كانت واجهة برمجة التطبيقات (API) تفتقر إلى المعلومات اللازمة لحل أي غموض، فيُرجى توجيهها إلى قسم التوفيق أو الدعم. لا ينبغي تصنيف سجل غير مؤكد ضمن فئة النجاح لمجرد تحقيق التوازن الإجمالي في لوحة المعلومات.
06 / ملاحظات المشتري
بناء المصالحة جنبًا إلى جنب مع البث المباشر
يمكن أن تساعد التغذية المباشرة في تسريع الاستجابة للعمليات، بينما يمكن للمقارنة الدورية تحديد السجلات المفقودة أو غير المتناسقة. استفسر عن تقارير المصادر أو الاستعلامات التاريخية المتاحة للمطابقة، وكيف يرتبط نطاقها بتدفق الأحداث.
قارن بين الفترات والتعريفات المتسقة. قد يُمثل تقرير مبيعات الآلات، وتقرير الدفع، وتسوية البنك مراحل أو مبالغ مختلفة. لذا، قم بمطابقتها من خلال المراجع ذات الصلة والقواعد الموثقة بدلاً من افتراض تطابق جميع المجاميع فوراً.
اختبر عمليات التسليم المكررة، والتأخير في الوصول، والتحديثات المفقودة، والتصحيحات المعتمدة باستخدام بيئة الاختبار المعتمدة لدى المزوّد. تجنب استخدام بيانات العملاء والمدفوعات الحقيقية في نماذج التطوير إلا عند الضرورة. يجب أن يُظهر القبول النتيجة التجارية الصحيحة، بالإضافة إلى استلام الرسالة بنجاح.
ثلاثة تسجيلات ذات معانٍ مختلفة
الرسائل الواردة
يمثل: عملية تسليم واحدة للمعلومات إلى نظامك.
لا تفترض أن: رسالة واحدة تساوي عملية بيع جديدة واحدة.
سجل المعاملة
يمثل: الحالة الحالية المفسرة للمعاملة التجارية.
الاحتياجات: هوية مستقرة وقواعد تحديث موثقة.
نتيجة المصالحة
يمثل: مقارنة بين سجلات محددة ضمن نطاق متفق عليه.
الاحتياجات: توقيت متسق، وكميات متسقة، وتعريفات موحدة للولاية.
إجابات عملية
أسئلة من المهم طرحها قبل الطلب
هل يثبت تسليم المنتج عبر Webhook أنه تم صرفه؟
فقط إذا كان الحدث الموثق يمثل تلك النتيجة تحديدًا، وكان النظام الأساسي يدعم تلك الأدلة. اقرأ تعريف الحدث.
هل يمكنني حساب استجابات واجهة برمجة التطبيقات (API) لحساب المبيعات؟
لا يمكن الاعتماد على ذلك دون فهم السجلات. قد تتضمن الاستجابات تحديثات متكررة، أو أحداثًا لا تتعلق بالبيع، أو عدة سجلات لمعاملة واحدة.
هل ينبغي التخلص من البيانات المتأخرة؟
ليس تلقائيًا. يجب تطبيق قواعد الإبلاغ والتصحيح المتفق عليها لضمان معالجة الأنشطة المتأخرة الصحيحة بدقة.
خطوتك التالية
راجع عقد البيانات قبل إنشاء لوحة المعلومات.
شارك متطلبات إعداد التقارير وهيكلية التكامل مع WEIMI. تأكد من المعرفات المتاحة ومعاني الأحداث وخيارات المطابقة للمنصة المقترحة.
استكشف المعدات → ناقش متطلباتك →