سلة

في تكامل Salla لا يكفي إرسال كل ما يتاح من بيانات. نحدد أولًا النتائج التجارية المطلوبة، ثم نختار الأحداث الملائمة، مثل: product interest, checkout initiation, paid order, cancellation, and refund. هذه أمثلة للمتطلبات التي ينبغي مراجعتها وليست وعدًا بأن كل حدث مدعوم تلقائيًا. نحدد مع العميل مصدر الحدث وصلاحيات استخدامه ونقطة تسجيله الصحيحة قبل بناء أي خريطة إرسال.

الحقول التي نراجع ملاءمتها بحسب طبيعة الحالة تشمل: store order reference, item totals, currency, status, event time and approved identifiers. لا نجمع هذه الحقول كلها بالضرورة؛ نستخدم الحد الأدنى المسموح به فقط، ونمنع انتقال المعلومات الحساسة إلى منصات غير مناسبة. الأهم هو ثبات المعرّفات وتطابق القيمة والزمن مع السجل الأصلي حتى تكون المقارنة عادلة.

نبدأ بمراجعة إعداد الحساب والأدوار والموافقات، وبعدها نرسم مسارًا صغيرًا لحدث تجريبي موثوق. نحدد من أين يأتي، وكيف تسمّى الخصائص، وما الذي يحدث عند غياب بيانات اختيارية. بعد اختبار المثال نراجع القيم والأزمنة والتكرار، ونوثق ما تم اختباره وما لم يختبر بعد.

نضع قائمة مراجعة للحقول الخاصة بالمصدر: store order reference, item totals, currency, status, event time and approved identifiers. لكل حقل نحدد النوع المتوقع والقيمة الافتراضية ومصدر الحقيقة وطريقة التأكد من سلامته. إذا تغيّر الاسم أو صيغة القيمة في النظام المصدر، ينبغي أن يظهر فشل واضح في الاختبار بدل إرسال نتائج لا يمكن الوثوق بها.

علامات النجاح العملية هي وجود حدث أو سجل أصلي معروف، ووصول نتيجة متوقعة مرة واحدة، وتوافق المبلغ والعملة والحالة عند اللزوم، والتزام الموافقات والصلاحيات. بعد ذلك نراجع تقريرًا من الأداة المستقبلة مع سجلات المصدر، ونوثق أي اختلافات في نوافذ الإسناد أو أوقات المعالجة.

بعد التشغيل، نحدد مسؤولًا عن مراقبة الأرقام وأسباب الأخطاء. تشمل قائمة المراجعة: duplicate webhooks, order status transitions, discounts changing value and store access permissions. عند ظهور اختلاف، نبدأ برقم الحدث أو السجل الأصلي، ثم نفحص توقيت الإرسال وحالة الاستجابة، ونوثق أي تغيير في خرائط البيانات قبل إعادة الاختبار.