SAP BPC

 

BPC(Business Planning & Consolidation)的前身是Outlooksoft，SAP公司在2007年收购了这个公司.公司原先的产品BPC5.1在市场上还是享有不错的市场份额的。收购以后，SAP在保留原有MS OLAP平台的基础上，又开发了基于Netweaver BW平台的新产品，所以现在SAP BPC有两条产品线，基于不同的OLAP引擎架构。从功能上面看，NW版的BPC拥有绝大多数MS的功能，但是不是所有，比如在BPC7.0中，NW版没有Insight和BPF两个颇为主要的功能。

 

 

 

从BPC7.5版开始，由于SAP收购了另一重量级BI厂商Business Objects，BPC引入了很多BO产品的整合，比如Voyager, Xcelsius.这也同时可以看出来SAP决心在这个软件市场行业，把自己的产品进行集中、整合。在下一代的EPM(Enterprise Performance Management)产品线上，设置一个以BPC为核心的大EPM平台。BPC目前在市场上，在售的NW版本有BPC7.0,BPC7.5预计会在六月底正式推向市场。这两个版本的客户已经过百，在中国也已经有了第一个吃螃蟹的公司。欧美市场上面的火爆，相信会在今年年底到明年传导至中国。加上 Microsoft已经明确表示将在企业级财务解决方案上，推荐SAP BPC为推荐使用方案，相信BPC的明天会美好的。

 

 

 

相对于主要的竞争对手Hyperion，BPC主要位于Excel客户端的功能一定也会更加赢得传统财务用户的亲睐。不过对于实施而言，加大了不少二次开发的难度。通常BPC项目，都需要consultant去开发一定量的macro，还要用BPC自带的脚本语言(script logic)，来书写业务逻辑。对于consolidation方面的功能，配置也实为不易。不过我想对于真正从事实施行业的consultant而言，这也就是自身价值体现的地方吧。

 

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系统架构

 

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。前者的功能主要包括:

 

 

提供modeling工具，配置application 和 dimension；

安全模型的配置(用户、团队、角色)；

管理application和dimension(重新构造dimension、优化application)。

后者的功能主要包括:

 

终端用户可以进行展示报表和数据输入；

提供展示报表和数据输入(input schedule)的工具；

进行大数据量数据的管理和其他系统管理功能。

在.net server层提供的功能包括:

 

对于BPC client soap请求的身份认证；

通过MSMQ存储异步soap请求的状态；

绑定abap的用户执行RFC call；

从RFC接收请求结果，进行数据转换再返回给客户端。

在abap层提供的功能包括:

 

业务逻辑的处理；

数据查询并返回；

提供MDX查询功能；

作为文件系统提供存储功能；

执行client自定义的用户逻辑；

向.net层提供RFC返回。

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

 

 

 

.net层和abap层之间的通信是通过RFC来实现的，每一个RFC call在后台都会需要一个dialog用户进程。目前对于每一个BPC .net服务器都是与一个abap活动实例一一对应的。这些配置的信息可以通过server manager来查看。

 

四.如何后台直接运行Data Manager包

 

Data Manager应该是所有实施项目的顾问第一个要进行的模块，除了要把master data和transaction data首先导入BPC，还要设置相应的数据包，以便后期进行数据的维护，以及进行报表合并操作、自动运行script logic操作、优化BPC Cube。这些操作都会需要用到数据包，也是因为数据包可以被BW process chain设置为周期运行。当然，作为节约人力的便捷方式，也有一些不方便的地方，最明显的就是在出错之后，如果在log中没有记下有意义的信息，很难检查出错的地方。本文最后也会介绍一两个可以自己检查数据包执行的方法。

 

本文主题是介绍如何能自己在后台搭建一个能运行的数据包。在进行后台设置之前，首先是同一般的前台执行数据包一样，这里举例是从BW infoprovider导出数据到BPC Application，如下图：

 

 

 

当我们从后台直接运行这个数据包时，一样需要有这些前台配置的参数信息，而这些信息是如何被代码读到的呢。这里是需要我们去写一个文本文件(answer prompt)。比如下面这样：

 

 

 

这个answer prompt文件的内容很容易理解，基本上都是与界面上面的参数设置一一对应的。每个参数作为一行，每一行用回车符作为结束，参数名称和参数值之间用一个tab符作为分隔。每一个BPC的process chain都有自己不同格式的answer prompt，要想知道如何去做answer prompt文件，简单的办法是前台运行一次数据包，然后去后台下载log文件，在log文件的基础上修改即可。进入Tcode:UJFS，打开文件夹root->webfolders->appset name->app name->privatepublications->user name->tempfiles，如下图：

 

 

log文件的文件名是根据执行的数据包名称和时间命名的，所以很容易找到你刚刚执行的那个数据包log文件，下载后打开如下：

 

