ปัจจุบันองค์กรต้องการโซลูชันที่สามารถพัฒนาและขยายขีดความสามารถได้อย่างรวดเร็ว โดย ABAP RESTful Application Programming Model (RAP) ได้กลายมาเป็นแนวทางสำคัญในการพัฒนาแอปพลิเคชันที่มีประสิทธิภาพ สำหรับ SAP S/4HANA และ SAP Business Technology Platform (SAP BTP) เพื่อสร้างบริการ OData Services ที่สามารถใช้บน SAP Fiori, SAP BTP และระบบอื่น ๆ ได้ อีกทั้ง SAP RAP มีโครงสร้างที่รองรับการทำงานของ Transaction, Analytical และ Searchable Services ที่มีประสิทธิภาพสูง และรองรับแนวทางของ SAP Clean Core เพื่อให้ระบบสามารถขยายและอัปเกรดได้ง่าย
ในบทความนี้ เราจะสำรวจว่าเหตุใด RAP จึงเป็นทางเลือกที่สำคัญสำหรับการพัฒนาแอปพลิเคชันด้วยภาษา ABAP และวิธีที่สามารถนำไปใช้ในการพัฒนาโซลูชันทางธุรกิจที่ทันสมัยได้อย่างมีประสิทธิภาพ
ทำไมต้องใช้ ABAP RESTful Application Programming Model (RAP)
ABAP RESTful Application Programming Model (RAP) เป็นแนวคิด เฟรมเวิร์ก และเครื่องมือสำหรับพัฒนาแอปพลิเคชันบนแพลตฟอร์ม ABAP ที่ทันสมัย รองรับการทำงานบน Cloud และ On-premise พร้อมความสามารถในการขยายและอัปเกรดได้ง่าย
RAP ช่วยยกระดับประสบการณ์ผู้ใช้และสร้างสรรค์กระบวนการธุรกิจใหม่ผ่าน SAP Fiori, SAP HANA และ Cloud เป็นโซลูชันเชิงกลยุทธ์ระยะยาวสำหรับการพัฒนา ABAP บนผลิตภัณฑ์หลักของ SAP อย่าง SAP S/4HANA ทั้งเวอร์ชัน Cloud และ On-premise ตั้งแต่เวอร์ชัน 1909 รวมถึงบน SAP BTP ABAP Environment
SAP นำ RAP มาใช้ในการพัฒนาแอปพลิเคชันมาตรฐานใหม่และปรับปรุงแอปพลิเคชันที่มีอยู่ให้ทันสมัย นอกจากนี้ SAP ยังแนะนำให้ลูกค้าและพันธมิตรใช้ RAP สำหรับการพัฒนาแบบกำหนดเอง (Customization) บน SAP S/4HANA และ SAP BTP ABAP Environment
RAP ใช้เทคโนโลยีและแนวคิดที่ทันสมัยและได้รับการพิสูจน์แล้ว ซึ่งรวมถึง
- Core Data Services (CDS) สำหรับกำหนดรูปแบบข้อมูลที่มีความหมายเชิงลึกสำหรับทุกโดเมนของแอปพลิเคชัน
- ภาษา ABAP ที่ได้รับการปรับปรุงและขยาย สำหรับการนำไปใช้กับตรรกะทางธุรกิจ
- โปรโตคอล OData สำหรับการสื่อสารแบบไร้สถานะ และ โปรโตคอล SAP Information Access (InA) สำหรับการเข้าถึงข้อมูลแบบเรียลไทม์
- แนวคิดของ Business Entities สำหรับการสร้างแอปพลิเคชันแบบธุรกรรม
- แนวคิด Draft ช่วยให้แอปพลิเคชันสามารถบันทึกข้อมูลแบบชั่วคราว (Stateful) บนเทคโนโลยีที่ออกแบบมาให้ไร้สถานะ (Stateless)
- แนวคิดของ Business Services สำหรับการสร้างบริการแบบ OData, InA และ SQL
RAP นำเสนอกระบวนการพัฒนาแบบมาตรฐานใน ABAP Development Tools ใน Eclipse (ADT) ที่ทันสมัย และชุดคุณสมบัติที่หลากหลายสำหรับการสร้างแอปพลิเคชันในโดเมนต่าง ๆ เช่น แอปธุรกรรมและการวิเคราะห์ ไม่ว่าจะเริ่มต้นจากศูนย์หรือนำโค้ดที่มีอยู่มาใช้ใหม่ โดยสามารถพัฒนาบริการและ API แบบโลคัลประเภทต่าง ๆ ด้วย RAP ดังนี้
- บริการ OData สำหรับการเผยแพร่เพื่อพัฒนา UI เพื่อสร้างแอป SAP Fiori ที่น่าประทับใจ มีบทบาทเฉพาะ ตอบสนองได้ดี และรองรับการร่าง
- บริการ OData สำหรับการเผยแพร่เป็น Web API
- บริการ InA สำหรับการวิเคราะห์ เพื่อสร้างแอปวิเคราะห์ใน SAP Analytics Cloud
- บริการ SQL สำหรับการรวมข้อมูล
- API แบบ Local มีความเสถียร ปลอดภัยต่อการอัปเกรด และสามารถให้บริการผ่านออบเจ็กต์ธุรกิจที่เผยแพร่แล้ว
ฟีเจอร์พื้นฐาน เช่น ABAP Unit Tests เครื่องมือ ABAP Cross Trace ถูกนำเสนอพร้อมกับ Development Stack ของ RAP เพื่อให้ครอบคลุมแนวคิดหลักด้านคุณภาพของซอฟต์แวร์ เช่น ความสามารถในการทดสอบ ความสามารถในการสนับสนุน เป็นต้น
นอกจากนี้โมเดลการเขียนโปรแกรมแบบเดิม เช่น ABAP Programming Model สำหรับ SAP Fiori, Classic Business Object Processing Framework (BOPF), Web Dynpro และ Dynpro ที่ได้ถูกพัฒนาไปถึงจุดสูงสุดแล้ว ทาง SAP เองจะยังคงสนับสนุนต่อไปในระบบแบบ On-premise แต่อย่างไรก็ตาม ทิศทางในอนาคตของ SAP เกี่ยวกับการพัฒนาแอปพลิเคชัน ABAP นั้นจะมุ่งเน้นไปที่ RAP อย่างชัดเจน อย่างการที่ RAP เป็นโมเดลการเขียนโปรแกรมที่ SAP แนะนำเป็นหลัก ใน SAP S/4HANA ตั้งแต่เวอร์ชั่น 2021 และ SAP BTP ABAP Environment นั่นเอง
การปรับใช้แบบ Greenfield และ Brownfield
หัวใจหลักของทุกแอปพลิเคชันอยู่ที่โมเดลข้อมูล ซึ่งประกอบด้วยคำอธิบายของเอนทิตี้ต่าง ๆ ที่เกี่ยวข้องกับสถานการณ์ทางธุรกิจ โมเดลข้อมูลสนับสนุนการเข้าถึงแบบธุรกรรมหรือการเข้าถึงแบบ Read-Only จะขึ้นอยู่กับกรณีการใช้งาน ดังนั้น โมเดลข้อมูลจึงถูกนำไปใช้ในทั้ง Business Objects หรือ Read-only Queries ใน RAP
RAP มีการใช้งานหลักๆ อยู่ด้วยกัน 2 รูปแบบ คือ Unmanaged และ Managed สำหรับสถานการณ์แบบอ่านอย่างเดียว (Read-Only) และแบบธุรกรรม (CRUD)
Unmanaged Business Object คือรูปแบบการพัฒนา Business Object (BO) ที่ผู้พัฒนาต้องจัดการการทำงานของ Business Logic และ Database Transactions ด้วยตัวเอง แทนที่ SAP RAP จะจัดการให้โดยอัตโนมัติ
ส่วน Managed Business Object เป็นแนวทางที่ SAP RAP จัดการการทำงานของ Business Logic และ Database Transactions ให้โดยอัตโนมัติ ซึ่งช่วยให้พัฒนาแอปพลิเคชันได้ง่ายและรวดเร็วขึ้น
ในสถานการณ์แบบอ่านอย่างเดียว พฤติกรรมของโมเดลข้อมูลถูกกำหนดโดยความสามารถในการค้นหา เช่น การกรองหรือลักษณะการวิเคราะห์ของข้อมูล การใช้งานแบบ Unmanaged Query ผู้พัฒนาต้องจัดการการดึงข้อมูลเองใน ABAP Class (ผ่าน Behavior Implementation) และการใช้งานแบบ Managed Query ถูกกำหนดด้วย CDS View โดยไม่ต้องเขียนโค้ด ABAP
ในสถานการณ์แบบธุรกรรม พฤติกรรมของออบเจ็กต์ธุรกิจ (BO) กำหนดว่าการดำเนินการใดและลักษณะใดเป็นของ Business Objects นั้น เพื่อกำหนดและใช้งานพฤติกรรมของ BO ซึ่งเป็นประเภทออบเจ็กต์ที่เก็บข้อมูลใหม่ของ ABAP Behavior Definition จึงได้ถูกนำมาใช้ และภาษา ABAP ได้ถูกขยายเพิ่มเติมเพื่อให้สามารถมี Entity Manipulation Language (EML) ได้
การใช้งาน BO แบบ Unmanaged คือ นักพัฒนาจะต้องรับผิดชอบในเรื่องของการจัดเตรียมการใช้งานรันไทม์ของ BO สำหรับการดึงข้อมูล ตรรกะทางธุรกิจ และการจัดเก็บข้อมูลทั้งหมด รวมถึงการจัดการธุรกรรมและการดำเนินการของ CRUD Operations เอง การใช้งานนี้มักใช้สำหรับการพัฒนาแอปพลิเคชันแบบ Brownfield ซึ่งช่วยให้สามารถนำโค้ดแบบกำหนดเองที่มีอยู่มาใช้ซ้ำได้ โดยในบางกรณี อาจต้องมีการจัดการล็อกข้อมูลและการบัฟเฟอร์เองตามความจำเป็น
การใช้งาน BO แบบ Managed นั้นถูกจัดการและควบคุมอย่างเต็มรูปแบบโดยเฟรมเวิร์ก RAP ซึ่งจัดการลักษณะเฉพาะทั้งหมดที่เกิดจากการสร้าง อ่าน อัปเดต และลบออกจากกล่อง โดยการใช้งานนี้ช่วยให้นักพัฒนาแอปพลิเคชันไม่ต้องทำงานซ้ำซ้อน เช่น การสร้างคำสั่ง SQL เพื่อดึงข้อมูลจากตารางฐานข้อมูล หรือในมุมของด้านเทคนิคการประมวลผลธุรกรรม ในสถานการณ์แบบธุรกรรม (Transactional Scenarios) นักพัฒนาจึงสามารถโฟกัสไปที่การดูแลตรรกะทางธุรกิจในแอปพลิเคชันเฉพาะต่างๆ ได้อย่างเต็มที่ ซึ่งการใช้งานนี้มักใช้สำหรับการพัฒนาแอปพลิเคชันแบบ Greenfield ที่นักพัฒนาเริ่มต้นจากศูนย์นั่นเอง
การใช้งาน BO แบบ Managed ยังมีรูปแบบต่างๆ ที่สามารถเลือกใช้ได้ในการใช้งานในหลากหลายธุรกรรมให้อีกด้วย เช่น การใช้งาน Managed BO ด้วย Unmanaged Save ซึ่งเป็นการผสมผสานระหว่างการใช้งาน BO แบบหลัก เพื่อจัดการกับสถานการณ์ที่ตรรกะทางธุรกิจแบบเดิมที่สามารถนำกลับมาใช้ใหม่ได้ (ฟังก์ชันโมดูลการอัปเดต) และถูกใช้เฉพาะสำหรับการจัดเก็บข้อมูลเท่านั้น หรือจะเป็นรูปแบบการใช้งาน Managed BO ด้วย Unmanaged Lock ซึ่งสามารถนำมาใช้งานในกรณีที่นักพัฒนาต้องการใช้งานตรรกะการล็อกของตนเองสำหรับ Managed BO เช่น เพื่อใช้ Lock Objects ที่มีอยู่แล้ว
นอกเหนือจากรูปแบบการใช้งานที่กล่าวมาข้างต้น SAP วางแผนที่จะเสนอรูปแบบการใช้งานใหม่ ที่เรียกว่า BOPF-managed BO สำหรับการย้ายและประยุกต์ใช้ BOPF BO ที่ใช้ CDS ซึ่งมาจาก ABAP Programming Model สำหรับ SAP Fiori เพิ่มเข้ามาในเฟรมเวิร์ก RAP ในอนาคตอันใกล้ โดยรูปแบบการใช้งานนี้จะถูกเสนอให้กับลูกค้าและพันธมิตรที่ได้สร้างแอปพลิเคชันด้วย ABAP Programming Model สำหรับ SAP Fiori และต้องการรักษาการลงทุนของตนเองแต่ยังคงอยากได้ประโยชน์ที่ RAP มีให้ อย่างไรก็ตาม การย้าย BOPF BO ที่ใช้ CDS ที่มีอยู่แล้วหรือถูกสร้างขึ้นมาใหม่จะไม่ใช่ข้อบังคับทางเทคนิคเมื่ออัปเกรดเป็น SAP S/4HANA เวอร์ชันล่าสุด เนื่องจาก ABAP Programming Model สำหรับ SAP Fiori ยังคงได้รับการสนับสนุนต่อในอนาคต แต่ BOPF แบบคลาสสิกจะไม่ได้รับการสนับสนุนโดยรูปแบบการใช้งานนี้
คุณควรใช้ RAP เมื่อไรและในรูปแบบไหน
เมื่อเข้าใจประโยชน์และประเภทการใช้งานของ RAP แล้ว ขั้นตอนต่อไปคือการเรียนรู้ว่าควรใช้แบบไหน เมื่อไหร่ ซึ่งปัจจัยทางธุรกิจที่สำคัญที่สุดที่นำไปสู่การตัดสินใจพัฒนาแบบกำหนดเองด้วย RAP คือ ประสบการณ์ผู้ใช้ (UX) นวัตกรรม SAP HANA และ Cloud
ความต้องการหลักของลูกค้าและพันธมิตร คือ
- คุณต้องการเพิ่มการยอมรับใน UI ของผู้ใช้ปลายทาง (End User) ของคุณโดยใช้แอป SAP Fiori ที่สามารถเปิดใช้งานการร่าง กำหนดบทบาทผู้ใช้งาน ตอบสนองได้บนทุกอุปกรณ์ หน้าตาแอปสวยงาม และปรับขยายการใช้งานได้
- คุณต้องการเปลี่ยนแปลงแอปพลิเคชันแบบกำหนดเอง (Customization) ของคุณบางส่วนหรือทั้งหมดจาก On-premise ไปยัง Cloud ในตอนนี้หรือในอนาคต และต้องการเตรียมพร้อมสำหรับการเปลี่ยนแปลงนั้น
- คุณต้องการขับเคลื่อนนวัตกรรมในกระบวนการทางธุรกิจของคุณโดยใช้ประโยชน์จากความสามารถของ SAP HANA เช่น การประมวลผลที่มีประสิทธิภาพสูงสำหรับการโต้ตอบและกระบวนการประเภทใหม่ๆ การทำเหมืองข้อมูล (Data Mining) และการวิเคราะห์เชิงคาดการณ์
โดยไม่ว่าจะเป็นธุรกรรมแบบใดก็ตาม งานหลักก็คือการสร้าง RAP Business Objects เพื่อให้เห็นถึงข้อมูลและฟังก์ชันการทำงานที่ต้องการ โดยทางเลือกของการใช้ประเภท BO Runtime ที่ถูกต้องที่สุดจะขึ้นอยู่กับความพร้อมใช้งานของโค้ดกำหนดเองที่สามารถนำกลับมาใช้ใหม่ได้
ตัวอย่างสถานการณ์ต่างๆ ของการใช้งาน RAP
สถานการณ์ 1 – ไม่มีโค้ดกำหนดเอง
หากคุณต้องการสร้างแอปพลิเคชันแบบกำหนดเองใหม่ ส่วนขยายที่ครอบคลุม (Rich Extension) หรือ API โดยเริ่มใหม่จากศูนย์ ซึ่งก็คือที่เราเรียกว่า Greenfield Implementation
คำแนะนำ คือ คุณควรใช้ Managed BO Implementation ซึ่ง โครงสร้างพื้นฐานของแอปพลิเคชัน RAP จะสามารถให้การสนับสนุนสูงสุดแก่ผู้พัฒนาในการนำไปใช้งานในลักษณะนี้ได้
สถานการณ์ 2 – โค้ดกำหนดเองที่มีความสัมพันธ์แน่นหนา
เมื่อคุณต้องการปรับปรุงให้แอปพลิเคชันและ API ที่มีอยู่ทันสมัยมากขึ้น ด้วยการใช้งานตรรกะทางธุรกิจแบบกำหนดขึ้นเองจากแอปพลิเคชันต่างๆ ที่มีอยู่แล้ว แต่เจออุปสรรคเนื่องจากโค้ดปัจจุบันมีความสัมพันธ์แบบแน่นหนามากกับด้านเทคนิค เช่น เทคโนโลยี UI และโปรโตคอล ซึ่งไม่มีโครงสร้างและยากต่อการบำรุงรักษา ดังนั้นยิ่งทำให้ยากต่อการนำมาใช้ใหม่ หรือนำมาสร้างแอปพลิเคชันใหม่ด้วยการใช้ RAP
ตัวอย่างที่พบได้บ่อยเมื่อเป็นแอปพลิเคชันที่มีอยู่แล้ว คือ
- แอปที่ใช้ Dynpro หรือ Web Dynpro ที่ตรรกะธุรกิจและตรรกะ UI มีความสัมพันธ์กันอย่างแน่นหนา
- การนำไปใช้งานแบบโค้ดของบริการ OData ที่สร้างขึ้นโดยไม่ใช้ CDS ใน SAP Gateway Service Builder (SEGW) โดยใช้คลาส Model Provider (MPC_EXT) และ Data Provider (DPC_EXT)
คำแนะนำ คือ อย่างน้อยที่สุด หากโค้ดแบบกำหนดเองที่มีอยู่แล้วสำหรับงานอัปเดตสามารถนำมาแยกส่วน และใช้งานซ้ำได้ การใช้งานแบบ Managed BO กับ Unmanaged Save จะเป็นทางออกในกรณีนี้ เพราะการใช้งานประเภทนี้จะสามารถทำให้ส่วนใหญ่ของ BO Runtime สามารถจัดการได้ด้วย เฟรมเวิร์ก RAP และให้นักพัฒนาดูแลเพียงส่วนของการบันทึกการทำงานเท่านั้น ซึ่งกรณีนี้ ต้องมั่นใจถึงความสอดคล้องของข้อมูลด้วยการตรวจสอบและการกำหนดต่างๆ ที่เหมาะสม
หากไม่สามารถนำโค้ดกำหนดเองที่มีอยู่กลับมาใช้ใหม่ได้ คุณสามารถเริ่มต้นจากศูนย์โดยใช้ Managed BO Implementation
หากจำเป็นต้องใช้เอนทิตี้แบบกำหนดเองของ CDS แทน CDS Views สำหรับการดึงข้อมูล การใช้ Unmanaged BO Implementation โดยไม่มีการร่างเป็นเพียงตัวเลือกเดียวที่เป็นไปได้
สถานการณ์ 3 – โค้ดกำหนดเองที่แยกอิสระและสามารถนำกลับมาใช้ใหม่ได้
ครั้งนี้ เมื่อคุณต้องการปรับปรุงและทำให้แอปพลิเคชันที่มีอยู่ทันสมัยยิ่งขึ้น แล้วโชคดีที่ตรรกะทางธุรกิจที่มีอยู่นั้นแยกอิสระจากด้านเทคนิค เช่น เทคโนโลยี UI และ โปรโตคอล นอกจากนี้ยังถูกแบ่งเป็นโมดูลอย่างดี และสามารถนำมาใช้ซ้ำสำหรับการโต้ตอบในช่วงต่างๆ และลำดับการบันทึกของ Business Object Runtime สำหรับการสสร้างแอปพลิเคชันใหม่ด้วย RAP
ตัวอย่างที่พบได้บ่อยของโค้ดที่แยกอิสระและสามารถนำกลับมาใช้ใหม่ได้
- แอปพลิเคชันที่สร้างขึ้นด้วยเฟรมเวิร์ก BOPF แบบคลาสสิก
- ฟังก์ชันโมดูล BAPI หรือ API แบบกำหนดเองเชิงวัตถุอื่นๆ ที่ไม่ดำเนินการ COMMIT เมื่อถูกเรียกใช้ หรือ Wrapper
คำแนะนำ คือ ขึ้นอยู่กับโค้ดแบบกำหนดเองที่สามารถนำมาใช้ใหม่ได้ที่มีอยู่แล้ว จะแนะนำให้ใช้ Unmanaged BO Implementation หรือ Managed BO ด้วย Unmanaged Save Implementation
หากมี API สำหรับการดำเนินการ CRUD ต่างๆ เช่น สร้าง อ่าน อัปเดต และลบ ที่สามารถเรียกใช้แยกกันได้ และหาก API เหล่านี้มีบัฟเฟอร์ธุรกรรม แนะนำให้ใช Unmanaged BO Implementation
หากสามารถนำฟังก์ชันโมดูลการอัปเดตกลับมาใช้ใหม่ได้เท่านั้น แนะนำให้ใช้ Managed BO ด้วย Unmanaged Save Implementation แต่ในกรณีนี้ ต้องมั่นใจถึงความสอดคล้องของข้อมูลด้วยการตรวจสอบและการกำหนดที่เหมาะสม
หากใช้เอนทิตี้แบบกำหนดเองของ CDS การใช้งาน Unmanaged BO Implementation โดยไม่มีการร่างเป็นตัวเลือกเดียวที่เป็นไปได้
สถานการณ์ 4 – เมื่อมีโค้ดกำหนดเองที่สร้างขึ้นจาก ABAP Programming Model สำหรับ SAP Fiori
เมื่อคุณต้องการปรับปรุงแอปพลิเคชันที่สร้างขึ้นด้วย ABAP Programming Model สำหรับ SAP Fiori เพื่อเข้าถึงประโยชน์ของ RAP โดยการนำ BO ของ BOPF ที่สร้างขึ้นโดย CDS และตรรกะธุรกิจที่นำไปใช้งานกลับมาใช้ใหม่
วิธีที่แนะนำสำหรับสถานการณ์ดังกล่าวคือ การใช้งาน BO แบบจัดการโดย BOPF สำหรับ BO ของ BOPF ที่ใช้ CDS ซึ่ง SAP วางแผนที่จะส่งมอบในอนาคตอันใกล้
สถานการณ์ 5 – อย่าเปลี่ยนทีมที่ชนะ (ไม่ใช้ RAP)
หากคุณต้องการสร้างแอปพลิเคชันใหม่ที่จะเป็นส่วนหนึ่งของชุดแอปพลิเคชันที่มีอยู่ กล่าวคือ คุณต้องการสร้างแอปตัวที่ 101 โดยที่ไม่มีข้อกำหนดเฉพาะของ RAP เช่น ความพร้อมใช้งานบน Cloud หรือ UI ของ SAP Fiori ที่เปิดใช้งานการร่าง
คำแนะนำสำหรับสถานการณ์ดังกล่าวคือ คุณควรใช้เทคโนโลยีเดียวกับชุดแอปพลิเคชันที่เกี่ยวข้องสำหรับการสร้างแอปพลิเคชันใหม่ เว้นแต่คุณต้องการใช้คุณสมบัติ ABAP ล่าสุด
สรุป
โมเดลการเขียนโปรแกรมแอปพลิเคชันแบบ RESTful ของ ABAP (RAP) เป็นสถาปัตยกรรมแบบครบวงจร เพื่อการพัฒนาที่รวดเร็วและพร้อมใช้งานบน Cloud มีความทันสมัยของบริการระดับองค์กร รวมถึงการต่อยอดจากแอปพลิเคชัน SAP แบบพื้นฐานทั้งบน Cloud และ On-premise
ไม่ว่าคุณจะเริ่มต้นจากศูนย์หรือใช้ตรรกะธุรกิจที่มีอยู่อยู่แล้ว RAP สามารถใช้บนแพลตฟอร์ม ABAP เพื่อสร้างแอปพลิเคชันสำหรับโดเมนแอปพลิเคชันต่างๆ เช่น ธุรกรรมและการวิเคราะห์ ทั้งบน Cloud และ On-premise
SAP มีแผนที่จะส่งมอบตัวเลือกการปรับแต่งขั้นสูงแบบ Built-in สำหรับโมเดลข้อมูล พฤติกรรมของ Business Objects โหนดของ Business Object และบริการทางธุรกิจ พร้อมกับการเปิดตัว On-premise และ Cloud ในอนาคต นอกจากนี้ยังมีแผนที่จะลดต้นทุนการพัฒนาในภาพรวม (TCD) โดยการสนับสนุนการกระยุต์ใช้อย่างไร้รอยต่อขององค์ประกอบต่างๆที่สามารถนำมาใช้ซ้ำได้ ตั้งแต่เหตุการณ์ทางธุรกิจ บันทึกต่างๆ และเอกสารการเปลี่ยนแปลง
หากการพัฒนาระบบ SAP แบบ RAP ยังใหม่สำหรับองค์กรของคุณ หรือต้องการที่ปรึกษาที่เชี่ยวชาญและไว้ใจได้ในด้าน ABAP สามารถขอคำปรึกษาได้เลยกับ ZyGen ทีมงานของเราพร้อมสนับสนุนคุณอย่างเต็มที่
Author: Chayanon T.
References:
– Technology Blogs by SAP
– ABAP RESTful Application Programming Model
