发明内容
为克服相关技术中存在的问题,本说明书提供了业务处理方法、装置、***及服务设备。
一种业务处理方法,所述方法包括:
针对待处理业务,根据所述待处理业务的业务信息,从流程模式集合中,选取与所述业务信息匹配的流程模式,其中,每一流程模式包括:一个或多个流程节点,以及多个流程节点的跳转顺序;针对每个所述流程节点,预先配置有处理该流程节点的通用处理规则;
根据所选取的流程模式,按照流程节点之间的跳转顺序调用相应流程节点的通用处理规则,完成所述待处理业务的处理流程;
存储调用所述通用处理规则后所获得的业务数据。
可选的,所述流程节点包括如下一种或多种节点:
指示需要与业务提供方数据库接入进行数据查询的查询节点;
指示需要在业务发起时创建业务单据的创建单据节点;
指示需要为涉及支付的业务进行支付处理的支付单据节点;
指示需要向业务提供方即时发起业务受理的销账节点;
指示与业务提供方进行业务单据核对的业务对账节点;
指示需要为涉及支付的业务与业务提供方进行资金清算的资金清算节点。
可选的,所述方法还包括:
预先通过业务的如下一种或多种特征,为所述业务的业务信息与流程模式建立匹配关系:
所述业务是否涉及数据查询的特征、所述业务是否涉及支付的特征、所述业务是否涉及资金清算的特征、所述业务是否需要业务提供方即时受理的特征或所述业务是否需要与业务提供方进行业务对账的特征。
可选的,所述流程模式包括如下一种或多种:
未涉及查询的流程模式,流程节点及跳转顺序包括:创建单据节点、支付单据节点、销账节点、业务对账节点和资金清算节点;
未涉及支付的流程模式,流程节点及跳转顺序包括:查询节点、创建单据节点、销账节点和业务对账节点;
查询及支付的流程模式,流程节点及跳转顺序包括:查询节点、创建单据节点、支付单据节点、销账节点、业务对账节点和资金清算节点;
纯查询的流程模式,流程节点包括:查询节点;
离线处理的流程模式,流程节点及跳转顺序包括:创建单据节点、支付单据节点、业务对账节点和资金清算节点。
可选的,所述方法还包括:
在存储所述业务数据时,记录业务数据的状态;所述状态根据所述流程节点的跳转顺序和所述流程节点是否处理成功而确定。
可选的,所述业务数据携带有用户标识;
所述方法还包括:
根据所述用户标识,为用户提供针对所述业务数据的统一视图。
一种支持多业务提供方的业务处理装置,包括:
选取模块,用于:针对待处理业务,根据所述待处理业务的业务信息,从流程模式集合中,选取与所述业务信息匹配的流程模式,其中,每一流程模式包括:一个或多个流程节点,以及多个流程节点的跳转顺序;针对每个所述流程节点,预先配置有处理该流程节点的通用处理规则;
处理模块,用于:根据所选取的流程模式,按照流程节点之间的跳转顺序调用相应流程节点的通用处理规则,完成所述待处理业务的处理流程;
存储模块,用于:存储调用所述通用处理规则后所获得的业务数据。
可选的,所述流程节点包括如下一种或多种节点:
指示需要与业务提供方数据库接入进行数据查询的查询节点;
指示需要在业务发起时创建业务单据的创建单据节点;
指示需要为涉及支付的业务进行支付处理的支付单据节点;
指示需要向业务提供方即时发起业务受理的销账节点;
指示与业务提供方进行业务单据核对的业务对账节点;
指示需要为涉及支付的业务与业务提供方进行资金清算的资金清算节点。
可选的,所述方法还包括:
预先通过业务的如下一种或多种特征,为所述业务的业务信息与流程模式建立匹配关系:
所述业务是否涉及数据查询的特征、所述业务是否涉及支付的特征、所述业务是否涉及资金清算的特征、所述业务是否需要业务提供方即时受理的特征或所述业务是否需要与业务提供方进行业务对账的特征。
可选的,所述流程模式包括如下一种或多种:
未涉及查询的流程模式,流程节点及跳转顺序包括:创建单据节点、支付单据节点、销账节点、业务对账节点和资金清算节点;
未涉及支付的流程模式,流程节点及跳转顺序包括:查询节点、创建单据节点、销账节点和业务对账节点;
查询及支付的流程模式,流程节点及跳转顺序包括:查询节点、创建单据节点、支付单据节点、销账节点、业务对账节点和资金清算节点;
纯查询的流程模式,流程节点包括:查询节点;
离线处理的流程模式,流程节点及跳转顺序包括:创建单据节点、支付单据节点、业务对账节点和资金清算节点。
可选的,所述存储模块还用于:
在存储所述业务数据时,记录业务数据的状态;所述状态根据所述流程节点的跳转顺序和所述流程节点是否处理成功而确定。
可选的,所述业务数据携带有用户标识;
所述装置还包括视图提供模块,用于:
根据所述用户标识,为用户提供针对所述业务数据的统一视图。
一种业务处理***,用于处理两个或以上业务提供方的一类或多类业务;所述***包括:
模式路由层,用于接收针对待处理业务的发起请求,根据所述待处理业务的业务信息,从流程模式集合中,选取与所述业务信息匹配的流程模式,将所述发起请求路由至与所述流程模式相应的业务流程引擎;其中,每一流程模式包括:一个或多个流程节点,以及多个流程节点的跳转顺序;针对每个所述流程节点,预先配置有处理该流程节点的通用处理规则;
业务流程引擎,用于按照流程节点之间的跳转顺序调用相应流程节点的通用处理规则,完成所述待处理业务的处理流程;
数据库,存储调用所述通用处理规则后所获得的业务数据。
一种服务设备,包括:
处理器;
用于存储处理器可执行指令的存储器;
其中,所述处理器被配置为:
针对待处理业务,根据所述待处理业务的业务信息,从流程模式集合中,选取与所述业务信息匹配的流程模式,其中,每一流程模式包括:一个或多个流程节点,以及多个流程节点的跳转顺序;针对每个所述流程节点,预先配置有处理该流程节点的通用处理规则;
根据所选取的流程模式,按照流程节点之间的跳转顺序调用相应流程节点的通用处理规则,完成所述待处理业务的处理流程;
存储调用所述通用处理规则后所获得的业务数据。
本说明书的实施例提供的技术方案可以包括以下有益效果:
首先,将流程节点作为业务处理流程的最小处理单元,从开发角度来看,每个流程节点的处理逻辑是完全相同的,因此针对每个流程节点可以开发对应的通用处理规则,从而可以根据实际需求更灵活地配置出满足各种业务的业务处理流程。
其次,由于同一流程节点可以被不同业务所复用,因此可以支持多个业务提供方的多种业务,可以避免重复开发。假设有新业务涉及新的流程节点,只需要对应开发新流程节点的通用处理规则,新配置的流程节点即可与已有流程节点组合成新的流程模式,从而有效降低增加新业务所带来的开发和维护成本,能显著降低开发成本,提高开发效率。
应当理解的是,以上的一般描述和后文的细节描述仅是示例性和解释性的,并不能限制本说明书。
具体实施方式
这里将详细地对示例性实施例进行说明,其示例表示在附图中。下面的描述涉及附图时,除非另有表示,不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本说明书相一致的所有实施方式。相反,它们仅是与如所附权利要求书中所详述的、本说明书的一些方面相一致的装置和方法的例子。
在本说明书使用的术语是仅仅出于描述特定实施例的目的,而非旨在限制本说明书。在本说明书和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式,除非上下文清楚地表示其他含义。还应当理解,本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
应当理解,尽管在本说明书可能采用术语第一、第二、第三等来描述各种信息,但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如,在不脱离本说明书范围的情况下,第一信息也可以被称为第二信息,类似地,第二信息也可以被称为第一信息。取决于语境,如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。
对于某些大型互联网应用,其可能作为很多其他业务提供方与用户之间的中间平台,该大型互联网应用可以提供接入其他业务提供方的入口,使得用户可以通过一个应用而获得多个业务提供方的多种服务。
以支付宝应用为例,其承担了很多传统业务互联网化的职责,用户通过该应用,可以获得水电煤缴费、手机话费充值、交通罚款、医院挂号或物业缴费等等服务,这类业务形态繁多、地域化差异突出,由于其涉多为民生行业,其重要性也非常突出。公共服务类业务由于业务形态繁多、地域化差异突出的特点,可以是由ISV(Independent SoftwareVendors,独立软件开发商,特指专门从事软件的开发、生产、销售和服务的企业)在自行开发并部署应用,通过支付宝应用提供的入口进行接入,业务的处理过程可能用到支付宝开放的支付等功能,但业务本身是在ISV的应用中进行处理的。
这种模式虽然可以调动生态开发者共同建设产品,但由于每个业务提供方都需要由ISV独立开发产品,如果能将各类业务形态进行全面抽象,大型互联网平台能够实现支持多个其他业务提供方的业务。
通过研究发现,在实际应用中,尽管不同业务提供方的业务的处理流程在整体上各不相同,但是某些场景之间或多或少都会存在部分相同的流程节点。
例子一:利用支付宝应用进行医院缴费;
假设用户就诊后需要缴纳医药费,该业务的处理流程可以包括:
查询:以用户在该医院的账户和/或用户本次就诊编号查询本次医药费;
创建单据:支付宝应用可以利用用户在支付宝的账户等信息创建针对本次业务的业务单据,该单据中可以记录有用户在支付宝的账户、用户在该医院的账户、用户本次就诊编号、医药费或时间等一种或多种业务信息;
支付单据:支付宝应用利用支付功能为本次业务发起支付,并创建支付单据;
销账:支付宝在确定用户成功支付后通知医院方即时处理,使得医院方在确定用户缴纳医药费成功后可以为用户配药等等其他业务。
业务对账:支付宝与医院方利用业务单据核对本次业务,本次流程可以是由医院方和支付宝在约定的时间段进行。
资金清算:支付宝与医院方根据业务对账的结果,进行资金清算。
例子二:手机话费充值,该业务的处理流程可以包括:
用户发起充值业务,输入本次充值的金额;
创建单据:支付宝应用可以利用用户在支付宝的账户等信息创建针对本次业务的业务单据,该单据中可以记录有用户在支付宝的账户、手机号码、充值金额或时间等一种或多种业务信息;
支付单据:支付宝应用利用支付功能为本次业务发起支付,并创建支付单据;
销账:支付宝在确定用户成功支付后通知通信提供方即时处理,使得通信提供方在确定用户充值成功后可以为用户的话费进行更新等等其他业务。
业务对账:支付宝与通信提供方利用业务单据核对本次业务,本次流程可以是由通信提供方和支付宝在约定的时间段进行。
资金清算:支付宝与通信提供方根据业务对账的结果,进行资金清算。
例子三:利用支付宝应用进行体检报告查询,该业务的处理流程可以包括:
查询:以用户在该医院的账户和/或用户本次体检编号查询本次体检报告。可选的,假设医院方的用户数据库向支付宝开放,可以由支付宝直接接入用户数据库查询得到;假设医院方的用户数据库没有向支付宝开放,可以由支付宝向医院方发起数据查询请求,在医院方接收到该数据查询请求后返回给支付宝。
可见,尽管上述三个例子所涉及的业务的处理流程不同,但是在局部仍然存在相同的部分,例子一和例子二中有5个相同的流程节点,例子一与例子三需要涉及相同的查询节点。
根据上述分析结果,本说明书实施例提出的方案是:将完整的业务处理流程拆分成若干个流程节点,针对每个流程节点开发一套通用的处理规则,同时,针对可能涉及的业务流程,配置一个通用的流程模式集,每个流程模式包括:一个或多个流程节点,以及多个流程节点的跳转顺序。当需要处理业务时,根据业务对应的流程模式,按照流程节点之间的跳转顺序调用相应流程节点的通用处理规则,完成所述待处理业务的处理流程。
因此,本说明书实施例至少具有以下优势:
首先,将流程节点作为业务处理流程的最小处理单元,从开发角度来看,每个流程节点的处理逻辑是完全相同的,因此针对每个流程节点可以开发对应的通用处理规则,从而可以根据实际需求更灵活地配置出满足各种业务的业务处理流程。
其次,由于同一流程节点可以被不同业务所复用,因此可以支持多个业务提供方的多种业务,可以避免重复开发。假设有新业务涉及新的流程节点,只需要对应开发新流程节点的通用处理规则,新配置的流程节点即可与已有流程节点组合成新的流程模式,从而有效降低增加新业务所带来的开发和维护成本,能显著降低开发成本,提高开发效率。
为了使本领域技术人员更好地理解本说明书中的技术方案,下面将结合本说明书实施例中的附图,对本说明书实施例中的技术方案进行详细地描述,显然,所描述的实施例仅仅是本说明书一部分实施例,而不是全部的实施例。基于本说明书中的实施例,本领域普通技术人员所获得的所有其他实施例,都应当属于本说明书保护的范围。
图1A所示,为本说明书所提供的一种业务处理***的架构示意图。该***包括:模式路由层100、业务流程引擎200和数据库300。
模式路由层100,可以直接与用户侧交互,负责接收用户的各种业务发起请求。在接收到针对待处理业务的发起请求,可以根据所述待处理业务的业务信息,从流程模式集合中,选取与所述业务信息匹配的流程模式,将所述发起请求路由至与所述流程模式相应的业务流程引擎;其中,每一流程模式包括:一个或多个流程节点,以及多个流程节点的跳转顺序;针对每个所述流程节点,预先配置有处理该流程节点的通用处理规则。
业务流程引擎200,用于按照流程节点之间的跳转顺序调用相应流程节点的通用处理规则,完成所述待处理业务的处理流程。
数据库300,存储调用所述通用处理规则后所获得的业务数据。
以上介绍了本说明书业务处理***的基本场景架构,接下来将结合具体实施例对流程节点和流程模式进行说明。
本说明书实施例将一个完整的业务处理流程拆分成若干个流程节点,这里流程节点的拆分,可以结合实际业务需求,通过分析多个业务的业务处理流程而灵活确定,具体设置的流程节点本说明书对此不作限定。例如,可以分析已有业务的特征进行拆分,例如,所述业务是否涉及数据查询的特征、所述业务是否涉及支付的特征、所述业务是否涉及资金清算的特征、所述业务是否需要业务提供方即时受理的特征或所述业务是否需要与业务提供方进行业务对账的特征等等。
举例来说,如图1B所示,是本说明书根据一示例性实施例示出的一种流程节点的示意图,图1B中的流程节点包括有:
指示需要与业务提供方数据库接入进行数据查询的查询节点;
指示需要在业务发起时创建业务单据的创建单据节点;
指示需要为涉及支付的业务进行支付处理的支付单据节点;
指示需要向业务提供方即时发起业务受理的销账节点;
指示与业务提供方进行业务单据核对的业务对账节点;
指示需要为涉及支付的业务与业务提供方进行资金清算的资金清算节点。
基于流程节点,可以预先开发对应的通用处理规则。可选的,在具体实现时,实现每个流程节点的通用处理规则可以封装为独立的功能模块,各功能模块可以在被调用时独立运行,从而可以根据实际需求灵活地配置出满足各种业务的处理流程。
在有多个流程节点的情况下,通过若干个流程节点和各流程节点之间的跳转顺序可以组合出多种流程模式。本实施例中,可以根据实际所需要支持的各业务的处理流程,预先配置包括有若干个流程模式的流程模式集合,每一流程模式包括:一个或多个流程节点,以及多个流程节点的跳转顺序。通过上述配置,在需要处理业务时,可以根据该业务的处理流程,选取合适的流程模式,根据该选取的流程模式,按照流程节点之间的跳转顺序调用相应流程节点的通用处理规则,完成所述待处理业务的处理流程。
作为一个例子,所述业务流程模式可以包括如下一种或多种:
未涉及查询的业务流程模式,流程节点及跳转顺序包括:创建单据节点、支付单据节点、销账节点、业务对账节点和资金清算节点;
未涉及支付的业务流程模式,流程节点及跳转顺序包括:查询节点、创建单据节点、销账节点和业务对账节点;
查询及支付的业务流程模式,流程节点及跳转顺序包括:查询节点、创建单据节点、支付单据节点、销账节点、业务对账节点和资金清算节点;
纯查询的业务流程模式,流程节点包括:查询节点;
离线处理的业务流程模式,流程节点及跳转顺序包括:创建单据节点、支付单据节点、业务对账节点和资金清算节点。
当需要支持的业务提供方越多,***所需要支持的业务也就非常多。为了实现快速处理业务,本实施例中,可以预先为业务配置业务信息,将业务信息与该业务对应的流程模式建立匹配关系,当待处理业务被发起时,可以根据待处理业务的业务信息快速选取到匹配的流程模式。其中,业务信息用于唯一区分每个业务提供方的每个业务,例如可以包括业务标识等信息。在本说明书实施例中,可以通过业务的如下一种或多种特征,为所述业务的业务信息与流程模式建立匹配关系:
所述业务是否涉及数据查询的特征、所述业务是否涉及支付的特征、所述业务是否涉及资金清算的特征、所述业务是否需要业务提供方即时受理的特征或所述业务是否需要与业务提供方进行业务对账的特征等等。
流程节点的通用处理规则被调用后,相应地会产生业务数据,本实施例可以存储该业务数据,用户在通过应用获得其他多个业务提供方的服务后,用户可能需要查阅在不同业务提供方的业务数据,而由于这些业务数据可以由应用的服务端统一管理,因此可以为用户提供统一视图的服务。可选的,服务端可以根据登录用户的用户标识,使业务数据携带有用户标识,为用户提供针对所述业务数据的统一视图。
另一方面,服务端在获得业务数据的情况下,可以对业务数据进行离线分析,根据分析结果还可以进一步业务或技术指标的监控、资金、安全风险防控等,这些分析结果也可以同步给ISV。
下面结合一个具体的应用实例,对本说明书所提供方案进行示意性的说明。该实例具体应用于第三方支付平台,主要需求包括以下几个方面:
该第三方支付平台为用户提供有第三方支付应用,该应用可以提供接入其他业务提供方的入口,使得用户可以通过一个应用而获得多个业务提供方的多种服务。例如,该应用中可以承担很多传统业务互联网化的职责,比如:水电煤缴费、手机话费充值、交通罚款、医院挂号、物业缴费等等,这类业务形态繁多、地域化差异突出,由于其涉多为民生行业,其重要性也非常突出。
根据本说明书方案,基于上述需求,提供一种具体的业务处理***,该业务处理***可以部署在第三方支付平台,该业务处理***可以运行如图2A所提供的业务处理方法,包括如下步骤:
在步骤202中,针对待处理业务,根据所述待处理业务的业务信息,从流程模式集合中,选取与所述业务信息匹配的流程模式,其中,每一流程模式包括:一个或多个流程节点,以及多个流程节点的跳转顺序;针对每个所述流程节点,预先配置有处理该流程节点的通用处理规则。
在步骤204中,根据所选取的流程模式,按照流程节点之间的跳转顺序调用相应流程节点的通用处理规则,完成所述待处理业务的处理流程。
在步骤206中,存储调用所述通用处理规则后所获得的业务数据。
基于上述业务处理方案,如图2B所示,本说明书实施例还提供了一种实现上述方案的基本设计架构,可以理解,实际应用中,还可以结合需要灵活调整和配置其他逻辑功能,本说明书实施例对此不作限定。
本说明书实施例预先根据各业务提供方的各个业务,预先确定了如下几种流程节点:
指示需要与业务提供方数据库接入进行数据查询的查询节点;
指示需要在业务发起时创建业务单据的创建单据节点;
指示需要为涉及支付的业务进行支付处理的支付单据节点;
指示需要向业务提供方即时发起业务受理的销账节点;
指示与业务提供方进行业务单据核对的业务对账节点;
指示需要为涉及支付的业务与业务提供方进行资金清算的资金清算节点。
针对上述流程节点,还预先确定了如下几种流程模式:
模式一:未涉及查询的流程模式,流程节点及跳转顺序包括:创建单据节点、支付单据节点、销账节点、业务对账节点和资金清算节点;
本模式适用于本次业务支付金额不需要进行查询,不需要满足某种金额范围要求的场景,例如:半离线的生活缴费等。
模式二:未涉及支付的流程模式,流程节点及跳转顺序包括:查询节点、创建单据节点、销账节点和业务对账节点;
本模式适用于仅委托业务提供方办理业务的场景,例如:部分医院的挂号业务、还款分期、报税、***摇奖等。此模式还可以演化出另一种模式,即没有查询,只有销账+业务对账的流程模式。
模式三:查询及支付的流程模式,流程节点及跳转顺序包括:查询节点、创建单据节点、支付单据节点、销账节点、业务对账节点和资金清算节点;
本模式适用于查询动作非一次完成,而是多次交互完成的场景,例如:部分机构的生活缴费等,模式一可以认为是模式三在查询次数为0时的特例。
模式四:纯查询的流程模式,流程节点包括:查询节点;
本模式适用于纯查询型业务,例如:高考查分、新生儿重名查询等,这类业务场景的特点是对用户的实名认证信息、安全性等有较高要求。此模式还可以演化出另一种模式,即多次查询。
模式五:离线处理的流程模式,流程节点及跳转顺序包括:创建单据节点、支付单据节点、业务对账节点和资金清算节点。
本模式适用于纯离线型的业务,例如:部分银行的***还款等,这类业务场景的特点是,业务提供方和第三方支付服务端没有实时的数据交互通道,或无需实时交互,并且本次业务支付金额不需要满足某种金额范围要求的场景。
业务处理过程中,涉及到业务数据的流转,相对应与上述流程节点和流程模式,从一个流程节点跳转至另一流程节点,业务数据的状态相应地发生改变,每一流程节点是否处理成功决定业务数据的状态。可选的,所述方法还包括:在存储所述业务数据时,记录业务数据的状态;所述状态根据所述流程节点的跳转顺序和所述流程节点是否处理成功而确定。通过上述业务数据的状态,可以监控业务的处理情况,以对业务数据的生命周期进行有效管理。
举例来说,从第三方支付服务端的角度而言,业务数据的状态流转可以按照是否涉及支付分为2种状态,如图2C所示,涉及支付的包括上述的模式一、模式三和模式五;流程涉及:用户发起业务数据请求,***创建单据后,用户进行支付,在支付成功后,涉及销账和对账,最终业务成功处理或业务失败。如图2D所示,无涉及支付的包括模式二。而模式四中涉及0-N次查询,可以根据查询结果确定状态,通过上述方式可以对业务数据的状态进行管理和监控。流程涉及:用户发起业务数据请求,***创建单据后进行数据处理,在处理后涉及销账和对账,最终业务成功处理或业务失败。
上述流程模式遵循两个原则:
第一:销账对应对账:由于涉及到与业务提供方的实时销账,有可能出现掉单或错账等情况,因此在有销账节点的情况下对应配置对账节点。
第二:支付对应资金清算:由于是由业务提供方提供的业务,涉及支付的情况下,用户支付的资金最终要清算给业务提供方。
基于上述两个原则,如图2E所示,是本说明书根据一示例性实施例示出的一种业务示意图,本说明书实施例还对上述5种流程模式进行业务模式抽象,对上述5种流程模式可以支撑大部分的业务进行了论证,分别按照是否需要ISV即时处理业务、有无资金交互、是否有实时受理交互(销账)对业务模式进行划分,每个模式均有0-N次查询的可能。
该***中提供有产品配置功能模块,以接入各个ISV的业务。具体的,可以是在ISV接入后,根据ISV所提供的业务,以建立业务的业务信息与其对应的流程模式之间的匹配关系。可选的,ISV与***还可以约定双方在业务处理过程的规则,例如***与业务提供方实时交互的查询指令、销账的报文模板、业务对账文件的生成脚本或业务对账文件的解析脚本等等。
当用户通过应用使用其他业务提供方的服务,应用可以提供有业务入口,当应用检测到用户单击该业务入口,即可确定用户发起了业务处理请求,该业务处理请求可以携带有业务信息。
应用可以将业务处理请求发送到***的模式路由层,模式路由层根据该业务处理请求中的业务信息,确定匹配该业务信息的流程模式,从而根据所选取的流程模式,调用对应的业务流程引擎,业务流程引擎按照流程节点之间的跳转顺序调用相应流程节点的通用处理规则,完成所述待处理业务的处理流程。
由于***调用了相应流程节点的通用处理规则,在调用所述通用处理规则后所获得的业务数据可以由***进行存储。可选的,业务数据可以落入线上流水表,按照一定的同步规则同步到离线数据处理模块进行分析,结果反馈给业务支撑模块进行业务或技术指标的监控、资金、安全风险防控等,这些业务数据和分析结果也可以通过外部交互模块同步给ISV。
通过上述处理方式,用户如果进行一笔医院挂号、交了一笔交通罚款、做了一笔水费缴费等等业务,虽然是由不同的业务提供方提供的服务,但由于***可以利用本地数据库集中管理这些业务数据,因此可以向用户提供针对上述业务数据的统一视图,以供查看和管理,同样,***也可以向业务提供方提供业务数据的统一视图。
与前述业务处理方法的实施例相对应,本说明书还提供了业务处理装置及其所应用的服务设备的实施例。
本说明书业务处理装置的实施例可以应用在服务设备上。装置实施例可以通过软件实现,也可以通过硬件或者软硬件结合的方式实现。以软件实现为例,作为一个逻辑意义上的装置,是通过其所在业务处理的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言,如图3所示,为本说明书业务处理装置所在服务设备的一种硬件结构图,除了图3所示的处理器310、内存330、网络接口320、以及非易失性存储器340之外,实施例中装置331所在的服务器,通常根据该服务设备的实际功能,还可以包括其他硬件,对此不再赘述。
如图4所示,图4是本说明书根据一示例性实施例示出的一种业务处理装置的框图,所述装置包括:
选取模块41,用于:针对待处理业务,根据所述待处理业务的业务信息,从流程模式集合中,选取与所述业务信息匹配的流程模式,其中,每一流程模式包括:一个或多个流程节点,以及多个流程节点的跳转顺序;针对每个所述流程节点,预先配置有处理该流程节点的通用处理规则;
处理模块42,用于:根据所选取的流程模式,按照流程节点之间的跳转顺序调用相应流程节点的通用处理规则,完成所述待处理业务的处理流程;
存储模块43,用于:存储调用所述通用处理规则后所获得的业务数据。
可选的,所述流程节点包括如下一种或多种节点:
指示需要与业务提供方数据库接入进行数据查询的查询节点;
指示需要在业务发起时创建业务单据的创建单据节点;
指示需要为涉及支付的业务进行支付处理的支付单据节点;
指示需要向业务提供方即时发起业务受理的销账节点;
指示与业务提供方进行业务单据核对的业务对账节点;
指示需要为涉及支付的业务与业务提供方进行资金清算的资金清算节点。
可选的,所述方法还包括:
预先通过业务的如下一种或多种特征,为所述业务的业务信息与流程模式建立匹配关系:
所述业务是否涉及数据查询的特征、所述业务是否涉及支付的特征、所述业务是否涉及资金清算的特征、所述业务是否需要业务提供方即时受理的特征或所述业务是否需要与业务提供方进行业务对账的特征。
可选的,所述流程模式包括如下一种或多种:
未涉及查询的流程模式,流程节点及跳转顺序包括:创建单据节点、支付单据节点、销账节点、业务对账节点和资金清算节点;
未涉及支付的流程模式,流程节点及跳转顺序包括:查询节点、创建单据节点、销账节点和业务对账节点;
查询及支付的流程模式,流程节点及跳转顺序包括:查询节点、创建单据节点、支付单据节点、销账节点、业务对账节点和资金清算节点;
纯查询的流程模式,流程节点包括:查询节点;
离线处理的流程模式,流程节点及跳转顺序包括:创建单据节点、支付单据节点、业务对账节点和资金清算节点。
可选的,所述存储模块还用于:
在存储所述业务数据时,记录业务数据的状态;所述状态根据所述流程节点的跳转顺序和所述流程节点是否处理成功而确定。
可选的,所述业务数据携带有用户标识;
所述装置还包括视图提供模块,用于:
根据所述用户标识,为用户提供针对所述业务数据的统一视图。
上述业务处理装置中各个模块的功能和作用的实现过程具体详见上述业务处理***和上述业务处理方法中对应步骤的实现过程,在此不再赘述。
对于装置实施例而言,由于其基本对应于方法实施例,所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的,其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的,作为模块显示的部件可以是或者也可以不是物理模块,即可以位于一个地方,或者也可以分布到多个网络模块上。可以根据实际的需要选择其中的部分或者全部模块来实现本说明书方案的目的。本领域普通技术人员在不付出创造性劳动的情况下,即可以理解并实施。
相应的,本说明书还提供一种服务设备,包括:
处理器;
用于存储处理器可执行指令的存储器;
其中,所述处理器被配置为:
针对待处理业务,根据所述待处理业务的业务信息,从流程模式集合中,选取与所述业务信息匹配的流程模式,其中,每一流程模式包括:一个或多个流程节点,以及多个流程节点的跳转顺序;针对每个所述流程节点,预先配置有处理该流程节点的通用处理规则;
根据所选取的流程模式,按照流程节点之间的跳转顺序调用相应流程节点的通用处理规则,完成所述待处理业务的处理流程;
存储调用所述通用处理规则后所获得的业务数据。
上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下,在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外,在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中,多任务处理和并行处理也是可以的或者可能是有利的。
本领域技术人员在考虑说明书及实践这里说明书的发明后,将容易想到本说明书的其它实施方案。本说明书旨在涵盖本说明书的任何变型、用途或者适应性变化,这些变型、用途或者适应性变化遵循本说明书的一般性原理并包括本说明书未说明书的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的,本说明书的真正范围和精神由下面的权利要求指出。
应当理解的是,本说明书并不局限于上面已经描述并在附图中示出的精确结构,并且可以在不脱离其范围进行各种修改和改变。本说明书的范围仅由所附的权利要求来限制。
以上所述仅为本说明书的较佳实施例而已,并不用以限制本说明书,凡在本说明书的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本说明书保护的范围之内。