CN112445807A - 商品数据更新方法、装置、服务器及存储介质 - Google Patents

Abstract

本申请公开了一种商品数据更新方法、装置、服务器及存储介质，属于互联网技术领域。该方法包括：接收商品数据更新请求，商品数据更新请求用于更新目标商品对应的商品信息，商品数据更新请求中包含流程属性信息，其中，不同命令流程对应不同流程属性信息；根据流程属性信息确定商品数据更新请求对应的目标命令流程；执行目标命令流程，更新目标商品对应的商品信息。可以实现对不同商品数据更新操作的隔离，避免多个用户同时更新商品数据时出现数据混淆的情况，优化了商品数据更新流程。

Description

商品数据更新方法、装置、服务器及存储介质

技术领域

本申请实施例涉及互联网技术领域，特别涉及一种商品数据更新方法、装置、服务器及存储介质。

背景技术

本地生活平台是提供有餐饮、生活服务、休闲娱乐等商品信息的平台，用户可以通过本地生活平台了解到更便捷、全面的商品信息，比如，商品价格、商品详细信息、商品优惠活动等。

相关技术中，为了维护本地生活平台中的商品业务，某个门店的业务往往需要多类用户共同维护，比如，商户管理员、门店的责任销售、运营小编等，以商品价格为例，可能同时存在多个用户需要修改商品内容，比如，用户A修改了商品A在未来某段时间的价格，但是用户A并未选择发布该价格，后续，用户B修改了商品A当天的价格并选择立即发布；由于用户A和用户B共享同一块数据编辑区域，用户B对商品A价格的修改会覆盖用户A对商品A价格的修改，导致用户A对商品A价格的修改无效或更早发布，从而可能出现商品信息丢失或冲突的情况。

发明内容

本申请实施例提供了一种商品数据更新方法、装置、服务器及存储介质。所述技术方案如下：

一方面，本申请实施例提供一种商品数据更新方法，所述方法包括：

接收商品数据更新请求，所述商品数据更新请求用于更新目标商品对应的商品信息，所述商品数据更新请求中包含流程属性信息，其中，不同命令流程对应不同流程属性信息；

根据所述流程属性信息确定所述商品数据更新请求对应的目标命令流程；

执行所述目标命令流程，更新所述目标商品对应的所述商品信息。

另一方面，本申请实施例提供一种商品数据更新装置，所述装置包括：

接收模块，用于接收商品数据更新请求，所述商品数据更新请求用于更新目标商品对应的商品信息，所述商品数据更新请求中包含流程属性信息，其中，不同命令流程对应不同流程属性信息；

第一确定模块，用于根据所述流程属性信息确定所述商品数据更新请求对应的目标命令流程；

更新模块，用于执行所述目标命令流程，更新所述目标商品对应的所述商品信息。

另一方面，本申请实施例提供一种服务器，所述服务器包括处理器和存储器，所述存储器中存储有计算机程序，所述计算机程序由所述处理器加载并执行以实现如上述方面所述的商品数据更新方法。

另一方面，本申请实施例提供一种非临时性计算机可读存储介质，其上存储有计算机程序，所述计算机程序由处理器加载并执行以实现如上述方面所述的商品数据更新方法。

另一方面，本申请实施例提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。服务器的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该服务器执行上述方面的各种可选实现方式中提供的商品数据更新方法。

本申请实施例提供的技术方案可以带来如下有益效果：

提出命令流程的概念，可以基于商品数据更新请求中包含的流程属性信息的不同，为不同的商品数据更新请求确定出不同的命令流程，使得在更新商品数据时可以基于其对应的命令流程来更新，比如，若来自两个用户的商品更新数据请求，即可以分别为其建立不同的命令流程，分别执行两个命令流程来实现对商品信息的更新，可以实现对不同商品数据更新操作的隔离，从而避免多个用户同时更新商品数据时出现数据混淆的情况，优化了商品数据更新流程。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1示出了本申请各个实施例提供的实施环境的示意图；

图2示出了本申请一个实施例提供的商品数据更新方法的流程图；

图3示出了本申请另一个实施例提供的商品数据更新方法的流程图；

图4示出了本申请另一个实施例提供的商品数据更新方法的流程图；

图5示出了本申请另一个实施例提供的商品数据更新方法的流程图；

图6示出了本申请一个示例性实施例示出的命令流程的执行过程的示意图；

图7示出了本申请另一个实施例提供的商品数据更新方法的流程图；

图8示出了本申请一个示例性实施例提供的命令流程的结构图；

图9示出了本申请一个实施例提供的商品数据更新装置的结构框图；

图10示出了本申请一个实施例提供的服务器的结构框图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。

相关技术中，一般需要多个用户来共同维护商品运营平台中的各个商品信息，比如，提供该商品的商家、商品运营平台中的责任销售等，这些用户均具有修改商品信息的权限，当多个用户共同对某个商品信息进行更新时，可能会出现商品数据更新冲突、交叉覆盖的问题，从而影响某些对商品信息的重要更新任务的执行。比如，在一种应用场景下，对于运营平台上的商品A，用户A和用户B均具有对商品A的商品信息的修改权限，当用户希望修改商品A在未来一周内的商品价格，当用户A修改后，先保存了当前修改数据，但是并未将该修改数据提交至发布；另一边，用户B需要紧急修改商品A的当天价格，并在修改后选择立即发布，传统的数据更新方法中，由于多人共同编辑时是共享同一数据编辑区域的，因此，用户B选择修改后并发布后，会将本来并未选择发布的用户A的修改数据也同时发布到商品运营平台中，从而导致商品A的商品信息出现冲突信息，从而威胁到商家或者运营平台的利益。

不同于相关技术中的商品数据更新方法，本申请实施例提供了一种新的商品数据更新方法，图1示出了本申请各个实施例提供的实施环境的示意图。该实施环境中包括第一终端101、服务器102和第二终端103。

第一终端101是具有商品数据查看和维护功能的设备，其可以是安装有商品运营应用程序的设备，比如，智能手机、平板电脑、PC(Personal Computer，个人计算机)等，其中，商品运营应用程序可以是点餐应用、购票应用、住宿订购应用等。本申请实施例中，第一终端101是目标角色所持有的设备，该目标角色指对商品运营平台中的商品数据具有更新或修改权限的角色，比如，商品提供商户、商品责任销售等；可选的，当目标角色在第一终端101发起对目标商品的商品信息的商品数据更新请求后，第一终端101将该商品数据更新请求发送至服务器102，使得服务器102可以基于该商品数据更新请求确定对应的命令流程；可选的，目标角色可以在第一终端101提供的商品运营界面中提交需要更新的商品更新数据，以便服务器102可以基于将该商品更新数据对商品信息进行更新。

第一终端101与服务器102之间通过有线或无线网络相连。

服务器102是商品运营应用程序对应的后台服务器或业务服务器。其是具有创建命令流程、执行命令流程、更新商品信息等功能的设备，其可以是一台服务器，若干台服务器构成的服务器集群或云服务器。本申请实施例中，服务器102可以接收第一终端101发送的商品数据更新请求，从而为该商品数据更新请求确定其对应的命令流程，并通过执行对应的命令流程，更新商品信息。可选的，服务器102可以接收来自第一终端101发送的商品更新数据，并执行命令流程，将该商品更新数据发布到线上，即更新其他终端上的商品信息。

服务器102和第二终端103之间通过有线或无线网络相连。

第二终端103是安装有商品运营客户端的设备。第二终端103提供有商品查询和商品交易功能的终端，其可以是智能手机、平板电脑、PC等。本申请实施例中，第二终端103可以接收来自服务器102发送的商品更新数据，并在商品运营客户端中对应更新商品信息，以便用户可以及时了解到商品的最新信息。

本实施例中，提出命令流程的概念，服务器102可以基于商品数据更新请求中包含的流程属性信息的不同，为不同的商品数据更新请求确定出不同的命令流程，使得在更新商品数据时可以基于其对应的命令流程来更新，比如，若来自两个用户的商品更新数据请求，即可以分别为其建立不同的命令流程，分别执行两个命令流程来实现对商品信息的更新，从而实现对不同商品数据更新操作的隔离，避免多个用户同时更新商品数据时出现数据混淆的情况，优化了商品数据更新流程。

请参考图2，其示出了本申请一个实施例提供的商品数据更新方法的流程图，本申请实施例以该方法应用于图1所示的服务器为例进行说明，该方法包括：

步骤201，接收商品数据更新请求，商品数据更新请求用于更新目标商品对应的商品信息，商品数据更新请求中包含流程属性信息，其中，不同命令流程对应不同流程属性信息。

其中，商品的商品信息可以是商品价格、商品详细信息(商品图文描述)、商品状态(商品上架或商品下架)、商品库存等。

在一种可能的实施方式中，当用户需要调整线上某个商品的商品信息时，可以在商品信息修改界面中选择所需要修改的目标商品，并选择需要修改的商品信息，比如，商品价格，提交后即向服务器发起对目标商品对应的商品价格的商品数据更新请求，则对应的服务器会接收到终端发送的商品数据更新请求。

相比于相关技术中，不同用户在线修改商品数据时，是针对同一商品数据区域进行修改，会出现后续修改的数据覆盖前次修改的情况，本申请实施例中，为了区分不同的商品数据更新请求，基于商品数据更新请求对应的流程属性信息来为其确定不同的命令流程。

针对用户发起商品数据更新请求的场景，若是不同用户发起商品数据更新请求，则对应的商品数据更新请求的请求发起方不同；若修改的是不同商品对应的商品数据，则对应的商品标识不同；若修改的是同一商品的不同商品内容，比如，价格或图文描述，则对应的商品更新的更新模块可能并不相同，因此，在一种可能的实施方式中，将不同商品数据更新请求对应的请求信息确定为流程属性信息，来区分不同命令流程。

可选的，可以发起商品数据更新请求的角色或用户均需要具有对商品数据的修改权限。

步骤202，根据流程属性信息确定商品数据更新请求对应的目标命令流程。

其中，命令流程即从接收商品数据更新请求至将商品更新数据发布至线上所需要经过的操作步骤。

为了区分不同商品数据更新请求，避免出现基于该商品数据更新请求更新的商品数据与其他更新请求对应的商品数据混淆的情况，在一种可能的实施方式中，针对流程属性信息的不同，为不同的商品数据更新请求确定不同命令流程，从而实现对不同商品数据更新请求的隔离，进而避免在不同商品更新请求下更新商品信息时的数据混淆情况。

在一个示例性的例子中，若用户A对商品A发起商品价格的变更，则商品更新数据请求中可能包含用户A标识、商品标识和商品价格，则可以将用户A标识、商品标识和商品价格确定为流程属性信息，并根据该流程属性信息确定出目标命令流程。

步骤203，执行目标命令流程，更新目标商品对应的商品信息。

当服务器为接收到的商品数据更新请求确定出其对应的目标命令流程后，即可以执行目标命令流程，即从接收商品更新数据到发布商品更新数据，实现基于该商品更新数据更新目标商品对应的商品信息，具体的实现逻辑可以为，当命令流程指示商品更新数据满足发布条件后，将商品更新数据发送至其他终端，其他终端接收到商品更新数据后，即自行更新商品信息。

综上所述，本申请实施例中提出命令流程的概念，提出命令流程的概念，可以基于商品数据更新请求中包含的流程属性信息的不同，为不同的商品数据更新请求确定出不同的命令流程，使得在更新商品数据时可以基于其对应的命令流程来更新，比如，若来自两个用户的商品更新数据请求，即可以分别为其建立不同的命令流程，分别执行两个命令流程来实现对商品信息的更新，从而实现对不同商品数据更新操作的隔离，避免多个用户同时更新商品数据时出现数据混淆的情况，优化了商品数据更新流程。

