比较 IBM Business Process Manager 仪表板和 IBM Business Monitor

简介

业务监控系统为企业中执行的工作提供了可见性。这些时间和成本视图使得利益相关者能够迅速解决问题，制定明智的决策，并改进工作方式。因为业务流程管理系统可以协调工作，所以监控是所有业务流程管理解决方案的一个重要组成部分。

IBM Business Monitor 是企业解决方案中可用于业务监控的最佳技术之一。然而，有了内置在 IBM BPM V8.5 中的、经过显著改进的仪表板，许多从业者都在问，如何识别何时这些内置功能是足够用的，何时需要额外的 IBM Business Monitor 产品。本教程将通过解释一个业务场景并检查代码工件来探讨这两个选项。本文将了解一些洞察，它们有助于评估在各种不同场景中哪种设计方法是最适合的。

您应该大致熟悉 IBM BPM 产品和基于业务流程建模标记 (BPMN) 的流程定义。本教程提供了 IBM BPM 和 IBM Business Monitor 的监控功能的简要说明。

范围

本教程中的讨论只集中于监控 IBM BPM 流程应用程序。像其他许多软件产品一样，IBM BPM 也有一些内置的监控功能。不过，在项目开始时，很容易评估某些特性，可以快速确定 IBM BPM 内置监控何时 不 匹配特定用例的需求。虽然 IBM Business Monitor 是一个通用的监控解决方案，可以扩展该解决方案，提供整个企业中的业务活动的综合视图，但 IBM BPM 却不是这样，原因如下。

IBM BPM 内置监控特性旨在监控仅在一个服务器集群实例上运行的流程。无法监控其他应用程序或远程服务器（无论是 IBM BPM 还是其他技术）的业务活动，也无法监控 IBM BPM Advanced 的 Business Process Execution Language (BPEL) 技术子流中实现的事件。如果您的项目需要任何这些特性，那么 IBM Business Monitor 不仅是一个很好的解决方案，还是在所有 IBM 监控技术中的惟一选择。这里的讨论只研究了应该在您的 IBM BPM 应用程序中使用 IBM BPM 的内置监控功能，还是使用 IBM Business Monitor。以 IBM BPM 为基础的解决方案是这两种技术重叠的惟一领域。

业务场景的代码示例

本教程中的场景模拟一家医院的附属公共医疗诊所。代码示例提供了两个监控实现：一个是使用内置的 Dashboards 工具包构建的，另一个刚使用 IBM Business Monitor 构建。在图 1 中所描绘的 BPMN 模型显示了流程。

图 1. 医疗诊所内运行的 BPMN 流程图

该解决方案需要至少为两组利益相关者提供服务。第一组利益相关者包括护士、医生和诊所经理，他们负责日常运营。这些团队希望看到最紧迫的情况能够最快地被处理，他们希望在等待时间超过预期时能够收到通知。他们需要了解哪些同事负担过重，以及哪些地方可能存在额外的容量。为了实现这些目标，这些利益相关者仅关注当前正在处理的情况。这些团队参与 “运营” 用户故事，因为利益相关者正在使用未完成的流程。

第二类利益相关者负责改进工作方法、战略规划和投资，获得有效的整体运营。这些分析师和高管需要发现和分析趋势，确定关系，更深入地了解运营。他们感兴趣的是大量流程的性能特征，包括整个历史时间段中正在进行的和已完成的流程。这组利益相关者将会参与 “分析” 用户故事。

本教程将会展示：内置到 IBM BPM 中的仪表板技术往往能够满足运营类 IBM BPM 用户的需求。相比之下，IBM Business Monitor 为运营用户提供了更强大的功能（通常需要高级定制），但 IBM Business Monitor 特别适用于满足分析类工作人员的需求。

回页首

职能性功能

我们需要一些定义，以提供用于讨论每种技术中的功能的词汇。

指标 是业务信息的持有者。在本教程中的示例指标包括患者的等待时间、治疗设施的位置、诊断，以及一些成本信息。术语 事实 有时在其他产品的上下文中被用来描述这种想法。IBM BPM 自动捕获这些指标，如果流程开发人员有专门标记，IBM BPM 还可以捕获其他指标。

维度 是用于报告或分析的一组指标。例如，利益相关者可能希望看到按设施位置分类的当前病例。时间是另一种常用维度。

