همانطور که می دانید، SAP طیف کاملی از نرم افزارها را هم برای نگهداری داده های تراکنش و هم برای پردازش این داده ها در سیستم های تحلیل و گزارش ارائه می دهد. به طور خاص، پلت فرم SAP Business Warehouse (SAP BW) ابزاری برای ذخیره و تجزیه و تحلیل داده ها با قابلیت های فنی گسترده است. با وجود تمام مزایای عینی آن، سیستم SAP BW یک اشکال قابل توجه دارد. این هزینه بالایی برای ذخیره و پردازش داده ها است، به ویژه در هنگام استفاده از SAP BW مبتنی بر ابر در Hana قابل توجه است.
اگر شروع به استفاده از برخی غیر SAP و ترجیحاً یک محصول OpenSource به عنوان ذخیره کنید، چه؟ ما در گروه خرده فروشی X5 GreenPlum را انتخاب کردیم. این، البته، مسئله هزینه را حل می کند، اما در عین حال، بلافاصله مسائلی پیش می آید که تقریباً به طور پیش فرض در هنگام استفاده از SAP BW حل شده است.
به طور خاص، چگونه می توان داده ها را از سیستم های منبع، که بیشتر راه حل های SAP هستند، بازیابی کرد؟
HR Metrics اولین پروژه ای بود که در آن برای حل این مشکل ضروری بود. هدف ما ایجاد یک مخزن از داده های منابع انسانی و ایجاد گزارش های تحلیلی در زمینه کار با کارکنان بود. در این مورد، منبع اصلی داده ها، سیستم معاملاتی 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 ماه قبل از تاریخ فعلی و دانلود کامل ماهانه انتخاب شود. پارامتر N به جدول خاص بستگی دارد
و از 1 تا 15 متغیر است.
طرح زیر برای استخراج داده ها پیشنهاد شد:
سیستم خارجی یک درخواست تولید می کند و آن را به SAP HCM می فرستد، جایی که این درخواست برای کامل بودن داده ها و مجوزهای دسترسی به جداول بررسی می شود. در صورت موفقیت آمیز بودن بررسی، SAP HCM برنامه ای را اجرا می کند که داده های لازم را جمع آوری کرده و به راه حل ادغام Fuse منتقل می کند. فیوز موضوع مورد نیاز را در کافکا تعیین می کند و داده ها را به آنجا منتقل می کند. سپس داده های کافکا به Stage Area GP منتقل می شود.
در این زنجیره، ما به موضوع استخراج داده ها از SAP HCM علاقه مند هستیم. بیایید با جزئیات بیشتری به آن نگاه کنیم.
نمودار تعامل SAP HCM-FUSE.
سیستم خارجی زمان آخرین درخواست موفقیت آمیز به SAP را تعیین می کند.
این فرآیند می‌تواند توسط یک تایمر یا رویداد دیگر راه‌اندازی شود، از جمله تعیین زمان برای انتظار برای پاسخ با داده‌های SAP و شروع درخواست تکرار. سپس یک درخواست دلتا ایجاد می کند و آن را به SAP می فرستد.
داده های درخواست با فرمت json به بدنه ارسال می شود.
روش http: POST.
درخواست نمونه:
سرویس SAP درخواست برای کامل بودن، انطباق با ساختار فعلی SAP و در دسترس بودن مجوز دسترسی به جدول درخواستی را نظارت می کند.
در صورت بروز خطا، سرویس پاسخی با کد و توضیحات مناسب برمی گرداند. اگر کنترل موفقیت آمیز باشد، یک فرآیند پس‌زمینه برای تولید نمونه ایجاد می‌کند، یک شناسه جلسه منحصربه‌فرد را تولید می‌کند و به طور همزمان بازمی‌گرداند.
در صورت بروز خطا، سیستم خارجی آن را در گزارش ثبت می کند. در صورت پاسخ موفقیت آمیز، شناسه جلسه و نام جدولی که درخواست برای آن ارسال شده است را ارسال می کند.
سیستم خارجی جلسه جاری را به عنوان باز ثبت می کند. اگر جلسات دیگری برای این جدول وجود داشته باشد، آنها با یک هشدار ثبت شده بسته می شوند.
کار پس زمینه SAP یک مکان نما بر اساس پارامترهای مشخص شده و یک بسته داده با اندازه مشخص ایجاد می کند. اندازه دسته ای حداکثر تعداد رکوردهایی است که یک فرآیند از پایگاه داده می خواند. به طور پیش فرض برابر با 2000 در نظر گرفته شده است. اگر رکوردهای در نمونه پایگاه داده بیشتر از اندازه بسته مورد استفاده باشد، پس از ارسال بسته اول، بلوک بعدی با آفست مربوطه و تعداد بسته افزایش یافته تشکیل می شود. اعداد 1 افزایش یافته و به صورت متوالی ارسال می شوند.
سپس SAP بسته را به عنوان ورودی به وب سرویس سیستم خارجی ارسال می کند. و سیستم کنترل هایی را بر روی بسته ورودی انجام می دهد. جلسه ای با شناسه دریافتی باید در سیستم ثبت شود و در وضعیت باز باشد. اگر شماره بسته > 1 باشد، سیستم باید دریافت موفق بسته قبلی (package_id-1) را ثبت کند.
اگر کنترل موفقیت آمیز باشد، سیستم خارجی داده های جدول را تجزیه و ذخیره می کند.
علاوه بر این، اگر پرچم نهایی در بسته وجود داشته باشد و سریال سازی موفقیت آمیز باشد، ماژول یکپارچه سازی از تکمیل موفقیت آمیز پردازش جلسه مطلع می شود و ماژول وضعیت جلسه را به روز می کند.
در صورت بروز خطای کنترل/تجزیه، خطا ثبت می‌شود و بسته‌های مربوط به این جلسه توسط سیستم خارجی رد می‌شوند.
به همین ترتیب، در حالت مخالف، هنگامی که سیستم خارجی یک خطا را برمی گرداند، ثبت می شود و انتقال بسته متوقف می شود.
برای درخواست داده در سمت SAP HСM، یک سرویس یکپارچه سازی اجرا شد. این سرویس بر روی چارچوب ICF پیاده سازی شده است (SAP Internet Communication Framework - ). این به شما امکان می دهد با استفاده از جداول خاص، داده ها را از سیستم SAP HCM پرس و جو کنید. هنگام ایجاد یک درخواست داده، می توان لیستی از فیلدهای خاص و پارامترهای فیلتر را برای به دست آوردن داده های لازم مشخص کرد. در عین حال، اجرای سرویس به هیچ منطق تجاری دلالت نمی کند. الگوریتم های محاسبه دلتا، پارامترهای پرس و جو، نظارت بر یکپارچگی و غیره نیز در کنار سیستم خارجی پیاده سازی شده اند.
این مکانیسم به شما اجازه می دهد تا در چند ساعت تمام داده های لازم را جمع آوری و انتقال دهید. این سرعت در مرز قابل قبول است، بنابراین ما این راه حل را موقتی می دانیم که باعث می شود نیاز به ابزار استخراج در پروژه برطرف شود.
در تصویر هدف، برای حل مشکل استخراج داده ها، گزینه هایی برای استفاده از سیستم های CDC مانند Oracle Golden Gate یا ابزارهای ETL مانند SAP DS در حال بررسی هستند.
منبع: www.habr.com