投保流程生成方法、投保请求处理方法及装置和电子设备与流程

本申请涉及计算机技术领域，尤其涉及一种投保流程生成方法及其装置、以及投保请求处理方法及其装置。

背景技术：

随着互联网技术的发展，与传统保险公司对接而建成的网上保险平台(又可称为第三方网络保险平台)也应运而生。网上保险平台因其高效便捷等诸多优势，得到了广泛应用。

为了满足用户的多种个性化需求，网上保险平台需要支持多种不同的保险产品所对应的业务类型，例如，个人险、企业险、车险、保险卡、续期续保等等。并且，新型保险产品的推出也要求网上保险平台能够支持更多的业务类型，例如，赠险、半赠险等等。

在现有技术中，为满足不同类型保险产品的投保流程的需要，通常通过产品编号或者类型标识来区分不同的业务类型，各个业务类型由其各自的投保流程分支来处理，且各业务类型的投保流程往往采用垂直的体系结构进行编码，可形象的称之为烟囱式架构。这种架构的主要缺陷在于：

在烟囱式架构中，当需要在业务类型的原投保流程的基础上进行更新或添加不同分支时，只能通过硬编码的方式将新增的业务逻辑往“烟囱”里叠加，因此，这种架构的可扩展性较差。并且，由于整个投保流程中可能涉及到散落在流程中的多个不同业务逻辑的判断，因此，在新增业务逻辑时也容易引起程序漏洞并可能导致整体测试回归的工作量增加一倍以上，可维护性较差。

技术实现要素：

本申请实施例提供投保流程生成方法及装置，旨在优化投保流程的生成过程，提高投保流程的可扩展性和可维护性。

本申请实施例还提供投保请求处理方法及装置，旨在优化投保请求的处理过程，提高投保请求处理过程的可扩展性和可维护性。

本申请实施例采用下述技术方案：

第一方面，本申请实施例提供一种投保流程生成方法，包括：

获取投保业务的业务信息；

依据所述业务信息和投保组件库，确定所述投保组件库中与所述投保业务相对应的投保组件及所述投保组件的执行顺序；所述投保组件库中存储有预设的至少一个投保组件，所述投保组件用于实现投保业务中的业务逻辑；

依据所述投保组件及其执行顺序，生成用于处理所述投保业务的投保流程；其中，所述投保流程按照所述执行顺序执行所述投保组件。

优选地，本申请实施例提供的第一方面的投保流程生产方法中，所述投保组件中包括请求参数信息和/或处理结果信息，则依据所述投保组件及其执行顺序，生成用于处理所述投保业务的投保流程时，包括：

在所述投保流程中预设上下文类；

将所述投保组件中的请求参数信息和/或处理结果信息与所述上下文类建立关联关系，用于在执行所述投保流程时在各投保组件间传递所述请求参数信息和/或处理结果信息；

依据所述投保组件及其执行顺序，生成按照所述执行顺序执行所述投保组件的投保流程。

优选地，本申请实施例提供的第一方面的投保流程生产方法中，所述投保组件中包括依赖属性，所述依赖属性包括强依赖，

则依据所述投保组件及其执行顺序生成的投保流程中，包括：

当依赖属性为强依赖的投保组件执行失败或异常时，所述投保流程中止，且返回投保流程执行失败或执行异常的处理结果。

优选地，本申请实施例提供的第一方面的投保流程生产方法中，所述依赖属性还包括弱依赖，则依据所述投保组件及其执行顺序生成的投保流程中，还包括：

当依赖属性为弱依赖的投保组件执行失败或异常时，所述投保流程按照所述执行顺序继续执行下一个投保组件。

优选地，本申请实施例提供的第一方面的投保流程生产方法中，依据所述业务信息和投保组件库，确定所述投保组件库中与所述投保业务相对应的投保组件及所述投保组件的执行顺序，包括：

依据所述业务信息和投保组件库，确定所述投保组件库中实现所述投保业务的业务逻辑所需的投保组件；

依据所述投保组件之间的依赖关系，确定所述投保组件的执行顺序。

优选地，本申请实施例提供的第一方面的投保流程生产方法中，所述投保组件库中包括以下一个或多个投保组件：

前置检查组件、用户获取组件、产品获取组件、白名单组件、询价组件、保期处理组件、险种处理组件、价格处理组件、优惠券处理组件、扩展处理组件、营销组件、收益人组件、被保人组件、付款人组件、标的组件、投保调用组件。

