ترحيل البيانات القديمة دون إفسادها

من الصعب ترحيل البيانات القديمة.

تمتلك العديد من المؤسسات أنظمة إدارة علاقات عملاء أعمال محلية قديمة ومعقدة. يوجد اليوم الكثير من بدائل SaaS السحابية ، والتي تأتي مع العديد من الفوائد ؛ ادفع كما تذهب وادفع فقط مقابل ما تستخدمه. لذلك ، قرروا الانتقال إلى الأنظمة الجديدة.

لا أحد يريد ترك بيانات قيمة عن العملاء في النظام القديم والبدء بالنظام الجديد الفارغ ، لذلك نحن بحاجة إلى ترحيل هذه البيانات. لسوء الحظ ، لا يعد ترحيل البيانات مهمة سهلة ، حيث يتم استهلاك حوالي 50 بالمائة من جهود النشر بواسطة أنشطة ترحيل البيانات. وفقًا لشركة Gartner ، فإن Salesforce هي الشركة الرائدة في حلول CRM السحابية. لذلك ، يعد ترحيل البيانات موضوعًا رئيسيًا لنشر Salesforce.

لذا ، كيف يمكننا ضمان انتقال ناجح للبيانات القديمة إلى نظام جديد لامع ونضمن أننا سنحتفظ بكل تاريخه؟ في هذه المقالة ، أقدم 10 نصائح لترحيل البيانات بنجاح. تنطبق النصائح الخمس الأولى على أي ترحيل للبيانات ، بغض النظر عن التكنولوجيا المستخدمة.

ترحيل البيانات بشكل عام

1. اجعل الهجرة مشروعًا منفصلاً

في قائمة التحقق من نشر البرنامج ، لا يعتبر ترحيل البيانات عنصرًا "تصديرًا واستيرادًا" تتم معالجته بواسطة أداة ترحيل بيانات ذكية "زر ضغط واحد" والتي تحتوي على تخطيط محدد مسبقًا للأنظمة المستهدفة.

يعد ترحيل البيانات نشاطًا معقدًا ، ويستحق مشروعًا وخطة ونهجًا وميزانية وفريقًا منفصلين. يجب إنشاء نطاق وخطة على مستوى الكيان في بداية المشروع ، مما يضمن عدم حدوث مفاجآت ، مثل "أوه ، لقد نسينا تحميل تقارير زيارة هؤلاء العملاء ، من سيفعل ذلك؟" قبل أسبوعين من الموعد النهائي.

يحدد نهج ترحيل البيانات ما إذا كنا سنقوم بتحميل البيانات دفعة واحدة (المعروف أيضًا باسم الانفجار الكبير ) ، أو ما إذا كنا سنقوم بتحميل دفعات صغيرة كل أسبوع.

هذا ليس قرارًا سهلاً ، رغم ذلك. يجب الاتفاق على النهج وإبلاغه لجميع أصحاب المصلحة في مجال الأعمال والتقنية حتى يكون الجميع على دراية بموعد وما هي البيانات التي ستظهر في النظام الجديد. هذا ينطبق على انقطاع النظام أيضا.

2. تقدير واقعي

لا تقلل من أهمية تعقيد ترحيل البيانات. تصاحب هذه العملية العديد من المهام التي تستغرق وقتًا طويلاً ، والتي قد تكون غير مرئية في بداية المشروع.

على سبيل المثال ، تحميل مجموعات بيانات محددة لأغراض التدريب بمجموعة من البيانات الواقعية ، ولكن مع إخفاء عناصر حساسة ، بحيث لا تؤدي أنشطة التدريب إلى إنشاء إشعارات بالبريد الإلكتروني للعملاء.

العامل الأساسي للتقدير هو عدد الحقول التي سيتم نقلها من نظام المصدر إلى النظام المستهدف.

هناك حاجة إلى بعض الوقت في مراحل مختلفة من المشروع لكل مجال ، بما في ذلك فهم المجال ، وتعيين حقل المصدر إلى الحقل المستهدف ، وتكوين أو بناء التحولات ، وإجراء الاختبارات ، وقياس جودة البيانات للميدان ، وما إلى ذلك.

