CICS 事件处理如何工作

您可以配置 CICS® 以检测和发出应用程序事件或系统事件。 当指定事件发生时，CICS 将通过 EP 适配器收集数据并触发同步或异步过程。

可以对 CICS 进行配置，从其后的 CICS 初始化阶段到 CICS 关闭的第一个阶段结束之前，检测和发布应用程序和系统事件。 事件处理将在 CICS 初始化 PLT 处理第二个阶段开始之前开始，并在 CICS 关闭 PLT 处理的第一个阶段完成之后停止。 但是，不保证对由 CICS 关闭 PLT 程序所启动的任何新任务触发的事件进行检测。

图 1。 事件处理高级别体系结构
此图显示用于定义应用程序事件捕获点，系统事件捕获点和事件处理适配器的事件绑定编辑器。 这样，捕获的事件会传递到事件分派器以进行格式化并发送至各种 EP 适配器。 然后， WebSphere Business Events， WebSphere Business Monitor或其他事件使用者可以使用这些事件。
注: IBM Business Monitor，以前称为 WebSphere Business Monitor。
  1. 可以使用事件绑定编辑器指定捕获和发出事件的时间。
    • 将在 CICS 捆绑软件项目中创建事件绑定。
    • 捕获事件的条件和事件中要包含的数据称为捕获规范，并将保存在事件绑定中。 每个捕获规范都将与特定的捕获点关联，例如，遵循 EXEC CICS READ FILE API 调用或更改文件启用状态的点。
    • 将在 EP 适配器中指定包含所需格式和目的地的事件发布选项。
  2. 将捆绑软件导出到 z/OS UNIX 文件系统，并使用 BUNDLE 资源将其安装到 CICS 中。
    • CICS 将从 BUNDLE 创建 EVENTBINDING 和 EPADAPTER 资源。
  3. CICS 将在事件捕获点运行时检查活动的捕获规范。
    • 如果捕获规范在捕获点处于活动状态，那么 CICS 将检查过滤条件并捕获为求值为 true 的过滤条件所指定的数据。
  4. 捕获的事件将被传递到事件分派器进行发布。
  5. 事件分派器会将每个事件传递到为事件绑定指定的 EP 适配器。
  6. EP 适配器将格式化事件，并根据其配置选项将其发布到目的地。

事件被捕获后的处理方式取决于用于将其发布的 EP 适配器的发布方式和事务方式。

事务方式

事务方式可用于控制事件发布是否取决于工作单元的成功捕获。
  • 非事务型：事件一旦被捕获即可用于发布。
    • 如果无论捕获工作单元成功完成与否均要发布事件，请使用非事务型。 例如，Order Attempted 事件应以非事务型发布，因为即使工作单元未成功完成，订单未就位，您同样希望发布该事件。
    • 即使捕获工作单元退出，仍然可以发布事件，因此即使退出或未执行某些工作，同样可以获取事件，并在再次尝试工作时复制事件。
    • 这样做的好处是无需等待同步点即可发布事件，如果从长时间运行的任务捕获事件，那么该事务方式十分有用，因为可立即发布事件。
  • 事务型：当（且仅当）从中捕获事件的工作单元成功完成时，才会发布事件。
    • 仅当希望在任务成功完成的情况下发布事件时，使用事务型。 例如，仅当订单成功完成时，才应发布 Order placed 事件。
    • 因为在工作单元退出或未执行时不会发布事件，如果再次尝试工作，将避免重复事件。
    • 其缺点是，如果从在同步点之间长时间等待的任务捕获事件，那么事件将在实际发生之后的一段时间发布。
    • 事务型发布不可用于系统捕获点。 系统事件通常不是事务型的，您可能不想在发布系统事件之前等待系统工作单元完成；您可能希望尽快发布系统事件。 为引用事务型 EP 适配器的任何事件绑定发布首个系统事件之后，您将在 CICS 消息日志中收到 DFHEC1023 错误消息。

发布方式

发布方式可用于控制是异步发布事件还是作为捕获工作单元的一部分发布。
  • 异步：捕获事件之后，会将其添加到分派器队列。 会将控件返回到它被捕获的工作单元，并异步格式化和发布事件。
    • 尽可能使用异步发布，因为它对捕获应用程序的响应时间影响较小，且不会更改其行为。 具体来说，在即使无法发布事件仍可视为捕获工作单元完成时，应该使用异步发布。 例如，用于统计、监控或定位促销产品的超过 1000 美元的订单事件应异步发布，因为无论该事件是否存在订单均完整且有效。
    • 对于异步发布，不存在传输可恢复性的问题，因为无论立即发布事件还是等待同步点，CICS 都将执行正确的事务行为。
    • 事件发布失败不会更改应用程序的行为。
    • 这样的好处是，异步发布对捕获应用程序的性能影响较小。
    • 缺点是，有可能丢失未能发布的事件，例如，因为网络停运或重新启动整个 CICS。 无论是否发布事件，从中捕获应用程序的事件都能够成功完成，因此使用异步发布方式发布事件不可靠。
  • 同步：事件被捕获时，会将其格式化并作为从中捕获它的工作单元的一部分发布。 如果无法发布事件，那么事务捕获将在同步点被退回，并发出 ASP7 异常终止代码。
    • 如果事件无法发布，且捕获工作单元被认为不完整，请使用同步发布。 例如，当使用 Order placed 事件触发事件驱动订单处理过程中的下一个步骤时。
    • 事件发布失败可能会影响应用程序的行为。 例如，当发布 order placed 事件时，如果事件使用者不可用，那么将不能处理订单。
    • 这样的好处是，如果事件未能发布，将不会丢失，因为触发它们的操作将被退回，并因此不再发生。 使用同步发布模式定义的事件是可靠的，可用作事件驱动过程的一部分。
    • 缺点是，会对应用程序性能造成较大的影响。 请考虑对响应时间造成的影响，因为此时将在应用程序线程上对事件发布进行格式化。
    • 同步事件发布不可用于系统事件捕获点。 由于系统事件通常用于统计和监控，一般不需要进行同步发布。 针对引用通过同步发布方式定义的 EP 适配器的事件绑定发布首个系统事件之后，将在 CICS 消息日志中收到 DFHEC1024 错误消息。