bpc以及最佳实践.docx

bpc以及最佳实践.docx

《bpc以及最佳实践.docx》由会员分享，可在线阅读，更多相关《bpc以及最佳实践.docx（12页珍藏版）》请在冰豆网上搜索。

bpc以及最佳实践

BPC以及最佳实践

SAPBPCRoadmap详解一常用术语SAPBPC:

SAPBusinessPlanningandConsolidationSAPBPCNW:

SAPNetWeaverversionSAPBPCMS:

SAPBPCMicrosoftplatformversionSAPBI–IP:

BIIntegratedPlanningBPS:

BusinessPlanning&SimulationSAPBPF:

SAPBusinessProcessFlowSAPECC:

SAPERPCentralComponentBPC-UX/Client:

BPCUserExperience（MicrosoftExcel,Word,PowerPointandWeb）ETL:

Extract,Transform,Load,adatawarehousingprocess/Layer.BPCRamp-upversion:

pre-releaseversion.二BPChistory/platform/Roadmap·BPC,versionfortheMicrosoftPlatform（4.2M,5.1M,and7.0M）·BPC,versionforSAPNetWeaver（7.0NW）·BPCRoadmap·24Apr2009:

NW7.0三BPSMS平台架构使用的基础服务·MSSQLServer·MSSSAS（AnalysisServices）·MSSSRS（ReportingServices）·MSSSIS（DTS）·.NET1.1Framework/ApplicationServer·WebServer（IIS）·FileShare四NW平台架构五MS7与NW7的版本区别BPCMSandNWversionTechnicalTerms（组件）MSNWMSSQLServerNetWeaverDatabase（MSSQL,Oracle,etc）MSAnalysisServicesNetWeaverBIOLAPengineMSSQLServerManagementStudioABAPDictionary/BIAdminWorkbenchSQLServerIntegrationServices（SSIS）ProcessChainsMSReportingServicesBusinessExplorerReportDesignerInternetInformationServices（IIS）NetWeaverWebApplicationServerBPCMSandNWversionTechnicalTerms（其他）MSNWApplicationApplicationInfoProviderDimensionInfoObjectMemberCharacteristicValuePropertyAttributeEvDescriptionTextsSignedDataKeyFigureMeasuresCalculatedKeyFigures六BPC的三种解决方案方案1（MS+BI）方案2（BPC+BI）方案3（MS+ETL）BPC安装及配置的常见问题一，BPC安装的环境要求:

A.服务器安装要求ABAP应用服务器-NWBI7.0EHP1-任何NW所支持的数据库系统-任何NW所支持的操作系统.NET应用服务器-操作系统:

WindowsServer2003,EnterpriseEdition（32-bitx86）,WindowsServer2003,Enterprisex64EditionWeb服务器-MicrosoftIIS6.0，MicrosoftIIS7.0B.客户端安装要求支持WindowsXP（32-bit）,WindowsVista（32-bit&64-bit）,Windows7（32-bit&64-bit）BPCWeb支持浏览器：

IE6,IE7,IE8BPCOffice支持：

Office2003（推荐使用）,Oframework1.1二，BPC安装以后常见问题及配置:

1,BPCWeb界面首次登录，安装OSoftProcess插件，安装以后，才能正常显示所有客户端图标；2,BPCExcel表单中开发自定义代码去调用后台二次开发程序时，需要安装SAPGUI，否则在运行CreateObject（"SAP.Functions.unicode"）时会不能创建此对象；3,设置excel安全性为低，由于BPCExcel端需要支持宏，进行设置会避免每次登录Excel客户端时都弹出安全提示。

在此设置安全级别为低；4,当企业内部使用代理服务器访问外网时，在IE中设置BPCServer地址为不经过代理的地址，这样会有效加快BPC客户端访问速度；5,当客户系统中存在用户自定义的宏去访问后台二次开发代码时，检查当前客户端计算机名是否为英文，否则会导致objConnection.Logon（0,True）vba代码与后台ABAP服务器建立连接时出错；6,当IE访问BPCWeb时，不能弹出用户登录窗口。

更改IE的安全设置；7,在Windows7/Vista模式下，当用户从BPF界面登录至Excel客户端时，系统不能正确的携带预先设置的CurrentView信息。

更改系统UAC设置，可以参考SAPNote1501591;在Win7环境下的设置:

在Vista环境下的设置:

8,当BPC客户端运行时，有.netFramework报错。

当用户正在运行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在financialapplication领域主推的产品，由于从原有产品线发展而来，产品本身有两个版本，分别是基于MSOLAP平台和NetweaverOLAP平台。

本文介绍的系统架构及功能只针对Netweaver平台产品。