يمكن أن يؤدي استخدام أدوات ذكية ، مثل Jitterbit و Informatica Cloud Data Wizard و Starfish ETL و Midas وما شابه ذلك ، إلى تقليل هذا الوقت ، خاصة في مرحلة البناء.

على وجه الخصوص ، لا يمكن أتمتة فهم بيانات المصدر - وهي المهمة الأكثر أهمية في أي مشروع ترحيل - بواسطة الأدوات ، ولكنها تتطلب من المحللين قضاء بعض الوقت في استعراض قائمة الحقول واحدًا تلو الآخر.

أبسط تقدير للجهد الإجمالي هو يوم واحد لكل حقل يتم نقله من النظام القديم.

الاستثناء هو نسخ البيانات بين نفس المخططات المصدر والهدف دون مزيد من التحويل - يُعرف أحيانًا بالترحيل 1: 1 - حيث يمكننا أن نبني التقدير على عدد الجداول المراد نسخها.

التقدير التفصيلي هو فن خاص به.

3. التحقق من جودة البيانات

لا تبالغ في تقدير جودة بيانات المصدر ، حتى لو لم يتم الإبلاغ عن أي مشكلات تتعلق بجودة البيانات من الأنظمة القديمة.

الأنظمة الجديدة لها قواعد جديدة ، والتي قد تنتهك بالبيانات القديمة. هذا مثال بسيط. يمكن أن يكون البريد الإلكتروني لجهة الاتصال إلزاميًا في النظام الجديد ، ولكن قد يكون للنظام القديم الذي يبلغ من العمر 20 عامًا وجهة نظر مختلفة.

يمكن أن تكون هناك ألغام مخفية في البيانات التاريخية لم يتم لمسها لفترة طويلة ولكن يمكن تنشيطها عند النقل إلى النظام الجديد. على سبيل المثال ، البيانات القديمة التي تستخدم العملات الأوروبية التي لم تعد موجودة تحتاج إلى تحويلها إلى اليورو ، وإلا يجب إضافة العملات إلى النظام الجديد.

تؤثر جودة البيانات بشكل كبير على الجهد ، والقاعدة البسيطة هي: كلما تقدمنا ​​في التاريخ ، زادت الفوضى التي نكتشفها. وبالتالي ، من الضروري أن نقرر مبكرًا مقدار التاريخ الذي نريد نقله إلى النظام الجديد.

4. إشراك رجال الأعمال

رجال الأعمال هم الوحيدون الذين يفهمون البيانات حقًا ويمكنهم بالتالي تحديد البيانات التي يمكن التخلص منها وما هي البيانات التي يجب الاحتفاظ بها.

من المهم إشراك شخص ما من فريق العمل أثناء تمرين رسم الخرائط ، وللتراجع في المستقبل ، من المفيد تسجيل قرارات رسم الخرائط وأسبابها.

نظرًا لأن الصورة تساوي أكثر من ألف كلمة ، قم بتحميل دفعة اختبارية في النظام الجديد ، ودع فريق العمل يلعب بها.

حتى إذا تمت مراجعة تعيين ترحيل البيانات والموافقة عليه من قبل فريق العمل ، يمكن أن تظهر المفاجآت بمجرد ظهور البيانات في واجهة المستخدم للنظام الجديد.

"أوه ، الآن أرى ، علينا تغييرها قليلاً" تصبح عبارة شائعة.

يعد الفشل في إشراك الخبراء المتخصصين ، الذين يكونون عادةً أشخاصًا مشغولين جدًا ، السبب الأكثر شيوعًا للمشكلات بعد بدء تشغيل نظام جديد.

5. تهدف إلى حل الترحيل الآلي

غالبًا ما يُنظر إلى ترحيل البيانات على أنه نشاط لمرة واحدة ، ويميل المطورون إلى التوصل إلى حلول مليئة بالإجراءات اليدوية على أمل تنفيذها مرة واحدة فقط. لكن هناك العديد من الأسباب لتجنب مثل هذا النهج.

