物流数据处理方法及装置与流程

本申请涉及物流数据处理技术领域，尤其涉及一种物流数据处理方法及装置。

背景技术：

目前的物流数据处理方法中，在接收到发货请求消息后，针对该发货请求消息执行发货操作的流程如图1中所示，图1中的发货中心、订单中心、仓储中心分别为物流数据处理系统所包含的子系统，该子系统间相互配合完成发货处理流程。具体发货请求消息的处理过程包括如下步骤：

S1、接收到来自用户的携带外部订单号的发货请求。

S2、查询是否存在与所述外部订单号对应的内部订单以及对应的内部订单的状态是否为已发货。

若存在与所述外部订单对应的内部订单，且状态为已发货，则执行步骤S3，向用户返回发货信息。

若存在与所述外部订单对应的内部订单，且状态为未发货，则执行步骤S5。

若不存在与所述外部订单对应的内部订单，则执行步骤S4，触发建立与所述外部订单号对应的内部订单，即触发订单中心建立与所述外部订单号对应的内部订单，之后执行步骤S5。步骤S3与S4同时只能执行一个步骤，因此步骤S3采用虚线表示。

S5、查询是否存在与所述内部订单对应的仓储订单。

若存在与所述内部订单对应的仓储订单，则执行步骤S6，向用户返回发货信息。

若不存在与所述内部订单对应的仓储订单，则执行步骤S7，触发生 成与所述内部订单对应的仓储订单。步骤S6与S7同时只能执行一个步骤，因此步骤S6采用虚线表示。

S8、针对所述仓储订单执行发货操作。

S9、发货完成后通知订单中心将内部订单状态更新为已发货。

S10、向用户返回发货信息。

上述流程中至少存在如下问题：

在当前的处理发货请求过程中，当接收到同一用户针对同一外部订单再次发送同样的发货请求时，在当前的发货请求未完成情况下，将同步处理后续接收到的针对同一外部订单的发货请求。例如，当前发货操作流程未执行步骤S9的将内部订单状态更新为已发货；或者，步骤S9执行失败，导致未将内部订单状态更新为已发货等情况，则针对后续接收到的同一外部订单的发货请求，同样会执行步骤S5～S10。

因此，目前的物流数据处理系统在处理发货操作流程时存在重复发货的问题。

技术实现要素：

本申请解决的技术问题之一是提供一种物流数据处理方法及装置，实现了有效防止重复发货。

根据本申请一方面的一个实施例，提供了一种物流数据处理方法，用于对用户发出的针对外部订单号的发货请求消息进行用于发货的事务处理，所述物流数据处理方法包括：

接收携带外部订单号及用户标识的发货请求消息；

判断在本地是否已建立有与所述外部订单号及用户标识对应的事务处理标记；

若已建立有对应的事务处理标记，则丢弃接收的所述发货请求消息；

若未建立有对应的事务处理标记，则在本地建立与所述外部订单号及用户标识对应的事务处理标记；

仅对未丢弃的发货请求消息执行用于发货的事务处理，从而对同一用户发出的针对同一外部订单号的并发的发货请求消息仅进行一次用于发货的 事务处理。

根据本申请另一方面的一个实施例，提供了一种物流数据处理装置，用于对用户发出的针对外部订单号的发货请求消息进行用于发货的事务处理，所述物流数据处理装置包括：

接收单元，用于接收携带外部订单号及用户标识的发货请求消息；

判断单元，用于判断在本地是否已建立有与所述外部订单号及用户标识对应的事务处理标记；

第一处理单元，用于在所述判断单元判断已建立有对应的事务处理标记情况下丢弃接收的所述发货请求消息；

建立单元，用于在所述判断单元判断未建立有对应的事务处理标记情况下在本地建立与所述外部订单号及用户标识对应的事务处理标记；

第二处理单元，用于仅对未丢弃的发货请求消息执行用于发货的事务处理，从而对同一用户发出的针对同一外部订单号的并发的发货请求消息仅进行一次用于发货的事务处理。

