管理 InterChange Server Express 系统中的故障包括使用故障诊断资源来解决问题。系统组件(如连接器或协作)或第三方组件(如集成的应用程序)有可能出现导致事件失败的关键错误。
当错误导致事件失败时,InterChange Server Express 系统具有允许您解决问题的内置能力。可以将系统设置为在发生故障时暂停 InterChange Server Express 内的协作。本节包括以下主题:
InterChange Server Express 的恢复策略
要避免将重复的事件发送至目标应用程序,您可能要防止恢复操作自动重新提交在发生故障时处于传输状态的所有服务调用。在服务器发生故障前,你可以对非事务性协作进行配置,以便当发生故障和恢复时,能使任何服务调用保持在“传输”状态。当 InterChange Server Express 恢复时,服务调用事件仍处于“传输”状态,并且您可以使用 流管理器或失败事件管理器管理器来检查单个失败的事件并控制何时(或是否)重新提交它们。
要将协作配置为保持失败的服务调用在传输状态,转至系统管理器并选择“协作一般属性”窗口的使服务调用保持在传输状态复选框。
如果 InterChange Server Express 在处理事件时失败,则必须恢复当前在“正在进行的”(WIP)队列中的所有事件,或在服务器重新引导时处理这些事件。由于内存需求,恢复 WIP 事件可能会减慢甚至停止服务器重新引导。InterChange Server Express 产品提供了两个功能:延迟恢复和异步恢复,它们用于减少服务器重新引导所需的时间及在恢复所有事件之前使服务器可用于其它工作。
流量控制和将业务对象密钥存储为 WIP 数据的一部分有助于提高延迟恢复和异步恢复的效率。两个功能都减少了 InterChange Server Express 恢复期间所需要的内存量,因此,可以显著减少 InterChange Server Express 在恢复期间重新引导所需要的时间量。
将业务对象密钥存储为 WIP 数据的一部分意味着在恢复期间,不必将业务对象反序列化就能找回密钥,从而避免 MQ 或数据库往返行程。流量控制是一项服务,它允许您配置系统范围或组件级别的队列深度参数,以控制 InterChange Server Express 中的内存需求。有关配置流量控制的更多信息,请参阅配置系统范围流量控制的步骤。
在延迟恢复中,将对协作 WIP 事件的恢复延迟至服务器重新引导之后,因而节省这些事件的内存用量。
在重新引导服务器之后,可以手工重新提交事件。注意以下建议:
通过设置协作对象的 RECOVERY_MODE 属性建立延迟恢复。
RECOVERY_MODE 属性具有两个设置,当发生服务器故障和重新引导时,它们执行以下操作:
在服务器故障发生之前处于“工作”状态的事件将更改为“延迟”状态。在您手工重新提交此协作的事件之前,将不会恢复它们。
将恢复在服务器故障之前处于“工作”状态的事件。“延迟”状态下的事件仍保持为延迟,直到您重新提交它们为止。
缺省设置是“始终”。
执行下列步骤来设置协作“恢复”模式值:
协作将恢复其状态是“工作”且在服务器引导时它拥有的所有 WIP 事件。
协作将 WIP 事件更改为“延迟恢复”状态。以后,您必须使用流管理器或失败事件管理器来处理这些事件。有关更多信息,请参阅处理失败事件。
InterChange Server Express 在完成引导过程之前不会等待协作和连接器恢复;在 InterChange Server Express 已引导之后,允许协作和连接器以异步方式进行恢复。这使得当连接器和协作在恢复时使用故障诊断工具(如系统监视器、失败事件管理器和流管理器)成为可能。
InterChange Server Express 系统中的关键错误可以导致运行时环境中的问题。以下其中一种情况可以生成在 InterChange Server Express 系统中所定义的关键错误:
缺省情况下,在流失败之后,协作继续处理后续启动程序。然而,可以将协作的行为配置为在发生可能导致流失败的关键错误时自动暂停。由于该协作在流失败之后不再处理任何启动程序,所以用这种方式配置协作 可以消除下一个流由于相同原因而失败的可能性。在需要维护启动程序处理顺序的情况下,这很关键。如果协作暂停,则将维护启动程序到达服务器的顺序。此时,可以改正关键错误,解析失败的流然后重新启动协作。如果协作不依赖于与失败的流相关联的启动程序,则您可以继续启动协作并稍后解析失败的流。有关提交失败事件的更多信息,请参阅流故障。
要将协作对象配置为在发生关键错误之后暂停,在“属性”对话框的“协作一般属性”选项卡中选择当发生关键错误时暂停复选框。
如果设置了此值,当发生关键错误时协作将暂停,且保持暂停状态,直到发生以下其中一种情况为止:
如果未将协作配置为在发生关键错误时暂停,则可能会发生以下情况:
两个启动程序 E1 和 E2 正在等待由协作进行处理。E1 创建一个新客户,而 E2 更新 E1。因为 E2 更新 E1,所以 E1 必须在 E2 之前处理。如果当协作处理 E1 时发生关键错误而导致 E1 失败,则将 E1 移至重新提交队列。如果未选择当发生关键错误时暂停复选框,则协作会尝试处理 E2。由于 E2 依赖于 E1 的成功处理,所以 E2 会失败。
如果协作属性 CONVERT_UPDATE 设置为 true,则更新 E1 的 E2 变为一个创建操作并使用更新后的数据创建新客户。E1 中的数据现在已变旧,由于它会覆盖由 E2 传递的数据,所以不应手工提交它。
正在运行的协作假定连接器具有与其应用程序的活连接。如果连接器的应用程序变为不可用,则连接器无法轮询该应用程序以获取事件和满足协作请求。
当应用程序不可用时,轮询该应用程序以获取事件的连接器在每次轮询尝试时生成一个错误。如果连接器确定已丢失与该应用程序的连接,则连接代理程序终止,并且将一个状态返回至连接器控制器以请求连接器控制器也终止。
如果协作在连接器处于打开状态但其应用程序已失败时将请求发送至连接器,则该请求将以一个故障状态返回至协作。仅当连接器属性 ControlStoreAndForwardMode 设置为 false 时才会发生这种情况。协作失败,记录以下其中一个消息:17050、17058、17059 或 17060。如果接收到这样的消息,应检查应用程序的状态。
连接器代理程序的状态对于 InterChange Server Express 系统是至关重要的,因为它是应用程序事件的起始点。连接器控制器维护其连接器代理程序的状态并将此信息传递至系统管理器。
连接器控制器通过以 15 秒的时间间隔将响应请求发送至其连接器代理程序,来维护该连接器代理程序的状态。
如果在三次连续检查后连接器代理程序不响应,则假定其状态是未知的。未知的连接器代理程序状态可能意味着连接器代理程序已失败,或者,如果连接器代理程序安装在网络上,则意味着网络连接可能已失败。
将连接器的 ControllerStoreAndForwardMode 属性设置为 true 会使连接器控制器在传递暂挂事件之前等待连接器代理程序完成启动。将此属性设置为 false 会使连接器控制器不能执行协作请求。失败的协作请求移至重新提交队列并可以使用流管理器重新提交。有关更多信息,请参阅流故障。
当对相关联的协作选择当发生关键错误时暂停复选框时,绑定至此连接器的协作在接收到连接器代理程序的未知状态时暂停。将记录一条错误消息并发送电子邮件(如果配置了电子邮件连接器)。
当 InterChange Server Express 需要数据库连接以用于它的一个服务,但发现已在使用的连接达到最大数时,服务器会尝试释放空闲的连接。如果服务器未成功,则该连接尝试失败,并且 InterChange Server Express 记录错误 5010:无法在高速缓存中找到可用连接。已达到最大连接数 max-connections-value。
如果通过设置 MAX_CONNECTIONS 参数对 InterChange Server Express 连接数设置约束,则应监视错误 5010 消息,这是由于连接失败可能产生不需要的结果。例如,当 InterChange Server Express 不能获取连接以用于其事件管理服务时,它会停止运行。缺省情况下,此约束设置为无限制的连接数。
连接故障指示分配的最大连接数不足,不能满足运行时工作负载。如果不能在当前数据库中分配更多与 InterChange Server Express 的连接,则考虑将其工作负载分布在多个数据库上。
有时,InterChange Server Express 系统或其相关联的应用程序可能失败。成功处理通过 InterChange Server Express 系统传送数据的流是很关键的,因此在运行时环境中维护数据一致性非常关键。系统故障(如系统错误、数据错误和关键错误)可以导致流不能处理。InterChange Server Express 系统具有允许您处理系统故障的内置能力。
系统配置错误、对象定义错误、特定于应用程序的错误或数据一致性错误可以导致 InterChange Server Express 系统处理流时失败。InterChange Server Express 组件工作不正常(如业务对象映射故障或连接器不可用)会生成导致流失败的系统错误。数据不一致性(如执行协作期间应用程序数据的隔离违例)会生成一些数据错误,它们也会导致流失败。
如果当连接器控制器或协作正在处理流时发生错误,该流失败且被移至事件重新提交队列。此时,您具有以下选项:
有关解析失败的流的指示信息,请参阅处理失败事件。
系统和数据错误可以导致事务性协作失败。当发生其中一个错误时,协作试图回滚。如果协作的校正步骤的回滚失败,则协作处于“不确定”状态。如果在运行时恢复期间出错,将把协作置于失败的事务型协作列表中,该列表由相应协作拥有。失败的事务性协作是其校正步骤不能回滚的协作。
在事务性协作失败之后,您必须解析它。可使用流管理器来处理失败的事务性协作。有关解析失败的事务性协作的指示信息,请参阅处理失败事件。
失败的事务性协作的缺省行为是暂停。通过将称为 PAUSE_ON_COMPENSATION_FAILURE 的属性添加至协作模板并将设置从 TRUE(缺省值)更改为 FALSE,可以防止失败的事务性协作暂停。
执行下列步骤来添加新属性并将设置更改为 FALSE: