CN106878043A - 一种业务处理方法和装置 - Google Patents

Abstract

本发明提供一种业务处理方法和装置，其中方法包括：接收业务对象请求，所述业务对象请求携带：请求方的属性信息；获取至少一个业务对象的对象信息，每个业务对象的所述对象信息包括：对应所述业务对象的预配置的业务条件；分别对每个所述业务对象，根据对应所述业务条件的校验模块，校验所述请求方的属性信息是否满足所述业务对象对应的业务条件；当校验结果为满足时，将所述业务对象提供至所述请求方。本发明提高了业务处理的效率。

Description

一种业务处理方法和装置

技术领域

本发明涉及网络技术，特别涉及一种业务处理方法和装置。

背景技术

随着网络技术的发展，很多业务通过网络来发布，其中存在如下一种类型的业务：该业务可以向用户展示至少一种业务对象，例如，该业务对象可以是提供给用户的产品；用户可以由上述展示的业务对象中选择一种，申请对选中的业务对象执行处理，例如可以是购买该产品。

在这种类型的业务中，并不是所有的业务对象用户都可以自由选择，通常业务对象的提供者会设置一定的业务条件。例如，对于某一种业务对象来说，只能向特定类型的用户展示。业务提供者可以为某一种待提供的业务对象设定一套对应该业务对象的业务处理流程，比如，用于向用户展示的前端在提交对象展示请求时，直接携带固定的业务对象标识，请求展示特定的业务对象；而负责业务提供的后端可以校验预设的业务条件，并在条件满足时将对象信息反馈给前端展示。这种方法存在如下缺点：当业务条件改变时，例如用户条件变更，则需要修改业务流程，或者当上线一个新的业务对象时，也需要配置对应该对象的处理流程，这使得业务处理相对比较繁琐，影响了业务发布的效率。

发明内容

有鉴于此，本发明提供一种业务处理方法和装置，以提高业务处理的效率。

具体地，本发明是通过如下技术方案实现的：

第一方面，提供一种业务处理方法，所述方法包括：

接收业务对象请求，所述业务对象请求携带：请求方的属性信息；

获取至少一个业务对象的对象信息，每个业务对象的所述对象信息包括：对应所述业务对象的预配置的业务条件；

分别对每个所述业务对象，根据对应所述业务条件的校验模块，校验所述请求方的属性信息是否满足所述业务对象对应的业务条件；

当校验结果为满足时，将所述业务对象提供至所述请求方。

第二方面，提供一种业务处理装置，所述装置包括：

请求接收模块，用于接收业务对象请求，所述业务对象请求携带：请求方的属性信息；

信息获取模块，用于获取至少一个业务对象的对象信息，每个业务对象的所述对象信息包括：对应所述业务对象的预配置的业务条件；

条件校验模块，用于分别对每个所述业务对象，根据对应所述业务条件的校验模块，校验所述请求方的属性信息是否满足所述业务对象对应的业务条件；

对象提供模块，用于当校验结果为满足时，将所述业务对象提供至请求方。

本发明实施例的业务处理方法和装置，通过设置业务对象对应的业务条件是可配置的，每个业务对象都可以选择使用哪个条件作为业务条件，该方法使得当条件变更时，只要选择该条件对应的校验模块校验即可，即使新增一个业务对象，也只要选择配置的业务条件，就可以根据该业务条件进行校验，从而提高了业务处理的效率。

附图说明

图1为本发明实施例提供的一种业务场景示意图；

图2为本发明实施例提供的一种业务处理方法的流程图；

图3为本发明实施例提供的一种金融产品展示购买的系统架构图；

图4为本发明实施例提供的一种业务处理方法的流程图；

图5为本发明实施例提供的一种业务处理装置的结构示意图；

图6为本发明实施例提供的另一种业务处理装置的结构示意图。

具体实施方式

图1示例了一种业务提供的场景，该图1所示的场景中，可以包括服务端11和客户端12，服务端11作为业务对象的提供者，向客户端提供的业务对象可以是一种产品。而客户端12可以是用户13接收该业务对象的设备，例如该客户端可以运行在一台电脑或者一部智能移动设备上，且通过其运行所在设备的屏幕显示服务端提供的产品，比如可以显示该产品的产品介绍信息，或者显示用户购买该产品的产品购买信息等。

在具体的业务实现时，服务端11对业务对象的提供通常会设置一定的业务条件，比如限定只能向特定类型的用户提供某种业务对象；并且，业务条件还可能进行变更，比如，一段时间内向一种类型的用户提供某业务对象，而在另一段时间内该业务对象又变更为向另一种类型的用户提供，这可以根据业务需求而定。还可能出现的情况是，服务端11能够提供的业务对象的数量可以多于一种，并且还可以增加一种新的业务对象，或者删除一种业务对象不再提供。

上面所描述的情况，都涉及到业务对象提供的变化，本申请实施例的业务处理方法，将用于实现在业务对象变化时(包括条件的变更、或者对象的增删)，能够提高业务变更的效率，比如，可以在改变业务条件后，仍然能够较快的向用户提供变更后的业务对象。此外，图1的场景只是一种示例，该方法的应用不局限于该场景的架构。

图2示例了一种业务处理方法，该方法例如可以由图1的服务端执行，服务端可以按照该方法向客户端提供业务对象。如图2所示，该方法可以包括：

在步骤201中，接收业务对象请求，该请求携带：请求方的属性信息。

例如，当用户点击客户端中的某个选项时，可以触发客户端向服务端发送业务对象请求，该请求可以是请求服务端提供产品的产品介绍信息，以供用户参考是否购买该产品。或者，业务对象请求还可以是当用户决定购买展示的某产品时触发，那么该请求用于指示服务端处理用户对该产品的本次购买，并向用户反馈产品购买信息，比如是否购买成功等。

本步骤中，业务对象请求中携带的请求方的属性信息，例如，请求方的该属性信息可以包括：用户的用户标识(比如可以是用户账号)，该用户是请求对象的用户，还可以包括客户端的客户端标识(也可以将客户端称为一种平台，多种平台可以展示该产品)，该客户端是用户查看产品所使用的客户端，或者说业务对象展示所在的客户端。请求中还可以包括其他信息，不再列举。

在步骤202中，获取至少一个业务对象的对象信息，每个业务对象的所述对象信息包括：对应所述业务对象的预配置的业务条件。

例如，本步骤中的预配置的业务条件，可以包括多种条件，比如，根据业务需求，假设一种业务对象只能提供给特定级别的用户，或者提供给特定的客户端，那么该特定级别的用户或特定客户端都可以作为业务条件，满足该条件才提供业务对象。此外，对象信息中还可以包括其他信息，比如可以包括对象提供信息，该对象提供信息可以是产品介绍信息、产品购买信息等。

本步骤中，业务条件可以是预配置的，这里的预配置指的是，由预先设定的多种条件中选择至少一种条件作为对应某个业务对象的业务条件。例如，仍以用户级别和客户端的限定为例，假设预先设定有五种用户级别和三种客户端类型，对于一种业务对象，可以选择上述五种用户级别中的其中三种级别、以及上述三种客户端类型中的一种客户端，作为业务条件，即满足该选择的三种级别之一的用户且为所选定的客户端时，才能向其提供业务对象。

在步骤203中，分别对每个所述业务对象，根据对应所述业务条件的校验模块，校验所述请求方的属性信息是否满足所述业务对象对应的业务条件。

本步骤中，对应业务对象的业务条件的校验过程，也可以是预先配置的。比如，预先设定有五种用户级别和三种客户端类型，那么每种用户级别和客户端类型，都可以预先设定对应的校验模块，该校验模块中包括了如何校验的处理限定，可以通过该模块校验业务条件。

在步骤204中，当校验结果为满足时，将业务对象提供至所述请求方。

