SAP HCM बाट गैर SAP डाटा गोदामहरूमा डाटा निकाल्दै

तपाईलाई थाहा छ, SAP ले लेनदेन डेटा कायम राख्न र विश्लेषण र रिपोर्टिङ प्रणालीहरूमा यो डेटा प्रशोधन गर्न दुवै सफ्टवेयरको पूर्ण दायरा प्रदान गर्दछ। विशेष गरी, SAP Business Warehouse (SAP BW) प्लेटफर्म व्यापक प्राविधिक क्षमताहरूको साथ डाटा भण्डारण र विश्लेषण गर्नको लागि एक टुलकिट हो। यसको सबै वस्तुगत फाइदाहरूको लागि, SAP BW प्रणालीमा एउटा महत्त्वपूर्ण कमी छ। यो डेटा भण्डारण र प्रशोधन गर्ने उच्च लागत हो, विशेष गरी हानामा क्लाउड-आधारित SAP BW प्रयोग गर्दा ध्यान दिईन्छ।

यदि तपाइँ केहि गैर-SAP र अधिमानतः एक OpenSource उत्पादन भण्डारणको रूपमा प्रयोग गर्न सुरु गर्नुहुन्छ भने के हुन्छ? हामीले X5 रिटेल समूहमा ग्रीनप्लम रोज्यौं। यो, निस्सन्देह, लागत को समस्या समाधान गर्दछ, तर एकै समयमा, समस्याहरू तुरुन्तै उत्पन्न हुन्छन् जुन SAP BW प्रयोग गर्दा लगभग पूर्वनिर्धारित रूपमा समाधान गरिएको थियो।

विशेष गरी, स्रोत प्रणालीहरूबाट डाटा कसरी पुन: प्राप्त गर्ने, जुन प्रायः SAP समाधानहरू हुन्?

एचआर मेट्रिक्स पहिलो परियोजना थियो जसमा यो समस्या समाधान गर्न आवश्यक थियो। हाम्रो लक्ष्य मानव संसाधन डेटाको भण्डार सिर्जना गर्नु र कर्मचारीहरूसँग काम गर्ने क्षेत्रमा विश्लेषणात्मक रिपोर्टिङ निर्माण गर्नु थियो। यस अवस्थामा, डाटाको मुख्य स्रोत 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 मा तिनीहरूलाई प्रशोधन गरिनेछ र भौतिक वस्तुहरूमा रूपान्तरण गरिनेछ (उदाहरणका लागि, विभाग वा कर्मचारी) र मेट्रिक्स (उदाहरणका लागि, औसत headcount)।

लगभग 70 तालिकाहरू परिभाषित गरिएको थियो, जसबाट डाटा ग्रीनप्लममा हस्तान्तरण गर्नुपर्छ। त्यसपछि हामीले यो डाटा ट्रान्समिट गर्ने विधि बनाउन थाल्यौं।

SAP ले एकीकरण संयन्त्रको एकदम ठूलो संख्या प्रदान गर्दछ। तर सबैभन्दा सजिलो तरीका भनेको इजाजतपत्र प्रतिबन्धका कारण डाटाबेसमा प्रत्यक्ष पहुँच निषेधित छ। यसैले, सबै एकीकरण प्रवाहहरू अनुप्रयोग सर्भर स्तरमा लागू गरिनु पर्छ।
अर्को समस्या SAP डाटाबेसमा मेटाइएका रेकर्डहरूको बारेमा डाटाको अभाव थियो। जब तपाइँ डेटाबेसमा पङ्क्ति मेटाउनुहुन्छ, यो भौतिक रूपमा मेटिन्छ। ती। परिवर्तनको समयको आधारमा परिवर्तन डेल्टाको गठन सम्भव थिएन।

अवश्य पनि, SAP HCM सँग डाटा परिवर्तनहरू रेकर्ड गर्ने संयन्त्र छ। उदाहरणका लागि, प्राप्तकर्ता प्रणालीहरूमा पछिको स्थानान्तरणको लागि, त्यहाँ परिवर्तन सूचकहरू छन् जुन कुनै पनि परिवर्तनहरू रेकर्ड गर्दछ र जसको आधारमा एक Idoc गठन हुन्छ (बाह्य प्रणालीहरूमा स्थानान्तरणको लागि वस्तु)।

कर्मचारी नम्बर १२५१४४५ भएको कर्मचारीको लागि इन्फोटाइप ०३०२ परिवर्तन गर्नको लागि IDoc उदाहरण:

वा DBTABLOG तालिकामा डेटा परिवर्तनहरूको लगहरू राख्दै।

hrp53216375 तालिकाबाट QK1000 कुञ्जीसँग रेकर्ड मेटाउनको लागि लगको उदाहरण:

तर यी संयन्त्रहरू सबै आवश्यक डेटाको लागि उपलब्ध छैनन्, र अनुप्रयोग सर्भर स्तरमा तिनीहरूको प्रशोधनले धेरै स्रोतहरू खपत गर्न सक्छ। त्यसकारण, सबै आवश्यक तालिकाहरूमा लगिङलाई व्यापक रूपमा सक्षम गर्नाले प्रणालीको कार्यसम्पादनमा उल्लेखनीय गिरावट आउन सक्छ।

अर्को प्रमुख समस्या क्लस्टर टेबल थियो। SAP HCM को RDBMS संस्करणमा समय अनुमान र पेरोल डेटा प्रत्येक गणनाको लागि प्रत्येक कर्मचारीको लागि तार्किक तालिकाहरूको सेटको रूपमा भण्डारण गरिन्छ। यी तार्किक तालिकाहरू तालिका pcl2 मा बाइनरी डेटाको रूपमा भण्डारण गरिएका छन्।

पेरोल क्लस्टर:

क्लस्टर गरिएको तालिकाहरूबाट डाटा SQL आदेशको रूपमा मान्न सकिँदैन, तर SAP HCM म्याक्रो वा विशेष प्रकार्य मोड्युलहरूको प्रयोग आवश्यक छ। तदनुसार, त्यस्ता तालिकाहरूको पढ्ने गति एकदम कम हुनेछ। अर्कोतर्फ, त्यस्ता क्लस्टरहरूले डाटा भण्डारण गर्दछ जुन महिनामा एक पटक मात्र आवश्यक हुन्छ - अन्तिम पेरोल र समय अनुमान। त्यसैले यस मामला मा गति यति महत्वपूर्ण छैन।

डेटा परिवर्तनहरूको डेल्टा गठनका लागि विकल्पहरू मूल्याङ्कन गर्दै, हामीले पूर्ण अनलोडिङको विकल्पलाई पनि विचार गर्ने निर्णय गर्यौं। प्रत्येक दिन प्रणालीहरू बीच अपरिवर्तित डाटाको गीगाबाइट स्थानान्तरण गर्ने विकल्प राम्रो देखिँदैन। यद्यपि, यसका धेरै फाइदाहरू पनि छन् - स्रोत साइडमा डेल्टा लागू गर्न र रिसीभर साइडमा यस डेल्टाको इम्बेडिङ लागू गर्न दुवै आवश्यक छैन। तदनुसार, लागत र कार्यान्वयन समय कम हुन्छ, र एकीकरणको विश्वसनीयता बढ्छ। एकै समयमा, यो निर्धारित गरिएको थियो कि SAP HR मा लगभग सबै परिवर्तनहरू हालको मिति अघि तीन महिनाको क्षितिज भित्र हुन्छ। तसर्थ, हालको मिति भन्दा पहिले SAP HR N महिनाहरूबाट डेटाको दैनिक पूर्ण डाउनलोड र मासिक पूर्ण डाउनलोडको लागि रोज्ने निर्णय गरियो। N प्यारामिटर विशिष्ट तालिकामा निर्भर गर्दछ
र 1 देखि 15 सम्मको दायरा।

डाटा निकासीको लागि निम्न योजना प्रस्ताव गरिएको थियो:

बाह्य प्रणालीले अनुरोध उत्पन्न गर्छ र यसलाई SAP HCM मा पठाउँछ, जहाँ यो अनुरोध डेटाको पूर्णता र तालिकाहरू पहुँच गर्न अनुमतिहरूको लागि जाँच गरिन्छ। यदि जाँच सफल भयो भने, SAP HCM ले आवश्यक डाटा सङ्कलन गर्ने र फ्यूज एकीकरण समाधानमा स्थानान्तरण गर्ने कार्यक्रम चलाउँछ। फ्यूजले काफ्कामा आवश्यक विषय निर्धारण गर्दछ र त्यहाँ डाटा स्थानान्तरण गर्दछ। अर्को, काफ्काबाट डाटा स्टेज एरिया GP मा स्थानान्तरण गरिएको छ।

यस श्रृंखलामा, हामी 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 इन्टरनेट कम्युनिकेसन फ्रेमवर्क -) मा लागू गरिएको छ। help.sap.com/viewer/6da7259a6c4b1014b7d5e759cc76fd22/7.01.22/en-US/488d6e0ea6ed72d5e10000000a42189c.html)। यसले तपाइँलाई विशिष्ट तालिकाहरू प्रयोग गरेर SAP HCM प्रणालीबाट डेटा क्वेरी गर्न अनुमति दिन्छ। डाटा अनुरोध सिर्जना गर्दा, आवश्यक डाटा प्राप्त गर्नका लागि विशिष्ट क्षेत्रहरू र फिल्टरिंग प्यारामिटरहरूको सूची निर्दिष्ट गर्न सम्भव छ। एकै समयमा, सेवाको कार्यान्वयनले कुनै पनि व्यापार तर्कलाई संकेत गर्दैन। डेल्टा गणना गर्नका लागि एल्गोरिदमहरू, क्वेरी प्यारामिटरहरू, अखण्डता निगरानी, ​​आदि बाह्य प्रणालीको छेउमा पनि लागू गरिन्छ।

यो संयन्त्रले तपाईंलाई केही घण्टामा सबै आवश्यक डाटा सङ्कलन र प्रसारण गर्न अनुमति दिन्छ। यो गति स्वीकार्य हुने कगारमा छ, त्यसैले हामी यो समाधानलाई अस्थायी रूपमा विचार गर्छौं, जसले परियोजनामा ​​निकासी उपकरणको आवश्यकता पूरा गर्न सम्भव बनायो।
लक्षित तस्विरमा, डाटा निकासीको समस्या समाधान गर्न, Oracle गोल्डेन गेट वा ETL उपकरणहरू जस्तै SAP DS जस्ता CDC प्रणालीहरू प्रयोग गर्ने विकल्पहरू अन्वेषण भइरहेको छ।

स्रोत: www.habr.com