为什么SAP有Crystal Report for Enterprise-优快云博客

本文解析SAP在BI4.0中引入基于JAVA的CR4E的原因，以及其与保留CR2011的区别。强调了SAP为整合收购产品与维护开发新功能所采取的策略，并建议客户在产品成熟时进行迁移。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

我想很多人都疑惑为什么SAP在BI4.0引入了基于JAVA的CR4E,而同时又保留了CR 2011。这让客户有时对产品的选择无所适从。BI4.0，SAP基本将开发语言从C++转到了JAVA上来，尽管JAVA现在已经是ORACLE的资产。这与C++产品开发难度高维护成本高可能有一定关系。但是，我这里想从软件的架构不同来猜猜为什么会产生CR4E。

CR最大的特点是高效和广泛的数据源支持，那么我就从这个数据源支持开始来说说。

在老的C++实现的CR里（CR 2011），基于非建模数据的报表的数据抽取是CR自己实现的一套DB Driver。也就是说，它没有利用到我们很熟的ConnectionServer. 因为CR产品是BO公司收购来的，而ConnectionServer是BO公司的产品架构里的一部分。想改变现有的软件架构，利用ConnectionServer，看来没法简单的实现。

而CR 2011基于建模数据的报表的数据抽取利用的是老的Universe（unv）。那么我们知道BO老的语义层是C++写的。而SAP将来的方向是新的语义层（UNX），这是JAVA开发的前端工具和Server端。所以CR 2011也没法简单地使用新的更强大的语义层。另外，还有一处比较有意思的是，即便基于语义层取数据，CR 2011也不过是利用语义层生成可执行SQL而已，而具体发送SQL获得结果集，还是CR 2011自己完成的。

那么在JAVA实现的CR4E里，它完全利用ConnectionServer来访问数据库，避免了重复发明轮子。此外，CR4E能够利用最新的语义层，而且，与CR 2011最大的不同是它从语义层获得的不是可执行SQL，而是结果集。

所以我们看到，无论是从收购产品整合的角度还是旧产品维护开发新功能的复杂度考虑，SAP都不得不开发出下一代水晶报表。

那么已经投资在老的水晶报表上的客户，如果出于稳定的考虑，可以暂时还继续使用CR 2011，当CR4E成熟时，再转换不迟。但是，迟早，客户要迁移到Crystel Report for Enterprise上来的。