sap abap

SAP ABAP程式語言最初被SAP的開發者用於開發SAP R/3平台。但它也被設計讓SAP的客戶用於增強SAP的軟體套用

客戶可以用ABAP編程開發自定義的報表和界面。這個程式語言對於程式設計師、運維人員、網路技術人員來說很容易學習但並不是一個非程式設計人員可以直接使用的工具。編寫ABAP程式需要良好的編程技巧和關係資料庫方面的知識，如果知道面向對象設計的概念更好。

國內SAP人才的稀缺，直接制約著SAP的發展。

基本介紹

• 中文名：sap abap
• 增強：SAP的軟體套用
• 用於：開發SAP R/3平台
• 面向：特定套用

ABAP概述

ABAP作為一種面向特定套用的第四代程式語言最早在20世紀80年代開發。它原本是作為一種報表語言套用在SAP R/2上，這是一個幫助大型公司在大型機上建立原材料管理和財務會計管理商務套用的平台。ABAP本來也是德語AllgemeinerBerichtsaufbereitungsprozessor的縮寫，意思是“通用報表預處理器”。ABAP第一次引入了“邏輯資料庫”的概念，它在基本的資料庫層提供了更高級的抽象。

雖然SAP最早於1992年就發布了R/3，但ABAP仍可以用於為R/3系統編寫程式。在20世紀90年代，隨著計算機硬體的發展，越來越多的SAP的套用軟體和系統都用ABAP來實現。一直到2001年，幾乎所有的基本功能都是由ABAP編程實現的。在1999年，SAP在發布R/3 4.6版的同時也發布了一個對ABAP的面向對象擴展，叫做ABAP Objects。

SAP最新的開發平台NetWeaver同時支持ABAP和Java。

運行環境

所有的ABAP程式都駐留在SAP資料庫里。他們不像Java或者C++程式那樣存儲在一個單獨的外部檔案里，在資料庫里所有的ABAP代碼都以兩種形式存在：可以用ABAP workbench查看和編輯的原始碼和由ABAP運行環境載入和解釋的“編譯”代碼（技術上更精確地說是“產生”代碼）。當一段ABAP原始碼第一次被調用時會隱含的進行代碼產生。如果稍後原始碼改變了或者程式訪問的對象改變了（比如資料庫的表添加了新的欄位），產生代碼就會自動重新產生。

ABAP程式在運行時系統（SAP核心的一部分）的控制下運行在SAP套用伺服器里。運行時系統負責處理ABAP語句，控制顯示的邏輯序列和回響事件（比如，用戶按一下螢幕上的一個按鈕）。ABAP運行時系統的一個關鍵組件是資料庫接口，它把ABAP的資料庫無關語句（“開放SQL”）變成底層資料庫管理系統可以理解的語句（“本地SQL”）。資料庫接口處理ABAP程式和關係資料庫之間所有的通信；它也有一些其他的作用，比如把經常訪問的數據快取到套用伺服器本地的存儲器里。

ABAP類型

模組池

這些程式使用一系列的螢幕來定義更複雜的用戶互動模式。術語“螢幕”是指用戶看到的實際的物理圖像。每個螢幕還有一個“流邏輯”；這是指由螢幕觸發的ABAP代碼，比如初始化螢幕，回響用戶請求的應答和控制模組池的螢幕之間的序列的邏輯。每個螢幕都有自己的流邏輯，每個流邏輯都分為“PBO”（輸出前處理）和“PAI”（輸入後處理）部分。在SAP的文檔中，術語“dynpro”（動態程式）用來表示這種螢幕和流邏輯的結合。

線上程式並不是通過名字調用的，而是和一段事務代碼聯繫在一起。用戶可以通過自定義，角色依賴，事務選單來觸發它們。

除了報表和線上程式外，以類庫，功能庫和子程式池的形式開發共享代碼段也是可以的。

報表程式

報表程式遵循一個相對簡單的編程模型，用戶可選的輸入一系列參數（比如，在一個數據子集上的選擇），然後程式根據輸入的參數以一個互動式列表的形式產生一張報表。報表程式的輸出之所以是互動式的是因為它不是一個被動的顯示；它允許用戶使用ABAP語言通過深入挖掘功能以獲得某個數據更細節的視圖，或者通過選單命令觸發更深入的處理，比如按不同的方式排序數據或者按某種選擇條件過濾數據。這種表現報表的方法有很大的優勢，特別是對於那些需要處理大量信息但又要以很靈活的方式來檢查這些信息的用戶，這樣他們就不會再被限制到一種固定的顯示形式或者大小上無法管理的列表形式的報表中了。這種方便的開發互動式報表的方式是ABAP語言的一大重要閃光點。

開發工具

ABAP Workbench有幾個不同的工具用於編輯容器對象。這些工具可以為你提供涵蓋整個軟體開發周期各階段的輔助。 創建和編輯容器對象的最重要的工具有：

ABAP Editer：編寫程式代碼

ABAP Dictionary：處理資料庫表定義，檢索全局類型

Menu Painter：設計用戶界面（包括選單欄，標準工具列，套用欄，配置功能鍵）

Screen Painter：為用戶對話框設計螢幕（動態程式）

Function Builder：顯示和處理功能模組