在一种可能的应用场景下，如果用户A发起对商品A的商品描述信息的修改，但是在本次修改过程中，用户A仅保存了修改内容，并未提交或发布，一段时间后，用户A想在上次修改内容的基础上继续对商品A进行商品描述信息的修改，此时，若服务器基于商品数据更新请求创建一个新的命令流程，显然需要用户重新输入上次修改内容，且会造成上次商品数据更新请求对应的命令流程无效，造成对服务器处理资源的浪费，因此，在一种可能的实施方式中，服务器可以基于商品更新数据表征的流程属性信息，来确定是否存在已创建的命令流程(未完成的命令流程)，若存在，则将该已创建的命令流程确定为当前商品数据更新请求对应的目标命令流程，若没有，则为商品数据更新请求创建新的命令流程。下文实施例即分别描述两种情况下的商品数据更新方法。

在一个示例性的例子中，如图3所示，其示出了本申请另一个实施例提供的商品数据更新方法的流程图，本申请实施例以该方法应用于图1所示的服务器为例进行说明，该方法包括：

步骤301，接收商品数据更新请求，商品数据更新请求用于更新目标商品对应的商品信息，商品数据更新请求中包含流程属性信息，其中，不同命令流程对应不同流程属性信息。

其中，流程属性信息包括请求发起方法标识、目标商品对应的商品标识和待更新的商品信息类型。针对请求发起方标识，即某个角色(用户)发起的商品数据更新请求，可以采用用户或角色账号(Identity Document，ID)来表示；对于目标商品对应的商品标识，由于不同商品一般都具有不同的ID，因此，可以采用商品ID来表示；对于待更新的商品信息类型，由于商品信息包含很多方面的内容，比如，价格、图文描述、库存、状态等，因此，根据商品信息类型将商品信息划分出不同模块，比如，价格模块、库存模块、状态模块、图文描述模块等，并将各个模块作为待更新的商品信息类型。

可选的，流程属性信息可以包括上述提到的三种的至少一种，或者，还可以包括商户ID，对应该商品可能需要在多个商户中进行更新的问题。

在一种可能的实施方式中，当用户发起对目标商品的商品数据更新请求时，该商品数据更新请求中会携带对应的请求发起方标识(用户ID)、目标商品对应的商品标识(商品ID)和待更新的商品信息类型(修改的模块名称或模块名称标识)，则对应的服务器接收到该商品数据更新请求，即获取到该商品数据更新请求对应的流程属性信息。

步骤302，响应于命令流程集合中包含流程属性信息对应的已创建命令流程，将已创建命令流程确定为目标命令流程，命令流程集合中包含至少一个已创建命令流程。

其中，已创建命令流程指该命令流程未完成，且该命令流程关联的商品更新数据未发布。

由于不同的命令流程具备不同流程属性信息，因此，需要确定接收的商品更新数据是否具备已创建命令流程，就需要基于该流程属性信息去命令流程集合中查找，若查找到存在已创建命令流程对应的流程属性信息与该流程属性信息一致，则无需为该商品更新数据创建新的命令流程，只需将已创建命令流程确定为当前商品更新数据对应的目标命令流程即可。

在一种可能的实施方式中，根据流程属性信息在命令流程集合中查找目标命令流程的方法可以包括以下步骤：

一、获取商品数据更新请求对应的请求发起方标识、目标商品对应的商品标识和待更新的商品信息类型。

本申请实施例中，将请求发起方标识、目标商品对应的商品标识和待更新的商品信息类型确定为流程属性信息，即请求发起方标识、目标商品对应的商品标识和待更新的商品信息类型这三类信息均一致，则表示是同一商品数据更新请求对应的目标命令流程。

可选的，流程属性信息可以具有比上述三类信息更少的信息，比如，上述三类信息中的任意两类信息；也可以包括比上述三类信息更多的信息，比如，在流程属性信息中增加商户ID，本申请实施例对此不构成限定。

在一种可能的实施方式中，商品数据更新请求中携带有上述流程属性信息，服务器接收到商品数据更新请求，即获取到该商品数据更新请求中包含的流程属性信息，以便根据该流程属性信息去已创建命令流程中查找，确认是否存在与该流程属性信息匹配的已创建命令流程。

在一个示例性的例子中，可以将角色ID+商品ID+内容模块作为键值，去命令流程集合中查找其对应的已创建命令流程。

可选的，当创建命令流程时，可以将该命令流程和其对应的流程属性信息关联存储，以便后续基于流程属性信息在命令流程集合中查找目标命令流程。

二、响应于请求发起方标识、商品标识和商品信息类型与已创建命令流程对应的流程属性信息一致，将已创建命令流程确定为目标命令流程。

在一种可能的实施方式中，当存在已创建命令流程对应的流程属性信息中，请求发起方标识、商品标识和商品信息类型均与当前商品数据更新请求表征的流程属性信息一致，则确定用户是想在上次未完成的已创建命令流程的基础上继续完善商品更新数据，可以将该已创建命令流程确定为目标命令流程，并将该已创建命令流程反馈给用户。

步骤303，获取与已创建命令流程关联的草稿数据，其中，草稿数据是目标商品的历史商品更新数据，且历史商品更新数据未发布。

为了避免不同命令流程对应的商品更新数据混淆，因此，服务器在根据商品数据更新请求创建命令流程后，若接收到用户对商品更新数据的输入和保存操作后，即会将接收到的商品更新数据作为草稿数据与其对应的命令流程关联，以便后续用户可以基于该草稿数据继续修改商品更新数据，或基于该草稿数据对线上商品进行更新。

在一种可能的实施方式中，若根据流程属性信息确定出已创建命令流程(未完成的命令流程)后，即获取与其关联的草稿数据(历史商品更新数据)，并将该草稿数据返回给用户，以便用户基于该草稿数据继续修改商品数据。