优选地，本申请实施例提供的第一方面的投保流程生产方法中，在依据所述投保组件及其执行顺序，生成用于处理所述投保业务的投保流程之后，所述方法还包括：

获取投保请求，所述投保请求中包括请求投保的投保业务的业务信息；

依据所述业务信息，确定用于处理所述投保业务的投保流程；

采用所述投保流程处理所述投保请求中请求投保的投保业务。

优选地，本申请实施例提供的第一方面的投保流程生产方法中，所述投保组件中包括请求参数信息和/或处理结果信息，所述投保流程中预设有上下文类，

则采用所述投保流程处理所述投保请求中请求投保的投保业务，包括：

依据所述投保请求，初始化所述投保流程中的上下文信息；

按照所述投保流程中的执行顺序执行所述投保组件，并将所述投保组件的请求参数信息和/或处理结果信息写入所述上下文信息，以便在各所述投保组件间传递。

优选地，本申请实施例提供的第一方面的投保流程生产方法中，在依据所述业务信息和投保组件库，确定所述投保组件库中与所述投保业务相对应的投保组件及所述投保组件的执行顺序之前，所述方法还包括：

构建所述投保组件库；其中，所述投保组件库中存储有预设的至少一个投保组件，所述投保组件用于实现投保业务中的业务逻辑。

优选地，本申请实施例提供的第一方面的投保流程生产方法中，构建所述投保组件库，包括：

按照预设粒度拆分所述投保业务的业务逻辑，确定多个子业务逻辑；

生成用于实现所述子业务逻辑的投保组件；

存储所述投保组件，构成所述投保组件库。

第二方面，本申请实施例提供一种投保请求处理方法，包括：

获取投保请求，所述投保请求中包括请求投保的投保业务的业务信息；

依据所述业务信息，确定用于处理所述投保业务的投保流程；其中，所述投保流程中包括按照执行顺序执行的投保组件，所述投保组件及其执行顺序依据投保业务的业务信息和投保组件库确定，所述投保组件库中存储有预设的至少一个投保组件，所述投保组件用于实现投保业务中的业务逻辑；

采用所述投保流程处理所述投保请求中请求投保的投保业务。

优选地，本申请实施例提供的第二方面的投保请求处理方法中，所述投保组件中包括请求参数信息和/或处理结果信息，所述投保流程中预设有上下文类，

则采用所述投保流程处理所述投保请求中请求投保的投保业务，包括：

依据所述投保请求，初始化所述投保流程中的上下文信息；

按照所述投保流程中的执行顺序执行所述投保组件，并将所述投保组件的请求参数信息和/或处理结果信息写入所述上下文信息，以便在各所述投保组件间传递。

优选地，本申请实施例提供的第二方面的投保请求处理方法中，所述投保请求中还包括请求投保的投保数据，则依据所述投保请求，初始化所述投保流程中的上下文信息，包括：

将所述投保请求中的所述投保数据写入所述上下文信息，用于在所述投保流程中的各投保组件之间传递。

优选地，本申请实施例提供的第二方面的投保请求处理方法中，所述投保组件中包括依赖属性，所述依赖属性包括强依赖，则采用所述投保流程处理所述投保请求中请求投保的投保业务，包括：

当所述投保流程中依赖属性为强依赖的投保组件执行失败或异常时，所述投保流程中止，且返回投保流程执行失败或执行异常的处理结果。

优选地，本申请实施例提供的第二方面的投保请求处理方法中，所述依赖属性还包括弱依赖，则采用所述投保流程处理所述投保请求中请求投保的投保业务，还包括：

当所述投保流程中依赖属性为弱依赖的投保组件执行失败或异常时，所述投保流程按照所述执行顺序继续执行下一个投保组件。

第三方面，本申请实施例提供一种投保流程生成装置，包括：

业务信息获取模块，获取投保业务的业务信息；

投保组件确定模块，依据所述业务信息和投保组件库，确定所述投保组件库中与所述投保业务相对应的投保组件及所述投保组件的执行顺序；所述投保组件库中存储有预设的至少一个投保组件，所述投保组件用于实现投保业务中的业务逻辑；

投保流程生成模块，依据所述投保组件及其执行顺序，生成用于处理所述投保业务的投保流程；其中，所述投保流程按照所述执行顺序执行所述投保组件。

第四方面，本申请实施例提供一种电子设备，包括：

处理器；以及

被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器执行以下操作：

获取投保业务的业务信息；

依据所述业务信息和投保组件库，确定所述投保组件库中与所述投保业务相对应的投保组件及所述投保组件的执行顺序；所述投保组件库中存储有预设的至少一个投保组件，所述投保组件用于实现投保业务中的业务逻辑；

依据所述投保组件及其执行顺序，生成用于处理所述投保业务的投保流程；其中，所述投保流程按照所述执行顺序执行所述投保组件。

第五方面，本申请实施例提供一种投保请求处理装置，包括：

投保请求获取模块，获取投保请求，所述投保请求中包括请求投保的投保业务的业务信息；

投保流程确定模块，依据所述业务信息，确定用于处理所述投保业务的投保流程；其中，所述投保流程中包括按照执行顺序执行的投保组件，所述投保组件及其执行顺序依据投保业务的业务信息和投保组件库确定，所述投保组件库中存储有预设的至少一个投保组件，所述投保组件用于实现投保业务中的业务逻辑；

投保请求处理模块，采用所述投保流程处理所述投保请求中请求投保的投保业务。

第六方面，本申请实施例提供一种电子设备，包括：

处理器；以及

被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器执行以下操作：

获取投保请求，所述投保请求中包括请求投保的投保业务的业务信息；

依据所述业务信息，确定用于处理所述投保业务的投保流程；其中，所述投保流程中包括按照执行顺序执行的投保组件，所述投保组件及其执行顺序依据投保业务的业务信息和投保组件库确定，所述投保组件库中存储有预设的至少一个投保组件，所述投保组件用于实现投保业务中的业务逻辑；

采用所述投保流程处理所述投保请求中请求投保的投保业务。

第七方面，本申请实施例提供一种投保请求处理方法，包括：

获取投保请求，所述投保请求中包括请求投保的投保业务的业务信息；

依据所述业务信息和投保组件库，确定所述投保组件库中与所述投保业务相对应的投保组件及所述投保组件的执行顺序；所述投保组件库中存储有预设的至少一个投保组件，所述投保组件用于实现投保业务中的业务逻辑；

依据所述投保组件及其执行顺序，生成用于处理所述投保业务的投保流程；其中，所述投保流程按照所述执行顺序执行所述投保组件；

采用所述投保流程处理所述投保请求中请求投保的投保业务。

本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：

本申请给出的实施例在生成投保流程时，根据投保业务的业务信息，从预先设计的投保组件库中确定出与投保业务相对应的投保组件以及这些投保组件的执行顺序，进而可以在此基础上生成按照这一执行顺序执行投保组件的投保流程。采用本申请实施例的技术方案，当需要增加新的投保业务时，由于投保组件能够实现投保业务中的业务逻辑，因此，可以依据新的投保业务所需要的业务逻辑在投保组件库中选取适当的投保组件，并可以按照新的投保业务的业务逻辑关系确定投保组件之间的执行顺序，即可生成新的投保业务所对应的投保流程。采用本申请实施例的技术方案，当需要在原有投保业务的基础上进行更新或添加不同分支时，只需根据新的投保业务的需要，既可以在投保组件库中修改原有的投保组件，也可以添加新的投保组件，既可以从投保组件库中选取新的投保组件，也可以调整投保组件间的执行顺序，从而构成与新的投保业务相适应的新的投保流程。因此，本申请实施例提供的投保流程具有更好的可扩展性和可维护性，从而可以快速的支持和满足新的业务需求。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本申请实施例中一种投保流程生成方法的流程示意图；

图2为本申请实施例中第二种投保流程生成方法的流程示意图；

图3为本申请一个实施例中的类图示意图；

图4为本申请实施例中一种投保请求处理方法的流程示意图；

图5为本申请实施例中一种投保流程生成装置的结构示意图；

图6为本申请实施例中一种电子设备的结构示意图；

图7为本申请实施例中一种投保请求处理装置的结构示意图；

图8为本申请实施例中另一种电子设备的结构示意图。

具体实施方式

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

以下结合附图，详细说明本申请各实施例提供的技术方案。

参见图1所示，本申请实施例提供了一种投保流程生成方法，包括：

s101：获取投保业务的业务信息；

s102：依据业务信息和投保组件库，确定投保组件库中与投保业务相对应的投保组件及投保组件的执行顺序；投保组件库中存储有预设的至少一个投保组件，投保组件用于实现投保业务中的业务逻辑；

s103：依据投保组件及其执行顺序，生成用于处理投保业务的投保流程；其中，投保流程按照执行顺序执行投保组件。

采用图1示例的方法生成投保流程时，可以根据投保业务的业务信息，从预先设计的投保组件库中确定出与投保业务相对应的投保组件以及这些投保组件的执行顺序，进而可以在此基础上生成按照这一执行顺序执行投保组件的投保流程。

采用上述实施例生成投保流程，当需要增加新的投保业务时，由于投保组件能够实现投保业务中的业务逻辑，因此，可以依据新的投保业务所需要的业务逻辑在投保组件库中选取适当的投保组件，并可以按照新的投保业务的业务逻辑关系确定投保组件之间的执行顺序，即可生成新的投保业务所对应的投保流程。除此之外，当需要在原有投保业务的基础上进行更新或添加不同分支时，只需根据新的投保业务的需要，既可以在投保组件库中修改原有的投保组件，也可以添加新的投保组件，既可以从投保组件库中选取新的投保组件，也可以调整投保组件间的执行顺序，从而构成与新的投保业务相适应的新的投保流程。因此，上述实施例提供的投保流程具有更好的可扩展性和可维护性，从而可以快速的支持和满足新的业务需求。

由于本申请实施例的实施依赖于投保组件库中预设的投保组件，因此，在执行步骤s102时，既可以调用或加载已经构建好的投保组件库，也可以在执行步骤s102之前，执行步骤s100构建投保组件库，参见图2所示。显然，在执行步骤s101之前执行步骤s100进行投保组件库的构建也是可行的。

执行步骤s100构建的投保组件库中，存储有预设的至少一个投保组件，这些投保组件用于实现投保业务中的业务逻辑，并且通常是投保业务中的部分业务逻辑。更具体地，步骤s100构建投保组件库，可以包括以下过程：

按照预设粒度拆分投保业务的业务逻辑，确定多个子业务逻辑；

生成用于实现子业务逻辑的投保组件；

存储投保组件，构成投保组件库。

换言之，在构建投保组件库时，可以先预设对业务逻辑的拆分粒度。本申请中所称的拆分粒度，可以理解为对投保业务的业务逻辑进行拆分所希望达到的拆分程度。

例如，用户的类型分为个人用户和企业用户，则可以按照用户类型进行拆分，将投保业务的业务逻辑拆分为针对个人用户的第一子业务逻辑和针对企业用户的第二子业务逻辑，进而分别生成用于实现第一子业务逻辑的个人投保组件和用于实现第二子业务逻辑的企业投保组件。可以理解到，以上举例的这种程度的拆分，拆分粒度较大，且个人投保组件中的第一子业务逻辑与企业投保组件中的第二子业务逻辑的具体实现过程可能存在相同的环节。例如，都需要先获取投保用户选择/输入的信息(可能包括用户自身的信息，所选保险产品的信息、所选保险机构的信息等)，再为用户展示险种、价格、询价等供用户选择，然后提示用户填写投保人和被保险人的信息等等。此时，第一子业务逻辑与第二子业务逻辑的区别可能仅仅在于针对个人用户和针对企业用户的信息格式、价格体系、价格的处理方式、优惠等营销策略等方面的不同。

又例如，在网上保险平台进行的一般投保业务的业务逻辑往往包括以下环节：阅读险种条款及有关说明、选择并进行保费试算、填写投保人及被保险人信息、在线支付、网上投保成功反馈等步骤。因此，也可以按照各环节的执行顺序进行业务逻辑的拆分，将能够实现某一具体子功能的逻辑单元确定为一个子业务逻辑。可以理解到，以上举例的这种程度的拆分，拆分粒度较小，每一投保组件所能实现的子业务逻辑是投保业务整体业务逻辑中的一部分。

在实施本申请实施例时，优选将整个投保业务的实施过程进行组件化拆分和抽象，将确定出的投保组件分为通用组件和专用组件。通用组件只处理在各类投保业务中相对稳定通用的业务逻辑，例如，被保人组件等；专用组件用来处理某类投保业务专用的逻辑，例如，企业保险询价组件等。

以图3所示的类图为例，在投保组件库中存储有多个投保组件，包括前置检查组件、用户获取组件、产品获取组件、白名单组件、询价组件、保期处理组件、险种处理组件、价格处理组件、优惠券处理组件、扩展处理组件、营销组件、收益人组件、被保人组件、付款人组件、标的组件和投保调用组件等。其中，类似前置检查组件、用户获取组件等在各类投保业务中均需要用到的投保组件，可以理解为通用组件；类似优惠券处理组件等仅在涉及到优惠券的投保业务中才会用到的投保组件，可以理解为专用组件。

