SAP软件系统传输功能分析和应用

SAP软件系统传输功能分析和应用

摘 要： 主要分析SAP系统底层软件传输架构，通过了解SAP系统底层传输机制，达到能够清楚分析传输故障的目的，并扩展传输使用范围，通过传输系统进行SAP系统补丁升级和实现手动传输的具体方法。关键词： SAP；系统管理；传输管理
　SAP公司的ERP（Enterprise Resource Planning）软件以其强大的行业解决方案、灵活的配置和开放性的接口等诸多优点正逐步成为各企业的首选ERP软件。其ERP产品线非常全，从小型企业的SAP Business One到大型企业的SAP Business Suite都提供了强大的行业解决方案。从底层技术架构上看，所有产品都离不开SAP软件的基座：SAP NetWeaver。而本文所要阐述的传输管理系统就是基于SAP NetWeaver的一项功能。通过传输管理系统，SAP系统管理员（BASIS）不仅可以将开发人员的程序、数据库表、Customazing配置从开发机传输到测试、生产机，还可以传输用户、角色、Notes补丁等。而且管理员在安装SAP ERP系统的语言包、Support Package、Add-On、Notes等基础功能时，传输系统是必须使用的工具，由此可见传输系统的重要性。本文就SAP ERP软件的传输功能进行深入分析，探讨其工作原理，并引申使用多种传输方法实现其传输功能。1 SAP ERP软件系统结构及传输介绍1.1 SAP NetWeaver系统结构　SAP NetWeaver是一种可以随时用于业务运作，服务源于架构SOA（Service Orinted Architecture）的软件平台，适用于SAP的所有解决方案。SAP NetWeaver7.0产品在SOA的基础上，推出面向企业级服务的SAP企业服务信息系统基础架构ESA（Enterprise Service Architecture）。其组件包括门户、应用服务器、商务智能解决方案以及系统整合和数据整合技术，贯穿始终的是组合应用的框架和产品生命周期管理。在底层还可以扩展.NET、WebSphere和其他第三方专业系统，并为客户提供管理不同基础设施、降低复杂层度和消减总体拥有成本的灵活性[1]，SAP NetWeaver架构。

1.2 SAP ERP软件Domain传输域的构成　构建Domain传输域是SAP ERP系统之间实现传输的前提。Domain传输域包含了所有加入到当前域的SAP ERP系统。在一个Domain传输域中只能有一个SAP ERP系统作为传输域控制器（一般按照系统的安装顺序，先装DEV系统则定义DEV为传输域控制器），其他系统安装配置好后加入到当前传输域。传输域中的SAP ERP系统按照一定顺序构建成一个或多个传输路径，这些传输路径和路径上的SAP ERP系统就组成了Landscape。因此一个Domain内可以有多个Landscape存在，典型的传输域模型。　图2中，整个系统组成Domain传输域，包括3个Landscape传输路径：DEV—TEST—PROD，DEV—SAND，DEV—TEST—TRAIN。在某个Landscape

