รู้จักภาษา ABAP : เปิดเบื้องหลังของ SAP R/3 ตอนที่ 1

<

เรียนรู้โครงสร้างของ SAP R/3 แบบง่ายๆ เพื่อปูทางไปสู่เซียนภาษา ABAP
หลายท่านคงรู้จักกับระบบ SAP R/3 ซึ่งเป็นซอฟต์แวร์ ERP (Enterprise Resource Planning) ชั้นนำตัวหนึ่งของโลกมาบ้าง แต่ทราบไหมครับว่า SAP R/3 ที่ใช้กันอยู่นี้ เขียนขึ้นมาจากภาษาโปรแกรมอะไร

บทความที่ผมจะนำเสนอต่อจากนี้ คือเรื่องราวของภาษา ABAP (อ่านว่าอาบัพ) ที่อยู่เบื้องหลังระบบ SAP R/3 โดยเราจะเริ่มต้นกันที่สถาปัตยกรรมของระบบ SAP R/3 และฉบับต่อไป ผมจะลงลึกไปถึงการทำโปรแกรมบน SAP R/3 แล้วคุณจะรู้สึกเหมือนกับผมว่าภาษา ABAP ง่ายกว่าที่คาดไว้จริงๆ

รู้จักกับระบบ SAP R/3

SAP R/3 เป็นแอพพลิเคชันซอฟต์แวร์ชนิดไคลเอ็นต์/เซิร์ฟเวอร์ ที่ทำงานในลักษณะของทรีเทียร์ (3 Tier Architecture) ซึ่งแบ่งลำดับชั้นของเซอร์วิสในแอพพลิเคชันเป็น 3 ระดับคือ Presentation Server, Application Server และ Database Server (อ้างอิงจากโมเดลมาตรฐานของแอพพลิเคชันแบบทรีเทียร์ ซึ่งประกอบไปด้วย Presen tation Logic, Application Logic, Data Logic และ Data Service)
Presentation Server (หมายถึงโปรแกรม SAPGUI ในระบบ SAP R/3) เป็นส่วนให้บริการด้านการแสดงผลบนจอภาพ ซึ่งรันอยู่บนไคลเอ็นต์ที่มีการโต้ตอบกับยูสเซอร์ ส่วน Application Server (ในระบบ SAP R/3 ส่วนนี้คือ R/3 Instance) จะให้บริการทางด้านแอพพลิเคชันลอจิก (Application Logic) และดาต้าลอจิก (Data Logic) สุดท้ายคือ Database Server จะทำงานร่วมกับ RDBMS ชั้นนำได้ ไม่ว่าจะเป็น ORACLE, Informix, DB2, Microsoft SQL Server หรือ ADABUS (ปัจจุบันเป็น SAP DB)

โมเดลมาตรฐานของแอพพลิเคชันแบบทรีเทียร์ Presentation Logic หมายถึง งานที่เกี่ยวข้องกับการแสดงข้อมูลบนจอภาพ ส่วน Application Logic เป็นคำสั่งที่ใช้ควบคุมการทำงานของโปรแกรม หรือคำนวณค่าต่างๆ เช่น คำสั่ง IF, CASE, DO, WHILE หรือคำนวณบวกลบคูณหาร Data Logic ก็คือ กลุ่มของโค้ดที่ใช้เข้าถึงข้อมูลในฐานข้อมูล อย่างคำสั่ง SQL เป็นต้น สุดท้ายคือ Data Service จะทำหน้าที่ดูแลและจัดการข้อมูลในระบบฐานข้อมูล (RDBMS)

แนวคิดของระบบไคลเอ็นต์/เซิร์ฟเวอร์

ระบบไคลเอ็นต์/เซิร์ฟเวอร์นั้นมีรากฐานมาจากวิธีคิดแบบกระจายงานกันทำ ซึ่งหมายถึงการแยกองค์ประกอบทั้ง 4 ของแอพพลิเคชัน ให้ไปทำงานบนคอมพิวเตอร์แต่ละเครื่อง ซึ่งจะไม่เหมือนกับระบบโฮสต์เดี่ยวบนเมนเฟรมอย่างในสมัยก่อน ถ้าเราย้อนไปในอดีตที่ผ่านมา คุณจะพบว่าไคลเอ็นต์/เซิร์ฟเวอร์เกิดขึ้นมาพร้อมๆ กับคำว่า Down Sizing คือ เมื่อมีการแยกส่วนของแอพพลิเคชันออกจากกันแล้ว (ทำงานที่คนละเครื่อง) เซิร์ฟเวอร์ก็ไม่จำเป็นต้องมีพลังประมวลผลสูงนัก เนื่องจากตัวมันจะถูกใช้งานเฉพาะในส่วนของ Data Service เท่านั้น ขณะที่ Presentation Logic, Application Logic และ Data Logic ถูกย้ายไปทำงานที่เครื่องไคลเอ็นต์แทน ซึ่งเป็นรูปแบบที่เรียกว่า 2 Tier Client/Server

สถาปัตยกรรมแบบทรีเทียร์ของระบบ SAP/R3

การทำงานของระบบโฮสต์เดี่ยว (Host-based)

แต่ปัญหาของ 2 Tier Client/Server ก็คือ ถ้าเรามีการแก้ไขเพิ่มเติมในส่วนของกฏเกณฑ์ทางธุรกิจ (Business Rule) ซึ่งหมายถึง Application Logic กับ Data Logic บนเครื่องไคลเอ็นต์ ก็จะประสบปัญหาในการดูแลระบบทันที ยกตัวอย่างเช่น ถ้าเราต้องการเพิ่มเงื่อนไข ว่านักศึกษาคนใดที่ต้องการลงทะเบียนเรียนวิชา X จะต้องผ่านการเรียนวิชา A มาก่อน สมมุติเรามีไคลเอ็นต์สำหรับลงทะเบียนอยู่ 10 เครื่อง ก็ต้องไปอัพเดตซอฟต์แวร์ใหม่ทั้ง 10 เครื่อง และถ้ามีการเปลี่ยน กฏเกณฑ์ในการลงทะเบียนเรียนวิชา X นี้อีก ก็ต้องตามไปแก้ไขโปรแกรมที่ไคลเอ็นต์ทั้ง 10 เครื่องใหม่ ดังนั้นในยุคต่อมาจึงมีการย้าย Application Logic และ Data Logic บางส่วน ไปทำงานที่เซิร์ฟเวอร์ โดยเราจะเรียกส่วนงานที่เซิร์ฟเวอร์นี้ ว่า Store Procedure ในรูปแบบของ Message-based Client/Server ก็คือ ไคลเอ็นต์จะไม่ได้สื่อสารกับเซิร์ฟเวอร์ ด้วยคำสั่ง SQL เท่านั้น แต่จะมีการเรียก Store Procedure ที่ฝั่งเซิร์ฟเวอร์ด้วย ข้อดีของระบบ Message-based Client/Server ก็คือ การดูแล Business Rule จะทำที่ฝั่งเซิร์ฟเวอร์เพียงแห่งเดียวเท่านั้น
แต่ปัญหาของระบบ Message-based Client/Server คือ เมื่อเราย้าย Application Logic และ Data Logic บางส่วนไปที่เซิร์ฟเวอร์ ก็ย่อมเป็นการเพิ่มภาระงานให้โดยปริยาย ปัญหาที่ตามมา ก็คือเรื่องของประสิทธิภาพ โดยเฉพาะถ้ามียูสเซอร์เข้ามาใช้งานมากขึ้นเท่าไร ก็จะยิ่งรับภาระมากขึ้นเท่านั้น แถมยังมีส่วนที่ทำงานซ้ำซ้อนกันอีกด้วย ดังนั้น จึงมีหลักการของ 3 Tier Client/Server เกิดขึ้นมา ข้อดีของการทำงานในแบบทรี-เทียร์ อยู่ตรงที่เราสามารถเพิ่มประสิทธิภาพ ให้กับแอพพลิเคชันเซิร์ฟเวอร์ได้ง่าย เป็นการแก้ปัญหาที่ตรงจุด แถมคอมพิวเตอร์ในแต่ละเลเยอร์ก็ไม่ต้องรับภาระหนักเกินตัว
สถาปัตยกรรมของ SAP R/3 หลังจากที่เรียนรู้แนวคิดของไคลเอ็นต์/เซิร์ฟเวอร์ในแบบทรีเทียร์กันพอสมควรแล้ว คราวนี้เรามาลองดูในภาคปฏิบัติกันบ้าง ผมจะแสดงให้เห็นถึงรูปแบบการทำงานของระบบ SAP R/3 ในส่วนของ 3 Tier Client/Server ว่าทำงานอย่างไร

การทำงานของระบบไคลเอ็นต์/เซิร์ฟเวอร์

ระบบไคลเอ็นต์/เซิร์ฟเวอร์ที่ทำงานด้วยแมสเซจ