跟上面的answer prompt文件对比，就可以看出log文件的第2-6行，就是answer prompt文件的内容。通过这样的方法，就可以得到任何一个数据包的answer prompt文件。

接下来，进入TCode:SE38->UJD_TEST_PACKAGE，填入一系列需要的参数，Team ID大多数时候是为空，Schedule Info不用修改，AnswerPrompt选取本地做好的answerprompt文件，程序会自动读取内容。不要直接把内容复制到这个文本框中，因为程序会做一些特殊字符的替换。第一个参数If Synchronous，是用来提示程序，执行数据包的操作不是通过schedule的方式从BW新建job的方式来运行的，而是直接通过程序执行的。这样的执行方法，是我们可以debug代码的第一种方法。

在执行之前，可以设置好内部断点，这样就可以在后台debug dm的代码了。同时可以把此页的参数存下来。然后自己搭建一个新的process chain，内容就是执行这个program，这样也可以实现一个从后台的自动运行的数据包任务。

对于已经执行过的job，如果没有执行成功，而又不能简单重现找到原因的，有另一个办法可以尝试去debug，进入TCode: SM37，输入相应的filter参数，查找出已经执行过的job，选中想要debug的job,在命令框中输入jdbg，执行就可以进入debug界面，当然最好提前设置好内部断点。

 

 

 

最受期待的75版新功能BPF(Business Process Flow)概述

 

对于做非企业软件的朋友来说，对为什么要在一个财务软件中加入流程控制的功能有疑问。其实这也很容易理解，对于在公司从事财务的人员来说，财务软件本身的易用性是很重要的。在BPC中，具体数据的录入，输出报表，数据的导入导出，都是分布在各个菜单项中，如果有一个流程管理的功能来集成，会方便很多。BPC7中没有实现这个功能，在75中隆重推出了这个功能，这也是中国客户最为看重的功能，因为它也集合了权限审批功能，这在预算中应该是非常必要的。

 

 

 

什么时候需要使用BPF呢？一言概之，通过提前设定好每一步要做的事情，指导商业用户使用BPC完成预算流程。举一个实际的例子来说明。某跨国公司，包括美国，加拿大，德国分公司，预算流程包括四个步骤。第一，复制前一个月的实际数据作为预测数据；第二，审阅之前的预测数据，手动调整这个数据；第三，进行商业逻辑的运算，比如货币转换；第四，执行并输出报表。同时，我们假设这几个步骤间存在依赖关系。前面三步可以分别在美国，加拿大，德国分公司中分别执行，而第三步要求必须在前面两步完成之后进行，第四步又可以分别执行。设想在没有BPF时，做预算的人如何能知道何时前面两个步骤已经完成了呢，如何去检查前面步骤的完成情况呢，审批的人如何能知道做预算的人已经完成预算了呢，等等。这些问题当然可以通过邮件来完成。BPF就解决了上面提到的问题。通过BPF，用户可以明确知道当前的状态和要去做什么。对于上一个步骤的完成，到打开下一个步骤都是由BPF来控制的。在例子中，只有美国的用户完成了第一步，美国的第二步才会开始；如果美国用户完成了前面的两步，而加拿大还没有开始第二步，那么美国的第三步是无法开始的。这样的控制流程都会由BPF来完成。

 

BPF主要作用于商业流程所需要的集中化处理数据，验证数据。BPF帮助执行序列化的流程步骤。而且在BPF中可以进行流程的监控，流程状态的报表显示。

 

BPF不同于普通的工作流，虽然在很多功能上相似，比如可以指导用户执行下一步行动，显示出期望用户去执行的行动，支持在完成上一个步骤后打开下一个步骤。BPF所涉及的BPC行为，本身是可以独立执行的，可以在BPF之外的。比如用户是可以进行报表输入的，无论他是不是一个BPF用户，这个是与工作流系统的一个区别。当然，通过BPF来设置和进行常规的月度预算，合并报表过程是更方便的。

 

构成BPF的主要概念。BPF模板和实例是两个最主要的BPF概念。每一个模板就代表着一个商务流程，一个模板可以产生若干个实例。比如我们建立一个模板，作为月度预算模板，它可以有一个2010年3月的实例，也可以还有一个2010年4月的实例，这两个实例共用一个模板。

 

每一个商务流程，对应一个模板，它有很多步骤和子步骤。每一个步骤和子步骤都可以拥有多个行为。一个具体的行为可以是输入报表的行为或者是执行某一个数据包。每一个步骤可以有不同的执行数据区域。每一个步骤都可以有一个所有者和可选的审阅者。所有的步骤是顺序执行的而一个步骤中的子步骤是可以不顺序执行的。重新打开已经执行完毕的步骤也是可以允许的。BPF希望为公司监控和管理商务流程提供最大的灵活性。