تكامل Salesforce لا يفشل تقريباً أبداً عند البروتوكول. المصادقة مشكلة محلولة، وكتابة سجل مشكلة محلولة أيضاً. ما ينهي المشاريع هو حصة الطلبات اليومية وشكل نموذج البيانات، ويُكتشف الاثنان عادةً بعد نحو ثلاثة أسابيع من الإطلاق، حين تبدأ المهمة الليلية بإرجاع أخطاء ولا يستطيع أحد تفسير سبب نجاحها في الاختبار.
النمط ثابت بما يكفي للتنبؤ به. يبني مطوّر على مؤسسة Developer Edition، فيمرّ كل شيء، ويعتمد العميل العمل. ثم يصطدم الكود بمؤسسة إنتاج تضم أصلاً موصّل تسويق، واستخراجاً نحو مستودع البيانات، ومشغّل Apex من عام 2019، فتتحول ميزانية الطلبات التي بدت سخية إلى وعاء مشترك ينفق منه آخرون منذ زمن.
يقدّم هذا المقال المفاجآت مبكراً: أي واجهة ينبغي أن تستخدم، وكيف تُحسب الحصة، وماذا يحدث حين تشغّل كتابتك كوداً لم تكتبه، وكيف تغيّرت المصادقة، وأي قرارات في نموذج البيانات يكلّف التراجع عنها كثيراً.
ما الذي يقرر نجاح تكامل Salesforce؟ الحصة ونموذج البيانات، لا البروتوكول. حصة طلبات API اليومية تسري على المؤسسة كلها وتُشتق من الإصدار وعدد التراخيص، فقد يجوّع تكاملٌ رديء الكتابة تكاملاً منضبطاً في المؤسسة نفسها. صمّم للتجميع من أول سطر برمجي، واتفق على External ID وعملية upsert قبل كتابة أي شيء، وافترض أن كل سجل ترسله سيشغّل كود Apex يخص شخصاً آخر.
ما الذي على تكامل Salesforce أن يصيبه
هناك أربعة أمور، وليست متساوية الوزن.
الأول هو الحصة. كل استدعاء متزامن يجريه كودك يُخصم من حصة يومية واحدة تسري على المؤسسة كلها ويتشاركها مع كل مستهلك آخر فيها.
الثاني هو المنصة تحته. Salesforce ليس قاعدة بيانات ذات واجهة HTTP. إنه منصة تطبيقات، وكتاباتك تشغّل مشغّلات وتدفقات وقواعد تحقق وقواعد تكرار ومجاميع تلخيصية أعدّها مسؤولون لم يسمعوا بمشروعك قط.
الثالث هو نموذج البيانات. Lead وContact وAccount وOpportunity ليست قابلة للتبادل، والتحويل بينها أحادي الاتجاه وله آثار جانبية، والاختيار الخاطئ يعني ترحيل بيانات لا تعديل كود.
الرابع هو الهوية: كيف يتفق نظامك وSalesforce على أي سجل هو أي. أخطئ فيها فتنتج نسخاً مكررة بسرعة الآلة. وكل ما تبقى هنا ينبع من واحد من هذه الأربعة.
مشهد الواجهات، وأيّها تحتاج فعلاً
تنشر Salesforce عائلة كبيرة من الواجهات. فهرس واجهات Salesforce هو القائمة المرجعية، والأسماء أدناه مأخوذة منه لا من الذاكرة.
REST API وSOAP API
REST API هي الخيار الافتراضي لكل ما له شكل سجل: الإنشاء والقراءة والتحديث والحذف والاستعلام والوصف. وهي الخيار الصحيح لنموذج ويب يكتب Lead، ولبوابة تقرأ حالات Case المفتوحة لعميل، ولأي مسار تفاعلي منخفض الحجم.
تؤدي SOAP API العمل نفسه عبر ملف WSDL، وتبقى حيّة لأن كثيراً من الوسائط المؤسسية تتحدثها بصورة أصيلة، ولأنها تمنحك عقداً قوي التنميط تولّد منه عميلاً. الخطأ الشائع هو افتراض أن SOAP قديمة وREST حديثة. كلتاهما حالية، واستدعاءا SOAP وهما create() وupdate() يقبل كلٌّ منهما حتى 200 سجل، وهذا أهم من صيغة النقل.
Bulk API 2.0
Bulk API 2.0 هي المسار غير المتزامن القائم على المهام لمعالجة الحجم. ترفع ملف CSV، فتقسّمه Salesforce وتعالجه في الخلفية، ثم تستعلم أنت عن النتائج. تسمح حدود Bulk API بما يصل إلى 15,000 دفعة لكل 24 ساعة متدحرجة، وبما يصل إلى 150 مليون سجل مُستوعَب في النافذة نفسها، بسقف 150 ميغابايت لملف المهمة.
الخطأ الشائع هو معاملة Bulk كخطوة ضبط لاحقة. إنها نموذج برمجة مختلف: النتائج تعود بصورة غير متزامنة، سجلاً سجلاً، وعلى كودك أن يستهلكها هكذا منذ البداية.
Composite وsObject Collections
هاتان أعلى أجزاء REST API قيمةً وأقلها استخداماً. يحمل طلب composite ما يصل إلى 25 طلباً فرعياً في استدعاء واحد، يمكن أن يكون 5 منها على الأكثر استعلامات أو عمليات sObject Collections، وللطلبات الفرعية اللاحقة أن تشير إلى المعرّفات التي أعادتها السابقة. وتتعامل sObject Collections مع ما يصل إلى 200 سجل من الكائن نفسه في طلب واحد. وكلتاهما تُحسب استدعاءً واحداً من حصتك اليومية، وهذا كل المقصود.
الخطأ الشائع هو عدم معرفة وجودهما أصلاً. إنشاء Account ثم Contact ثم Opportunity في ثلاثة استدعاءات متتابعة يكلّف ثلاثة أضعاف حصة طلب composite واحد، وثلاثة أضعاف زمن الاستجابة.
Streaming وChange Data Capture وPub/Sub
Streaming API هي قناة الاشتراك القائمة على CometD لأحداث PushTopic والأحداث العامة وأحداث Platform وChange. وينشر Change Data Capture إشعارات شبه فورية عند إنشاء السجلات أو تحديثها أو حذفها أو استعادتها، فيتمكن مخزن خارجي من ملاحقة Salesforce دون استطلاع دوري. وPlatform Events هي تعريفات الأحداث الخاصة بك.
Pub/Sub API هي الواجهة الأحدث القائمة على gRPC وHTTP/2، وتجمع النشر والاشتراك وجلب المخطط واكتشاف المواضيع في واجهة واحدة، بحمولات بصيغة Avro بدل JSON. ولأي بناء جديد مدفوع بالأحداث، ابدأ من هناك.
الخطأ الشائع هو معاملة الأحداث كتدفق مضمون. إنها لا تغني عن المطابقة، للسبب الوارد في القسم التالي.
حدود طلبات API هي القيد الحقيقي
هذا هو القسم الذي يقرر معماريتك، وهو الأكثر قراءةً بعد أن يكون التصميم قد اكتمل.
كيف تُحسب الحصة اليومية
تحدد وثيقة حدود طلبات API الحصة بحسب الإصدار وعدد التراخيص، لا بحسب المستخدم ولا التطبيق. إصدارا Enterprise وProfessional مع صلاحية API يحصلان على 100,000 استدعاء زائد 1,000 لكل ترخيص Salesforce أو Salesforce Platform. وإصدارا Unlimited وPerformance يحصلان على 100,000 زائد 5,000 لكل ترخيص. وتحصل Developer Edition على 15,000 ثابتة، وتحصل بيئة Full sandbox على 5,000,000.
ينتج عن ذلك أمران. مؤسسة Enterprise بستين مستخدماً لديها نحو 160,000 استدعاء يومياً، لا مورد لا ينضب. ولأن الحصة مشتقة من التراخيص، فالسبيلان الوحيدان لرفعها هما تراخيص مستخدمين إضافية أو استدعاءات API إضافية مشتراة، وكلاهما عبر تطبيق Your Account من Salesforce.
ما الذي يُحتسب، وماذا يحدث حين تنفد الحصة
تُقاس الحصة على مجموع كل الاستدعاءات الواردة إلى المؤسسة خلال 24 ساعة، وتغطي معاً REST API وSOAP API وBulk API وBulk API 2.0 ومعظم استدعاءات Connect REST API. أما استدعاءات بعض تطبيقات Salesforce المتصلة، مثل تطبيق الهاتف، فمستثناة.
هذا التجميع هو ما يباغت الفرق. تكاملك لا يملك ميزانية خاصة به. إنه يتقاسمها مع موصّل التقارير ومنصة التسويق وكل تكامل آخر في المؤسسة، ويكفي مستهلك واحد رديء الكتابة يستطلع كل ثلاثين ثانية كي يستنزفها ويجوّع كوداً يتصرف تصرفاً سليماً تماماً.
حين تتجاوز المؤسسة حصتها تفشل الطلبات برمز 403 وبالخطأ REQUEST_LIMIT_EXCEEDED. وتسمح Salesforce لمؤسسات الإنتاج المدفوعة بقدر من التجاوز قبل التطبيق الصارم، بينما لا تنال مؤسسات التجربة وDeveloper Edition أي تسامح. صمّم كأن لا تسامح أصلاً.
قِس قبل أن تلتزم بتصميم
اطلب من المسؤول حصة المؤسسة واستهلاكها اليومي الحالي قبل كتابة الكود؛ فREST API تعرض مورداً لحدود المؤسسة من أجل ذلك. وإذا كان المستهلكون الحاليون يستنفدون سبعين بالمئة، فالتكامل المتزامن سجلاً بسجل غير قابل للحياة، ولن يجعله الضبط قابلاً لها.
التجميع في دفعات قرار تصميمي لا تحسين لاحق
ما إن تقبل أن الحصة محدودة ومشتركة، حتى يفرض التصميم نفسه.
لا تضع أبداً استدعاء السجل الواحد داخل حلقة. مهمة تنشئ 5,000 سجل Contact واحداً واحداً تنفق 5,000 استدعاء. والـ 5,000 نفسها عبر sObject Collections بواقع 200 لكل طلب تنفق 25 استدعاءً. هذا المعامل 200 هو الفرق بين تكامل يتسع داخل حصة مؤسسة متوسطة وتكامل لا يتسع.
استخدم Composite حيث يكون العمل رسماً بيانياً لا قائمة. إنشاء سجل أب وأبنائه في طلب واحد يزيل الرحلات المتكررة والحالة الوسيطة التي سيضطر كودك إلى حملها بانتظار معرّف.
استخدم Bulk API 2.0 لكل ما يشبه التحميل أو التصدير لا المعاملة. وهي خيار خاطئ للمسارات التفاعلية، لأنها غير متزامنة بحكم تصميمها ولا تعيد للمستخدم جواباً متزامناً.
خزّن البيانات المرجعية مؤقتاً. قيم القوائم المنسدلة ومعرّفات أنواع السجلات ونتائج describe تتغير نادراً، ومع ذلك تُجلب من جديد في كل تشغيل بلا سبب. هذا التغيير وحده كثيراً ما يزيل ربع حجم الاستدعاءات في تكامل ساذج.
governor limits: كتابتك تشغّل كود غيرك
تنفّذ Salesforce كود Apex الذي يكتبه العملاء داخل سقوف صارمة لكل معاملة. وgovernor limits الخاصة بـ Apex التي تهم التكامل هي 100 استعلام SOQL لكل معاملة متزامنة، و50,000 سجل يجلبها SOQL، و150 تعليمة DML، و10,000 سجل يعالجها DML، و10 ثوانٍ من زمن المعالج المتزامن، و6 ميغابايت من الذاكرة.
أنت لا تكتب ذلك الكود. ومع ذلك تصطدم بتلك الحدود، لأن كتابتك الواردة تفتح معاملة تشغّل كل المشغّلات الموجودة على الكائن.
التجميع الدفعي، دون كتابة Apex
الفكرة تستحق الفهم حتى لو لم تفتح ملف Apex أبداً.
تسلّم Salesforce المشغّل مجموعةً من السجلات لا سجلاً واحداً. والمشغّل المكتوب بصورة صحيحة يعالج المجموعة كلها باستعلام واحد وتحديث واحد. أما المشغّل المكتوب كأنه يتلقى دائماً سجلاً مفرداً فيشغّل استعلاماً وتحديثاً لكل سجل.
ذلك المشغّل الثاني يعمل بلا عيب سنوات، لأن المستخدمين يحفظون سجلاً واحداً في كل مرة من الواجهة. ثم يرسل تكاملك 200 سجل في طلب واحد، فيشغّل المشغّل استعلامه 200 مرة، ويتجاوز سقف 100 استعلام، فتسقط الدفعة كلها.
وتعالج Bulk API 2.0 بيانات الاستيعاب في كتل من 200 سجل، كل منها معاملة منفصلة، فالأمر إذاً ليس نظرياً. إنه الشكل المعتاد لأول تحميل ضخم إلى مؤسسة لها تاريخ.
ما العمل حيال ذلك
دقّق المشغّلات والتدفقات على كل كائن ستكتب فيه، قبل أن توافق على تاريخ تسليم. وإذا كان مشغّل غير مهيأ للدفعات فعلى أحدهم إصلاحه، وذلك الأحد يحتاج مهارات Apex ونافذة نشر. أدرج ذلك بنداً مستقلاً في الميزانية.
وحيث يقع الإصلاح خارج النطاق، خفّض حجم الدفعة. المئتان لكل طلب حد أقصى لا التزام، والنزول إلى خمسين يشتري أحياناً متنفساً كافياً للتسليم بينما يُجدوَل العمل على المشغّل. إنه يكلّف حصة، فعامله على أنه إجراء مؤقت.
مصادقة ستظل تعمل العام المقبل
تغيّر هذا المجال تغيراً جوهرياً، وكثير من الإرشادات المنشورة صار خاطئاً.
تدفق OAuth 2.0 باسم المستخدم وكلمة المرور هو ما ينبغي تجنبه. فهو يكشف بيانات الاعتماد مباشرةً داخل الطلب، وتحجبه Salesforce افتراضياً في المؤسسات الأحدث، وسحبه بالنسبة إلى connected apps مجدول. وأي تكامل ما زال يستخدمه يحتاج خطة ترحيل بتاريخ محدد.
وللعمل بين الخوادم دون إنسان في الحلقة، فالجوابان الحاليان هما تدفق JWT bearer الذي يوقّع تأكيداً بشهادة، وتدفق client credentials الذي يبادل مفتاح المستهلك وسرّه برمز وصول. وإرشاد Salesforce حول استدعاء واجهات REST بمستخدم التكامل وclient credentials يقول صراحةً إن هذا التدفق لا يصدر رمز تحديث، فيطلب العميل رمز وصول جديداً عند انتهاء صلاحية القديم.
connected apps وexternal client apps
كانت الحاوية لكل ذلك هي connected app. وقد صارت الآن external client app. وتقول Salesforce بوضوح إن إنشاء connected apps مقيّد اعتباراً من إصدار Spring ‘26، وتوصي بـ external client apps بدلاً منها، وتصفها بأنها الجيل الجديد المصمم لتحسين الأمان وحل مشكلات التحزيم.
فإذا قالت وثيقة التكامل لديك “أنشئ connected app”، فهي تصف مساراً قد لا توفره المؤسسات الجديدة. تحقق مما ينطبق على المؤسسة المستهدفة قبل تقدير العمل.
شغّله بمستخدم تكامل مخصص، وخطط لتدوير الاعتمادات
امنح التكامل مستخدماً خاصاً به، بملف تعريف بأقل صلاحية ومقتصر على API. ولا تشغّله باسم موظف بعينه. فحين يغادر ذلك الموظف ويُعطّل حسابه يتوقف التكامل، في أسوأ لحظة ممكنة، وبخطأ لا يدل على شيء مفيد.
الشهادات تنتهي صلاحيتها والأسرار تُدوَّر. وكلاهما صامت حتى اليوم الذي يتوقف فيه عن الصمت، وكلاهما يُخرج التكامل من الخدمة كلياً لا جزئياً. ضع تواريخ الانتهاء في تقويم يملكه شخص، واحفظ بيانات الاعتماد في مدير أسرار، واختبر التدوير في بيئة sandbox قبل أن تحتاجه في وقت عصيب.
مصائد نموذج البيانات
هذه هي التي تكلّف ثلاثة أسابيع، لأن التراجع عنها يعني نقل بيانات لا تغيير كود.
Lead وContact وAccount وPerson Account
الـ Lead عميل محتمل غير مؤهل لم يُربط بعد بسجل شركة. والـ Contact شخص مرتبط بـ Account. والـ Account منظمة. والتحويل يحوّل Lead إلى Account وContact، واختيارياً مع Opportunity، ويقول استدعاء SOAP المسمى convertLead صراحةً إن الحقول الفارغة وحدها في الهدف هي التي تُستبدل، فقد لا تصل حقول Lead التي ملأتها بعناية إلى حيث تتوقع.
وتزيد Person Accounts الأمر تعقيداً. المؤسسات الموجهة إلى المستهلك تفعّلها كي يُمثَّل الفرد بوصفه Account وContact مدمجين، وتكامل مكتوب على نموذج Account تجاري لن يعمل دون تعديل مع مؤسسة تستخدمها. ويُكتشف هذا متأخراً بانتظام محبط.
قرّر مع الجهة المعنية، كتابةً، إلى أي كائن يتحول سجل وارد بعينه. فهذا ليس قراراً تقنياً.
External ID وupsert
هذه هي آلية عدم التكرار الوحيدة العاقلة التي تمنحك إياها Salesforce، ولا ينبغي أن تكون قابلة للتفاوض. أنشئ على الكائن حقلاً مخصصاً موسوماً بأنه External ID، واحفظ فيه المفتاح الأساسي لنظامك أنت. عندها يمكنك استخدام عملية upsert، وهي طلب PATCH على المسار /sobjects/{Object}/{ExternalIdField}/{Value}، ينشئ السجل حين لا يطابق شيء ويحدّثه حين يطابق واحد بالضبط. صفر مطابقات يعيد 201، ومطابقة واحدة تعيد 200، وتعدد المطابقات يفشل برمز 300 بدل التخمين.
والنتيجة تستحق أن تقال صراحةً. مع upsert تصير إعادة محاولة طلب فاشل آمنة. وبدونه تصير كل إعادة محاولة تكراراً محتملاً، ويتحول انقطاع شبكي أثناء مهمة ليلية إلى عملية تنظيف تُقاس بالأيام.
القواعد التي تنطلق على كتاباتك
قواعد التكرار قد تحجب السجلات التي ينشئها تكاملك أو تنبّه عليها. وقواعد التحقق ترفض السجلات التي لا تستوفي شروطاً وضعها مسؤول. والحقول الإلزامية قد تُضاف بعد شهور من إطلاقك، فيبدأ عندها تكامل عامل بالفشل على كل سجل.
لا شيء من هذا خلل؛ فالمؤسسة تعمل كما هي معدّة. الخطأ هو معاملة الكتابة المرفوضة كعطل نقل وإعادة المحاولة إلى ما لا نهاية، بينما الجواب الصحيح رفعها إلى إنسان مع سبب الرفض على مستوى الحقل. ودليلنا حول أنماط فشل تكامل واجهات الطرف الثالث يغطي الفئة نفسها في موضع آخر.
معالجة الأخطاء وعدم التكرار وإعادة التشغيل
التكامل بلا آلية لإعادة التشغيل يتحول إلى إصلاح يدوي للبيانات. وهذا ليس تنبؤاً، بل هو ما يحدث.
النجاح الجزئي هو الحالة الطبيعية. تضبط sObject Collections القيمة allOrNone على false افتراضياً، فقد يعيد طلب من 200 سجل عدد 187 نجاحاً و13 إخفاقاً بأسباب فردية، وتعيد Bulk API 2.0 نتائج على مستوى السجل بالطريقة نفسها. والكود الذي يفحص حالة HTTP الخارجية وحدها سيبلّغ بالنجاح بينما يسقط سجلات بصمت.
صنّف الإخفاقات قبل إعادة المحاولة. الحالات العابرة مثل أقفال الصفوف ومهل الانتظار ونفاد الحصة تستحق تراجعاً أسّياً. أما الإخفاقات الحتمية مثل أخطاء التحقق والحقول الإلزامية الناقصة فستفشل بالطريقة نفسها إلى الأبد، وإعادة محاولتها تحرق حصة لا تملك ترفها.
كل سجل غير قابل للإنقاذ يذهب إلى مخزن المهملات بحمولته وخطئه، كي يفحصه شخص ويعيد إرساله. ولأن كتاباتك مفهرسة على External ID فإعادة الإرسال آمنة. سجّل على الجانبين المطابقة بين معرّفك ومعرّف Salesforce؛ فبعد ستة أشهر سيكون ذلك السجل الشيء الوحيد الذي يفسر لماذا بيانات عميل بعينه خاطئة.
وطابِق. تبقى أحداث Platform وChange محفوظة في ناقل الأحداث 72 ساعة، وتحدد مخصصات platform events سقف التسليم اليومي عند 25,000 حدث على Enterprise و50,000 على Unlimited وPerformance. والمقارنة المجدولة لأعداد السجلات وتواريخ التعديل تلتقط ما أسقطه التدفق.
وسيط تكامل أم اتصال مباشر
الاتصال من نقطة إلى نقطة صحيح أكثر مما يعترف به بائعو المنصات. مصدر واحد، وهدف واحد، واتجاه واحد، وحجم متواضع، وعقد مستقر: ابنِه مباشرةً ووفّر الترخيص.
يستحق الوسيط كلفته حين تتوقف الطوبولوجيا عن كونها خطاً. أنظمة عدة تتبادل البيانات، وتحويلات يحتاج مستخدمو الأعمال إلى تغييرها دون نشر، وتنسيق بين أنظمة تتعطل بصورة مستقلة، وحاجة حقيقية إلى مراقبة وإعادة محاولة مركزيتين.
والملاحظة الصادقة أن الوسيط ينقل الكلفة لا يزيلها. فأنت تظل تدفع ثمن الربط ومعالجة الأخطاء والمعرفة التشغيلية، وتضيف ترخيصاً وخط أنابيب ثانياً ومجموعة مهارات ثانية تحتاج إلى توظيفها. وحصة API لا تتغير، لأن الوسيط يستدعي الواجهات نفسها التي كان كودك سيستدعيها.
اخترْه لأن طوبولوجيتك تقتضيه، لا لأنه يبدو مقللاً للكود. ودليلنا حول قرار البناء أم الشراء يعالج المفاضلة نفسها للأنظمة الأساسية، ودليل تكامل CRM وERP يغطي حالة الأنظمة المتعددة. وإن أردت تقييم هذا بدل الجدال فيه، فمن هناك تبدأ ارتباطاتنا في تطوير البرمجيات.
بيئات sandbox والنشر وإصدارات API
ابنِ في بيئة sandbox. لا على الإنتاج أبداً، ولا على مؤسسة Developer Edition لا تشارك إعدادات الإنتاج، لأن الإعدادات هي ما سيكسرك.
افهم ما يفعله التحديث. إنه يستبدل بالبيئة نسخة جديدة من الإنتاج، فتختفي أي بيانات اختبار كانت موجودة هناك وحدها. وما يجب أن ينجو من التحديث يجب أن يُكتب بسكربت قابل لإعادة التشغيل. تتعلم الفرق هذا بخسارة أسبوع من بيانات الاختبار.
ثبّت إصدار API صراحةً في كل مسار طلب، واعرف سياسة السحب. تلتزم سياسة انتهاء عمر واجهات Salesforce بدعم كل إصدار ثلاث سنوات على الأقل، وبإشعار العملاء قبل انتهاء الدعم بسنة على الأقل. وقد سُحبت الإصدارات من 21.0 إلى 30.0 في إصدار Summer ‘25، والطلبات الموجهة إلى إصدار مسحوب تعيد 410 Gone.
هذا توقف حاد لا تدهور تدريجي، ولهذا يخص تثبيت الإصدار خطة الصيانة لديك. وينطبق الانضباط نفسه على أي واجهة تنشرها أنت، كما يشرح مقالنا عن إصدارات الواجهات البرمجية.
حماية البيانات في المملكة المتحدة وبيانات CRM
نظام CRM يتكون كله تقريباً من بيانات شخصية: أسماء وجهات عمل وأرقام هواتف وعناوين بريد وملاحظات عن محادثات. ونقلها بين الأنظمة معالجة بموجب UK GDPR.
السؤال الأول من هو المتحكم. يعرّف إرشاد مكتب ICO حول المتحكمين والمعالجين المتحكم بأنه الطرف الذي يحدد أغراض المعالجة ووسائلها، والمعالج بأنه من يعالج نيابةً عن المتحكم. وحين تبني وكالة تكاملاً لك وتشغّله، تكون تلك الوكالة معالجاً عادةً، ويصبح العقد المكتوب المستوفي لمتطلبات المادة 28 إلزامياً لا اختيارياً.
والثاني هو النقل الدولي. فمؤسسات Salesforce وأي وسيط قد تقع خارج المملكة المتحدة، ويعرض إرشاد ICO حول عمليات النقل الدولية الآليات المتاحة وحالات الحاجة إلى تقييم مخاطر النقل. حدد أين تستقر البيانات قبل التوقيع.
وتترتب ثلاث نتائج. لا تنسخ حقولاً لا تحتاجها، فتقليل البيانات مطلب قانوني وعمل ربط أقل في آن. ولا تضع بيانات شخصية إنتاجية في sandbox دون قرار مدروس. واحرص على انتقال الحذف، فجهة اتصال مُحيت في Salesforce وبقيت سليمة في مستودعك مشكلة امتثال قائمة، وينطبق الأمر نفسه حين تصل وكلاء الذكاء الاصطناعي إلى تلك السجلات.
كم يكلّف تكامل Salesforce
تنشر Salesforce أسعار إصداراتها وتراخيصها على صفحات التسعير الخاصة بها، ولا نذكر هنا أي رقم لها، لأن الرقم الذي يحكم تصميم التكامل هو حصة API التي تنتجها تلك التراخيص لا سعر القائمة.
الأرقام أدناه تقديرات Mecanik الخاصة للخدمات المهنية في المملكة المتحدة، لا أسعار المورّد، وتفترض مؤسسة قائمة بالفعل ولها مسؤول قادر على الإجابة عن الأسئلة.
التكامل البسيط أحادي الاتجاه، أي نموذج ويب ينشئ Lead مع External ID ومعالجة أخطاء معقولة، يتراوح عادةً بين GBP 3,000 وGBP 7,000. أما المزامنة ثنائية الاتجاه لكائن أو كائنين مع حل التعارضات ومهمة مطابقة فتقع غالباً بين GBP 15,000 وGBP 40,000. والتكامل المدفوع بالأحداث على Pub/Sub مع إعادة تشغيل ومعالجة للمهملات ومراقبة يستقر عموماً بين GBP 30,000 وGBP 80,000.
ما ينبغي أن يتضمنه التسليم
وثيقة ربط على مستوى الحقل متفق عليها مع الجهة المعنية لا مستنتجة. وExternal ID على كل كائن متزامن. ومعالجة أخطاء بمخزن مهملات وعملية إعادة إرسال موثقة. ومهمة مطابقة. ومراقبة لاستهلاك API مقابل حصة المؤسسة، بتنبيه أدنى من السقف بكثير. وأدلة تشغيل لتدوير الرموز وانتهاء الشهادات وإعادة التشغيل. وإعداد sandbox مكتوب بسكربت كي ينجو من التحديث. والتكامل الخالي من ذلك نموذج أولي مهما قالت الفاتورة.
الكلفة المستمرة
خصص بين GBP 400 وGBP 1,500 شهرياً للمراقبة، ولإصدارات Salesforce الثلاثة سنوياً، ولتدوير بيانات الاعتماد، ولتغييرات الحقول التي سيجريها مسؤول دون إخبارك. والمؤسسات التي تموّل هذا هي المؤسسات التي تستمر تكاملاتها في العمل.
كيف يُنجَز البناء
أنماط الفشل هنا متكررة على نحو ممل: حصة تُكتشف متأخراً، ومشغّل لم يدققه أحد، وLead كان ينبغي أن يكون Contact، ولا وسيلة لإعادة تشغيل دفعة فاشلة. الأربعة كلها رخيصة المنع وقت التصميم وباهظة الإصلاح بعد وجود سجلات حقيقية.
تبني Mecanik تكاملات Salesforce وتصونها ضمن عملها في تطوير البرمجيات، بدءاً من تدقيق حصة المؤسسة ومشغّلاتها ونموذج بياناتها قبل كتابة أي كود. ولقطعة عمل تكامل محددة بدل ارتباط كامل، يمكنك توظيف مطوّر ويب مباشرةً.
الأسئلة الشائعة
كم عدد استدعاءات API التي يحصل عليها تكامل Salesforce يومياً؟ يعتمد ذلك على الإصدار وعدد التراخيص، والحصة تسري على المؤسسة كلها لا على كل تكامل على حدة. إصدارا Enterprise وProfessional مع صلاحية API يحصلان على 100,000 استدعاء زائد 1,000 لكل ترخيص Salesforce أو Salesforce Platform، ويحصل Unlimited وPerformance على 100,000 زائد 5,000 لكل ترخيص، وتحصل Developer Edition على 15,000 ثابتة خلال 24 ساعة متدحرجة.
هل أستخدم REST API أم Bulk API مع Salesforce؟ استخدم REST API للعمل التفاعلي منخفض الحجم ذي شكل السجل، وBulk API 2.0 لعمليات التحميل والتصدير حيث يكون الحجم كبيراً ويكون الجواب غير المتزامن مقبولاً. ولكل ما بينهما، تُحسب sObject Collections بواقع 200 سجل لكل طلب وComposite بواقع 25 طلباً فرعياً لكل طلب استدعاءً واحداً من حصتك، وتزيلان معظم الضغط.
أي تدفق OAuth ينبغي أن يستخدمه تكامل Salesforce بين الخوادم؟ تدفق JWT bearer أو تدفق client credentials، مشغّلاً بمستخدم تكامل مخصص مقتصر على API. أما تدفق اسم المستخدم وكلمة المرور فمحجوب افتراضياً في المؤسسات الأحدث ومجدول للسحب، فلا ينبغي استخدامه في عمل جديد. ولاحظ أيضاً أن إنشاء connected apps مقيّد اعتباراً من إصدار Spring ‘26 وأن Salesforce توصي الآن بـ external client apps.
لماذا يفشل تكامل Salesforce لدي في الدفعات الكبيرة وحدها؟ السبب غالباً مشغّل Apex لم يُهيَّأ للدفعات. تسلّم Salesforce المشغّلات مجموعةً من السجلات، والمشغّل المكتوب كأنه يتلقى سجلاً واحداً في كل مرة سيشغّل استعلاماته مرة لكل سجل، فيتجاوز حد 100 استعلام SOQL حين تصل دفعتك. وهو يعمل جيداً مع مستخدمي الواجهة الذين يحفظون سجلاً واحداً في كل مرة، ولهذا بقي غير مكتشف.
هل أحتاج وسيط تكامل للاتصال بـ Salesforce؟ ليس لتكامل بمصدر واحد وهدف واحد واتجاه واحد وحجم متواضع، حيث البناء المباشر أرخص وأبسط. ويستحق الوسيط كلفته حين تتبادل أنظمة عدة البيانات، أو يحتاج مستخدمو الأعمال إلى تغيير عمليات الربط دون نشر، أو تحتاج إلى تنسيق وإعادة محاولة مركزيين. إنه ينقل الكلفة لا يزيلها، وهو لا يزيد حصة API لديك.
التعليقات