خدمة WordPress · تطوير متقدم
ربط ووردبريس بالأنظمة الخارجية وواجهات API بشكل موثوق
البيانات التي تُنقل يدويًا بين موقعك وCRM أو ERP أو مزود الدفع أو شركة الشحن تضيع وتتأخر وتتكرر. أبني التكامل ليتحمل الفشل: يعيد المحاولة حين يتوقف الطرف الآخر، ولا يكرر الطلب نفسه مرتين، ويسجل كل خطأ في مكان تستطيع قراءته.
أنظمة أتعامل مع واجهاتها في مصر والسعودية والخليج
العلامات للتعريف فقط ولا تعني شراكة أو اعتمادًا رسميًا. توفر كل تكامل يعتمد على وجود واجهة لدى المزود، وبلد متجرك، وخطتك لديه؛ أتحقق من ذلك في الفحص الأولي قبل الالتزام.
بوابات الدفع
الشحن
CRM وتسويق
قياس وإعلانات
مواقع ومتاجر تتبادل بياناتها مع أنظمة أخرى
صيدليات وتوريد ومنتجات رقمية؛ مواقع يمر فيها الطلب أو العميل أو المخزون بين ووردبريس ونظام خارجي، وهنا يوفر الربط وقتًا حقيقيًا.
-
دواك فارما
موقع دواك فارما على ووكومرس يجمع التعريف بالشركة وكتالوج منتجاتها الصحية، مع مداخل للمجموعات ومسار واضح للتواصل والاستفسار.
-
BioCorp Nutrition Labs
موقع BioCorp Nutrition Labs على ووكومرس للتعريف بخدمات تصنيع المكملات والتعبئة، مع تنظيم القدرات ومسار لطلب الاستفسار التجاري.
-
Wellcaremed
موقع WellCare على ووكومرس يجمع التعريف بالشركة ومنتجاتها الصحية مع صفحات للنشاط والقيم ووسائل التواصل ضمن واجهة هادئة.
-
سبلاش مصر
موقع سبلاش مصر على ووكومرس لعرض معدات حمامات السباحة، يجمع المضخات ومجموعات المنتجات مع معلومات الشركة وخدماتها.
-
هايجينيكا مصر
متجر هايجينيكا مصر على ووكومرس للمنظفات ومستلزمات النظافة، بواجهة عربية تجمع الفئات وصور العبوات ومعلومات الاستخدام المعلنة.
-
Orderking
Orderking، موقع ووردبريس في مجال برامج إدارة المطاعم؛ عرض النظام، تعريف الحل، العلامات.
-
webpushly
webpushly، موقع ووردبريس في مجال إشعارات المواقع؛ عرض الخدمة، شرح الاستخدام، الروابط.
سيناريوهات فوري أم دفعات
ليس كل تكامل يحتاج مزامنة فورية، والفوري أغلى صيانة
القرار لكل تدفق على حدة حسب أثر التأخير: الطلب الجديد يحتاج الفورية، وتحديث أسعار آلاف المنتجات يناسبه جدول ليلي.
| التدفق | الاتجاه | النمط المناسب غالبًا | لماذا | ما يُختبر |
|---|---|---|---|---|
| طلب جديد → CRM أو ERP | صادر | فوري عبر webhook مع طابور إعادة محاولة | فريق المبيعات يحتاجه الآن؛ التأخر يعني عميلًا ينتظر | توقف CRM أثناء الإرسال، إرسال الطلب نفسه مرتين، تعديل الطلب بعد الإرسال |
| حالة الشحن → الموقع | وارد | webhook من شركة الشحن أو استعلام دوري إن لم تتوفر | العميل يسأل عن طلبه؛ الحالة تظهر في حسابه | webhook بتوقيع غير صالح، حالة تصل بترتيب خاطئ |
| مخزون ERP → المتجر | وارد | دفعات كل N دقائق أو webhook لكل تغيير إن كان الحجم صغيرًا | آلاف المنتجات؛ الفوري لكل تغيير يثقل الطرفين | منتج غير موجود في المتجر، كمية سالبة، انقطاع في منتصف الدفعة |
| الأسعار والكتالوج | وارد | دفعة مجدولة بمراجعة فروقات | الأخطاء هنا تظهر للعميل مباشرة؛ الأفضل مراجعة قبل النشر | سعر صفر، عملة خاطئة، منتج محذوف في المصدر |
| تأكيد الدفع → الطلب | وارد | webhook موقّع من البوابة + تحقق استعلامي | لا يُعتمد على عودة المتصفح وحدها | webhook يصل قبل العودة، يصل مرتين، أو لا يصل |
| نشرات بريدية / أتمتة تسويق | صادر | فوري عند الحدث مع موافقة مسجلة | الموافقة شرط قانوني وتُخزن مع الحدث | حذف المشترك، تغيير البريد، سحب الموافقة |
- مسار طبيعي
- نجاح
- إعادة محاولة أو تجاهل
- فشل يحتاج مراجعة
كيف تنتقل البيانات
حدث واحد، ثلاثة مصائر: نجاح، إعادة محاولة، أو مراجعة بشرية
الفارق بين تكامل يعمل في العرض التجريبي وتكامل يعمل في رمضان تحت ضغط الطلبات هو ما يحدث حين يفشل الطرف الآخر. لذلك يُصمم كل تدفق حول حالات الفشل أولًا: ماذا لو انقطع الاتصال في منتصف الإرسال؟ ماذا لو وصل الحدث نفسه مرتين؟ ماذا لو رفض النظام البيانات؟
التكرار يُمنع بمفتاح تفرد لكل حدث يُرسل مع الطلب ويُفحص عند الاستلام. الفشل المؤقت يُعالج بطابور وإعادة محاولة متباعدة. الفشل الدائم لا يُخفى: يذهب إلى قائمة مراجعة مع سبب واضح وتنبيه.
الأمان
المفاتيح في الخادم، الصلاحيات بالحد الأدنى، وكل webhook موقّع
قواعد ثابتة لا أتنازل عنها في أي تكامل، وهي مستمدة من إرشادات REST API في ووردبريس وممارسات المزودين.
- الأسرار خارج الواجهة
مفاتيح API تُخزن في إعدادات الخادم أو wp-config أو خيار مشفر، ولا تظهر في JavaScript أو في مصدر الصفحة أبدًا. لا أطلب نشر مفاتيح Admin في المتصفح.
- أقل صلاحية ممكنة
مفتاح لكل تكامل بالنطاق الذي يحتاجه فقط (قراءة الطلبات لا إدارة المتجر كله)، ويُدوَّر عند تغيير الفريق أو الاشتباه في تسرب.
- تحقق توقيع الـ webhooks
كل حدث وارد يُفحص توقيعه (HMAC أو سر مشترك) ووقته قبل أي معالجة، ويُرفض ويُسجل إن لم يطابق.
- مسارات REST بصلاحيات
أي مسار يستقبل بيانات يحدد permission_callback صريحًا وطريقة مصادقة (Application Passwords أو توكن)، ولا يُترك عامًا سهوًا.
- حدود المعدل والمهل
احترام حدود المزود (rate limits) بتباعد الطلبات، ومهلة لكل اتصال حتى لا يعلق الموقع في انتظار طرف لا يرد.
- بيانات العملاء
تُنقل الحقول اللازمة فقط، وفق سياسة خصوصيتك وشروط الطرف الآخر، وتُسجل الموافقة حين يتطلبها القانون أو المنصة.
أخطاء شائعة ومنع التكرار
خمسة أخطاء أراها في التكاملات المكتوبة على عجل، وما يحل كلًا منها
- الاعتماد على عودة المتصفح لتأكيد الدفعالعميل يغلق الصفحة بعد الدفع فلا يُسجل الطلب مدفوعًا. الحل: webhook موقّع من البوابة هو مصدر الحقيقة، مع تحقق استعلامي عند الشك.
- إرسال الحدث مرتين عند تعثر الحفظووردبريس يطلق الـ hook نفسه أكثر من مرة في بعض المسارات. الحل: مفتاح تفرد لكل حدث وفحصه قبل الإرسال وعند الاستلام.
- معالجة الـ webhook داخل الطلب نفسهالمزود ينتظر ردًا سريعًا؛ المعالجة الطويلة تسبب مهلة وإعادة إرسال. الحل: رد 200 فورًا ثم معالجة في الخلفية (Action Scheduler أو طابور).
- الفشل الصامتخطأ في الطرف الآخر لا يراه أحد لأسابيع. الحل: سجل لكل محاولة ونتيجتها، وتنبيه عند تجاوز عدد أخطاء في فترة.
- ترتيب الأحداثتحديث الحالة «تم الشحن» يصل قبل «قيد التجهيز» فتُعرض حالة خاطئة. الحل: طابع زمني أو رقم تسلسل مع كل حدث ورفض الأقدم.
طريقة العمل
من فحص الواجهات إلى تشغيل تدريجي يمكن إيقافه
لا أعد بجدوى تكامل قبل فحص واجهة الطرف الآخر فعليًا؛ بعض الأنظمة لا توفر واجهة أو تقيدها بخطة مدفوعة.
- اكتشاف الأنظمة والواجهات
ما الأنظمة، ما التدفقات، ما التوثيق المتاح، وهل توجد بيئة اختبار (sandbox) لدى المزود. أختبر الوصول بمفتاح تجريبي.
المخرج: تقييم جدوى لكل تدفق - مخطط البيانات والتطابق
جدول يربط كل حقل في ووردبريس بنظيره في النظام الآخر، مع قواعد التحويل والحالات الخاصة (عملة، عنوان، حالة).
المخرج: ملف mapping معتمد - التطوير في بيئة اختبار
الإضافة أو الوحدة التي تنفذ التدفقات مع الطابور والسجل، على نسخة تجريبية وsandbox المزود.
المخرج: تكامل يعمل على بيانات تجريبية - اختبار حالات الفشل
قطع الاتصال، إرسال مكرر، بيانات مرفوضة، توقيع خاطئ، ترتيب خاطئ. كل حالة لها نتيجة متوقعة موثقة.
المخرج: تقرير اختبار الفشل - تشغيل تدريجي
تفعيل تدفق واحد أولًا على الحي مع مراقبة السجل، ثم الباقي. زر إيقاف لكل تدفق دون تعطيل الموقع.
المخرج: تكامل حي بمراقبة - التسليم
توثيق التدفقات والمفاتيح (أين تُحفظ ومن يملكها) وكيفية قراءة السجل والتعامل مع قائمة المراجعة.
المخرج: دليل تشغيل التكامل
ما أحتاجه منك
- أسماء الأنظمة وحساباتك فيها وتوثيق واجهاتها
- مفاتيح بيئة الاختبار (sandbox) من المزود
- التدفقات المطلوبة وأيها عاجل وأيها يقبل التأخير
- من يراجع قائمة الفشل ويستلم التنبيهات
- سياسة الخصوصية وما يُسمح بنقله من بيانات
ما تستلمه
- تقييم جدوى وملف mapping
- تكامل يعمل مع طابور إعادة محاولة ومنع تكرار
- سجل أحداث مقروء وقائمة مراجعة وتنبيهات
- تقرير اختبار حالات الفشل
- دليل تشغيل وتوثيق المفاتيح
خارج النطاق إلا باتفاق
- رسوم الأنظمة والمنصات وخططها التي تتيح الواجهة
- تطوير أو تعديل الطرف الخارجي
- ترحيل بيانات تاريخية ضخمة (يُقدر على حدة)
- بناء سير عمل داخلي كامل (الوظائف المخصصة)
- مراقبة مستمرة بعد فترة المتابعة إلا باتفاق صيانة
أسئلة شائعة
أسئلة قبل ربط الأنظمة
هل يمكن ربط الموقع بـ CRM؟
هل المزامنة فورية؟
ماذا يحدث عندما يتوقف API الطرف الآخر؟
كيف تُخزن مفاتيح الربط؟
هل تشمل الخدمة رسوم المنصات؟
هل أحتاج إلى Zapier أو أداة وسيطة؟
اذكر النظام الذي تريد ربطه والتدفق الأهم، وسأعيد لك تقييم جدوى قبل أي التزام
اسم النظام وخطتك فيه وهل لديك وصول لتوثيق واجهته. أفحص الواجهة وأرد بما يمكن وما لا يمكن ونطاق مبدئي.