Salesforce متصل ببقية أنظمتك
يجمع هذا الربط المخصص بيئة Salesforce لديك ببرمجيات لا يتوفر لها موصّل جاهز، وأكثرها منتج بنيته بنفسك أو نظام ERP له أعرافه الخاصة. نستخدم واجهات REST وComposite للسجلات المفردة، وBulk API للكميات الكبيرة، وأحداث المنصة أو رصد تغيّر البيانات لمعرفة ما تغيّر، مع خدمة خارج Salesforce تتولى مطابقة البيانات ووضعها في الطابور وإعادة المحاولة.
يناسب هذا الربط الشركات التي تُعاد فيها كتابة الفرص على شكل طلبات، أو لا يرى موظفو الخدمة فيها عمليات التسليم والفواتير، أو تحتاج فيها تطبيقات العملاء إلى قراءة Salesforce وتحديثه بأمان. وكل بيئة Salesforce مخصصة بطريقتها، إذ تتفاعل قواعد التحقق والتدفقات والمشغّلات وإعدادات المشاركة كلها مع البيانات التي يكتبها الربط. لذلك نختبر على نسخة معزولة من إعداداتك الحقيقية، ولا نفترض إعداداً قياسياً.
مطابقة الكائنات والحقول
نطابق الكائنات القياسية والمخصصة، وأنواع السجلات، والقوائم المنسدلة، وحقول الربط، مع سجلات نظامك، باستخدام معرّفات خارجية تضمن العثور على السجل نفسه في كل مرة.
الاتجاه والنظام المرجعي
نوثّق أي نظام يحق له إنشاء كل كائن وتعديله. ففي الغالب يملك Salesforce الحسابات والفرص، بينما يملك نظام ERP الطلبات والفواتير والوضع الائتماني.
الوصول بتطبيق عميل خارجي
تتحقق عملية الربط من هويتها عبر تطبيق عميل خارجي، بمسار OAuth يناسب الخوادم، وبمستخدم مخصص لا تكشف مجموعة صلاحياته إلا الحقول المطلوبة.
معالجة الأخطاء والطابور
السجل الذي توقفه قاعدة تحقق أو مشغّل أو صف مقفل يُحفظ مع الرسالة التي أعادها Salesforce، ليعالج مسؤول النظام السبب ويعيد تشغيله.
الكميات الكبيرة وإعادة المحاولة
تمر الأحمال الكبيرة عبر Bulk API على دفعات، بينما تعتمد عمليات الكتابة المفردة على الإنشاء أو التحديث وفق معرّف خارجي، فتحدّث إعادة المحاولة السجل بدل أن تكرره.
مراقبة الحصص والأحداث
نتابع الاستهلاك اليومي لواجهات API، ووصول الأحداث، وطول الطابور، وأعداد حالات الفشل، مع تنبيهات، حتى لا تنفد حصة بيئتك دون إنذار.
ما تتسلمه منا
- مطابقة الكائنات مع معرّفاتها
- قواعد النظام المرجعي وحل التعارضات
- خدمة الربط مع شيفرتها المصدرية
- مسار تحويل الفرصة إلى طلب
- مجموعة صلاحيات خاصة بالربط
- طابور أخطاء قابل لإعادة التشغيل
- لوحة لمتابعة حصة واجهات API
- دليل تشغيل وتسليم لمسؤول النظام
طريقة عملنا
- 01
دراسة بيئة Salesforce
نراجع الكائنات والأتمتة والمشاركة وعمليات الربط القائمة في نسخة معزولة، لأن تدفقاً أو مشغّلاً ينطلق مع ما نكتبه قد يغيّر النتيجة تماماً.
- 02
تصميم الاتفاق بين الأنظمة
نوثّق المطابقة والمعرّفات والنظام المرجعي والأحداث التي تطلق كل مسار، ثم نعتمدها مع مسؤول Salesforce لديك والمسؤولين عن النظام الآخر.
- 03
البناء والاختبار
نبني الخدمة على نسخة معزولة كاملة أو جزئية، ثم نشغّلها بكميات واقعية لنتأكد أن الأتمتة وقفل الصفوف وحصة واجهات API تصمد.
- 04
النشر بحذر
تنتقل الإعدادات إلى بيئة التشغيل الفعلي عبر إجراءات التغيير المعتادة لديك. ونفعّل المسارات واحداً تلو الآخر، ونراقب كل مسار فترة من الوقت قبل أن نبدأ التالي.
التقنيات التي نستخدمها
| المجال | التقنيات |
|---|---|
| جانب Salesforce | واجهات REST وComposite، Bulk API 2.0، أحداث المنصة، رصد تغيّر البيانات |
| أنظمتك | خدمات REST وSOAP، واجهات ERP، تدفقات الأحداث، قواعد البيانات |
| خدمة الربط | Node.js، TypeScript، PostgreSQL، طوابير الرسائل |
| التشغيل | تتبع الحصص، التنبيهات، أدوات إعادة التشغيل، سجل التدقيق |
بيانات Salesforce تخالف أنظمتك الأخرى كل يوم
تُكسب الفرصة، ثم يعيد أحدهم كتابتها طلباً في نظام آخر. ولا يعرف موظفو الخدمة هل دُفعت الفاتورة. ويحتفظ تطبيقك بنسخته من بيانات العملاء، فيبتعد النظامان أحدهما عن الآخر. أما النصوص البرمجية السابقة فتتعطل بصمت كلما أضاف مسؤول النظام قاعدة تحقق.
- تحويل الفرص إلى طلبات في ERP
- إظهار الفواتير لفريق الخدمة
- بوابات عملاء تعمل ببيانات Salesforce
- بيانات استخدام المنتج على الحسابات
- نقل البيانات بعد عمليات الاندماج
- استبدال النصوص البرمجية الهشة
أسئلة شائعة
ماذا تحتاج بيئة Salesforce لدينا لإنجاز ربط مخصص؟
إصدار يشمل الوصول إلى واجهات API، ونسخة معزولة للبناء عليها، ومسؤول نظام يستطيع إنشاء تطبيق عميل خارجي ومجموعة صلاحيات. وقد قيّدت Salesforce إنشاء التطبيقات المتصلة الجديدة، وتوصي بتطبيقات العميل الخارجية بدلاً منها، لذلك نعتمد عليها في الأعمال الجديدة. ولكل بيئة أيضاً حصة يومية من طلبات API مرتبطة بتراخيصها، ونقارنها بالكميات التي تتوقعها.
هل يمكن أن تتحول الفرصة المكسوبة إلى طلب في نظام ERP؟
نعم. عند إغلاق الفرصة، يتحقق الربط من وجود الحساب في نظام ERP ببيانات فوترة صحيحة، وينشئه إن لزم، ثم ينشئ الطلب من منتجات الفرصة. وتعود إلى Salesforce بيانات رقم الطلب في نظام ERP وحالة التنفيذ والفواتير. وتُغذّى المنتجات ودفاتر الأسعار من نظام ERP مسبقاً، ليكون ما قُدّم في العرض قابلاً للطلب فعلاً.
هل نبني الربط داخل Salesforce أم خارجه؟
عادةً خارجه لنقل البيانات، وداخله للتفاعل معها. فالشيفرة داخل Salesforce تعمل ضمن حدود تنفيذ صارمة، ولا تناسب المهام الطويلة وإعادة المحاولة والكميات الكبيرة. أما الخدمة المستقلة فتتولى ذلك بسهولة، وتُبقي بيانات الدخول إلى الأنظمة الأخرى خارج بيئتك في Salesforce. وداخل Salesforce لا نضيف إلا أجزاء خفيفة، مثل حدث يعلن وقوع تغيير.
هل البرمجيات الوسيطة أو الموصّل الجاهز خيار أفضل؟
أحياناً. فإن كانت شركتك تستخدم منصة ربط بالفعل، فالبناء عليها يُبقي المهارات والمراقبة في مكان واحد، ويمكننا العمل بهذه الطريقة. ويناسب الموصّل الجاهز نظام ERP قياسياً يُستخدم بطريقة قياسية. أما الربط المخصص فهو الأداة المناسبة للبرمجيات التي بنيتها بنفسك، والكائنات غير المألوفة، وقواعد النظام المرجعي الصارمة، والكميات التي تجعل التسعير لكل مهمة غير مجدٍ.
كيف تتجنبون تعطيل الأتمتة القائمة؟
نختبر عليها مباشرة. فكل عملية كتابة من الربط قد تطلق قواعد تحقق وتدفقات ومشغّلات، لذلك نطوّر في نسخة معزولة تحاكي بيئة التشغيل الفعلي، ونشغّل فيها كل السيناريوهات. وحين لا ينبغي أن تسري قاعدة ما على بيانات الربط، يقرر مسؤول النظام ذلك ويوثّق الاستثناء. وبعد الإطلاق، تظهر السجلات المتوقفة في الطابور مع نص الرسالة كما هو، فلا يمر شيء بصمت.