更具体地说，本申请实施例定义了通用的组件接口(如图3中所示的“component”接口)和投保流程的处理器接口(如图3中所示的“handler”接口)。投保组件仅执行投保组件的子业务逻辑所实现的功能，投保流程的处理器(此处可将投保流程抽象为执行这一流程的处理器)仅执行该投保流程所包含的投保组件按照执行顺序运行所实现的功能。

本申请实施例中除定义抽象的投保组件外，还定义了投保组件的接口，并扩展出了参数检查和业务检查的方法，从而可以在每一个投保组件内部进行逻辑检查，且根据投保组件内部业务逻辑的不同而不同。

在实施图1所示的实施例时，从已经预设好的投保组件(这些投保组件存储在投保组件库中)中选取与投保业务的业务信息相对应的投保组件，用以实现投保业务的业务逻辑。可以理解到，投保组件库中存储的投保组件能够实现投保业务中的部分或者全部业务逻辑，因此，执行步骤s102将确定出至少一个投保组件以实现投保业务的业务逻辑。

基于以上抽象出的投保组件库及存储在投保组件库中的独立的投保组件，执行步骤s102依据业务信息和投保组件库，确定投保组件库中与投保业务相对应的投保组件及投保组件的执行顺序时，可具体包括：

依据业务信息和投保组件库，确定投保组件库中实现投保业务的业务逻辑所需的投保组件；

依据投保组件之间的依赖关系，确定投保组件的执行顺序。

需要说明的是，投保业务的业务信息，可以是投保业务的类型标识信息、保险产品的编号信息等，这种业务信息能够反映投保业务所需的业务逻辑，从而能够依据业务信息从投保组件库中确定出实现投保业务的业务逻辑所需的投保组件。在此基础上，为实现投保组件之间的衔接和投保流程的连贯执行，还需要根据各类投保业务的整体业务逻辑的需求对选取出的投保组件进行编排，也就是确定这些投保组件的执行顺序。在本申请实施例中，可以依据投保组件之间的依赖关系，将投保组件进行链式编排。更进一步地，投保组件间的通讯可以通过上下文来实现，从而可以快速的生成新的投保流程，支持和满足新的业务需求。

在具体实现时，投保组件中可能包括请求参数信息和/或处理结果信息，则在执行步骤s103依据投保组件及其执行顺序，生成用于处理投保业务的投保流程时，可包括：

在投保流程中预设上下文类，本申请预设的上下文类用于在构成投保流程的各个投保组件之间传递请求参数信息和/或处理结果信息；

将投保组件中的请求参数信息和/或处理结果信息与上下文类建立关联关系，从而在执行投保流程时，可以将每个投保组件的请求参数信息和/或处理结果信息写入上下文中，以便在各投保组件间进行传递；

依据投保组件及其执行顺序，生成按照执行顺序执行投保组件的投保流程。

更具体地，可以在确定投保流程中所包含的投保组件及各投保组件间的执行顺序之后，生成一组件列表(例如图3示例类图中insurehandler里面的components，即为组件列表list)，将投保流程所包含的投保组件按照其执行顺序列入该组件列表中，则在执行这一投保流程时按照组件列表中的顺序执行投保组件即可。在图3示例的类图中，通过对投保组件库中投保组件的选取及其执行顺序的确定，抽象出了三类处理器用于分别处理三类不同类型的投保业务，如图3中所示的保险卡投保处理器、赠险投保处理器和个险投保处理器。

在本申请实施例中所称的投保组件中，还可以包括依赖属性，依赖属性包括强依赖，则依据投保组件及其执行顺序生成的投保流程中，包括：

当依赖属性为强依赖的投保组件执行失败或异常时，投保流程中止，且返回投保流程执行失败或执行异常的处理结果。

进一步地，依赖属性还可包括弱依赖，则依据投保组件及其执行顺序生成的投保流程中，还包括：

当依赖属性为弱依赖的投保组件执行失败或异常时，投保流程按照执行顺序继续执行下一个投保组件。

采用本申请实施例提供的方法，假设个人保险投保业务的投保流程处理器中包含用户获取组件、产品获取组件、机构获取组件、白名单组件、询价组件、保期处理组件、险种处理组件、价格处理组件、营销组件、投保人组件、被保人组件、标的组件等投保组件。在用户请求投保时根据用户选择的产品类型，可使用该投保流程处理器处理用户提出的个人保险投保业务。而对于企业保险投保业务而言，其投保流程与个人保险投保业务大体一样，则只需将个人保险投保业务的投保流程处理器中的部分投保组件，例如询价组件、价格处理组件等，替换为适用于企业保险投保业务的投保组件，即可生成新的适用于企业保险投保业务的投保流程。

