CN109388424A - 一种进行交互需求的方法和系统 - Google Patents

Abstract

本申请涉及互联网术领域，特别涉及一种进行交互需求的方法和系统，用以解决现有技术中存在的还没有一种对无法解决的交互需求的处理方式的问题。本申请实施例确定交互需求对应的生命周期节点和所述生命周期节点对应的规则，在确定交互需求的业务数据不符合确定的所述规则后，进行调整操作。由于可以在确定交互需求的业务数据不符合确定的规则后，进行调整操作，从而提供一种针对由于非发布者自身原因被终止或者服务质量不高的交互需求的处理方式，提高了解决这种交互需求的成功率和效率。

Description

一种进行交互需求的方法和系统

技术领域

本申请涉及互联网术领域，特别涉及一种进行交互需求的方法和系统。

背景技术

网络发布平台是发布者通过网络发布自己的产品，用户通过网络浏览产品，并通过网络进行交互的平台。

发布者在网络发布平台发布产品时都会为该产品配置产品信息。用户根据产品信息可以与网站发布平台针对一个产品发生交互行为。

除了由发布者通过网络发布自己的产品，网络发布平台还可以由发布者发布需要交互的产品，由提供产品的用户进行响应，最后由发布者从响应的用户中选择至少一个发生交互行为。

目前对于发布者发布在网络发布平台发布需要交互的产品，并由提供产品的用户进行响应的方式，一般是有两种发布方式：

第一种、发布者发布的需要交互的产品被构建到搜索引擎，提供产品的用户通过搜索引擎进行搜索；

第二种、将发布者发布的需要交互的产品推送给提供产品的用户。

当发布者在网络发布平台发布需要交互的产品后，有些交互需求可以高效的完成，而有些交互需求由于非发布者自身原因(比如没有提供产品的用户响应、响应的用户数量比较少、响应时间比较长等不确定因素)被终止或者服务质量不高(比如很长时间才完成交互需求、交互需求完成后发布者的评价不高等)。而目前还没有一种对由于非发布者自身原因被终止或者服务质量不高的交互需求的处理方式。

发明内容

本申请提供一种进行交互需求的方法和系统，用以解决现有技术中存在的还没有一种对由于非发布者自身原因被终止或者服务质量不高的交互需求的处理方式的问题。

本申请实施例提供的一种进行交互需求的方法，该方法包括：

确定交互需求对应的生命周期节点；

确定所述生命周期节点对应的规则；

若所述交互需求的业务数据不符合确定的所述规则，则进行调整操作。

本申请实施例提供的一种进行交互需求的系统，该系统包括：

周期确定模块，用于确定交互需求对应的生命周期节点；

规则确定模块，用于确定所述生命周期节点对应的规则；

处理模块，用于若所述交互需求的业务数据不符合确定的所述规则，则进行调整操作。

本申请实施例确定交互需求对应的生命周期节点和所述生命周期节点对应的规则，在确定交互需求的业务数据不符合确定的所述规则后，进行调整操作。由于可以在确定交互需求的业务数据不符合确定的规则后，进行调整操作，从而提供一种针对由于非发布者自身原因被终止或者服务质量不高的交互需求的处理方式，提高了解决这种交互需求的成功率和效率。

附图说明

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

图1为本申请实施例进行交互需求的方法流程示意图；

图2为本申请实施例倒计时的结构示意图；

图3为本申请实施例接收指令的结构示意图；

图4为本申请实施例进行交互需求的完整方法流程示意图；

图5为本申请实施例进行交互需求的系统结构示意图。

具体实施方式

本申请实施例的交互需求为发布者发布交互的对象的信息。任何能够进行交易或者非交易的对象都可以作为本申请实施例的对象，比如交易对象可以是商品、服务等；非交易对象可以是问题等，例如用户提出一个问题，这个问题从提出到被回答这个过程也是一个交互需求的过程。

以购物场景为例，如果有买家需要某个产品，可以在网络发布平台(比如淘宝，拍拍，京东，苏宁，亚马逊，ebay等零售平台，还比如1688、卓越批发网、慧聪网等批发平台)上发布该产品相关的交互需求；

销售该产品的卖家可以进行响应，比如报价等行为；

最后买家从中可以选择与进行相应的至少卖家进行交易。

