ABAP บน Maguyva: กราฟคลาสสำหรับโค้ด SAP ที่พัฒนาเอง

ทำไมควรทำแผนที่ ABAP ก่อนแก้ไข

ABAP ที่พัฒนาเองมักบรรจุกฎทางธุรกิจที่สะสมมาหลายสิบปี โค้ดบางส่วนเป็นเชิงวัตถุ บางส่วนเป็นเชิงกระบวนการ และโครงสร้างการสืบทอดกับอินเทอร์เฟซเป็นตัวตัดสินว่าเมธอดใดจะทำงาน สิ่งนี้มองไม่เห็นเมื่ออ่านทีละคลาส

Maguyva ให้กราฟคลาสกับเอเจนต์ก่อน เพื่อให้แผนการเปลี่ยนแปลงเริ่มจากสิ่งที่พึ่งพาคลาสนั้น ไม่ใช่จากการเดา

Maguyva ดึงอะไรจาก ABAP ได้บ้าง

Maguyva แยกวิเคราะห์ซอร์ส .abap ด้วยไวยากรณ์เฉพาะของ ABAP สัญลักษณ์ครอบคลุมนิยามและการอิมพลีเมนต์คลาส อินเทอร์เฟซ การประกาศและการอิมพลีเมนต์เมธอด และรูทีน FORM

กราฟบันทึกความสัมพันธ์ที่นักพัฒนา ABAP ให้ความสำคัญ:

• การสืบทอดจาก CLASS ... INHERITING FROM
• การอิมพลีเมนต์อินเทอร์เฟซจาก INTERFACES
• การ override จาก METHODS ... REDEFINITION
• เอกซ์เซปชันจาก RAISE EXCEPTION และ CATCH
• การเรียกเมธอด (obj->m( ), cls=>m( ), CALL METHOD) การอ้างอิงชนิดข้อมูลจาก TYPE และ TYPE REF TO และการ export เมธอดในส่วนสาธารณะ ซึ่งระบุว่าเป็นของคลาสนั้น
• การอ่าน การเขียน และโฟลว์การควบคุม (IF, CASE, LOOP, TRY) ภายในตัวเมธอด

ตัวอย่างพรอมต์สำหรับเอเจนต์

• “คลาสใดสืบทอดจาก zcl_order_base และนิยามเมธอดใดใหม่บ้าง” (find_symbol แล้วตามด้วย dependency_search ทิศทางขาเข้า)
• “zcx_pricing_error ถูกโยนที่ใด และใครเป็นผู้ catch” (dependency_search)
• “สรุปว่าโฟลว์การสร้างการส่งมอบเดินจากรีพอร์ตไปยังคลาสจัดเก็บข้อมูลอย่างไร” (get_task_context)

ข้อจำกัดที่ทราบ

• ไวยากรณ์ ABAP ปัจจุบันไม่แยกวิเคราะห์ Open SQL (SELECT ... FROM ... INTO), EXEC SQL และ AUTHORITY-CHECK การอ่านตารางผ่าน SQL จึงยังไม่เป็นเส้นเชื่อมในกราฟ ใช้ text_pattern_search สำหรับชื่อตาราง
• คำสั่ง INTERFACES เป็นความสัมพันธ์การอิมพลีเมนต์ ไม่ใช่การนำเข้า ในการค้นหาเชิงโครงสร้าง มีเพียงคำสั่ง INCLUDE ที่ถูกเลือกเป็นการนำเข้า
• Maguyva ทำดัชนี ABAP ที่อยู่ในรีโพซิทอรี Git เป็นไฟล์ .abap และไม่เชื่อมต่อกับระบบ SAP

ขั้นตอนถัดไป

เชื่อมต่อรีโพซิทอรีด้วยคู่มือเริ่มต้นใช้งาน แล้วดูตารางการรองรับได้ที่หน้าความเข้ากันได้ สำหรับสภาพแวดล้อมรุ่นเก่าอื่น ๆ ดูคู่มือภาษา COBOL