IBM® WebSphere Process Server 可以用来在面向服务体系结构 (SOA) 中运行业务集成应用程序。它提供高级的业务过程管理系统，可以执行业务过程，能够与消息传递设施、Web 服务和各种后端系统集成。
图 1 显示 WebSphere Process Server 的主要组件。
图 1. WebSphere Process Server 组件
图 1 的底部显示 WebSphere Process Server 的基础设施 —— WebSphere Application Server。位于基础设施层之上的是 SOA 核心层，其中包含 Service Component Architecture (SCA)、业务对象 (BO) 和通用基础事件（CEI)。
SOA 核心层的上面是支持服务。这包括来自 Enterprise Service Bus (ESB) 的仲裁流以及各种映射组件、选择器和业务日历。最上面一层包含用于编排业务过程的各种元素：业务过程和业务状态机、人工任务和业务规则。
WebSphere Process Server 使用多个数据库或数据库表存储运行时数据。这些数据库用来存储以下方面的信息：
- 业务过程、人工任务和业务状态机：这些信息存储在 Business Process Choreographer 数据库 (BPEDB) 中。每个 Business Process Choreographer 部署目标有一个数据库。
- 由 Business Process Choreographer Explorer 报告功能使用的来自业务过程事件的数据：这些信息存储在 Observer 数据库 (OBSRVDB) 中。每个 Business Process Choreographer 报告功能部署目标使用一个数据库。
- 关于业务规则、选择器、仲裁、Business Space 和失败事件的信息：这些信息存储在公共数据库 (WPRCSDB) 中。每个单元使用一个数据库。
- Enterprise Service Bus 日志：这些信息存储在 ESB Log Mediation 数据库 (EsbLogMedDB) 中。
- 消息传递信息和 Service Integration Bus (SIB) 消息：它们存储在由 WebSphere Process Server 使用的总线的 SIB 数据库表 (MEDB) 中。每个消息传递引擎有自己的一组表。
- 公共事件：这些数据存储在公共事件数据库 (EVENT) 中。每个 CEI 部署目标有一个数据库。
根据业务需要或可用的基础设施，WebSphere Process Server 可以使用多种拓扑。图 2 给出许多客户环境中常用的三种主要拓扑。可以使用管理控制台提供的模式和向导安装和配置这些拓扑。
除了集群式拓扑之外，WebSphere Process Server 还可以在单独的服务器环境中运行。但是，这种设置更适合开发环境，典型的生产环境最好使用集群式拓扑。因此，本系列主要关注集群式环境和其中适用的拓扑。
关于 WebSphere Process Server 拓扑的更多信息，请参见 IBM Redbook WebSphere Business Process Management V6.2 Production Topologies。
WebSphere Process Server 环境通常是集群或单独服务器实例的组合，它们运行服务器代码、数据库、用户注册表以及后端和前端系统。管理员主要负责维护 WebSphere Process Server 环境。这包括运行时服务器本身，以及用来存储 WebSphere Process Server 运行时数据的数据库。尽管常常由不同的管理员分别负责这些资源，但是我们认为应该对保持 WebSphere Process Server 环境顺畅运行所需的整个设置有一个总体了解。
生产环境需要连续地监视。因为 WebSphere Process Server 基于 WebSphere Application Server，所以 Application Server 管理实践也适用于 WebSphere Process Server。另外，有专门针对 WebSphere Process Server 的系统监视工具和实践。
WebSphere Application Server 提供大量工具，可以从应用服务器的角度管理系统。详细信息参见 IBM Redbook WebSphere Application Server V6.1: System Management and Configuration。
WebSphere Process Server 为 Application Server 管理控制台提供更多功能，比如管理失败的事件和浏览公共事件。下面几小节将解释需要监视的内容。
需要设置监视工具，从而在发生系统事件时通知系统管理员。例如，某个队列超过了为它定义的阈值。另外，这些工具提供从系统收集的信息，从而修复或响应这些事件。至少应该通过自动化脚本收集操作支持所需的所有数据。
WebSphere 的 MBean API 与 Java™ Management Extension 兼容，它们提供许多可监视的项目，可以以程序方式管理系统中的更改。可以使用这些 API 方便地编写定制的监视应用程序。关于这个主题的更多信息，请参见以下信息中心主题：关于这个主题的更多信息，请参见以下信息中心主题：
- 使用管理程序 (JMX)
- 使用 WebSphere Application Server 管理 Java API 来创建定制 Java 管理客户机程序
- 开发管理客户机程序
- WebSphere Application Server Release 6.1 Public MBean Interfaces
除此之外，还可以实现复合应用程序监视工具。可以使用这些工具提供 WebSphere Process Server 环境中部署的复合服务的可用性和响应时间报告。
实现这种工具的方法是，让定制的服务定期调用涉及的子系统上的 “心跳” 应用程序，或者通过现有的监视、警报和报告基础设施中集成的 Tivoli® ITCAM 等解决方案实现。
提示：应该定期检查日志中的错误消息。
WebSphere Process Server 环境中的 JVM 会在日志文件中写入信息，如果启用了跟踪，还会将信息写入跟踪文件。这些日志文件能够很好地反映系统的总体健康状态。另外，如果在运行时处理期间发生意外问题，就会生成 First Failure Data Capture (FFDC) 文件。
在典型的 WebSphere Process Server 集群环境中有多个 JVM。每个 JVM 根据自己的需要记录信息和错误（见表 1）。
表 1. JVM 在 WebSphere Process Server 环境中的典型用途
| JVM | 用途 | 要寻找的信息 |
|---|---|---|
| Deployment Manager | 中心配置点。 | Deployment Manager 的日志文件对于判断配置问题很重要。 |
| Node Agent | 通信和配置更新。 | Node Agent 的 JVM 日志对于判断通信问题通常很重要。 |
| ME 集群成员 | 驻留消息引擎。 | JVM 日志显示处于 “Started” 或 “Joined” 状态的消息引擎，或者是否有失败。 |
| 应用程序集群成员 | 通常驻留 Business Process Choreographer。 | JVM 日志显示执行业务过程和人工任务的相关信息。 |
| 支持集群成员 | 通常驻留 Common Event Infrastructure 和 Business Space。 | JVM 日志显示执行 Business Space 和处理 CEI 事件的相关信息。 |
关于可用的日志记录选项和如何指定它们的概述，请参见 IBM Redbook WebSphere Application Server V6.1: System Management and Configuration。它概述可以使用的所有日志记录选项。
需要定期检查日志文件以便快速发现问题。另外，应该定期监视 FFDC 目录。从 WebSphere Process Server 6.1 开始，JVM 的 SystemOut.log 文件中的条目会表示出 FFDC 的创建以及它们在系统上的位置。
一般情况下，生产环境中的跟踪应该被设置为最低级别。如果没有特殊的需要（例如为了判断问题），不要 启用详细级别高于 INFO 的跟踪。
应该保留那些记录各个组件在启动服务器之后进行初始化的日志文件，因为它们包含重要的信息，比如组件的构建级别可能与 WebSphere Process Server 的总体构建级别不同。例如，如果在安装一个临时补丁之后没有调用 bpeupgrade.jacl，BPC Explorer 就会处于与 WebSphere Process Server 系统总体级别不同的级别。
我们还建议启用详细的垃圾收集跟踪。它对性能的影响非常小，可以连续地监视与堆使用情况相关的系统行为。关于如何启用这个特性及记录数据的位置的更多信息，请参见 Enabling verbose garbage collection (verboseGC) in WebSphere Application Server。
应该确保文件系统中的磁盘空间和访问权限支持 WebSphere Process Server 日志记录。
除了 WebSphere Application Server 日志记录和跟踪特性之外，WebSphere Process Server 还提供 跨组件跟踪。这种跟踪显示 SCA 组件交互方面的详细信息。
在 WebSphere Process Server 解决方案中广泛使用了业务过程实例，包括业务状态机和人工任务实例。它们存储在 Business Process Choreographer 数据库 (BPEDB) 中。为了保证系统的健康状态，数据库的规模不应该无限制地增长。
管理已完成的业务过程实例和人工任务
提示：应该尽可能减少实例的总数。
业务过程和人工任务实例完成之后，实例可能留在数据库中，也可能自动地删除。对于在完成之后没有自动删除的实例，WebSphere Process Server 系统管理员需要特别注意。
您需要与拥有实例的相关人员一起决定已完成的实例必须保留多长时间。需要根据这个决定实现一个管理操作，删除不再需要的实例。本系列的 第 2 部分 详细讨论从 Business Process Choreographer 数据库中清除已完成实例的各种方法。
在大多数情况下，把实例保留在数据库中是为了以后检查它们的相关信息。但是，一定要明白一点：运行时数据库只保存快照而不是完整的历史。本系列中后续的一篇文章将讨论适当的存档方法。
修复业务过程实例
提示：检查和修复正在等待的过程实例。
长时间运行的业务过程的寿命可能长达几年，但是 WebSphere Process Server 环境中运行的业务过程的业务功能所有者常常会定义最大时间。建议定期检查那些已经超过最大持续时间的过程实例。另外，需要定期检查在执行业务过程期间是否发生了错误，导致某些活动进入 STOPPED 状态。这些活动需要人工干预，过程实例才能继续执行。
在 BPC Explorer 中，可以使用预定义的 “Critical processes” 视图，还可以定义定制的视图，根据指定的筛选条件只获取有问题的实例。我们建议为您的业务过程实例定义这种视图并定期监视它们。需要结合业务功能分析显示的所有实例，决定是需要增加持续时间，还是需要人工干预（比如重新启动活动或终止这个实例）。
本系列中后续的一篇文章将提供详细信息。
提示：尽可能消除失败的事件。
如果在 SCA 组件之间异步地处理请求时发生技术故障，就会产生失败的事件。可以在管理控制台中使用失败事件管理器用户界面检查这些事件，然后重新提交或删除它们。可以通过管理控制台或 MBean 接口访问失败事件管理器。您需要与应用程序所有者一起制定处理失败事件的管理战略。关于失败事件管理器的更多信息，请参见 WebSphere Process Server 信息中心主题 Failed event manager。
可以实现自动处理已知的失败事件的过程，还可以实现自动监视失败事件管理器中的新事件的过程。我们建议这么做。可以使用 MBean 接口编写自己的监视应用程序。关于失败事件管理器接口的更多信息，请参见 FailedEventManager interface。
本系列中后续的一篇文章将提供关于失败事件处理的更多信息。
提示：如果可能的话，根本不要使用 CEI 事件存储。
可以把 WebSphere Process Server 中的组件发出的公共事件存储在公共事件数据存储（EVENTS 数据库）中，而不是发布在 CEI 总线中。可以启用或禁用事件的发送和存储。如果您的系统支持将这些事件存储在事件数据库中，那么需要使用管理控制台中的 CBE Browser 监视并主动地管理它的大小。
信息中心的以下主题讨论如何使用公共事件：
WebSphere Process Server 允许通过消息传递集成后端系统。它还在服务集成总线上使用消息传递进行内部处理。因此，监视和管理系统中的消息是很重要的。除了关注生成的 SCA 模块队列和 JMS 导出和导入使用的定制队列之外，还需要特别关注以下队列。
监视和重放 Business Flow Manager 和 Human Task Manager 持有队列
提示：保持持有队列为空。
必须监视 Business Flow Manager (BFM) 持有队列和 Human Task Manager (HTM) 持有队列。持有队列中的消息常常用于导航长时间运行的业务过程实例。在 BFM 持有队列中出现消息的原因可能是系统的临时负载过高，这种情况可能导致事务超时并回滚。为了在这种情况下不丢失消息，系统把消息放在持有队列中。这些队列中的消息数量应该是零，因此如果其中出现消息，就需要管理员人工干预。
从 WebSphere Process Server V6.2 开始，可以通过失败事件管理器访问这些消息，还可以重放它们。本系列中后续的一篇文章将解释管理这些消息的各种方法。
监视系统异常目的地
提示：保持系统异常目的地为空。
WebSphere Process Server 使用几个服务集成总线进行消息传递。每个总线有一个系统异常目的地。服务集成总线无法处理的消息存储在这里。无法处理消息的原因可能是：
- 系统负载过重，这导致事务超时并回滚。
- 消息的内容损坏或消费应用程序无法读取它。
- 应用程序错误。
应该监视系统异常目的地的队列深度。目标是保持这些队列为空。可以使用定制的管理脚本监视队列，还可以使用 Service Integration Bus Explorer 或 Service Integration Bus Destination Handler 等工具。从 WebSphere Process Server V6.2 开始，还可以在管理控制台中使用 Service Integration Bus Browser。本系列中后续的一篇文章将详细解释如何处理这些队列中的消息。
监视 WebSphere MQ 监听器端口的状态
提示：确保监听器端口正常运行。
在从 WebSphere MQ 队列获取消息时，Process Server 要使用监听器端口。需要不断监视这些端口，确保它们已经启动，让 Process Server 可以从 WebSphere MQ 获取消息。
可以使用管理控制台或 ListenerPort MBean 监视系统中的监听器端口的状态。我们建议使用 ListenerPort MBean 实现一个监视应用程序，用它定期检查端口状态并根据需要重新启动端口。
提示：确保释放锁。
事件序列可以确保 WebSphere Process Server 组件按事件的交付次序处理它们。在整个业务集成场景中维护事件次序以保证异步调用正常运行。
事件序列服务通过在 WebSphere Process Server 的后端数据库上存储锁来确保这个功能正常运行。
有时候无法释放这些锁，就需要使用 esAdmin 命令人工释放锁。更多信息参见以下 WebSphere Process Server 信息中心主题：
提示：确保到达的工作不会堆积起来。
WebSphere 有许多适配器，可以在模块的输入端和输出端使用它们。在输入端使用适配器时，建议使用事件存储保存从数据库、文件系统或 EIS 读取的事件，从而避免在交付过程中丢失事件。在这种情况下，应该定期监视事件存储，避免事件堆积起来。
到达的工作（比如平面文件适配器的文件系统中的文件或 JDBC 适配器的数据库表中的数据）不应该以超常的速度增长。
关于适配器的更多信息请参见 Configuring and using adapters。
提示：定期更新数据库统计数据。
要想维护健康的生产环境，必须管理它的后端数据库。第 3 部分 讨论一般的最佳实践。
提示：不断监视操作系统资源。
为了确保系统健康，不但需要维护 WebSphere Process Server，还需要定期监视操作系统级别的情况。应该监视 CPU 和内存使用量、网络和 I/O 利用率以及空闲磁盘空间的数量。
为了给临时性的高峰负载留出足够的容量，平均资源使用量不应该接近基础设施的限制。
提示：在维护时删除它。
当管理单元中的 JVM 停止并且没有活跃的配置会话时，需要定期清除这个目录的内容。这对安装应用程序等配置操作的性能有积极影响。
应该在部署过程中包含清除 wstemp 目录内容的步骤。在这个过程中，一定不要 删除 wstemp\events 子目录及其内容。关于 wstemp 目录的详细信息参见 Content and maintenance of the wstemp directory for WebSphere Process Server V6。
需要定期修改 Process Server 系统，包括引入新的应用程序、更新应用程序、更改配置和应用最新的服务包。这些修改都需要仔细地管理。
在对生产环境做任何修改之前，必须在与生产环境相似的测试环境中进行充分的测试。在生产环境中不加控制地引入修改会破坏系统。例如，在现有系统中添加新的应用程序可能会影响现有应用程序的服务水平，因为系统资源现在由更多应用程序分享。应该用更改日志记录修改的内容、修改的时间和应用修改的人。
在引入修改（比如产品维护或应用程序更新）之前，还应该建立系统的备份。全面可靠的备份战略是每个 WebSphere Process Server 环境都必须包含的部分。
除了 WebSphere Application Server 应用程序管理实践（比如安装、卸载和更新应用程序）之外，还有 WebSphere Process Server 特有的应用程序管理主题和最佳实践。
与一般的 Application Server 应用程序不同，WebSphere Process Server 应用程序的组件可能有长时间运行的实例。例如，系统中的业务过程实例可能会运行好几周。卸载相应的应用程序会破坏业务操作。
Process Server 应用程序基于 SCA 模块。可以通过 Process Server 管理控制台检查这些模块。在应用程序管理期间，需要特别关注一些 Process Server SCA 组件实现（比如业务过程）。例如，在卸载或更新包含业务过程或人工任务的应用程序时，需要额外的操作。另外，还可以停止过程和任务模板，这会禁止创建新的实例，但是仍然允许现有的实例继续执行。
WebSphere Process Server 应用程序管理的一个重要方面是 SCA 模块、业务过程和人工任务的版本化。Process Server 的版本化概念在引入新的应用程序版本的同时，允许老版本仍然存在并完成正在处理的长时间工作。关于业务过程和人工任务版本化的更多信息参见 Versioning business processes and human tasks in WebSphere Process Server。
本系列中后续的一篇文章将提供关于应用程序管理的详细信息。
有计划的维护活动有助于避免那些 IBM 已经发现并为其提供了解决方案的系统异常行为。应该制定维护计划，从而及时地应用 Application Server 和 Process Server 补丁，避免不必要的生产系统停机。
可以通过以下任务应用维护：
- 预订 My Notifications 支持内容更新，定期检查可用的补丁，判断它们对自己的生产环境的影响。
- 根据生产战略的需要，在下一个发布计划中包含应用相关补丁的步骤。
另外，需要通过有效的通知过程及时了解环境中连接的系统的所有计划内或计划外维护窗口，从而在 WebSphere Process Server 环境中采取相应的必要措施。
在本文中，您了解了操作 WebSphere Process Server 环境的基本概念。本文只是一个起点，本系列中后续的文章将详细讨论这里提到的各个主题。
第 2 部分 介绍清理已完成的过程和任务实例以保持最佳 BPEDB 大小的方法。第 3 部分 讨论 BPEDB 的数据库级维护。本系列中的后续文章将讨论应用程序管理、监视和修复或存档方法等主题。
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/14789789/viewspace-659796/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/14789789/viewspace-659796/
273
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