每个交互需求都有至少一个生命周期节点，每个生命周期节点对应一个事件节点。不同的交互需求对应的事件节点有可能不同。

以农业类目的交互需求为例，事件节点可以包括但不限于下列中的部分或全部：

收到第一个报价、收到3个报价、报价满(比如收到10个报价)、买家查看报价、买家与供应商沟通、买家下样品单和产生订单等。

每一个事件节点对应的生命周期节点可能不同。

以农业类目的交互需求为例，一种可能的生命周期节点和事件节点对应关系如表1所示：

事件节点	收到第一个报价	收到3个报价	报价满
				生命周期节点	发布6小时	3天	7天

表1

从表1可以看出：

1、收到第一个报价对应发布6小时，即在发布6小时内需要收到第一个报价；

2、收到3个报价对应3天，即在发布3天内需要收到至少3个报价；

3、报价满对应7天，即在发布7天内需要收到报价的数量不小于报价满对应的数量。

用户发布的交互需求中会包括至少一个属性，本申请实施例可以通过交互需求中包括的属性找到该交互需求对应的生命周期节点，从而确定对应的规则。

在实施中，本申请实施例通过大量的交互需求的离线业务数据，利用分类统计等方式进行训练，从而得到属性集合和生命周期节点的第一对应关系和生命周期节点和规则的第二对应关系。

具体的，通过交互需求的离线业务数据可以获取大量交互需求中包括的属性，通过对属性的细化就可以对属性划分为多个属性集合，每个属性集合对应至少一个交互需求。

比如从大量交互需求中获取到的属性包括：用户质量、交互需求质量、类目属性、发布时间、采购数量等，之后可以选择某一单一属性或者对多种属性进行组合，从而形成属性集合。如(类目)，(类目+用户质量)都可以作为属性集合中的元素。

利用数据统计或者机器学习算法(比如决策树算法)等方式，通过对交互需求的离线业务数据分析可以获取到该交互需求所有的生命周期节点，以及每个生命周期节点对应的事件节点。

比如(a)农业类目的交互需求，60％在发布6小时后收到第一个报价，90％在24小时收到1个报价，80％在3天内收到3个报价，30％在7天内报价满(收到10个报价)。

(b)饰品类目的交互需求，80％在发布3小时后收到第一个报价，90％在6小时收到1个报价，80％在3天内收到3个报价，40％在5天内报价满。

针对不同的指标可以设定不同的规则，比如以用户满意度指标为例：

结合业务线不同的指标(如收到1个报价，收到3个报价以及报价满)和各个指标切割的百分比，就可以确定出不同的用户满意度指标。

比如表2所示：

类目	收到1个报价	收到3个报价	报价满
				农业	60％	80％	30％
饰品	80％	80％	40％

表2

根据上述内容可以产生农业类目的交互需求和饰品类目的交互需求在各个生命周期节点不同的用户满意度指标：

(a)农业类目的交互需求：

发布6小时后收到第一个报价为发布6小时这个生命周期节点对应的规则；

3天收到3个报价为3天这个生命周期节点对应的规则；

7天内报价满为7天这个生命周期节点对应的规则。

(b)饰品类目的交互需求：

发布3小时后收到第一个报价为发布3小时这个生命周期节点对应的规则；

3天收到3个报价为3天这个生命周期节点对应的规则；

5天内报价满为5天这个生命周期节点对应的规则。

以上举例中，仅涉及类目一个属性，在实际业务中，可能会包含多个属性，如来源，是否vip，是否优质用户等。因此在实际满意度指标的规则描述中可以有1个或多个属性的规则。

生命周期节点也不仅仅限于收到报价，还包括买家查看报价、产生沟通、评价、生成订单等过程。

在确定属性集合和生命周期节点的第一对应关系和生命周期节点和规则的第二对应关系后，就可以根据第一对应关系和第二对应关系，对用户提交的需求进行监测，如果根据交互需求的业务数据确定不符合某一个生命周期节点对应的规则，就可以对交互需要进行调整。

不同的交互需求以及不同的规则，对应的调整方式也可能不同。

比如：1.农业类目的交互需求：发布6小时后收到第一个报价这个生命周期节点对应的规则未满足，那么可以发送指令，通知搜索引擎，对该需求增加爆光权重，让其更容易被搜索到。

比如2.农业类目的交互需求：发布3天后收到3个报价这个生命周期节点对应的规则未满足，那么可以发送指令，通知推荐系统，进行一次APP推荐。

比如3.农业类目的交互需求：收到报价1天没查看，这个生命周期节点对应的规则未满足，那么可以发送指令，通知触答系统，进行一次邮件通知。

为了使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请作进一步地详细描述，显然，所描述的实施例仅仅是本申请一部份实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。

如图1所述，本申请实施例进行交互需求的方法包括：

步骤100、确定交互需求对应的生命周期节点；

步骤101、确定所述生命周期节点对应的规则；

步骤102、若所述交互需求的业务数据不符合确定的所述规则，则进行调整操作。

本申请实施例确定交互需求对应的生命周期节点和所述生命周期节点对应的规则，在确定交互需求的业务数据不符合确定的所述规则后，进行调整操作。由于可以在确定交互需求的业务数据不符合确定的规则后，进行调整操作，从而提供一种针对由于非发布者自身原因被终止或者服务质量不高的交互需求的处理方式，提高了解决这种交互需求的成功率和效率。

可选的，所述确定交互需求对应的生命周期节点，包括：

根据属性集合和生命周期节点的第一对应关系，确定交互需求的属性集合对应的生命周期节点；

所述确定所述生命周期节点对应的规则，包括：

根据生命周期节点和规则的第二对应关系，确定所述交互需求对应的生命周期节点对应的规则。

本申请实施例的属性为交互需求涉及的属性，包括但不限于下列中的部分或全部：

用户质量(包括用户是否vip，是否大买家，是否老用户，是否低端用户，是否活跃等)、交互需求质量(是否优质需求，或者是需求质量分来表达)、类目属性(属于什么分类，类目又可以分多层，最上层的类目为跟类目，最下层为叶子类目，如淘宝上的一级类目(又可以成为根类目)有服装，配饰，美妆和食品等；服装类目下又分为男装，女装，童装等)、发布时间、采购数量、创建类型、发布国家、是否付费需求、是否小单(需求数量小于阈值为小单)、需求状态等。

在实施中，会预先建立属性集合和生命周期节点的第一对应关系以及生命周期节点和规则的第二对应关系。

建立方式可以人工建立，也可以根据交互需求的离线业务数据建立。

如果是根据交互需求的离线业务数据建立，则需要获取交互需求的离线业务数据。

其中，交互需求的离线业务数据包括每个交互需求的事件节点、触发事件节点的时间以及交互需求涉及到的属性。

比如一个农业类目的交互需求包括但不限于下列事件节点中的部分或全部：

收到第一个报价、收到3个报价、报价满(比如收到10个报价)、买家查看报价、买家与供应商沟通、买家下样品单和产生订单等。

农业类目的交互需求包括的触发事件节点的时间可以如表3所示：

表3

从表3可以看出：交互需求的离线业务数据包括发布6小时收到第一个报价，3天收到3个报价，7天报价满，第5天第10小时买家查看报价，第8天第13小时买家与供应商沟通，第10天买家下样品单。

交互需求涉及到的属性是根据具体的交互需求确定的，比如用户质量(包括用户是否vip，是否大买家，是否老用户，是否低端用户，是否活跃等)、用户国家、交互需求质量(是否优质需求，或者是需求质量分来表达)、类目属性发布国家、是否付费需求、是否小单等。

每个交互需求的离线业务数据都包括上面类似的内容。

基于每个交互需求的离线业务数据就可以得到每类交互需求对应的属性集合。

根据每个交互需求的离线业务数据中的事件节点以及触发事件节点的时间，就可以建立第二对应关系。具体过程可以参见上面关于第二对应关系建立的描述，在此不再赘述。

建立的第二对应关系中的规则，可以包括属性+交互需求+生命周期节点+过程满意度指标。

例如：农业类目的(属性)+RFQ(交互需求)+发布6小时(生命周期节点)+收到第一个报价(事件节点)。

属性可以是一个或多个。

比如农业类目的交互需求：3个小时收到1个报价这个规则中的属性只有类目一个；

再比如vip用户发布的付费交互需求：1个小时收到1个报价这个规则中的属性有用户质量(vip用户)和付费2个；

大量规则的组合，可以将任意新来的交互需求对应出生命周期节点。例如，规则A，饰品类目下，vip买家发送的采购需求1小时内应该收到第一个报价；规则B，饰品类目下，普通买家发送的付费采购需求2小时内应该收到第一个报价；规则C，vip买家发送的采购需求1小时内应该收到第一个报价；规则D，农业类目下，买家发布的采购需求6小时内收到第一个报价；规则E，饰品类目下，vip买家发送的采购需求14天内应该有样品单。

可选的，在后续使用第一对应关系和第二对应关系时，随着获取到新的交互需求的新的业务数据，可以根据交互需求的新的离线业务数据对所述第一对应关系和所述第二对应关系进行更新。

比如最初的规则为：农业类目的交互需求，60％在发布6小时后收到第一个报价，90％在24小时收到1个报价，80％在3天内收到3个报价，30％在7天内报价满(收到10个报价)，具体可以参见表2。

经过1个月的使用后从新的业务数据中得到：农业类目的交互需求，60％在发布4小时后收到第一个报价，90％在20小时收到1个报价，80％在3天内收到3个报价，30％在6天内报价满，40％在7天内报价满(收到10个报价)。

这个结合业务线不同的指标和各个指标切割的百分比，就可以对规则进行优化：农业类目的交互需求，发布4小时后收到第一个报价，3天收到3个报价，6天内报价满。

相应的，表2的内容就可以变为表4的内容：

类目	收到1个报价	收到3个报价	报价满
				农业	60％	80％	40％
饰品	80％	80％	40％

表4

在实施中，对第一对应关系和第二对应关系进行更新时可以是实时在线进行更新，也可以是离线进行更新。

如果是实时在线进行更新，则交互需求新的业务数据就是实时获取到的业务数据；

如果是离线进行更新，则交互需求新的业务数据就是新的离线业务数据。

在实施中，可以实时对交互需求进行监控，如果有新的交互需求，可以先对交互需求的有效性进行判断。

比如要求交互需求必须有效的，或者被判断为广告、垃圾或者需求状态为审核不通过等的交互需求是无效的。

对于无效的交互需求不进入监测过程。

在交互需求有效后，就可以根据交互需求包括的属性，查找与第一对应关系中匹配的属性集合。

比如可以将包含交互需求包括的所有属性的属性集合作为匹配的属性集合。

在交互需求与属性集合进行匹配时，可能会匹配到多个属性集合。如果匹配到多个属性集合，可以针对每个属性集合都确定对应的生命周期节点并进行监测，判断是否符合对应的规则；也可以从匹配的多个属性集合中选择一个，并根据选择的属性集合判断是否符合对应的规则。

如果从匹配的多个属性集合中选择一个，可以随机选择，也可以选择匹配度最高的属性集合。比如交互需求包括属性1、属性2和属性3这三个属性，包括属性1、属性2和属性3的属性集合有属性集合A和属性集合B，其中属性集合A一共有3个属性，属性集合B一共有5个属性，则确认属性集合A匹配度最高。

如果有多个匹配度最高的属性集合，可以随机选择一个。

在确定匹配的属性集合后，根据第一对应关系就可以确定交互需求对应的生命周期节点。

之后根据第二对应关系就可以确定每个生命周期节点对应的规则。

交互需求的生命周期节点根据不同业务来确定。一般交互需求的生命周期节点包括但不限于下列过程：

发布、收到第一个报价、收到3个报价(3个以下的报价被称为零少报价)、报价满(收到10个报价)、买家查看报、买家与供应商沟通、买家下样品单，产生订单等。

以农业类目的交互需求举例，每个生命周期节点都对应一个规则：

发布4小时后收到第一个报价；

发布3天收到3个报价；

发布7天内报价满；

收到报价1天内查看报价；

收到报价2天内产生沟通；

收到报价7天产生样品单；

收到报价30天产生订单。

根据获取的当前的生命周期节点对应的业务数据就可以判断是否符合当前的生命周期节点对应的规则，如果不符合就需要对所述交互需求进行调整操作。

具体判断是否符合当前的生命周期节点对应的规则的方式有两种，下面分别进行介绍。

方式一、在生命周期节点到达后，获取所述交互需求的业务数据，并判断所述交互需求的业务数据是否符合确定的所述规则。

这种方式可以参见图2。

图2中包括四部分。

第一部分是规则决策部分：

该部分生成第一对应关系和第二对应关系。

第二部分是决策实施部分：

该部分在有新的交互需求后，会对新的交互需求有效性进行判断，如果符合要求，则通过第一部分获得交互需求的每个生命周期节点；

确定当前的生命周期节点，并进行倒计时。

第三部分是指令分发部分：

该部分通过第一部分获得交互需求的对应的规则；

在倒计时结束(即当前的生命周期节点到达)后从存储业务数据的实体中获取交互需求对应的业务数据；

从获取的业务数据中查找当前的生命周期节点对应的业务数据，并判断当前的生命周期节点对应的业务数据是否符合当前的生命周期节点对应的规则；

如果符合，则继续监测下一个生命周期节点；

否则确定需要调整的操作所属的系统，向确定的系统发送指令，以使对应的系统根据收到的指令进行调整操作。

比如当前的生命周期节点发布6小时，对应的规则是发布6小时收到第一个报价，基于发布6小时进行倒计时，在发布6小时后获取业务数据。

获取的业务数据包括已经发生的生命周期节点的业务数据，从中找到当前生命周期节点的业务数据，从中可以查看到收到第一个报价的时间，如果超过6个小时，说明不符合对应的规则；如果未超过6个小时，说明符合对应的规则。

如果当前的生命周期节点不符合对应的规则，在对交互需求进行调整操作的同时可以继续监测下一个生命周期节点。

具体向哪个系统发送进行哪个或者哪些方面的调整是根据具体的交互需求以及生命周期节点确定的。

比如农业类目的交互需求，发布4小时后收到第一个报价。那么针对每个符合农业类目的交互需求，在4小时这个生命周期节点结束时，会检查其服务情况，是否收到第一个报价。根据服务情况，可能会产生一下两种处理方案：

如果收到报价，那么表示对这个交互需求符合要求，进入监听生命周期节点下一阶段。

如果没有收到1个报价，说明对这个交互需求需要加强。这种情况的指令包括两部分：

1.发送指令来提升服务，如通知推荐系统，进行一次额外的推荐给供应商，和/或通知搜索系统，增加爆光权重等。

2.指令变更生命周期节点状态。这里可以根据业务不同进行选择，一是生命周期节点仍然停留在当前节点，直到完成该节点的满意度指标才进入下一周期；二是直接进入下一个生命周期节点。

第四部分是其他系统部分：

该部分包括至少一个系统，用于在接收到指令后对对应的需求业务进行调整操作。

方式二、在接收到来自其他系统的所述交互需求的业务数据后，判断所述交互需求的业务数据是否符合确定的所述规则。

这种方式可以参见图3。

图3中包括四部分。

第一部分是规则决策部分：

该部分生成第一对应关系和第二对应关系。

第二部分是决策实施部分：

该部分在有新的交互需求后，会对新的交互需求有效性进行判断，如果符合要求，则通过第一部分获得交互需求的每个生命周期节点和对应的规则；

在接收到其他系统发送的交互需求的业务数据后，从收到的业务数据中获取交互需求对应的业务数据；

从获取的业务数据中查找当前的生命周期节点对应的业务数据，并判断当前的生命周期节点对应的业务数据是否符合当前的生命周期节点对应的规则；

如果符合，则继续监测下一个生命周期节点；

否则确定需要调整的操作所属的系统，向确定的系统发送指令，以使对应的系统根据收到的指令进行调整操作。

比如当前的生命周期节点发布6小时，对应的规则是发布6小时收到第一个报价，基于发布6小时进行倒计时，在发布6小时后获取业务数据。

其他系统在交互需求的业务数据发生变化后就可以发送业务数据，比如收到第一个报价就可以发送业务数据；

收到的业务数据包括已经发生的生命周期节点的业务数据，从中找到当前生命周期节点的业务数据，从中可以查看到收到第一个报价的时间，如果超过6个小时，说明不符合对应的规则；如果未超过6个小时，说明符合对应的规则。

如果当前的生命周期节点不符合对应的规则，在对交互需求进行调整操作的同时可以继续监测下一个生命周期节点。

具体向哪个系统发送进行哪个或者哪些方面的调整是根据具体的交互需求以及生命周期节点确定的。