因此，在采用本申请实施例的方法生成投保流程时，利用本申请中所称的投保组件和投保组件库，能够通过对投保组件和投保组件库的更新、调整、修改、增删实现新的子业务逻辑，还可以通过选取不同的投保组件和/或调整投保组件的执行顺序快速的形成新的投保流程，克服了现有技术中烟囱式架构可扩展性差、可维护性差的缺陷，从而能够快速的支持和满足新的业务需求。

在采用本申请实施例给出的投保流程生成方法生成投保流程之后，可以直接调用已生成的投保流程(或者由投保流程抽象出的投保流程的处理器)对用户提出的投保请求进行处理。

参见图4所示，本申请实施例还提供了一种投保请求处理方法，该方法可以在生成投保流程的基础上独立进行，也可以在图1所示投保流程生成方法之后延续进行。投保请求的处理过程具体可包括：

s201：获取投保请求，投保请求中包括请求投保的投保业务的业务信息；

s202：依据业务信息，确定用于处理投保业务的投保流程；其中，投保流程中包括按照执行顺序执行的投保组件，投保组件及其执行顺序依据投保业务的业务信息和投保组件库确定，投保组件库中存储有预设的至少一个投保组件，投保组件用于实现投保业务中的业务逻辑；

s203：采用投保流程处理投保请求中请求投保的投保业务。

在上述实施例中，步骤s201获取的投保请求，通常由用户提出，用于向网上保险平台请求投保。因此，投保请求中包括请求投保的投保业务的业务信息。这里的业务信息，可以是保险产品的编号，也可以是投保业务的类型等方面的信息。

在本实施例中，在处理投保请求之前，网上保险平台已经生成并保存了与投保业务相对应的投保流程，因此，可以执行步骤s202，依据业务信息确定出相对应的投保流程，进而采用投保流程处理投保请求中请求投保的投保业务即可。

在某些应用场景下，也可以在获取到用户的投保请求之后，根据用户请求投保的投保业务进行投保组件的选取和编排，进而生成与用户的请求相对应的投保流程。具体地可包括以下步骤：

获取投保请求，所述投保请求中包括请求投保的投保业务的业务信息；

依据所述业务信息和投保组件库，确定所述投保组件库中与所述投保业务相对应的投保组件及所述投保组件的执行顺序；所述投保组件库中存储有预设的至少一个投保组件，所述投保组件用于实现投保业务中的业务逻辑；

依据所述投保组件及其执行顺序，生成用于处理所述投保业务的投保流程；其中，所述投保流程按照所述执行顺序执行所述投保组件；

采用所述投保流程处理所述投保请求中请求投保的投保业务。

采用这种方式，网上保险平台所提供的保险产品将更加灵活多变，更好地满足投保用户的个性化需求。

在图4所示的投保请求处理方法中，投保组件中可包括请求参数信息和/或处理结果信息，相对应地，投保流程中将预设有上下文类，则执行步骤s203采用投保流程处理投保请求中请求投保的投保业务时，可具体包括：

依据投保请求，初始化投保流程中的上下文信息；

按照投保流程中的执行顺序执行投保组件，并将投保组件的请求参数信息和/或处理结果信息写入上下文信息，以便在各投保组件间传递。

在投保组件的执行过程中，部分组件的执行会有返回结果(即处理结果信息)，则该组件执行完毕后，其处理结果信息可直接设置到上下文信息中，以便向其他投保组件传递。

在具体实现时，投保请求中还可包括请求投保的投保数据，则依据投保请求，初始化投保流程中的上下文信息，包括：

将投保请求中的投保数据写入上下文信息，用于在投保流程中的各投保组件之间传递。

上述实施例中所进行的初始化，主要是将用户请求的数据转换成投保流程处理器能识别的上下文信息，以便投保组件在执行时使用。除此之外，初始化时写入上下文信息的数据还可能包括服务器端的部分其他信息，例如，登录的用户id等信息。

更进一步地，投保组件中可包括依赖属性，依赖属性包括强依赖，则执行步骤s203采用投保流程处理投保请求中请求投保的投保业务时，可具体包括：

当投保流程中依赖属性为强依赖的投保组件执行失败或异常时，投保流程中止，且返回投保流程执行失败或执行异常的处理结果。

除此之外，依赖属性还可包括弱依赖，则采用投保流程处理投保请求中请求投保的投保业务，还包括：

当投保流程中依赖属性为弱依赖的投保组件执行失败或异常时，投保流程按照执行顺序继续执行下一个投保组件。

