跳到主要内容
版本：7.0.2

出站网关

DeepSeek V3 中英对照 Outbound Gateway

以下列表展示了 AMQP 出站网关的可能属性：

@Bean
public IntegrationFlow amqpOutbound(AmqpTemplate amqpTemplate) {
    return f -> f.handle(Amqp.outboundGateway(amqpTemplate)
                    .routingKey("foo")) // default exchange - route to queue 'foo'
            .get();
}

@MessagingGateway(defaultRequestChannel = "amqpOutbound.input")
public interface MyGateway {

    String sendToRabbit(String data);

}

  • 此适配器的唯一 ID。可选。

  • 消息发送到的消息通道，以便进行转换并发布到 AMQP 交换机。必需。

  • 对已配置的 AMQP 模板的 Bean 引用。可选（默认为 amqpTemplate）。

  • 消息应发送到的 AMQP 交换机的名称。如果未提供，消息将发送到默认的无名交换机。与 exchange-name-expression 互斥。可选。

  • 一个 SpEL 表达式，用于评估确定消息应发送到的 AMQP 交换机的名称，以消息作为根对象。如果未提供，消息将发送到默认的无名交换机。与 exchange-name 互斥。可选。

  • 当注册了多个消费者时，此消费者的顺序，从而实现负载均衡和故障转移。可选（默认为 Ordered.LOWEST_PRECEDENCE [=Integer.MAX_VALUE]）。

  • 从 AMQP 队列接收并转换后，回复消息应发送到的消息通道。可选。

  • 网关将回复消息发送到 reply-channel 时的等待时间。这仅在 reply-channel 可能阻塞时适用——例如，具有容量限制且当前已满的 QueueChannel。默认为无限等待。

  • 当为 true 时，如果在 AmqpTemplate 的 replyTimeout 属性规定的时间内未收到回复消息，网关将抛出异常。默认为 true。

  • 发送消息时使用的 routing-key。默认情况下，这是一个空的 String。与 routing-key-expression 互斥。可选。

  • 一个 SpEL 表达式，用于评估确定发送消息时使用的 routing-key，以消息作为根对象（例如，payload.key）。默认情况下，这是一个空的 String。与 routing-key 互斥。可选。

  • 消息的默认传递模式：PERSISTENT 或 NON_PERSISTENT。如果 header-mapper 设置了传递模式，则此设置将被覆盖。如果存在 Spring Integration 消息头 amqp_deliveryMode，DefaultHeaderMapper 会设置其值。如果未提供此属性且头部映射器也未设置，则默认值取决于 RabbitTemplate 使用的底层 Spring AMQP MessagePropertiesConverter。如果该转换器完全未自定义，则默认为 PERSISTENT。可选。

  • 自版本 4.2 起可用。定义关联数据的表达式。提供此表达式时，将配置底层 AMQP 模板以接收发布者确认。需要专用的 RabbitTemplate 和 CachingConnectionFactory，且其 publisherConfirms 属性设置为 true。当收到发布者 confirm 并且提供了关联数据时，根据确认类型，该数据将被写入 confirm-ack-channel 或 confirm-nack-channel。confirm 的有效负载是由此表达式定义的关联数据。消息具有一个头部 amqp_publishConfirm，其值设置为 true（ack）或 false（nack）。对于 nack 确认，Spring Integration 提供了一个额外的头部 amqp_publishConfirmNackCause。示例：headers['myCorrelationData'] 和 payload。如果表达式解析为 Message<?> 实例（例如 #this），则在 ack/nack 通道上发出的消息将基于该消息，并添加了额外的头部。以前，无论类型如何，都会创建一个以关联数据作为其有效负载的新消息。另请参阅 发布者确认和返回的替代机制。可选。

  • 发送肯定（ack）发布者确认的通道。有效负载是由 confirm-correlation-expression 定义的关联数据。如果表达式是 #root 或 #this，则消息是从原始消息构建的，并且 amqp_publishConfirm 头部设置为 true。另请参阅 发布者确认和返回的替代机制。可选（默认为 nullChannel）。

  • 发送否定（nack）发布者确认的通道。有效负载是由 confirm-correlation-expression 定义的关联数据（如果未配置 ErrorMessageStrategy）。如果表达式是 #root 或 #this，则消息是从原始消息构建的，并且 amqp_publishConfirm 头部设置为 false。当存在 ErrorMessageStrategy 时，消息是一个 ErrorMessage，其有效负载为 NackedAmqpMessageException。另请参阅 发布者确认和返回的替代机制。可选（默认为 nullChannel）。

  • 设置此值后，如果在此毫秒数内未收到发布者确认，网关将合成一个否定确认（nack）。每经过此值的 50% 会检查一次待处理的确认，因此实际发送 nack 的时间将在此值的 1 倍到 1.5 倍之间。默认无（不会生成 nack）。

  • 发送返回消息的通道。提供此通道时，将配置底层 AMQP 模板以将无法投递的消息返回给适配器。当未配置 ErrorMessageStrategy 时，消息是根据从 AMQP 接收的数据构建的，并具有以下附加头部：amqp_returnReplyCode、amqp_returnReplyText、amqp_returnExchange 和 amqp_returnRoutingKey。当存在 ErrorMessageStrategy 时，消息是一个 ErrorMessage，其有效负载为 ReturnedAmqpMessageException。另请参阅 发布者确认和返回的替代机制。可选。

  • 对 ErrorMessageStrategy 实现的引用，用于在发送返回或否定确认的消息时构建 ErrorMessage 实例。

  • 当设置为 false 时，端点会在应用程序上下文初始化期间尝试连接到代理。这允许通过记录错误消息（如果代理宕机）来“快速失败”检测错误配置。当为 true（默认值）时，连接在发送第一条消息时建立（如果连接尚未因其他组件建立而存在）。

important

return-channel

使用 return-channel 需要将 RabbitTemplate 的 mandatory 属性设置为 true，并将 CachingConnectionFactory 的 publisherReturns 属性设置为 true。当多个出站端点使用返回机制时，每个端点都需要一个单独的 RabbitTemplate。

important

底层的 AmqpTemplate 默认的 replyTimeout 为五秒。如果需要更长的超时时间，必须在 template 上进行配置。

请注意，出站适配器与出站网关配置之间的唯一区别在于 expectReply 属性的设置。