SAP ABAP开发

ABAP概述 ABAP作为一种面向特定应用的第四代编程语言最早在2世纪8年代开发。它原本是作为一种报表语言应用在SAP R/2上，这是一个帮助大型公司在大型机上建立原材料管理和财务会计管理商务应用的平台。ABAP本来也是德语AllgemeinerBerichtsaufbereitungsprozessor的缩写，意思是“通用报表预处理器”。ABAP第一次引入了“逻辑数据库”的概念，它在基本的数据库层提供了更高级的抽象。 虽然SAP最早于1992年就发布了R/3，但ABAP仍可以用于为R/3系统编写程序。在2世纪9年代，随着计算机硬件的发展，越来越多的SAP的应用软件和系统都用ABAP来实现。一直到21年，几乎所有的基本功能都是由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、可用性：界面操作标准化，有完善的文档制作和交互式教学课件制作工具；　　1、所有的一切处理操作都是事务代码；操作可跟踪、可追溯；　　11、符合业务特点的数据库表类型定义，即将数据库开发的成功实践固化在开发环境中。 实施因素 范围不局限于即将实施的应用程序数量以及即将需要培训的最终用户的数量。以下简要地列出了在SAP实施全过程中将影响你项目范围的一些因素。 1. 地点多地点实施很明显将比单地点实施持续更长的时间尤其是当新的业务流程跨越多个地点时所需时间就更长。即使有两个项目除了一个是单地点另一个是多地点这方面不同以外其它方面完全相似多地点的那个项目要成功也会多花费25的成本而且时间更长。 2. 用户数量这个范围因素有两个层次。第一为1位用户重组业务流程要远比为1位用户重组简单得多。第二更加紧迫的任务是最终用户培训。但是纯粹的用户人数在范围中的作用没有象想象得那么重要因为在大多数情况下用户问题要到项目的后期才会出现。所以一家拥有1名用户的公司除了在最终用户培训方面以外并不比拥有1名用户的公司在范围上大出十倍。 3. 业务流程一家只买卖产品而不生产和储存产品的贸易公司要比一家生产、销售门类齐全的企业需要建立数量少得多的业务流程。同样道理生产的复杂性程度也因人而异。从事石油和天然气之类的加工企业会比主要从事装配工作的企业产生更多的麻烦。 4. 应用程序FICOMM 和 SD 通常被看成是核心应用程序在所在的项目中都会被实施。第二级应用程序包括 PPPM 和 1996年成熟的3.版引入的 HR第三级应用程序数不胜数。有些公司以线性的方式实施先是 FI然后是 SD再是 MM......。另外一些公司则一组组地实施先是 FI-SD-MM然后是 PP 和 PM或者其它什么程序。你实施的次序和组合方式将明显地对你的项目范围产生重大的影响。 5. 扩展和购买这是范围中最难的因素。因为为两者作规划时没有预先知识和经验的基础。许多公司选择SAP时看法一致把它当作“通过购买求发展”战略的解决方案。应该考虑到购买公司的起点文化以及该公司发展的曲线。 6. SAP项目期间的结构重新调整你可能会希望你公司会冻结这样的活动直到业务流程重组得以完成但这不会发生。没有办法可以为此作规划也没有办法在其发生前调整项目范围。屏住呼吸它会发生的。 7. 实施方式“一次性完全实施”还是“循序渐进式实施一次性完全实施”的方式很吓人但通常比“循序渐进式实施”更容易成功。“循序渐进式实施”缓慢、拖延但同“一次性完全实施”一样具有高风险。范围问题主要在于用户和他们是否愿意转向SAP。如果他们紧紧依附于遗留系统你的范围将由于包括了对阻力的预防措施而扩大。