可选的，若草稿数据为商品图文描述，则将其渲染画面也反馈给用户，以便用户基于该渲染画面继续修改商品图文描述相关信息。

步骤304，响应于接收到商品更新数据的输入操作，根据商品更新数据修改草稿数据。

在一种可能的实施方式中，用户基于历史商品更新数据继续修改商品信息，并点击保存商品更新数据，则服务器接收到商品更新数据的输入操作，即根据该输入操作对应的商品更新数据修改已创建命令流程关联的草稿数据，即确定出本次商品数据更新请求对应的目标命令流程，以及本次商品数据更新请求对应的待更新商品数据。

步骤305，执行目标命令流程，更新目标商品对应的商品信息。

在一种可能的实施方式中，按照目标命令流程的执行步骤，并在目标命令流程指示发布商品更新数据时，根据与目标命令流程关联的草稿数据更新线上该目标商品对应的商品信息。

本实施例中，通过流程属性信息在命令流程集合中查找，并在查找到与流程属性信息一致的已创建命令流程后，表示用户需要在之前未完成的命令流程基础上继续进行商品数据更新，因此，将已创建命令流程确定为本次商品数据更新请求对应的目标命令流程，并向用户反馈已创建命令流程对应的草稿数据，以便用户可以基于历史商品更新数据继续修改商品信息，避免用户需要重新输入历史商品更新数据，提高了用户进行商品数据更新的效率，同时避免创建新的命令流程对服务器处理资源的浪费。

上文实施例描述了存在与本次商品数据更新请求对应的流程属性信息一致的已创建命令流程的情况，本实施例着重描述若不存在与该流程属性信息一致的已创建命令流程，服务器如何基于商品数据更新请求确定目标命令流程。

在一个示例性的例子中，如图4所示，其示出了本申请另一个实施例提供的商品数据更新方法的流程图，本申请实施例以该方法应用于图1所示的服务器为例进行说明，该方法包括：

步骤401，接收商品数据更新请求，商品数据更新请求用于更新目标商品对应的商品信息，商品数据更新请求中包含流程属性信息，其中，不同命令流程对应不同流程属性信息。

本步骤的实施方式可以参考上文实施例，本实施例对此不做赘述。

步骤402，响应于命令流程集合中不包含流程属性信息对应的已创建命令流程，创建流程属性信息对应的目标命令流程。

其中，命令流程属性信息包括商品数据更新请求对应的请求发起方标识、目标商品对应的商品标识和待更新的商品信息类型。

其中，根据命令流程属性信息在命令流程集合中查找已创建命令流程的方式可以参考上文实施例，本实施例在此不做赘述。

在一种可能的实施方式中，当确定出命令流程集合中不存在与该流程属性信息一致的已创建命令流程，表示本次商品数据更新请求不同于服务器中已有的未完成命令流程，需要为该商品数据更新请求创建新的命令流程，即目标命令流程，并将该流程属性信息与该目标命令流程关联，方便后续查找。

步骤403，响应于接收到商品更新数据的输入操作，根据商品更新数据创建草稿数据。

由于本次商品数据更新请求对应的是新创建的命令流程，则该命令流程不具有历史商品更新数据，即草稿数据，因此，在一种可能的实施方式中，当用户在终端中输入需要更新的商品更新数据，并保存该商品更新数据后，对应的，服务器接收到商品更新数据的输入操作，即根据该商品更新数据为该目标命令流程创建新的草稿数据。

步骤404，将草稿数据与目标命令流程关联。

为了便于后续用户可以基于该草稿数据进行修改或服务器可以基于该草稿数据更新线上的商品信息，因此，在一种可能的实施方式中，将草稿数据与目标命令流程关联。

步骤405，执行目标命令流程，更新目标商品对应的商品信息。

在一种可能的实施方式中，按照目标命令流程的执行步骤，并在目标命令流程指示发布商品更新数据后，根据与目标命令流程关联的草稿数据更新线上该目标商品对应的商品信息。

本实施例中，当根据流程属性信息在命令流程集合中未查找到已创建命令流程后，表示本次商品数据更新请求为新的更新请求，因此，服务器需要针对本次商品数据更新请求创建新的命令流程和草稿数据，以便根据该命令流程和草稿数据更新商品信息。

上文实施例着重描述如何确定商品更新数据请求对应的目标命令流程的过程，本实施例即重点描述如何执行目标命令流程更新商品信息的过程。

如图5所示，其示出了本申请另一个实施例提供的商品数据更新方法的流程图，本申请实施例以该方法应用于图1所示的服务器为例进行说明，该方法包括：

步骤501，接收商品数据更新请求，商品数据更新请求用于更新目标商品对应的商品信息，商品数据更新请求中包含流程属性信息，其中，不同命令流程对应不同流程属性信息。

步骤502，根据流程属性信息确定商品数据更新请求对应的目标命令流程。

步骤501和步骤502的实施方式可以参考上文实施例，本实施例在此不做赘述。

步骤503，响应于对草稿数据的提交操作，将目标命令流程对应的流程状态由编辑状态更新为审核状态，草稿数据是目标商品的商品更新数据。

其中，编辑状态下，用户可以对草稿数据进行修改。

当服务器为本次商品数据更新请求创建其对应的目标命令流程后，从目标命令流程创建开始，设置目标命令流程处于编辑状态，直至用户对草稿数据的提交操作后，流程状态才会变更。

其中，当用户正在编辑草稿数据的过程中，或用户仅保存该草稿数据，并未提交草稿数据，服务器均设置目标命令流程处于编辑状态。

当用户编辑完成商品更新数据即草稿数据后，若确认无误可以点击提交控件，则服务器接收到对草稿数据的提交操作，可以将目标命令流程的流程状态由编辑状态转为审核状态。

