Difference between BW 3.5 and BI 7.0

1. In Infosets now you can include Infocubes as well.

2. The Remodeling transaction helps you add new key figure and characteristics and handles historical data as well without much hassle. This is only for info cube.

3. The BI accelerator (for now only for infocubes) helps in reducing query run time by almost a factor of 10 - 100. This BI accl is a separate box and would cost more. Vendors for these would be HP or IBM.

4. The monitoring has been imprvoed with a new portal based cockpit. Which means you would need to have an EP guy in ur project for implementing the portal ! :)

5. Search functionality hass improved!! You can search any object. Not like 3.5

6. Transformations are in and routines are passe! Yess, you can always revert to the old transactions too.

7. The Data Warehousing Workbench replaces the Administrator Workbench.

8. Functional enhancements have been made for the DataStore object:New type of DataStore object Enhanced settings for performance optimization of DataStore objects.

9. The transformation replaces the transfer and update rules.

10. New authorization objects have been added

11. Remodeling of InfoProviders supports you in Information Lifecycle Management.

12 The Data Source:There is a new object concept for the Data Source.Options for direct access to data have been enhanced.From BI, remote activation of Data Sources is possible in SAP source systems.

13.There are functional changes to the Persistent Staging Area (PSA).

14.BI supports real-time data acquisition.

15 SAP BW is now known formally as BI (part of NetWeaver 2004s). It implements the Enterprise Data Warehousing (EDW). The new features/ Major differences include:
a) Renamed ODS as DataStore.

b) Inclusion of Write-optmized DataStore which does not have any change log and the requests do need any activation

c) Unification of Transfer and Update rulesd) Introduction of "end routine" and "Expert Routine"

e) Push of XML data into BI system (into PSA) without Service API or Delta Queue

f) Intoduction of BI accelerator that significantly improves the performance.

g) Load through PSA has become a must. I am not too sure about this. It looks like we would not have the option to bypass the PSA Yes,

16. Load through PSA has become a mandatory. You can't skip this, and also there is no IDoc transfer method in BI 7.0. DTP (Data Transfer Process) replaced the Transfer and Update rules. Also in the Transformation now we can do "Start Routine, Expert Routine and End Routine". during data load. New features in BI 7 compared to earlier versions:

i. New data flow capabilities such as Data Transfer Process (DTP), Real time data Acquisition (RDA).

ii. Enhanced and Graphical transformation capabilities such as Drag and Relate options.

iii. One level of Transformation. This replaces the Transfer Rules and Update Rules

iv. Performance optimization includes new BI Accelerator feature.

v. User management (includes new concept for analysis authorizations) for more flexible BI end user authorizations.

(转)SAP接口项目经验

某ERP 主要应用 SAP R/3 系统，某接口项目是原系统与 SAP R/3 的部分集成。

在 ERP 的实施中，面临众多原有异构系统与正在实施的 SAP R/3 的集成问题。基于以后在一个平台上维护及监视接口比较方便的考虑，ERP 项目组决定采用 SAP XI。

SAP XI（Exchange Infrastructure）是SAP Netweaver 中的一个产品。SAP Netweaver 是一种可随时用于业务运作、面向服务的平台，适用于SAP的所有解决方案。基于Netweaver，企业能够实现各个层面充分的集成，降低信息系统建设的总体成本（TCO）。
归纳起来，
第一个层面，是人的集成，产品以Portal比较有代表性；
第二个层面，是信息的集成，产品有Knowledge Management 和MDM(Master Data Management)等；
第三个层面，是流程的集成，即 XI；
第四个层面，是平台的集成，在这个层面上，SAP 提供的是支持开放标准（如XML）的底层架构，可以实现灵活的互接。

XI 的集成又可以分为两个层次，第一个层次称为Integration Broker，以消息的方式进行的数据的交换；另外一个层次是 BPM，即业务流程管理。

在 XI 中，数据（可以使一条记录，比如单个的物料主数据；也可以是多条记录，比如含主单明细的供应商主数据）从某一个业务系统通过 XI 发送到另外一个业务系统，站在业务系统的角度，前者称为 Sender，后者称为 Receiver 。