Class Builder：顯示和處理ABAP對象類

語法特點

由各自獨立的語句構成。每個語句的第一個單詞必須是ABAP關鍵字。單詞之間至少要用一個空格分隔。

每個語句結束必須要用句號。一個語句可以跨多行，只要不遇到句號，就認為是一個延續 的語句。

可以把多個語句放在一行。ABAP不區分大小寫，關鍵字和用戶運算元都一樣，為了便於閱讀，一般把關鍵字大寫，而運算元小寫。如果連續多行的第一個關鍵字相同，可以使用鏈語句方式減少輸入

™data: id type I.

™data: name type c.

™可寫為:

™data: id type I ,

™ name type c.

注釋:

注釋行由第一列的星號（*）開頭，並且必須寫在第一 列，前面不能有空格。

在行末的注釋用雙引號（”）作為前導。

™data: id type i. “ 定義一個對象num數據類型為I

技術架構

SAP的系統架構設計無疑是值得學習的，以下是我從網路上收集的一些相關信息，也可以作為架構設計的參考。
1、實施、開發過程和維護過程管理細緻，角色劃分清晰，即使在項目的開發過程中，仍然要配備BASIS人員，並對系統進行運維工作管理；
2、三種環境：開發、QA、生產，在三種環境下的整合開發過程；
3、注重許可權、審計：所有的操作都和許可權綁定，並對每項業務操作都進行日誌記錄，資料庫記錄邏輯刪除，這對系統的體系結構和資料庫設計規範提出相應的要求，同時也對系統的實施和運維工作提出了要求；
4、套用伺服器和資料庫伺服器的層次定義：和J2EE體系架構不同，一方面保持套用的獨立性，另一方面保證資料庫伺服器的穩定；
5、系統的穩定性壓倒一切：即使犧牲性能，也要確保系統的穩定；
6、模組的質量保證：對測試的組織，完整的測試流程貫穿項目開發實施的全過程；
7、可維護性的表現：一方面是基於運維的，對於系統軟硬體各個部分的監控；另一方面是系統架構上，編程模式上能支撐二次開發；
8、可擴展性的表現：系統架構上和物理部署上的兩種體現；
9、可用性：界面操作標準化，有完善的文檔製作和互動式教學課件製作工具；
10、所有的一切處理操作都是事務代碼；操作可跟蹤、可追溯；
11、符合業務特點的資料庫表類型定義，即將資料庫開發的成功實踐固化在開發環境中。

實施因素

範圍不局限於即將實施的應用程式數量以及即將需要培訓的最終用戶的數量。以下簡要地列出了在SAP實施全過程中將影響你項目範圍的一些因素。

1. 地點多地點實施很明顯將比單地點實施持續更長的時間尤其是當新的業務流程跨越多個地點時所需時間就更長。即使有兩個項目除了一個是單地點另一個是多地點這方面不同以外其它方面完全相似多地點的那個項目要成功也會多花費25的成本而且時間更長。

2. 用戶數量這個範圍因素有兩個層次。第一為10位用戶重組業務流程要遠比為1000位用戶重組簡單得多。第二更加緊迫的任務是最終用戶培訓。但是純粹的用戶人數在範圍中的作用沒有象想像得那么重要因為在大多數情況下用戶問題要到項目的後期才會出現。所以一家擁有1000名用戶的公司除了在最終用戶培訓方面以外並不比擁有10名用戶的公司在範圍上大出十倍。

3. 業務流程一家只買賣產品而不生產和儲存產品的貿易公司要比一家生產、銷售門類齊全的企業需要建立數量少得多的業務流程。同樣道理生產的複雜性程度也因人而異。從事石油和天然氣之類的加工企業會比主要從事裝配工作的企業產生更多的麻煩。

4. 應用程式FICOMM 和 SD 通常被看成是核心應用程式在所在的項目中都會被實施。第二級應用程式包括 PPPM 和 1996年成熟的3.0版引入的 HR第三級應用程式數不勝數。有些公司以線性的方式實施先是 FI然後是 SD再是 MM......。另外一些公司則一組組地實施先是 FI-SD-MM然後是 PP 和 PM或者其它什麼程式。你實施的次序和組合方式將明顯地對你的項目範圍產生重大的影響。

5. 擴展和購買這是範圍中最難的因素。因為為兩者作規劃時沒有預先知識和經驗的基礎。許多公司選擇SAP時看法一致把它當作“通過購買求發展”戰略的解決方案。應該考慮到購買公司的起點文化以及該公司發展的曲線。

6. SAP項目期間的結構重新調整你可能會希望你公司會凍結這樣的活動直到業務流程重組得以完成但這不會發生。沒有辦法可以為此作規劃也沒有辦法在其發生前調整項目範圍。屏住呼吸它會發生的。

7. 實施方式“一次性完全實施”還是“循序漸進式實施一次性完全實施”的方式很嚇人但通常比“循序漸進式實施”更容易成功。“循序漸進式實施”緩慢、拖延但同“一次性完全實施”一樣具有高風險。範圍問題主要在於用戶和他們是否願意轉向SAP。如果他們緊緊依附於遺留系統你的範圍將由於包括了對阻力的預防措施而擴大。