ดังที่คุณทราบ SAP มีซอฟต์แวร์ครบวงจรทั้งสำหรับการรักษาข้อมูลธุรกรรมและสำหรับการประมวลผลข้อมูลนี้ในระบบการวิเคราะห์และการรายงาน โดยเฉพาะอย่างยิ่ง แพลตฟอร์ม SAP Business Warehouse (SAP BW) เป็นชุดเครื่องมือสำหรับจัดเก็บและวิเคราะห์ข้อมูลที่มีความสามารถด้านเทคนิคที่ครอบคลุม สำหรับข้อได้เปรียบตามวัตถุประสงค์ทั้งหมด ระบบ SAP BW มีข้อเสียเปรียบที่สำคัญประการหนึ่ง นี่เป็นค่าใช้จ่ายสูงในการจัดเก็บและประมวลผลข้อมูล โดยเฉพาะอย่างยิ่งเมื่อใช้ SAP BW บนคลาวด์บน Hana
จะเป็นอย่างไรหากคุณเริ่มใช้ผลิตภัณฑ์ที่ไม่ใช่ SAP และควรใช้ผลิตภัณฑ์ OpenSource เป็นที่จัดเก็บ พวกเราที่ X5 Retail Group เลือก 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 จะแสดงภาพโครงสร้างองค์กร พนักงาน และข้อมูลทรัพยากรบุคคลอื่นๆ ให้กับผู้ใช้ ตัวอย่างเช่น นี่คือลักษณะโครงสร้างองค์กรใน 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:
แต่กลไกเหล่านี้ไม่พร้อมใช้งานสำหรับข้อมูลที่จำเป็นทั้งหมดและการประมวลผลในระดับแอปพลิเคชันเซิร์ฟเวอร์อาจใช้ทรัพยากรค่อนข้างมาก ดังนั้นการเปิดใช้งานการบันทึกอย่างหนาแน่นในตารางที่จำเป็นทั้งหมดอาจทำให้ประสิทธิภาพของระบบลดลงอย่างเห็นได้ชัด
ปัญหาสำคัญต่อไปคือตารางคลัสเตอร์ การประมาณเวลาและข้อมูลเงินเดือนใน SAP HCM เวอร์ชัน RDBMS จะถูกจัดเก็บเป็นชุดตารางลอจิคัลสำหรับพนักงานแต่ละคนสำหรับการคำนวณแต่ละครั้ง ตารางลอจิคัลเหล่านี้ถูกจัดเก็บเป็นข้อมูลไบนารีในตาราง pcl2
คลัสเตอร์เงินเดือน:
ข้อมูลจากตารางคลัสเตอร์ไม่ถือเป็นคำสั่ง SQL แต่ต้องใช้มาโคร SAP HCM หรือโมดูลฟังก์ชันพิเศษ ดังนั้นความเร็วในการอ่านของตารางดังกล่าวจึงค่อนข้างต่ำ ในทางกลับกัน คลัสเตอร์ดังกล่าวจะจัดเก็บข้อมูลที่จำเป็นเพียงเดือนละครั้งเท่านั้น เช่น การบัญชีเงินเดือนขั้นสุดท้ายและการประมาณเวลา ดังนั้นความเร็วในกรณีนี้จึงไม่สำคัญนัก
ในการประเมินตัวเลือกสำหรับการสร้างส่วนต่างของการเปลี่ยนแปลงข้อมูล เราตัดสินใจพิจารณาตัวเลือกในการขนถ่ายทั้งหมดด้วย ตัวเลือกในการถ่ายโอนข้อมูลกิกะไบต์ที่ไม่เปลี่ยนแปลงระหว่างระบบทุกวันอาจดูไม่ดี อย่างไรก็ตาม ยังมีข้อดีอีกหลายประการ โดยไม่จำเป็นต้องนำเดลต้าไปใช้งานที่ฝั่งต้นทางและไม่จำเป็นต้องฝังเดลต้านี้ที่ฝั่งตัวรับ ดังนั้นต้นทุนและเวลาดำเนินการจึงลดลง และความน่าเชื่อถือของการบูรณาการก็เพิ่มขึ้น ในเวลาเดียวกัน มีการพิจารณาว่าการเปลี่ยนแปลงเกือบทั้งหมดใน SAP HR เกิดขึ้นภายในขอบเขตสามเดือนก่อนวันที่ปัจจุบัน ดังนั้นจึงตัดสินใจเลือกดาวน์โหลดข้อมูลแบบเต็มรายวันจาก SAP HR N เดือนก่อนวันที่ปัจจุบันและดาวน์โหลดแบบเต็มรายเดือน พารามิเตอร์ N ขึ้นอยู่กับตารางเฉพาะ
และมีตั้งแต่ 1 ถึง 15
มีการเสนอรูปแบบต่อไปนี้สำหรับการดึงข้อมูล:
ระบบภายนอกสร้างคำขอและส่งไปยัง SAP HCM โดยที่คำขอนี้ได้รับการตรวจสอบความสมบูรณ์ของข้อมูลและสิทธิ์ในการเข้าถึงตาราง หากการตรวจสอบสำเร็จ SAP HCM จะรันโปรแกรมที่รวบรวมข้อมูลที่จำเป็นและถ่ายโอนไปยังโซลูชันการรวม Fuse ฟิวส์จะกำหนดหัวข้อที่ต้องการในคาฟคาและถ่ายโอนข้อมูลไปที่นั่น จากนั้น ข้อมูลจาก Kafka จะถูกถ่ายโอนไปยัง 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 กำลังถูกสำรวจ
ที่มา: will.com