Salesforce Commerce Cloud هي واحدة من أقوى منصات التجارة الإلكترونية للشركات في العالم. وهي أيضاً من بين الأكثر التباساً. تختار العلامات التجارية منصة SFCC للشعار والوعود بـ Einstein AI والنظام البيئي Salesforce. تبدأ العقوبة قبل وقت طويل من الانطلاق. بعض الفرق لا تصل إلى هناك أبداً. تتطلب SFCC مطوري برامج متمكنين يعيشون داخل النظام البيئي Salesforce. بدونهم، تبدأ تجاوزات التكاليف في البداية الأولى، وتنزلق الجداول الزمنية في الشهر الأول، وبعض المشاركات ببساطة لا تصل إلى الإطلاق.
شيء واحد لا يقول معظم الناس صراحة. أنت تبني على Demandware. استحوذت Salesforce على Demandware في 2016 مقابل 2.8 مليار دولار وأعادت تسميتها Salesforce Commerce Cloud في نفس العام. البنية التحتية الأساسية، نموذج الخرطوشة، ISML templating، Business Manager، معمارية الخط الأنابيب - كل ذلك هو الحمض النووي Demandware. استثمرت Salesforce بكثافة على رأسه، خاصة مع Einstein AI و Composable Storefront. لكن SFCC للشركات لا تزال، بشكل أساسي، منصة Demandware. المطورون الذين لم يعيشوا أبداً داخل هذا النظام البيئي يقللون بشكل روتيني من منحنى التعلم.
Salesforce يقوم أيضاً ببناء شيء يسمى Commerce on Core، منتج التجارة الإلكترونية الأحدث لديهم المبني بشكل أصلي على منصة Salesforce (Force.com) بدلاً من البنية التحتية Demandware القديمة. أشارت Salesforce إلى هذا على أنه عرضة التجارة الإلكترونية DTC الخاصة بهم. اعتباراً من الآن، إنها ليست بديلاً لـ Commerce Cloud الكبيرة للشركات. يستهدف حالات الاستخدام متوسطة السوق وسيناريوهات الخدمة الذاتية B2B. إذا كنت تقيم SFCC اليوم كعلامة تجارية للشركات، فأنت لا تزال تقيم منصة الوراثة Demandware. اعرف ما تشتريه.
طبقنا SFCC في Columbia Sportswear، إحدى أكبر شركات الملابس في الهواء الطلق في العالم، وفي Empower Global، منصة مبنية لرفع العلامات التجارية المملوكة للسود. نطاق مختلف، نماذج أعمال مختلفة، نفس الدرس. تقدم المنصة النتائج عندما تحترم ما هي عليه.
هذا ما تعلمناه عن تشغيل SFCC على نطاق واسع.
قرار المعمارية الذي يجب عليك الحصول عليه بشكل صحيح أولاً
تمنحك SFCC مسارين معماريين أساسيين. SFRA (Storefront Reference Architecture) هو النهج المقترن التقليدي حيث يعيش الواجهة الأمامية والخلفية معاً داخل منصة SFCC. Composable Storefront (المبني على PWA Kit و Managed Runtime Salesforce) يفكك الواجهة الأمامية بالكامل، مما يوفرها كتطبيق ويب متقدم قائم على React متصل بـ SFCC عبر API.
يشكل هذا القرار كل شيء في المنطقة السفلية. هيكل الفريق، توظيف المطورين، تعقيد التكامل، الوقت حتى الوصول إلى السوق، وتكاليف الصيانة المستمرة جميعها تتتبع المعمارية التي اخترتها في اليوم الأول.
عندما يكون SFRA الإجابة الصحيحة
يكون SFRA منطقياً عندما تكون خبرة فريقك الموجودة في SFCC قائمة على الخرطوشة، عندما تكون مساحة التكامل الخاصة بك ضيقة، وعندما تحتاج إلى الانطلاق بسرعة. تم اختبار SFRA في عمليات نشر هائلة عبر مئات الشركات. نظام خرطوشة الطرف الثالث لـ SFRA ناضج. معالجات الدفع وبرامج الضرائب وأنظمة الولاء والأدوات الموصى بها جميعها لها عمليات تكامل SFRA أصلية. أنت لا تبني من الصفر.
الخطر مع SFRA هو سقف الأداء على المدى الطويل. المعمارية المقترنة تعني أن تحسينات الواجهة الأمامية تتطلب نشر الخلفية. تحسين سرعة الصفحة يضرب القيود الهيكلية. مع أن المركبات تصبح الاتجاه الاستراتيجي للمنصة، ستحتاج SFRA في النهاية إلى الترحيل على أي حال.
عندما يكون Composable الإجابة الصحيحة
يكون Composable Storefront منطقياً عندما تكون الأداء متطلباً صعباً، عندما يكون لدى فريقك خبرة React قوية، وعندما تحتاج إلى أقصى مرونة لتركيب أفضل الحلول عبر طبقات البحث والـ CMS والتخصيص. أوقات تحميل الصفحة في تطبيق PWA Kit المبني بشكل جيد أسرع حقاً. تجربة التطوير حديثة. الواجهة الأمامية محمولة بالكامل.
الخطر مع composable هو نضج التكامل. النظام البيئي لـ PWA Kit للطرف الثالث لا يزال في تطوره. ما كان تثبيت خرطوشة في SFRA يصبح تطويراً مخصصاً في composable. وتطبيق Salesforce الهجين (تشغيل SFRA و composable في نفس الوقت) يحل مشكلة الترحيل من الناحية النظرية لكنه ينشئ تعقيداً تشغيلياً يتضاعف كلما طال مدة تشغيله.
إذا كنت تقوم بتطبيق SFCC الجديد في 2025، فبني composable من اليوم الأول ما لم يكن لديك سبب محدد عدم القيام بذلك. إذا كنت على SFRA، فيجب أن يكون لديك خريطة طريق لـ composable لكن لا تهاجر حتى يكون لديك الفريق والميزانية وحالة عمل واضحة تبرر الاضطراب.
معمارية التكامل هي المكان الذي تفشل فيه مشاريع SFCC
SFCC لا تعيش في عزلة. تتصل بـ ERP الخاص بك للمخزون والتسعير. تتصل بـ OMS الخاص بك لإدارة الطلبات وتوجيه الوفاء. تتصل بـ CRM الخاص بك لبيانات العملاء والتخصيص. تتصل بـ PIM الخاص بك لمحتوى المنتج. احصل على هذه التكاملات بشكل خاطئ والمنصة التي بدت قوية جداً في العرض التوضيحي تصبح التزاماً في الإنتاج.
في Columbia، طبقنا Order Dynamics كـ OMS وبنينا طبقة تكامل سحابية جديدة تماماً وقائمة على الأحداث تربط واجهة المتجر SFCC بأنظمة الخلفية عبر التسويق والولاء العملاء والذكاء التجاري. امتدت معمارية التكامل عبر 21 موقع تجارة إلكترونية عالمي تم إطلاقها بنفس الوقت. لم يكن تعقيد التكامل عائقاً أمام نشر SFCC. كان الانتشار. كانت واجهة المتجر الجزء السهل.
أكثر ثلاثة أخطاء تكامل نراها بشكل متكرر
التكاملات المتزامنة على تدفقات البيانات الخاطئة. الاستعلامات عن توفر المخزون في الوقت الفعلي من واجهة المتجر إلى ERP عند الدفع تخلق زمن انتظار ونقاط فشل. يجب الضغط على توفر المخزون إلى SFCC على جدول زمني وتخزينه مؤقتاً. احجز المكالمات المتزامنة للحظات التي تتطلبها فعلاً، وتحديداً وضع الطلب والتقاط الدفع.
OMS كـ فكرة لاحقة. Salesforce Order Management هي OMS قادرة وتندمج بشكل طبيعي مع SFCC - طبقناها في Empower Global جنباً إلى جنب مع Commerce Cloud و Marketing Cloud و Service Cloud و Loyalty Cloud. لكن حتى التكامل الأصلي لا يزال يتطلب تكوين كبير لتحقيق الوفاء متعدد المواقع، منطق الشحن المنقسم، وتوجيه الإرجاع. العلامات التجارية التي تعامل OMS كمرحلة لاحقة وتوصل SFCC مباشرة بـ ERP لإدارة الطلبات تبني الدين التقني الذي يكلف من اثنين إلى ثلاثة أضعاف لفك الارتباط عما كان سيكلفه القيام بذلك بشكل صحيح في المرة الأولى.
لا توجد استراتيجية بديلة قائمة على الأحداث. تفشل التكاملات. تحتاج معمارتك إلى التعامل مع وقت التوقف ERP دون عرض تجربة دفع مكسورة. صمم للوضع المتدهور من اليوم الأول. خزن مؤقتاً ما يمكن تخزينه مؤقتاً. ضع في قائمة الانتظار ما يجب أن يكون في الوقت الفعلي. حدد البديل لكل نقطة تكامل قبل الانطلاق، وليس بعد حادث الإنتاج الأول.
Einstein AI حقيقي. لكنه يتطلب بيانات حقيقية لكي يعمل.
Einstein for Commerce قوي حقاً. توصيات المنتجات، الفرز التنبؤي، رؤى التجارة الإلكترونية، وقواميس بحث Einstein يمكن أن تحرك معدلات التحويل والقيمة المتوسطة للطلب ومعدلات البحث إلى الشراء بشكل ملموس. رأينا يعمل. رأينا أيضاً علامات تجارية تنفق ستة أرقام على تفعيل Einstein ورؤية لا شيء ملموس يتحرك لأن البيانات الأساسية لم تكن جاهزة.
يتعلم Einstein من الإشارات السلوكية. النقرات والمشاهدات والإضافة إلى السلة والشراء والاستعلامات البحثية وتسلسلات الجلسات جميعها توجه النماذج. إذا كان الكتالوج الخاص بك سيء البناء، فإن شروط البحث الخاصة بك لم تحتوي على خرائط، أو أن تدفق بيانات السلوك الخاص بك غير مكتمل، تعكس مخرجات Einstein جودة ذلك. القمامة الداخلة، القمامة الخارجة تنطبق بنفس الدقة على تخصيص الذكاء الاصطناعي كما تنطبق على أي نظام بيانات آخر.
ما تحتاجه قبل أن يقدم Einstein النتائج
- كتالوج منتج نظيف. كل منتج يحتاج إلى سمات دقيقة وفئات كاملة وروابط متغيرة مناسبة. تستخدم نماذج توصية Einstein بنية الكتالوج كإشارة أساسية. الكتالوج المسطح والمنسوب بشكل غير متسق ينتج عنه توصيات تبدو عشوائية لأنها كذلك.
- سجل السلوك الكافي. يحتاج Einstein إلى الحجم للعثور على الأنماط. المتاجر الجديدة والكتالوجات المهاجرة مؤخراً والقطاعات منخفضة حركة المرور لا تعطي النماذج إشارة كافية. خطط لفترة تراكم البيانات من 60 إلى 90 يوماً قبل أن تصل التوصيات إلى دقة ذات معنى.
- استثمار قاموس البحث. قواميس بحث Einstein تحسن ملحوظة تحسن ملاءمة البحث من خلال التعامل مع الأخطاء الإملائية والمرادفات والمصطلحات الخاصة بالعلامة التجارية. لكنها تتطلب تنسيقاً مستمراً. شخص ما في فريقك يحتاج إلى امتلاك هذا. لا أحد يفعل، والبحث يصبح نقطة الهجر الأعلى.
- استراتيجية الموضع وليس فقط التفعيل. مكان وضع التوصيات مهم مثل التوصيات التي تظهر. وضع الصفحة التفصيلية للمنتج يدفع البيع المتقاطع. وضع صفحة السلة يدفع الزيادة. وضع الصفحة الرئيسية يدفع الاكتشاف. كل يتطلب استراتيجية مختلفة ومقاييس نجاح مختلفة.
معمارية متعددة المواقع والعالمية. خطط لها قبل أن تبني.
قدرات SFCC متعددة المواقع هي أحد أعظم نقاط القوة التنافسية. يمكن لمثيل واحد من SFCC تشغيل العشرات من المتاجر عبر العلامات التجارية والمناطق واللغات والعملات مع إدارة كتالوج مركزية وتجارب عملاء مترجمة. في Columbia Sportswear، ساعدنا في تصميم وإطلاق 21 موقع تجارة إلكترونية عالمي في نفس الوقت من أساس SFCC مشترك - مواقع تمتد عبر مناطق متعددة مع وقت تشغيل يقترب من 100٪ من اليوم الأول.
لكن متعددة المواقع التي تعمل بشكل خاطئ أسوأ من عدم وجود متعددة مواقع على الإطلاق. قرارات الحوكمة التي تتخذها في التطبيق الأول تحدد مدى تكلفة كل إطلاق متجر مستقبلي.
قرارات الحوكمة التي تتضاعف بمرور الوقت
الكتالوج المشترك مقابل الكتالوج الخاص بالموقع. إذا قمت ببناء كتالوج أحادي كل موقع يشاركه دون منطق التباين، فأنت تنشئ قيوداً عندما تحتاج مناطق مختلفة إلى تسعير أو محتوى أو مجموعة مختلفة. بنى معمارية الكتالوج مع اختلاف متعددة المواقع في الاعتبار من البداية، حتى لو كنت تطلق متجراً واحداً فقط في البداية.
الكود المشترك مقابل خراطيش خاصة بالموقع. كل تخصيص خاص بالموقع مضاف مباشرة إلى مسار الخرطوشة الأساسي ينشئ دين. بنى نموذج وراثة خرطوشة واضح في اليوم الأول. الخراطيش الأساسية للوظائف المشتركة. خراطيش الموقع للتباين المترجم. خراطيش مخصصة لمنطق العلامة التجارية. انتهاك هذا النموذج من أجل السرعة في التطبيقات المبكرة يجعل المواقع اللاحقة أكثر تكلفة بشكل كبير.
معمارية إدارة المحتوى. تعمل Page Designer وContent Assets الخاصة بـ SFCC بشكل جيد على نطاق موقع واحد وتصبح غير عملية على نطاق عالمي دون نموذج حوكمة. حدد من يمكنه تحرير ماذا، ما هو المحتوى المشترك مقابل المترجم، وكيف تتدفق موافقات المحتوى عبر الفرق قبل الإطلاق. إعادة تصميم هذا بعد الحقيقة مؤلمة.
إطلاق 21 موقعاً عالمياً في نفس الوقت على أساس SFCC مشترك ليس شيئاً ترتجله. نموذج الحوكمة لبنية الكتالوج ووراثة الخرطوشة وإدارة المحتوى يجب أن يتم تصميمه قبل بناء الموقع الأول، وليس معاد بناؤه بعد الموقع الخامس. الحصول على ذلك بشكل صحيح من البداية هو ما جعل إطلاق 21 موقعاً متزامناً ممكناً.
ترحيل SFRA إلى Composable. ما لا تخبره Salesforce.
كانت Salesforce واضحة أن Composable Storefront هو الاتجاه الاستراتيجي للمنصة. يمثل PWA Kit و Managed Runtime مكان استثمار SFCC يذهب. هذا يعني أنه إذا كنت على SFRA، فالترحيل ليس مسألة الوقت بل متى.
يسمح مسار التطبيق الهجين Salesforce بتشغيل SFRA و Composable في نفس الوقت، مع الترحيل صفحة بصفحة أو دفق بدفق. من الناحية النظرية، هذا يقلل المخاطر. من الناحية العملية، الحالة الهجينة هي الحالة الأكثر خطورة يمكن أن تكون عليها على المدى الطويل.
يعني التشغيل الهجين الحفاظ على نظامي مصادقة في نفس الوقت. ابتداءً من إصدار SFCC 25.3، يتطلب هذا Hybrid Authentication لإدارة كل من ملف تعريف الجلسة SFRA التقليدي و SLAS JSON Web Token في المزامنة عبر كل طلب. هذه المزامنة ليست تافهة، والنافذة لأخطاء حالة الجلسة التي تؤثر على التحويل مفتوحة طوال الوقت الذي تكون فيه في الوضع الهجين.
توصيتنا هي أن تعامل الهجين كدولة انتقالية مع تاريخ انتهاء صعب، وليس كنموذج تشغيلي. حدد نطاق ترحيل composable، وحدد موعد نهائي للخروج من الهجين، والموارد وفقاً لذلك. العلامات التجارية التي تدع تطبيقات هجينة تنجرف تصبح مكلفة بشكل دائم في التشغيل.
الأداء على نطاق واسع ليس تلقائياً
تتعامل SFCC مع حركة ذروة جيدة. تدرج البنية التحتية Managed Runtime تلقائياً. يتعامل CDN Salesforce مع التسليم العالمي. لكن البنية التحتية للتحجيم التلقائي لا تعوض مشاكل الأداء على مستوى التطبيق، ويمكن لتطبيقات SFCC أن تتراكم هذه المشاكل بهدوء حتى حدث حركة مرور عالية مثل إطلاق منتج أو فترة الإجازات يكشف عنها جميعاً في نفس الوقت.
عمل الأداء الذي يحدث قبل الانطلاق وليس بعده
- عمليات تدقيق أداء مكون Page Designer. صفحات SFCC الموجهة بشكل كبير والمبنية بمكونات Page Designer متعددة يمكن أن تولد مكالمات API مفرطة. تدقيق كل قالب واجهة متجر لحجم مكالمة API قبل الانطلاق. دمج المكالمات. خزن مؤقتاً بقوة على مستوى المكون.
- استراتيجية تحسين الصور. قدرات Dynamic Imaging الخاصة بـ SFCC قوية لكنها تتطلب تكويناً متعمداً. تسليم الصور غير المحسنة هي واحدة من أكثر الأسباب شيوعاً لنقاط Core Web Vitals السيئة على متاجر SFCC. حدد حجم الصور وعمل الفرز والجودة بشكل صريح. لا تعتمد على الافتراضيات.
- اختبار الحمل قبل كل حدث ذروة. اختبر طبقة التكامل الخاصة بك وليس فقط واجهة المتجر. البنية التحتية SFCC تتسع. ERP الخاص بك و OMS وبوابة الدفع قد لا تكون كذلك. انتهاء صلاحية السداد في حركة ذروة هو حدث إيرادات. اختبر الحمل للمكدس الكامل.
- التكافؤ بين الحماية والإنتاج. لدى حمايات SFCC خصائص أداء مختلفة عن الإنتاج. اختبار الأداء في sandbox يخبرك عن الأداء النسبية بين تغييرات التعليمات البرمجية، وليس الأداء المطلقة للإنتاج. اختبر في بيئة تشبه الإنتاج قبل الإصدارات الكبرى.
دعنا نبني تطبيق SFCC الخاص بك بـ الطريقة الصحيحة
طبقت TechSparq Salesforce Commerce Cloud للعلامات التجارية للشركات العالمية. نحن نعرف مكان التعقيد ويعيش وكيفية الهندسة حوله. إذا كنت تخطط لتطبيق SFCC جديد أو تحسين واحد موجود أو التنقل في ترحيل SFRA إلى Composable، يجب أن نتحدث.
احجز استشارة ↖︎