适配器(Adapter)进行 XI-XML 格式与业务系统的特定类型的数据格式之间的转换。依据业务系统的数据格式的不同，适配器可以分为多种类型，比如 SOAP Adapter, JDBC Adapter, File Adapter, RFC Adapter 和 IDoc Adapter 等。通常说的实现方式，譬如 SOAP+RFC，是指Sender 与 XI 之间使用 SOAP Adapter，XI 与 Receiver 之间使用 RFC Adapter。

Integration Broker 的工作原理大致如下。XI 主动或者被动通过一个适配器从 Sender 取得数据，数据进入 XI 后的存在形式是基于 SOAP 的 XI-XML 格式的消息。消息在 XI 内部，依照事先做好的配置，决定消息将发送到哪一个业务系统，进行何种转换以及选用哪一个适配器将消息发送出去。消息最终通过适配器将 XI-XML 格式的消息转换为特定类型的数据并发送给 Receiver。

BPM 是建立在前者的基础上的，BPM 使用了 work flow 的概念，涉及到业务逻辑的处理。一个典型的订票例程的应用如下。某旅行社 A 发出北京到孟买的订票请求，两个航空公司 B 和 C 分别有北京到新加坡和新加坡到孟买的航线。A的订票请求在 XI 内部被分割为两个订票请求，请求消息分别发往两个航空公司并等待反馈。如果得到两个都订票成功的反馈，则将反馈进行合并处理，并返回给旅行社；如果得到一个成功一个失败的反馈，则需要将反馈合并处理，将订票失败消息返回给旅行社，同时向其中一家航空公司发送取消订票的请求；如果得到均失败的反馈，则值需要将反馈合并处理，将订票失败消息返回给旅行社。

在此接口项目中，经多次确认、修改和论证，最终确定采用 Integration Broker，具体的实现方式是 SOAP+RFC 与 JDBC+IDoc 。采用 Integration Broker 主要是考虑到现有的集成业务逻辑简单、清晰，并不存在特别复杂的业务逻辑的现象，而 BPM 存在配置复杂以及技术上的风险。在某些功能点，考虑到客户对的实时性要求，采用了 SOAP+RFC 方式。

SOAP和RFC均为同步数据交换协议，包括输入和输出参数。SOAP是建立在 HTTP 协议基础之上的一种协议，通过特定格式的 XML文件来进行数据交换。RFC 是 Remote Function Call的简称，广泛应用在 SAP 的产品之间，类似于常见的 RPC。
SOAP+RFC 方式实现的难点在于某系统发送 SOAP 消息的客户端如何建立，以及如何得到 SAP R/3 的反馈。前者通过相关文档的帮助下得到解决，后者是通过实现错误信息同步由 R/3反馈给 XI，XI 再反馈给某系统来解决的。

其他对实时性没有要求的接口，采用了 JDBC+IDoc 方式。其特点在于 JDBC 方式实现起来比较简单，系统只需要将要传给 R/3 的数据存放到临时表，XI会通过 JDBC 方式从临时表取走数据；XI 向系统写数据，会通过调用存储过程，直接将数据写入后台数据库，生成相关单据。采用 IDoc 方式，其特点是 IDoc 实现了对数据的封装，能够记录数据的传输状态。IDoc 方式是 SAP 推荐的 SAP 产品间的标准数据交换方式。这种方式是之前JDBC+File 方案的替代，在方案改变后，我方的程序完全没有改变，这是采用中间件的优点的一个体现。

JDBC+IDoc 方式实现的难点是对出错如何处理。在三个可选方案中，采用的是最简单的人工干预方法，即对于出错，统一由 XI 发送包含错误信息的电子邮件给相关人员。

如果有条件的话，自己搭建一套SAP XI DEMO EXAMPLE环境，其中涉及了RFC,SOAP,IDOC,XI的adapter，对大家学习ID（Integration Directory）极为有用

BW PSA

BW中PSA的方式
1.PSA and then data targets (by package)
If errors occur when posting data to the data targets, you can updatethe data packages from the PSA table to the data targets again afteryou have eliminated the errors.
2.PSA and data targets in parallel (by package)
Need many Dialog process
3.PSA only
Enables you to write all the extracted data packages for arequest to the PSA table without updating them to the data targets.
Ready for further update
4.Data targets only
if you load the data using the PSA table, you have the option ofcreating a start routine in the maintenance screen for the transfer rules.With the start routine you canchange (for example, add or delete data) or check data packages.

测试

测试