本申请实施例通过为发货请求消息建立对应的事务处理标记，在事务处理标记存在情况下，对于并发的同一发货请求消息不做发货处理，从而可有效避免针对同一发货请求消息的重复发货问题。

本领域普通技术人员将了解，虽然下面的详细说明将参考图示实施例、附图进行，但本申请并不仅限于这些实施例。而是，本申请的范围是广泛的，且意在仅通过后附的权利要求限定本申请的范围。

附图说明

通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本申请的其它特征、目的和优点将会变得更明显：

图1是现有技术的物流数据处理方法的流程图。

图2是根据本申请一个实施例的物流数据处理方法的流程图。

图3是根据本申请一个实施例的物流数据处理方法中对发货请求消息执行发货操作的流程图。

图4是根据本申请一个实施例的物流数据处理装置的结构示意图。

本领域普通技术人员将了解，虽然下面的详细说明将参考图示实施例、附图进行，但本申请并不仅限于这些实施例。而是，本申请的范围是广泛的，且意在仅通过后附的权利要求限定本申请的范围。

具体实施方式

在更加详细地讨论示例性实施例之前，应当提到的是，一些示例性实施例被描述成作为流程图描绘的处理或方法。虽然流程图将各项操作描述成顺序的处理，但是其中的许多操作可以被并行地、并发地或者同时实施。此外，各项操作的顺序可以被重新安排。当其操作完成时所述处理可以被终止，但是还可以具有未包括在附图中的附加步骤。所述处理可以对应于方法、函数、规程、子例程、子程序等等。

所述计算机设备包括用户设备与网络设备。其中，所述用户设备包括但不限于电脑、智能手机、PDA等；所述网络设备包括但不限于单个网络服务器、多个网络服务器组成的服务器组或基于云计算(Cloud Computing)的由大量计算机或网络服务器构成的云，其中，云计算是分布式计算的一种，由一群松散耦合的计算机集组成的一个超级虚拟计算机。其中，所述计算机设备可单独运行来实现本申请，也可接入网络并通过与网络中的其他计算机设备的交互操作来实现本申请。其中，所述计算机设备所处的网络包括但不限于互联网、广域网、城域网、局域网、VPN网络等。

需要说明的是，所述用户设备、网络设备和网络等仅为举例，其他现有的或今后可能出现的计算机设备或网络如可适用于本申请，也应包含在本申请保护范围以内，并以引用方式包含于此。

后面所讨论的方法(其中一些通过流程图示出)可以通过硬件、软件、固件、中间件、微代码、硬件描述语言或者其任意组合来实施。当用软件、固件、中间件或微代码来实施时，用以实施必要任务的程序代码或代码段可以被存储在机器或计算机可读介质(比如存储介质)中。(一个或多个)处理器可以实施必要的任务。

这里所公开的具体结构和功能细节仅仅是代表性的，并且是用于描 述本申请的示例性实施例的目的。但是本申请可以通过许多替换形式来具体实现，并且不应当被解释成仅仅受限于这里所阐述的实施例。

应当理解的是，虽然在这里可能使用了术语“第一”、“第二”等等来描述各个单元，但是这些单元不应当受这些术语限制。使用这些术语仅仅是为了将一个单元与另一个单元进行区分。举例来说，在不背离示例性实施例的范围的情况下，第一单元可以被称为第二单元，并且类似地第二单元可以被称为第一单元。这里所使用的术语“和/或”包括其中一个或更多所列出的相关联项目的任意和所有组合。

应当理解的是，当一个单元被称为“连接”或“耦合”到另一单元时，其可以直接连接或耦合到所述另一单元，或者可以存在中间单元。与此相对，当一个单元被称为“直接连接”或“直接耦合”到另一单元时，则不存在中间单元。应当按照类似的方式来解释被用于描述单元之间的关系的其他词语(例如“处于…之间”相比于“直接处于…之间”，“与…邻近”相比于“与…直接邻近”等等)。

