حدّد مصدراً معتمداً لكل حقل ولكل مرحلة من دورة العمل. لا يلزم أن يملك نظام واحد كل بيانات العميل، لكن يجب ألا يعدّل نظامان القيمة نفسها دون قاعدة تعارض واضحة. تكرار المزامنة لا يحل غموض الملكية؛ قد يكرر الخطأ فقط.
افصل هوية السجل عن محتواه
أنشئ علاقة ثابتة بين معرف العميل في CRM ومعرفه في ERP. البريد أو الهاتف قابلان للتغيير، فلا يكونان وحدهما مفتاح الربط الدائم. راجع حالات العملاء المكررين والفروع والحسابات القانونية المختلفة مع الفريق؛ لا تدمج سجلين لأن اسميهما متشابهان.
قد يملك CRM بيانات التواصل قبل البيع، بينما يملك ERP الاسم القانوني المعتمد للفوترة. هذا مثال محتمل لا قاعدة إلزامية. إذا طلب العميل تغيير الاسم بعد إصدار فاتورة، فالتعديل قد يحتاج إجراءً مالياً مستقلاً، وليس استبدالاً صامتاً لكل السجلات السابقة.
وثيقة ملكية الحقول
| الحقل أو العملية | المصدر المقترح في المثال | التعامل مع التعارض |
|---|---|---|
| مسؤول العلاقة التجارية | CRM | يرسل إلى النظام الآخر للعرض |
| الاسم القانوني للفوترة | ERP بعد التحقق | طلب مراجعة بدلاً من استبدال آلي |
| حالة فرصة البيع | CRM | لا تعادل حالة تنفيذ الطلب |
| المخزون المتاح | نظام المخزون المعتمد | إعادة تحقق قبل تثبيت الطلب |
| حالة سداد الفاتورة | سجل الدفع المالي | دليل موثوق وليس نقرة مستخدم |
أضف إلى الوثيقة اتجاه التبادل، والتأخير المقبول، ومن يصحح الخطأ، وهل يجب حفظ تاريخ القيمة. اتفق على ما يحدث إذا كان المصدر غير متاح: عرض آخر حالة مع وقتها، أو إيقاف الإجراء، أو تسجيل عملية معلقة. لا تخفِ التأخير تحت عبارة «متزامن».
اختبر الرسائل غير المثالية
ستصل رسالة متأخرة أو مكررة، وقد تصل عمليتان بترتيب مختلف. استخدم معرف حدث أو طلب ثابتاً، وتحقق من الإصدار أو التسلسل عندما يسمح عقد المزود بذلك. لا تفترض أن توقيت ساعة كل نظام دقيق بما يكفي لحسم كل تعارض.
اختبر تحديث العميل في المصدر ثم وصول تحديث أقدم، وانقطاع أحد النظامين أثناء إنشاء الطلب، وإعادة إرسال الرسالة نفسها. ينبغي ألا ينشأ عميل أو طلب ثانٍ، وألا تتراجع حالة معتمدة بسبب حدث قديم. خصص قائمة أخطاء يستطيع المسؤول فهمها وإعادة معالجتها دون تعديل قاعدة البيانات يدوياً.
المطابقة أهم من انطباع النجاح
نجاح طلب API لا يثبت أن السجل الناتج صحيح تجارياً. قارِن عينات وإجماليات وحالات استثناء، وسجل الفروق ومن اعتمد معالجتها. احمِ السجلات من البيانات الشخصية والمفاتيح السرية، وأبقِ صلاحيات التكامل في أقل نطاق مطلوب.
تشرح خدمة تكامل الأنظمة حدود هذا العمل، وتساعد أنظمة الأعمال المخصصة في معالجة الاستثناءات. وللتنفيذ التقني، اقرأ التعامل الموثوق مع Webhooks.
مصادر ومراجعة
- Microsoft: نمط Anti-corruption layer.
- Stripe: معالجة أحداث Webhook المكررة؛ مثال مزود، وليس عقداً عاماً لكل الأنظمة.
- المساهمة الأصلية: جدول ملكية الحقول وحالات المطابقة.




