道教皈依证免门票:BPC 以及最佳实践
来源:百度文库 编辑:偶看新闻 时间:2024/04/29 13:00:33
SAP BPC Roadmap详解
一 常用术语
SAP BPC: SAP Business Planning and Consolidation
SAP BPC NW: SAP NetWeaver version
SAP BPC MS: SAP BPC Microsoft platform version
SAP BI –IP: BI Integrated Planning
BPS: Business Planning & Simulation
SAP BPF: SAP Business Process Flow
SAP ECC: SAP ERP Central Component
BPC-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 ServicesNetWeaver 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 Server
BPC MS and NW version Technical Terms (其他)MSNWApplicationApplication InfoProviderDimensionInfoObjectMemberCharacteristic ValuePropertyAttributeEvDescriptionTextsSignedDataKeyFigureMeasuresCalculated 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.0
B. 客户端安装要求
支持Windows XP(32-bit), Windows Vista(32-bit&64-bit), Windows 7(32-bit&64-bit)
BPC Web支持浏览器:
IE6,IE7,IE8
BPC Office支持:
Office2003(推荐使用), Office2007
.net 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客户端运行时,有.net 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平台产品。 整个系统分为.net前台和abap后台。由于abap端的数据结构与.net数据结构的差异,所以没有采用MVC架构,层次上约分为三层架构。abap端的数据服务是以Remote Function Call的形式提供给前台。这里需要用到微软与SAP共同开发的一个visual studio插件,它的功能就是将abap端的RFC暴露给.net,同时提供两边数据结构的转换。这样在.net代码中,可以像访问自带的数据结构一样去访问abap端的数据结构。 BPC的.net端是架构在IIS6.0上的,以web service的形式向client端提供数据,这里既包括CS结构的client,也有BS结构的client。关于安装以及支持平台的版本,可以详见installation guide。在BPC client中,和用户行为最为紧密的就是admin console和excel client。前者的功能主要包括: 后者的功能主要包括: 在.net server层提供的功能包括: 在abap层提供的功能包括: .net层和abap层的通讯如下图所示: .net层和abap层之间的通信是通过RFC来实现的,每一个RFC call在后台都会需要一个dialog用户进程。目前对于每一个BPC .net服务器都是与一个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 InfoObject的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 它的意图就是用户可以读和写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。 对于在在线文档中之外提到的内容,还有以下这些: 在这当中特别提到了一个常见的问题,不要在EDW中,引用基于BW模型的BPC对象的技术名称; 表记录和数据模型(Application,Dimensions,Properties)如果在开发系统中被删除,而Appset被transport时,他们在目标系统中也会被删除 ;文件类型,比如script logic和excel的模板文件,只能被更新,也就是说当这些文件的修改被transport时,开发系统上对这些文件的删除不会影响测试机和生产机上的文件。如果在目标系统上删除这些文件也不会产生副作用; 在BPC的transport中应该避免的有: BPF作为BPC系统中最重要的功能之一,在系统的实施过程中,很有可能需要对此部分进行多次传输。虽然表单也会多次更改,但是上传表单本身是比较容易保持一致的。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名称,选择恢复元数据表、主数据、交易数据。我们是在测试系统中恢复生产系统的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: // 因为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:// 定义代表公司代码、科目、时间的参数,注意参数名是指定的,~okcode也是一个全局的参数,必须要被传送给显示程序的。 输入测试用的参数值。 可以看到在打开的web事务中,相应的参数值被传递给了事务FAGLB03。 接下来,还是新建一个evdre报表来测试这个钻取。 点击菜单上的Drill through之后,选取刚新建的这个钻取。 所选中单元格数据的上下文维度成员属性值就被传递给了web事务,打开如下。 通过上文介绍的两种方式,我们就可以定义一些钻取到BEX报表,或者ECC事务,对于数据的有效性做了一个很好的佐证。
BPC的BPF传输