• إذا تم تقسيم الترحيل إلى عدة موجات ، يتعين علينا تكرار نفس الإجراءات عدة مرات.
• عادةً ، هناك ثلاث عمليات ترحيل على الأقل لكل موجة: تشغيل جاف لاختبار أداء ووظائف ترحيل البيانات ، وتحميل كامل للتحقق من صحة البيانات لاختبار مجموعة البيانات بأكملها وإجراء اختبارات الأعمال ، وبالطبع ، حمل الإنتاج. يزيد عدد عمليات التشغيل بجودة البيانات الرديئة. يعد تحسين جودة البيانات عملية تكرارية ، لذلك نحتاج إلى العديد من التكرارات للوصول إلى نسبة النجاح المطلوبة.

وبالتالي ، حتى إذا كان الترحيل نشاطًا لمرة واحدة بطبيعته ، فإن اتخاذ إجراءات يدوية يمكن أن يؤدي إلى إبطاء عملياتك بشكل كبير.

ترحيل بيانات Salesforce

بعد ذلك سنغطي خمس نصائح لترحيل Salesforce بنجاح. ضع في اعتبارك أن هذه النصائح من المحتمل أن تكون قابلة للتطبيق على الحلول السحابية الأخرى أيضًا.

6. الاستعداد للأحمال الطويلة

الأداء هو أحد المقايضات ، إن لم يكن الأكبر ، عند الانتقال من حل محلي إلى حل سحابي - لا يتم استبعاد Salesforce.

عادةً ما تسمح الأنظمة المحلية بالتحميل المباشر للبيانات في قاعدة بيانات أساسية ، وباستخدام أجهزة جيدة ، يمكننا الوصول بسهولة إلى ملايين السجلات في الساعة.

لكن ليس في السحابة. في السحابة ، نحن مقيدون بشدة بعدة عوامل.

• زمن انتقال الشبكة - يتم نقل البيانات عبر الإنترنت.
• طبقة تطبيق Salesforce - يتم نقل البيانات من خلال طبقة متعددة المؤسسات لواجهة برمجة التطبيقات (API) السميكة حتى تصل إلى قواعد بيانات Oracle الخاصة بهم.
• رمز مخصص في Salesforce - عمليات التحقق المخصصة والمشغلات ومهام سير العمل وقواعد الكشف عن التكرار وما إلى ذلك - والتي يعمل العديد منها على تعطيل الأحمال المتوازية أو المجمعة.

نتيجة لذلك ، يمكن أن يصل أداء التحميل إلى آلاف الحسابات في الساعة.

يمكن أن يكون أقل ، أو يمكن أن يكون أكثر ، اعتمادًا على أشياء ، مثل عدد الحقول وعمليات التحقق من الصحة والمحفزات. لكنها عدة درجات أبطأ من التحميل المباشر لقاعدة البيانات.

يجب أيضًا مراعاة تدهور الأداء ، الذي يعتمد على حجم البيانات في Salesforce.

وهو ناتج عن فهارس في RDBMS (Oracle) الأساسي المستخدمة للتحقق من المفاتيح الخارجية والحقول الفريدة وتقييم قواعد النسخ. الصيغة الأساسية هي تباطؤ بنسبة 50 بالمائة تقريبًا لكل درجة من 10 ، ناتج عن O (logN) جزء التعقيد الزمني في عمليات الفرز و B-tree.

علاوة على ذلك ، فإن Salesforce لديها العديد من حدود استخدام الموارد.

أحدها هو حد Bulk API الذي تم تعيينه على 5000 دفعة في نوافذ متداولة على مدار 24 ساعة ، بحد أقصى 10000 سجل في كل دفعة.

لذا ، فإن الحد الأقصى النظري هو 50 مليون سجل يتم تحميلها في 24 ساعة.

في مشروع حقيقي ، يكون الحد الأقصى أقل بكثير بسبب حجم الدُفعة المحدود عند استخدام ، على سبيل المثال ، المشغلات المخصصة.

هذا له تأثير قوي على نهج ترحيل البيانات.

