在作为咨询顾问的工作经历中，我经常会与SAP NetWeaver Business Warehouse （BW）相关项目打交道，因此也为客户们总结出了一套最佳实践。那么在本文中，我就将介绍5条关于SAP BW的技巧。

尽可能不要使用ABAP

在我遇到的客户当中，有80-90%的SAP BW实施项目是没有必要使用ABAP（高级企业应用编程语言，Advanced Business Application Programming）的。ABAP可以表现为BEx user-exit变量，转换规则程序以及客户数据加载程序等形式。

人们使用ABAP通常出于几个原因，比如它有标准化的功能，SAP BW自身不具备一些功能，同时它更快。但除了第二条之外，其他的都不能成为使用ABAP的充分条件。定制后的代码通常不会比正确部署后SAP BW原生的功能更快，而且它提供的标准化功能也不会比SAP BW更易用，因为这里会涉及到长期的维护成本。

即使ABAP是我们唯一的备选项，甚至可以说它更易用或者性能更好。但要记住，当在ABAP中部署数据流或报表语义时，我们就无法再享受BW为我们提供的最大好处：数据管理系统中一致的语义模型。通过这个模型我们可以理解并管理数据以及整个平台，同时它是保证BW正常运转的前提。

举例来说，在BW7.4 on HANA中，SAP BW与上一个版本（7.3）相比运行了许多标准化转换的。它会将转换操作推送到HANA上进行处理。对于已有的转换它能够在很大程度上改善性能，同时无需进行任何更改。前提是，你不能在转换中使用ABAP程序，否则就无法实现上述优化。

因此我们必须仔细考虑是否要继续使用ABAP，包括维护的成本以及BW语言模型的问题。除非在迫不得已的情况下，请不要使用ABAP。

制定一个架构和开发的指导守则

你要为BW系统指定一个一致的架构和开发守则。SAP甚至根据分层体系架构（LSA）概念为企业量身定制了一个BW的参考架构。而最新的版本的LSA（LSA++）也纳入了参考范围以便更好地支持新技术，比如SAP HANA，它还添加了虚拟语义层，比如SAP BusinessObjects Universes。如果LSA太高深了，你没有这方面需求的话，或者说你没有把SAP BW作为一个真正的数据仓库时，那么你就需要与这方面的专家进行探讨，然后总结一个适合你的架构，并把它编成一个文档或者在版本控制下设置一系列的文档。

这样做的好处在于它能够帮助你将BW环境更好地组织起来。当团队有新成员加入的时候，他们就能够很快速地了解系统，同时为开发者进行检查的时候提供一个一致的框架。

对开发工作进行检查

尽管在测试环境中能够正常运行，但你也不要自以为开发工作就不会出现问题。在将产品投入生产环境之前，所有的开发都需要一个熟悉你BW和架构的QA专家进行检查。更进一步说，如果能够有一个QA在整个开发过程中都参与进来那就更好了。这样的话你就能够避免高风险，在投入生产环境之前做到万无一失。注意，这不是一项临时的任务，而是需要你持之以恒。

保证补丁以及版本的更新

要保证你的BW系统支持软件包是最新的。我建议最多不要超过2个版本的软件包，也就是说每4-6个月就对系统进行一次补丁升级。没错，给系统打补丁是费时又费力的，但它同时能够为你寻找Bug节省一点时间，让你的系统更好地运行。我建议不要大规模地更新，而是要每次只更新一小部分补丁包，这样做的目的是降低风险。

同样地，你需要注意更新到最新版本的BW软件，都是出于同样的理由。一旦你验证了新版本的稳定性，那么建议更新宜早不宜迟。这样做能够让你更快地使用到一些新功能，而这些功能也许正是你的业务所需要的。

使用元数据

BW的一个长项就是系统能够记录非常详细的数据和流程模型。你需要使用这些记录和元数据来了解关键的指标，比如数据质量，我的主数据文本字段是否都使用了要求的语言？还有系统性能，我的夜间加载速度和一年前相比有没有提升？

在很大程度上，BW现有的统计内容能够回答数据加载以及查询性能等问题，而SAP的信息治理工具能够进行更深层次的数据质量管理。但即使你没有信息治理工具，如果你有更细节的问题，那么元数据已经在系统当中了。你需要做的只是在它的基础上创建一个标准的BW报表结构。

再强调一下，尽量别使用ABAP！