传输路径下，还可以存在多个不同集团之间的传输。例如开发、配置系统分别为集团100和200，SAND系统为800，则Landscape传输路径DEV—SAND可以有DEV（100）—SAND（800）和DEV（200）—SAND（800）两条传输路由（Transport Routes）。图2中所示的DEV为开发系统，作用是进行程序开发和配置。按照SAP的标准，在DEV系统中，应该是尽量避免有客户数据。开发完成后，所有正确的配置应该传输到测试系统中进行测试；TEST为测试用系统，其作用是验证开发系统中所开发的程序和配置是否正确。为了完成测试，应该在这个系统中输入少量客户数据。如果测试的结果是某项配置没有达到目的，应该返回开发系统修改后再进行测试，如此循环直到配置完成；PROD为正式上线的生产系统。生产系统完全就是为了生产。为了保证系统的安全，生产系统不允许有任何与生产无关的数据；SAND为沙盒系统（又被称为playground），主要给顾问做程序开发测试使用；TRAIN为培训系统，主要给关键用户和最终用户学习培训使用。1.3 三种常见的Landscape结构　根据SAP ERP企业用户各自的情况，传输域配置各不一样。大多数用户由于资金预算限制，一般会节省SAND、TRAN等系统而采用图3所示的几种Landscape结构。1-system Landscape为一套硬件服务器安装SAP R3系统，再通过不同集团（Client）区分DEV、TEST、PROD子系统，分别用作SAP的开发、测试和生产系统。　2-system Landscape为两套硬件服务器，其中一般将性能大的单独安装为PROD用作生产系统，性能小的用作开发、测试系统。　3-system Landscape为3套硬件服务器，分别安装单独的SAP系统用作开发、测试、生产系统，各系统底层硬件可以不同，但SAP软件系统版本高度一致。　3种Landscape架构各有优劣，其中1-system Landscape最为省钱，毕竟只用了1套硬件系统，通过Client的方式实现了开发、测试、生产3套系统软隔离。但是缺点是不能实现真正意义的传输，而且3套系统共用同1套SAP底层数据库，如果操作系统或SAP底层软件故障，3套系统都将不能访问和使用。3-system Landscape最安全且方便管理。通过独立的3套系统，分别建立RFC连接后，独立的硬件系统即可实现各套系统之间各种数据的传输。2-system Landscape介于1-system Landscape和3-system Landscape两种架构之间，是一种折中的架构方式。1.4 集团相关数据（Client-specific）和跨集团数据（Cross-client）的区别　在图3中，不论是何种Landscape形式，DEV、QAS、PROD都表现为上层独立模块，彼此间数据各自独立，此部分为集团相关数据。而跨集团数据则为底层共用数据部分，只能通过独立安装SAP ERP软件来分隔，在图中为“跨集团客户定

制”和“集成知识库”。

　集团相关数据包括权限、账号、角色、业务数据等。如果传输请求的内容是这部分，传输一定要选对目标集团，传输请求只对目标集团有效。　跨集团客户定制数据包括开发类数据、ABAP程序、表定义、各种程序补丁等。如果传输请求的内容为跨集团客户定制数据，传输目标集团可以任选一个（包括SAP系统安装后生成的000、001、066），传输请求内容变更到该SAP ERP系统的所有集团。1.5 SAP ERP系统传输域部署方法　按照实际项目要求及资金预算考虑，选择何种Landscape进行部署。同时还要考虑特殊要求。比如有些公司开发机、测试、生产机分别部署在不同城市。但总的来说，SAP ERP系统的传输域部署是在SAP ERP系统软件部署完成后进行配置的。　进入TMS（Transport Management System）建立传输域。首先登录SAP GUI（SAP Graphic User Interface）客户端后使用T-code（Transaction-code）事物代码：STMS进入TMS管理配置界面。当SAP ERP系统安装完成，首次进入TMS进行配置时系统会提示配置传输域。配置完成。

　配置完传输域后即进入配置Landscape阶段。点击菜单Overview的System选项将各套系统添加到Domain，点击菜单Overview选择Transport Routes选项进入Landscape传输平台配置，然后点击菜单Configuration的Standard Configuration选项选择并配置需要的系统架构即可。图5为3-system Landscape配置完成图。


2 SAP系统软件传输的作用和功能2.1 SAP系统软件传输的作用　SAP系统的配置和开发过程是一个持续改进的过程，即配置、开发到测试到正式使用，然后客户在使用的过程中遇到问题，顾问继续修改部分不足，重复以上的测试到正式使用的步骤。以上每一次在开发系统中的创建和修改工作都会生成多个请求号，跨系统操作则需要传输来完成。一旦顾问完成配置和开发，即进行请求号释放（事物代码SE01，释放之前顾问可以将多个请求号合并，减少传输工作量），释放之后系统后台会产生传输文件，并将传输请求号加入到目标系统的传输队列中（对应SAP自有表TRBAT和TRJOB）。在目标系统中经过刷新请求号队列，系统会检查有没有后续传输路径，如果有且当前系统传输完毕，请求号又会自动产生新的传输文件，重复上面的操作。当然，如果事先不配置好传输路径，即传输的目标系统，那么就不会生成传输文件了。　事物代码SPAM用来安装Support Package，事物代码SAINT用来安装Add-On，事物代码SNOTE则用来打NOTES补丁。虽然各自的功能不同，只要是在开发系统中进行安装时生成了请求号，最终都可以调用SAP的传输系统，将补丁直接传输到测试和开发系统中，而不用分别安装3套