整个系统分为.net前台和abap后台。

由于abap端的数据结构与.net数据结构的差异，所以没有采用MVC架构，层次上约分为三层架构。

abap端的数据服务是以RemoteFunctionCall的形式提供给前台。

这里需要用到微软与SAP共同开发的一个visualstudio插件，它的功能就是将abap端的RFC暴露给.net，同时提供两边数据结构的转换。

这样在.net代码中，可以像访问自带的数据结构一样去访问abap端的数据结构。

BPC的.net端是架构在IIS6.0上的，以webservice的形式向client端提供数据，这里既包括CS结构的client,也有BS结构的client。

关于安装以及支持平台的版本，可以详见installationguide。

在BPCclient中，和用户行为最为紧密的就是adminconsole和excelclient。

前者的功能主要包括:

提供modeling工具，配置application和dimension；安全模型的配置（用户、团队、角色）；管理application和dimension（重新构造dimension、优化application）。

后者的功能主要包括:

终端用户可以进行展示报表和数据输入；提供展示报表和数据输入（inputschedule）的工具；进行大数据量数据的管理和其他系统管理功能。

在.netserver层提供的功能包括:

对于BPCclientsoap请求的身份认证；通过MSMQ存储异步soap请求的状态；绑定abap的用户执行RFCcall；从RFC接收请求结果，进行数据转换再返回给客户端。

在abap层提供的功能包括:

业务逻辑的处理；数据查询并返回；提供MDX查询功能；作为文件系统提供存储功能；执行client自定义的用户逻辑；向.net层提供RFC返回。

.net层和abap层的通讯如下图所示:

.net层和abap层之间的通信是通过RFC来实现的，每一个RFCcall在后台都会需要一个dialog用户进程。

目前对于每一个BPC.net服务器都是与一个abap活动实例一一对应的。

这些配置的信息可以通过servermanager来查看。

SAPBPC的OLAP引擎比较（MSOLAP&BWOLAP）相对于SAPNetweaver的BWOLAP引擎，大家可能更加熟悉MS的OLAP引擎，所以我这里作一些概念上的类比。

这样对于BW的一些概念就容易理解了。

1，OLAP引擎类型因为这篇文章不是普及OLAP和OLTP的区别，就不多做说明了。

OLAP从实现机制上面分为ROLAP和MOLAP两种类型，前者的代表产品就是SQLServer所带的AnalysisService。

而BW的OLAP引擎是基于MOLAP的。

这两种OLAP引擎的区别主要在于前者会在写会数据时，更新aggregate节点的值；而后者会在读取aggregate节点值时，才计算出它的值。

换言之，ROLAP的读取快，写回慢而MOLAP的读取慢，写回快。

所以大致上面来说，BPCMSversion的读取效率更高。

2，术语区别由于BW也会支持行业内所同行的MDX标准查询语言，所以对于MSOLAP的概念，BW里面都有相对应的概念，关系如下图所示：

基于这个图表，也就可以看出两个不同版本的BPC产品在元数据上面的联系。

这种联系在原来ms版用户升级到nw版时尤为重要。

从BPC产品的功能角度出发，下面是另一张图表，说明两个应用平台的联系：

在SQLServer2005套件中，SQLServerManagementStudio可以作为一个工作站组件，这是用来查看数据库，相应表、试图、存储过程的工具。

而从ABAP数据词典中，也可以相对应查看表、视图、结构（structure）。

此外，在SQLServerManagementStudio中可以查看AnalysisService实例中的Cube、Dimension,而在BW的DataWarehouseWorkbench（Tcode:

RSA1）中也可以看到类似的结构。

在SQLServer2005中，SSIS被作为DTS的替代者引入，它允许用户自定义数据流，并且控制数据转换的规则。

SSIS从SQLServer数据类型中导入dataobjects、tables、cubes、masterdata;而在BW中，可以通过Tcode：

RSPC来定义自己的数据流，通过processtype来组装流程和自己编写转换规则。

下面深入的看一下在Cube下面的一些概念对应：

需要强调的是：

在MS中的property相当于在BW中navigationattribute；而BPC中的Hierarchy并不是BIHierarchy，BPCHierarchy在技术上是CharacteristicInfoObject的masterdata表的一个attribute；（要理解这句话，首先你得知道InfoObject有两种类型，然后InfoObject有三张对应表）在SAPBPC中，Time这个InfoObject作为CharacteristicInfoObject。

下面展示的图表是说明组成一个InfoCube的表结构：

在Netweaver中的dimensiontable和BPC中的dimension是一一对应的;对于Facttable，这个对应于Netweaver中的F-table；writebacktable在功能上面与Netweaverinfocube的openrequest联系。

