SAP R / 3 Archiเทคเจอร์
⚡ สรุปอย่างชาญฉลาด
SAP R / 3 Archiสถาปัตยกรรมนี้เป็นการออกแบบไคลเอ็นต์-เซิร์ฟเวอร์แบบสามระดับที่แยกความรับผิดชอบด้านการนำเสนอ แอปพลิเคชัน และฐานข้อมูล บทความนี้จะอธิบายแต่ละระดับ รวมถึง ABAP และ Java ส่วนประกอบต่างๆ กระบวนการล็อกอินที่ขับเคลื่อนโดยตัวจัดการ และเหตุผลต่างๆ SAP เลือกใช้โมเดลแบบหลายชั้นนี้

SAP R / 3 Archiสถาปัตยกรรมเป็นรากฐานสำคัญของสิ่งคลาสสิกเกือบทุกอย่าง SAP การติดตั้งระบบ ERP ส่วนด้านล่างจะอธิบายถึงวิธีการทำงานร่วมกันของทั้งสามระดับ และวิธีการทำงานของ ABAP และ Java โครงสร้างข้อมูลแบบ Stack จะแบ่งงานระหว่าง Dispatcher, Message Server และ Database
ความหมายของ SAP ร/3?
SAP R/3 เป็นระบบองค์กรแบบไคลเอ็นต์-เซิร์ฟเวอร์ที่สร้างขึ้นบน สถาปัตยกรรมสามชั้น ประกอบด้วยสามชั้นอิสระ:
- การเสนอ
- การใช้งาน
- ฐานข้อมูล
- R ย่อมาจาก เรียลไทม์ การประมวลผล
- 3 ย่อมาจาก 3 ชั้น รูปแบบทางสถาปัตยกรรม
คอมพิวเตอร์ของผู้ใช้ (ส่วนหน้า): ผู้ใช้เข้าถึง SAP ระบบผ่าน SAP อินเทอร์เฟซผู้ใช้แบบกราฟิก (GUI) หรือเว็บเบราว์เซอร์ โดยจะติดตั้งเฉพาะส่วนหน้า (front-end) ของโปรแกรมเท่านั้นบนเครื่องของผู้ใช้ ส่วนเซิร์ฟเวอร์แอปพลิเคชันและฐานข้อมูลจะทำงานแยกต่างหากบนฮาร์ดแวร์เฉพาะ
เซิร์ฟเวอร์แอปพลิเคชัน: เซิร์ฟเวอร์แอปพลิเคชันทำหน้าที่ประมวลผลตรรกะทางธุรกิจ โดยจะกระจายภาระงานไปยังเซิร์ฟเวอร์แอปพลิเคชันหลายเครื่อง เพื่อให้ผู้ใช้ได้รับผลตอบรับที่เร็วขึ้นภายใต้ภาระงานหนัก เซิร์ฟเวอร์เหล่านี้มักทำงานบนโครงสร้างพื้นฐานระยะไกล แทนที่จะทำงานบนเวิร์กสเตชันของผู้ใช้
เซิร์ฟเวอร์ฐานข้อมูล: เซิร์ฟเวอร์ฐานข้อมูลจัดเก็บและเรียกใช้ข้อมูลตามการตอบสนองต่อ SQL ข้อความค้นหาที่สร้างโดย ABAP และ Java แอปพลิเคชันต่างๆ ฐานข้อมูลและบริการแอปพลิเคชันอาจทำงานบนเครื่องเดียวกันหรือบนโฮสต์ทางกายภาพที่แยกจากกัน ขึ้นอยู่กับความต้องการด้านความจุ
ทำไม SAP R/3 ใช้สถาปัตยกรรมแบบ 3 ระดับใช่หรือไม่?
การแยกส่วนการนำเสนอ ตรรกะทางธุรกิจ และการจัดเก็บข้อมูลออกเป็นสามระดับอิสระทำให้ SAP R/3 มีข้อดีในทางปฏิบัติสี่ประการเหนือกว่าการออกแบบแบบชั้นเดียวหรือสองชั้น:
- ความสามารถในการปรับขนาดอย่างอิสระ: แต่ละเลเยอร์สามารถปรับขนาดแยกกันได้ ปัญหาคอขวดในตรรกะทางธุรกิจจะได้รับการแก้ไขโดยการเพิ่มเซิร์ฟเวอร์แอปพลิเคชันโดยไม่ต้องแตะต้องฮาร์ดแวร์ฐานข้อมูล
- การกระจายภาระงาน: เซิร์ฟเวอร์รับส่งข้อความจะกระจายภาระงานของเซสชันขาเข้าไปยังเซิร์ฟเวอร์แอปพลิเคชันต่างๆ เพื่อป้องกันไม่ให้เซิร์ฟเวอร์ใดเซิร์ฟเวอร์หนึ่งกลายเป็นจุดศูนย์กลางของการแย่งชิงทรัพยากร
- การปกป้องฐานข้อมูล: ผู้ใช้ปลายทางจะไม่เชื่อมต่อกับฐานข้อมูลโดยตรง การดำเนินการอ่านและเขียนทั้งหมดจะไหลผ่านกระบวนการทำงานของเซิร์ฟเวอร์แอปพลิเคชัน ซึ่งจะกำหนดมาตรฐานการตรวจสอบสิทธิ์ การล็อก และการบันทึกธุรกรรม
- Upgrade ความยืดหยุ่น: การขอ SAP ส่วนหน้า GUI สามารถพัฒนาได้ (สำหรับเดสก์ท็อป เว็บเบราว์เซอร์ หรืออุปกรณ์เคลื่อนที่) ผ่านทาง SAPUI5) โดยไม่ต้องแก้ไขโค้ดแอปพลิเคชันหรือฐานข้อมูล
การแยกนี้เองที่ทำให้สามารถเกิดขึ้นได้ SAP เพื่อรองรับระบบฐานข้อมูลหลายประเภท รวมถึง SAP HANA, Oracle, IBM ดีบี2 และ Microsoft SQL Server — โดยใช้ฐานรหัสแอปพลิเคชันเดียวกัน
SAP R/2 เทียบกับ SAP R/3: อย่างไร Archiวิวัฒนาการของสถาปัตยกรรม
SAP R/2 ทำงานบนเมนเฟรมและใช้สถาปัตยกรรมแบบสองระดับ โดยที่เทอร์มินัลของผู้ใช้สื่อสารโดยตรงกับฐานข้อมูล R/3 ซึ่งเปิดตัวในปี 1992 ได้เพิ่มเลเยอร์แอปพลิเคชันเฉพาะระหว่างไคลเอ็นต์และฐานข้อมูล ทั้งสองระบบแสดงอยู่เคียงข้างกัน:
| แง่มุม | SAP R / 2 | SAP R / 3 |
|---|---|---|
| Archiเทคเจอร์ | ระบบ 2 ระดับ (เมนเฟรม + เทอร์มินัล) | โครงสร้าง 3 ระดับ (การนำเสนอ + แอปพลิเคชัน + ฐานข้อมูล) |
| ฮาร์ดแวร์ | เมนเฟรมส่วนกลาง | ดิสทริบิวเต็ด ยูนิกซ์ / Windows เซิร์ฟเวอร์ Linux |
| scalability | เฉพาะแนวตั้ง (เมนเฟรมขนาดใหญ่กว่า) | แนวนอน (เพิ่มเซิร์ฟเวอร์แอปพลิเคชัน) |
| การเข้าถึงฐานข้อมูล | โดยตรงจากเซสชันของผู้ใช้ | ดำเนินการโดยกระบวนการทำงานของเซิร์ฟเวอร์แอปพลิเคชัน |
| แบบจำลองการเขียนโปรแกรม | ABAP/4 เท่านั้น | เอบีเอพีและ Java เคียงบ่าเคียงไหล่ |
ส่วนที่เหลือจะอธิบายรายละเอียดของแต่ละชั้น R/3 ทั้งสามชั้นอย่างละเอียด
เข้าใจความแตกต่าง SAP ชั้น
รูปที่ 1: ทั้งสาม SAP เลเยอร์ R/3 และปริมาณการรับส่งข้อมูลที่ไหลเวียนระหว่างเลเยอร์เหล่านั้น
เลเยอร์การนำเสนอ
การขอ เลเยอร์การนำเสนอ มีส่วนประกอบซอฟต์แวร์ที่ประกอบเป็น SAP GUI — ส่วนหน้าแบบกราฟิกของระบบ R/3 เป็นส่วนติดต่อระหว่างระบบกับผู้ใช้ โดยมีรูปแบบที่ใช้งานง่ายสำหรับการป้อนและแสดงข้อมูล
เลเยอร์นี้ส่งต่อข้อมูลที่ผู้ใช้ป้อนไปยังเซิร์ฟเวอร์แอปพลิเคชัน และแสดงผลข้อมูลที่ได้รับกลับมา ในขณะที่ SAP เมื่อ GUI ทำงานอยู่ GUI จะยังคงเชื่อมต่อกับเซสชันเทอร์มินัลของผู้ใช้ในระบบ R/3 ตลอดระยะเวลาของเซสชันนั้น
Application Layer
การขอ Application Layer ประกอบด้วยเซิร์ฟเวอร์แอปพลิเคชันหนึ่งตัวหรือมากกว่า และ เซิร์ฟเวอร์ข้อความเซิร์ฟเวอร์แอปพลิเคชันแต่ละตัวจะรันชุดบริการที่ประมวลผลตรรกะทางธุรกิจของ R/3 ในทางทฤษฎีแล้ว เซิร์ฟเวอร์แอปพลิเคชันเพียงตัวเดียวก็เพียงพอ แต่ในทางปฏิบัติ บริการต่างๆ จะถูกกระจายไปยังเซิร์ฟเวอร์หลายตัวเพื่อเพิ่มขีดความสามารถและความซ้ำซ้อน
เซิร์ฟเวอร์รับส่งข้อความทำหน้าที่ประสานงานการสื่อสารระหว่างเซิร์ฟเวอร์แอปพลิเคชัน โดยจะส่งต่อคำขอต่างๆ tracks จัดกลุ่มเซิร์ฟเวอร์แอปพลิเคชันและกำหนดเซิร์ฟเวอร์ที่เหมาะสมเมื่อผู้ใช้ล็อกอินโดยพิจารณาจากปริมาณงานในปัจจุบัน นี่คือสิ่งที่ทำให้การขยายขนาดในแนวนอนเป็นไปได้
ชั้นฐานข้อมูล
การขอ ชั้นฐานข้อมูล เป็นที่ตั้งของระบบฐานข้อมูลส่วนกลางที่จัดเก็บข้อมูลทั้งหมดที่ระบบ R/3 ใช้ โครงสร้างฐานข้อมูลประกอบด้วยสองส่วน คือ ระบบจัดการฐานข้อมูล (DBMS) และตัวฐานข้อมูลเอง SAP จัดส่งระบบจัดการฐานข้อมูล (DBMS) ของตนเอง SAP HANAและยังรองรับฐานข้อมูลเชิงพาณิชย์หลักทุกฐานอีกด้วย (Oracle, IBM ดีบี2, Microsoft SQL Server).
ข้อมูล R/3 ทั้งหมด ไม่ว่าจะเป็นการตั้งค่า การเขียนโค้ดแอปพลิเคชัน คำจำกัดความหน้าจอ เมนู โมดูลฟังก์ชัน และข้อมูลรันไทม์ ล้วนอยู่ในฐานข้อมูลนี้ ส่วนโค้ดโปรแกรมและวัตถุการออกแบบจะอยู่ในส่วนพิเศษที่เรียกว่า... คลังเก็บข้อมูล R/3อ็อบเจ็กต์ในที่เก็บข้อมูลเหล่านี้คือสิ่งที่ ABAP Workbench อ่าน เขียน และส่งต่อระหว่างระบบต่างๆ
ทำความเข้าใจส่วนประกอบของ SAP R/3 3 ชั้น Archiเทคเจอร์
รูปที่ 2: ABAP + Java สถาปัตยกรรมระบบที่แสดงให้เห็นว่าทั้งสองส่วนใช้โครงสร้างพื้นฐานร่วมกันอย่างไร
ความทันสมัย SAP อินสแตนซ์ NetWeaver สามารถรองรับทั้ง ABAP และ Java ส่วนประกอบด้านล่างแสดงให้เห็นว่าแต่ละสแต็กจัดการการส่งต่อข้อมูลของตนเองอย่างไร ในขณะที่ใช้เกตเวย์ ICM และบริดจ์ JCO ร่วมกันสำหรับการสื่อสารข้ามสแต็ก
| ตัวแทน | กอง | บทบาท |
|---|---|---|
| เซิร์ฟเวอร์ข้อความ (ABAP) | ABAP | ประสานงานการสื่อสารระหว่างตัวจัดการการกระจายสัญญาณแบบกระจายในระบบ ระบบเอบีเอพี และกระจายภาระงานไปยังอินสแตนซ์ต่างๆ อย่างสมดุล |
| คิวผู้จัดส่ง | ABAP | Buffer ซึ่งจะระงับคำขอที่เข้ามาจนกว่ากระบวนการทำงานจะว่างลง |
| รีบ | ABAP | ดึงคำขอจากคิวและกำหนดแต่ละคำขอให้กับประเภทกระบวนการทำงานที่เหมาะสม |
| กระบวนการทำงานของ ABAP | ABAP | ดำเนินการขั้นตอนการสนทนาในแอปพลิเคชัน R/3 ประเภทต่างๆ ได้แก่ การสนทนา การอัปเดต การทำงานเบื้องหลัง การจัดคิว และการจัดลำดับ |
| ประตู | ที่ใช้ร่วมกัน | ช่วยให้สามารถสื่อสารระหว่างกันได้ SAP ระบบและระหว่างกัน SAP และระบบภายนอกผ่านทาง RFC |
| ท่อหน่วยความจำ | ที่ใช้ร่วมกัน | ส่งข้อมูลระหว่าง Internet Communication Manager (ICM) และกระบวนการทำงานของ ABAP |
| เซิร์ฟเวอร์ข้อความ (Java) | Java | พิกัด Java ตัวจัดการการส่งและกระบวนการเซิร์ฟเวอร์ ช่วยให้สามารถสื่อสารภายในได้ Java คลัสเตอร์รันไทม์ |
| เซิร์ฟเวอร์จัดคิว | Java | จัดการการล็อกเชิงตรรกะที่ตั้งค่าโดย Java โค้ดแอปพลิเคชันทำงานอยู่ภายในกระบวนการของเซิร์ฟเวอร์ |
| บริการจากส่วนกลาง | Java | พิเศษ Java อินสแตนซ์คลัสเตอร์ที่จัดการการล็อกและการส่งข้อความระหว่างกระบวนการ “อินสแตนซ์” คือกลุ่มของทรัพยากร (หน่วยความจำ กระบวนการทำงาน ฯลฯ) |
| Java รีบ | Java | รับคำขอจากลูกค้าและส่งต่อไปยัง... Java กระบวนการของเซิร์ฟเวอร์ |
| SDM | Java | ตัวจัดการการปรับใช้ซอฟต์แวร์ — ติดตั้งส่วนประกอบ J2EE ลงบนระบบ Java กอง |
| Java กระบวนการเซิร์ฟเวอร์ | Java | ประมวลผลคำขอจำนวนมากพร้อมกันโดยใช้มัลติเธรดดิ้ง |
| ICM | ที่ใช้ร่วมกัน | ตัวจัดการการสื่อสารทางอินเทอร์เน็ต — ช่วยให้สามารถรับส่งข้อมูลผ่าน HTTP, HTTPS และ SMTP ได้ SAP สามารถเข้าถึงได้ผ่านทางเว็บเบราว์เซอร์ |
| JCO | สะพาน | Java ตัวเชื่อมต่อ — ทำหน้าที่จัดการการสื่อสารระหว่าง Java ตัวจัดการการส่งคำสั่งและตัวจัดการการส่งคำสั่ง ABAP เมื่อทั้งสองสแต็กทำงานควบคู่กันไป |
รูปที่ 3: ประเภทของกระบวนการทำงานของ ABAP (Dialog, Update, Background, Spool, Enqueue)
วิธี SAP กระบวนการเข้าสู่ระบบใช้งานได้หรือไม่
รูปที่ 4: ขั้นตอนการเข้าสู่ระบบของผู้ใช้ทีละขั้นตอน SAP ระบบ R/3 ประกอบด้วยเลเยอร์การจัดการงานและกระบวนการทำงาน
ขั้นตอน 1) ผู้ใช้คลิก SAP ระบบจาก SAP GUI; คำขอจะถูกส่งต่อไปยัง ผู้จัดส่ง.
ขั้นตอน 2) คำขอจะถูกส่งไปยัง คิวคำขอเจ้าหน้าที่ควบคุมการจราจรปฏิบัติตาม เข้าก่อนออกก่อน กำหนดกฎและมอบหมายคำขอให้กับกระบวนการทำงานที่ว่างอยู่ถัดไป
ขั้นตอน 3) กระบวนการทำงานที่เหมาะสมจะถูกกำหนดขึ้น ผู้ใช้ที่ล็อกอินจะได้รับกระบวนการทำงานแบบ Dialog รายงานที่ทำงานเบื้องหลังจะได้รับกระบวนการทำงานแบบ Background และคำสั่ง UPDATE จะถูกส่งไปยังกระบวนการทำงานแบบ Update การกระทำจะเป็นตัวกำหนดประเภทของกระบวนการทำงาน
ขั้นตอน 4) เมื่อกำหนดกระบวนการทำงาน Dialog แล้ว สิทธิ์การใช้งานและการตั้งค่าปัจจุบันของผู้ใช้จะถูกกำหนดโดยอัตโนมัติ กลิ้งเข้ามา ไปยังหน่วยความจำที่ใช้ร่วมกันเพื่อให้กระบวนการทำงานสามารถดำเนินการกับข้อมูลของผู้ใช้ได้ เมื่อขั้นตอนการสนทนาเสร็จสิ้น ข้อมูลนั้นจะถูกส่งต่อไป รีดออก เพื่อเพิ่มพื้นที่ว่างในหน่วยความจำสำหรับผู้ใช้รายถัดไป “ขั้นตอนการสนทนา” คือการเปลี่ยนจากหน้าจอหนึ่งไปยังอีกหน้าจอหนึ่งภายในธุรกรรม
ขั้นตอน 5) ขั้นตอนการทำงานจะค้นหาข้อมูลที่ร้องขอในบัฟเฟอร์ก่อน การค้นพบข้อมูลในนั้นเรียกว่า... ตี และหลีกเลี่ยงการเรียกใช้ฐานข้อมูลไปกลับ ซึ่งช่วยปรับปรุงเวลาตอบสนอง การหาไม่พบจะทำให้เกิดข้อผิดพลาด พลาด และการอ่านฐานข้อมูล อัตราส่วนความถูกต้องต่อการผิดพลาดที่สูงเป็นปัจจัยสำคัญที่สุดที่ส่งผลต่อ SAP การปฏิบัติ
ขั้นตอน 6) ข้อมูลที่เหลือจะถูกดึงมาจากฐานข้อมูล และผลลัพธ์ที่รวมกันแล้วจะถูกส่งกลับไปยังระบบ SAP GUI ผ่านทางตัวจัดการการส่งคำสั่ง
ขั้นตอน 7) ข้อมูลเซสชันของผู้ใช้จะถูกลบออกจากหน่วยความจำที่ใช้ร่วมกันในขั้นตอนสุดท้าย เปิดตัวเพื่อปล่อยพื้นที่หน่วยความจำสำหรับคำขอถัดไป
วงจรการส่งต่อ → คิว → กระบวนการทำงาน → บัฟเฟอร์ → การเผยแพร่ จะเกิดขึ้นซ้ำๆ สำหรับทุกการโต้ตอบของผู้ใช้ ไม่ว่าคำขอจะมาจากแหล่งใดก็ตาม SAP GUI, เว็บเบราว์เซอร์ผ่าน ICM หรือระบบภายนอกผ่านเกตเวย์