将一个维度组织为一个层次结构，这样做通常十分有用。例如，某个位置维度可能被进一步分解成地区、州和城市。这些级别使得用户能够 向下 钻取 到相继更细粒度的信息。

量度 ，有时称为 汇总 ，是基于指标的计算。例如，利益相关者可能希望看到患者的平均等待时间，或者当前等待看病的患者的总数。报告通常包括至少一个维度，并且可视化了一些量度。

维度分析 描述根据绩效指标评估业务运营的多个方面的行为。例如，利益相关者可能希望探索按设施、成本和患者愈后结果进行分类的平均等待时间。

关键绩效指标 (KPI) 是关键成功因素的量度。例如，经理可能要管理诊所，这样某些类型的病例的等待时间就不会超过某个阈值。KPI 通常是实时监控的，以便根据 服务水平协议 (SLA) 管理运营。

利用 IBM BPM 仪表板实现用户故事

IBM BPM 为最常见的流程监控用例提供内置的可视化， 即 仪 表板 。内置的 IBM BPM 报告提供了有关流程和工作人员状态的摘要及详细信息。大多数的状态信息涉及当前工作量计数，以及准时与逾期状态。图 2 显示了一个例子。在 IBM BPM V8.5 Process Performance Dashboards by Gerhard Pfau 和 IBM BPM V8.5 Team Performance Dashboards by Gerhard Pfau 中提供了两个演示这些特性的短视频。

图 2. IBM BPM 示例仪表板

过滤特性让您可以选择满足某些搜索条件的流程或任务的子集。仪表板用户还可以向下钻取摘要图表，获取特定病例的详细信息。不过，这些图形仪表板只显示与预定义量度相关的状态，也就是说，只显示任务和流程的时效， 以及任务和流程的实例数量。

根据 IBM BPM 团队的经验，在内置仪表板中，由这些预定义量度提供的特性涵盖了运营利益相关者的许多最常见用例。然而，如果利益相关者希望在其报告中包含下列任某种特性，就需要执行一些自定义开发。以下列表包括了一些示例，但并不意味着它是一个完整列表。

• 定义尚未定义的新量度。例如，利益相关者希望看到不同类别的工作人员或设备成本。
• 自定义可视化。例如，一个利益相关者想将成本表示为条形图。
• 将图表汇总为一个自定义布局。例如，您的组织在三个地点有三个分厂。利益相关者要求您创建有三个 Process Status 图表的屏幕，显示所有三个分厂的流程，并用一个图表显示每个地点的状态。
• 定义定制的外观，比如图形的类型，或不同的图表和图形的布局，或者样式和颜色。

构建自定义报表有两个要求：能够访问绩效数据，以及图形用户界面编程工具。IBM BPM V8.5 引入了 Dashboards 工具包，以便提供一个应用程序编程接口 (API) 来支持数据访问和图形。在 IBM BPM V8.5 之前，开发人员通常会访问该产品的 Performance Data Warehouse 来获取绩效和业务数据，并使用第三方 JavaScript 库创建图形（例如， dojox.charting 库）。具体情况取决于不同的用例，对 Performance Data Warehouse 进行直接的 SQL 查询来检索绩效数据可能仍然更简单，有时甚至更快。您可以从 “下载” 部分的code_sample.zip文件中提取示例代码，该示例代码探索了这两种数据访问的方法。

在示例代码中， Dimensional Report 人性化服务实现了一个自定义的仪表板。它首先使用 TWProcessPerformanceMetric Javascript 对象检索绩效数据，这是 IBM BPM V8.5 中的新特性。请注意，这种方法只提供未完成流程的信息。示例代码通过对 Get data from PDW 服务中的 Performance Data Warehouse 执行 SQL 查询来执行另一种数据检索方法。通过这两种方法检索到的数据最终都被移入 ChartData 业务对象，这是后续的图形方法所需的正确数据类型。最后，顶层的仪表板排列出 Chart 图形对象的四个实例，创建四个图表。 Chart 是在 Dashboards 工具包中提供的一个图形对象集合。应用程序开发人员构建图形仪表板时使用的用户界面 (UI) 框架与用来构建 IBM BPM 人性化服务（称为 Coach）的 UI 框架是相同的，而最终结果可以很容易地添加到 Process Portal。图 3 显示了自定义仪表板的一个渲染。

图 3. 通过下载的示例代码来实现的自定义仪表板