步骤504，响应于目标命令流程处于审核状态，根据审核规则对草稿数据进行审核，得到审核结果。

为了保证提交的商品更新数据符合市场要求和规则，避免随意更改商品信息威胁到其他用户的利益，在一种可能的实施方式中，设置有审核规则，该审核规则用于对提交的商品更新数据(草稿数据)进行审核，只有审核通过后的草稿数据才可以被用于发布至线上。

其中，审核规则的确定方式可以包括以下步骤：

一、获取目标商品对应的商品属性信息。

其中，审核规则是基于用户提交的草稿数据(商品更新数据确定的)，因此，当服务器接收到对草稿数据的提交操作后，即进行上述确定审核规则的过程。

其中，商品属性信息可以指目标商品所属类别，比如，目标商品属于书籍类、家居类、植物类。也可以指目标商品所属行业，比如，医美类、鲜花类、护肤类等，或其他更详细的信息，本申请实施例对此不构成限定。

在一种可能的实施方式中，服务器在接收到草稿数据的提交操作后，即获取目标商品对应的商品属性信息，以便后续根据该商品属性信息确定其对应的审核规则。

二、根据商品属性信息确定审核规则，其中，不同商品属性信息对应不同审核规则。

其中，审核规则指一些可以通过服务器识别的审核通过或审核驳回的指标，比如，商品佣金设置需小于0.5；商品描述信息中不得包含“最好”等词汇。

在一种可能的实施方式中，当服务器获取到目标商品对应的商品属性信息后，即可以根据该商品属性信息确定其对应的审核规则，并将审核规则保存在目标命令流程对应的命令上下文中，以便基于该审核规则对草稿数据进行审核。

可选的，审核规则也可以由负责商品运营的管理员设置。

三、将审核规则存储在目标命令流程对应的命令上下文中。

在一种可能的实施方式中，审核规则存储在目标命令流程对应的命令上下文中，当目标命令流程对应的流程状态由编辑状态流转至审核状态时，根据命令上下文中的审核规则对草稿数据进行审核，得到审核结果。

步骤505，响应于审核结果指示草稿数据审核通过，将目标命令流程由审核状态更新为发布状态。

在一种可能的实施方式中，当审核结果指示草稿数据审核通过后，即表示该草稿数据符合商品信息规范，可以用于线上发布，则将目标命令流程对应的流程状态由审核状态更新为发布状态。

可选的，若审核结果指示草稿数据未经过审核，即表示用户当前修改的商品信息不符合商品信息规范，需要重新修改和提交，因此，为了提醒用户对草稿数据进行修改，则将目标命令流程对应的流程状态由审核状态更新为编辑状态，以便用户在编辑状态下对草稿数据重新修改。

步骤506，响应于目标命令流程处于发布状态，根据草稿数据更新目标商品对应的商品信息。

在一种可能的实施方式中，当目标命令流程处于发布状态时，即表示草稿数据可以被用于发布至线上，则服务器就可以根据草稿数据更新目标商品对应的商品信息。

步骤507，响应于商品信息更新完成，清除草稿数据和目标命令流程，草稿数据是目标商品的商品更新数据。

在一种可能的实施方式中，当服务器确定出线上该商品信息更新完成后，表示目标命令流程已完成，则可以清除目标命令流程和草稿数据，避免已完成命令流程和草稿数据对服务器处理资源的占用。

可选的，若服务器确定草稿数据未发布成功，即发布失败的情况，表示可能存在某些原因，比如，商品更新数据设置有误，或其他原因导致商品信息未按时发布至线上，为了便于用户可以修改商品更新数据，并重新发布至线上，服务器可以在发布失败的情况下将目标命令流程对应的流程状态由发布状态更新至编辑状态，以便用户基于发布失败的情况重新编辑商品更新数据。

在一个示例性的例子中，如图6所示，其示出了本申请一个示例性实施例示出的命令流程的执行过程的示意图。当命令流程创建后，其处于制作中(即编辑状态)；当接收到对草稿数据的提交操作后，且提交成功后，服务器确定草稿数据已提交，则服务器将草稿数据提交审核，命令流程转至审核中(审核状态)；当审核结果指示草稿数据通过审核，则流程状态更新为审核通过或待发布(即发布状态)中，服务器确定发布策略为实时发布后，即根据草稿数据更新商品信息，流程状态处于发布中，当发布成功后，流程状态为发布成功；若发布失败，则流程状态为发布失败，并更新流程状态至制作中；可选的，只要流程状态位于发布中之前，用户均可以对草稿数据发起撤回，比如，当命令流程处于审核中，用户需要修改草稿数据，可以发起撤回，则流程状态由审核中更新为制作中；当流程状态处于待发布状态，用户也可以发起撤回，则流程状态由待发布中更新为制作中；可选的，当草稿数据未通过审核(驳回审核)，则流程状态由审核中更新为审核驳回，再更新为制作中，以便用户重新编辑草稿数据。

本实施例中，描述了目标命令流程在创建后各个流程状态的转换情况，即编辑状态、审核状态和发布状态这三个状态之间的转换，且当流程状态转至发布状态后，商品更新数据才可以被用于更新商品信息。此外，当商品信息更新完成后，即清除本次商品数据更新请求对应的目标命令流程和草稿数据，以避免对服务器处理资源的占用。

在一种可能的应用场景下，由于用户需要修改的商品信息数量较多，若在当天进行商品数据更新操作，显然无法及时实现商品信息更新，用户的诉求是可以提前将商品更新数据编辑后，设置发布时间，并在发布时间上准时将商品更新数据发布至线上，本申请实施例针对该应用场景提供有发布策略选项，以便用户可以根据自身需求设置发布时间。

在图5的基础上，如图7所示，步骤506可以包括步骤506A和步骤506B。

步骤506A，响应于目标命令流程处于发布状态，从目标命令流程对应的命令上下文中获取预设发布策略。

