业务处理方法、装置及设备
技术领域
本说明书涉及互联网技术领域,尤其涉及业务处理方法、装置及设备。
背景技术
随着互联网技术的持续发展,业务提供方为用户提供的业务类型越来越多,给人们工作生活带来了极大便利。业务提供方为用户提供业务的过程中,可以创建业务数据,以记录该笔业务的各种相关信息,方便用户查询管理等。可以理解,业务提供方进行业务处理、创建业务数据的方式多种多样,提供一种更高效的业务处理方案,无疑具有重要意义。
发明内容
为克服相关技术中存在的问题,本说明书提供了业务处理方法、装置及设备。
根据本说明书实施例的第一方面,提供一种业务处理方法,包括:
针对主用户的业务订单,根据预设数据结构创建绑定所述业务订单的主用户数据,其中,所述预设数据结构至少指定用户数据具有资产字段,所述主用户数据的资产字段指示资产所有人包括所述主用户;
若通过所述业务订单确定所述主用户将资产共享给关联用户,根据所述预设数据结构创建绑定所述业务订单的关联用户数据,其中,所述关联用户数据的资产字段指示资产所有人包括所述关联用户。
可选的,所述预设数据结构还指定有数据创建者字段,所述主用户数据的数据创建者字段指示所述主用户,所述关联用户数据的数据创建者字段指示所述主用户。
可选的,所述方法还包括:
基于用户的用户数据,创建对应用户的数据库视图,所述数据库视图对应有利用所述用户数据查询展示数据的查询语句;
若接收到用户发起的携带有用户标识的数据查阅请求,通过所述用户标识查找对应所述用户的数据库视图,利用所述数据库视图中的查询语句获取展示数据后返回。
可选的,所述用户的数据库视图包括一个或多个对应不同业务场景的数据库视图,所述数据查阅请求还携带有对应业务场景的请求触发入口信息,所述通过所述用户标识查找对应所述用户的数据库视图,包括:
通过所述用户标识和请求触发入口信息查找对应所述用户及业务场景的数据库视图。
可选的,所述展示数据包括如下一种或多种:所述资产所有人信息、所述业务订单信息或数据创建者信息。
可选的,所述方法还包括:
获取登录用户信息,通过登录用户信息查找登录用户数据,获取所述登录用户数据中的资产字段和数据创建者字段,进而确定所述登录用户对所述登录用户数据关联的业务订单的操作权限。
根据本说明书实施例的第二方面,提供另一种业务处理方法,包括:
针对主用户的保险订单,根据预设数据结构创建绑定所述业务订单的主用户数据,其中,所述预设数据结构至少指定用户数据具有资产字段,所述主用户数据的资产字段指示资产所有者包括所述主用户;
若通过所述保险订单确定所述主用户将保险保额共享给关联用户,根据所述预设数据结构创建绑定所述业务订单的关联用户数据,其中,所述关联用户数据的资产字段指示资产所有者包括所述关联用户。
可选的,所述预设数据结构还指定有数据创建者字段,所述主用户数据的数据创建者字段指示所述主用户,所述关联用户数据的数据创建者字段指示所述主用户。
可选的,所述方法还包括:
基于用户的用户数据,创建对应用户的数据库视图,所述数据库视图对应有利用所述用户数据查询展示数据的查询语句;
若接收到用户发起的携带有用户标识的数据查阅请求,通过所述用户标识查找对应所述用户的数据库视图,利用所述数据库视图中的查询语句获取展示数据后返回。
可选的,所述用户的数据库视图包括一个或多个对应不同业务场景的数据库视图,所述数据查阅请求还携带有对应业务场景的请求触发入口信息,所述通过所述用户标识查找对应所述用户的数据库视图,包括:
通过所述用户标识和请求触发入口信息查找对应所述用户及业务场景的数据库视图。
可选的,所述展示数据包括如下一种或多种:所述资产所有人信息、所述保险订单信息或数据创建者信息。
可选的,所述方法还包括:
获取登录用户信息,通过登录用户信息查找登录用户数据,获取所述登录用户数据中的资产字段和数据创建者字段,进而确定所述登录用户对所述登录用户数据关联的保险订单的操作权限。
根据本说明书实施例的第三方面,提供一种业务处理装置,所述装置包括:
主用户数据创建模块,用于:针对主用户的业务订单,根据预设数据结构创建绑定所述业务订单的主用户数据,其中,所述预设数据结构至少指定用户数据具有资产字段,所述主用户数据的资产字段指示资产所有人包括所述主用户;
关联用户数据创建模块,用于:若通过所述业务订单确定所述主用户将资产共享给关联用户,根据所述预设数据结构创建绑定所述业务订单的关联用户数据,其中,所述关联用户数据的资产字段指示资产所有人包括所述关联用户。
可选的,所述预设数据结构还指定有数据创建者字段,所述主用户数据的数据创建者字段指示所述主用户,所述关联用户数据的数据创建者字段指示所述主用户。
可选的,所述装置还包括数据库视图创建模块,用于:基于用户的用户数据,创建对应用户的数据库视图,所述数据库视图对应有利用所述用户数据查询展示数据的查询语句;
数据查阅模块,用于:若接收到用户发起的携带有用户标识的数据查阅请求,通过所述用户标识查找对应所述用户的数据库视图,利用所述数据库视图中的查询语句获取展示数据后返回。
可选的,所述用户的数据库视图包括一个或多个对应不同业务场景的数据库视图,所述数据查阅请求还携带有对应业务场景的请求触发入口信息,所述数据查阅模块,还用于:
通过所述用户标识和请求触发入口信息查找对应所述用户及业务场景的数据库视图。
可选的,所述展示数据包括如下一种或多种:所述资产所有人信息、所述业务订单信息或数据创建者信息。
可选的,所述装置还包括权限确定模块,用于:
获取登录用户信息,通过登录用户信息查找登录用户数据,获取所述登录用户数据中的资产字段和数据创建者字段,进而确定所述登录用户对所述登录用户数据关联的业务订单的操作权限。
根据本说明书实施例的第四方面,提供一种计算机设备,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,其中,所述处理器执行所述程序时实现如下方法:
针对主用户的业务订单,根据预设数据结构创建绑定所述业务订单的主用户数据,其中,所述预设数据结构至少指定用户数据具有资产字段,所述主用户数据的资产字段指示资产所有人包括所述主用户;
若通过所述业务订单确定所述主用户将资产共享给关联用户,根据所述预设数据结构创建绑定所述业务订单的关联用户数据,其中,所述关联用户数据的资产字段指示资产所有人包括所述关联用户。
本说明书的实施例提供的技术方案可以包括以下有益效果:
本说明书实施例中,对于主用户向关联用户分享的业务订单的资产,可以对应创建有绑定业务订单的关联用户数据,利用该关联用户数据的资产字段记录该关联用户所拥有的资产。因此可以有效记录业务订单中主用户与共享者的关系,可以支持共享者对业务订单的查阅,可以便于业务提供方进行数据的维护。
应当理解的是,以上的一般描述和后文的细节描述仅是示例性和解释性的,并不能限制本说明书。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分,示出了符合本说明书的实施例,并与说明书一起用于解释本说明书的原理。
图1A是本说明书根据一示例性实施例示出的一种业务处理方法的流程图。
图1B是本说明书根据一示例性实施例示出的一种业务处理场景示意图。
图1C是本说明书根据一示例性实施例示出的一种不同业务场景下的数据展示示意图。
图2是本说明书根据一示例性实施例示出的另一种业务处理方法的流程图。
图3是本说明书实施例业务处理装置所在计算机设备的一种硬件结构图。
图4是本说明书根据一示例性实施例示出的一种业务处理装置的框图。
具体实施方式
这里将详细地对示例性实施例进行说明,其示例表示在附图中。下面的描述涉及附图时,除非另有表示,不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本说明书相一致的所有实施方式。相反,它们仅是与如所附权利要求书中所详述的、本说明书的一些方面相一致的装置和方法的例子。
在本说明书使用的术语是仅仅出于描述特定实施例的目的,而非旨在限制本说明书。在本说明书和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式,除非上下文清楚地表示其他含义。还应当理解,本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
应当理解,尽管在本说明书可能采用术语第一、第二、第三等来描述各种信息,但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如,在不脱离本说明书范围的情况下,第一信息也可以被称为第二信息,类似地,第二信息也可以被称为第一信息。取决于语境,如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。
在一些业务场景中,可能会涉及资产共享的情况。例如,以保险业务场景为例,用户可以将保险保额共享给子女等其他人。首先对保险业务涉及的词语进行说明:
保险人,保险人又称“承保人”,是指与投保人订立保险合同,并承担赔偿或者给付保险金责任的保险主体。
投保人,是指与保险人订立保险合同,并按照保险合同负有支付保险费义务的人。
被保人,是指根据保险合同,其财产利益或人身受保险合同保障,在保险事故发生后,享有保额请求权的人。
保额,保险金额的简称,指保险人承担赔偿或者给付保险金责任的最高限额。
向用户提供保险业务时,用户会有相应的协议签约动作,之后该用户会获得一份保单。其中,保额可能是固定不变的,也有可能发生变动。
作为例子,Lulu在保险公司购买一款保险产品,Lulu即投保人,保险人即保险公司,Lulu可以将保险金额的被保人指定为自己,或者是其他人。
在另一些例子中,随着互联网业务的创新,也出现了其他保险类型。例如,第三方支付平台方为用户向保险公司购买了一款保险产品,其中,第三方支付平台方即投保人,用户为被保人。第三方支付平台可以针对用户的保险订单创建业务数据,该条业务数据可以记录有用户信息、该笔保险订单的各种相关信息等。
在另一些保险业务中,还可能出现保额共享的情况,用户将保额共享给其他人,例如用户的家庭成员(自己的子女或配偶等)。针对这种情况,业务处理会面临一些问题,例如,如何记录该笔保险订单中用户与共享者的关系,如何在用户数据中记录共享者的信息,以方便共享者也可以查阅到用户分享给他人的保单等等。
基于此,本说明书提供一种业务处理方案,该方案可以有效记录保险订单中用户与共享者的关系,可以支持共享者对保险订单的查阅,可以便于业务提供方进行数据的维护。接下来对本说明书实施例进行详细说明。
如图1A所示,图1A是本说明书根据一示例性实施例示出的一种业务处理方法的流程图,包括以下步骤:
在步骤102、针对主用户的保险订单,根据预设数据结构创建绑定所述业务订单的主用户数据,其中,所述预设数据结构至少指定用户数据具有资产字段,所述主用户数据的资产字段指示资产所有人包括所述主用户。
在步骤104、若通过所述保险订单确定所述主用户将保险保额共享给关联用户,根据所述预设数据结构创建绑定所述业务订单的关联用户数据,其中,所述关联用户数据的资产字段指示资产所有人包括所述关联用户。
如图1B所示,是本说明书根据一示例性实施例示出的业务处理场景图,本说明书实施例中涉及两类用户,为了便于区分,本实施例将其中一类称为主用户,即保险订单所有者、作为被保人的用户;另一类称为关联用户,即主用户将自身保险订单的保险保额所共享的一方。
本实施例的业务处理方法可应用于业务方侧,该业务方可以是服务方具体可以是提供保险产品的服务方,在另一些例子中,业务方具体也可以是保险平台业务方,该业务方可以接入多家保险产品的服务方,向用户提供各种保险产品。
对于主用户,业务提供方会针对该笔保险订单创建用户数据,本说明书实施例可以从用户数据的数据结构上提出解决方案。本实施例中可以将保险保额作为用户的资产,对于主用户,其资产包括该保险保额,主用户将保险保额共享给关联用户,也即是将资产共享,关联用户也拥有了该资产。因此,本实施例可以预先设置数据结构,该数据结构中至少指定用户数据具有资产字段,利用该资产字段指示资产所有人,可以理解,主用户数据的资产字段指示资产所有者包括所述主用户。基于此,利用该预设数据结构创建的主用户数据中具有资产,通过读取该资产字段,即可确定该条用户数据中资产所有人是该主用户。可以理解,实际应用中,该预设数据结构还可指定用户数据中的其他字段,例如用户标识、业务订单标识、订单完成时间、保障时长、付款方式或用户个人信息等等,以详细记录有关该用户的该笔业务订单的相关信息。
其中,若用户第一次通过业务方侧购买保险完成一笔有关保险的业务订单,业务方可以基于该笔业务订单为该主用户建立账户,该主用户的用户数据属于该用户的账户下的数据;可以理解,若该用户后续还有其他业务订单,则在该账户下还可以有更多的用户数据。
进一步的,对于主用户将保险保额共享给关联用户的保险订单,本实施例同样会根据该预设数据结构为该关联用户创建关联用户数据,由于该数据结构中至少指定用户数据具有资产字段,利用该资产字段指示资产所有人,可以理解,关联用户数据的资产字段指示资产所有者包括所述关联用户,基于此,利用该预设数据结构创建的关联用户数据中具有资产,通过读取该资产字段,即可确定该条关联用户数据中资产所有人包括该关联用户。
其中,若该关联用户是第一次被该主用户分享资产,则可以为该关联用户建立账户,该关联用户的用户数据属于该用户的账户下的数据;可以理解,若该关联用户后续还被该主用户分享其他业务订单的资产,则该账户下可以有更多的数据;可选的,若该关联用户后续被其他主用户分享其他业务订单的资产,可以是在该关联用户的账户下创建其他数据,也可以是针对该关联用户创建其他账户,以在该其他账户下创建数据。
实际应用中,某个用户还可以同时作为主用户和关联用户,例如用户Lulu有一笔业务订单A,并且被用户Tony分享有业务订单B的资产,可以针对业务订单A创建Lulu的主账户,该主账户下有业务订单A的主用户数据,同时,针对用户Tony的业务订单B创建Lulu的另一账户,该账户是与业务订单B关联的关联账户,该关联账户下有业务订单B的关联用户数据。在另一些场景中,也可以是针对Lulu只创建一个账户,在该账户下既有业务订单A的主用户数据,也有业务订单B的关联用户数据。
其中,主用户数据和关联用户数据都与主用户的业务订单进行绑定,绑定的实现方式可以有多种,作为例子,可以是预设数据结构指定有业务订单信息字段,通过在该业务订单信息字段中写入业务订单的标识等信息。也可以是在其他数据表中记录用户数据与业务订单的对应关系。
由上述实施例可见,主用户将保险保额所共享的关联用户也创建有用户数据,利用该关联用户数据的资产字段记录该关联用户所拥有的保额,因此可以有效记录业务订单中主用户与共享者的关系,可以支持共享者对保险订单的查阅,可以便于业务提供方进行数据的维护。
为了更为清晰地供用户查阅资产来源等信息、便于业务方进行数据维护,可选的,预设数据结构还指定有数据创建者字段,所述主用户数据的数据创建者字段指示所述主用户,所述关联用户数据的数据创建者字段指示所述主用户;例如,通过数据创建者字段,服务方可以确定该条用户数据是由哪个用户的保险订单创建的。例如,从主用户数据的数据创建者字段可以确定该条用户数据的数据创建者是该主用户,从关联用户数据的数据创建者字段可以确定该条关联用户数据的数据创建者是该关联用户,基于此,业务方、主用户或关联用户等可以提供用户数据查阅到数据创建者,清楚资产的来源。
实际应用中,对于业务方来说,可能由于业务需要,创建的用户数据中可能包含有有关用户及业务订单的诸多信息,例如业务方为该笔订单创建的订单标识、订单流水号或付款流水号等等。但对于用户来说,用户可能只关心其中的部分信息,用户还有查阅其中部分信息的需求,例如查看保险的保障时长、保额有多少、保险购买时间或保险合同等等。用户查询的信息可能只是用户数据中的少量字段,诸如保险合同等数据可能与用户数据不在同一张数据库表中,查询的过程可能涉及多张数据库表。基于此,本实施例中还提供了如下方案,可以便于处理用户对数据的查阅需求。可选的,本实施例中可以基于用户的用户数据,创建对应用户的数据库视图,所述数据库视图对应有利用所述用户数据查询展示数据的查询语句;若接收到用户发起的携带有用户标识的数据查阅请求,通过所述用户标识查找对应所述用户的数据库视图,利用所述数据库视图中的查询语句获取展示数据后返回。
其中,数据库视图(view)是一个虚拟表,本身不存储数据,其内容由查询定义,可以按照指定的方式进行查询。对于复杂的查询事件,每次查询都需要编写查询语句必然效率低下,本实施例利用数据库的视图功能解决该问题。可选的,本实施例可以为每个用户预先创建对应的数据库视图,其中,数据库视图所能查询的数据是返回给用户查阅的数据,本实施例称为展示数据,基于用户数据的存储位置等条件,可以预先编写能利用所述用户数据查询展示数据的查询语句以完成视图的创建,其中,每个用户的数据库视图与用户对应,可选的,可以采用用户标识将各个视图进行区分。当用户需要查阅时(例如用户利用APP等方式登录个人页面,该个人页面中提供有数据展示功能),可以发起携带有用户标识的数据查阅请求,通过该用户标识可以查找对应所述用户的数据库视图,利用所述数据库视图中的查询语句获取展示数据后返回。
可选的,用户账户下可能还涉及多笔业务订单、具有多条用户数据,不同业务订单可能基于不同业务场景发起,在不同业务场景下用户所关注的数据不同,基于此,本实施例中,所述用户的数据库视图包括一个或多个对应不同业务场景的数据库视图,所述数据查阅请求还携带有对应业务场景的请求触发入口信息,所述通过所述用户标识查找对应所述用户的数据库视图,包括:通过所述用户标识和请求触发入口信息查找对应所述用户及业务场景的数据库视图。通过上述方式,可以达到不同业务场景下提供不同数据的效果。
作为例子,业务方提供有两类保险产品,第一类保险产品是可供用户将保险保额分享给家人,第二类保险产品是用户参与业务方的营销活动后,由业务方购买并分享保额给用户的。假设用户A涉及一笔购买第一类保险产品后产生的业务订单,并且用户A还将保险保额分享给家人;用户A参与了业务方的营销活动后,作为关联用户,获得了业务方分享的保险保额。其中,用户A可以使用业务方提供的客户端或登录服务页面查阅这两类保险产品的相关数据。针对第一类保险产品,用户A的需求是希望能够查阅到该第一类保险产品以及分享给家人的情况;针对第二类保险产品,用户A的需求是查阅到业务方分享的保险保额即可,并不需要涉及到业务方等诸多信息。
基于这两类保险产品所对应的不同业务场景,业务方可以预先配置这两种业务场景的数据库视图,以提供不同的业务数据。以使用客户端为例,用户A可以采用UID和/或身份证等用户标识登录服务器。可选的,客户端提供有请求触发入口,用户可以触发该请求触发入口,以使客户端发起数据查阅请求。可选的,该请求触发入口可以是包括查阅两类保险产品的数据查阅请求,则业务方可以分别通过前述两种业务场景的数据库视图,对应获取到两类保险产品的展示数据后返回。在另一些例子中,请求触发入口可以有两个,一个是针对第一类保险产品的触发入口,一个是针对第二类保险产品的触发入口,用户可以触发其中任一入口,以查阅数据。如图1C所示,是本说明书根据一示例性实施例示出了两种不同业务场景下的展示数据示意图,在业务场景一中,作为“父亲”角色的用户将资产分享给孩子和孩子母亲,相对应的数据库视图可以获取到分享给孩子和孩子母亲的相关展示数据;在在业务场景二中,该用户是作为被业务方分享保险保额的关联用户,相对应的数据库视图可以获取到与其自身保额相关的数据。
接下来再通过一实施例对本说明书的业务处理方案进行详细说明。
本实施例以保险场景为例,若用户第一次通过业务方侧购买保险完成一笔有关保险的业务订单,业务方可以基于该笔业务订单为用户建立账户,本实施例称为健康账户并基于该账户生成用户数据。实际应用中,该业务方不限定是否是保险产品的服务方,可以是为保险产品服务方提供服务的平台。
针对健康账户,服务方可以预先配置数据结构,以规定账户数据中包含哪些字段。可选的,预设数据结构可以指定的数据主键包括:用户标识,可以是用户的身份证号码和/或UserID(User,Identification,用户身份证明,简称UID)。本实施例以用户的UID和身份证号码为例。通过基于用户UID和身份证号的索引,可以保证用户后续进行数据查询的时候,能支持多维度的查询。
由于该用户完成了保险订单,该用户作为主用户可以按照预设数据结构生成相应的用户数据。其中,保险订单涉及有干系人,如投保人和被保人。若主用户未分享保额,则被保人只有一个,即主用户自己。也就是说该保单的权益,只能主用户自己享用。其中,预设数据结构至少指定用户数据具有资产字段,所述主用户数据的资产字段指示资产所有人包括所述主用户。
本实施例中,用户A(主用户)也可以将保额权益分享给关联用户(用户B)。具体的:
服务方可以为用户A创建健康账户,对于用户的某一个保险订单,服务方会在该健康账户下创建对应该保险订单的主用户数据。其中,基于预设数据结构的规定,该条主用户数据的数据创建者字段指示用户A,资产字段指示用户A。该保险订单可以作为健康资产与该用户A绑定到健康账户上。
可选的,可以为用户A创建健康账户组视图,即用户A登录服务端后,通过该视图可以获得数据后展示给用户查阅,可选的,用户A可以使用自己的UID和身份证号码登录服务端并访问自己的健康账户。
由于用户A将保额分享给用户B,若用户B未在服务端有健康账户,则可以为用户B创建一健康账户。如果用户B已创建有健康账户,则不需要重复创建。同样,用户B也可以使用自己的UID和身份证号码来访问自己的健康账户。相应地,在用户B的健康账户下创建对应用户A所分享的保险订单的用户数据,用户B的用户数据中,资产字段指示资产所有者包括该用户B,并且与所述主用户的保险订单绑定。因此,用户B的健康账户下就拥有了A的保单,用户B通过自己的身份证或UID来访问健康账户的时候,通过该用户数据,可以查阅到账户下的保单是A分享给自己的,而资产所有人是自己。
由上述实施例可见,通过上述用户数据,主用户和关联用户之间的资产信息不会发生信息丢失的问题。另外,如果用户A有自己的保险订单,可以拥有自己是创建人,同时自己是资产所有人的用户数据。在一些业务场景中,用户A可能有多笔业务订单,关注自己的保单例如用户B将保单如果用户B只需要关注自己的账户,则可以通过数据创建者和资产所有者的关系来进行数据筛选,解决了不同业务视角业务隔离的问题。
在保单分享的场景下,健康资产的类型是保单。在其他场景中,还可以扩展不同的类型,例如体检报告或体质监测报告等其他类型,从而实现其他类型资产的分享。
对服务方来说,上述方案还可以解决权限隔离的问题,获取登录用户信息,通过登录用户信息查找登录用户数据,获取所述登录用户数据中的资产字段和数据创建者字段,进而确定所述登录用户对所述登录用户数据关联的业务订单的操作权限。作为例子,用户登录后可以获得当前登录用户的UID,该登录用户对应有用户数据,用户数据中资产字段指示有资产所有人UID,数据创建者字段指示有数据创建者UID,可以通过这三个UID的关系来确定用户的权限。例如登录态UID和资产所有人UID相同,但与数据创建者UID不同,说明这个账户下对应的资产是别人分享给自己的,则不能对该条用户数据关联的保单资产进行退保等操作,因此也解决了权限隔离的问题。
除了保险业务场景之外,本说明书实施例的业务处理方案也可以应用在其他涉及需要资产分享的业务场景中,例如红包分享场景或业务订单权益分享场景等,作为例子涉及购买会员的业务订单中,可以将所购买的会员资格分享给其他关联用户等。
如图2所示,是根据一示例性实施例示出的另一种业务处理方法,包括如下步骤:
在步骤202中,针对主用户的业务订单,根据预设数据结构创建绑定所述业务订单的主用户数据,其中,所述预设数据结构至少指定用户数据具有资产字段,所述主用户数据的资产字段指示资产所有人包括所述主用户;
在步骤204中,若通过所述业务订单确定所述主用户将资产共享给关联用户,根据所述预设数据结构创建绑定所述业务订单的关联用户数据,其中,所述关联用户数据的资产字段指示资产所有人包括所述关联用户。
可选的,所述预设数据结构还指定有数据创建者字段,所述主用户数据的数据创建者字段指示所述主用户,所述关联用户数据的数据创建者字段指示所述主用户。
可选的,所述方法还包括:
基于用户的用户数据,创建对应用户的数据库视图,所述数据库视图对应有利用所述用户数据查询展示数据的查询语句;
若接收到用户发起的携带有用户标识的数据查阅请求,通过所述用户标识查找对应所述用户的数据库视图,利用所述数据库视图中的查询语句获取展示数据后返回。
可选的,所述用户的数据库视图包括一个或多个对应不同业务场景的数据库视图,所述数据查阅请求还携带有对应业务场景的请求触发入口信息,所述通过所述用户标识查找对应所述用户的数据库视图,包括:
通过所述用户标识和请求触发入口信息查找对应所述用户及业务场景的数据库视图。
可选的,所述展示数据包括如下一种或多种:所述资产所有人信息、所述业务订单信息或数据创建者信息。
可选的,所述方法还包括:
获取登录用户信息,通过登录用户信息查找登录用户数据,获取所述登录用户数据中的资产字段和数据创建者字段,进而确定所述登录用户对所述登录用户数据关联的业务订单的操作权限。
与前述业务处理方法的实施例相对应,本说明书还提供了业务处理装置及其所应用的设备的实施例。
本说明书业务处理装置的实施例可以应用在计算机设备上,例如服务器或终端设备。装置实施例可以通过软件实现,也可以通过硬件或者软硬件结合的方式实现。以软件实现为例,作为一个逻辑意义上的装置,是通过其所在文件处理的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言,如图3所示,为本说明书实施例业务处理装置所在计算机设备的一种硬件结构图,除了图3所示的处理器310、内存330、网络接口320、以及非易失性存储器340之外,实施例中装置331所在的服务器或电子设备,通常根据该计算机设备的实际功能,还可以包括其他硬件,对此不再赘述。
如图4所示,图4是本说明书根据一示例性实施例示出的一种业务处理装置的框图,所述装置包括:
主用户数据创建模块41,用于:针对主用户的业务订单,根据预设数据结构创建绑定所述业务订单的主用户数据,其中,所述预设数据结构至少指定用户数据具有资产字段,所述主用户数据的资产字段指示资产所有人包括所述主用户;
关联用户数据创建模块42,用于:若通过所述业务订单确定所述主用户将资产共享给关联用户,根据所述预设数据结构创建绑定所述业务订单的关联用户数据,其中,所述关联用户数据的资产字段指示资产所有人包括所述关联用户。
可选的,所述预设数据结构还指定有数据创建者字段,所述主用户数据的数据创建者字段指示所述主用户,所述关联用户数据的数据创建者字段指示所述主用户。
可选的,所述装置还包括数据库视图创建模块,用于:基于用户的用户数据,创建对应用户的数据库视图,所述数据库视图对应有利用所述用户数据查询展示数据的查询语句;
数据查阅模块,用于:若接收到用户发起的携带有用户标识的数据查阅请求,通过所述用户标识查找对应所述用户的数据库视图,利用所述数据库视图中的查询语句获取展示数据后返回。
可选的,所述用户的数据库视图包括一个或多个对应不同业务场景的数据库视图,所述数据查阅请求还携带有对应业务场景的请求触发入口信息,所述数据查阅模块,还用于:
通过所述用户标识和请求触发入口信息查找对应所述用户及业务场景的数据库视图。
可选的,所述展示数据包括如下一种或多种:所述资产所有人信息、所述业务订单信息或数据创建者信息。
可选的,所述装置还包括权限确定模块,用于:
获取登录用户信息,通过登录用户信息查找登录用户数据,获取所述登录用户数据中的资产字段和数据创建者字段,进而确定所述登录用户对所述登录用户数据关联的业务订单的操作权限。
相应的,本说明书还提供一种计算机设备,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,其中,所述处理器执行所述程序时实现如下方法:
针对主用户的业务订单,根据预设数据结构创建绑定所述业务订单的主用户数据,其中,所述预设数据结构至少指定用户数据具有资产字段,所述主用户数据的资产字段指示资产所有人包括所述主用户;
若通过所述业务订单确定所述主用户将资产共享给关联用户,根据所述预设数据结构创建绑定所述业务订单的关联用户数据,其中,所述关联用户数据的资产字段指示资产所有人包括所述关联用户。
上述业务处理装置中各个模块的功能和作用的实现过程具体详见上述业务处理方法中对应步骤的实现过程,在此不再赘述。
对于装置实施例而言,由于其基本对应于方法实施例,所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的,其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的,作为模块显示的部件可以是或者也可以不是物理模块,即可以位于一个地方,或者也可以分布到多个网络模块上。可以根据实际的需要选择其中的部分或者全部模块来实现本说明书方案的目的。本领域普通技术人员在不付出创造性劳动的情况下,即可以理解并实施。
上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下,在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外,在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中,多任务处理和并行处理也是可以的或者可能是有利的。
本领域技术人员在考虑说明书及实践这里申请的发明后,将容易想到本说明书的其它实施方案。本说明书旨在涵盖本说明书的任何变型、用途或者适应性变化,这些变型、用途或者适应性变化遵循本说明书的一般性原理并包括本说明书未申请的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的,本说明书的真正范围和精神由下面的权利要求指出。
应当理解的是,本说明书并不局限于上面已经描述并在附图中示出的精确结构,并且可以在不脱离其范围进行各种修改和改变。本说明书的范围仅由所附的权利要求来限制。
以上所述仅为本说明书的较佳实施例而已,并不用以限制本说明书,凡在本说明书的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本说明书保护的范围之内。