这里所使用的术语仅仅是为了描述具体实施例而不意图限制示例性实施例。除非上下文明确地另有所指，否则这里所使用的单数形式“一个”、“一项”还意图包括复数。还应当理解的是，这里所使用的术语“包括”和/或“包含”规定所陈述的特征、整数、步骤、操作、单元和/或组件的存在，而不排除存在或添加一个或更多其他特征、整数、步骤、操作、单元、组件和/或其组合。

还应当提到的是，在一些替换实现方式中，所提到的功能/动作可以按照不同于附图中标示的顺序发生。举例来说，取决于所涉及的功能/动作，相继示出的两幅图实际上可以基本上同时执行或者有时可以按照相反的顺序来执行。

下面结合附图对本申请的技术方案作进一步详细描述。

图2是根据本申请一个实施例的物流数据处理方法的流程图，本实施例的物流数据处理方法主要涉及物流数据处理中的发货数据处理过程，也就是本实施例的物流数据处理方法主要用于对用户发出的针对外部订单号的发货请求消息进行用于发货的事务处理。该方法的执行主体 可以为物流数据处理系统中发货中心子系统的服务器，也就是该方法主要由发货中心子系统完成。该方法主要包括如下步骤：

S21、接收携带外部订单号及用户标识的发货请求消息。

S22、判断在本地是否已建立有与所述外部订单号及用户标识对应的事务处理标记。

若已建立有对应的事务处理标记，则进入步骤S23；若未建立有对应的事务处理标记，则进入步骤S24。

S23、丢弃接收的所述发货请求消息。

S24、在本地建立与所述外部订单号及用户标识对应的事务处理标记；

S25、仅对未丢弃的发货请求消息执行用于发货的事务处理，从而对同一用户发出的针对同一外部订单号的并发的发货请求消息仅进行一次用于发货的事务处理。

下面对上述各步骤做进一步详细介绍。

由于本申请实施例中的物流数据处理系统支持不同平台产生的订单，本申请实施例将来自不同平台的待发货的订单统称为外部订单。步骤S21中所述的外部订单号即为由不同平台产生的外部订单的订单号。

在发货请求消息中携带的用户标识为发送所述发货请求消息的用户的用户标识。该发送发货请求消息的用户为在该物流数据处理系统中注册的用户。

假设当前接收到一个发货请求消息，在该发货请求消息中携带的外部订单号为：123456，用户标识为：userA。

步骤S22中所述的事务处理标记是为发货请求消息建立的，具体的，可以是为针对发货请求消息中携带的外部订单号及用户标识建立的。每一外部订单号及用户标识的组合对应唯一的事务处理标记。该事务处理标记的存在用于表示与该事务处理标记对应的发货请求消息(发货请求消息中携带的外部订单号及用户标识)正在被处理。

判断在本地是否已建立有与所述外部订单号及用户标识对应的事务处理标记的方法可以为：以外部订单号+用户标识为关键词在保存事务处理标记的存储设备中查找。该保存事务处理标记的存储设备可以为存储系统或数 据库等具备存储功能的设备，在该存储设备中保存所有外部订单号与用户标识的组合与事务处理标记的对应关系。例如，针对步骤S21中接收的携带的外部订单号为：123456，用户标识为：userA的发货请求消息，其查找过程中以123456+userA作为key在保存事务处理标记的设备中查找。

其中，若查找时发现所述保存事务处理标记的设备中保存有与所述外部订单号及用户标识对应的事务处理标记。例如，以123456+userA作为key，在保存事务处理标记的设备中查找时发现存在与该123456+userA组合对应的事务处理标记LOCK1，则可确定本地已建立有与所述外部订单号及用户标识对应的事务处理标记。也就是所接收的发货请求消息为并发的发货请求消息，在接收当前的发货请求消息前，该发货请求消息已被接收并处理。

另外，本申请实施例在判断是否已建立有与外部订单号及用户标识对应的事务处理标记的同时，还可进一步了解携带同一外部订单号及用户标识的发货请求消息的并发量。此种情况下，可通过获取事务处理标记的值来实现，也就是说，在所述存储设备中除保存事务处理标记与外部订单号及用户标识的对应关系外，还保存事务处理标记的值。具体方法可以为：为建立的所述事务处理标记赋值；通过更新所述事务处理标记的值来统计接收的携带同一外部订单号及用户标识的发货请求消息的数量。其中，在建立与外部订单号及用户标识对应的事务处理标记时，可设置该事务处理标记的初始值为1，后续每次接收到携带与该事务处理标记对应的外部订单号及用户标识的发货请求消息时，将事务处理标记的当前值加1。也就是每次以外部订单号及用户标识为关键词在该存储设备中查找对应的事务处理标记时，在查找到对应的事务处理标记情况下，将该事务处理标记的值加1，加1后得到的事务处理标记的值即为携带同一外部订单号及用户标识的发货请求消息的并发量值。例如，上述查找到的事务处理标记LOCK1的当前值为1，将该当前值加1后得到该LOCK1的值为2，则可知同样的发货请求消息已经发送了2次。

若已建立有与所述外部订单号及用户标识对应的事务处理标记，则说明该用户的与所述外部订单号对应的发货请求消息正在被处理，为避 免出现重复发货现象，可执行步骤S23，丢弃当前接收的发货请求消息，也就是忽略当前接收的发货请求消息，不再针对该发货请求执行发货操作，因此在一个发货请求未处理完成情况下，接收到同一用户发送的同样的发货请求消息将不会对其进行处理，因此不会出现重复发货的现象。

步骤S24为在判断未建立有与所述发货请求消息中携带的外部订单号及用户标识对应的事务处理标记的情况下，为所述发货请求消息建立事务处理标记。具体为，在本地建立与所述外部订单号及用户标识对应的事务处理标记。也就是，本申请实施例在首次接收到一个携带外部订单号及用户标识的发货请求消息时，会针对该发货请求消息中的外部订单号及用户标识建立事务处理标记，以表示该发货请求消息正在处理。将建立的事务处理标记与外部订单号及用户标识的对应关系保存于所述存储设备中。

同时，本申请实施例还可设置所述事务处理标记的有效时长。所述的有效时长，即该事务处理标记被保留的最长时间。在达到有效时长时可以将该事务处理标记释放，即可删除该事务处理标记。设置该事务处理标记的有效时长的目的在于可以防止出现发货请求消息被锁定现象，也就是防止在发货请求消息无法成功发货情况下，后续无法针对同样的发货请求消息进行处理的情况。为实现该目的，本申请实施例从建立所述事务处理标记，并为该事务处理标记设置完有效时长情况下开始计时，判断当前时间距离建立所述事务处理标记的时间的时长是否达到所述有效时长，若达到所述有效时间则删除所述事务处理标记。该有效时长为经过多次实验确定的时长，该有效时长可保证一个发货请求消息从接收到发货成功具有足够的时间，也就是能够保证正常的对发货请求消息的发货处理过程完成。例如，经实验发现，一个发货请求消息从接收到发货完成平均需要时长为1s，本申请实施例为事务处理标记设置的有效时长可以为5s，或6s等等，足够完成一个正常的发货处理流程。

从上面的描述可以看出，本申请实施例对于首次接收的发货请求消息建立对应的事务处理标记，在事务处理标记存在情况下对于后续接收的同样的(携带的外部订单号及用户标识相同)发货请求消息不做任何处理，可有效保证重复发货现象。

步骤S25为仅对未丢弃的发货请求消息执行用于发货的事务处理。在每执行该发货操作的每一步操作前，都先判断对应的操作是否已经执行完成，以进一步避免重复操作的现象。