在一种可能的实施方式中，当用户提交草稿数据时，可以设置该商品更新数据的发布策略，以发布时间为例，若用户需要立即更新该商品信息，可以选择实时发布，即目标命令流程处于发布状态后，立即根据草稿数据更新商品信息；若用户想在未来某个时间更新商品信息，可以选择延时发布策略，并预设发布时间，以便目标命令流程在达到预设发布时间后，根据草稿数据更新商品信息。

可选的，若用户并未设置预设发布策略，服务器默认实时发布策略。

其中，当服务器接收到发布策略设置操作，即将预设发布策略存储在目标命令流程对应的命令上下文中，使得当目标命令流程处于发布状态时，可以基于该预设发布策略对商品信息进行更新。

步骤506B，根据预设发布策略和草稿数据更新目标商品对应的商品信息。

以预设发布策略为发布时间为例，预设发布策略可以包括实时发布和延时发布两种。实时发布即当流程状态更新至发布状态后，立即根据草稿数据对商品信息进行更新；延时发布即当流程状态更新至发布状态后，并非立即更新商品信息，而是在达到延时发布指示的发布时间后，才会根据草稿数据更新商品信息。

其中，根据预设发布策略和草稿数据更新商品信息的过程可以包括以下步骤：

一、响应于预设发布策略为实时发布，根据草稿数据更新商品信息。

在一种可能的实施方式中，当用户选择实时发布策略后，服务器将实时发布策略预存在目标命令流程对应的流程上下文中，当目标命令流程处于发布状态时，并确定出需要实时发布商品更新数据，则立即根据草稿数据更新商品信息。

二、响应于预设发布策略为延时发布，将目标命令流程添加至发布队列中，发布队列包含至少一个处于发布状态的命令流程。

当服务器获取到预设发布策略为延时发布，以及延时发布时间，表示用户并不想在当前时刻立即发布商品更新数据，为了满足用户延时发布的需求，可以先将目标命令流程添加至发布队列中，以便后续在达到发布时间后发布商品更新数据。

可选的，可以按照延时发布所指示的发布时间的先后顺序，在发布队列中添加目标命令流程。

三、响应于达到延时发布对应的发布时间，根据草稿数据更新商品信息。

在一种可能的实施方式中，若将目标命令流程添加至发布队列后，则服务器可以实时监测发布队列中各个命令流程的发布时间，若当前时刻达到该发布时间，则立即根据草稿数据更新商品信息。

其中，服务器可以每隔预设时间间隔扫描一次发布队列，以确定是否存在命令流程达到延时发布对应的发布时间，预设时间间隔可以是1h。

本实施例中，通过在目标命令流程对应的命令上下文中预存发布策略，以便基于用户需求更新商品信息，若用户需要实时发布，则目标命令流程处于发布状态后，立即根据商品更新数据更新商品信息；若用户需要延时发布，则目标命令流程基于延时发布对应的发布时间更新商品信息，提高了用户更新商品数据的效率，避免需要更新大量商品信息时的延时问题。

在一个示例性的例子中，针对上文实施例所示出的目标命令流程的确定和执行过程，可以得到命令流程所具有的结构，如图8所示，其示出了本申请一个示例性实施例提供的命令流程的结构图。根据商品数据更新请求确定命令流程800，命令流程800具有的流程属性信息可以包括：命令ID、商品ID、模块、角色标识和流程状态，其中，商品ID即商品数据更新请求所需要更新的目标商品对应的ID；角色标识即商品数据更新请求对应的请求发起方标识；模块即商品数据更新请求对应的待更新商品信息类型；命令ID即命令流程800对应的标识；流程状态即命令流程800所处的状态，比如，编辑状态、审核状态和发布状态。可选的，命令流程800与草稿数据关联，其中，草稿数据即商品更新数据；可选的，命令流程800还包括命令上下文，且命令上下文中至少包含审核规则和发布策略，其中，审核规则用于对命令流程800所关联的草稿数据进行审核，发布策略用于指示根据草稿数据更新商品信息的时间。

下述为本申请装置实施例，可以用于执行本申请方法实施例。对于本申请装置实施例中未披露的细节，请参照本申请方法实施例。

请参考图9，其示出了本申请一个实施例提供的商品数据更新装置的结构框图。该装置具有实现上述方法示例的功能，所述功能可以由硬件实现，也可以由硬件执行相应的软件实现。如图9所示，该装置可以包括：

接收模块901，用于接收商品数据更新请求，所述商品数据更新请求用于更新目标商品对应的商品信息，所述商品数据更新请求中包含流程属性信息，其中，不同命令流程对应不同流程属性信息；

第一确定模块902，用于根据所述流程属性信息确定所述商品数据更新请求对应的目标命令流程；

更新模块903，用于执行所述目标命令流程，更新所述目标商品对应的所述商品信息。

可选的，所述第一确定模块902，包括：

确定单元，用于响应于命令流程集合中包含所述流程属性信息对应的已创建命令流程，将所述已创建命令流程确定为所述目标命令流程，所述命令流程集合中包含至少一个所述已创建命令流程；

创建单元，用于响应于所述命令流程集合中不包含所述流程属性信息对应的所述已创建命令流程，创建所述流程属性信息对应的所述目标命令流程。

可选的，所述确定单元，还用于：

获取所述商品数据更新请求对应的请求发起方标识、所述目标商品对应的商品标识和待更新的商品信息类型；

响应于所述请求发起方标识、所述商品标识和所述商品信息类型与所述已创建命令流程对应的流程属性信息一致，将所述已创建命令流程确定为所述目标命令流程。

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

第一获取模块，用于获取与所述已创建命令流程关联的草稿数据，其中，所述草稿数据是所述目标商品的历史商品更新数据，且所述历史商品更新数据未发布；

修改模块，用于响应于接收到商品更新数据的输入操作，根据所述商品更新数据修改所述草稿数据。

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

