论文部分内容阅读
摘要:本文阐述了SAP系统(基于客户/服务机构和开放系统的集成的企业资源计划系统)的用户操作的基础知识,讲述了标准用户管理的现状与不足,引入了更高级的SAP系统的用户管理模式——CUA(中央用户管理),介绍了采用该种模式的前提条件,详细讲述了CUA模式下,高级用户管理的先进性与操作步骤,包括搭建步骤与移除步骤——CUA的搭建,子系统的加入步骤以及暂时与永久移除子系统的操作步骤和彻底移除CUA的操作步骤。
关键词:SAP用户;CUA操作步骤;管理
作者简介:李亚林(1976-),女,陕西扶风人,陕西电力信通有限公司,工程师,主要研究方向:SAP BASIS管理。(陕西 西安
710004)闫峰(1975-),男,陕西延安人,陕西延安供电局客户服务中心,工程师,主要研究方向:电力营销管理。(陕西 延安 716000)
伴随SAP在国内外大型企业的应用增多,及各企业业务类型日益复杂和引入的SAP相关产品的日益增多,用户权限管理作为一项基础管理工作,则尤显重要,但基于SAP产品的特殊性,为了在不同场景下能够顺畅使用SAP,并且为了减轻SAP Basis人员的工作量,特引入SAP CUA用户管理,供业内相关人士参考。
一、SAP的用户管理机制
在SAP系统的用户管理在整个SAP的运维工作中占有很重要的地位,构成SAP用户的因素主要是用户主记录(User Master Record),而构成一个用户主记录的元素除了其地址、参数和登录数据等信息外,还有重要的授权信息,即角色,而授权信息又分为角色和参数文件两个一一对应的信息,角色的构成元素有参数,给了赋值的授权,一个或若干个参数又构成了参数文件,一个参数文件对应一个角色。一个用户登录SAP系统时,就会将该用户所拥有的所有授权参数文件读入到用户主记录区域,在其每做一步操作时,SAP就会严格做一次权限校验,检查该用户是否拥有操作该事物代码所拥有的授权对象及其赋予的对应值,若校验通过,校验检查值ACTIVE赋为1,用户的事务操作可顺利执行,若校验失败,则ACTIVE赋为0,并提示权限不足,用户则无权继续再做相关的操作。
二、标准模式下用户管理的现状与不足
在很多情况下,由于公司业务的深入以及信息化应用的高水平发展,可能会在ECC产品(企业资源计划系统中央控制)应用很成熟的基础之上,还会再引入CRM、SRM、BW等系列产品。面对这些SAP产品的逐步深入应用,用戶管理就会变得日益复杂,我们就有可能在之前ECC用户管理模式及操作技术已经完善的基础之上,再在新引进的SAP产品里根据需求,再创建一大批用户出来,而且这些用户的信息之前已经存在于ECC里。由于用户主记录在SAP系统中是以集团相关的数据存在,也就是说,每一个集团都有他自身并独立的受限用户群组,如果你的公司拥有一个相对复合的系统环境,即上述的环境有ECC、CRM、BW等,而且针对每一个系统,由于安全性系统蓝图设计标准,又会存在至少三系统的架构,即开发环境、测试环境与生产环境。例如就ECC系统而言,可能会有标准的三系统架构:DEV、QAS、PRD,所以在其他的SAP系统中,都会根据系统实施需求,存在一个或若干个Client来做不同的实施环境。
当同一个用户在上述实施环境中拥有不同的操作或者管理身份时,即用户李四在ECC、CRM及BW中可能都会存在用户ID,这个用户在多系统中的多Client下可能都会有用户ID及相应授权角色存在。传统的用户操作模式是:由BASIS管理员登录到不同系统的不同Client下,分别应用事物代码SU01,创建用户,填写用户地址、参数以及登录数据,并在角色信息里分配该用户应该具有的角色信息,保存后该用户就有了登录系统并做被许可的相关操作,此操作不复杂,但假如该用户以其特殊的管理与决策者的身份在公司引入的各SAP产品里都有ID存在时,那使用该模式来管理用户就会相当繁杂与混乱,为什么呢?采用上述传统的操作模式,要分别登录进各产品的相关Client里,全必须做一遍一个用户新建操作,在ECC的500、550两个Client里分别做完之后,又要在SCM的100、200,CRM的250、300,即6个Client里都要分别做一遍,且不说后期还要再引入的BW、EP产品等,而且用户删除、锁定、权限调整等也都是如此操作。面对如此繁杂且日复一日的重复工作,除了要耗掉大量的工时,由于还牵扯到用户的授权分配,该操作在SAP的运维中安全级别相对较高,要求管理员做该操作时要谨慎,所以说多数的BASIS管理员为此头疼不已。在此基础之上,SAP推出了其功能强大的CUA用户管理模式。
三、CUA模式的优点与实施前提条件与搭建步骤
CUA管理模式是:将所有的用户管理都纳入到统一的单一环境下来进行集中管理,然后通过分发的方式,将更改后的用户迁移到相应的Client里。在一个多SAP系统的环境中,尤其当同一个用户分别存在于不同的系统中时,用CUA模式的部署功能则尤为方便。CUA环境的搭建方法也相对简单,现在模拟一个CUA实施的环境,DEV200为Central System,DEV的100、400、700以及QAS的200、420、600和PRD的700及800全部为CUA Child System系统,对于具体的实施步骤在此做简单指导。
第一步:登录系统,应用事务代码BD54按照需求定义逻辑系统,并应用SCC4事务代码分配逻辑系统给每个集团。
基于SAP的传输路由机制,只需要在D200中创建以上所有的集团的逻辑系统,由于逻辑系统的跨集团性,在DEV系统的其他所有Client端这些逻辑系统自动存在,再利用传输工具,将所有创建的逻辑集团都分别传至QAS和PRD系统,使其生效。
第二步:创建所需的System类别的技术用户:在本论文中的模拟实施场景共有9个Client,其中DEV200作为CUA的主系统,其他的8个Client均为受控的集团。(见图1)
第三步:创建RFC连接:在Central DEV200中创建RFC Connection为DEVCLNT200,再创建所有相关的其他Child System的RFC连接,RFC连接的命名规则是CLNT####,比如子系统PRD800的RFC连接就应该是PRDCLNT800,连接所用的可信任帐户就是第二步中创建的相应用户。
在主系统中应该创建的RFC有Loopback的DEVCLNT 200和指向8个子Client的RFC,在8个子系统中分别创建DEVCLNT200,即指向主Client的RFC,所用到的用户为上述第二步中创建的用户。
第二步和第三步需注意的是:逻辑系统的名称必须和RFC目的地的名称完全一致,而且必须是大写标识。
第四步:配置并激活CUA设置。登录Central System,应用SCUA事务代码来创建一个distribution model,比如CUA,输入或者选择所有将要被连接和分发的子系统(比如其中的QASCLNT200),保存后若没有异常应该出现三个提示:
ALE distribution model was saved
Central User Administration Activated
Text comparision was started
出现上述三条信息,则表示CUA在系统中已激活并生效。
一旦激活了CUA配置,就再不能在子系统中用SU01的事务代码来创建新用户。
第五步:设置字段分发的参数:对于SU01操作中的每个修改项,应用SCUM事务代码可对其限制是否可修改的参数。对于一些重要的字段项,可参考如下方式设置:
第六步:比较公司地址,应用事务代码SCUG做Central System和Child System间所维护的公司地址。
第七步:传输Child System里的用户到Central System里,并检查传输结果。
(1)登录Central System应用事务代码SCUG,拷贝子系统中的用户到主系统中。
(2)应用SCUL事务代码检查日志,确认用户的传输记录是否完整。
(3)如果CUA组中还有未传完的用户主记录,则继续在相应的子系统中应用事务代码BD87做后续手工处理,当然,此类现象的用户不会很多。
至此,所有CUA的相关配置到此结束,如果能够顺利的做完上述每一步操作,并监控配置日志都正常的话,那说明系统中已经成功存在了CUA的用户管理环境。一般情况下,为了安全原因,部署CUA都是将生产环境单独列出来,即一个公司的所有用户管理会存在两个CUA环境:开发测试和生产环境。
后续操作:CUA一旦建成之后,也不是必须采用这种完全固定的模式,为了灵活管理,可恢复此模式到之前的用户管理操作模式,分为两种模式:一是将一个子系统从CUA里暂时或者永久的移除;二是将整个CUA用户集中管理的模式彻底去掉。
第一種方式:若要将一个子系统从系统中永久移除,需要登录到Central系统中,运行以下的步骤:
(1)应用事务代码SCUA点击DELETE按钮,或者在SA38中运行报表RSDELCUA。
(2)在DELETE区域,选中要删除的Child系统后,运行测试和执行,在之后的屏幕中会列表显示将要删除的数据和有关联的表,双机表可显示表的具体内容(所查表内容同于SE16的内容)。若确定要删除,则继续执行。
(3)在WE20事务代码中,在“合作伙伴编号”和“伙伴类型”选项里,将子系统的信息类型为CCLONE和USERCLONE的两个类型删除。
(4)运行事务代码BD64,切换到Modify模式,删除子系统的模型视图并保存退出。分发CUA系统的分配模式,选择Edit-模型观察-分配,选择刚被删除的子系统作为输入项。
(5)在SCUA事务代码里,查看子系统是否已从CUA里被移除,如果所有的子系统都已从CUA里移除,就用SU01修改之前创建的Communication User,比如CUA_QAS,删除其Z_SAP_BC_USR_CUA_CLIENT这个角色,如果该用户没有其他角色和登录用户,就彻底将其删除。
第二种方式:暂时将子系统从CUA里移除,步骤:SA38运行Report RSDELCUA,可暂时从CUA组里删除子系统。如在后期某个时间段再要将该子系统加入到CUA,可用SCUA事务代码将子系统再次加入到CUA中,并用SCUG事务代码做一次CUA和子系统的比对。用SCUM维护Field分配参数后,将子系统本地的数据传输到CUA中去。
永久移除CUA:除了将子系统可暂时或者永久的从CUA里移除,也可永久的彻底移除CUA环境,步骤是:
(1)在Central System里,在SA38运行报表RSDELCUA,选中“Complete CUA and Test”选项后点击执行,如果确认要删除屏幕中显示的数据,则返回重新执行RSDELCUA,但不要勾选“Test”选项。
(2)在Central系统里,用WE20删除子系统在CUA里的数据,即删除信息类型为CCLONE和USERCLONE,如果信息类型只剩下SYNCH,则彻底删除该参数即可。
(3)在事务代码BD64里,删除CUA的分发模式。
(4)在所有的子系统里重复上面的步骤2和3。
(5)从所有的Communication User里移除CUA的角色:SAP_BC_USR_CUA_CENTRAL、SAP_BC_USR_CUA_CLIENT。
鉴于以上的操作,均可根据实际管理模式来做灵活调整。
四、结束语
由于CUA用户管理模式的简便性,使操作者摆脱了在每个SAP系统的不同集团中一一创建用户的烦恼,管理范围缩小,操作次数显著减少,实施过程的误操作带来的困扰已接近于零,使得SAP系统的管理更规范严谨,并节省大量的人力资源与时间资源,这种技术已经逐步得到了很多较大规模使用SAP产品的公司青睐,并已逐步应用于实际的管理操作模式中。
(责任编辑:苏宇嵬)
关键词:SAP用户;CUA操作步骤;管理
作者简介:李亚林(1976-),女,陕西扶风人,陕西电力信通有限公司,工程师,主要研究方向:SAP BASIS管理。(陕西 西安
710004)闫峰(1975-),男,陕西延安人,陕西延安供电局客户服务中心,工程师,主要研究方向:电力营销管理。(陕西 延安 716000)
伴随SAP在国内外大型企业的应用增多,及各企业业务类型日益复杂和引入的SAP相关产品的日益增多,用户权限管理作为一项基础管理工作,则尤显重要,但基于SAP产品的特殊性,为了在不同场景下能够顺畅使用SAP,并且为了减轻SAP Basis人员的工作量,特引入SAP CUA用户管理,供业内相关人士参考。
一、SAP的用户管理机制
在SAP系统的用户管理在整个SAP的运维工作中占有很重要的地位,构成SAP用户的因素主要是用户主记录(User Master Record),而构成一个用户主记录的元素除了其地址、参数和登录数据等信息外,还有重要的授权信息,即角色,而授权信息又分为角色和参数文件两个一一对应的信息,角色的构成元素有参数,给了赋值的授权,一个或若干个参数又构成了参数文件,一个参数文件对应一个角色。一个用户登录SAP系统时,就会将该用户所拥有的所有授权参数文件读入到用户主记录区域,在其每做一步操作时,SAP就会严格做一次权限校验,检查该用户是否拥有操作该事物代码所拥有的授权对象及其赋予的对应值,若校验通过,校验检查值ACTIVE赋为1,用户的事务操作可顺利执行,若校验失败,则ACTIVE赋为0,并提示权限不足,用户则无权继续再做相关的操作。
二、标准模式下用户管理的现状与不足
在很多情况下,由于公司业务的深入以及信息化应用的高水平发展,可能会在ECC产品(企业资源计划系统中央控制)应用很成熟的基础之上,还会再引入CRM、SRM、BW等系列产品。面对这些SAP产品的逐步深入应用,用戶管理就会变得日益复杂,我们就有可能在之前ECC用户管理模式及操作技术已经完善的基础之上,再在新引进的SAP产品里根据需求,再创建一大批用户出来,而且这些用户的信息之前已经存在于ECC里。由于用户主记录在SAP系统中是以集团相关的数据存在,也就是说,每一个集团都有他自身并独立的受限用户群组,如果你的公司拥有一个相对复合的系统环境,即上述的环境有ECC、CRM、BW等,而且针对每一个系统,由于安全性系统蓝图设计标准,又会存在至少三系统的架构,即开发环境、测试环境与生产环境。例如就ECC系统而言,可能会有标准的三系统架构:DEV、QAS、PRD,所以在其他的SAP系统中,都会根据系统实施需求,存在一个或若干个Client来做不同的实施环境。
当同一个用户在上述实施环境中拥有不同的操作或者管理身份时,即用户李四在ECC、CRM及BW中可能都会存在用户ID,这个用户在多系统中的多Client下可能都会有用户ID及相应授权角色存在。传统的用户操作模式是:由BASIS管理员登录到不同系统的不同Client下,分别应用事物代码SU01,创建用户,填写用户地址、参数以及登录数据,并在角色信息里分配该用户应该具有的角色信息,保存后该用户就有了登录系统并做被许可的相关操作,此操作不复杂,但假如该用户以其特殊的管理与决策者的身份在公司引入的各SAP产品里都有ID存在时,那使用该模式来管理用户就会相当繁杂与混乱,为什么呢?采用上述传统的操作模式,要分别登录进各产品的相关Client里,全必须做一遍一个用户新建操作,在ECC的500、550两个Client里分别做完之后,又要在SCM的100、200,CRM的250、300,即6个Client里都要分别做一遍,且不说后期还要再引入的BW、EP产品等,而且用户删除、锁定、权限调整等也都是如此操作。面对如此繁杂且日复一日的重复工作,除了要耗掉大量的工时,由于还牵扯到用户的授权分配,该操作在SAP的运维中安全级别相对较高,要求管理员做该操作时要谨慎,所以说多数的BASIS管理员为此头疼不已。在此基础之上,SAP推出了其功能强大的CUA用户管理模式。
三、CUA模式的优点与实施前提条件与搭建步骤
CUA管理模式是:将所有的用户管理都纳入到统一的单一环境下来进行集中管理,然后通过分发的方式,将更改后的用户迁移到相应的Client里。在一个多SAP系统的环境中,尤其当同一个用户分别存在于不同的系统中时,用CUA模式的部署功能则尤为方便。CUA环境的搭建方法也相对简单,现在模拟一个CUA实施的环境,DEV200为Central System,DEV的100、400、700以及QAS的200、420、600和PRD的700及800全部为CUA Child System系统,对于具体的实施步骤在此做简单指导。
第一步:登录系统,应用事务代码BD54按照需求定义逻辑系统,并应用SCC4事务代码分配逻辑系统给每个集团。
基于SAP的传输路由机制,只需要在D200中创建以上所有的集团的逻辑系统,由于逻辑系统的跨集团性,在DEV系统的其他所有Client端这些逻辑系统自动存在,再利用传输工具,将所有创建的逻辑集团都分别传至QAS和PRD系统,使其生效。
第二步:创建所需的System类别的技术用户:在本论文中的模拟实施场景共有9个Client,其中DEV200作为CUA的主系统,其他的8个Client均为受控的集团。(见图1)
第三步:创建RFC连接:在Central DEV200中创建RFC Connection为DEVCLNT200,再创建所有相关的其他Child System的RFC连接,RFC连接的命名规则是
在主系统中应该创建的RFC有Loopback的DEVCLNT 200和指向8个子Client的RFC,在8个子系统中分别创建DEVCLNT200,即指向主Client的RFC,所用到的用户为上述第二步中创建的用户。
第二步和第三步需注意的是:逻辑系统的名称必须和RFC目的地的名称完全一致,而且必须是大写标识。
第四步:配置并激活CUA设置。登录Central System,应用SCUA事务代码来创建一个distribution model,比如CUA,输入或者选择所有将要被连接和分发的子系统(比如其中的QASCLNT200),保存后若没有异常应该出现三个提示:
ALE distribution model was saved
Central User Administration Activated
Text comparision was started
出现上述三条信息,则表示CUA在系统中已激活并生效。
一旦激活了CUA配置,就再不能在子系统中用SU01的事务代码来创建新用户。
第五步:设置字段分发的参数:对于SU01操作中的每个修改项,应用SCUM事务代码可对其限制是否可修改的参数。对于一些重要的字段项,可参考如下方式设置:
第六步:比较公司地址,应用事务代码SCUG做Central System和Child System间所维护的公司地址。
第七步:传输Child System里的用户到Central System里,并检查传输结果。
(1)登录Central System应用事务代码SCUG,拷贝子系统中的用户到主系统中。
(2)应用SCUL事务代码检查日志,确认用户的传输记录是否完整。
(3)如果CUA组中还有未传完的用户主记录,则继续在相应的子系统中应用事务代码BD87做后续手工处理,当然,此类现象的用户不会很多。
至此,所有CUA的相关配置到此结束,如果能够顺利的做完上述每一步操作,并监控配置日志都正常的话,那说明系统中已经成功存在了CUA的用户管理环境。一般情况下,为了安全原因,部署CUA都是将生产环境单独列出来,即一个公司的所有用户管理会存在两个CUA环境:开发测试和生产环境。
后续操作:CUA一旦建成之后,也不是必须采用这种完全固定的模式,为了灵活管理,可恢复此模式到之前的用户管理操作模式,分为两种模式:一是将一个子系统从CUA里暂时或者永久的移除;二是将整个CUA用户集中管理的模式彻底去掉。
第一種方式:若要将一个子系统从系统中永久移除,需要登录到Central系统中,运行以下的步骤:
(1)应用事务代码SCUA点击DELETE按钮,或者在SA38中运行报表RSDELCUA。
(2)在DELETE区域,选中要删除的Child系统后,运行测试和执行,在之后的屏幕中会列表显示将要删除的数据和有关联的表,双机表可显示表的具体内容(所查表内容同于SE16的内容)。若确定要删除,则继续执行。
(3)在WE20事务代码中,在“合作伙伴编号”和“伙伴类型”选项里,将子系统的信息类型为CCLONE和USERCLONE的两个类型删除。
(4)运行事务代码BD64,切换到Modify模式,删除子系统的模型视图并保存退出。分发CUA系统的分配模式,选择Edit-模型观察-分配,选择刚被删除的子系统作为输入项。
(5)在SCUA事务代码里,查看子系统是否已从CUA里被移除,如果所有的子系统都已从CUA里移除,就用SU01修改之前创建的Communication User,比如CUA_QAS,删除其Z_SAP_BC_USR_CUA_CLIENT这个角色,如果该用户没有其他角色和登录用户,就彻底将其删除。
第二种方式:暂时将子系统从CUA里移除,步骤:SA38运行Report RSDELCUA,可暂时从CUA组里删除子系统。如在后期某个时间段再要将该子系统加入到CUA,可用SCUA事务代码将子系统再次加入到CUA中,并用SCUG事务代码做一次CUA和子系统的比对。用SCUM维护Field分配参数后,将子系统本地的数据传输到CUA中去。
永久移除CUA:除了将子系统可暂时或者永久的从CUA里移除,也可永久的彻底移除CUA环境,步骤是:
(1)在Central System里,在SA38运行报表RSDELCUA,选中“Complete CUA and Test”选项后点击执行,如果确认要删除屏幕中显示的数据,则返回重新执行RSDELCUA,但不要勾选“Test”选项。
(2)在Central系统里,用WE20删除子系统在CUA里的数据,即删除信息类型为CCLONE和USERCLONE,如果信息类型只剩下SYNCH,则彻底删除该参数即可。
(3)在事务代码BD64里,删除CUA的分发模式。
(4)在所有的子系统里重复上面的步骤2和3。
(5)从所有的Communication User里移除CUA的角色:SAP_BC_USR_CUA_CENTRAL、SAP_BC_USR_CUA_CLIENT。
鉴于以上的操作,均可根据实际管理模式来做灵活调整。
四、结束语
由于CUA用户管理模式的简便性,使操作者摆脱了在每个SAP系统的不同集团中一一创建用户的烦恼,管理范围缩小,操作次数显著减少,实施过程的误操作带来的困扰已接近于零,使得SAP系统的管理更规范严谨,并节省大量的人力资源与时间资源,这种技术已经逐步得到了很多较大规模使用SAP产品的公司青睐,并已逐步应用于实际的管理操作模式中。
(责任编辑:苏宇嵬)