[IB]Integration Broker 是如何处理传入的请求（Part 2）

让我们讨论一下集成代理如何处理传入的请求。可以先阅读（理解PeopleSoft集成代理 Part1）。

当PeopleSoft集成代理接收传入请求时，会发生一系列事件。

1. 当侦听连接器（Listening Connector）接收到请求时，连接器所做的第一件事就是将请求写入到网关日志文件。请求是完全按照接收的方式编写的。这有助于在规范化发生之前捕获消息的发送。

2. 然后，连接器尝试用收到的消息填充内部请求消息类。传入消息有2个部分——凭证和mesage body。值得注意的是，没有凭证的消息无法处理。如果网关接收到这样的消息，将会出现错误，并将错误消息返回给请求者。在此步骤中不发生解析——只是验证。

3. 接下来，消息是PeopleSoft Target Connector来操作。这个连接器有两个主要职责:它将消息序列化为一个字符串，并通过与应用服务器的一个jolt连接发送该字符串。网关和应用服务器之间的所有通信都是通过使用多用途Internet邮件扩展(MIME)消息完成的。通常，MIME消息只有两个部分——消息正文和XML格式的凭证。

4. PeopleSoft Target Connector以标准格式转换消息,这样才能被网关和应用程序服务器所理解。所有消息最终都必须解析成这种格式，然后才能将其发送到应用服务器进行处理，否则appserver将无法理解它们。这种格式有效地将应用服务器与网关支持的协议隔离开来。

5. 一旦MIME消息被构建，它就被写入到网关日志。然后将MIME响应解析回网关请求对象，然后返回到倾听连接器。

6. 最后，连接器从integration properties file中查找jolt连接属性，并尝试将MIME发送到应用服务器。如果这些属性没有正确设置，网关将无法发送请求。

   要记住的一点是，即使对appserver的MIME请求可能出现在网关日志文件中，实际的请求可能还没有到达应用服务器，因为日志条目是在消息发送之前写的。如果发生通信错误，该条目将仍然存在于日志文件中。但是，如果出现这种情况，将抛出异常，也将创建一个错误日志条目。

7. 当应用服务器接收MIME请求时，将解析消息并用于构建请求对象。假定消息没有发生错误，应用程序服务器必须在实际处理请求之前预先处理消息。预处理包括:

• 根据配置的身份验证方案验证消息。如果请求失败身份验证，则返回一个错误。

• 确定是否有与节点事务表中的请求对应的事务。除了Ping消息，所有传入的消息都必须解析为该表中唯一的条目。如果不能为请求找到合适的事务，则发生错误。

• 确定要调用的消息处理程序。目前，集成代理支持三种消息类型:Ping、同步和异步。消息类型确定要调用的处理程序代码。同步消息传递到特定于sync的代码，而async消息传递给发布/订阅subsytem。

一旦消息传递给它们各自的处理程序，进一步的处理将由数据和特定于特定系统的人员决定。异步请求将被发布，订阅PeopleCode将被执行。同步消息可以调用PeopleCode，或者在集线器配置的情况下，请求可以立即路由到另一个外部系统。

8. 不管请求是如何处理的，响应消息必须由应用服务器返回到相同执行线程中的网关。网关与应用服务器之间的连接本质上是同步的，独立于交换的消息的类型。当网关向应用服务器发送请求时，它期望并必须得到响应。

在同步消息的情况下，响应的生成被请求的处理阻塞。无法生成响应，直到消息运行完成为止。在接收响应时，可能会有一个明显的延迟，这取决于PeopleCode是否正在运行，或者请求消息是否被从代理发送到外部系统以进行额外处理。

不像同步请求，在异步请求的情况下没有阻塞。当请求被写入发布队列时，将生成一个异步请求的响应。因此，对于异步请求生成的响应并不是最严格意义上的响应。这样的回答应该被认为是“pub / sub系统接收到消息”的响应。收到这样的响应并不能保证任何适用的订阅人员都成功运行了。

响应消息被应用服务器转换为MIME标准，并返回到网关。

9.一旦MIME PeopleSoft Target Connector收到响应,它是日志文件写入到网关。然后将MIME响应解析回网关请求对象，然后返回到ListeningConnector。

10. reponse对象被返回到ListeningConnector，响应被映射到一个响应给定协议的响应。从ListeningConnector的角度来看，请求消息的处理是同步进行的。一个请求被一个ListeningConnector接收，然后将其覆盖到合适的格式，对网关进行阻塞调用，以处理消息，并最终在执行的相同线程中得到响应。

---

如果感到对您有帮助没准儿你就会赞赏，iOS 专用赞赏通道：