创建模块，用于响应于接收到商品更新数据的输入操作，根据所述商品更新数据创建草稿数据；

关联模块，用于将所述草稿数据与所述目标命令流程关联。

可选的，所述更新模块903，包括：

第一更新单元，用于响应于对草稿数据的提交操作，将所述目标命令流程对应的流程状态由编辑状态更新为审核状态，所述草稿数据是所述目标商品的商品更新数据；

审核单元，用于响应于所述目标命令流程处于所述审核状态，根据审核规则对所述草稿数据进行审核，得到审核结果；

第二更新单元，用于响应于所述审核结果指示所述草稿数据审核通过，将所述目标命令流程由所述审核状态更新为发布状态；

第三更新单元，用于响应于所述目标命令流程处于所述发布状态，根据所述草稿数据更新所述目标商品对应的所述商品信息。

可选的，所述第三更新单元，还用于：

响应于所述目标命令流程处于所述发布状态，从所述目标命令流程对应的命令上下文中获取预设发布策略；

根据所述预设发布策略和所述草稿数据更新所述目标商品对应的所述商品信息。

可选的，所述第三更新单元，还用于：

响应于所述预设发布策略为实时发布，根据所述草稿数据更新所述商品信息；

响应于所述预设发布策略为延时发布，将所述目标命令流程添加至发布队列中，所述发布队列包含至少一个处于所述发布状态的命令流程；

响应于达到所述延时发布对应的发布时间，根据所述草稿数据更新所述商品信息。

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

第二获取模块，用于获取所述目标商品对应的商品属性信息；

第二确定模块，用于根据所述商品属性信息确定所述审核规则，其中，不同商品属性信息对应不同审核规则；

存储模块，用于将所述审核规则存储在所述目标命令流程对应的命令上下文中。

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

清除模块，用于响应于所述商品信息更新完成，清除草稿数据和所述目标命令流程，所述草稿数据是所述目标商品的商品更新数据。

综上所述，本申请实施例提出了命令流程的概念，可以基于商品数据更新请求中包含的流程属性信息的不同，为不同的商品数据更新请求确定出不同的命令流程，使得在更新商品数据时可以基于其对应的命令流程来更新，比如，若来自两个用户的商品更新数据请求，即可以分别为其建立不同的命令流程，分别执行两个命令流程来实现对商品信息的更新，从而实现对不同商品数据更新操作的隔离，避免多个用户同时更新商品数据时出现数据混淆的情况，优化了商品数据更新流程。

需要说明的是：上述实施例提供的装置在实现其功能时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将设备的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的装置与方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。

请参考图10，其示出了本申请一个实施例提供的服务器的结构框图。该服务器可用于实施上述实施例中提供的商品数据更新方法。具体来讲：

所述服务器1000包括中央处理单元(Central Processing Unit，CPU)1001、包括随机存取存储器(Random Access Memory，RAM)1002和只读存储器(Read-Only Memory，ROM)1003的系统存储器1004，以及连接系统存储器1004和中央处理单元1001的系统总线1005。所述服务器1000还包括帮助服务器内的各个器件之间传输信息的基本输入/输出系统(Input/Output系统，I/O系统)1006，和用于存储操作系统1013、应用程序1014和其他程序模块1015的大容量存储设备1007。

所述基本输入/输出系统1006包括有用于显示信息的显示器1008和用于用户输入信息的诸如鼠标、键盘之类的输入设备1009。其中所述显示器1008和输入设备1009都通过连接到系统总线1005的输入输出控制器1010连接到中央处理单元1001。所述基本输入/输出系统1006还可以包括输入输出控制器1010以用于接收和处理来自键盘、鼠标、或电子触控笔等多个其他设备的输入。类似地，输入输出控制器1010还提供输出到显示屏、打印机或其他类型的输出设备。

所述大容量存储设备1007通过连接到系统总线1005的大容量存储控制器(未示出)连接到中央处理单元1001。所述大容量存储设备1007及其相关联的计算机可读存储介质为服务器1000提供非易失性存储。也就是说，所述大容量存储设备1007可以包括诸如硬盘或者只读光盘(Compact Disc Read-Only Memory，CD-ROM)驱动器之类的计算机可读存储介质(未示出)。

不失一般性，所述计算机可读存储介质可以包括计算机存储介质和通信介质。计算机存储介质包括以用于存储诸如计算机可读存储指令、数据结构、程序模块或其他数据等信息的任何方法或技术实现的易失性和非易失性、可移动和不可移动介质。计算机存储介质包括RAM、ROM、可擦除可编程只读寄存器(Erasable Programmable Read OnlyMemory，EPROM)、电子抹除式可复写只读存储器(Electrically-Erasable ProgrammableRead-Only Memory，EEPROM)、闪存或其他固态存储其技术，CD-ROM、数字多功能光盘(Digital Versatile Disc，DVD)或其他光学存储、磁带盒、磁带、磁盘存储或其他磁性存储设备。当然，本领域技术人员可知所述计算机存储介质不局限于上述几种。上述的系统存储器1004和大容量存储设备1007可以统称为存储器。

存储器存储有一个或多个程序，一个或多个程序被配置成由一个或多个中央处理单元1001执行，一个或多个程序包含用于实现上述方法实施例的指令，中央处理单元1001执行该一个或多个程序实现上述各个方法实施例提供的方法。

根据本申请的各种实施例，所述服务器1000还可以通过诸如因特网等网络连接到网络上的远程服务器运行。也即服务器1000可以通过连接在所述系统总线1005上的网络接口单1011连接到网络1012，或者说，也可以使用网络接口单元1011来连接到其他类型的网络或远程服务器系统(未示出)。

所述存储器还包括一个或者一个以上的程序，所述一个或者一个以上程序存储于存储器中，所述一个或者一个以上程序包含用于进行本申请实施例提供的方法中由服务器所执行的步骤。