系统。既然有请求号，其底层传输动作就跟配置和程序的传输一样，只是传输的内容变成了补丁。以上传输过程是建立在2-system Landscape及以上Landscape架构上的。如果用户因特殊原因选择1-system Landscape架构，传输就只是同系统不同集团Client之间传输。对应图3中1-system Landscape为“跨集团客户定制”的改变，事物代码为：SCC1。2.2 SAP软件传输功能分析　当系统配置完TMS和Landscape后，SAP即在服务器上关联了传输路径和连接方式等相关内容，用户的所有前台传输操作都将按照配置进行传输。这些配置参数保存在Transport profile文件中，文件名为tp_<domain>.PFL，其中<domain>是配置在TMS中的传输域名。　配置和程序的传输部署在操作系统层就是tp软件的动作。tp是SAP应用层面反应到操作系统层面进行传输的程序，支持UNIX系统和Windows系统之间的传输。当BASIS管理员通过SAP客户端进行请求号传输时，tp首先建立需要传输的传输号列表，然后通过RFC连接到远程系统，建立连接后按列表进行传输。在OS层面，tp在进行数据以及版本升级补丁的传输时，也会调用另外一个传输程序R3trans，SAP的标准文档并没有给出R3trans底层的传输过程，涉及到系统升级相关的内容SAP不建议手动操作。传输的目录文件默认情况下在/usr/sap/trans/cofiles和/usr/sap/trans/data两个目录下，文件名称跟TMS实际传输列表一致（TMS传输请求号类似DEVK123456，则文件名字类似K123456.DEV）。管理员能监控目标系统的该两个目录的变化来监控传输[2]。3 软件传输功能的应用实例分析　经过以上对传输动作的逐层分析，了解了SAP系统传输的底层操作步骤后，SAP系统管理员完全可以直接跳开SAP传输管理界面，对开发顾问生成的传输请求在操作系统层面进行手动传输。以某公司的SAP项目为例，前期配置2-system Landscape架构，后期增加预算调整为3-system Landscape后，系统中已经有部分配置和开发程序传输到PROD中。这就需要手动传输来补QAS系统的传输请求。传输请求的传输有一些是必须按照先后顺序来传输的。只需要按照请求号从低到高的排列顺序进行传输就可以了。3.1 具体实现步骤　（1）首先需要进入TMS将现有Landscape打乱。具体方法为添加一个Virtual System代替中间节点，这样各套系统中的传输记录不会丢失，现有系统的Landscape又独立出来。完成后分别从DEV、QAS、PROD看传输域类似图6所示。

　（2）进入开发系统的操作系统，转到传输所使用的目录地址：/usr/sap/trans/cofiles（控制文件）和/usr/sap/trans/datafile（数据文件）两个目录下，同时找到需要传输的请求号所对应的文件。在目标系统（测试或生产）系统的操作