当数据需要从BPC的写回时，首先会被写到一张独立的表中。

当Netweaver写回数据时，会把F-table中的数据切割成片，根据requestid使用最近的request写回到cube中；Fact2table类似于E-table的用法，当使用BPC的Optimize功能时，系统会将数据从WriteBackTable移到Fact2Table。

这种做法是为了提高性能。

以上的概念讲解会体现在如何使用BPCAdminConsole建模，以及不同的数据模型之间的关系上。

BPCNW版的应用程序优化（ApplicationOptimization）当用户在BPC中新建一个appset和application以后，应用程序集中会存在越来越多的历史数据。

BPCNW版所提供的优化流程会在NetweaverBIInfoCube上进行一系列的操作。

在官方的帮助说明中，并没有提示说需要做优化的频率，但是最好定期进行应用程序集的优化。

BPC系统提供了两种优化类型：

1，轻量级优化（LightOptimize）:

关闭打开的请求，对Cube进行压缩，重建索引，更新BICube的数据库相关变量；2，全优化（FullOptimize）:

会包含所有轻量级优化的操作。

与此同时，系统会检查BI模型，如果符合优化条件，全优化会进行额外操作。

这些操作包括:

A,把当前的Appset置成离线；B,建立一个新的拥有优化数据模型的Cube；C,将源Cube的数据复制到新的Cube,删除原Cube；D,将打开的请求关掉，压缩并重建Cube索引，更新数据库的相关变量；E,将新建的Cube置成在线。

Cube数据的压缩是通过两张事实表的数据切换完成的，在SAPBI中有两张事实表，（E表中存储的是已压缩数据，F表中存储的是非压缩数据）。

当进行Cube压缩时，系统会将多条相等的数据合并成一条，这样做可以节约数据库存储的空间。

这些数据就会从F事实表转移到E事实表。

当进行全量优化时，Cube如果符合重建的条件，系统新建另一个Cube，这样Cube的techname自然会被更新，与此技术名相关的表名及内容也会被更新。

但是，comment表和workstatus表，这两张表的名字是由当前appset的prefixname加上cube的prefixname生成的，当新建cube，techname更改后，prefixname不会被更改，所以comment表和workstatus表都无需更改。

以上介绍的是在BPC系统中，两种优化模型的理论基础，下面是在系统中进行配置和运行优化的流程:

1,在BW处理链的查看界面中，可以查看到这两条用于优化的处理链本身;2,在Datamanager中新建一个执行这个处理链的包:

3,新建一个执行包：

4,轻量级优化的执行包新建成功:

5,执行这个包，可以像执行其他包一样定制定期执行:

6,在Adminconsole中也可以直接去执行这个优化操作，如图：

7,执行结果如图:

在BPCNW中何时使用WritebackBADI在BPC75中，系统增加了很多用户自定义函数开发的接口，这其中就包括writeback的BADI接口。

当前，最新的BPC75NW的支持包是SP4，但是在75的前期版本中，都已经带有这个开发接口了。

这个开发接口本身并不是强制要实现的。

在没有实现writebackBADI的前提下，我们依然可以可以通过正常的inputschedule,datamanagerpackage,comment去向数据库发送数据。

WritebackBADI是在我们需要加强系统自带的写回功能时，需要执行自定义的逻辑时去实现的。

举一个按照Entity来做财务预算的例子说明，我们在Entity这个dimension上有一个层次结构，Worldwide是根节点，下面有亚洲、欧洲、美洲这几个子节点，然后再往下每个节点又有若干个国家的子节点。

也就是说，在Entity这个dimension上，baselevel都是一些国家的节点。

通常情况下，我们做预算的情况是，由每个国家的子节点输入数据，然后报表可以累加计算出toplevel的预算值，这是由于我们只能在baselevel的节点上postdata。

这是一个bottom-up预算的实例，但是我们不能做到反向，也就是top-down的预算流程。

这种情况下，我们就可以通过实现writebackBADI去完成一个分发的逻辑，将toplevel上面的数据值按照指定的算法分发到子节点上。

比如在member的定义中，我们就可以专门指定一个属性去代表每一个member的分配权重，或者也可以根据去年同期实际数据做一个分发的逻辑。

再举一个复合的安全模型为例，在BPC的安全模型中，有一条基本的规则是，当dimension不同的安全规则叠加时，最小的限制条件起作用。

我们有一个A的memberaccessprofile,设置如下：

Category=PlanRead/WriteTime=2009.OCTRead/WriteTime=[ALL]Read