حتى بالنسبة لمجموعات البيانات متوسطة الحجم (من 100،000 إلى مليون حساب) ، فإن نهج الانفجار الكبير غير وارد ، لذلك يجب علينا تقسيم البيانات إلى موجات ترحيل أصغر.

هذا ، بالطبع ، يؤثر على عملية النشر بأكملها ويزيد من تعقيد الترحيل لأننا سنضيف زيادات في البيانات إلى نظام تم ملؤه بالفعل بواسطة عمليات الترحيل السابقة والبيانات التي أدخلها المستخدمون.

يجب علينا أيضًا مراعاة هذه البيانات الموجودة في عمليات التحويل والتحقق من صحة الترحيل.

علاوة على ذلك ، قد تعني الأحمال الطويلة أنه لا يمكننا إجراء عمليات الترحيل أثناء انقطاع النظام.

إذا كان جميع المستخدمين موجودين في بلد واحد ، فيمكننا الاستفادة من انقطاع الخدمة لمدة ثماني ساعات أثناء الليل.

لكن بالنسبة لشركة ، مثل Coca-Cola ، التي لديها عمليات في جميع أنحاء العالم ، فهذا غير ممكن. بمجرد أن يكون لدينا الولايات المتحدة واليابان وأوروبا في النظام ، فإننا نغطي جميع المناطق الزمنية ، لذا فإن يوم السبت هو خيار الانقطاع الوحيد الذي لا يؤثر على المستخدمين.

وقد لا يكون ذلك كافيًا ، لذلك ، يجب علينا التحميل أثناء الاتصال بالإنترنت ، عندما يعمل المستخدمون مع النظام.

7. احترام احتياجات الهجرة في تطوير التطبيقات

يجب أن تكون مكونات التطبيق ، مثل عمليات التحقق من الصحة والمشغلات ، قادرة على التعامل مع أنشطة ترحيل البيانات. لا يعد التعطيل الثابت لعمليات التحقق في وقت تحميل الترحيل خيارًا إذا كان يجب أن يكون النظام متصلاً بالإنترنت. بدلاً من ذلك ، يتعين علينا تنفيذ منطق مختلف في عمليات التحقق من التغييرات التي يقوم بها مستخدم ترحيل البيانات.

• يجب عدم مقارنة حقول التاريخ بتاريخ النظام الفعلي لأن ذلك سيعطل تحميل البيانات التاريخية. على سبيل المثال ، يجب أن يسمح التحقق بإدخال تاريخ بدء حساب سابق للبيانات التي تم ترحيلها.
• يجب تنفيذ الحقول الإلزامية ، التي قد لا يتم ملؤها بالبيانات التاريخية ، على أنها غير إلزامية ، ولكن مع التحقق من الصحة الحساسة للمستخدم ، وبالتالي السماح بالقيم الفارغة للبيانات الواردة من الترحيل ، ولكن مع رفض القيم الفارغة القادمة من المستخدمين العاديين عبر واجهة المستخدم الرسومية .
• يجب أن تكون المشغلات ، خاصة تلك التي ترسل سجلات جديدة إلى التكامل ، قادرة على التشغيل / إيقاف التشغيل لمستخدم ترحيل البيانات من أجل منع إغراق التكامل بالبيانات التي تم ترحيلها.

هناك خدعة أخرى تتمثل في استخدام الحقل "المعرف القديم" أو "معرّف الترحيل" في كل كائن تم ترحيله. هناك سببان لهذا. الأول واضح: الاحتفاظ بالمعرف من النظام القديم للتراجع ؛ بعد أن تكون البيانات في النظام الجديد ، قد يظل الأشخاص يرغبون في البحث في حساباتهم باستخدام المعرفات القديمة الموجودة في أماكن مثل رسائل البريد الإلكتروني والمستندات وأنظمة تتبع الأخطاء. عادة سيئة؟ يمكن. لكن سيشكرك المستخدمون إذا احتفظت بمعرفاتهم القديمة. السبب الثاني تقني ويأتي من حقيقة أن Salesforce لا تقبل المعرفات المقدمة صراحةً للسجلات الجديدة (على عكس Microsoft Dynamics) ولكنها تنشئها أثناء التحميل. تظهر المشكلة عندما نريد تحميل كائنات فرعية لأننا يجب أن نخصص لها معرفات للكائنات الأصلية. نظرًا لأننا لن نعرف هذه المعرفات إلا بعد التحميل ، فهذه ممارسة غير مجدية.