在本申请中，依赖属性为强依赖的投保组件，可以理解为该投保组件所处理的子业务逻辑是投保业务中必不可少的，而依赖属性为弱依赖的投保组件可以理解为该投保组件所处理的子业务逻辑在投保业务的处理中是可有可无的。例如，在投保业务中，投保人、被保人信息等是投保业务中的必要信息，因此，涉及到获取投保人、被投保人信息的投保组件的依赖属性就可设定为强依赖，必须执行成功才能继续执行后续的投保组件。若依赖属性为强依赖的投保组件执行失败或异常，则整个投保流程处理器中止，并返回投保流程执行失败或执行异常的处理结果。而若是埋点组件这类对投保业务的正常进行不会构成实质影响的投保组件，可将其依赖属性设定为弱依赖，则当这类投保组件执行失败或异常时，投保流程按照执行顺序继续执行下一个投保组件即可，不影响整体投保流程的执行。

基于以上描述，本申请实施例还可提供一种投保流程生成装置，参见图5所示，包括：

业务信息获取模块101，获取投保业务的业务信息；

投保组件确定模块102，依据业务信息和投保组件库，确定投保组件库中与投保业务相对应的投保组件及投保组件的执行顺序；投保组件库中存储有预设的至少一个投保组件，投保组件用于实现投保业务中的业务逻辑；

投保流程生成模块103，依据投保组件及其执行顺序，生成用于处理投保业务的投保流程；其中，投保流程按照执行顺序执行投保组件。

基于以上描述，本申请实施例还可提供一种电子设备，参见图6所示，包括：

处理器；以及

被安排成存储计算机可执行指令的存储器，可执行指令在被执行时使处理器执行以下操作：

获取投保业务的业务信息；

依据业务信息和投保组件库，确定投保组件库中与投保业务相对应的投保组件及投保组件的执行顺序；投保组件库中存储有预设的至少一个投保组件，投保组件用于实现投保业务中的业务逻辑；

依据投保组件及其执行顺序，生成用于处理投保业务的投保流程；其中，投保流程按照执行顺序执行投保组件。

图6是本申请的一个实施例电子设备的结构示意图。请参考图6，在硬件层面，该电子设备包括处理器，可选地还包括内部总线、网络接口、存储器。其中，存储器可能包含内存，例如高速随机存取存储器(random-accessmemory，ram)，也可能还包括非易失性存储器(non-volatilememory)，例如至少1个磁盘存储器等。当然，该电子设备还可能包括其他业务所需要的硬件。

处理器、网络接口和存储器可以通过内部总线相互连接，该内部总线可以是isa(industrystandardarchitecture，工业标准体系结构)总线、pci(peripheralcomponentinterconnect，外设部件互连标准)总线或eisa(extendedindustrystandardarchitecture，扩展工业标准结构)总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图6中仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。

存储器，用于存放程序。具体地，程序可以包括程序代码，所述程序代码包括计算机操作指令。存储器可以包括内存和非易失性存储器，并向处理器提供指令和数据。

处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成投保流程生成装置。处理器，执行存储器所存放的程序，并具体用于执行以下操作：

获取投保业务的业务信息；

依据业务信息和投保组件库，确定投保组件库中与投保业务相对应的投保组件及投保组件的执行顺序；投保组件库中存储有预设的至少一个投保组件，投保组件用于实现投保业务中的业务逻辑；

依据投保组件及其执行顺序，生成用于处理投保业务的投保流程；其中，投保流程按照执行顺序执行投保组件。

上述如本申请图1所示实施例揭示的投保流程生成装置执行的方法可以应用于处理器中，或者由处理器实现。处理器可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器，包括中央处理器(centralprocessingunit，cpu)、网络处理器(networkprocessor，np)等；还可以是数字信号处理器(digitalsignalprocessor，dsp)、专用集成电路(applicationspecificintegratedcircuit，asic)、现场可编程门阵列(field－programmablegatearray，fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。

该电子设备还可执行图1中投保流程生成装置执行的方法，并实现投保流程生成装置在图1所示实施例的功能，本申请实施例在此不再赘述。

本申请实施例还提出了一种计算机可读存储介质，该计算机可读存储介质存储一个或多个程序，该一个或多个程序包括指令，该指令当被包括多个应用程序的电子设备执行时，能够使该电子设备执行图1所示实施例中应用页面截图上报装置执行的方法，并具体用于执行：

获取投保业务的业务信息；

依据所述业务信息和投保组件库，确定所述投保组件库中与所述投保业务相对应的投保组件及所述投保组件的执行顺序；所述投保组件库中存储有预设的至少一个投保组件，所述投保组件用于实现投保业务中的业务逻辑；

依据所述投保组件及其执行顺序，生成用于处理所述投保业务的投保流程；其中，所述投保流程按照所述执行顺序执行所述投保组件。

基于以上描述，本申请实施例还可提供一种投保请求处理装置，参见图7所示，包括：

投保请求获取模块201，获取投保请求，投保请求中包括请求投保的投保业务的业务信息；

投保流程确定模块202，依据业务信息，确定用于处理投保业务的投保流程；其中，投保流程中包括按照执行顺序执行的投保组件，投保组件及其执行顺序依据投保业务的业务信息和投保组件库确定，投保组件库中存储有预设的至少一个投保组件，投保组件用于实现投保业务中的业务逻辑；

投保请求处理模块203，采用投保流程处理投保请求中请求投保的投保业务。

基于以上描述，本申请实施例还可提供一种电子设备，参见图8所示，包括：

处理器；以及

被安排成存储计算机可执行指令的存储器，可执行指令在被执行时使处理器执行以下操作：

获取投保请求，投保请求中包括请求投保的投保业务的业务信息；

依据业务信息，确定用于处理投保业务的投保流程；其中，投保流程中包括按照执行顺序执行的投保组件，投保组件及其执行顺序依据投保业务的业务信息和投保组件库确定，投保组件库中存储有预设的至少一个投保组件，投保组件用于实现投保业务中的业务逻辑；

采用投保流程处理投保请求中请求投保的投保业务。

图8是本申请的一个实施例电子设备的结构示意图。请参考图8，在硬件层面，该电子设备包括处理器，可选地还包括内部总线、网络接口、存储器。其中，存储器可能包含内存，例如高速随机存取存储器(random-accessmemory，ram)，也可能还包括非易失性存储器(non-volatilememory)，例如至少1个磁盘存储器等。当然，该电子设备还可能包括其他业务所需要的硬件。

处理器、网络接口和存储器可以通过内部总线相互连接，该内部总线可以是isa(industrystandardarchitecture，工业标准体系结构)总线、pci(peripheralcomponentinterconnect，外设部件互连标准)总线或eisa(extendedindustrystandardarchitecture，扩展工业标准结构)总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图8中仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。

存储器，用于存放程序。具体地，程序可以包括程序代码，所述程序代码包括计算机操作指令。存储器可以包括内存和非易失性存储器，并向处理器提供指令和数据。

处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成投保请求处理装置。处理器，执行存储器所存放的程序，并具体用于执行以下操作：

获取投保请求，投保请求中包括请求投保的投保业务的业务信息；

依据业务信息，确定用于处理投保业务的投保流程；其中，投保流程中包括按照执行顺序执行的投保组件，投保组件及其执行顺序依据投保业务的业务信息和投保组件库确定，投保组件库中存储有预设的至少一个投保组件，投保组件用于实现投保业务中的业务逻辑；

采用投保流程处理投保请求中请求投保的投保业务。

上述如本申请图4所示实施例揭示的投保请求处理装置执行的方法可以应用于处理器中，或者由处理器实现。处理器可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器，包括中央处理器(centralprocessingunit，cpu)、网络处理器(networkprocessor，np)等；还可以是数字信号处理器(digitalsignalprocessor，dsp)、专用集成电路(applicationspecificintegratedcircuit，asic)、现场可编程门阵列(field－programmablegatearray，fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。

该电子设备还可执行图4中投保请求处理装置执行的方法，并实现投保请求处理装置在图4所示实施例的功能，本申请实施例在此不再赘述。

本申请实施例还提出了一种计算机可读存储介质，该计算机可读存储介质存储一个或多个程序，该一个或多个程序包括指令，该指令当被包括多个应用程序的电子设备执行时，能够使该电子设备执行图1所示实施例中应用页面截图上报装置执行的方法，并具体用于执行：

获取投保请求，所述投保请求中包括请求投保的投保业务的业务信息；

依据所述业务信息，确定用于处理所述投保业务的投保流程；其中，所述投保流程中包括按照执行顺序执行的投保组件，所述投保组件及其执行顺序依据投保业务的业务信息和投保组件库确定，所述投保组件库中存储有预设的至少一个投保组件，所述投保组件用于实现投保业务中的业务逻辑；

采用所述投保流程处理所述投保请求中请求投保的投保业务。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flashram)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitorymedia)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。