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代码，比如初始化萤幕，回响用户请求的应答和控制模组池的萤幕之间的序列的逻辑。每个萤幕都有自己的流逻辑，每个流逻辑都分为“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。如果他们紧紧依附于遗留系统你的範围将由于包括了对阻力的预防措施而扩大。