لنستخدم الحسابات وجهات الاتصال الخاصة بهم ، على سبيل المثال:

1. توليد البيانات للحسابات.
2. تحميل الحسابات إلى Salesforce ، واستلام المعرفات التي تم إنشاؤها.
3. دمج معرفات الحساب الجديدة في بيانات الاتصال.
4. توليد البيانات لجهات الاتصال.
5. تحميل جهات الاتصال في Salesforce.

يمكننا القيام بذلك بسهولة أكبر عن طريق تحميل الحسابات بمعرفاتهم القديمة المخزنة في حقل خارجي خاص. يمكن استخدام هذا الحقل كمرجع رئيسي ، لذلك عند تحميل جهات الاتصال ، فإننا ببساطة نستخدم معرف الحساب القديم كمؤشر للحساب الرئيسي:

1. إنشاء البيانات للحسابات ، بما في ذلك المعرف القديم.
2. أنشئ بيانات لجهات الاتصال ، بما في ذلك المعرف القديم للحساب.
3. تحميل الحسابات في Salesforce.
4. تحميل جهات الاتصال في Salesforce ، باستخدام معرف الحساب القديم كمرجع رئيسي.

الشيء الجميل هنا هو أننا فصلنا جيلًا عن مرحلة التحميل ، مما يسمح بتوازي أفضل ، وتقليل وقت الانقطاع ، وما إلى ذلك.

8. كن على دراية بالميزات المحددة لـ Salesforce

مثل أي نظام ، فإن Salesforce لديها الكثير من الأجزاء الصعبة التي يجب أن نكون على دراية بها لتجنب المفاجآت غير السارة أثناء ترحيل البيانات. فيما يلي بعض الأمثلة:

• تقوم بعض التغييرات على المستخدمين النشطين بإنشاء إشعارات بالبريد الإلكتروني تلقائيًا إلى رسائل البريد الإلكتروني للمستخدم. وبالتالي ، إذا أردنا اللعب ببيانات المستخدم ، فنحن بحاجة إلى إلغاء تنشيط المستخدمين أولاً والتفعيل بعد اكتمال التغييرات. في بيئات الاختبار ، نقوم بترتيب رسائل البريد الإلكتروني الخاصة بالمستخدمين بحيث لا يتم إطلاق الإشعارات على الإطلاق. نظرًا لأن المستخدمين النشطين يستهلكون تراخيص باهظة الثمن ، فلا يمكننا جعل جميع المستخدمين نشطين في جميع بيئات الاختبار. علينا إدارة مجموعات فرعية من المستخدمين النشطين ، على سبيل المثال ، لتفعيل فقط أولئك الموجودين في بيئة التدريب.
• لا يمكن تعيين المستخدمين غير النشطين ، لبعض الكائنات القياسية مثل الحساب أو الحالة ، إلا بعد منح إذن النظام "تحديث السجلات مع المالكين غير النشطين" ، ولكن يمكن تعيينهم ، على سبيل المثال ، إلى جهات الاتصال وجميع الكائنات المخصصة.
• عندما يتم إلغاء تنشيط جهة الاتصال ، يتم تشغيل جميع حقول إلغاء الاشتراك بصمت.
• عند تحميل عنصر مكرر في فريق الحساب أو كائن "مشاركة الحساب" ، يتم الكتابة فوق السجل الحالي بصمت. ومع ذلك ، عند تحميل شريك فرصة مكرر ، تتم إضافة السجل ببساطة مما يؤدي إلى وجود نسخة مكررة.
• يمكن كتابة حقول النظام ، مثل Created Date ، Created By ID ، Last Modified Date ، Last Modified By ID ، بشكل صريح فقط بعد منح إذن نظام جديد "تعيين حقول التدقيق عند إنشاء السجل".
• لا يمكن ترحيل تغييرات قيمة تاريخ الحقل على الإطلاق.
• لا يمكن تحديد مالكي المقالات المعرفية أثناء التحميل ولكن يمكن تحديثهم لاحقًا.
• الجزء الصعب هو تخزين المحتوى (المستندات والمرفقات) في Salesforce. هناك عدة طرق للقيام بذلك (باستخدام المرفقات والملفات ومرفقات الخلاصة والمستندات) ، ولكل طريقة مزاياها وعيوبها ، بما في ذلك حدود حجم الملف المختلفة.
• تجبر حقول قائمة الاختيار المستخدمين على تحديد إحدى القيم المسموح بها ، على سبيل المثال ، نوع الحساب. ولكن عند تحميل البيانات باستخدام Salesforce API (أو أي أداة مبنية عليها ، مثل Apex Data Loader أو Informatica Salesforce Connector) ، ستمر أي قيمة.

تطول القائمة ، لكن خلاصة القول هي: تعرف على النظام ، وتعلم ما يمكنه فعله وما لا يمكنه فعله قبل وضع افتراضات. لا تفترض السلوك القياسي ، خاصة بالنسبة للأشياء الأساسية. دائما البحث والاختبار.

9. لا تستخدم Salesforce كنظام أساسي لترحيل البيانات

من المغري جدًا استخدام Salesforce كمنصة لبناء حل ترحيل البيانات ، خاصة لمطوري Salesforce. إنها نفس التقنية لحل ترحيل البيانات كما هو الحال بالنسبة لتخصيص تطبيق Salesforce ، ونفس واجهة المستخدم الرسومية ، ونفس لغة برمجة Apex ، ونفس البنية التحتية. لدى Salesforce كائنات يمكن أن تعمل كجداول ، ونوع من لغة SQL ، لغة استعلام كائن Salesforce (SOQL). ومع ذلك ، يرجى عدم استخدامه ؛ سيكون عيبًا معماريًا أساسيًا.

Salesforce هو تطبيق SaaS ممتاز مع الكثير من الميزات الرائعة ، مثل التعاون المتقدم والتخصيص الغني ، لكن المعالجة الجماعية للبيانات ليست واحدة منها. أهم ثلاثة أسباب هي:

• الأداء - تتم معالجة البيانات في Salesforce بعدة درجات أبطأ مما هو عليه في RDBMS.
• عدم وجود ميزات تحليلية - لا تدعم خدمة SOQL الخاصة بـ Salesforce الاستعلامات المعقدة والوظائف التحليلية التي يجب أن تدعمها لغة Apex ، وستؤدي إلى تدهور الأداء أكثر.
• الهندسة المعمارية * - وضع نظام أساسي لترحيل البيانات داخل بيئة Salesforce معينة ليس ملائمًا للغاية. عادة ، لدينا بيئات متعددة لأغراض محددة ، وغالبًا ما يتم إنشاؤها لأغراض خاصة حتى نتمكن من تخصيص الكثير من الوقت لمزامنة الكود. بالإضافة إلى ذلك ، ستعتمد أيضًا على الاتصال وتوافر بيئة Salesforce المحددة هذه.

بدلاً من ذلك ، قم ببناء حل ترحيل البيانات في مثيل منفصل (يمكن أن يكون سحابة أو داخل الشركة) باستخدام نظام أساسي RDBMS أو ETL. قم بتوصيله بأنظمة المصدر واستهدف بيئات Salesforce التي تريدها ، وانقل البيانات التي تحتاجها إلى منطقة التدريج الخاصة بك وقم بمعالجتها هناك. سيسمح لك ذلك بما يلي:

• استفد من القوة والإمكانيات الكاملة للغة SQL أو ميزات ETL.
• احتفظ بكل التعليمات البرمجية والبيانات في مكان واحد حتى تتمكن من إجراء التحليلات عبر جميع الأنظمة.
  • على سبيل المثال ، يمكنك دمج أحدث تكوين من أحدث بيئة اختبار Salesforce مع بيانات حقيقية من بيئة Salesforce الخاصة بالإنتاج.