实现自定义仪表板的编程工作可以相对简单一些，但仅限于所需的自定义报表与 Dashboards 工具包的可视化范例一致的时候。例如，如果应用程序需要摘要视图，在某个特定的布局中显示工作状态的摘要，那么开发人员可以相对容易地创建那个视图。但是，使用 Dashboards 工具包的自定义开发还要求有以下限制工作：

• 当您使用的量度和维度不是由内置工具包提供的时候，或者您正在使用备用图形、备用布局或类似因素，开发挑战就会变得越来越复杂。
• 仪表板是在流程应用程序中实现的，并与该应用程序一起部署。对仪表板的任何更改都需要一个新的应用程序部署周期。
• 实现需要在多个专业知识领域的 IT 开发技能。可能需要的技能包括：熟悉 IBM BPM Coach UI 框架、服务器端和客户端 Javascript，以及客户端的 CSS 和图形库。
• 根据正在开发的仪表板的复杂性，开发人员可能需要学习特定于 Process Portal 行为的技能。例如，开发人员可能需要研究 Navigation Controller 控件的行为，该控件是 Process Portal 的一部分，可以根据需要实现向下钻取操作。
• 如前面提到的，绩效指标 API 仅搜索未完成的流程。

这个列表只提供了一些约束示例，并且不是所有约束的完整列表。

总之，由 Dashboards 工具包供的绩效数据和图形对象可以满足与业务用户故事相关的流程工作人员的需求。您的用例与 Dashboards 工具包实现的范例偏离得越远，在开发自定义仪表板时所面临的工作就越多。

利用 IBM Business Monitor 实现用户故事

当您仅使用 IBM Integration Designer 工具包中的特性时，您的维度和度量也将使用 Javascript 进行预定义或从头构建。相比之下，IBM Business Monitor 提供一种模型驱动的编程范式。在 IBM Business Monitor 环境中，开发人员首先确定维度、量度，以及在模型创作环境 (IBM Integration Designer) 中的其他报表工件。在定义了模型之后，无论是开发人员还是最终用户，都可以组合不同的维度、量度、过滤器与可视化，以满足他们的需求。

即使在完成应用程序部署之后，最终用户也可以定义新的仪表板。他们可以开发视图，探索最初定义模型时所没有预料到的业务绩效关系，不需要开发人员的参与。这些交互功能使得 IBM Business Monitor 特别适合于分析任务，因为分析人员可以快速构建对运营的不同方面的评估。

IBM BPM 中的 Process Designer 创作工具可以自动生成一个 IBM Business Monitor 模型。生成的模型可用作自定义的起点，在本教程中，它被用于构建 IBM Business Monitor 部分的示例代码和插图。图 4 显示了在 IBM BPM V8.5.5 Process Designer 中的设置，用于控制模型生成特性。

图 4. 触发 IBM Business Monitor 模型生成的 Process Designer 设置

用 IBM Business Monitor 实现比用 IBM BPM Dashboards 工具包实现更简单，因为 IBM Business Monitor 开发人员只需要定义感兴趣的量度、KPI 和可视化。最终结果也会好得更多。例如，示例解决方案在 IBM Business Monitor 版本中提供向下钻取功能，但 Dashboards 工具包版本中没有提供此功能。向下钻取在模型中的实现非常简单，但是，如果使用 Dashboards 工具包，就会需要做更多的工作。图 5 显示了使用 IBM Business Monitor 中的代码示例开发的仪表板。

图 5. 使用 IBM Business Monitor 技术开发的自定义仪表板的示例

维度分析是通过 Cognos Business Intelligence 技术获得支持的，它打包并集成了 IBM Business Monitor。开发人员可以享受 Cognos Business Intelligence 产品的所有功能和工具。Cognos 许可是作为支持软件向 IBM Business Monitor 提供的。IBM Business Monitor 的许可信息文档提供了关于适当使用的详细信息。

Cognos 技术还提供了高级可视化功能。如果没有 IBM Business Monitor，那么 IBM BPM 中提供的惟一开箱即用的可视化工具就是基于 dojox.charting 的图表控件，以及在 Dashboards 工具包中用于创建内置仪表板的图形集合。此外，开发人员可以自由加载自己选择的 JavaScript 库。但是，这些库是从相对原始的工具构建的。相比之下，COGNOS 捆绑了 Rapid Adaptive Visualizations Engine (RAVE) 技术，该技术提供了用于构建可视化的复杂功能。

