ibm服务器重装系统_使用IBM Integration Bus重试失败的后端系统操作

ibm服务器重装系统

在许多业务集成项目中，业务规则要求在发生故障的情况下重试后端系统操作。 这样的后端操作始终是创建或更新客户帐户或业务项目的交易操作。 当后端操作的回滚非常困难甚至几乎不可能时，您通常需要实现重试机制。 重试机制避免了人工处理失败交易的巨额成本，否则在每个工作日结束时可能需要这样做。

例如，考虑一个通信公司，其客户通过支付服务公司支付月费。 如果支付服务公司向通信公司系统发送请求，则通常很难回滚甚至进行同步呼叫，因为后端系统的可用性和性能会下降，尤其是在高峰时段。 因此，如果请求失败，则中间件必须在报告失败之前重试指定次数，然后在工作日结束之前将其发送给员工进行手动处理。

异步互动

两个组件之间的异步交互意味着发送组件不等待来自接收组件的对其请求的响应。 而是，发送组件发送请求，并立即继续其他活动。 当接收组件返回其响应时，将通知发送组件并在需要时处理响应。 通常，当应用程序对时间要求不严格时，异步交互是首选，因为交互系统不会花费任何时间等待响应，从而提高了性能。

实现异步交互的最佳方法是通过排队消息传递。 IBM®WebSphere®MQ提供了高效的企业级排队消息传递，并且其功能已集成到IBM Integration Bus中。

消息流中的事件计时

IBM Integration Bus Toolkit提供了TimeoutControl和TimeoutNotification节点来实现定时事件。 其他节点（例如MQInput节点）也具有嵌入式计时器。 可配置计时器使节点能够执行队列内容的定时浏览。

重试消息流

提议的重试消息流优化了重试流的两个重要参数-与主流交互的方法以及计时机制。 使用WebSphere MQ消息传递技术，交互方法是异步的。 时序使用具有嵌入式计时器的现有节点之一，避免了添加一个或多个新时序节点的开销。 图1显示了典型集成流中重试流的位置。 如果无法调用后端操作CreateUserPaymentWS ，则通过其输入队列RETRY_QUEUE （以红色概述）访问重试流：

图1.重试消息流的用例

这是重试机制的说明：

1. 如果发生后端呼叫失败，则中间件集成流属于需要呼叫重试的服务组，它将失败的请求消息放入重试流的输入队列中。
2. 每n分钟浏览一次输入队列中的消息，其中n是预定义值。 此值影响任何请求消息的重试时间的不确定性。 换句话说，该期间将几乎在计划的期间之内，即正负n。 将n设置为较高的值会导致较高的不确定性。 将其设置为较低的值会增加开销，并且可能会阻止重试队列在指定时间段内处理所有消息。
3. 重试输入队列中的消息进入队列m分钟后将重试，其中m是预定义的值。 您可以定义此时间段，以使后端系统有时间解决导致故障的问题。 为了确定是否重试，重试流程将检查浏览的消息创建时间，并将其与当前时间进行比较。
4. 如果特定消息的重试次数超过了预定义的限制，则流程停止重试该消息。

图2显示了具有MQ输入的后端系统的重试消息流。 常规流路径由MQInput，Filter，MQGet，Compute和MQOutput节点组成：

图2.重试消息流

MQInput节点侦听重试队列，该队列保存来自中间件消息流的重试请求消息。 使用其内部计时器配置MQInput节点，每隔n分钟浏览一次队列中的消息：在Node属性下，选择Advanced => Only only ，并设置Reset Browse timeout的值，如图3所示：

图3. MQInput节点的高级属性

“筛选器”节点通过将当前时间与消息创建时间进行比较，然后确定是处理消息还是将其保留在队列中来支持计时活动。 如果比较表明重试时间段已经过去，则该流程将消息从输入队列中删除，并通过将其发送到后端系统来执行重试。 否则，该流程将浏览输入队列中的下一条消息。 清单1显示了Filter节点的ESQL代码。 消息创建时间是在接收到重试输入队列中时设置的。

清单1. Filter节点的ESQL代码

DECLARE waitTime INTEGER 1;
DECLARE creationHour INTEGER EXTRACT (HOUR FROM CAST (Root.Properties.CreationTime AS TIMESTAMP));
DECLARE currentHour INTEGER EXTRACT (HOUR FROM CURRENT_TIME);
DECLARE creationDay INTEGER EXTRACT (DAY FROM CAST (Root.Properties.CreationTime AS TIMESTAMP));
DECLARE currentDay INTEGER EXTRACT (DAY FROM CURRENT_DATE);
		
IF currentHour >= creationHour + waitTime OR currentDay > creationDay THEN
	RETURN TRUE;
ELSE
	RETURN FALSE;
END IF;

MQGet节点的作用是通过使用消息ID来获取重试队列中的已浏览消息，以使用该消息。 配置MQGet节点，使其自动通过其ID获取消息：在Node属性下，选择Request => Get by message ID ：

图4.配置MQGet节点

计算节点RouteToBackend检查消息失败的次数是否等于或超过指定的限制（例如5）。 如果是这样，则该流程将其路由到“失败”队列（在我们的示例中为DLQ）。 否则，该流会将其发送到后端系统队列以重试该操作。 清单2中显示了Compute节点的ESQL代码。消息的目标队列由OutputLocalEnvironment的代码动态设置：

清单2.计算节点的ESQL代码

DECLARE discardTime INTEGER 5;
DECLARE retryCounter INTEGER COALESCE(InputRoot.MQRFH2.usr.RetryCounter, 0);

IF retryCounter > discardTime THEN
	SET OutputLocalEnvironment.Destination.MQ.DestinationData[1].queueName = 'FAILURE_QUEUE';
ELSE
	SET OutputLocalEnvironment.Destination.MQ.DestinationData[1].queueName = 'BackendRequestQueue';
	SET OutputRoot.MQRFH2.usr.RetryCounter = retryCounter + 1;
END IF;

流中的最后一个节点是MQOutput节点，其名称由前面的Compute节点设置。 要支持此动态队列名称定义，请在Node属性下，选择Advanced => Destination mode => Destination list ，如图5所示：

图5. MQOutput节点的高级属性

结论

本文向您展示了如何从业务和技术角度使用IBM Integration Bus重试后端系统操作。 它描述了重试很重要的情况，然后提供了一个重试组件的示例，该示例已证明在生产环境中具有有效的性能。 本文还描述了异步组件交互方法及其使用WebSphere MQ技术的实现。 最后，本文描述了基于IBM Integration Bus MQInput节点中嵌入的计时器的重试计时机制。

---

翻译自: https://www.ibm.com/developerworks/websphere/library/techarticles/1401_soultan/1401_soultan.html

ibm服务器重装系统