本步骤中，当满足业务条件时，比如，请求方的用户级别是业务条件中包括的允许提供业务对象的用户级别，则将业务对象提供至请求方，比如可以将对象提供信息发送至请求方。例如，服务端可以将对象提供信息发送给客户端，由客户端将该信息展示给用户。

本例子的业务处理方法，业务对象对应的业务条件是可配置的，每个业务对象都可以选择使用哪个条件作为业务条件，该方法使得当条件变更时，只要选择该条件对应的校验模块校验即可，即使新增一个业务对象，也只要选择配置的业务条件，就可以根据该业务条件进行校验，业务处理的效率较高。

如下将本申请实施例的业务处理方法，应用于金融产品的展示和购买为例。本例子中，服务端提供的业务对象可以是一种理财产品，例如，一种“短期定期理财”品种，期限为1个月内，年化收益率为6％，起购金额为1000元。服务端向客户端提供该业务对象时，可以包括两个步骤，用户可以先通过客户端请求服务端展示理财产品，服务端通过校验将该用户能够购买的理财产品的产品介绍信息提供给客户端进行显示，使得用户了解该产品；当用户确定购买该产品时，再通过客户端向服务端提交购买请求，服务端可以向用户提供购买成功或失败的相关提示信息。

假设服务端可以提供的理财产品有多种，不同的理财产品具有不同的收益率和起购金额等参数，并且，不同的理财产品可以提供给不同的用户购买，购买的条件也不同，比如，理财产品提供的数量有限，用户需要去抢占名额，抢到后才可以购买该产品，服务端可以设定每天的理财产品申购名额，且限定每个用户每天只有一次机会抢占。基于上述，服务端可以设定“活动”，活动中包括对应的理财产品以及用户的购买条件。

例如，一个“活动”可以是：

“短期定期理财”品种，期限为1个月内，年化收益率为6％，起购金额为1000元；该品种提供给某客户端的新注册用户；每天的限量名额是10名，每个用户一天一次机会抢占。

又例如，另一个“活动”可以是：

“短期定期理财”品种，期限为2个月内，年化收益率为7％，起购金额为2000元；该品种提供给某客户端的老用户；每天的限量名额是20名，每个用户一天两次机会抢占。

服务端可以将当前能够提供的活动的活动编码，记录在“对象标识配置文件”中，如下表1示例了该文件中记录的部分活动编码，但具体实施中不限制活动编码的记录方式。该活动编码可以称为“业务对象的对象标识”，因为不同的活动可以对应一种理财产品，也可以用该产品的标识作为活动编码：

表1对象标识配置文件

活动编码
	123a
234b

上述的对象标识配置文件可以存储在一个文件存储位置，比如文件服务器中；当服务端上线一个活动时，可以在该配置文件中增加对应的活动编码，当服务端下线一个活动时，可以将该活动的活动编码由配置文件中删除，该对象标识配置文件中的活动编码对应的各个活动，可以是当前已经上线的能够向用户提供的活动。该配置文件的使用在后续实施例将说明。

此外，不同的活动具有不同的提供条件，例如，上述例子中理财品种限定只能提供给特定客户端的特定用户，只要该类用户才可以在客户端中看到展示的理财品种并进行申购，服务端不会向其他客户端或其他客户展示或接受申购。本例子中设置了业务对象对应的业务条件，例如，可以是理财产品对应的“用户级别”或“平台标识”，这里的平台标识比如可以是A客户端或者B客户端。

本实施例对用户级别进行了细致的划分，以下示例一种划分方式，其中，如下的a、b等分别作为一种级别的标识，对应的描述可以是该级别的定义：

a)A客户端的新用户：在A客户端尚未进行过预约申请和主动购买的用户；

b)B客户端的新用户：在B客户端尚未进行过预约申请的用户；

c)新用户：不区分来源平台(可以是A客户端或B客户端)，用户从未进行过预约申请或主动购买。

d)准用户：不区分来源平台(可以是A客户端或B客户端)，用户进行过预约申请，但尚未撮合交易成功。

e)一级老用户：不区分来源平台(可以是A客户端或B客户端)，用户仅存在一笔撮合或主动购买交易成功的订单。

f)活动新用户：不区分来源平台(可以是A客户端或B客户端)，用户从未参与过该活动或活动申请未成交。

如上所述，业务条件中的用户级别或平台标识，可以预先设置几种，每次增加一个新的活动时，可以对应该活动去配置对应的业务条件。假设上述的几种用户级别可以标识为：a、b、c、d、e、f，将平台标识设定为A、B。

举例如下：假设当前要上线一个活动，该活动对应的业务对象是一种定期理财产品，根据业务需求，该理财产品只能提供给B客户端的新用户，即只能是B客户端的新用户才可以在B客户端看到该理财产品的活动展示，才可以申购该产品，其他用户或其他客户端不能展示或购买。如下的表2，示例一种对该业务对象的业务条件的配置：

表2业务条件的配置

上述例子中，例如，可以用“1”标识选择该条件，用“0”表示不选择该条件。由表2可以看到，活动123a提供的理财产品，只能在B平台展示，并且只能提供给b级别的用户。其中，可以将“1”标识的允许提供业务对象的用户级别称为目标用户级别，则该目标用户级别是由预设的多个用户级别中选择出的用户级别。同样，可以将“1”标识的允许提供业务对象的平台标识称为目标平台标识，则该目标平台标识是由预设的多个平台标识中选择出的平台标识。每一个活动都可以按照类似的方式进行业务条件的配置，此外，本例子的业务条件是以用户级别和平台标识为例，但具体实施中并不局限于此，可以根据实际业务需求设定。

图3示例一种对应上述的金融产品展示购买的系统架构图，如图3所示，客户端侧可以包括A客户端和B客户端这两种，用于进行活动的展示，以及活动申请的提交，是用户进行操作的终端设备侧。服务端可以分成两个部分，一个部分是门户中心，另一个部分是活动中心。

上述对业务条件中的用户级别和平台标识的配置，可以在图3的活动中心部分的“活动管理”模块进行，条件配置的操作可以是业务人员根据业务需求进行配置和修改，或者也可以支持根据业务信息进行自动化配置。此外，活动的新上线或下线也可以通过该活动管理模块进行，比如可以在对象标识配置文件中增加活动编码或删除活动编码。

配置完成的活动，比如表2所示的配置业务条件，可以存储在图3中的活动中心部分的“业务条件”模块；当“活动服务”模块接收到对于条件的查询请求时，可以由该“业务条件”模块中获取到对应某个业务对象的业务条件。活动中心的“名额控制”和“活动数据统计”可以用于校验用户的申购次数，产品的限额等方面，满足该条件才可以允许用户购买该产品。

而图3中的门户中心部分，可以负责活动中心与客户端之间的对接，比如，客户端发送的请求展示或购买的业务对象请求，可以被门户中心接收，例如可以被门户中心的“活动展示处理”接收，门户中心可以去活动中心获取校验业务条件所需要的信息，并进行业务条件的校验，在校验通过后，将业务对象的对象提供信息，比如产品介绍信息或申购成功信息等，提供给客户端。

如下结合图3的系统图和图4的流程图，描述一次用户查看和申购某个理财产品的流程：

在步骤401中，客户端向门户中心发送业务对象请求，该业务对象请求中可以携带请求方的属性信息。

例如，可以是用户在客户端的显示界面上点击了某个触发选项，触发客户端向服务端的门户中心发送了业务对象请求。本次的业务对象请求用于请求服务端提供对于理财产品的展示，比如，服务端可以将产品介绍信息(如，理财产品的年收益率，最低金额等)发送至客户端，以供用户了解该产品。

本步骤中，请求中可以携带请求方的属性信息，该属性信息可以包括：用户账号，比如用户可以以注册的账号登录客户端，触发客户端发送业务对象请求，则请求中携带该用户账号。属性信息还可以包括：平台标识，比如，本次的请求是A客户端发送，则可以携带A客户端的标识。

结合图3的系统图来看，A客户端可以将业务对象请求发送至门户中心的活动展示处理模块，该活动展示处理模块在接收到请求后，可以继续执行402。

在步骤402中，门户中心获取至少一个业务对象的对象标识。

例如，步骤401中的业务对象请求中可以携带：对象标识配置文件的存储地址。门户中心的活动展示处理模块可以根据该存储地址，获取到对象标识配置文件，得到该文件中包括的至少一个业务对象的对象标识。假设文件中包括了三种对象标识，123a、234b、345c，如前所述的，该对象标识可以是活动编码，当然该活动编码可以对应一种理财产品，也可以作为理财产品的标识。

在步骤403中，门户中心根据对象标识，调用活动查询服务，请求获取对象标识对应的对象信息。

对于在步骤402中获取到的至少一种活动编码，门户中心对每个活动编码都要校验下是否允许将该编码对应的活动信息提供给用户展示。例如，本例子中的对象标识配置文件中有三种活动编码，这三种活动编码可以是当前已经上线的活动，但是当前登录的发送业务对象请求的用户，是否能够查看或购买该活动对应的理财产品，还需要根据业务需求的设定，如果某个活动对应的理财产品只能提供给B客户端的一级用户，那么当前发送请求的A客户端的用户是不能查看和购买的。因此，门户中心要分别对每个活动编码对应的活动都进行校验，以确定是否将活动对应的理财产品信息提供给客户端展示。

本步骤中，门户中心的活动展示处理模块，可以调用活动中心的活动服务模块，进行活动信息的查询，查询时可以携带活动编码，以使得活动中心知道要查询的是哪个活动。例如，查询时将上述三个活动编码都携带上。

在步骤404中，活动中心将对象标识对应的对象信息返回给门户中心。

本步骤中，活动中心的活动服务模块接收到门户中心的查询请求后，将各个活动编码分别对应的对象信息返回给门户中心。例如表3所示：

表3对象标识对应的对象信息

活动编码	对象提供信息	预配置的业务条件
			123a	收益率6％、起购金额1000	b；A客户端；
234b	收益率7％、起购金额2000	a、b；B客户端

上述的表3只是一种示例。活动中心可以根据活动编码，查询对应该编码的预配置的业务条件和对象提供信息，在对象展示流程中，其中的对象提供信息可以是用于用户了解理财产品的一些产品介绍信息；业务条件可以包括用户级别(例如，b级别)和平台标识(例如，A客户端)，活动中心可以根据表2得到该业务条件。

在步骤405中，门户中心分别对每个业务对象，都校验请求方的属性信息是否满足业务条件的限定。

例如，仍以用户级别和平台标识这两个条件为例，每一种活动都包括这两个条件，门户中心可以分别对每个活动进行校验，判断请求方的属性信息是否满足该活动的业务条件。比如，属性信息中包括平台标识，例如A客户端的标识，那么门户中心可以检查该标识是否是预配置的业务条件中允许的平台标识。又比如，属性信息中可以包括用户账号，那么可以获取该用户账号对应的同一身份下的所有账号，查询这些账号是否存在预约单，以前是否进行过预约或购买等历史记录，从而判断该用户是新用户或老用户，并可以结合用户所在的客户端，确定用户所属的级别。

以表3中的活动编码123a对应的活动为例，该活动对应的业务条件包括“b—A客户端”，那么门户中心可以根据步骤401接收到的业务对象请求中的属性信息，查看平台是否是A客户端，用户级别是否是b级别。如果都满足则表示校验通过，可以将该活动编码对应的对象提供信息发送至客户端展示给用户。

每一个活动，门户中心都分别进行上述的校验。此外，本例子中，门户中心执行上述校验可以是通过预先配置的与业务条件对应的校验模块。举例如下：假设用户级别有a至f六个级别，每一个级别可以称为该业务条件中的一个子条件，门户中心可以分别为每个子条件设置一个对应的校验器，用于校验该子条件是否满足。比如，a级别对应的校验器用于校验a级别定义的条件是否满足，b级别对应的校验器用于校验b级别定义的条件是否满足。这种原子型的校验，具有比较好的可扩展性，比如，当新定义了一种用户级别时，主要增加该级别对应的校验器即可。还可以将校验器改为拦截器方式实现，对于不同的用户级别，调用不同的方法，为每个方法配置对应的拦截器。

在步骤406中，将通过校验的对象信息加入反馈对象列表。

例如，门户中心在校验每个活动的业务条件后，将通过校验的活动对应的对象信息加入反馈对象列表中。这里的对象信息可以是对象提供信息，比如表3示例的理财产品的产品介绍信息。此外，门户中心可以在对某一个活动校验完成后，如果校验通过将该活动加入反馈对象列表，然后再继续校验下一个活动；或者，也可以是待所有活动都校验完成后，将通过校验的对象信息加入列表。

在步骤407中，门户中心将校验结果为满足的业务对象的对象提供信息，发送至所述请求方。

例如，请求方所在的A客户端，可以在显示界面上展示多种理财产品的产品信息，供用户了解查看。这些展示的产品都是门户中心校验过的允许提供给用户的产品。客户端展示的产品可以为至少一种。

用户在了解了展示的产品后，可以选择至少一种产品进行申购。此时将进行图4所示的申购流程。在申购时，同样要进行一些校验操作，比如，某个理财产品每天的限量申购名额是20名，每个用户一天限两次机会抢占，那门户中心可以校验该用户的当天抢占次数是否达到两次，产品的申购名额是否已经足够等。如图4所示，活动中心可以存储一些名额控制的活动规则，比如限量名额是20名，还可以存储一些活动统计数据，比如当前的产品名额已经占用了多少，剩余名额的数量，用户已经参加活动的次数等，门户中心在接收到用户的申请请求时，可以由活动中心获取上述的活动规则和活动统计数据，并由门户中心的抢购前置校验模块来校验用户是否能够进行本次申购。

在步骤408中，客户端进行活动提交，请求申购某个理财产品。

例如，本步骤的活动提交，可以是用户对选中的理财产品进行申请请求，也可以称为业务对象请求，不过本次请求的目的是申购该产品。本步骤的请求也可以携带请求方的属性信息，在后续步骤中，门户中心可以再进行一次业务条件的校验，以确保安全性。

不同于步骤401的地方在于，步骤401中可以携带对象标识配置文件的存储地址，以用于门户中心得到文件中的多个对象标识并进行分别校验；而本步骤的请求中，由于用户已经选择了特定的理财产品，因此只要携带用户选中的理财产品对应的对象标识即可。

在步骤409中，门户中心请求获取对象标识对应的对象信息。

例如，门户中心可以根据步骤408中携带的对象标识，去活动中心获取该标识对应的对象提供信息、预配置的业务条件等。其中的业务条件同样可以包括预配置的用户级别和平台标识；对象提供信息可以包括：活动申购成功或失败的结果信息；对象信息中还可以包括：本次活动的剩余名额、活动金额等活动规则，以用于门户中心校验申购的条件是否满足。

在步骤410中，活动中心将对象信息返回给门户中心。

在步骤411中，门户中心校验活动规则是否满足。

例如，门户中心可以再进行一次用户级别、平台标识的条件是否满足，并且还校验用户的身份信息、活动的限额是否达到、剩余名额是否足够、用户参加活动的次数是否已经达到上限等，以确定用户是否允许参见本次申购。

如果校验通过，用户有条件申购，则门户中心可以执行411。

在步骤412中，门户中心向活动中心申请活动抢购，为用户抢占活动名额。

在步骤413中，活动中心向门户中心返回抢占结果。

本步骤的结果可以是用户抢占成功，即申购成功，则活动中心可以创建活动预约单，等待撮合；或者，抢占结果也可能是抢占失败。

在步骤414中，门户中心向客户端返回活动提交结果，以告知用户本次申购成功或失败。

本例子的业务处理方法，业务对象对应的业务条件是可配置的，每个业务对象都可以选择使用哪个条件作为业务条件，该方法使得当条件变更时，只要选择该条件对应的校验模块校验即可，即使新增一个业务对象，也只要选择配置的业务条件，就可以根据该业务条件进行校验，业务处理的效率较高。

该方法可以快速的进行业务对象的变更，比如业务条件的变更或者对象的增删。例如，假设业务条件有所变更，允许提供的用户级别由b级别调整为c和d级别，那么可以在图3的活动中心的活动管理模块进行下配置修改即可，然后等门户中心再次接收到客户端的业务对象请求时，活动中心可以将更新后的业务条件返回给门户中心，门户中心侧已经预先配置好了对应业务条件的校验模块，则通过与更新后的业务条件对应的校验模块进行校验处理即可。这种方式不需要再修改框架或代码，能够做到对活动变更的快速响应。

假设服务端新增了一个业务对象，则同样可以在在图3的活动中心的活动管理模块进行配置，配置该新增业务对象对应的业务条件；并且将该新增业务对象也增加进对象标识配置文件中，这样当门户中心再次接收到客户端的业务对象请求时，根据文件地址获取的对象标识配置文件中已经包括进了新增业务对象的对象标识，活动中心就可以将该新增业务对象对应的业务条件返回给门户中心，由业务中心进行校验。该方法对业务对象变更具有较强的适应性。

为了实现上述的方法，本申请实施例还提供了一种业务处理装置，该装置可以应用于例如图1所示的服务端。图5示例了该装置的结构，可以包括：请求接收模块51、信息获取模块52、条件校验模块53和对象提供模块54。

请求接收模块51，用于接收业务对象请求，所述业务对象请求携带：请求方的属性信息；

信息获取模块52，用于获取至少一个业务对象的对象信息，每个业务对象的所述对象信息包括：对应所述业务对象的预配置的业务条件；

条件校验模块53，用于分别对每个所述业务对象，根据对应所述业务条件的校验模块，校验所述请求方的属性信息是否满足业务对象对应的业务条件；

对象提供模块54，用于当校验结果为满足时，将业务对象提供至请求方。

例如，上述的请求接收模块、信息获取模块，可以位于图3示例的系统中的门户中心的“活动展示处理”中。条件校验模块，例如可以位于门户中心的“校验模块”中。

在一个例子中，信息获取模块52，具体用于根据所述存储地址，获取所述对象标识配置文件，所述对象标识配置文件包括：所述至少一个业务对象的对象标识；根据每个所述对象标识，获取所述对象标识对应的所述对象信息。

在一个例子中，如图6所示，该装置还可以包括：配置接收模块55。

配置接收模块55，用于接收对应所述业务对象的预配置的业务条件，所述业务条件包括：与所述业务对象对应的目标用户级别，所述目标用户级别是由预设多个用户级别中选择的允许提供所述业务对象的用户级别。

例如，该配置接收模块可以位于图3示例的系统中的活动中心，且可以位于活动中心的“活动管理”或“业务条件”。

条件校验模块53，用于根据所述请求方的属性信息，判断所述业务条件中的目标用户级别中是否包括所述请求方的用户级别。

在一个例子中，配置接收模块55，还用于接收对应所述业务对象的预配置的业务条件，所述业务条件包括：与所述业务对象对应的目标平台标识，所述目标平台标识是由预设多个平台标识中选择的允许提供业务对象的平台标识；

所述条件校验模块53，还用于根据所述请求方的属性信息，判断所述业务条件中的目标平台标识中是否包括所述请求方的业务对象平台的平台标识。

在一个例子中，当所述业务条件中包括多个子条件时，每个子条件表示一种允许提供业务对象的条件，所述条件校验模块包括多个校验子模块，每个校验子模块用于校验一个子条件是否满足。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明保护的范围之内。

Claims (10)

1.一种业务处理方法，其特征在于，所述方法包括：

接收业务对象请求，所述业务对象请求携带：请求方的属性信息；

获取至少一个业务对象的对象信息，每个业务对象的所述对象信息包括：对应所述业务对象的预配置的业务条件；

分别对每个所述业务对象，根据对应所述业务条件的校验模块，校验所述请求方的属性信息是否满足所述业务对象对应的业务条件；

当校验结果为满足时，将所述业务对象提供至所述请求方。

2.根据权利要求1所述的方法，其特征在于，所述业务对象请求，还携带：对象标识配置文件的存储地址；

所述获取至少一个业务对象的对象信息，包括：

根据所述存储地址，获取所述对象标识配置文件，所述对象标识配置文件包括：所述至少一个业务对象的对象标识；

根据每个所述对象标识，获取所述对象标识对应的所述对象信息。

3.根据权利要求1所述的方法，其特征在于，所述对应所述业务对象的预配置的业务条件，包括：与所述业务对象对应的目标用户级别，所述目标用户级别是由预设多个用户级别中选择的允许提供所述业务对象的用户级别；

所述校验所述请求方的属性信息是否满足所述业务对象对应的业务条件，包括：根据所述请求方的属性信息，判断所述业务条件中的目标用户级别中是否包括所述请求方的用户级别。

4.根据权利要求1所述的方法，其特征在于，所述对应所述业务对象的预配置的业务条件，还包括：与所述业务对象对应的目标平台标识，所述目标平台标识是由预设多个平台标识中选择的允许提供所述业务对象的平台标识；

所述校验所述请求方的属性信息是否满足所述业务对象对应的业务条件，包括：根据所述请求方的属性信息，判断所述业务条件中的目标平台标识中是否包括所述请求方的业务对象平台的平台标识。

5.根据权利要求1所述的方法，其特征在于，当所述业务条件中包括多个子条件时，每个子条件表示一种允许提供业务对象的条件；

所述根据对应所述业务条件的校验模块，校验所述请求方的属性信息是否满足所述业务对象对应的业务条件，包括：对于每一个子条件，通过与所述子条件对应的校验器，校验所述子条件是否满足。

6.一种业务处理装置，其特征在于，所述装置包括：

请求接收模块，用于接收业务对象请求，所述业务对象请求携带：请求方的属性信息；

信息获取模块，用于获取至少一个业务对象的对象信息，每个业务对象的所述对象信息包括：对应所述业务对象的预配置的业务条件；

条件校验模块，用于分别对每个所述业务对象，根据对应所述业务条件的校验模块，校验所述请求方的属性信息是否满足所述业务对象对应的业务条件；

对象提供模块，用于当校验结果为满足时，将所述业务对象提供至请求方。

7.根据权利要求6所述的装置，其特征在于，

所述信息获取模块，具体用于根据所述存储地址，获取所述对象标识配置文件，所述对象标识配置文件包括：所述至少一个业务对象的对象标识；根据每个所述对象标识，获取所述对象标识对应的所述对象信息。

8.根据权利要求6所述的装置，其特征在于，所述装置还包括：

配置接收模块，用于接收对应所述业务对象的预配置的业务条件，所述业务条件包括：与所述业务对象对应的目标用户级别，所述目标用户级别是由预设多个用户级别中选择的允许提供所述业务对象的用户级别；

所述条件校验模块，用于根据所述请求方的属性信息，判断所述业务条件中的目标用户级别中是否包括所述请求方的用户级别。

9.根据权利要求8所述的装置，其特征在于，

所述配置接收模块，还用于接收对应所述业务对象的预配置的业务条件，所述业务条件包括：与所述业务对象对应的目标平台标识，所述目标平台标识是由预设多个平台标识中选择的允许提供所述业务对象的平台标识；

所述条件校验模块，还用于根据所述请求方的属性信息，判断所述业务条件中的目标平台标识中是否包括所述请求方的业务对象平台的平台标识。

10.根据权利要求6所述的装置，其特征在于，当所述业务条件中包括多个子条件时，每个子条件表示一种允许提供业务对象的条件，所述条件校验模块包括多个校验子模块，每个校验子模块用于校验一个子条件是否满足。