该步骤S25的详细执行流程参见图3中所示，图3中的发货中心、订单中心、仓储中心以及异步调度中心均为物流数据处理系统中的子系统，该方法主要由发货中心子系统的服务器来完成，具体可包括如下步骤：

S251、判断是否存在与所述外部订单号对应的内部订单以及对应的内部订单的状态是否为已发货，从而依据不同的判断结果执行对应的后续的发货操作。

由于外部订单来自不同平台，其格式各不相同，为方便数据处理本申请实施例会针对外部订单生成对应的内部订单，一个外部订单号对应一个内部订单号。

判断是否存在与外部订单号对应的内部订单，即向订单中心查询是否存在与外部订单号对应的内部订单号。例如，若外部订单号为12345，则以12345为key向订单中心查询是否存在与该12345对应的内部订单号。

若存在与外部订单号对应的内部订单，且该内部订单状态为已发货，则返回发货信息，并结束操作，如图3中虚线所示的步骤。由于在步骤S23中已经通过事务处理标记对并发的发货请求消息进行了拦截，因此该场景出现的几率较低。此场景为针对前一发货请求消息对应的事务处理标记删除，但发货流程未执行完成，后续接收到同一发货请求消息情况下，在接收后续并发的发货请求消息时，前一发货请求消息已经处理完的场景。则步骤S21中接收的发货请求消息即为后续接收的并发的发货请求消息。

若存在与外部订单号对应的内部订单，且该内部订单状态为未发货，则如图3中所示进入步骤S252。

S252、判断该内部订单是否存在对应的仓储订单。

由于不同订单中的物品有可能对应不同的仓储中心，因此，本申请实施例需要进一步根据内部订单生成仓储订单。生成仓储订单的过程为：由发货中心确定生成仓储订单的方案，包括确定生成仓储订单的参数，并将该生成仓储订单的方案通知给仓储中心，后续接收仓储中心依据该生成仓储订单的 方案生成的仓储订单。

若存在与该内部订单对应的仓储订单，则返回发货信息如图3中虚线所示的步骤。返回的发货信息包括仓储订单的订单号及每个仓储订单包含的物品信息。此步骤为针对内部订单状态更新失败的场景，也就是前一发货请求消息处理过程中，仓储订单已经生成并已发货，但对应的内部订单状态未更新为已发货状态的场景。

若不存在与该内部订单对应的仓储订单，则如图3中所示进入步骤S253。

S253、判断所述内部订单是否已经拆单。

由于一个外部订单中可能包含两个或多个物品，而该两个或多个物品有可能归属不同的仓储中心，因此，有必要将该外部订单对应的内部订单拆分成多个子内部订单，从而根据拆分后的子内部订单生成对应的仓储订单以方便发货。

判断所述内部订单是否已经拆单，即判断该内部订单是否存在对应的多个子内部订单，若存在一个内部订单号对应多个子内部订单号，则说明该内部订单已经拆单。所述内部订单未拆单时对应两种情况，一种为该内部订单无需拆单，另一种该内部订单需拆单，但未执行拆单操作。

若所述内部订单已经拆单，则执行步骤S254，回滚到未拆单状态，得到未拆单的内部订单，之后执行步骤S255。此步骤为针对拆单成功但调用仓储中心失败的情况，也就是拆单成功后没有成功发货的情况。所述回滚到未拆单状态即，删除与所述外部订单号对应的多个子内部订单，保留未拆单前的与所述外部订单对应内部订单。

若所述内部订单未拆单且无需拆单，则直接进入步骤S256。

若所述内部订单未拆单但该内部订单需拆单，则进入步骤S255。