比如农业类目的交互需求，发布4小时后收到第一个报价。那么针对每个符合农业类目的交互需求，在4小时这个生命周期节点结束时，会检查其服务情况，是否收到第一个报价。根据服务情况，可能会产生一下两种处理方案：

如果收到报价，那么表示对这个交互需求符合要求，进入监听生命周期节点下一阶段。

如果没有收到1个报价，说明对这个交互需求需要加强。这种情况的指令包括两部分：

1.发送指令来提升服务，如通知推荐系统，进行一次额外的推荐给供应商，和/或通知搜索系统，增加爆光权重等。

2.指令变更生命周期节点状态。这里可以根据业务不同进行选择，一是生命周期节点仍然停留在当前节点，直到完成该节点的满意度指标才进入下一周期；二是直接进入下一个生命周期节点。

第四部分是其他系统部分：

该部分包括至少一个系统，用于发送交互需求的业务数据，以及在接收到指令后对对应的需求业务进行调整操作。

下面以上述方式一为例详细介绍下本申请实施例的流程，方式二与方式一类似，在此不再赘述。

如图4所示，本申请实施例进行交互需求的完整方法包括：

步骤400、获取新的交互需求。

步骤401、判断获取的交互需求是否需要处理，如果是，则执行步骤402，否则，跳出本流程。

步骤402、从所有属性集合中，确定与交互需求匹配的属性集合。

步骤403、根据属性集合和生命周期节点的第一对应关系，确定与交互需求匹配的属性集合对应的生命周期节点。

步骤404、根据生命周期节点和规则的第二对应关系，确定所述交互需求的生命周期节点中当前的生命周期节点对应的规则。

步骤405、从所有生命周期节点中确定当前需要监测的生命周期节点。

步骤406、在生命周期节点到达后，获取所述交互需求的业务数据。

步骤407、判断所述交互需求的业务数据是否符合确定的所述规则，如果是，则执行步骤408；否则，执行步骤409。

步骤408、判断交互需求对应的生命周期节点中是否还有未检测的生命周期节点，如果是，则返回步骤406；否则，跳出本流程。

步骤409、确定需要调整的操作所属的系统。

步骤410、向确定的系统发送指令，以使对应的系统根据收到的指令进行调整操作，并执行步骤408。

基于同一发明构思，本申请实施例中还提供了一种进行交互需求的系统，由于该系统解决问题的原理与本申请实施例进行交互需求的方法相似，因此该系统的实施可以参见方法的实施，重复之处不再赘述。

如图5所述，本申请实施例进行交互需求的系统包括：

周期确定模块500，用于确定交互需求对应的生命周期节点；

规则确定模块501，用于确定所述生命周期节点对应的规则；

处理模块502，用于若所述交互需求的业务数据不符合确定的所述规则，则进行调整操作。

可选的，所述周期确定模块500具体用于：

根据属性集合和生命周期节点的第一对应关系，确定交互需求的属性集合对应的生命周期节点；

所述规则确定模块501具体用于：

根据生命周期节点和规则的第二对应关系，确定所述交互需求对应的生命周期节点对应的规则。

可选的，所述第一对应关系和所述第二对应关系是根据交互需求的离线业务数据确定的。

可选的，所述系统还包括：

更新模块503，用于根据交互需求新的业务数据对所述第一对应关系和所述第二对应关系进行更新。

可选的，所述处理模块502还用于：

在生命周期节点到达后，获取所述交互需求的业务数据，并判断所述交互需求的业务数据是否符合确定的所述规则；或

在接收到来自其他系统的所述交互需求的业务数据后，判断所述交互需求的业务数据是否符合确定的所述规则。

可选的，所述处理模块502具体用于：

确定需要调整的操作所属的系统；

向确定的系统发送指令，以使对应的系统根据收到的指令进行调整操作。

图5中的各个模块可以有设置在一个设备中，也可以设置在多个设备中。一个模块的功能可以由一个设备实现，也可以由多个设备实现。

本申请实施例还提供一种存储介质，该存储介质可以是非易失性的，即断电后内容不丢失。该存储介质中存储软件程序，该软件程序在被一个或多个处理器读取并执行时可实现本申请实施例上面任何一种调用数据的方案。

