ولكن ماذا لو بدأت في استخدام بعض المنتجات بخلاف SAP ويفضل أن تكون مفتوحة المصدر كمخزن؟ اخترنا في X5 Retail Group GreenPlum. هذا ، بالطبع ، يحل مشكلة التكلفة ، ولكن في الوقت نفسه ، تظهر أسئلة على الفور أنه عند استخدام SAP BW ، تم حلها افتراضيًا تقريبًا.
على وجه الخصوص ، كيفية استرداد البيانات من أنظمة المصدر ، والتي هي في الغالب حلول SAP؟
كانت مقاييس الموارد البشرية أول مشروع يعالج هذه المشكلة. كان هدفنا هو إنشاء مستودع لبيانات الموارد البشرية وبناء تقارير تحليلية في مجال العمل مع الموظفين. في هذه الحالة ، يكون المصدر الرئيسي للبيانات هو نظام معاملات SAP HCM ، حيث يتم إجراء جميع الموظفين والأنشطة التنظيمية والرواتب.
استخراج البيانات
توجد أدوات استخراج بيانات قياسية في SAP BW لأنظمة SAP. يمكن لهذه المستخرجات جمع البيانات الضرورية تلقائيًا وتتبع سلامتها وتحديد دلتا التغييرات. على سبيل المثال ، يوجد هنا مصدر بيانات قياسي لسمات الموظف 0EMPLOYEE_ATTR:
نتيجة استخراج البيانات منه موظف واحد في كل مرة:
إذا لزم الأمر ، يمكن تعديل هذا المستخرج ليناسب متطلباتك الخاصة ، أو يمكن إنشاء مستخرج خاص بك.
نشأت الفكرة الأولى حول إمكانية إعادة استخدامها. لسوء الحظ ، ثبت أن هذه مهمة مستحيلة. يتم تنفيذ معظم المنطق على جانب SAP BW ، ولم يكن من الممكن فصل المستخرج دون ألم من المصدر عن SAP BW.
أصبح من الواضح أنه سيكون من الضروري تطوير آلية مخصصة لاستخراج البيانات من أنظمة SAP.
هيكل تخزين البيانات في SAP HCM
لفهم متطلبات مثل هذه الآلية ، عليك أولاً تحديد نوع البيانات التي نحتاجها.
يتم تخزين معظم البيانات في SAP HCM في جداول SQL مسطحة. بناءً على هذه البيانات ، تصور تطبيقات SAP الهياكل التنظيمية والموظفين ومعلومات الموارد البشرية الأخرى للمستخدم. على سبيل المثال ، هكذا تبدو البنية التنظيمية في SAP HCM:
فعليًا ، يتم تخزين هذه الشجرة في جدولين - في كائنات hrp1000 وفي hrp1001 الروابط بين هذه الكائنات. الكائنين
"القسم 1" و "المكتب 1":
الاتصال بين الكائنات:
يمكن أن يكون هناك عدد كبير من كلا النوعين من الأشياء وأنواع الاتصال بينهما. هناك روابط قياسية بين الكائنات ، ومخصصة لاحتياجاتك الخاصة. على سبيل المثال ، تشير العلاقة القياسية B012 بين وحدة تنظيمية ووظيفة بدوام كامل إلى رئيس القسم.
تعيين المدير في SAP:
التخزين في جدول
قاعدة البيانات: يتم تخزين بيانات الموظف في جداول pa *. على سبيل المثال ، يتم تخزين البيانات المتعلقة بأنشطة التوظيف لموظف في جدول pa0000.
لقد قررنا أن GreenPlum سيأخذ بيانات "أولية" ، أي فقط قم بنسخها من جداول SAP. وبالفعل مباشرة في GreenPlum ، ستتم معالجتها وتحويلها إلى كائنات مادية (على سبيل المثال ، قسم أو موظف) ومقاييس (على سبيل المثال ، متوسط عدد الموظفين).
تم تحديد حوالي 70 جدولًا ، يجب نقل البيانات منها إلى GreenPlum. بعد ذلك ، بدأنا في إيجاد طريقة لنقل هذه البيانات.
تقدم SAP عددًا كبيرًا من آليات التكامل. ولكن أسهل طريقة - الوصول المباشر إلى قاعدة البيانات محظور بسبب قيود الترخيص. وبالتالي ، يجب تنفيذ جميع تدفقات التكامل على مستوى خادم التطبيق.
كانت المشكلة التالية هي نقص البيانات حول السجلات المحذوفة في قاعدة بيانات SAP. عند حذف صف من قاعدة البيانات ، يتم حذفه فعليًا. أولئك. لم يكن من الممكن تشكيل دلتا من التغييرات على مدار وقت التغيير.
بالطبع ، لدى SAP HCM آليات لإجراء تغييرات في البيانات. على سبيل المثال ، للإرسال اللاحق إلى الأنظمة ، يكون لدى المستلمين مؤشرات تغيير تسجل أي تغييرات وعلى أساسها يتم تكوين Idoc (كائن للإرسال إلى أنظمة خارجية).
مثال على IDoc لتغيير نوع المعلومات 0302 للموظف مع رقم الموظف 1251445:
أو الاحتفاظ بسجلات تغيير البيانات في الجدول DBTABLOG.
مثال لسجل لحذف إدخال بمفتاح QK53216375 من جدول hrp1000:
لكن هذه الآليات غير متاحة لجميع البيانات الضرورية ومعالجتها على مستوى خادم التطبيق يمكن أن تستهلك الكثير من الموارد. لذلك ، يمكن أن يؤدي التضمين الهائل لتسجيل الدخول على جميع الجداول الضرورية إلى تدهور ملحوظ في أداء النظام.
كانت الجداول العنقودية هي المشكلة الرئيسية التالية. يتم تخزين تقدير الوقت وبيانات كشوف المرتبات في إصدار RDBMS من SAP HCM كمجموعة من الجداول المنطقية لكل موظف لكل قائمة رواتب. يتم تخزين هذه الجداول المنطقية كبيانات ثنائية في جدول pcl2.
مجموعة كشوف المرتبات:
لا يمكن قراءة البيانات من الجداول المجمعة بواسطة أمر SQL وتتطلب استخدام وحدات ماكرو SAP HCM أو وحدات دالة خاصة. وفقًا لذلك ، ستكون سرعة قراءة هذه الجداول منخفضة جدًا. من ناحية أخرى ، تقوم هذه المجموعات بتخزين البيانات المطلوبة مرة واحدة فقط في الشهر - كشوف المرتبات النهائية وتقدير الوقت. لذا فإن السرعة في هذه الحالة ليست حرجة للغاية.
بتقييم الخيارات مع تشكيل دلتا لتغيير البيانات ، قررنا أيضًا التفكير في الخيار مع التفريغ الكامل. لا يمكن أن يبدو خيار نقل غيغابايت من البيانات غير المتغيرة بين الأنظمة كل يوم جميلاً. ومع ذلك ، فإن لها أيضًا عددًا من المزايا - ليست هناك حاجة لتنفيذ دلتا على جانب المصدر ، أو لتنفيذ تضمين هذه الدلتا على جانب المستقبِل. وفقًا لذلك ، يتم تقليل التكلفة ووقت التنفيذ ، وزيادة موثوقية التكامل. في الوقت نفسه ، تم تحديد أن جميع التغييرات تقريبًا في SAP HR تحدث في أفق ثلاثة أشهر قبل التاريخ الحالي. وبالتالي ، فقد تقرر التوقف عند التنزيل اليومي الكامل للبيانات من SAP HR قبل أشهر من التاريخ الحالي وتنزيل كامل شهريًا. تعتمد المعلمة N على الجدول المحدد
وتتراوح من 1 إلى 15.
لاستخراج البيانات ، تم اقتراح المخطط التالي:
ينشئ النظام الخارجي طلبًا ويرسله إلى SAP HCM ، حيث يتم التحقق من هذا الطلب للتأكد من اكتمال البيانات والتفويض للوصول إلى جداول. إذا نجح الفحص ، فإن SAP HCM يدير برنامجًا يجمع البيانات الضرورية وينقلها إلى حل تكامل Fuse. يحدد فيوز الموضوع المطلوب في كافكا ويمرر البيانات هناك. بعد ذلك ، يتم نقل البيانات من كافكا إلى منطقة المرحلة GP.
نحن في هذه السلسلة مهتمون بمسألة استخراج البيانات من SAP HCM. دعونا نتناولها بمزيد من التفصيل.
مخطط تفاعل SAP HCM-FUSE.
يحدد النظام الخارجي وقت آخر طلب ناجح لـ SAP.
يمكن أن تبدأ العملية بواسطة مؤقت أو حدث آخر ، بما في ذلك مهلة انتظار استجابة ببيانات من SAP وبدء طلب متكرر. ثم يقوم بإنشاء طلب دلتا وإرساله إلى SAP.
يتم تمرير بيانات الطلب بشكل أساسي بتنسيق json.
http: طريقة POST.
نموذج طلب:
تتحقق خدمة SAP من الطلب للتأكد من اكتماله والامتثال لهيكل SAP الحالي ومدى توفر الإذن للوصول إلى الجدول المطلوب.
في حالة وجود أخطاء ، تقوم الخدمة بإرجاع استجابة بالرمز والوصف المناسبين. إذا كان عنصر التحكم ناجحًا ، فإنه ينشئ عملية في الخلفية لإنشاء تحديد ، ويقوم بإنشاء معرّف جلسة فريد وإرجاعه بشكل متزامن.
سيقوم النظام الخارجي بتسجيله في حالة حدوث خطأ. في حالة الاستجابة الناجحة ، فإنه يرسل معرف الجلسة واسم الجدول الذي تم تقديم الطلب من أجله.
يقوم النظام الخارجي بتسجيل الجلسة الحالية على أنها مفتوحة. إذا كانت هناك جلسات أخرى لهذا الجدول ، فسيتم إغلاقها مع تسجيل تحذير.
تنشئ وظيفة SAP الخلفية مؤشرًا وفقًا للمعلمات المحددة وحزمة بيانات بالحجم المحدد. حجم الحزمة - الحد الأقصى لعدد السجلات التي تقرأها العملية من قاعدة البيانات. بشكل افتراضي ، يُفترض أن تكون 2000. إذا احتوت عينة قاعدة البيانات على سجلات أكثر من حجم الحزمة المستخدمة ، بعد إرسال الحزمة الأولى ، يتم تشكيل الكتلة التالية مع الإزاحة المقابلة ورقم الحزمة المتزايد. يتم زيادة الأرقام بمقدار 1 وإرسالها بشكل تسلسلي صارم.
بعد ذلك ، يمرر SAP الحزمة كمدخل إلى خدمة ويب النظام الخارجية. وهو النظام الذي يتحكم في الحزمة الواردة. يجب تسجيل جلسة بالمعرف المستلم في النظام ويجب أن تكون في حالة مفتوحة. إذا كان رقم الحزمة> 1 ، يجب على النظام تسجيل الاستلام الناجح للحزمة السابقة (package_id-1).
في حالة التحكم الناجح ، يوزع النظام الخارجي بيانات الجدول ويحفظها.
بالإضافة إلى ذلك ، إذا كانت العلامة النهائية موجودة في الحزمة ونجحت عملية التسلسل ، يتم إخطار وحدة التكامل بشأن الإكمال الناجح لمعالجة الجلسة وتقوم الوحدة بتحديث حالة الجلسة.
في حالة حدوث خطأ في التحكم / التحليل ، يتم تسجيل الخطأ وسيرفض النظام الخارجي الحزم الخاصة بهذه الجلسة.
وبالمثل ، في الحالة المعاكسة ، عندما يُرجع النظام الخارجي خطأً ، يتم تسجيله ويتم إيقاف إرسال الحزم.
تم تنفيذ خدمة تكامل لطلب البيانات على جانب SAP HM. يتم تنفيذ الخدمة في إطار عمل ICF (SAP Internet Communication Framework - help.sap.com/viewer/6da7259a6c4b1014b7d5e759cc76fd22/7.01.22/en-US/488d6e0ea6ed72d5e10000000a42189c.html ). يتيح لك الاستعلام عن البيانات من نظام SAP HCM في جداول محددة. عند تكوين طلب بيانات ، من الممكن تحديد قائمة الحقول المحددة ومعلمات التصفية من أجل الحصول على البيانات اللازمة. في الوقت نفسه ، لا يعني تنفيذ الخدمة أي منطق أعمال. يتم أيضًا تنفيذ خوارزميات لحساب دلتا ، ومعلمات الطلب ، ومراقبة السلامة ، وما إلى ذلك على جانب النظام الخارجي.
تسمح لك هذه الآلية بجمع ونقل جميع البيانات اللازمة في غضون ساعات قليلة. هذه السرعة على وشك أن تكون مقبولة ، لذلك نعتبر هذا الحل مؤقتًا ، مما جعل من الممكن تغطية الحاجة إلى أداة استخراج في المشروع.
في الصورة المستهدفة لحل مشكلة استخراج البيانات ، يتم العمل على خيارات استخدام أنظمة CDC مثل Oracle Golden Gate أو أدوات ETL مثل SAP DS.