สมมติว่าผมต้องการเรียกโปรแกรมที่เขียนด้วยภาษา ABAP ดังต่อไปนี้มาทำงาน
Report ztest.
Tables customers.
Select single * from customers where id = 1
Write customers-name
ขั้นตอนแรกเราจะต้องล็อกออนเข้าไปใช้งานระบบ SAP R/3 ก่อน โดยเรียกโปรแกรม SAPGUI ที่ฝั่งไคลเอ็นต์ขึ้นมาทำงาน จากนั้นก็เรียกโปรแกรม ztest มา ทำงาน เพื่อนำข้อมูลของลูกค้าที่มีรหัส ID เป็น 1 ออกมาแสดงผลที่หน้าจอ ขั้นตอนของ การเอ็กซีคิวต์โปรแกรม ztest จะเป็นดังนี้

รีเควสต์ถูกส่งจากโปรแกรม SAPGUI ไปที่ R/3 Instance โดยส่วนของ Dispatcher จะทำหน้าที่รับรีเควสต์ (ก็คือ ต้องการเอ็กซีคิวต์โปรแกรม ztest) พร้อมกับนำรีเควสต์จากไคลเอ็นต์เครื่องนี้ เข้าไปรออยู่ใน Queue ซึ่งเป็นหน่วยความจำบัฟเฟอร์บนแอพพลิเคชันเซิร์ฟเวอร์

ขั้นตอนต่อมา Dispatcher จะพิจารณาหา Dialog Work Process (D) ที่ว่าง ถ้าพบว่ามี Dialog Work Process ตัวใดว่าง Dispatcher จะกำหนดรีเควสต์ที่รออยู่ใน Queue นี้ ให้กับ Dialog Work Process ตัวที่ว่างทำงานทันที

เมื่อ Dialog Work Process ได้รับการมอบหมายงานแล้ว ซึ่งในที่นี้คือ การเอ็กซีติวต์โปรแกรม ABAP ที่ชื่อ ztest ระบบก็จะโหลดโปรแกรม ztest ซึ่งเก็บอยู่ในตารางบนระบบฐานข้อมูลที่ Database Server ไปไว้ที่ Program Buffer (ถ้ายังไม่มีอยู่ในบัฟเฟอร์นั้น)

จากนั้น Dialog Work Process ก็จะนำคำสั่ง ABAP ไปทำงานทีละคำสั่งดังนี้

คำสั่ง Tables customers เป็นคำสั่งประเภท Application Logic ดังนั้น คำสั่งนี้จะถูกประมวลผลที่เครื่องแอพพลิเค-ชันเซิร์ฟเวอร์ (R/3 Instance) โดยระบบจะสร้าง Table Structure ชื่อ customers บนเมโมรีสเปซของ Dialog Work Process

จากนั้นระบบจะทำงานในคำสั่งถัดไป ในที่นี้คือ คำสั่ง Select single * from customers where id = 1 ซึ่งเป็นคำสั่งประเภท Data Logic ระบบจะแปลง Open SQL ให้เป็น Native SQL เพื่อส่งไปให้กับ Database Server ทำงานในส่วนของ Data Service ซึ่งก็คือการค้นหาข้อมูลในฐานข้อมูลตามที่ต้องการ จากนั้นก็จะคืนค่า (Return) ข้อมูลที่ต้องการกลับไปหาแอพพลิเคชันเซิร์ฟเวอร์

คำสั่งสุดท้ายคือ Write customers-name เป็นคำสั่งประเภท Presentation Logic ซึ่งใช้สำหรับการแสดงผลข้อมูล (ในที่นี้คือ customers-name) ด้วยการส่งต่อไปให้โปรแกรม SAPGUI

ระบบไคลเอ็นต์/เซิร์ฟเวอร์แบบทรีเทียร์

ภาพรวมของระบบ SAP R/3

จากตัวอย่างที่ผมกล่าวมานั้น จะเห็นได้ว่าการทำงานของโปรแกรม ztest แต่ละคำสั่ง จะถูกกระจายออกไปยังส่วนต่างๆ ตามประเภทของคำสั่งในโปรแกรม ztest ผมหวังว่าทุกท่านคงพอจะมองเห็นภาพการทำงานในแบบ 3 Tier Client/Server ของระบบ SAP R/3 บ้างไม่มากก็น้อย
ส่วนท่านใดที่อยากรู้รายละเอียดของการทำงานในระบบ SAP R/3 มากกว่านี้ ก็ขอแนะนำให้เตรียมอ่านหนังสือ SAP R/3: Basis Administration ที่ผมได้เขียนไว้โดยละเอียด ซึ่งหนังสือเล่มนี้คาดว่าคงจะปรากฏอยู่ในแผงหนังสือทั่วไปเร็วๆ นี้
สำหรับบทความในฉบับต่อไปนั้น เราจะเริ่มลุยการเขียนโปรแกรม ABAP กัน อดใจรอสักนิด อาจจะมีเซียน ABAP เกิดขึ้นในวงการอีกไม่มากก็น้อย ผมหวังไว้เช่นนั้นครับ