另外，若判断结果为不存在与所述外部订单号对应的内部订单，则对应的后续的处理操作为：触发建立与所述外部订单号对应的内部订单，图3中未示出。所述触发建立与所述外部订单号对应的内部订单，即触发物流数据处理系统的订单中心生成与所述外部订单号对应的内部订单，例如，将携带外部订单号的发货请求消息发送给订单中心，从而接收订单中心返回的针对 所述外部订单号创建的内部订单的内部订单号(返回外部订单号与内部订单号的对应关系)，之后若该内部订单需要拆单则进入步骤S255，若无需拆单，则针对建立的与所述外部订单号对应的内部订单执行发货操作，即进入步骤S256。

S255、根据设置的拆单方案将所述内部订单拆分成多个子内部订单，之后针对拆分后的多个子内部订单执行发货操作，即进入步骤S256。

所述内部订单有可能为之前未拆单的内部订单，也有可能为已拆单但回滚后保留的内部订单。针对该回滚后保留的内部订单需重新依据拆单方案进行拆单。

所述的拆单方案由发货中心服务器确定，例如，可以根据订单中包含的物品对应的仓储中心的个数来拆单，本申请实施例对具体的拆单方案不做限制。由于该拆单方案有可能为动态拆单方案，也就是即使针对同一发货请求消息，在每次接收并处理过程中确定的拆单方案有可能不同，因此需要将已拆单的内部订单回滚到未拆单状态，重新依据当前确定的拆单方案进行拆单，以保证发货中心与订单中心的订单状态一致。

该拆单过程具体包括：发货中心服务器将确定的拆单方案通知给订单中心，触发订单中心依据发货中心服务器确定的拆单方案对所述内部订单进行拆单。发货中心服务器接收订单中心的拆单结果，该拆单结果包括一个内部订单拆分后对应的多个子内部订单，也就是内部订单号与多个拆分后的子内部订单号的对应关系，以及每个子内部订单对应的物品。

S256、触发生成与所述内部订单对应的仓储订单。

可以理解的是，所生成的仓储订单的数量与子内部订单的数量一致。也就是在内部订单已拆单情况下，仓储订单是依据拆单后的子内部订单来生成，即，针对拆分后的多个子内部订单生成对应的多个仓储订单。生成与内部订单对应的仓储订单的过程同上面所述，此处不再赘述。

S257、依据所述仓储订单进行发货操作。

具体的，依据仓储订单进行发货操作即为调用相应仓储中心的发货接口对已经生成的仓储订单进行发货操作。其中，本申请实施例为保证物流数据处理系统的各子系统间信息的一致性，对于一个内部订单对应的多个仓储订 单(将一个内部订单拆分成多个子内部订单的情况)，在调用发货接口时需调用仓储中心的批量发货接口将所述内部订单对应的多个仓储订单统一发货。也就是针对重新拆分后的多个子内部订单生成对应的多个仓储订单，调用仓储中心的批量发货接口将所述多个子内部订单对应的多个仓储订单统一发货。

S258、触发更新内部订单状态为已发货状态。

具体的，触发更新内部订单状态为已发货状态，即，在调用仓储中心的发货接口发货成功后，通知订单中心发货成功的内部订单号，以便订单中心将对应的发货成功的内部订单号对应的内部订单状态更新为已发货状态。其中对于调用批量发货接口将内部订单对应的多个仓储订单统一发货的场景，需该多个仓储订单全部发货成功情况下才执行该更新操作，以保证同一内部订单对应的多个子内部订单状态统一。

其中，若更新所述内部订单状态失败，则触发生成异步调用任务，重复执行更新所述内部订单状态为已发货状态，直到更新成功，如图3中虚线所示。也就是，本申请实施例对发货请求消息的整个处理过程进行监控，在系统间互相调用(包括：触发订单中心生成与外部订单对应的内部订单、触发订单中心进行拆单、触发仓储中心生成仓储订单以及触发订单中心更新内部订单状态等)失败情况下，可通知异步调度中心，触发异步调度中心生成异步调度任务，从而回调执行失败的接口，重新执行该步骤直到执行成功为止。例如，在监控到内部订单更新为已发货状态失败情况下，生成异步调度任务，调用更新内部订单状态的接口重新执行更新内部订单状态为已发货的操作，直到更新成功为止。通过该异步回调过程可进一步保证物流数据处理系统的各子系统间信息的一致性。

