通常,会对中心接收的 EDI 交换进行解包,然后处理各个单独的事务。 通常,标准 EDI 事务(如 X12 850 或 EDIFACT ORDERS,这表示采购订单)被转换成后端应用程序可以解析的格式。 另外,还通常会向参与者发送确认,以表明接收到交换。 因此,EDI 交换的交换需要多个操作(如,EDI 解包、EDI 转换和 EDI 验证)。 例如,如果交换包含两个事务并且不需要确认,则 WebSphere Partner Gateway 会执行下列操作:
WebSphere Partner Gateway 在交换、组和事务级别从包络头和尾段抽取有关交换的信息。 这些信息包含:
类似地,当中心发送源自社区管理者后端应用程序的文档时,文档会被转换成标准 EDI 事务。 产生的 EDI 事务封包后发送给参与者。与接收 EDI 交换的情况一样,需要多个操作来创建、封包和发送 EDI 交换。
个别事务、组和交换是用控制编号标识的。WebSphere Partner Gateway 在发生交换时设置这些控制编号。 然而,您可以定制控制编号,如控制编号中所述。
下图从整体上阐述了如何从参与者发送一个封装为 AS 的 EDI 交换,最终目标是将两个已转换的 XML 文档传递到社区管理者后端系统上的两个不同网关。 在本示例中,850 事务被转换成后端应用程序可以处理的采购订单。890 事务被转换成后端应用程序可以处理的仓库发货订单。
该交换需要三个连接,而不是需要一个从参与者到社区管理者的连接:
对于事务,源封装是“不适用”,因为该事务进入了由系统解包的初始交换。因此,事务的源端应该适用参与者连接中指定的封装:不适用。
对于被转换成 XML 且将通过 JMS 流向后端应用程序的事务,该事务的参与者连接上目标网关应被指定为社区管理者的 JMS 网关。对于被转换成 XML 且将通过 HTTP 流向后端应用程序的事务,该事务的参与者连接上目标网关应被指定为 HTTP 网关。
您可以使用“文档查看器”来查看交换和单独的事务,对于“文档查看器”来说,这些事务是交换的子代。使用“文档查看器”,可以显示与源和目标交换关联的子代,而且可以显示与它们关联的事件。管理员指南的“查看事件和文档”部分对“文档查看器”进行了描述。
如果发送方请求确认,则需要其他连接: