bpc以及最佳实践
BPC 以及最佳实践
SAP BPC Roadmap详解⼀常⽤术语SAP BPC: SAP Business Planning and ConsolidationSAP BPC NW: SAP NetWeaver versionSAP BPC MS: SAP BPC Microsoft platform versionSAP BI –IP: BI Integrated PlanningBPS: Business Planning & SimulationSAP BPF: SAP Business Process FlowSAP ECC: SAP ERP Central ComponentBPC-UX/Client: BPC User Experience (Microsoft Excel, Word, PowerPoint and Web)ETL: Extract, Transform, Load, a data warehousing
process/Layer.BPC Ramp-up version: pre-release version. ⼆BPC history / platform /Road map· BPC, version for the Microsoft Platform (4.2 M, 5.1 M, and 7.0 M)· BPC, version for SAP NetWeaver(7.0 NW)· BPC Road map· 24 Apr 2009 : NW 7.0三BPS MS平台架构使⽤的基础服
务· MS SQL Server· MS SSAS (Analysis Services)· MS SSRS (Reporting Services)· MS SSIS (DTS)· .NET 1.1 Framework/Application Server· Web Server (IIS)· File Share 四NW平台架构五MS 7与NW 7的版本区别BPC MS and NW version Technical Terms
(组件)MSNWMS SQL ServerNetWeaver Database (MS SQL, Oracle, etc)MS Analysis ServicesNetWeav
er BI OLAP engineMS SQL Server Management StudioABAP Dictionary / BI Admin WorkbenchSQL Server Integration Services (SSIS)Process ChainsMS Reporting ServicesBusiness Explorer Report DesignerInternet Information Services
(IIS)NetWeaver Web Application ServerBPC MS and NW version Technical Terms (其
他)MSNWApplicationApplication InfoProviderDimensionInfoObjectMemberCharacteristic ValuePropertyAttributeEvDescriptionTextsSignedDataKey FigureMeasuresCalculated Key Figures六BPC的三种解决⽅案⽅案1 (MS + BI) ⽅案2 (BPC+BI) ⽅案3 (MS+ETL) BPC安装及配置的常见问题⼀，BPC安装的环境要求:A. 服务器安装要求ABAP应⽤服务器
-NW BI 7.0EHP1 -任何NW所⽀持的数据库系统
-任何NW所⽀持的操作系统 .NET应⽤服务器
-操作系统:Windows Server2003,Enterprise Edition(32-bit x86), Windows Server2003, Enterprise x64 Edition
Web服务器-Microsoft IIS 6.0，Microsoft IIS 7.0B. 客户端安装要求⽀持Windows XP(32-bit), Windows
Vista(32-bit&64-bit), Windows
7(32-bit&64-bit)BPC Web⽀持浏览器：
IE6,IE7,IE8BPC Office⽀持：Office2003(推荐使⽤),
www.doczj/doc/34c82b0c814d2b160b4e767f5acfa1c7ab008265.html framework 1.1⼆，BPC安装以后常见问题及配置:1, BPC Web界⾯⾸次登录，安装OSoftProcess插件，安装以后，才能正常显⽰所有客户端图标；2, BPC Excel 表单中开发⾃定义代码去调⽤后台⼆次开发程序时，需要安装SAPGUI，否则在运⾏
CreateObject("SAP.Functions.unicode")时会不能创建此对象；3, 设置excel安全性为低，由于BPC Excel端需要⽀持宏，进⾏设置会避免每次登录Excel客户端时都弹出安全提⽰。在此设置安全级别为低；4, 当企业内部使⽤代理服务器访问外⽹时，在IE中设置BPC Server地址为不经过代理的地址，这样会有效加快BPC客户端访问速度；5, 当客户系统中存在⽤户⾃定义的宏去访问后台⼆次开发代码时，检查当前客户端计算机名是否为英⽂，否则会导致objConnection.Logon(0, True)vba代码与后台ABAP服务器建⽴连接时出错；6, 当IE访问BPC Web时，不能弹出⽤户登录窗⼝。更改IE的安全设置；7, 在
Windows7/Vista 模式下，当⽤户从BPF界⾯登录⾄Excel客户端时，系统不能正确的携带预先设置的CurrentView信息。更改系统UAC 设置，可以参考SAP Note 1501591；在Win7环境下的设置：在Vista环境下的设置: 8, 当BPC客户端运⾏时，有
Framework报错。当⽤户正在运⾏BPC客户端时，偶尔会有以下系统错误提⽰出现，当出现此类错误时，需要关闭当前BPC 客户端，重新打开；9, 转储错误窗⼝提⽰。BPC客户端使⽤时，偶尔会出现如下转储错误窗⼝，关闭当前所有BPC进程，重新打开客户端。10, 客户端⾸次登录，提⽰对象错误。当安装好BPC客户端以后，登录时提⽰以下错误，这个是因为BPC没有安装成功，需要进⾏卸载和重新安装；11, 处理维度时出现报错，报错信息为
"CX_SY_OPEN_SQL_DB"。解决⽅法为在RSA1中调整⼀信息提供者属性，⾄于此项⽬被错误设置的原因不详。调整此属性为默认。12, 当⽤户在office2007环境下，遭遇excel 客户端长时间⽆法刷新，然后强⾏关闭excel客户端。之后从bpf⽹页链接⾄excel客户端时，会产⽣如下报错。且提⽰⽆法登录。解决⽅法为进⼊office2007的菜单，excel选项中，进⼊加载项。将禁⽤项启⽤。将COM选项添加。BPC 系统架构BPC是⽬前SAP在financial application领域主推的产品，由于从原有产品线发展⽽来，产品本⾝有两个版本，分别是基于MS OLAP平台和Netweaver OLAP平台。本⽂介绍的系统架构及功能只针对Netweaver平台产品。整个系统分为前台和abap后台。由于abap端的数据结构与 数据结构的差异，所以没有采⽤MVC架构，层次上约分为三层架构。abap端的数据服务是以Remote Function Call
的形式提供给前台。这⾥需要⽤到微软与SAP共同开发的⼀个visual studio插件，它的功能就是将abap端的RFC暴露给，同时提供两边数据结构的转换。这样在代码中，可以像访问⾃带的数据结构⼀样去访问abap端的数据结构。BPC的端是架构在IIS6.0上的，以web service 的形式向client端提供数
据，这⾥既包括CS结构的client，也有BS结构的client。关于安装以及⽀持平台的版本，可以详见installation guide。在BPC client中，和⽤户⾏为最为紧密的就是admin console和excel client。前者的功能主要包括：提供modeling⼯具，配置application 和dimension；安全模型的配置(⽤户、团队、⾓⾊)；管理application和dimension(重新构造dimension、优化application)。后者的功能主要包括：终端⽤户可以进⾏展⽰报表和数据输⼊；提供展⽰报表和数据输⼊(input schedule)的⼯具；进⾏⼤数据量数据的管理和其他系统管理功能。在 server层提供的功能包括：对于BPC client soap请求的⾝份认证；通过MSMQ 存储异步soap请求的状态；绑定abap的⽤户执⾏RFC call；从RFC接收请求结果，进⾏数据转换再返回给客户端。在abap层提供的功能包括：业务逻辑的处理；数据查询并返回；提供MDX 查询功能；作为⽂件系统提供存储功能；执⾏client ⾃定义的⽤户逻辑；向层提供RFC返回。层和abap 层的通讯如下图所⽰:层和abap层之间的通信是通过
RFC来实现的，每⼀个RFC call在后台都会需要⼀个dialog ⽤户进程。⽬前对于每⼀个BPC 服务器都是与⼀个abap活动实例⼀⼀对应的。这些配置的信息可以通过server manager来查看。SAP BPC的OLAP引擎⽐较(MS OLAP&BW OLAP)相对于SAP Netweaver的BW OLAP引擎，⼤家可能更加熟悉MS的OLAP引擎，所以我这⾥作⼀些概念上的类⽐。这样对于BW的⼀些概念就容易理解了。1，OLAP引擎类型因为这篇⽂章不是普及OLAP 和OLTP的区别，就不多做说明了。OLAP从实现机制上⾯分为ROLAP和MOLAP两种类型，前者的代表产品就是SQL Server所带的Analysis Service。⽽BW的OLAP
引擎是基于MOLAP的。这两种OLAP引擎的区别主要在于前者会在写会数据时，更新aggregate节点的值；⽽后者会在读取aggregate节点值时，才计算出它的值。换⾔之，ROLAP 的读取快，写回慢⽽MOLAP的读取慢，写回快。所以⼤致上⾯来说，BPC MS version的读取效率更⾼。2，术语区别由于BW也会⽀持⾏业内所同⾏的MDX标准查询语⾔，所以对于MS OLAP的概念，BW ⾥⾯都有相对应的概念，关系如下图所⽰：基于这个图表，也就可以看出两个不同版本的BPC产品在元数据上⾯的联系。这种联系在原来ms 版⽤户升级到nw版时尤为重要。从BPC产品的功能⾓度出发，下⾯是另⼀张图表，说明两个应⽤平台的联系：在SQL
Server 2005套件中，SQL Server Management Studio可以作为⼀个⼯作站组件，这是⽤来查看数据库，相应表、试图、存储过程的⼯具。⽽从ABAP数据词典中，也可以相对应查看表、视图、结构(structure)。此外，在SQL Server Management Studio中可以查看Analysis Service实例中的Cube、Dimension,⽽在BW的Data Warehouse Workbench(Tcode: RSA1)中也可以看到类似的结构。在SQL Server2005中，SSIS被作为DTS的替代者引⼊，它允许⽤户⾃定义数据流，并且控制数据转换的规则。SSIS 从SQL Server数据类型中导⼊data objects、tables、cubes、master data;⽽在BW中，可以通过Tcode：RSPC 来定义⾃⼰的数据流，通过process type来组装流程和⾃⼰编写转换规则。下⾯深⼊的看⼀下在Cube下⾯的⼀些概念对应：需要强调的是：在MS中的property相当于在BW中navigation attribute；⽽BPC中的Hierarchy并不是BI Hierarchy，BPC Hierarchy在技术上是Characteristic InfoObje
ct的master data表的⼀个attribute；(要理解这句话，⾸先你得知道InfoObject有两种类型，然后InfoObject 有三张对应表)在SAP BPC中，Time这个InfoObject作为Characteristic InfoObject。下⾯展⽰的图表是说明组成⼀个InfoCube的表结构：在Netweaver中的dimension table和BPC中的dimension是⼀⼀对应的；对于Fact table，这个对
应于Netweaver中的F-table；writeback table在功能上⾯与Netweaver infocube的open request联系。当数据需要从BPC的写回时，⾸先会被写到⼀张独⽴的表中。当Netweaver写回数据时，会把F-table中的数据切割成⽚，根据request id使⽤最近的request写回到cube中；Fact 2 table类似于E-table的⽤法，当使⽤BPC的Optimize功能时，系统会将数据从Write Back Table 移到Fact 2 Table。这种做法是为了提⾼性能。以上的概念讲解会体现在如何使⽤BPC Admin Console建模，以及不同的数据模型之间的关系上。
BPC NW版的应⽤程序优化(Application Optimization)当⽤户在BPC中新建⼀个appset和application以后，应⽤程序集中会存在越来越多的历史数据。BPC NW版所提供的优化流程会在Netweaver BI InfoCube上进⾏⼀系列的操作。在官⽅的帮助说明中，并没有提⽰说需要做优化的频率，但是最好定期进⾏应⽤程序集的优化。BPC系统提供了两种优化类型：1，轻量级优化(Light Optimize)：关闭打开的请求，对Cube进⾏压缩，重建索引，更新BI Cube的数据库相关变量；2，全优化(Full Optimize)：会包含所有轻量级优化的操作。与此同时，系统会检查BI模型，如果符合优化条件，全优化会进⾏额外操作。
这些操作包括: A, 把当前的Appset 置成离线；B, 建⽴⼀个新的拥有优化数据模型的Cube；C,
将源Cube的数据复制到新的Cube，删除原Cube；D, 将打开的请求关掉，压缩并重建Cube索引，更新数据库的相关变量；E，将新建的Cube置成在线。Cube数据的压缩是通过两张事实表的数据切换完成的，在SAP BI中有两张事实表，(E表中存储的是已压缩数据，F表中存储的是⾮压缩数据)。当进⾏Cube压缩时，系统会将多条相等的数据合并成⼀条，这样做可以节约数据库存储的空间。这些数据就会从F事实表转移到E事实表。当进⾏全量优化时，Cube如果符合重建的条件，系统新建另⼀个Cube，这样Cube的tech name⾃然会被更新，与此技术名相关的表名及内容也会被更新。但是，comment表和workstatus 表，这两张表的名字是由当前appset的prefix name加上cube 的prefix name⽣成的，当新建cube，tech name更改后，prefix name 不会被更改，所以comment表和workstatus 表都⽆需更改。以上介绍的是在BPC系统中，两种优化模型的理论基础，下⾯是在系统中进⾏配置和运⾏优化的流程: 1, 在BW处理链的查看界⾯中，可以查看到这两条⽤于优化的处理链本⾝; 2, 在Data manager中新建⼀个执⾏这个处理链的包: 3, 新建⼀个执⾏包：4, 轻量级优化的执⾏包新建成功: 5, 执⾏这个包，可以像执⾏其他包⼀样定制定期执⾏: 6, 在Admin console中也可以直接去执⾏这个优化操作，如图：7, 执⾏结果如图:
在BPC NW中何时使⽤Write back BADI在BPC75中，系统增加了很多⽤户⾃定义函数开发的接⼝，这其中就包括write back 的BADI接⼝。当前，最新的BPC75NW的⽀持包是SP4，但是在75的前期版本中，
都已经带有这个开发接⼝了。这个开发接⼝本⾝并不是强制要实现的。在没有实现write back BADI的前提下，我们依然可以可以通过正常的input schedule, data
manager package, comment去向数据库发送数据。Write back BADI是在我们需要加强系统⾃带的写回功能时，需要执⾏⾃定义的逻辑时去实现的。
举⼀个按照Entity来做财务预算的例⼦说明，我们在Entity 这个dimension上有⼀个层次结构，Worldwide是根节点，下⾯有亚洲、欧洲、美洲这⼏个⼦节点，然后再往下每个节点⼜有若⼲个国家的⼦节点。也就是说，在Entity这个dimension上，base level都是⼀些国家的节点。通常情况下，我们做预算的情况是，由每个国家的⼦节点输⼊数据，然后报表可以累加计算出top level的预算值，这是由于我们只能在base level的节点上post data。这是⼀个bottom-up 预算的实例，但是我们不能做到反向，也就是top-down的预算流程。这种情况下，我们就可以通过实现write back BADI去完成⼀个分发的逻辑，将top level上⾯的数据值按照指定的算法分发到⼦节点上。⽐如在member的定义中，我们就可以专门指定⼀个属性去代表每⼀个member的分配
权重，或者也可以根据去年同期实际数据做⼀个分发的逻辑。
再举⼀个复合的安全模型为例，在BPC的安全模型中，有⼀条基本的规则是，当dimension不同的安全规则叠加时，最⼩的限制条件起作⽤。我们有⼀个A的member access profile，设置如下：Category =
Plan
Read/Write Time = 2009.OCT Read/Write Time = [ALL] Read
它的意图是要在plan这个category⾥⾯，⽤户可以
查看所有时间的数值，但是只能写⼊2009.OCT这个时间区间的数值。同时还有另⼀个B的member access profile，
设置如下：
Category = Forecast Read/Write Time = [ALL]
Read/Write 它的意图就是⽤户可以读和写forecast
⾥所有时间区间值。
如果上述的两个member access profile是分配给不
同的⽤户是没有问题的。但是如果当他们被分配给了同⼀个⽤户的时候，就有会冲突了。管理员的意图是想限制在plan ⾥⾯⽤户只能数据写到2009.OCT⾥⾯，但是当⽤户有了这两个member access profile
以后，⽤户就可以写回数据到
别的时间区间了，⽐如2009.APR。⽽这并不是管理员设计这样的安全模型的本意了。
在这种情况下，我们可以通过实现Write back BADI
来处理。Write back BADI是⼀个pre-process BADI，它会在所有的BPC检查(security check,validation check,work status check)开始之前被调⽤。所以在调⽤安全模型检查之前，write back BADI就被调⽤到了。所以在这⾥我们可以根据需要，去绕过标准的安全模型。
顺便提下UJR_WRITE_BACK的filter参数，包括APPSET_ID,APPLICATION_ID,MODULE_ID，前两个是必须要有
的，module可以是Manual planning, journals, data manager, comment, etc.
在BPC NW中何时使⽤Shared Query Engine BADI对于BPC系统的读写接⼝来说，都提供了可供⽤户⾃定义开发的BADI接⼝，SQE的BADI会在系统查询后调⽤，此时⽤户可以根据需求进⼀步筛选数据。⽐较典型的应⽤是矩阵式的安全模型。BPC 的Member Access Profile只提供了对独⽴的维度成员权限控制，当⽤户需要在不同的两个维度上作交叉的成员权限控制
时，Member Access Profile就不能够满⾜需求了。举例如下：地区维度有成员美国(US)和欧洲(EMEA)，账户维度有成员个⼈费⽤(Personal Costs)和⼴告费⽤(Advertising Costs)。某⽤户只被允许去查看美国的个⼈费⽤和欧洲的⼴告费⽤。BPC的Member Access Profile只能针对某⼀个维度的某些成员赋予权限控制，如果⽤户可以访问地区维度的美国和欧洲，以及账户维度的个⼈
费⽤和⼴告费⽤，那么他就可以看到美国的⼴告费⽤以及欧洲的个⼈费⽤。⽽这是我们需求中所不允许的。下⾯将从BW端新建SQE的BADI讲起，直到在BPC中新建report来检查是否实现了此功能。⼀、登录BW端，进⼊SE18界⾯：⼆、显⽰这个BADI的定义，展开定义树：三、创建此BADI定义的⼀个实现体：四、输⼊enhancement implementation的名字和描述：五、此时，需要指定如需这个BADI要传输则开发包是什么，或者不参与传输时作为local object存储：六、指定BADI implementation的名字、描述及实现类，同样也要指定开发包：七、现在就新建出了⼀个BADI implementation，但是还没有激活的内容：⼋、打开BADI implementation的菜单树：九、双击下⾯的"Filter Val"：⼗、选中编辑按钮，然后点击"Combination"：⼗⼀、选中显⽰的两个参数：⼗⼆、双击"Application_ID"这⼀⾏，然后输⼊filter的值：⼗三、然后为"APPSET_ID"输⼊filter 值，保存并激活已经更改的这些对象；⼗四、在BADI implementation中双击"Implementing Class"：⼗五、双击implementing class的名字：⼗六、选择编辑这个类，然后双击"POST_PROCESS"⽅法名，加⼊实现⽅法代码：
具体代码在附件中，激活刚刚新建的类。接下来就可以在BPC的报表中看到如上需求的结果了。
/Files/libihui422/SQE_⼀、为⽤户创建两
个Member Access Profile，⼀个叫US_MAP，可以访问地区维度的US和账户维度的个⼈费⽤(CE0004000)。另⼀个叫EMEA_MAP，可以访问地区维度的EMEA和账户维度的⼴告费⽤(CE0004200)：⼆、先展⽰⼀下当我们前⾯新建的SQE BADI没有⽣效时，两条规则对于同⼀个⽤户是叠加的，⽤户可以读取到US和EMEA⾥⾯两个账户的所有值：三、当新建的SQE BADI⽣效后，报表内容就改变了：
BPC的传输(transport)PC作为基于SAP Netweaver平台的产品，⾃然可以运⽤transport机制去进⾏系统范围内(开发机-测试机-⽣产机)的transport。但是BPC的transport与标准的过程⼜不是完全相同，本⽂旨在对此做⼀些介绍。
⾸先介绍下有关BPC的transport机制的资料，⽤户可以通过service market place上⾯的operation guide查，在线帮助的Section5.1就是对于transport的介绍，以及⽤户可
以如何使⽤它。这个⽂档同样可以通过www.doczj/doc/34c82b0c814d2b160b4e767f5acfa1c7ab008265.html 去访问，可以在SAP Business Objects的tab下，在Planning and Consolidation下⾯到Installation,Upgrade,Master and Operations Guides.⽐如对于TLOGO的对象类型“team”，
它在开发系统中被创建出来，但是从不来不会被transport。⽤户在team⾥⾯的分配是不会被transport的，因为可以访问开发机的⽤户未必与访问⽣产机的⽤户是同样的⼈。因此，TLOGO对象只对于在开发机和⽣产机上都存在且同名时起
作⽤，这时，team可以被transport到⽬标系统上，这⾥⾯就包括在team⾥⾯的transformation file和conversion file。对于在在线⽂档中之外提到的内容，还有以下这些：升级系统有关transport的BW note，检查这个component下的note,EPM-BPC-NW-TRA；通过note 1415296去进⾏检查，这是对于BPC安装以及transport的troubleshooting的概述，在遇到transport的问题时，应该⾸先通过这个note检查；在这当中特别提到了⼀个常见的问题，不要在EDW中，引⽤基于BW模型的BPC对象的技术名称；有关对于对象的
删除，在由transport引⼊⽬标系统时，两种主要的对象类型采⽤不同的⾏为：表记录和数据模型
(Application,Dimensions,Properties)如果在开发系统中被删除，⽽Appset被transport时，他们在⽬标系统中也会被删除；⽂件类型，⽐如script logic和excel的模板⽂件，只
能被更新，也就是说当这些⽂件的修改被transport时，开发系统上对这些⽂件的删除不会影响测试机和⽣产机上的⽂件。如果在⽬标系统上删除这些⽂件也不会产⽣副作⽤；
如果在⼀个对象类型中去transport特定的对象是不⽀持的，⽬前BPC只能tranport appset⽽不能transport appset中
的application；
如果需要transport⽂件到其他的bpc系统，⽐如report、input schedule ，以下⽂章介绍的⼀个program可以帮助⽤
户完成这个复制。
<www.doczj/doc/34c82b0c814d2b160b4e767f5acfa1c7ab008265.html /irj/scn/index?rid=/library/uuid/0 096026f-7fc4-2c10-5c92-e75f4c13ca10>
BPC的transport机制有若⼲种。推荐的是对最后⼀个好的transport进⾏传输。⽐如我们在开发机上进⾏了6次transport到测试机，⽤于构建appset，那么我们就可以⽤最后⼀个好的transport去在⽣产机上构建appset。BPC的transport框架可以收集所有appset级别的对象，这样可以减轻我们对于会遗漏某些对象的担⼼。在BPC的transport中应该避免的有：不要直接修改⽬标系统中的数据模型，⼀个典型的系统范围包括开发机、测试机、⽣产机。如果对于⽬标系统的对象要修改，从⽣产系统来源的transport是可以被分散的。数据模型的改变包括
appset,application,dimension,perperties.如果⽤户希望直接维护测试机或者⽣产机上的模型，那么将不能使⽤BPC的transport 框架，这样的话，report,input schedule,data manager package都不能直接使⽤。不要在RSA1中直接去修改BPC相关的数据模型，这些数据模型包括
Appset(InfoArea),Application(Multiprovider,InfoCube),Dim ension(InfoObject),Properties(InfoObjects)。如果做了这些修
改，transport将会失败。在遇到这样的情况时，只能通过删除这个appset，然后再重新import这个appset 。这个操
作可以参考以下⽂章。
<www.doczj/doc/34c82b0c814d2b160b4e767f5acfa1c7ab008265.html /irj/scn/weblogs?blog=/pub/wlg/ 17532>⼀定要注意到在不同的系统范围进⾏transport时，InfoCube/Multiprovider的技术名称是会改变的。BPC不会transport cube的技术名称，这样transport才能⼯作。所以基本规则就是，不要在EDW中基于BW模型，引⽤BPC
⽣成的模型的技术名称。BPC的BPF传输
BPF作为BPC系统中最重要的功能之⼀，在系统的实施过程中，很有可能需要对此部分进⾏多次传输。
mvc和三层架构的理解虽然表单也会多次更
改，但是上传表单本⾝是⽐较容易保持⼀致的。BPF 部分由于模板ID是在新建/修改模板时，即时⽣成的GUID，只有通过传输，才能保证多系统之间的⼀致性。单独对这个部分进⾏说明，但是整个过程是⽆论对什么BPC object传
输都是⼀样的。⼀、设置⽬标appset为不可⽤；⼆、在⽬
标系统的BPF管理界⾯上，归档已存在的实例，注意BPF
实例不能直接从活动状态设置为归档状态。需要将实例先从活动状态设为不活动状态，然后再从不活动状态归档。如果在系统上有很多已存在实例，可以后台⾃⼰开发⼀个程序去批量进⾏实例的归档；三、在⽬标系统的BW端，在传输配置表中设置要进⾏传输的BPC Object，这⾥只将BPF设为D(可传输的)。这样在BPC传输后，系统只进⾏BPF相关部分的释放；四、在源系统BW端，进⼊BPC传输打包程序；
选择“直接下达请求”，此程序会在打包请求结束后，直接释
放此请求；打包结束后；此时也可以在se09中，查看到系
统⾃动释放的已打包请求；五、在⽬标系统的BW端，对BPC的⽤户、权限相关信息进⾏备份；只需要
导出⽤户、⽤户团队匹配、TaskProfile匹配、MemberAccessProfile匹配⽂件，有了这⼏个匹配⽂件，系统会⾃动创建相应的团队、TaskProfile、MemberAccessProfile⽂件；六、在⽬标系统的BW端，进⼊STMS传输打包的请求；选择要导⼊此请求的⽬标端；选中刚才打包的请求；在Options中选中前⾯四项；七、当传输结束以后，进⼊⽬标系统的Admin console，可以看到所有BPF模板都是未激活状态，在激活之前，⽤户需要去将Template Access信息设置完整。如果系统中的模板数量很多的话，可以开发⾃定义程序去批量填充此项信息。完成了此项操作以后，⽤户就可以在⽬标的BPC系统中新
建所需要BPF模板的实例了。
BPC系统备份及恢复BPC系统作为基于BW的产品，但是由于在维度、属性等若⼲概念上与BW的差别，在传输、复制、备份恢复⽅⾯都难以沿⽤BW的传统策略。举⼀个例⼦，如果我们需要在⽣产系统中恢复某⼀个时间点的BPC Cube 中的交易数据，即便我们能将数据还原⾄新的Cube，Cube 之间的数据切换依然需要遵循传统的BW ETL策略，我们要建⽴
dtp,transformation⽂件，并且需要依次将这些模型传
输⾄⽣产机后才能使⽤。BPC本⾝提供了⼀个备份和恢复的⼯具，它可以较为⽅便的实现主数据、交易数据的备份及恢复，甚⾄某种程度的替代传输的功能。本篇⽂章的假定环境是，在⽣产机发现某些BPC表单上的数据被误清零后，如何恢复。这样的情景与整个cube的恢复相⽐，在BPC 所运⽤的预算过程
中遇到的可能性更⼤。且通过BPC Data Manager的Package，也可以⾜够实现两个Cube之间的数据复制。进⼊BW后端，输⼊T-Code:UJBR 按照如图所选，⼀般在备份时会勾选所有选项，元数据表、主数据、交易数据，建议每天进⾏BPC系统备份。我们可以点击程序菜单下的“后台执⾏”选项，之后选择要执⾏的⽇期和时间。这样每天服务器都会备份⼀个压缩包⾄服务器上的指定地址。如需保留多个备份压缩包，则需要修改每天备份的压缩包名称，避免覆盖。当某时刻发现BPC ⽣产系统中⼀些预算表单数据丢失后，保险起见，我们并不会直接在⽣产系统中去恢复这些数据。甚⾄，我们也不会恢复⼀个⽆关的AppSet在⽣产系统中。通过BPC的备份恢复⼯具，我们可以恢复BPC相关模型及数据在任⼀BPC环境下。这也就是这个备份恢复⼯具在某种程度下可以实现传输的原因。还是进⼊T-Code:UJBR 下载需要还原的备份压缩包，之后输⼊需要还原后的AppSet名称，选择恢复元数据表、主数据、交易数据。我们是在测试系统中恢复⽣

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。