注明:本篇的技术性细节参考了SAP SCN上的一篇SAP PI 和BW集成的文章,本篇文章并不打算过多探讨实现的技术细节,因为在SCN上的这篇英文文章已经完全涵盖了技术细节和配置步骤
大家可以通过搜索PI BW找到相关的文档,本文只是希望通过简单通俗的说明来阐述PI在SAP BW项目中集成第三方业务系统数据的优势和必要性,以及这样做的价值,是一片纯理念和价值探索性短文
在以前经历的SAP BI项目中我们经常会遇到这样一些棘手的情景,就是我们的商务智能数据来源于不同的业务系统,如果企业将SAP BW作为其唯一的官方数据仓库进行规划,那么一般来说,
由于企业的数据仓库数据需要从多种数据源中取得数据,我们必须规划出可行(应对大量数据以及增量加载)的方案集成企业数据,这里就不得不提到BW两种重要的数据加载方式,BW数据上载
有FULL UPDATE和DELTA UPDATE两种,但是我们很容易分析出这两种加载方式的优势和劣势,前者实现非常简便,而且可以从平面文件,数据库中轻松实现数据加载,但是劣势就是无法实现
数据增量加载,因为DELTA加载需要借助数据源的QUEUE机制,因此对于日积月累的大量事务系统,通过简单的设计就能够实现第三方系统的轻松加载显然不太可能,对于平面文件等数据源,每次
更改都需要FULL UPDATE的机制显然不合理,也许经验丰富的BW顾问会在我们日常BI项目中设计出非常复杂的机制实现这种ECC和外部系统同时加载数据的可能,但是的确第三方系统如果能实现
在低成本的状态下支持DELTA加载和避免数据重复加载的可能,那么对于第三方系统数据集成将是一个非常完美的解决方案,因此我们通过一系列分析来论证这种可能性。
1 首先通过这张架构图我们可以明显看到PI处于BI的下层,也就是说SAP NETWEAVER架构设计的初衷有可能就是将来会应用PI的一些功能以及特性为BI产品线在数据集成和数据交换方面提供强有力的保障
2 PI在消息和数据交换方面具备的几大功能无疑都是实现BW集成第三方系统数据的重要支柱:
因此我们一般设计第三方系统集成BW数据源,只需要应用PI的INBOUND RFC ADAPTER或者ABAP PROXY向数据源的DELTA QUEUE写入数据,而推送功能,非重复数据发送
EO/EOIO等功能可以完全在PI端实现,对于第三方数据传输的监控和管理,PI提供的机制也完全能满足后期运维管理的要求,因此,PI在实现BW集成第三方业务系统数据的增量加载场景中,
真的可以说具备得天独厚的优势。