它的意图就是用户可以读和写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_BADI_SAMPLE.txt

一、为用户创建两个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的介绍，以及用户可以如何使用它。这个文档同样可以通过help.sap.com去访问，可以在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。

     对于在在线文档中之外提到的内容，还有以下这些：

1. 升级系统有关transport的BW note，检查这个component下的note,EPM-BPC-NW-TRA；
2. 通过note 1415296去进行检查，这是对于BPC安装以及transport的troubleshooting的概述，在遇到transport的问题时，应该首先通过这个note检查；

   在这当中特别提到了一个常见的问题，不要在EDW中，引用基于BW模型的BPC对象的技术名称；

3. 有关对于对象的删除，在由transport引入目标系统时，两种主要的对象类型采用不同的行为：

   表记录和数据模型(Application,Dimensions,Properties)如果在开发系统中被删除，而Appset被transport时，他们在目标系统中也会被删除 ；文件类型，比如script logic和excel的模板文件，只能被更新，也就是说当这些文件的修改被transport时，开发系统上对这些文件的删除不会影响测试机和生产机上的文件。如果在目标系统上删除这些文件也不会产生副作用； 
   

4. 如果在一个对象类型中去transport特定的对象是不支持的，目前BPC只能tranport appset而不能transport appset中的application；
   
5. 如果需要transport文件到其他的bpc系统，比如report、input schedule ，以下文章介绍的一个program可以帮助用户完成这个复制。
   
6. BPC的transport机制有若干种。推荐的是对最后一个好的transport进行传输。比如我们在开发机上进行了6次transport到测试机，用于构建appset，那么我们就可以用最后一个好的transport去在生产机上构建appset。BPC的transport框架可以收集所有appset级别的对象，这样可以减轻我们对于会遗漏某些对象的担心。

    在BPC的transport中应该避免的有：

1. 不要直接修改目标系统中的数据模型，一个典型的系统范围包括开发机、测试机、生产机。如果对于目标系统的对象要修改 ，从生产系统来源的transport是可以被分散的。数据模型的改变包括appset,application,dimension,perperties.如果用户希望直接维护测试机或者生产机上的模型，那么将不能使用BPC的transport框架，这样的话，report,input schedule,data manager package都不能直接使用。
2. 不要在RSA1中直接去修改BPC相关的数据模型，这些数据模型包括Appset(InfoArea),Application(Multiprovider,InfoCube),Dimension(InfoObject),Properties(InfoObjects)。如果做了这些修改，transport将会失败。在遇到这样的情况时，只能通过删除这个appset，然后再重新import这个appset 。这个操作可以参考以下文章。
3. 一定要注意到在不同的系统范围进行transport时，InfoCube/Multiprovider的技术名称是会改变的。BPC不会transport cube的技术名称，这样transport才能工作。所以基本规则就是，不要在EDW中基于BW模型，引用BPC生成的模型的技术名称。

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名称，选择恢复元数据表、主数据、交易数据。我们是在测试系统中恢复生产系统的BPC模型，所以没有勾选使用相同的技术名称。在交易数据量较大的情况下，恢复过程需要超过1小时的时间，所以注意执行此还原操作的用户权限，避免前台操作超时。

      在系统恢复完成之后，从BPC管理控制台登陆测试系统，选中维度库后，处理所有维度。

      之后选择。

      这个时候，我们就可以通过BPC Excel客户端连接测试系统并且刷新数据了。之后使用Park N Go功能将表单数据及主数据保存至静态表单。Park N Go中设置为静态数据和静态当前视图，就是将目前表单上所有通过EV函数取得的字符及数值都以静态数据的形式保存。在此状态下，表单的扩展及刷新功能将会被禁用。

      重新登陆至生产系统，发送数据，就可以将这张表单的数据恢复了。如果是前文提到的需要恢复某个Cube数据的话，就需要使用UJBR恢复BPC模型至生产系统，然后采用Data Manager的包复制或者导入交易数据。

如何配置和使用BPC的钻取Drill through

BPC的Drill through功能在75版本中就已经具备，简单言之，就是在BPC页面中，将上下文环境的维度成员作为参数，传递到预先设计好的Drill through地址。这个地址可以是一个普通的URL，通常会是BW Bex查询或者ECC的一个事务代码。BPC目前也只支持URL方式的跳转。

      1，到Bex Query的Drill through

      首先新建一个BW Query,ZDT_PLANNING，同时新建两个变量，分别对应科目编号和时间，ZDTACCT,ZDTTIME。在BPC Admin控制台中选择Drill through

Drill through是在Application级别的，所以定义时相应的维度也是这个Application中的维度，添加一个新的Drill through。当然了，首先要具备相应的Task access权限。

新建一个Drill through

在定义处填入URL，比如http: //:/sap/bw/bex?&query=

因为BW Query的参数是类似于VAR_NAME_1, VAR_VALUE_EXT_1，我们就通过定义这样的参数格式将BPC的参数值传递给BW Query。例如第一个参数值就是P_ACCT的成员ID，第二个参数值是TIME的成员ID。

点击测试按钮，参数名与参数值将会出现在如下窗口中，我们可以输入两个测试用的参数值。

运行测试，就会打开BW报表，参数值就是我们在测试窗口中输入的。

新建完毕这个drill through之后，我们就在evdre中新建一张报表来测试它。

鼠标点中某一个报表单元格，然后点击菜单上的drill through，当然用户已经具备执行drill through的相关task profile。

选中单元格的上下文维度成员会作为参数传递给BW报表，打开展示如下。

      2，到ECC事务的Drill through

      我们将新建一个到ECC FAGLB03事务的钻取，它所需要的参数是ECC的公司代码和科目代码。由于ECC的科目编号与BPC的科目编号未必是相同的，我们可以先新建相关的主数据属性来记录匹配关系。首先为维度P_CC新建一个ECC_COMP_CODE的属性。

维护主数据的相应属性值。

接下来为维度P_ACCT维护一个ECC_ACCT的属性，对应预算科目的ECC科目代码。

维护主数据的相应属性值。

定义一个新的drill through，如下图。

输入webgui访问事务的URL，实例如下http:// :/sap/bc/gui/sap/its/webgui?sap-language=EN&sap-client=&~transaction=

定义代表公司代码、科目、时间的参数，注意参数名是指定的，~okcode也是一个全局的参数，必须要被传送给显示程序的。

输入测试用的参数值。

可以看到在打开的web事务中，相应的参数值被传递给了事务FAGLB03。

接下来，还是新建一个evdre报表来测试这个钻取。

点击菜单上的Drill through之后，选取刚新建的这个钻取。

 所选中单元格数据的上下文维度成员属性值就被传递给了web事务，打开如下。

     通过上文介绍的两种方式，我们就可以定义一些钻取到BEX报表，或者ECC事务，对于数据的有效性做了一个很好的佐证。