系统，查看以上两个传输目录，确定需要传输的请求号不在其中。　（3）通过rcp（remote file copy）命令或ftp进行手动传输文件拷贝（注意ftp在进行传输的时候使用ASIC传输模式）。拷贝完成后还要将属组进行调整，让传输文件能被系统中的SAP用户访问，命令为：chown<sap用户>：<sap管理组>文件名。　（4）在/usr/sap/trans/bin目录中执行以下命令：　tp connect <SID>　tp addtobuffer DEVK123456 <SID>　tp import DEVK123456<SID>Client 800　其中<SID>为目标系统的实例号，800为目标系统Client号。tp命令格式：tp<command>[argument（s）][option（s）]。tp命令<command>参数包括Exporting、Importing、Buffer Actions、Disk Space、Information、Special Functions功能，通过正确使用带参数的tp能完成所有SAP客户端中的TMS传输工作。　（5）如果是补丁升级和实际数据传输，tp还会调用R3Trans，命令格式：R3trans[<options>]<control_file>。R3Trans命令<options>参数可以是以下内容：-c f1 f2：带字符集转换拷贝文件f1到文件f2。-d：连接数据库，测试SAP数据库是否可用。-i file：不使用控制文件导入文件。-l file：列出日志文件清单。-m file：列出允许使用tp创建cofile的内容清单。-t：测试。回滚所有数据变更操作。-t4：跟踪级别4，开启开发跟踪。-u<int>：无条件模式-v：冗余。写入更多细节到日志文件。-w file：指定日志文件。默认为“trans.log”。-x：连接数据库但不访问SAP表[3]。　（6）手动传输完成后，还需要将TMS的Landscape重新恢复到正常状态，刷新TMS检查传输号是否已经传输成功。3.2 手动传输的后继操作　手动传输能解决很多SAP传输问题，例如开发进程超前，传输卡死等。但是手动传输也有新问题。SAP系统的客户端进行的传输自动记录了传输动作，而手动则没有。当系统发生了手动传输后，客户端刷新是要对比传输记录的。SAP系统通过将整个Landscape中各套系统的/usr/sap/trans/下的相关目录文件进行列表对比，以显示已发生和将要发生的传输清单。手动传输后SAP系统需要更新这部分内容。而SAP的自动更新将会非常缓慢。为了解决这个问题，SAP的TMS给出了两种解决方法：　（1）进行一致性检查。包括：consistancy；crital objects；transport tools 3个工具。　（2）进行校正。运行事物代码：STMS后进入某个系统的Import Queue，使用Queue菜单中的Adjust进行校正。如开发定制的请求号多，该步骤比较慢，可以新开客户端用Import Monitor进行监控。　传输请求的内容有可能是一段程序，也有可能是对某张数据表的修改。在进行程序传输的时候如果发现传输程序一致处于运行状态“RUNNING EXECUTION

OF REPORTS AFTER PUT”，这也有可能是数据表的问题。一种可能是数据表正在被访问，而传输的请求是更改该数据表，则必须事先查看是否有人正在使用该表；另外一种情况是数据表所需要的空间不够，虽然sap和oracle都能自动扩容空间，但如果所扩容空间的增量跟不上传输需求，就会导致传输卡死的情况。通过事物代码SE16N查看TMSTLOCK表，该表中的记录锁定了传输故障的传输请求条目。如强制解锁，还要监控另外两张传输相关的表TRBAT和TRJOB。TRBAT记录传输工作列表，TRJOB记录传输状态列表。　在使用以上几种方法进行检查和校正需要停止一切tp和R3Trans软件的访问活动。因此操作之前先用事物代码SM02发个消息，通知所有有权限的顾问，避免与其他开发人员或管理员的操作发生冲突。　SAP的BASIS管理员主要负责系统的安装、配置、管理、监控、维护、调优工作。这些工作都需要掌握传输系统才能很好的完成。正常情况下管理员只需要通过TMS传输管理系统或Solution Manager管理机进行传输的管理维护。但当传输系统出现卡死，项目开发硬件不到位后期调整Landscape等情况时，手动传输就变得尤为重要。掌握底层传输技术手段，SAP系统管理员能将应用层面的传输工作转到OS层面进行，绕开SAP R3系统对传输过程的监控，不仅效率更高，而且能绕开应用层面的传输报错等情况进行传输，这不仅为系统管理员提供了解决传输问题的途径，也提高了管理员进行系统维护的效率。不论是整个项目的开发和业务应用都将在此受益。因此作为SAP系统管理员，掌握底层传输机制也是非常重要的。