S259、删除与所述外部订单号及用户标识对应的事务处理标记。

由上面的描述可知，在当前时间距离建立事务处理标记本的时间的时长达到事务处理标记的有效时长时，不论与该事务处理标记对应的发货请求消息是否处理完成，均删除该事务处理标记。本申请实施例还包括如下两种情况可触发删除该事务处理标记：

其一、与事务处理标记对应的发货请求消息处理完成，也就是携带 与该事务处理标记对应的外部订单号及用户标识的发货请求消息处理完成，即发货成功，对应的内部订单状态更新为已发货。

其二、监控对所述发货请求消息执行发货的事务处理的状态，响应于确定对所述发货请求消息执行发货的事务处理中断，则删除与中断的发货请求消息中携带的外部订单号及用户标识对应的所述事务处理标记。也就是，携带与该事务处理标记对应的外部订单号及用户标识的发货请求消息因故障等各种原因处理中断，无法继续对该发货请求消息进行发货处理的情况。

S260、返回发货信息。

本申请实施例各所返回的发货信息的步骤所返回的发货请求消息均包括仓储订单号以及每个仓储订单号对应的物品信息。

本申请实施例通过为发货请求消息建立对应的事务处理标记，在事务处理标记存在情况下，对于并发的同一发货请求消息进行丢弃，即不做发货处理，从而可有效避免针对同一发货请求消息的重复发货问题。

另外，本申请实施例实现了依据设置的拆单方案进行自动拆单，避免了现有技术中人为拆单效率低及拆单维度不统一导致的系统间单据信息不一致的现象。针对拆单后对应的多个仓储订单实行统一发货，可进一步保证系统间信息的一致性。

同时，对系统间相互调用操作进行监控，在操作失败情况下通过异步回调保证操作的成功率，从而进一步保证系统间信息的一致性。

本申请实施例还提供一种与上述物流数据处理方法对应的物流数据处理装置，该装置可设置于物流数据处理系统的发货中心子系统的服务器中，或与该服务器相连，用于对用户发出的针对外部订单号的发货请求消息进行用于发货的事务处理，该装置结构示意图如图4中所示，该装置主要包括如下单元：

接收单元41，用于接收携带外部订单号及用户标识的发货请求消息；

判断单元42，用于判断在本地是否已建立有与所述外部订单号及用户标识对应的事务处理标记；

第一处理单元43，用于在所述判断单元判断已建立有对应的事务处理标记情况下丢弃接收的所述发货请求消息；

建立单元44，用于在所述判断单元判断未建立有对应的事务处理标记情况下在本地建立与所述外部订单号及用户标识对应的事务处理标记；

第二处理单元45，用于仅对未丢弃的发货请求消息执行用于发货的事务处理，从而对同一用户发出的针对同一外部订单号的并发的发货请求消息仅进行一次用于发货的事务处理。

其中，所述建立单元44被配置为：

设置所述事务处理标记的有效时长。

从建立所述事务处理标记开始计时；

判断当前时间距离建立所述事务处理标记的时间的时长是否达到所述有效时长；

若达到所述有效时长则删除所述事务处理标记。

可选地，所述建立单元44被配置为：

在第二处理单元45对未丢弃的发货请求消息执行用于发货的事务处理完成后，删除与所述未丢弃的发货请求消息中携带的外部订单号及用户标识对应的所述事务处理标记。

可选地，所述建立单元44被配置为：

监控对所述发货请求消息执行发货的事务处理的状态；

响应于确定对所述发货请求消息执行发货的事务处理中断，则删除与中断的发货请求消息中携带的外部订单号及用户标识对应的所述事务处理标记。

另外，所述建立单元44还可被配置为：

为建立的所述事务处理标记赋值；