该存储介质可以通过外部接口或内部接口与处理器连接。比如存储器是U盘、移动硬盘等，则可以通过外部接口连接；比如存储器是处理器所在的设备中的存储模块，则可以通过内部接口连接。

以上参照示出根据本申请实施例的方法、装置(系统)和/或计算机程序产品的框图和/或流程图描述本申请。应理解，可以通过计算机程序指令来实现框图和/或流程图示图的一个块以及框图和/或流程图示图的块的组合。可以将这些计算机程序指令提供给通用计算机、专用计算机的处理器和/或其它可编程数据处理装置，以产生机器，使得经由计算机处理器和/或其它可编程数据处理装置执行的指令创建用于实现框图和/或流程图块中所指定的功能/动作的方法。

相应地，还可以用硬件和/或软件(包括固件、驻留软件、微码等)来实施本申请。更进一步地，本申请可以采取计算机可使用或计算机可读存储介质上的计算机程序产品的形式，其具有在介质中实现的计算机可使用或计算机可读程序代码，以由指令执行系统来使用或结合指令执行系统而使用。在本申请上下文中，计算机可使用或计算机可读介质可以是任意介质，其可以包含、存储、通信、传输、或传送程序，以由指令执行系统、装置或设备使用，或结合指令执行系统、装置或设备使用。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (12)

1.一种进行交互需求的方法，其特征在于，该方法包括：

确定交互需求对应的生命周期节点；

确定所述生命周期节点节点对应的规则；

若所述交互需求的业务数据不符合确定的所述规则，则进行调整操作。

2.如权利要求1所述的方法，其特征在于，所述确定交互需求对应的生命周期节点，包括：

根据属性集合和生命周期节点的第一对应关系，确定交互需求的属性集合对应的生命周期节点；

所述确定所述生命周期节点对应的规则，包括：

根据生命周期节点和规则的第二对应关系，确定所述交互需求对应的生命周期节点对应的规则。

3.如权利要求2所述的方法，其特征在于，所述第一对应关系和所述第二对应关系是根据交互需求的离线业务数据确定的。

4.如权利要求3所述的方法，其特征在于，该方法还包括：

根据交互需求新的业务数据对所述第一对应关系和所述第二对应关系进行更新。

5.如权利要求1所述的方法，其特征在于，所述确定所述生命周期节点对应的规则之后，还包括：

在生命周期节点到达后，获取所述交互需求的业务数据，并判断所述交互需求的业务数据是否符合确定的所述规则；或

在接收到来自其他系统的所述交互需求的业务数据后，判断所述交互需求的业务数据是否符合确定的所述规则。

6.如权利要求1所述的方法，其特征在于，所述进行调整操作，包括：

确定需要调整的操作所属的系统；

向确定的系统发送指令，以使对应的系统根据收到的指令进行调整操作。

7.一种进行交互需求的系统，其特征在于，该系统包括：

周期确定模块，用于确定交互需求对应的生命周期节点；

规则确定模块，用于确定所述生命周期节点对应的规则；

处理模块，用于若所述交互需求的业务数据不符合确定的所述规则，则进行调整操作。

8.如权利要求7所述的系统，其特征在于，所述周期确定模块具体用于：

根据属性集合和生命周期节点的第一对应关系，确定交互需求的属性集合对应的生命周期节点；

所述规则确定模块具体用于：

根据生命周期节点和规则的第二对应关系，确定所述交互需求对应的生命周期节点对应的规则。

9.如权利要求8所述的系统，其特征在于，所述第一对应关系和所述第二对应关系是根据交互需求的离线业务数据确定的。

10.如权利要求9所述的系统，其特征在于，所述系统还包括：

更新模块，用于根据交互需求新的业务数据对所述第一对应关系和所述第二对应关系进行更新。

11.如权利要求7所述的系统，其特征在于，所述处理模块还用于：

在生命周期节点到达后，获取所述交互需求的业务数据，并判断所述交互需求的业务数据是否符合确定的所述规则；或

在接收到来自其他系统的所述交互需求的业务数据后，判断所述交互需求的业务数据是否符合确定的所述规则。

12.如权利要求7所述的系统，其特征在于，所述处理模块具体用于：

确定需要调整的操作所属的系统；

向确定的系统发送指令，以使对应的系统根据收到的指令进行调整操作。