ผมทำงานกับ Oracle EBS มาเกิน 18 ปี โดยได้สัมผัสกับวิวัฒนาการทั้งหมดตั้งแต่ 11i ถึง R12 ตลอดอาชีพการงานอันยาวนานนี้ การพัฒนารายงานเฉพาะระบบถือเป็นงานหลักที่หลีกเลี่ยงไม่ได้ และรอบ ๆ งานนี้ ปัญหาบางอย่างก็เกิดขึ้นซ้ำแล้วซ้ำเล่าโดยไม่ได้รับการแก้ไขอย่างแท้จริง
ผมทำงานกับ Oracle EBS มาเกิน 18 ปี โดยได้สัมผัสกับวิวัฒนาการทั้งหมดตั้งแต่ 11i ถึง R12 ตลอดอาชีพการงานอันยาวนานนี้ การพัฒนารายงานเฉพาะระบบถือเป็นงานหลักที่หลีกเลี่ยงไม่ได้ และรอบ ๆ งานนี้ ปัญหาบางอย่างก็เกิดขึ้นซ้ำแล้วซ้ำเล่าโดยไม่ได้รับการแก้ไขอย่างแท้จริง
บทความนี้ไม่ได้ตั้งใจจะเล่าเรื่องราว เพียงแต่ต้องการบันทึกปัญหาที่ผมได้สังเกตและประสบพบเจอมาหลายปี รวมถึงความพยายามที่ได้ทำเพื่อแก้ไขปัญหาเหล่านั้น อย่างตรงไปตรงมา หวังว่าจะเป็นข้อมูลอ้างอิงสำหรับผู้ประกอบวิชาชีพที่เผชิญกับความท้าทายคล้ายคลึงกัน
ในระบบนิเวศของ EBS มีขั้นตอนการปฏิบัติงานที่ตายตัวระหว่างการเขียน SQL เสร็จสิ้น ไปจนถึงเวลาที่รายงานสามารถทำงานได้โดยผู้ใช้ปลายทาง กระบวนการนี้มีความสมเหตุสมผลและจำเป็นภายใต้กรอบการออกแบบของ EBS—เพื่อรับประกันความปลอดภัย การแยกองค์กรหลายแห่ง การตรวจสอบพารามิเตอร์ และการจัดตารางคำขอ แต่อย่างไรก็ตาม จากมุมมองของประสิทธิภาพการพัฒนา ต้นทุนของมันก็สูงจริง ๆ
โดยเฉพาะอย่างยิ่ง หลังจากที่นักพัฒนาทำการเขียนและทดสอบ SQL เสร็จแล้ว ยังต้องดำเนินการตามลำดับดังต่อไปนี้:
ขั้นตอนเหล่านี้ไม่เกี่ยวข้องกับตรรกะทางธุรกิจที่ซับซ้อน—เป็นงานกำหนดค่าล้วน ๆ แต่สำหรับรายงานแบบง่าย ๆ ที่อาจใช้เพียงครั้งเดียว ต้นทุนการเริ่มต้นของกระบวนการนี้สูงเกินไป รายงานที่ใช้เวลาเขียน SQL เพียง ๒๐ นาที มักต้องใช้เวลามากกว่าหนึ่งชั่วโมงในการดำเนินกระบวนการทั้งหมด โดยเวลาส่วนใหญ่หมดไปกับการนำทางเมนู การกรอกข้อมูลในฟิลด์ และการรอการตอบสนองของหน้าเว็บ
ที่สำคัญกว่านั้น หากรายงานจำเป็นต้องปรับเปลี่ยนตรรกะ SQL หรือนิยามพารามิเตอร์หลังจากการทดสอบ ขั้นตอนส่วนใหญ่ข้างต้นจะต้องถูกทำซ้ำ นี่ถือเป็นคอขวดสำคัญสำหรับสถานการณ์การพัฒนาที่ต้องการการวนซ้ำอย่างรวดเร็ว
นี่คือปัญหาที่ผมเห็นว่าเป็นแกนหลัก และมีผลกระทบต่อประสบการณ์ผู้ใช้มากที่สุด
รูปแบบผลลัพธ์ดั้งเดิมของโปรแกรมพร้อมกัน EBS คือไฟล์ข้อความ (โดยทั่วไปคือ .out หรือ .txt) ไม่ว่าจะเป็นรายงาน .rdf ที่พัฒนาด้วย Report Builder หรือผลลัพธ์จากโพรซีเยอร์ที่เก็บไว้ใน PL/SQL สิ่งที่ส่งถึงผู้ใช้ในท้ายที่สุดก็คือข้อความที่มีความกว้างคงที่หรือคั่นด้วยตัวคั่น
แต่สิ่งที่ผู้ใช้ทางธุรกิจต้องการในการทำงานประจำวันนั้น แทบไม่มีข้อยกเว้น คือไฟล์ข้อมูลในรูปแบบ Excel สิ่งนี้สร้าง "ขั้นตอนกลาง" ที่มีมายาวนาน: ผู้ใช้ต้องคัดลอกและวางเนื้อหาของไฟล์ข้อความลงใน Excel แล้วใช้ฟังก์ชัน "ข้อความเป็นคอลัมน์" เพื่อแยกเป็นหลายคอลัมน์
ขั้นตอนนี้มีปัญหาเชิงเทคนิคเฉพาะหลายประการ:
ประการแรก ปัญหาความกว้างของฟิลด์ นักพัฒนารายงานต้องกำหนดความกว้างในการแสดงผลสำหรับแต่ละฟิลด์ผลลัพธ์ล่วงหน้า หากความยาวข้อมูลจริงของฟิลด์ใดเกินความกว้างที่ตั้งไว้ล่วงหน้านี้ (เช่น ฟิลด์ข้อความอิสระอย่างคำอธิบายวัสดุหรือชื่อผู้จัดจำหน่าย) EBS จะจัดการโดยการตัดบรรทัดอัตโนมัติ โดยแทรกอักขระขึ้นบรรทัดใหม่ลงในไฟล์ข้อความ อักขระขึ้นบรรทัดใหม่นี้ปรากฏตามปกติในโปรแกรมดูข้อความ—เนื้อหาจะแสดงในบรรทัดใหม่ แต่เมื่อผู้ใช้คัดลอกข้อความทั้งหมดไปที่ Excel และดำเนินการแยกคอลัมน์ Excel จะรับรู้อักขระขึ้นบรรทัดใหม่นี้เป็นตัวยุติแถว ทำให้ระเบียนเดียวถูกแยกออกเป็นสองแถวหรือมากกว่าอย่างไม่ถูกต้อง การจัดตำแหน่งคอลัมน์ของระเบียนที่ตามมาทั้งหมดจะเสียหายโดยสมบูรณ์ ผู้ใช้ต้องค้นหาและแก้ไขข้อผิดพลาดเหล่านี้ด้วยตนเอง หรือปรับความกว้างฟิลด์ของรายงานใหม่แล้วส่งคำขออีกครั้ง
ประการที่สอง ปัญหาการเข้ารหัสอักขระ รูปแบบการเข้ารหัสเริ่มต้นของไฟล์ข้อความมักไม่ตรงกับการเข้ารหัสเริ่มต้นของ Excel ในการเปิดไฟล์ โดยเฉพาะอย่างยิ่งเมื่อจัดการกับอักขระหลายไบต์ เช่น ภาษาจีนหรือญี่ปุ่น ซึ่งมักทำให้เกิดข้อความที่อ่านไม่ได้ ผู้ใช้ต้องเลือกการเข้ารหัสที่ถูกต้องด้วยตนเองเมื่อเปิดไฟล์ข้อความ หรือระบุรูปแบบการเข้ารหัสระหว่างการนำเข้า Excel สำหรับผู้ใช้ทางธุรกิจที่ไม่มีความรู้ด้านเทคนิค นี่เป็นภาระเพิ่มเติมและไม่จำเป็น
ประการที่สาม การจัดการรูปแบบตัวเลขและวันที่ ตัวเลขและวันที่ที่ส่งออกในไฟล์ข้อความมักอยู่ในรูปแบบข้อความธรรมดา หลังจากวางใน Excel ผู้ใช้ต้องกำหนดรูปแบบเซลล์ด้วยตนเองก่อนที่จะสามารถดำเนินการคำนวณ เช่น การรวมหรือการหาค่าเฉลี่ย เมื่อเกี่ยวข้องกับตัวคั่นหลักพัน ความแม่นยำทศนิยม หรือรูปแบบการแสดงวันที่ จำเป็นต้องมีขั้นตอนการปรับแต่งเพิ่มเติม
ประการที่สี่ ประสิทธิภาพการประมวลผลด้วยข้อมูลจำนวนมาก เมื่อรายงานส่งคืนข้อมูลปริมาณมาก (เช่น เกิน ๑๐,๐๐๐ แถว) การดำเนินการคัดลอก-วางและแยกคอลัมน์ด้วยตนเองก็ใช้เวลามาก และประสิทธิภาพของ Excel ในการวางข้อความปริมาณมากก็ไม่เสถียรเสมอไป มักเกิดอาการหน่วงหรือไม่ตอบสนอง
ปัญหาเหล่านี้พบได้ทั่วไปทั้งในรายงานมาตรฐานของ EBS และรายงานเฉพาะระบบ พูดอย่างเคร่งครัด นี่ไม่ใช่ "จุดบกพร่อง"—แต่เป็นทางเลือกในการออกแบบจากยุคที่สร้าง EBS ซึ่งการส่งออกข้อความเป็นวิธีหลักในการแลกเปลี่ยนข้อมูลข้ามแพลตฟอร์ม แต่ในสภาพแวดล้อมทางธุรกิจปัจจุบัน ทางเลือกในการออกแบบนี้ไม่สอดคล้องกับสถานการณ์การใช้งานจริงของผู้ใช้
แผนกธุรกิจมักมีความต้องการวิเคราะห์ข้อมูลที่ไม่เป็นงวดในการดำเนินงานประจำวัน ตัวอย่างเช่น:
ลักษณะของความต้องการเหล่านี้คือ: ตรรกะ SQL ค่อนข้างชัดเจน ขอบเขตข้อมูลจำกัด ข้อกำหนดด้านความทันเวลาสูง และมีแนวโน้มสูงที่จะใช้เพียงครั้งเดียวโดยไม่เกิดขึ้นซ้ำ
ภายใต้เส้นทางการพัฒนามาตรฐานของ EBS แม้แต่รายงานเฉพาะครั้งก็ยังต้องผ่านกระบวนการลงทะเบียนทั้งหมด ตั้งแต่การกำหนดไฟล์ปฏิบัติการไปจนถึงการแนบเข้ากลุ่มคำขอ ซึ่งหมายความว่านักพัฒนาต้องทำงานกำหนดค่าที่ไม่เกี่ยวข้องกับตรรกะทางธุรกิจซ้ำแล้วซ้ำเล่าทุกครั้งที่ตอบสนองต่อความต้องการเฉพาะครั้งดังกล่าว
อีกวิธีแก้ปัญหาทั่วไปคือ นักพัฒนาดำเนินการ SQL โดยตรงในเครื่องมือฐานข้อมูล (เช่น PL/SQL Developer หรือ Toad) คัดลอกผลลัพธ์และส่งให้ผู้ใช้ใน Excel วิธีนี้หลีกเลี่ยงกระบวนการลงทะเบียนของ EBS และเร็วกว่ามาก แต่ก็หลีกเลี่ยงการควบคุมการเข้าถึงหลายองค์กรและการตรวจสอบสิทธิ์ข้อมูลของ EBS ทำให้เกิดความเสี่ยงด้านความปลอดภัยของข้อมูลที่อาจเกิดขึ้น และไม่สามารถใช้ Concurrent Manager สำหรับการจัดตารางเวลาและบันทึกประวัติแบบรวมศูนย์ได้
ปัญหาที่อธิบายข้างต้นไม่ได้เกิดขึ้นใหม่ อันที่จริง ในชุมชนผู้ใช้ EBS และในแวดวงผู้ปฏิบัติงาน ปัญหาเหล่านี้เป็นความลับที่เปิดเผยมายาวนาน แต่ตลอดหลายปีที่ผ่านมา วิธีแก้ปัญหาของอุตสาหกรรมส่วนใหญ่มุ่งเน้นไปที่แนวทางต่อไปนี้ ซึ่งทั้งหมดมีประสิทธิผลจำกัด:
ไม่มีแนวทางใดที่เปลี่ยนแปลงรูปแบบการพัฒนารายงาน EBS อย่างมีนัยสำคัญ นักพัฒนายังคงต้องลงทุนความพยายามทั้งในระดับการเขียน SQL และการกำหนดค่าระบบ และผู้ใช้ยังคงต้องใช้เวลาเพิ่มเติมทั้งในการรับข้อมูลและการทำความสะอาดข้อมูล
จากปัญหาข้างต้น ผมได้พยายามสร้างชั้นเครื่องมือรายงานอิสระ ใช้ชื่อว่า SQLVantage การวางตำแหน่งของมันไม่ใช่การแทนที่ Concurrent Manager ของ EBS แต่เป็นการทำหน้าที่เป็นชั้นการตอบสนองที่รวดเร็วเสริม ซึ่งครอบคลุมสถานการณ์ต่อไปนี้:
ปรัชญาการออกแบบหลักของเครื่องมือนี้คือ: ตัดงานเชิงกระบวนการที่ใช้เวลามากที่สุดและไม่เกี่ยวข้องกับตรรกะทางธุรกิจในการพัฒนารายงาน EBS ออกไป เพื่อให้นักพัฒนาสามารถมุ่งเน้นไปที่องค์ประกอบหลักสองประการโดยตรง—SQL และการกำหนดค่าพารามิเตอร์
แนวทางเฉพาะมีดังนี้:
ในด้านการพัฒนา นักพัฒนาเพียงแค่กรอกชื่อรายงาน เขียนคำสั่ง SQL และกำหนดพารามิเตอร์การสอบถาม (ชื่อพารามิเตอร์ ชนิดข้อมูล ป้ายแสดงผล ค่าเริ่มต้น) ในเครื่องมือ หลังจากบันทึก รายงานจะพร้อมใช้งานทันที ไม่จำเป็นต้องกำหนดไฟล์ปฏิบัติการ ลงทะเบียนโปรแกรมพร้อมกัน กำหนดค่าชุดค่า หรือแนบกลุ่มคำขอ กระบวนการกำหนดค่าทั้งหมดสามารถเสร็จสิ้นภายใน ๓ ถึง ๕ นาที
ในด้านความปลอดภัยของข้อมูล เครื่องมือใช้กลไกการตรวจสอบสิทธิ์ผู้ใช้ของ EBS ซ้ำ เพื่อให้แน่ใจว่าเฉพาะผู้ใช้ที่มีความรับผิดชอบ EBS ที่เหมาะสมเท่านั้นที่สามารถเข้าถึงและเรียกใช้รายงานได้ ตรรกะการควบคุมการเข้าถึงหลายองค์กร (MOAC) ที่เกี่ยวข้องในคำสั่ง SQL ยังคงอยู่ในคำสั่ง SQL เอง โดยนักพัฒนาจะควบคุมตามความต้องการทางธุรกิจจริง
ในด้านรูปแบบผลลัพธ์ เครื่องมือสร้างไฟล์ Excel .xlsx โดยตรง แต่ละฟิลด์ผลลัพธ์การสอบถามจะตรงกับหนึ่งคอลัมน์ใน Excel และแต่ละแถวข้อมูลจะตรงกับหนึ่งแถวใน Excel ความกว้างของฟิลด์ปรับให้เข้ากับเนื้อหาโดยอัตโนมัติ และข้อความยาวจะไม่ทำให้เกิดการตัดบรรทัดที่ทำให้ข้อมูลเสียหาย ตัวเลข วันที่ และชนิดข้อมูลอื่น ๆ จะรักษาแอตทริบิวต์ชนิดข้อมูลเดิมไว้ระหว่างการส่งออก ทำให้ผู้ใช้สามารถจัดเรียง กรอง และดำเนินการคำนวณได้ทันทีเมื่อเปิดไฟล์ Excel
ในด้านความสามารถในการขยาย นอกจาก Excel แล้ว เครื่องมือยังรองรับการส่งออกในรูปแบบ JSON เพื่อความสะดวกในการเชื่อมต่อกับแพลตฟอร์มข้อมูลภายนอกหรือระบบ BI
หลังจากใช้งานภายในระยะเวลาหนึ่ง เครื่องมือนี้ได้ปรับปรุงประสิทธิภาพในด้านต่าง ๆ ดังนี้:
ในเวลาเดียวกัน ผมต้องชี้ให้เห็นข้อจำกัดของเครื่องมือนี้ด้วย:
ตลอด ๑๘ ปีที่ผ่านมา EBS เป็นแพลตฟอร์มแอปพลิเคชันระดับองค์กรที่มีความเสถียรและความเข้มงวดทางสถาปัตยกรรมหลักที่ไม่มีข้อกังขา แต่เพราะความเสถียรนี้เอง ทางเลือกในการออกแบบบางอย่างที่สมเหตุสมผลในยุคนั้น จึงดูเชื่องช้าและเทอะทะในสถานการณ์การใช้งานในปัจจุบัน
ต้นทุนกระบวนการพัฒนารายงาน รูปแบบผลลัพธ์ที่ใช้ข้อความ เส้นทางการตอบสนองสำหรับความต้องการเฉพาะครั้ง—ปัญหาเหล่านี้ไม่ได้เกิดขึ้นในวันนี้ เพียงแต่ในสภาพแวดล้อมปัจจุบัน ต้นทุนของปัญหาเหล่านี้ชัดเจนขึ้น จังหวะธุรกิจเร็วขึ้น ความต้องการขององค์กรในการตอบสนองข้อมูลเพิ่มขึ้น และเครื่องมือและกระบวนการที่เราใช้ยังคงติดอยู่ในยุคที่ผ่านไปแล้ว
SQLVantage เป็นความพยายามที่ผมทำขึ้นจากปัญหาเหล่านี้ ไม่ได้เป็นนวัตกรรมใหม่แต่อย่างใด แต่เป็นการลดความซับซ้อนและการจัดระเบียบกระบวนการที่มีอยู่ใหม่ หากบทความนี้สามารถสะท้อนใจเพื่อนร่วมงานบางคน หรือให้มุมมองอ้างอิงสำหรับผู้ที่กำลังคิดเกี่ยวกับปัญหาคล้ายคลึงกัน ก็บรรลุวัตถุประสงค์แล้ว
การเขียนมาถึงจุดนี้ ผมไม่ได้ตั้งใจจะนำเสนอสิ่งนี้เป็น "เรื่องราวความสำเร็จ" มันเป็นเพียงคนที่ถูกปัญหาเฉพาะในสถานการณ์การทำงานเฉพาะรบกวนซ้ำแล้วซ้ำเล่า พยายามปรับปรุงปัญหาเหล่านั้นด้วยวิธีของตนเอง ส่วนเส้นทางนี้จะไปได้ไกลแค่ไหน ยังคงต้องทดสอบต่อไปในทางปฏิบัติ แต่อย่างน้อย ทิศทางก็ถูกต้อง—ปล่อยให้นักพัฒนากลับไปที่ SQL เอง ปล่อยให้ผู้ใช้กลับไปที่ข้อมูลเอง และปล่อยให้เครื่องมือจัดการกับสิ่งที่ไม่จำเป็นระหว่างทาง