通过更新所述事务处理标记的值来统计接收的携带同一外部订单号及用户标识的发货请求消息的数量。

其中，所述第二处理单元45被配置为：

响应于确定存在与所述外部订单号对应的内部订单，以及不存在与所述内部订单对应的仓储订单，且所述内部订单已经拆分成多个子内部订单；则

删除所述内部订单拆分后的所述多个子内部订单，保留所述内部订单；

依据设置的拆单方案将保留的所述内部订单重新拆分成多个子内部订单；

针对重新拆分后的多个子内部订单执行用于发货的事务处理。

针对重新拆分后的多个子内部订单执行用于发货的事务处理包括：

针对重新拆分后的多个子内部订单生成对应的多个仓储订单；

调用仓储中心的批量发货接口将所述多个子内部订单对应的多个仓储订单统一发货。

针对重新拆分后的多个子内部订单执行用于发货的事务处理还包括：

所述多个子内部订单对应的多个仓储订单统一发货成功后，触发更新与所述外部订单号对应的内部订单状态为已发货状态。

可选地，所述装置还可包括：

监控单元46，用于监控更新与所述外部订单号对应的内部订单状态为已发货状态是否成功；

异步调用单元47，用于在所述监控单元监控所述更新与所述外部订单号对应的内部订单状态为已发货状态失败情况下，触发生成异步调用任务，以重复执行所述与所述外部订单号对应的内部订单状态为已发货状态的步骤，直到更新成功。

综上所述，本申请实施例至少具有如下优势：

通过为发货请求消息建立对应的事务处理标记，在事务处理标记存在情况下，对于并发的同一发货请求消息进行丢弃，即不做发货处理，从而可有效避免针对同一发货请求消息的重复发货问题。

另外，本申请实施例实现了依据设置的拆单方案进行自动拆单，避免了现有技术中人为拆单效率低及拆单维度不统一导致的系统间单据信息不一致的现象。针对拆单后对应的多个仓储订单实行统一发货，可进一步保证系统间信息的一致性。

同时，对系统间相互调用操作进行监控，在操作失败情况下通过异步回调保证操作的成功率，从而进一步保证系统间信息的一致性。

需要注意的是，本申请可在软件和/或软件与硬件的组合体中被实施， 例如，可采用专用集成电路(ASIC)、通用目的计算机或任何其他类似硬件设备来实现。在一个实施例中，本申请的软件程序可以通过处理器执行以实现上文所述步骤或功能。同样地，本申请的软件程序(包括相关的数据结构)可以被存储到计算机可读记录介质中，例如，RAM存储器，磁或光驱动器或软磁盘及类似设备。另外，本申请的一些步骤或功能可采用硬件来实现，例如，作为与处理器配合从而执行各个步骤或功能的电路。

另外，本申请的一部分可被应用为计算机程序产品，例如计算机程序指令，当其被计算机执行时，通过该计算机的操作，可以调用或提供根据本申请的方法和/或技术方案。而调用本申请的方法的程序指令，可能被存储在固定的或可移动的记录介质中，和/或通过广播或其他信号承载媒体中的数据流而被传输，和/或被存储在根据所述程序指令运行的计算机设备的工作存储器中。在此，根据本申请的一个实施例包括一个装置，该装置包括用于存储计算机程序指令的存储器和用于执行程序指令的处理器，其中，当该计算机程序指令被该处理器执行时，触发该装置运行基于前述根据本申请的多个实施例的方法和/或技术方案。

对于本领域技术人员而言，显然本申请不限于上述示范性实施例的细节，而且在不背离本申请的精神或基本特征的情况下，能够以其他的具体形式实现本申请。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本申请的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化涵括在本申请内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。此外，显然“包括”一词不排除其他单元或步骤，单数不排除复数。系统权利要求中陈述的多个单元或装置也可以由一个单元或装置通过软件或者硬件来实现。第一，第二等词语用来表示名称，而并不表示任何特定的顺序。