• أنت لا تعتمد كثيرًا على تقنية أنظمة المصدر والهدف ويمكنك إعادة استخدام الحل الخاص بك للمشروع التالي.

10. الإشراف على بيانات تعريف Salesforce

في بداية المشروع ، عادة ما نحصل على قائمة بحقول Salesforce ونبدأ في تمرين رسم الخرائط. أثناء المشروع ، غالبًا ما يتم إضافة حقول جديدة بواسطة فريق تطوير التطبيق إلى Salesforce ، أو تغيير بعض خصائص الحقل. يمكننا أن نطلب من فريق التطبيق إخطار فريق ترحيل البيانات بكل تغيير في نموذج البيانات ، ولكن هذا لا يعمل دائمًا. لكي نكون آمنين ، نحتاج إلى إخضاع جميع تغييرات نموذج البيانات للإشراف.

تتمثل إحدى الطرق الشائعة للقيام بذلك في تنزيل البيانات الوصفية المتعلقة بالترحيل من Salesforce إلى بعض مستودعات البيانات الوصفية ، على أساس منتظم. بمجرد حصولنا على هذا ، لا يمكننا فقط اكتشاف التغييرات في نموذج البيانات ، ولكن يمكننا أيضًا مقارنة نماذج البيانات لبيئتي Salesforce.

ما البيانات الوصفية لتنزيلها:

• قائمة الكائنات مع تسمياتها وأسماءها التقنية وسماتها مثل creatable أو updatable .
• قائمة الحقول مع سماتها (من الأفضل الحصول عليها جميعًا).
• قائمة بقيم قائمة الاختيار لحقول قائمة الاختيار. سنحتاج منهم لتعيين أو التحقق من صحة بيانات الإدخال للقيم الصحيحة.
• قائمة عمليات التحقق للتأكد من أن عمليات التحقق الجديدة لا تخلق مشاكل للبيانات التي تم ترحيلها.

كيفية تنزيل البيانات الوصفية من Salesforce؟ حسنًا ، لا توجد طريقة معيارية للبيانات الوصفية ، ولكن هناك خيارات متعددة:

• إنشاء WSDL للمؤسسة - في تطبيق الويب Salesforce ، انتقل إلى قائمة Setup / API وقم بتنزيل Enterprise WSDL المكتوب بشدة ، والذي يصف جميع الكائنات والحقول في Salesforce (ولكن ليس قيم قائمة الاختيار أو عمليات التحقق من الصحة).
• describeSObjects مكالمة Salesforce خدمة الويب الخاصة بـ الكائنات الحية ، مباشرةً أو باستخدام Java أو C # wrapper (استشر Salesforce API). بهذه الطريقة تحصل على ما تحتاجه ، وهذه هي الطريقة الموصى بها لتصدير البيانات الوصفية.
• استخدم أيًا من الأدوات البديلة العديدة المتاحة على الإنترنت.

الاستعداد لترحيل البيانات التالية

الحلول السحابية ، مثل Salesforce ، جاهزة على الفور. إذا كنت راضيًا عن الوظائف المضمنة ، فما عليك سوى تسجيل الدخول واستخدامها. ومع ذلك ، فإن Salesforce ، مثل أي حل CRM سحابي آخر ، يجلب مشاكل محددة لموضوعات ترحيل البيانات لتكون على دراية ، على وجه الخصوص ، فيما يتعلق بحدود الأداء والموارد.

دائمًا ما يكون نقل البيانات القديمة إلى النظام الجديد رحلة ، وأحيانًا رحلة إلى التاريخ مخبأة في بيانات من السنوات الماضية. في هذه المقالة ، استنادًا إلى عشرات من مشاريع الترحيل ، قدمت عشرة نصائح حول كيفية ترحيل البيانات القديمة وتجنب معظم المزالق بنجاح.

المفتاح هو فهم ما تكشفه البيانات. لذلك ، قبل أن تبدأ في ترحيل البيانات ، تأكد من أن فريق تطوير Salesforce لديك مستعد جيدًا للمشاكل المحتملة التي قد تواجهها بياناتك.