《电子技术应用》
您所在的位置:首页 > 通信与网络 > 设计应用 > SAP软件系统传输功能分析和应用
SAP软件系统传输功能分析和应用
来源:微型机与应用2013年第19期
董 伟,丁建华,杨正平
(云南铜业股份有限公司,云南 昆明 650051)
摘要: 主要分析SAP系统底层软件传输架构,通过了解SAP系统底层传输机制,达到能够清楚分析传输故障的目的,并扩展传输使用范围,通过传输系统进行SAP系统补丁升级和实现手动传输的具体方法。
Abstract:
Key words :

摘  要: 主要分析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所示。


1.2 SAP ERP软件Domain传输域的构成
 构建Domain传输域是SAP ERP系统之间实现传输的前提。Domain传输域包含了所有加入到当前域的SAP ERP系统。在一个Domain传输域中只能有一个SAP ERP系统作为传输域控制器(一般按照系统的安装顺序,先装DEV系统则定义DEV为传输域控制器),其他系统安装配置好后加入到当前传输域。传输域中的SAP ERP系统按照一定顺序构建成一个或多个传输路径,这些传输路径和路径上的SAP ERP系统就组成了Landscape。因此一个Domain内可以有多个Landscape存在,典型的传输域模型如图2所示。
 图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进行配置时系统会提示配置传输域。配置完成如图4所示。

 配置完传输域后即进入配置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系统管理员,掌握底层传输机制也是非常重要的。
参考文献
[1] 石坚燕.SAP NetWeaer--SAP新一代业务平台[M].北京:东方出版社,2005.
[2] 周旋.SAP R/3技术与实现[M].北京:机械工业出版社,2010.
[3] 希格里德·哈格曼,蓝·威尔.SAP R/3系统管理[M].北京:东方出版社,2006.

此内容为AET网站原创,未经授权禁止转载。