它的意图是要在plan这个category里面，用户可以查看所有时间的数值，但是只能写入2009.OCT这个时间区间的数值。

同时还有另一个B的memberaccessprofile，设置如下：

Category=ForecastRead/WriteTime=[ALL]Read/Write它的意图就是用户可以读和写forecast里所有时间区间值。

如果上述的两个memberaccessprofile是分配给不同的用户是没有问题的。

但是如果当他们被分配给了同一个用户的时候，就有会冲突了。

管理员的意图是想限制在plan里面用户只能数据写到2009.OCT里面，但是当用户有了这两个memberaccessprofile以后，用户就可以写回数据到别的时间区间了，比如2009.APR。

而这并不是管理员设计这样的安全模型的本意了。

在这种情况下，我们可以通过实现WritebackBADI来处理。

WritebackBADI是一个pre-processBADI，它会在所有的BPC检查（securitycheck,validationcheck,workstatuscheck）开始之前被调用。

所以在调用安全模型检查之前，writebackBADI就被调用到了。

所以在这里我们可以根据需要，去绕过标准的安全模型。

顺便提下UJR_WRITE_BACK的filter参数，包括APPSET_ID,APPLICATION_ID,MODULE_ID，前两个是必须要有的，module可以是Manualplanning,journals,datamanager,comment,etc.

在BPCNW中何时使用SharedQueryEngineBADI对于BPC系统的读写接口来说，都提供了可供用户自定义开发的BADI接口，SQE的BADI会在系统查询后调用，此时用户可以根据需求进一步筛选数据。

比较典型的应用是矩阵式的安全模型。

BPC的MemberAccessProfile只提供了对独立的维度成员权限控制，当用户需要在不同的两个维度上作交叉的成员权限控制时，MemberAccessProfile就不能够满足需求了。

举例如下：

地区维度有成员美国（US）和欧洲（EMEA），账户维度有成员个人费用（PersonalCosts）和广告费用（AdvertisingCosts）。

某用户只被允许去查看美国的个人费用和欧洲的广告费用。

BPC的MemberAccessProfile只能针对某一个维度的某些成员赋予权限控制，如果用户可以访问地区维度的美国和欧洲，以及账户维度的个人费用和广告费用，那么他就可以看到美国的广告费用以及欧洲的个人费用。

而这是我们需求中所不允许的。

下面将从BW端新建SQE的BADI讲起，直到在BPC中新建report来检查是否实现了此功能。

一、登录BW端，进入SE18界面：

二、显示这个BADI的定义，展开定义树：

三、创建此BADI定义的一个实现体：

四、输入enhancementimplementation的名字和描述：

五、此时，需要指定如需这个BADI要传输则开发包是什么，或者不参与传输时作为localobject存储：

六、指定BADIimplementation的名字、描述及实现类，同样也要指定开发包：

七、现在就新建出了一个BADIimplementation，但是还没有激活的内容：

八、打开BADIimplementation的菜单树：

九、双击下面的"FilterVal"：

十、选中编辑按钮，然后点击"Combination"：

十一、选中显示的两个参数：

十二、双击"Application_ID"这一行，然后输入filter的值：

十三、然后为"APPSET_ID"输入filter值，保存并激活已经更改的这些对象；十四、在BADIimplementation中双击"ImplementingClass"：

十五、双击implementingclass的名字：

十六、选择编辑这个类，然后双击"POST_PROCESS"方法名，加入实现方法代码：

具体代码在附件中，激活刚刚新建的类。

接下来就可以在BPC的报表中看到如上需求的结果了。

/Files/libihui422/SQE_BADI_SAMPLE.txt一、为用户创建两个MemberAccessProfile，一个叫US_MAP，可以访问地区维度的US和账户维度的个人费用（CE0004000）。

另一个叫EMEA_MAP，可以访问地区维度的EMEA和账户维度的广告费用（CE0004200）：

二、先展示一下当我们前面新建的SQEBADI没有生效时，两条规则对于同一个用户是叠加的，用户可以读取到US和EMEA里面两个账户的所有值：

三、当新建的SQEBADI生效后，报表内容就改变了：

BPC的传输（transport）PC作为基于SAPNetweaver平台的产品，自然可以运用transport机制去进行系统范围内（开发机-测试机-生产机）的transport。

但是BPC的transport与标准的过程又不是完全相同，本文旨在对此做一些介绍。

首先介绍下有关BPC的transport机制的资料，用户可以通过servicemarketplace上面的operationguide查找，在线帮助的Section5.1就是对于transport的介绍，以及用户可以如何使用它。

这个文档同样可以通过去访问，可以在SAPBusinessObjects的tab下，在PlanningandConsolidat