用BPM、业务规则和商业智能创建智能的、灵活的解决方案.doc

3（上）-用BPM、业务规则和商业智能创建智能的、灵活的解决方案 在 第一篇文章（1、2） 中，我们介绍了随需应变企业、业务流程管理（BPM）、业务规则引擎和商业智能的总体概念。我们调查研究了各种不同的业务规则引擎，并讨论了如何区分这些不同的业务规则引擎。在本文中，我们将主要关注商业智能在一个智能而灵活的 BPM 解决方案中所扮演的角色。特别地，我们将讨论用于进行高级分析的在线分析处理（on-line analytical processing，OLAP）技术的应用，讨论时我们将同时考虑 OLAP 的访问和集成。这包括对实现一个动态定价模型的技术细节的深入研究。最后，我们还将介绍 DB2 Cube Views，这是 OLAP 范例的一个扩展，在 OLAP 产品中，可以使用它来为企业产生优化的 OLAP 解决方案。 商业智能对于业务流程管理来说有多重要呢？正如我们首篇文章中所说的，商业智能为公司在客户、销售、财政计划和竞争等方面的策略制定提供了洞察力。由业务流程管理系统实现的业务流程需要由能付诸实施的（actionable）智能来驱动。这种能付诸实施的智能超出了像报告和图表这样的传统概念。能付诸实施的智能是通过高级的数据分析获得的，如果将其与业务流程引擎集成起来，那么就可以用它来驱动策略性的企业运作。 在我们的例子中，Cristina White 是一位 International Foods Market (IFM) 公司的 CIO，她接受了转换 IT 环境的挑战，以便促进 IFM 转换成一家快速响应的随需应变企业。她理解商业智能在业务流程管理中的关键角色，并且想要理解如何部署 BI 以支持她的目标，她请求 Greg 这位 IFM 架构师给出他的想法。Greg 对商业智能有非常广泛的了解，他指出了三种架构驱动（architectural driver）： 避免数据筒仓（silo）。 避免孤立的决策制定。 减少在决策制定过程中的延时。 实时数据访问和分析 让我们仔细地分别看看这些架构驱动。 数据筒仓 要将来自各种不同数据源的数据合并成一致的、统一的全局视图（global view）可能要花很长的时间，通过这种全局视图，业务分析员可以发现新的业务机遇或者察觉到异常。在很多情况下，来自传统（brick-and-mortar）商店、Web 站点、呼叫中心（call center）、库存（inventory）和 CRM 系统的大量数据通常都被当作单独的筒仓来对待，它们彼此之间互不通信。来自这些系统的数据可能以不同的格式表示，存放在不同的数据库中，并且为各种不同的应用程序所捕获。为了净化、协调和整合来自整个企业中各种不同筒仓中的数据，需要付出一定的努力。 孤立的决策制定 在传统业务环境中，业务规划或财政建模曾是一种离线活动。首先，统计人员需要消化大量的企业数据，并提交一大堆的报告和分析结果，然后业务分析员解释这些分析结果，并开发出一个业务模型和计划。高级行政官员根据分析结果和他们的业务直觉来决定预算。我们都清楚，这些活动是完全不同的，互不相干的。运气好的话，离线报告和离线分析或许可以为公司提供有利的机遇。但如果运气不好，它们就无法完成使命了，也无法提供准确、安全和实时的商业智能信息。 决策过程中的延时 许多大型公司如果能够减少业务事件和响应之间的延时，就能获得巨大的利益。只是在某个区域推迟了某种产品的上市或许是件小事，可以忽略。但是，如果在很多商店都再三出现这种情况的话，其影响就不容忽视了，并且应该对此进行调查。不幸的是，当决策制定者决定采取前瞻性行动时，他们手头上却缺少探测市场变化和客户数量削减所需的商业智能信息。结果，公司只能被动地作出反应，试图缓和事件的影响，而不是前瞻性地利用事件所带来的机遇。 商业智能的演变图1（商业智能的演变） 孤立的数据，不管是事务性的还是操作性的，都需要进行整合。不管是手工整合还是自动整合，整合过程对于数据仓库的延时都会产生深远的影响，而正是这种延时约束了我们获得实时信息的能力。为了理解可用于解决实时信息需求的一些选择，看一下商业智能的演变过程是值得的。 商业智能的演变可以通过 4 种模型来诠释： 传统模型 在传统模型中，由一个批处理进程捕获事务数据并将其传播到一个登台服务器（staging server）上，通常这个进程被安排在每天或每个星期执行一次。接下来，来自登台服务器的数据通过一个提取转换装载（extract transformation load，ETL）过程得以净化、转换并与数据仓库相协调，这同样是通过一个计划性批处理进程完成的。然后，数据仓库将经过合并的数据提供给分析应用程序，业务分析员利用这些数据来产生报告。之后这些报告被提交给合适的决策制定者，以做出业务决策。整个循环周期通常要花数个星期才能完成。 实时反馈（real-time feed）模型 在第二种模型中，通过业务流程管理（BPM）或企业应用集成（EAI）过程将事务数据直接集成到数据仓库中。通常，事务数据以消息的形式发送到一个队列，EAI 代理程序（broker）会对该队列进行轮询。一旦 EAI 代理程序收到了消息，它就可以净化、转换数据并将其聚合（aggregate）或合并成业务对象，从而使其符合数据仓库的规范和要求。之后，通过数据库连接（database connectivity ）技术将业务对象填入到数据仓库中。一旦数据存在于数据仓库中，便可以对数据进行分析处理，从而派生出商业智能。业务分析员应用他们的知识和专业经验收集有用的信息，并将这些信息提供给决策制定者。 嵌入式（embedded）模型 在这种模型中，事务系统嵌入了商业智能的能力。这种模型提供了一个强大的中间层，该中间层具有数据集成和数据表示能力。很多 ERP 和供应链厂商，例如 SAP 和 PeopleSoft 都正在采用这种方法。通过这样做，他们的客户可以轻松地将数据转换成信息，以进行有效的决策制定。这种模型在规划和预测应用程序中被广泛采纳，这些应用程序有助于企业设定目标。嵌入式模型可动态生成分析结果（例如计分卡），以帮助调整企业的活动和执行。 闭环 BI 在这种最先进的模型中，事务数据是动态捕获并整合到数据仓库中的，之后数据仓库再将数据提供给一些商业智能工具，例如 OLAP 或挖掘工具。接着，商业智能的输出以推荐对策（例如动态价格变化）的形式直接反馈给前线的决策制定者。这样就形成了一个闭环，从而创造出一种零延时环境。零延时环境允许公司将分析结果整合到每天的企业运转中，并缩短业务决策与业务行动之间的时间间隔。为了实现这个系统，首先应该将这个闭环流程自动化。这可以通过实时构建一个数据仓库、集成实时分析引擎并利用实时规则引擎来实现。其次，这个自动化的闭环流程应该实时出现。这种闭环环境根据由决策引擎生成的消息动态地调整企业运作。这两个标准为更快地制定决策、更快地将产品推向市场以及获得更大的市场机遇打下了基础。 COLOR=blueOLAP 巴贝尔塔/COLOR IFM 使用 OLAP 作为报告接口，以帮助分析员通过分析历史事务数据执行决策支持和战略规划。OLAP 提供了一个多维视图，这个视图由一些分类属性（例如 Products 和 Market）和数值属性（例如 Sales 和 Profit）组成。分类属性形成了各个维，而数值属性形成了一个多维数据集的度量（measure）。维可以包含指定聚合层次的层次结构。通过应用一些数学函数（例如求和、平均值和不同的维属性组合），度量属性被聚合为不同层次的细节。 可以通过使用不同的导航操作符，例如向下钻取（drill-down）、上卷（roll-up）、切块（dicing）、切片（slicing）和旋转（pivot），来对 OLAP 数据进行探究。通常，用户从某个聚合层次开始，可视地检查各个条目，根据业务猜测或财政策略选择子范围的数据，以便进行进一步的检查，向下钻取更多的细节，再次检查条目，然后要么上卷到一个更高层次的视图，要么向下钻取到一个更原子性的层次。 尽管 OLAP 是一种极好的技术，但是 OLAP API 并没有通用的标准。在关系数据库中，SQL （Structured Query Language，结构化查询语言）和 ODBC （Open Database Connectivity，开放数据库连接）已经被普遍接受并得到发展。相反，当前在 OLAP 领域还没有哪个产品能够主导市场，并强大到可以赢得平台霸主的境地。结果，在 OLAP 领域的应用程序编程接口（API）、数据定义语言（DDL）或数据操作语言（DML）方面仍然存在着许多的派系。问题的根源就在于处于主导地位的主要几家公司都将心思花在竞争上，而对合作不感兴趣，而其他厂商又忙于合并不同的 API 访问，以维持和扩展他们的市场份额，更是远离了这场争夺。下面我简要地讨论一下 OLAP API 领域的几个主要参与者： Hyperion Essbase Report Writer APIHyperion Report Writer API 是一种基于文本的报告描述 API，它提供了最佳级别（best-in-class）的财政报告和合并（consolidation）功能。尽管 Hyperion Report Writer API 是 OLAP 领域中处于主导地位的 API 之一，但它仍然是完全专有的。它允许用户选择数据、修改布局以及格式化结果集。 Microsoft 多维表达式语言Microsoft 多维表达式语言（MultiDimensional Expression MDX）是 Microsoft OLEDB MD 背后的 OLAP 查询语言，而 OLEDB MD 是 Microsoft 的新 OLEDB 数据访问层的一个多维数据库扩展。MDX 的格式和结构与 SQL 类似。您可以使用 FROM 子句来指定数据源，用 WHERE 子句来过滤数据，用 SELECT 子句来指定或计算结果集中的成员。与关系表中的 SQL 相比，使用多维数据库中的 MDX 要比使用 SQL 创建基本查询更加复杂和困难。SQL 只检索二维格式的数据，而 MDX 检索的是多维数据，这使得业务分析员可以执行像上卷和向下钻取这样的任务，并且可以根据业务需求将数据切片和切块。MDX 有三种级别的用法：1-2 维结果中的基本数据检索，MDX 公式（formula），以及立方体的 n-维结构中的复杂数据检索。 其他 XML/AXML for Analysis 是由 Microsoft 的 OLE DB for OLAP 派生而来的，因而与其祖先有很多相似之处。这里主要的不同点是它是基于 Web 服务的，因而也是平台无关的，并且不会与任何特定的客户机或服务器有紧密的耦合。 MDAPIMDAPI 是 OLAP Council 建议的，它被设计用来支持各种各样的计算环境，这使得它与 Microsoft 的 OLE DB for OLAP API 区分开来。它允许客户机和服务器通过像 DCOM、CORBA 和 Java 这样的标准技术进行通信。这种 API 提供了一些 Java 库和 COM 对象，并且可以与 C+ 和 Java 这样的编程语言集成。此外，像 Visual Basic 和 Java Script 这样的应用程序开发工具也可以访问这种 API。不幸的是，还没有对这种 API 的实际支持。 JOLAPJOLAP 是一种基于 Java 的多厂商 OLAP API 计划（initiative），它基于 J2EE 平台下 Java API 。这种 API 允许以一种厂商无关的方式操作 OLAP 数据和元数据。它负有两个主要的使命：通用 OLAP 查询和管理 OLAP 数据以及元数据。Microsoft 的 OLE DB for OLAP 和 XML for Analysis 以及 OLAP Council 的已废弃 MDAPI 的目标是创建一种通用的 OLAP 查询 API。JOLAP 扩展了基本函数，并且提供了对创建、存储、访问和操作 OLAP 服务器和多维数据库中数据的计划支持。 由于没有通用标准，在可以预见的将来，我们还需要继续使用多种接口。近期内，选择 OLAP 报告引擎技术仍然十分重要，因为这种技术支持将在某个环境中采用的 OLAP 技术。幸运的是，大多数的领先报告引擎确实支持多 OLAP 技术。OLAP 访问和集成的新范例 有了 Greg 在 BI 方面的知识，Christina 召集业务流程和业务规则引擎开发小组来讨论集成过程，并评价几种市场上的产品。经过多次自由讨论会议并评估了这些产品的优缺点之后，他们达成了下面的几条设计原则。这些原则不仅使集成过程健壮而有弹性，并且还使得商业智能在全球全天候（每周7天，每天24小时）可以为不同层次的决策利益相关者所用。 第一条原则：以 XML 格式进行数据交换 由于 XML 是一种用于数据交换的公共语言，XML 格式被普遍接受，因此开发小组断定 XML 格式的 OLAP 数据比非 XML 的专有格式的数据要好。多维技术已经发展到了比较高级的程度，因而开发小组可以直接利用已有的解析器、数据确认工具以及 XSL 转换。当前 XML 包括了 XML schema 和 DTD，通过它们可以确认或检验文档的结构化内容。当数据与期望某种特定结构的遗留系统进行交互时，验证文档有效性有助于防止发生错误。此外，通过动态地转换 XML 数据，使得利用单个源进行多项输出成为可能，而不管那些输出是要集成到不同的遗留应用程序中，还是集成到数据库或 J2EE 应用程序中。 第二条原则：使用遵从 J2EE 规范的技术 新的 OLAP 应用程序应该支持标准 J2EE 应用程序开发。J2EE 为构建应用程序定义了一个完整的开发范例。在这个范例中，HTML 页面用于静态内容，JSP 用于动态内容，而 servlets/EJB 则用于应用程序逻辑。通过遵从这一范例，可以集成 BPI/EAI 服务器、商业智能应用程序和操作性应用程序，从而产生出一种更有效的架构。 第三条原则：在一个应用程序中分析关系数据和多维数据 商业智能系统应该能够以一种实时方式既检索关系数据源又检索多维数据源。随着公司的扩张及合并，IFM 的数据现在驻留在一些不同的数据源中，例如 Financial、HR、CRM、ERP，等等。在最优情况下，如果能够在一个应用程序中访问遗留关系数据库和多维数据库中的实时信息，将有助于 IFM 检测市场变化，并及时地作出响应。否则，操作性系统和商业智能中的数据就仍然是筒仓式的。 基于上述三条原则，Christina 请求 Greg 再深入研究一下市场，并提出一个能够满足公司需求的商业智能解决方案。3（下）-用BPM、业务规则和商业智能创建智能的、灵活的解决方案接上文场景解决方案架构概述（灵活的动态定价） 架构流图 回过头来再谈本系列中 文章 1（1、2） 和 文章 2 （1、2） 里面的内容，Christina 有一个需求，那就是将他们的遗留定价系统转换成一个灵活的新定价模型，这个定价模型以从数据仓库中历史信息和分析信息得来的当前利润值为基础。此外，这个动态定价模型还应该足够灵活，能够考虑到一些新的因素，例如供应链、销售、客户反馈和竞争对手。Greg 认识到，为了创造这种灵活性，他们可以利用业务流程管理作为商业智能和决策规则引擎之间的集成中心。当发现了市场利基（market niche）并创造出了新的需求时，他们就可以通过使用 WebSphere Business Integrator (WBI) 流程设计工具来快速地更改业务流程流。这种架构引入了对业务流程的实时分析功能，并且具有提供不同业务决策规则的灵活性。因此，它允许 IFM 预测在价格响应性（responsiveness）方面的波动，从而相应地设置价格。 商店经理将登录到门户应用程序并输入定购信息。之后门户的前端生成一个 XML 订单文件，再由 JTEXT Connector 将该文件解析成 PurchaseOrder 业务对象。然后该连接器进一步调用一个映射，将 PurchaseOrder 转换成 WebSphere Business Integration ORDER 普通业务对象。由于协作（collaboration）被指派来处理该 ORDER 对象，于是协作触发它的预定义业务流程，以便从分析引擎调用 getProfit%，以及从规则引擎调用 getMarkup。然后，通过 JTEXT Connector 应用一个映射将 WBI ORDER 对象转换成应用程序 PurchaseOrder 业务对象。接着 JTEXT Connector 将 XML 格式的结果写出到文件系统。然后该门户再读取该文件并以可读性好的表格形式将结果显示出来。图 2 表示了上述架构流注1。图2（架构流图）OLAP 访问技术简述 数据仓库小组将来自不同数据源（例如 ERP、CRM 和操作性存储）的数据合并起来，并建立一个星型模式，在 DB2 OLAP 服务器中可以利用这种模式来定义立方体。通过利用 DB2 OLAP 服务器的功能性，该小组建立一个多维立方体，这个多维立方体包含产品、时间、商店、人口、客户和度量等一些维。一旦这个立方体可以使用，他们就有三个任务需要处理。 要构建什么样的报告？ 要访问一个立方体是很复杂的，因为 API 存在很多可能的派系。更糟糕的是，API 本身就很复杂。这里实际的问题就是导航立方体以获得业务分析员想要的信息单元这一任务的复杂性。 以 IFM 为例。有很多方法可以将立方体切片和切块以检索利润信息。他们可以使用上个月按地区计算的评价产品利润，也可以使用上季度全公司的平均产品类别利润，还可以使用上个月商店的平均产品利润。上述几种可能的计算方法会各自形成一些不同的将立方体切片和切块的方法，从而产生了 1-维、2-维或 n-维的结果集。 OLAP API 可以检索文本格式的结果，但是要想灵活地对立方体进行导航，还需要一个 OLAP 报告实用程序。OLAP 报告实用程序允许用户通过向上钻取来查看聚合的值，通过向下钻取来查看更详细的值，通过将某些维切片来比较这些值，还可以通过将立方体切块来调查研究最原子的信息。 下面的图 3 展示了 IFM OLAP 报告的一个例子，该报告以三个维（产品、市场和时间）来报告利润百分比。业务分析员可以在立方体上自由导航，随意地查看这三个维所有可能的交叉点，并且可以自由地选择查看表格形式的数据还是图形式的数据。由于采用了一些高级的 OLAP 报告实用程序，他们还可以用一个条带（binding）系统来表示业绩以及可能触发外部动作的警报。图3（IFM OLAP 报告的例子） 查询在哪里？ 业务分析员具备对立方体进行导航以检索关键信息的业务洞察力和专业知识，但是他们不一定具有理解 OLAP API 所需的技术知识。传统的方法是，业务分析员选择一种喜欢的报告，然后由 IT 专家指出相应的 OLAP 查询。在业务分析员和 IT 专家之间总存在一定的延时，并且可能出现错误的传达，要使公司转变成更快速响应的随需应变企业，这是一大障碍。 OLAP 报告实用程序已经得到了很好的发展，这些工具可以提供图形化的查询生成器，这种查询生成器允许业务分析员选择各个不同的维并动态地对立方体上卷、向下钻取、切片和切块。一旦业务分析员对视图觉得满意，查询生成器将生成 OLAP 查询。然后业务分析员就可以保存该查询，并通过邮件将其发送给 IT 专家，IT 专家将使用该查询来启用业务流程，以访问商业智能。IFM 将采用这种方法，而最适用的利润计算方法被证明是上个月按地区计算的平均产品利润。 如何支持 XML 格式的 OLAP 数据？ 开发小组接下来要做的一步就是在 OLAP 报告实用程序（在我们的场景中是 Alphablox）中提交 XML 格式的数据，以便 BPI/EAI 应用程序可以访问商业智能信息，并相应地对其进行处理。 清单 1 中展示的例子演示了所涉及的过程和步骤。 1 定义一个带有标准 DataBlox 控件的 HTML 页面。第 2-3 行展示了如何包括一个 DataBlox 控件并定义它的数据源。 2 使用 DataBlox 的属性或方法来指定它的数据源和查询字符串。第 6-17 行演示了如何接受用户输入的两个可能的参数（productId 和 state），以建立用于找出那种产品利润百分比的查询。 3 定义包含 JSP 文件的应用程序和包含该立方体的数据源。 4 调用该应用程序，确保将 render 属性添加到该应用程序的 URL 中： ./AppName.jsp?render=XML 以我们的场景为例，我们将通过访问下面的 URL 来调用上述应用程序： http:/businessIntelligence:9080/IntegratedAnalysis/profit_XMLDatablox.jsp?render=XML&productId=300-20&state=Utah 该 URL 中的第一个参数是 render=XML ，它使得结果集以 XML 格式提交，该 URL 还有一些动态参数，例如用于指定产品的 productId 参数和用于选择特定国家的 state 参数。 清单 1. 在 OLAP 报告实用程序中以 XML 格式提交数据1: 2: 5: %6: String productId=(String)request.getParameter(productId);7: System.out.println(productId=+productId);8: String state=(String)request.getParameter(state);9: System.out.println(state=+state);10: String queryString=Sym Column ( Year, Measures) Profit %+11: 19: 20: 21: XML Datablox view22: 23: 24: 展示 对动态定价项目进行了数个月的集成和开发之后，项目小组已经克服了所有的障碍并解决了所有的技术问题。图 4 中给出了程序的试运行结果。经理可以登录到门户服务器中并使用订单 portlet，该 portlet 允许她选择某种产品并指定一个数量。接着该 portlet 通过商业智能工具动态地算出利润百分比，然后将该数据传播到规则引擎，以算出加值百分比。下面的图 4 显示，利润百分比是 30%、33% 和 26%，推荐的加值百分比根据某种动态定价算法而发生变化，在这种算法中，当利润率下降时加值百分比将增加，当利润率上升时加值百分比将减少。图4（BPM 程序的试运行）新技术：DB2 Cube Views 8.1 最近，DB2 Cube Views 这种新产品让 OLAP 技术专家们激动不已。从 IFM 集成的角度来看，这种产品作为已有 OLAP 服务器的加速器，提供了一个优化的 OLAP 解决方案，这是由于它支持带有 OLAP 能力的数据库。OLAP 开发者对以下几个重要特性很感兴趣： 集中式元数据仓库 多维元数据与数据仓库元数据之间的分离已经存在多年了。这是因为多维元数据被捕获并保存在特定 OLAP 厂商的专有仓库中。结果，这些仓库便形成了一个个的筒仓，从而阻碍了元数据的交换。DBA 们都因试图同步关系数据库与多维数据库之间的元数据而劳累不堪，更因要分析将元数据从数据仓库更改到多维数据库所产生的影响而色变。 为了缓和这个问题，DB2 Cube Views 扩展了编目（catalog）以容纳多维对象，从而将传统的元数据和多维元数据都包含在一个仓库中。它还可以从定义了关系数据库或多维数据库中的元数据的 XML 文件导入数据或将数据导出到这种文件中。这种功能允许端到端的元数据流，并减少了由于模式的更改而导致的对 BI 工具的额外维护费用。尤其是它还减少了在管理多个元数据仓库时的重复劳动以及错误。 优化的 OLAP 风格的数据访问 实例化的查询表（Materialized Query Tables，MQT）在 DB2 中被用来提供预先计算好的、聚合的、被存储的数据，这些数据都是要重复访问的。通过利用 MQT，那些代价较高的表联结（join）操作和计算量较大的计算可以只执行一次，后面类似的查询可以使用已有的数据来更快地返回结果。通过适当地构建 MQT，可以显著地提高性能。Cube Views 一个有趣的特性是，Optimization Advisor 向导可以帮助生成 MQT。通过分析元数据和需求，Optimization Advisor 将生成一套推荐的总计表，用户可以根据自己的需