最后，IBM Business Monitor 为处理关键绩效指标和 SLA 提供了更强大的功能（图 6 显示了 IBM Business Monitor 中的用户自 定义 KPI）。例如，当 KPI 值超出范围时，运营工作人员可能需要一些自动通知。IBM BPM 中的编程工具提供了一些功能，但自定义编程是必需的，而且可能无法实时生成警报。IBM Business Monitor 在违反 SLA 的瞬间就会生成警报。此外，IBM Business Monitor 可以分析 KPI 历史记录，并应用趋势分析算法来预 测未来的行为。

图 6. IBM Business Monitor 中的用户定义 SLA

在 IBM Business Monitor 中，维度报表功能、量度和警报行为都可供最终用户进一步定制。在完成模型定义后，最终用户可以直接控制 SLA 的定义和管理。业务所有者可以改变警报行为，或制作自己的报表，对开发周期没有依赖性。最终的结果是产生一个更加敏捷的组织。

回页首

非职能性功能

从非职能性的角度对 IBM BPM 中的 Dashboards 工具包与 IBM Business Monitor 进行比较也很有用。最明显的因素是：IBM Business Monitor 和 IBM BPM 是两个独立的软件产品（虽然它们均由同一个 IBM 开发团队开发）。 因此，将 IBM Business Monitor 引入 IBM BPM 解决方案为解决方案团队带来了额外的任务。

• 截至 IBM BPM V8.5.5 和 IBM Business Monitor V8.5.5，两个产品都必须各自安装在自己的服务器或服务器集群上。在早期版本中，这种拓扑结构对于生产环境是公认的良好实践（因为一个 IBM Business Monitor 专用单元提供了一些优势，这将在接下来的段落中进行介绍）。从管理角度而言，每个产品应保持在自己的 WebSphere Application Server 单元中。为了支持两个单元，IT 基础架构团队必须提供足够的硬件资源，除了配置 IBM BPM 之外，还要安装、配置和维护 IBM Business Monitor 软件。
• IBM Business Monitor 与 IBM BPM 的许可是各自独立的，所以实现解决方案可能会产生额外的软件许可费用。

虽然 IBM Business Monitor 的额外服务器对于基础架构团队是额外的任务，但监控的专用组件也提供了一定的优势。功能的分离更简单。因此，对于监控功能的处理要求更加完全脱离 IBM BPM 服务器，在 IBM BPM 和监控之间的 IT 资源更容易被隔离和微调。可以在这两个组件上独立管理软件修复级别。

业务监控解决方案通常每一天都捕获有关业务活动的大量信息并存储它们。业务活动数据库不断增长，而且必须对它们进行管理。与 IBM BPM 中提供的工具相比，IBM Business Monitor 产品中提供的关于这个领域的工具更加全面一些。

回页首

结束语

本教程探索的因素可以引导解决方案架构师在实现监控时选择内置的 IBM BPM 特性，或者单独许可的 IBM Business Monitor 产品，抑或同时采用两种产品的特性。各个示例说明，内置的 IBM BPM 特性最能满足运营工作人员的需求，一般地讲，他们使用报表信息来主动管理未完成的工作负载。相比之下，IBM Business Monitor 的特性特别适用于分析人员，他们需要对历史和当前工作负载进行了大量维度分析。IBM Business Monitor 更适合于以下组织：高度重视业务用户拥有和维护报表职责，快速更改报表，支持敏捷部署。

从广义上讲，如果您想监控整个企业中的活动（其中有些活动发生在 IBM BPM 中，另一些活动发生在其他应用程序中），那么 IBM Business Monitor 就是 IBM 监控技术中的惟一选择。如果您需要深入了解在业务运营中多个变量之间的关系，您很可能需要使用 IBM Business Monitor 中由 COGNOS 提供的复杂分析工具。但是，如果您的需求全部在运营用户故事的范围之内，那么 IBM BPM 的仪表板特性有可能足以满足您的利益相关者。

本教程确定了一些因素，帮助您评估有多种需求的更复杂情况。自定义测量、可视化和报表分析变得越来越复杂，仅使用 IBM BPM 中的 Dashboards 工具中的基本监控工具实现所需的操作的难度也变得越来越大。由于这些因素变得日益复杂，IBM Business Monitor 中的建模和维度分析工具变得更有价值，作为构建解决方案的基础也越来越引人注目。

致谢

作者衷心感谢 Jim Thorpe 和 Rich Szulewski 对本教程的审查和贡献。

回页首

下载