جیسا کہ آپ جانتے ہیں، SAP لین دین کے ڈیٹا کو برقرار رکھنے اور تجزیہ اور رپورٹنگ کے نظام میں اس ڈیٹا کو پروسیس کرنے کے لیے سافٹ ویئر کی مکمل رینج پیش کرتا ہے۔ خاص طور پر، SAP بزنس ویئر ہاؤس (SAP BW) پلیٹ فارم وسیع تکنیکی صلاحیتوں کے ساتھ ڈیٹا کو ذخیرہ کرنے اور تجزیہ کرنے کے لیے ایک ٹول کٹ ہے۔ اپنے تمام معروضی فوائد کے لیے، SAP BW سسٹم میں ایک اہم خرابی ہے۔ یہ ڈیٹا کو ذخیرہ کرنے اور پروسیسنگ کرنے کی بہت زیادہ لاگت ہے، خاص طور پر جب ہانا پر کلاؤڈ بیسڈ SAP BW استعمال کرتے ہوئے قابل توجہ ہے۔
اگر آپ کچھ نان SAP اور ترجیحی طور پر اوپن سورس پروڈکٹ کو بطور اسٹوریج استعمال کرنا شروع کر دیں تو کیا ہوگا؟ ہم نے X5 ریٹیل گروپ میں GreenPlum کا انتخاب کیا۔ یہ، بلاشبہ، لاگت کا مسئلہ حل کرتا ہے، لیکن اس کے ساتھ ہی، فوری طور پر ایسے مسائل پیدا ہو جاتے ہیں جو SAP BW استعمال کرتے وقت تقریباً ڈیفالٹ کے طور پر حل ہو جاتے تھے۔
خاص طور پر، سورس سسٹمز سے ڈیٹا کیسے حاصل کیا جائے، جو زیادہ تر SAP سلوشنز ہیں؟
HR Metrics پہلا پروجیکٹ تھا جس میں اس مسئلے کو حل کرنا ضروری تھا۔ ہمارا مقصد HR ڈیٹا کا ذخیرہ بنانا اور ملازمین کے ساتھ کام کرنے کے شعبے میں تجزیاتی رپورٹنگ بنانا تھا۔ اس معاملے میں، ڈیٹا کا بنیادی ذریعہ SAP HCM لین دین کا نظام ہے، جس میں تمام اہلکار، تنظیمی اور تنخواہ کی سرگرمیاں انجام دی جاتی ہیں۔
ڈیٹا نکالنا
SAP BW میں SAP سسٹمز کے لیے معیاری ڈیٹا نکالنے والے ہیں۔ یہ ایکسٹریکٹر خود بخود ضروری ڈیٹا اکٹھا کر سکتے ہیں، اس کی سالمیت کی نگرانی کر سکتے ہیں اور ڈیلٹا کی تبدیلی کا تعین کر سکتے ہیں۔ یہاں، مثال کے طور پر، ملازم کی خصوصیات 0EMPLOYEE_ATTR کے لیے ڈیٹا کا معیاری ذریعہ ہے:
ایک ملازم کے لیے اس سے ڈیٹا نکالنے کا نتیجہ:
اگر ضروری ہو تو، اس طرح کے ایکسٹریکٹر کو آپ کی اپنی ضروریات کے مطابق تبدیل کیا جا سکتا ہے یا آپ کا اپنا ایکسٹریکٹر بنایا جا سکتا ہے۔
پیدا ہونے والا پہلا خیال ان کو دوبارہ استعمال کرنے کا امکان تھا۔ بدقسمتی سے یہ ایک ناممکن کام نکلا۔ زیادہ تر منطق SAP BW سائیڈ پر لاگو ہوتی ہے، اور SAP BW سے ماخذ پر ایکسٹریکٹر کو بغیر تکلیف کے الگ کرنا ممکن نہیں تھا۔
یہ واضح ہو گیا کہ ہمیں SAP سسٹمز سے ڈیٹا نکالنے کے لیے اپنا طریقہ کار تیار کرنے کی ضرورت ہوگی۔
SAP HCM میں ڈیٹا اسٹوریج کا ڈھانچہ
اس طرح کے میکانزم کے تقاضوں کو سمجھنے کے لیے، ہمیں پہلے یہ طے کرنا ہوگا کہ ہمیں کس ڈیٹا کی ضرورت ہے۔
SAP HCM میں زیادہ تر ڈیٹا فلیٹ SQL ٹیبلز میں محفوظ ہوتا ہے۔ اس اعداد و شمار کی بنیاد پر، SAP ایپلیکیشنز تنظیمی ڈھانچے، ملازمین اور دیگر HR معلومات کو صارف تک پہنچاتی ہیں۔ مثال کے طور پر، SAP HCM میں تنظیمی ڈھانچہ ایسا لگتا ہے:
جسمانی طور پر، ایسے درخت کو دو جدولوں میں محفوظ کیا جاتا ہے - hrp1000 اشیاء میں اور hrp1001 میں ان اشیاء کے درمیان کنکشن۔
آبجیکٹ "محکمہ 1" اور "آفس 1":
اشیاء کے درمیان تعلق:
دونوں قسم کی اشیاء اور ان کے درمیان کنکشن کی اقسام کی ایک بڑی تعداد ہو سکتی ہے۔ آپ کی اپنی مخصوص ضروریات کے لیے اشیاء اور اپنی مرضی کے مطابق دونوں کے درمیان معیاری کنکشن موجود ہیں۔ مثال کے طور پر، ایک تنظیمی اکائی اور کل وقتی پوزیشن کے درمیان معیاری B012 تعلق ایک شعبہ کے سربراہ کی نشاندہی کرتا ہے۔
SAP میں مینیجر ڈسپلے:
ڈیٹا بیس ٹیبل میں ذخیرہ:
ملازمین کا ڈیٹا pa* ٹیبلز میں محفوظ ہے۔ مثال کے طور پر، ایک ملازم کے لیے پرسنل ایونٹس کا ڈیٹا ٹیبل pa0000 میں محفوظ کیا جاتا ہے۔
ہم نے فیصلہ کیا کہ GreenPlum "خام" ڈیٹا لے گا، یعنی انہیں صرف SAP ٹیبلز سے کاپی کریں۔ اور براہ راست GreenPlum میں ان پر کارروائی کی جائے گی اور انہیں جسمانی اشیاء (مثال کے طور پر، محکمہ یا ملازم) اور میٹرکس (مثال کے طور پر، اوسط ہیڈ کاؤنٹ) میں تبدیل کیا جائے گا۔
تقریباً 70 ٹیبلز کی وضاحت کی گئی تھی، جن سے ڈیٹا کو گرین پلم میں منتقل کیا جانا چاہیے۔ جس کے بعد ہم نے اس ڈیٹا کی ترسیل کے لیے ایک طریقہ وضع کرنا شروع کیا۔
SAP انضمام کے طریقہ کار کی کافی بڑی تعداد پیش کرتا ہے۔ لیکن سب سے آسان طریقہ یہ ہے کہ لائسنسنگ کی پابندیوں کی وجہ سے ڈیٹا بیس تک براہ راست رسائی ممنوع ہے۔ اس طرح، تمام انضمام کے بہاؤ کو ایپلیکیشن سرور کی سطح پر لاگو کیا جانا چاہیے۔
اگلا مسئلہ SAP ڈیٹا بیس میں حذف شدہ ریکارڈز کے بارے میں ڈیٹا کی کمی تھی۔ جب آپ ڈیٹا بیس میں ایک قطار کو حذف کرتے ہیں، تو یہ جسمانی طور پر حذف ہو جاتی ہے۔ وہ. تبدیلی کے وقت کی بنیاد پر تبدیلی کے ڈیلٹا کی تشکیل ممکن نہیں تھی۔
بلاشبہ، SAP HCM کے پاس ڈیٹا کی تبدیلیوں کو ریکارڈ کرنے کا طریقہ کار ہے۔ مثال کے طور پر، بعد میں وصول کنندہ کے نظاموں میں منتقلی کے لیے، تبدیلی کے اشارے ہیں جو کسی بھی تبدیلی کو ریکارڈ کرتے ہیں اور جس کی بنیاد پر ایک Idoc تشکیل دیا جاتا ہے (بیرونی نظاموں میں منتقلی کے لیے ایک شے)۔
پرسنل نمبر 0302 والے ملازم کے لیے انفو ٹائپ 1251445 کو تبدیل کرنے کے لیے IDoc کی مثال:
یا DBTABLOG ٹیبل میں ڈیٹا کی تبدیلیوں کے لاگز کو رکھنا۔
hrp53216375 ٹیبل سے کلید QK1000 کے ساتھ ریکارڈ کو حذف کرنے کے لیے لاگ کی ایک مثال:
لیکن یہ میکانزم تمام ضروری ڈیٹا کے لیے دستیاب نہیں ہیں، اور ایپلیکیشن سرور کی سطح پر ان کی پروسیسنگ کافی وسائل استعمال کر سکتی ہے۔ لہذا، تمام ضروری ٹیبلز پر بڑے پیمانے پر لاگنگ کو فعال کرنے سے سسٹم کی کارکردگی میں نمایاں کمی واقع ہو سکتی ہے۔
اگلا بڑا مسئلہ کلسٹرڈ ٹیبلز کا تھا۔ SAP HCM کے RDBMS ورژن میں وقت کا تخمینہ اور تنخواہ کا ڈیٹا ہر حساب کے لیے ہر ملازم کے لیے منطقی جدولوں کے سیٹ کے طور پر محفوظ کیا جاتا ہے۔ یہ منطقی میزیں ٹیبل pcl2 میں بائنری ڈیٹا کے طور پر محفوظ ہیں۔
پے رول کلسٹر:
کلسٹرڈ ٹیبلز کے ڈیٹا کو SQL کمانڈ کے طور پر نہیں سمجھا جا سکتا، لیکن SAP HCM میکروز یا خصوصی فنکشنل ماڈیولز کے استعمال کی ضرورت ہوتی ہے۔ اس کے مطابق، اس طرح کی میزوں کی پڑھنے کی رفتار کافی کم ہو گی. دوسری طرف، اس طرح کے کلسٹرز ڈیٹا کو ذخیرہ کرتے ہیں جس کی مہینے میں صرف ایک بار ضرورت ہوتی ہے - حتمی تنخواہ اور وقت کا تخمینہ۔ لہذا اس معاملے میں رفتار اتنی اہم نہیں ہے۔
ڈیٹا کی تبدیلیوں کا ڈیلٹا بنانے کے اختیارات کا جائزہ لیتے ہوئے، ہم نے مکمل اتارنے کے آپشن پر بھی غور کرنے کا فیصلہ کیا۔ سسٹمز کے درمیان ہر روز گیگا بائٹس کے غیر تبدیل شدہ ڈیٹا کی منتقلی کا آپشن شاید اچھا نہ لگے۔ تاہم، اس کے کئی فائدے بھی ہیں - سورس سائیڈ پر ڈیلٹا کو لاگو کرنے اور ریسیور سائیڈ پر اس ڈیلٹا کی ایمبیڈنگ دونوں کو لاگو کرنے کی ضرورت نہیں ہے۔ اس کے مطابق، لاگت اور عمل درآمد کا وقت کم ہو جاتا ہے، اور انضمام کی وشوسنییتا بڑھ جاتی ہے۔ ایک ہی وقت میں، یہ طے پایا کہ SAP HR میں تقریباً تمام تبدیلیاں موجودہ تاریخ سے تین ماہ پہلے کے افق کے اندر ہوتی ہیں۔ اس طرح، موجودہ تاریخ سے پہلے SAP HR N سے ڈیٹا کے روزانہ مکمل ڈاؤن لوڈ اور ماہانہ مکمل ڈاؤن لوڈ کا انتخاب کرنے کا فیصلہ کیا گیا۔ N پیرامیٹر مخصوص جدول پر منحصر ہے۔
اور رینج 1 سے 15 تک ہے۔
ڈیٹا نکالنے کے لیے درج ذیل اسکیم تجویز کی گئی تھی۔
بیرونی نظام ایک درخواست تیار کرتا ہے اور اسے SAP HCM کو بھیجتا ہے، جہاں اس درخواست کو ڈیٹا کی مکمل ہونے اور میزوں تک رسائی کی اجازت کے لیے چیک کیا جاتا ہے۔ اگر چیک کامیاب ہو جاتا ہے تو، SAP HCM ایک پروگرام چلاتا ہے جو ضروری ڈیٹا اکٹھا کرتا ہے اور اسے فیوز انٹیگریشن سلوشن میں منتقل کرتا ہے۔ فیوز کافکا میں مطلوبہ موضوع کا تعین کرتا ہے اور ڈیٹا کو وہاں منتقل کرتا ہے۔ اس کے بعد، کافکا سے ڈیٹا سٹیج ایریا جی پی کو منتقل کیا جاتا ہے۔
اس سلسلہ میں، ہم SAP HCM سے ڈیٹا نکالنے کے معاملے میں دلچسپی رکھتے ہیں۔ آئیے اسے مزید تفصیل سے دیکھتے ہیں۔
SAP HCM-FUSE تعامل کا خاکہ۔
بیرونی نظام SAP کو آخری کامیاب درخواست کے وقت کا تعین کرتا ہے۔
اس عمل کو ٹائمر یا دوسرے ایونٹ کے ذریعے شروع کیا جا سکتا ہے، بشمول SAP کے ڈیٹا کے ساتھ جواب کا انتظار کرنے کے لیے ٹائم آؤٹ سیٹ کرنا اور دوبارہ درخواست شروع کرنا۔ پھر یہ ڈیلٹا کی درخواست تیار کرتا ہے اور اسے SAP کو بھیجتا ہے۔
درخواست کا ڈیٹا json فارمیٹ میں باڈی کو بھیجا جاتا ہے۔
طریقہ http: POST.
مثال کی درخواست:
SAP سروس مکمل ہونے کی درخواست، موجودہ SAP ڈھانچے کی تعمیل، اور درخواست کردہ ٹیبل تک رسائی کی اجازت کی دستیابی کی نگرانی کرتی ہے۔
غلطیوں کی صورت میں، سروس مناسب کوڈ اور تفصیل کے ساتھ جواب واپس کرتی ہے۔ اگر کنٹرول کامیاب ہو جاتا ہے، تو یہ ایک نمونہ بنانے کے لیے ایک پس منظر کا عمل بناتا ہے، ایک منفرد سیشن آئی ڈی تیار کرتا ہے اور ہم وقت کے ساتھ واپس کرتا ہے۔
خرابی کی صورت میں، بیرونی نظام اسے لاگ میں ریکارڈ کرتا ہے۔ کامیاب جواب کی صورت میں، یہ سیشن آئی ڈی اور اس ٹیبل کا نام بھیجتا ہے جس کے لیے درخواست کی گئی تھی۔
بیرونی نظام موجودہ سیشن کو کھلے کے طور پر رجسٹر کرتا ہے۔ اگر اس ٹیبل کے لیے دیگر سیشنز ہیں، تو وہ انتباہ لاگ ان کے ساتھ بند کر دیے جاتے ہیں۔
SAP پس منظر کا کام مخصوص پیرامیٹرز اور مخصوص سائز کے ڈیٹا پیکٹ کی بنیاد پر ایک کرسر تیار کرتا ہے۔ بیچ کا سائز ریکارڈز کی زیادہ سے زیادہ تعداد ہے جسے کوئی عمل ڈیٹا بیس سے پڑھتا ہے۔ پہلے سے طے شدہ طور پر، یہ 2000 کے برابر سمجھا جاتا ہے۔ اگر ڈیٹا بیس کے نمونے میں استعمال شدہ پیکٹ کے سائز سے زیادہ ریکارڈ موجود ہیں، تو پہلے پیکٹ کو منتقل کرنے کے بعد، اگلا بلاک متعلقہ آفسیٹ اور بڑھے ہوئے پیکٹ نمبر کے ساتھ بنتا ہے۔ نمبروں کو 1 سے بڑھایا جاتا ہے اور سختی سے ترتیب وار بھیجا جاتا ہے۔
اس کے بعد، SAP پیکٹ کو بیرونی نظام کی ویب سروس میں بطور ان پٹ پاس کرتا ہے۔ اور نظام آنے والے پیکٹ پر کنٹرول کرتا ہے۔ موصولہ آئی ڈی کے ساتھ ایک سیشن سسٹم میں رجسٹرڈ ہونا چاہیے اور اسے کھلی حالت میں ہونا چاہیے۔ اگر پیکیج نمبر > 1 ہے، تو سسٹم کو پچھلے پیکیج (package_id-1) کی کامیاب رسید ریکارڈ کرنی چاہیے۔
اگر کنٹرول کامیاب ہو جاتا ہے تو، بیرونی نظام ٹیبل ڈیٹا کو پارس اور محفوظ کرتا ہے۔
مزید برآں، اگر پیکج میں حتمی جھنڈا موجود ہے اور سیریلائزیشن کامیاب رہی، تو انضمام ماڈیول کو سیشن پروسیسنگ کی کامیاب تکمیل کے بارے میں مطلع کیا جاتا ہے اور ماڈیول سیشن کی حیثیت کو اپ ڈیٹ کرتا ہے۔
کنٹرول/پارسنگ کی خرابی کی صورت میں، ایرر لاگ ان ہو جاتا ہے اور اس سیشن کے پیکٹ بیرونی سسٹم کے ذریعے مسترد کر دیے جائیں گے۔
اسی طرح، مخالف صورت میں، جب بیرونی نظام ایک خرابی واپس کرتا ہے، تو یہ لاگ ان ہوتا ہے اور پیکٹ کی ترسیل رک جاتی ہے۔
SAP HCM سائیڈ پر ڈیٹا کی درخواست کرنے کے لیے، انٹیگریشن سروس لاگو کی گئی تھی۔ سروس کو ICF فریم ورک (SAP انٹرنیٹ کمیونیکیشن فریم ورک -) پر لاگو کیا گیا ہے۔ )۔ یہ آپ کو مخصوص جدولوں کا استعمال کرتے ہوئے SAP HCM سسٹم سے ڈیٹا استفسار کرنے کی اجازت دیتا ہے۔ ڈیٹا کی درخواست بناتے وقت، ضروری ڈیٹا حاصل کرنے کے لیے مخصوص فیلڈز اور فلٹرنگ پیرامیٹرز کی فہرست بتانا ممکن ہے۔ ایک ہی وقت میں، سروس کا نفاذ کسی کاروباری منطق کا مطلب نہیں ہے۔ ڈیلٹا، استفسار کے پیرامیٹرز، سالمیت کی نگرانی، وغیرہ کا حساب لگانے کے الگورتھم بھی بیرونی نظام کے اطراف میں لاگو ہوتے ہیں۔
یہ طریقہ کار آپ کو چند گھنٹوں میں تمام ضروری ڈیٹا اکٹھا اور منتقل کرنے کی اجازت دیتا ہے۔ یہ رفتار قابل قبول ہونے کے دہانے پر ہے، اس لیے ہم اس حل کو ایک عارضی حل سمجھتے ہیں، جس کی وجہ سے پروجیکٹ پر نکالنے کے آلے کی ضرورت کو پورا کرنا ممکن ہوا۔
ٹارگٹ پکچر میں، ڈیٹا نکالنے کے مسئلے کو حل کرنے کے لیے، سی ڈی سی سسٹم جیسے اوریکل گولڈن گیٹ یا ای ٹی ایل ٹولز جیسے ایس اے پی ڈی ایس استعمال کرنے کے اختیارات تلاش کیے جا رہے ہیں۔
ماخذ: www.habr.com