本申请实施例还提供了一种计算机可读存储介质，该计算机可读存储介质存储有至少一条指令，所述至少一条指令由所述处理器加载并执行以实现如上各个实施例所述的商品数据更新方法。

根据本申请的一个方面，提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。服务器的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该服务器执行上述方面的各种可选实现方式中提供的商品数据更新方法。

应当理解的是，在本文中提及的“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。另外，本文中描述的步骤编号，仅示例性示出了步骤间的一种可能的执行先后顺序，在一些其它实施例中，上述步骤也可以不按照编号顺序来执行，如两个不同编号的步骤同时执行，或者两个不同编号的步骤按照与图示相反的顺序执行，本申请实施例对此不作限定。

以上所述仅为本申请的可选实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (13)

1.一种商品数据更新方法，其特征在于，所述方法包括：

接收商品数据更新请求，所述商品数据更新请求用于更新目标商品对应的商品信息，所述商品数据更新请求中包含流程属性信息，其中，不同命令流程对应不同流程属性信息；

根据所述流程属性信息确定所述商品数据更新请求对应的目标命令流程；

执行所述目标命令流程，更新所述目标商品对应的所述商品信息。

2.根据权利要求1所述的方法，其特征在于，所述根据所述流程属性信息确定所述商品数据更新请求对应的目标命令流程，包括：

响应于命令流程集合中包含所述流程属性信息对应的已创建命令流程，将所述已创建命令流程确定为所述目标命令流程，所述命令流程集合中包含至少一个所述已创建命令流程；

响应于所述命令流程集合中不包含所述流程属性信息对应的所述已创建命令流程，创建所述流程属性信息对应的所述目标命令流程。

3.根据权利要求2所述的方法，其特征在于，所述响应于命令流程集合中包含所述流程属性信息对应的已创建命令流程，将所述已创建命令流程确定为所述目标命令流程，包括：

获取所述商品数据更新请求对应的请求发起方标识、所述目标商品对应的商品标识和待更新的商品信息类型；

响应于所述请求发起方标识、所述商品标识和所述商品信息类型与所述已创建命令流程对应的流程属性信息一致，将所述已创建命令流程确定为所述目标命令流程。

4.根据权利要求2所述的方法，其特征在于，所述将所述已创建命令流程确定为所述目标命令流程之后，所述方法还包括：

获取与所述已创建命令流程关联的草稿数据，其中，所述草稿数据是所述目标商品的历史商品更新数据，且所述历史商品更新数据未发布；

响应于接收到商品更新数据的输入操作，根据所述商品更新数据修改所述草稿数据。

5.根据权利要求2所述的方法，其特征在于，所述创建所述流程属性信息对应的所述目标命令流程之后，所述方法还包括：

响应于接收到商品更新数据的输入操作，根据所述商品更新数据创建草稿数据；

将所述草稿数据与所述目标命令流程关联。

6.根据权利要求1至5任一所述的方法，其特征在于，所述执行所述目标命令流程，更新所述目标商品对应的所述商品信息，包括：

响应于对草稿数据的提交操作，将所述目标命令流程对应的流程状态由编辑状态更新为审核状态，所述草稿数据是所述目标商品的商品更新数据；

响应于所述目标命令流程处于所述审核状态，根据审核规则对所述草稿数据进行审核，得到审核结果；

响应于所述审核结果指示所述草稿数据审核通过，将所述目标命令流程由所述审核状态更新为发布状态；

响应于所述目标命令流程处于所述发布状态，根据所述草稿数据更新所述目标商品对应的所述商品信息。

7.根据权利要求6所述的方法，其特征在于，所述响应于所述目标命令流程处于所述发布状态，根据所述草稿数据更新所述目标商品对应的所述商品信息，包括：

响应于所述目标命令流程处于所述发布状态，从所述目标命令流程对应的命令上下文中获取预设发布策略；

根据所述预设发布策略和所述草稿数据更新所述目标商品对应的所述商品信息。

8.根据权利要求7所述的方法，其特征在于，所述根据所述预设发布策略和所述草稿数据更新所述目标商品对应的所述商品信息，包括：

响应于所述预设发布策略为实时发布，根据所述草稿数据更新所述商品信息；

响应于所述预设发布策略为延时发布，将所述目标命令流程添加至发布队列中，所述发布队列包含至少一个处于所述发布状态的命令流程；

响应于达到所述延时发布对应的发布时间，根据所述草稿数据更新所述商品信息。

9.根据权利要求6所述的方法，其特征在于，所述响应于对草稿数据的提交操作，将所述目标命令流程对应的流程状态由编辑状态更新为审核状态之后，所述方法还包括：

获取所述目标商品对应的商品属性信息；

根据所述商品属性信息确定所述审核规则，其中，不同商品属性信息对应不同审核规则；

将所述审核规则存储在所述目标命令流程对应的命令上下文中。

10.根据权利要求1至5任一所述的方法，其特征在于，所述更新所述目标商品对应的所述商品信息之后，所述方法还包括：

响应于所述商品信息更新完成，清除草稿数据和所述目标命令流程，所述草稿数据是所述目标商品的商品更新数据。

11.一种商品数据更新装置，其特征在于，所述装置包括：

接收模块，用于接收商品数据更新请求，所述商品数据更新请求用于更新目标商品对应的商品信息，所述商品数据更新请求中包含流程属性信息，其中，不同命令流程对应不同流程属性信息；

第一确定模块，用于根据所述流程属性信息确定所述商品数据更新请求对应的目标命令流程；

更新模块，用于执行所述目标命令流程，更新所述目标商品对应的所述商品信息。

12.一种服务器，其特征在于，所述服务器包括处理器和存储器，所述存储器中存储有计算机程序，所述计算机程序由所述处理器加载并执行以实现如权利要求1至10任一所述的商品数据更新方法。

13.一种非临时性计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至10任一所述的商品数据更新方法。

Images