本说明书一个或多个实施例涉及信息技术领域，尤其涉及一种团单处理方法和系统。
背景技术：
计算机应用技术是一门用来分析计算机应用于社会各行业、各领域的技术、方法、理论及系统的学科。例如，计算机技术可以应用于保险行业中，可以利用计算机手段解决业务办理中的问题。
使用计算机进行业务处理时，会涉及到信息处理，信息作为一种资源，它的普遍性、增值性、可处理性和多效用性，使其对于人类具有特别重要的意义。信息安全的实质就是要保护信息系统或信息网络中的信息资源免受各种类型的威胁、干扰和破坏，需要保证信息的保密性、真实性、完整性、未授权拷贝、和所寄生系统的安全性。而使用计算机处理团单时，需要在短时间内处理大量信息，会产生业务数量挤压，处理效率下降的问题。
因此，需要一种团单处理方法，用于提升计算机系统对团单的处理效率。
技术实现要素：
有鉴于此，本说明书一个或多个实施例的目的在于提出一种团单处理方法，以解决提升计算机系统对团单的处理效率的问题。
基于上述目的，本说明书一个或多个实施例提供了一种团单处理方法，包括：互联网应用获取团单信息，从所述团单信息中解析出清单信息，并将所述清单信息发送至核心业务系统；所述核心业务系统基于业务预估规则和接收到的所述清单信息，对所述团单进行业务预估，得到业务预估结果，并将所述业务预估结果返回至所述互联网应用；响应于接收到用户输入的对所述业务预估结果的确认信息，所述互联网应用将指示确认提交所述团单的团单确认提交指令发送至所述核心业务系统；响应于所述团单确认提交指令，所述核心业务系统通过后台线程从所述互联网应用导入所述团单信息，基于业务处理规则处理所述团单信息，得到对所述团单的业务处理结果。
在一种可能的实现方式中，还包括：所述核心业务系统通过kafka分布式消息队列，将指示所述业务处理结果的消息推送给所述互联网应用。
在一种可能的实现方式中，响应于所述团单确认提交指令，所述核心业务系统通过后台线程从所述互联网应用导入所述团单信息，基于业务处理规则处理所述团单信息，得到对所述团单的业务处理结果，包括：建立线程池，所述线程池对用于处理所述团单信息的线程进行调度，包括：获取所述团单信息的到达时间；查询所述线程池中是否存在空闲线程；如果查询结果为是，则调用空闲的线程处理所述团单信息；如果查询结果为否，则计算获得空闲线程的等待时间，根据所述团单信息的到达时间和所述空闲线程的等待时间将所述团单信息分配至对应的空闲线程等待队列。
在一种可能的实现方式中，所述核心业务系统基于业务预估规则和接收到的所述清单信息，对所述团单进行业务预估，得到业务预估结果，并将所述业务预估结果返回至所述互联网应用，包括：调用所述核心业务系统的接口；通过所述核心业务系统的接口导入所述团单信息中的规则和金额，所述核心业务系统根据导入的所述团单信息中的规则和金额进行试算，将试算后的结果生成为所述业务预估结果。
在一种可能的实现方式中，所述核心业务系统基于业务预估规则和接收到的所述清单信息，对所述团单进行业务预估，还包括：通过所述核心业务系统的规则引擎对所述团单信息进行校验，如果所述团单信息无法通过所述规则引擎的校验，则向所述互联网应用发送警告信息；对所述团单信息和所述清单信息进行缓存，并设立所述团单信息和所述清单信息的缓存时间，缓存时间结束后，清除所述团单信息和所述清单信息。
在一种可能的实现方式中，基于业务处理规则处理所述团单信息，还包括：所述核心业务系统的规则引擎对所述团单信息进行规则校验；如果所述规则校验发生异常，则查找异常原因，将所述异常原因推送并停止处理所述团单信息；其中，所述规则校验至少包括校验字段数量是否符合或字段间关系是否符合中的一个。
在一种可能的实现方式中，还包括：对所述团单的业务处理结果进行分类，获得所述团单的业务处理结果的类别；将所述团单的业务处理结果存入与其类别对应的订阅消息队列；所述团单的业务处理结果由其所存入的订阅消息队列推送；对所述订阅消息队列中所述团单的业务处理结果的保存时间进行配置，如果所述保存时间结束，则删除所述团单的业务处理结果。
在一种可能的实现方式中，还包括：通过移动客户端搜集独立团单信息；所述移动客户端将搜集到的所述独立团单信息发送至所述互联网应用；所述互联网应用调度线程处理所述独立团单信息并生成所述独立团单信息的处理结果；所述互联网应用向发送所述独立团单信息的移动客户端推动所述独立团单信息的处理结果；所述互联网应用对多个所述独立团单信息进行整合并生成所述团单信息。
在一种可能的实现方式中，响应于所述团单确认提交指令，所述核心业务系统通过后台线程从所述互联网应用导入所述团单信息，基于业务处理规则处理所述团单信息，得到对所述团单的业务处理结果，包括：使用线程池进行试算，所述线程池的核心线程数为2至20个，最大线程数为20个至50个，等待队列为100至500个；通过接口创建异步任务，并通过所述线程池异步执行清单校验任务；所述清单校验任务完成后，将获得的试算结果返回。
本说明书一个或多个实施例提供了一种团单处理系统，包括：互联网应用模块，用于获取团单信息，从所述团单信息中解析出清单信息，并将所述清单信息发送至核心业务系统服务器；所述核心业务系统服务器，基于业务预估规则和接收到的所述清单信息，对所述团单进行业务预估，得到业务预估结果，并将所述业务预估结果返回至所述互联网应用模块；所述互联网应用模块接收用户输入的对所述业务预估结果的确认信息，所述互联网应用模块将指示确认提交所述团单的团单确认提交指令发送至所述核心业务系统服务器；所述核心业务系统服务器接收所述团单确认提交指令，所述核心业务系统通过后台线程从所述互联网应用模块导入所述团单信息，基于业务处理规则处理所述团单信息，得到对所述团单的业务处理结果。
从上面所述可以看出，本说明书一个或多个实施例提供的团单处理方法，引入互联网应用，可以简化团单录入的处理流程；通过引入异步处理方式，可以提升团单的处理速度，提升业务办理效率。亦即，上述方法可以提升计算机系统对团单的处理效率。
附图说明
为了更清楚地说明本说明书一个或多个实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本说明书一个或多个实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为本说明书一个或多个实施例中团单处理方法的流程示意图；
图2为本说明书一个或多个实施例中保险业务团单处理的流程示意图；
图3为本实施例所提供的一种更为具体的电子设备硬件结构示意图。
具体实施方式
为使本公开的目的、技术方案和优点更加清楚明白，以下结合具体实施例，并参照附图，对本公开进一步详细说明。
需要说明的是，除非另外定义，本说明书一个或多个实施例使用的技术术语或者科学术语应当为本公开所属领域内具有一般技能的人士所理解的通常意义。本说明书一个或多个实施例中使用的“第一”、“第二”以及类似的词语并不表示任何顺序、数量或者重要性，而只是用来区分不同的组成部分。“包括”或者“包含”等类似的词语意指出现该词前面的元件或者物件涵盖出现在该词后面列举的元件或者物件及其等同，而不排除其他元件或者物件。“连接”或者“相连”等类似的词语并非限定于物理的或者机械的连接，而是可以包括电性的连接，不管是直接的还是间接的。“上”、“下”、“左”、“右”等仅用于表示相对位置关系，当被描述对象的绝对位置改变后，则该相对位置关系也可能相应地改变。
本说明书实施例中所述支付涉及的技术载体，例如可以包括近场通信(nearfieldcommunication，nfc)、wifi、3g/4g/5g、pos机刷卡技术、二维码扫码技术、条形码扫码技术、蓝牙、红外、短消息(shortmessageservice，sms)、多媒体消息(multimediamessageservice，mms)等。
本说明书实施例中所述生物识别所涉及的生物特征，例如可以包括眼部特征、声纹、指纹、掌纹、心跳、脉搏、染色体、dna、人牙咬痕等。其中眼纹可以包括虹膜、巩膜等生物特征。
需要说明的是，普通保单团体业务(团单)，是指以团体单位或团体单位中的特定团体为投保人、为其5人以上(除条款另有规定外)特定团体成员(可包括成员配偶、子女和父母)投保，由保险人用一份保险合同提供保险保障的业务。
需要说明的是，增加被保险人，是指增加被保险人是指在团体保险合同有效期内，投保人申请对原保险合同增加一名或若干名被保险人(含附带被保险人，部分条款称为“连带被保险人”)的业务行为。
需要说明的是，减少被保险人，是指减少被保险人(含附带被保险人，部分条款称“连带被保险人”)是指在保险期间内，投保人申请将原保险合同减少一名或若干名被保险人，其他被保险人保险责任不变的业务行为。减少被保险人也可视作保险合同的部分退保。
团单增减人是保险公司团体业务中处理量较大的两项保全业务，增减人业务均由企业客户提交申请，并将资料提交至保险公司柜面进行处理。正常保全业务分为保全受理、处理两步，分别由柜面受理岗和处理岗两个角色进行操作。
在一种可能的实现方式中，可以采用如下步骤处理保全业务：
步骤1：受理岗使用excel对客户提交的名单进行手工初筛，筛选错误比较明显的人员信息，如个人信息不完整、增人名单中已经在保、减人名单中没有承保等。
步骤2：通过逐条录入或者批量导入的方式录入核心业务系统，核心业务系统通过规则引擎对录入的清单进行业务规则校验，如并计算出应收应付的金额。
步骤3：针对有超保额、追溯生效日超期等问题的记录，系统提示操作人员修改或者剔除。
步骤4：受理岗对名单进行修改和确认后提交处理，完成保全受理；
步骤5：处理岗接到处理任务后，确认受理内容与产生金额，针对特殊情况进行审核确认，提交后保全处理完成，产生应收应付。
步骤6：处理岗通知客户进行收付费，完成后保全生效，业务处理完成。
对于上述步骤，可以引入互联网应用，通过互联网应用辅助完成客户信息的搜集和校验，从而可以在短时间内处理大量的客户信息，提升保全业务系统对团单的处理效率。
一方面，通过提供互联网应用，可以支持企业客户身份认证，实现客户在线自助受理增减人业务，从而解决业务处理不透明的问题，同时可以大幅降低柜面人员工作量，节约人力成本。
另一方面，可以利用互联网通信技术，使用restful(representationalstatetransfer，表现层状态转移)的方式实现互联网应用与核心业务系统之间的数据交互。
另一方面，用户数据导入和系统间数据传输可以采用异步处理方式，解决用户长时间在页面等待的问题，避免页面超时，提升用户体验。
另一方面，可以去掉中间状态，实现用户一次提交就完成全部受理和处理过程，避免未完成业务的产生。
另一方面通过消息推送技术可以实时通知处理结果，用户可以随时了解处理情况并及时进行收付费，解决人工通知的效率问题，同时可以避免由于通知不及时导致的业务脱落的情况。
本说明书一个或多个实施例提供一种团单处理方法，如图1所示，图1为本说明书一个或多个实施例中团单处理方法的流程示意图，包括：
步骤s10：互联网应用获取团单信息，从团单信息中解析出清单信息，并将清单信息发送至核心业务系统。
团单信息包括多种信息，例如需要增加的被保险人的信息，或者需要减少的被保险人信息，或者需要更改的保险业务类型等，对于具体的团单信息可以根据实际需要进行选择，在此不作限定。
需要说明的是，团单信息中的团单可以是一份保险合同中包含多个投保人，该份保险合同可以由一人代理全员进行操作，及该份保险合同的签订由一人代理即可完成。
互联网应用用于向用户提供数据库的访问或操作工具，例如，供b/s架构(浏览器和服务器架构模式)的在线服务。需要说明的是，互联网应用可以具有合理的安全措施，不需要向用户提供数据库访问工具，并且用户不能直接访问数据库。
清单信息来源于团单信息，清单信息可以根据实际需要进行定制，例如人员清单、金额清单。清单信息中的字段可以根据预设规则从团单信息中进行提取。举例来说，人员清单的预设规则包括提取姓名字段、身份证号字段、联系电话字段；或者金额清单的预设规则包括提取姓名字段、保险额度字段；总而言之，可以根据实际需要设置预设规则，用于从团单信息中提取所需字段及字段下的信息。
需要说明的是，规则引擎可以用来进行规则校验，例如校验待增客户是否存在已签订业务契约，是否有其它在途业务，从而判断当前数据能否正常进行该笔业务，并对违反业务规则无法继续处理的数据提示异常原因，具体的规则校验可以根据实际需要进行选择，在此不作限定。
在一种可能的实现方式中，互联网应用提供模板下载功能，用户按照模板填写信息。互联网应用按照模板中设置的列进行解析，从而解析出清单信息，例如人员清单。举例来说，互联网应用提供的模板可以包括姓名列、身份证号列、联系电话列，用户按照模板填写完信息后，可从模板的姓名列、身份证号列、联系电话列中解析出相应的用户姓名、用户身份证号和用户联系电话，再将这些信息整合后生成人员清单。
在一种可能的实现方式中，从团单信息中解析出清单信息包括从团单信息中获取所需生成的清单的类型，根据清单类型判断需要从团单信息中提取的字段，利用提取的字段生成清单信息。举例来说，可以在团单信息中设置“清单类型”列，从“清单类型”列下的数值可以解析出须从该团单信息中解析出的清单类型。
在步骤s10中，从团单信息中解析出清单信息包括，分析清单信息，以对清单信息进行初步校验，例如校验清单中的数值格式是否正确、用户身份是否正确等；如果初步校验结构发现异常，则对清单信息进行处理，对清单信息的处理包括标注异常原因，或者通过互联网应用将清单信息和异常原因一并返回。从团单信息中解析出清单信息的具体步骤可以根据实际需要进行选择，只要能够保证后续步骤的顺利进行即可，在此不作限定。
在一种可能的实现方式中，互联网应用获取团单信息可以通过客户端进行，客户端可以为一个，也可以为分布式的多个。
步骤s20：核心业务系统基于业务预估规则和接收到的清单信息，对团单进行业务预估，得到业务预估结果，并将业务预估结果返回至互联网应用。
需要说明的是，核心业务系统可以部署在专用网络中，保证核心业务数据的安全性。核心业务系统提供基础的规则引擎和业务处理服务，例如：
1、提供查询和试算服务，用于正式受理前的检查，以确保受理后业务的正常处理。
2、提供保全受理服务，生成业务流水号，用于后续结果查询的凭证
3、提供清单导入服务，并在导入结束后完成所有保全受理操作，避免人工介入。
4、保全处理结束后，将处理结果推送至消息队列。
具体的，核心业务系统可以由一台或者多台服务器构成，或者由工作站构成，对于核心业务系统的构成方式可以根据实际需要进行选择，只能能够提供基础的规则引擎和业务处理服务即可，对此不作限定。
另一方面，规则引擎可以用来进行保单上业务规则的校验，例如待增客户是否在保，是否有其它在途业务，从而判断当前数据能否正常进行该笔保全业务，并对违反业务规则无法继续处理的数据提示原因。
在步骤s20中，核心业务系统基于业务预估规则和接收到的清单信息，对团单进行业务预估，可以包括调用规则引擎对团单信息进行规则校验，或者对团单即将产生的金额进行试算。
在步骤s20中，对清单信息进行业务预估得到的业务预估结果可以为一个或者多个，例如规则引擎对团单信息进行规则校验的结果，对团单即将产生的金额进行试算的结果等，对清单信息进行业务预估得到的业务预估结果可以根据实际需要进行选择，在此不作限定。
举例来说，如果规则引擎对团单信息进行规则校验的结果为通过，则业务预估结果为通过；或者对团单即将产生的金额进行试算后得到的具体金额数值，则该具体金额数值为业务预估结果。
在一种可能的实现方式中，业务预估规则可以包括用于计算团单即将产生的金额的规则。例如，业务预估规则可以是投保年数乘以每年的保额；或者，业务预估规则可以是投保年数乘以每年的保额乘以减免系数，其中减免系数可以根据已投保年数进行确定。
在一种可能的实现方式中，业务预估规则可以包括用于校验用户能够投保的规则。例如，业务预估规则可以是检验用户的年龄是否在预设范围内的规则；或者，业务预估规则可以是检验用户以往保单是否过期的规则。
需要说明的是，业务预估规则可以根据实际需要进行设定，只要能够根据业务预估规则得出业务预估结果即可，对此不作限定。
步骤s30：响应于接收到用户输入的对业务预估结果的确认信息，互联网应用将指示确认提交团单的团单确认提交指令发送至核心业务系统。
举例来说，对团单即将产生的金额进行试算，将预估的结果展示给用户，由用户决定是否终止业务，避免产生中间状态。如果用户对试算后的金额表示确认，则继续后续的签单步骤，如果用户对试算后的金额表示拒绝，则停止进行后续步骤。
在一种可能的实现方式中，如果接收到用户输入的对业务预估结果的确认信息为否，则停止进行后续步骤，互联网应用将确认信息发送至核心业务系统后，不再调用核心业务系统的接口。
在一种可能的实现方式中，如果接收到用户输入的对业务预估结果的确认信息为是，则互联网应用将确认信息发送至核心业务系统后，继续进行后续步骤。
步骤s40：响应于团单确认提交指令，核心业务系统通过后台线程从互联网应用导入团单信息，基于业务处理规则处理团单信息，得到对团单的业务处理结果。
在此步骤中，后台线程的调用方式可以根据实际需要进行选择，例如使用线程池进行，或者使用已有的全部空闲线程进行，或者开启新的线程进行等，只要能够异步处理团单信息即可，具体的后台线程调用方式在此不作限定。
在此步骤中，基于业务处理规则处理团单信息可以包括将团单信息录入核心业务系统，也可以通过业务处理规则以确保录入核心业务系统的团单信息合乎规则且正确。
在此步骤中，可以采用异步处理方式进行处理，通过同一周期内多个线程的并行处理，提升核心业务系统处理团单信息的效率。
需要说明的是，业务处理规则可以根据实际需要进行设定，对此不作限定。
通过上述方法，引入互联网应用，可以简化团单录入的处理流程；通过引入异步处理方式，可以提升团单的处理速度，提升业务办理效率。亦即，上述方法可以提升计算机系统对团单的处理效率。
另一方面，通过互联网应用处理用户提交的团单信息，可以使用户自己完成团单信息的提交，而不需要受理岗的人工辅助，可以使处理过程对用户透明话，提高用户参与度。
另一方面，通过互联网应用的自动化处理，可以避免业务量大导致的时常积压，提升业务处理效率。
另一方面，在核心业务系统与用户端之间增加互联网应用，受理过程中的修改和确认步骤设置于互联网应用进行处理，核心业务系统的调用与用户端间的操作分开，可以避免等待处理结果时产生中间态，也可以避免产生未操作完成的业务。
另一方面，将对团单的业务处理结果进行推送，可以避免人工参与导致的额外操作。例如，每笔业务企业对口提交人不一致，系统无法判断通知接收人，则其后需要人工处理，人工发送收付费通知。
在一种可能的实现方式中，核心业务系统通过kafka分布式消息队列，将指示业务处理结果的消息推送给互联网应用。通过此种方式，可以及时告知用户团单的处理结果，提升用户体验。
在一种可能的实现方式中，响应于团单确认提交指令，核心业务系统通过后台线程从互联网应用导入团单信息，基于业务处理规则处理团单信息，得到对团单的业务处理结果，包括：
建立线程池，线程池对用于处理团单信息的线程进行调度，该步骤还包括：
步骤s41：获取团单信息的到达时间。
步骤s42：查询线程池中是否存在空闲线程。
步骤s43：如果查询结果为是，则调用空闲的线程处理团单信息。
如果查询结果为否，则计算获得空闲线程的等待时间，根据团单信息的到达时间和空闲线程的等待时间将团单信息分配至对应的空闲线程等待队列。例如，将团单信息分配至到达时间与等待时间最接近的空闲线程等待队列。
通过上述方法，引入线程池来进行异步处理，可以优化对线程的利用效率，减小对系统资源的占用，提升核心业务系统处理团单信息的效率。
在一种可能的实现方式中，响应于团单确认提交指令，核心业务系统通过后台线程从互联网应用导入团单信息，基于业务处理规则处理团单信息，得到对团单的业务处理结果，包括：
使用线程池进行试算，线程池的核心线程数为2至20个，最大线程数为20个至50个，等待队列为100至500个。
通过接口创建异步任务，并通过线程池异步执行清单校验任务。
清单校验任务完成后，将获得的试算结果返回。
举例来说，上述步骤可以为：
步骤a41：使用线程池threadpooltaskexecutor进行试算，核心线程数10，最大线程数30，等待队列300。
步骤a42：异步上传清单，通过runnable接口创建异步任务，并通过线程池异步执行清单校验任务。
步骤a43：通过callable接口调用试算接口，通过future返回接口调用结果，通过future.get()等待接口处理完成，并将结果返回给service层进行处理。
通过上述方法，引入线程池来进行异步处理，可以优化对线程的利用效率，减小对系统资源的占用，提升核心业务系统处理团单信息的效率。
在一种可能的实现方式中，可以通过互联网应用获取团单信息，互联网应用从团单信息中解析出清单信息并对清单信息进行分析和处理，包括：
步骤s11：提取团单信息中的字段信息，将字段信息按照预设规则存入清单数组。
步骤s12：从字段信息中提取出须生成的清单类型，根据清单类型从清单数组中提取出所需的字段信息，并且利用提取出的所需的字段信息生成清单信息。
通过上述方法，可以从团单信息中获得清单信息，则即可在互联网应用通过信息量较小的清单信息对团单信息进行初步验证，例如验证团单信息是否合乎规则或者是否安全。
在一种可能的实现方式中，核心业务系统基于业务预估规则和接收到的清单信息，对团单进行业务预估，得到业务预估结果，并将业务预估结果返回至互联网应用，包括：
步骤s31：调用核心业务系统的接口。
步骤s32：通过核心业务系统的接口导入团单信息中的规则和金额，核心业务系统根据导入的团单信息中的规则和金额进行试算，将试算后的结果生成为业务预估结果。
通过上述方法，可以将预估的结果展示给用户，由用户决定是否终止业务，避免产生中间状态。
举例来说，在保险团单业务中，调用核心系统提供的接口进行规则和金额的试算，在业务受理之前对业务处理结果进行预估，并将预估的结果展示给用户，由用户决定是否终止业务，避免产生中间状态。
在一种可能的实现方式中，核心业务系统基于业务预估规则和接收到的清单信息，对团单进行业务预估，还包括：
通过核心业务系统的规则引擎对团单信息进行校验，如果团单信息无法通过规则引擎的校验，则向互联网应用发送警告信息。通过这一步骤，减小用户误操作的概率。
或者，对团单信息和清单信息进行缓存，并设立团单信息和清单信息的缓存时间，缓存时间结束后，清除团单信息和清单信息。通过这一步骤，节省系统资源。
在一种可能的实现方式中，核心业务系统基于业务预估规则和接收到的清单信息，对团单进行业务预估，还包括：
通过核心业务系统的规则引擎对团单信息进行校验，如果团单信息无法通过规则引擎的校验，则向互联网应用发送警告信息。通过这一步骤，减小用户误操作的概率。
以及，对团单信息和清单信息进行缓存，并设立团单信息和清单信息的缓存时间，缓存时间结束后，清除团单信息和清单信息。通过这一步骤，节省系统资源。
在一种可能的实现方式中，基于业务处理规则处理团单信息，还包括：
通过核心业务系统的规则引擎对团单信息进行规则校验。
如果规则校验发生异常，则查找异常原因，将异常原因推送并停止处理团单信息。
其中，规则校验至少包括校验字段数量是否符合或字段间关系是否符合中的一个。
在一种可能的实现方式中，上述方法还包括：
步骤b1：对团单的业务处理结果进行分类，获得团单的业务处理结果的类别。
步骤b2：将团单的业务处理结果存入与其类别对应的订阅消息队列。
步骤b3：团单的业务处理结果由其所存入的订阅消息队列推送。
步骤b4：对订阅消息队列中团单的业务处理结果的保存时间进行配置，如果保存时间结束，则删除团单的业务处理结果。
在一种可能的实现方式中，对团单的业务处理结果进行推送，包括：采用kafka分布式消息队列(卡夫卡队列)进行推送。
需要说明的是，kafka是一个高吞吐量的分布式发布订阅消息系统，一般为集群式部署。kafka将消息分为多个主题(topic)，每个主题包含多个分区(partition)，每个分区会有多个副本(replication)，这种设置方便扩展的同时可以提高并发。生产者将消息按早预先设置的规则写入不同的分区，即可继续处理其它业务。kafka将数据顺序保存到磁盘。消费者按照分区进行数据的消费，分区的数量一般与消费者的数量相同。
需要说明的是，一方面，采用kafka分布式消息队列，具有高性能、持久化、多副本、可横向拓展等特点。
另一方面，kafka将消息进行分类，每一类消息称之为一个主题(topic)。核心业务系统作为生产者往topic中写消息，即将保全处理结果写入队列；互联网应用作为消费者从topic中读消息，即从消息队列中获取处理结果，并推送给用户。
另一方面，kafka可将消息保存一段时间，以确保消息在被消费之前不会丢失。根据消费端的需求对消息的保存时长进行配置。
通过上述方法，可以及时告知用户团单的处理结果，提升用户体验。
在一种可能的实现方式中，本说明书一个或多个实施例中的方法，还可以通过移动客户端搜集独立团单信息。包括：
步骤c1：移动客户端将搜集到的独立团单信息发送至互联网应用。
步骤c2：互联网应用调度线程处理独立团单信息并生成独立团单信息的处理结果。
步骤c3：互联网应用向发送独立团单信息的移动客户端推动独立团单信息的处理结果；
步骤c4：互联网应用对多个独立团单信息进行整合并生成团单信息。
通过上述方法，可以减缓单个客户端搜集团单信息的压力。
本说明书一个或多个实施例还提供一种保险业务团单处理的方法，如图2所示，图2为本说明书一个或多个实施例中保险业务团单处理的流程示意图。该方法包括部署客户浏览器、互联网应用、核心业务系统及消息队列四个部分。
具体的，互联网应用可以向企业用户提供b/s架构的在线服务，客户只要通过联网的浏览器，就可以进行保全受理操作。互联网应用可以进行如下操作：
1、该应用采用授权的方式创建用户账号，用户线下提交一次授权申请，由保险公司管理人员审核通过后，便可通过身份证号进行登录，登录时需要通过申请中提交的手机号或者邮箱接收动态验证码以完成身份认证。
2、该应用使用alibaba/easyexcel框架实现excel的解析，支持从用户上传的清单列表中解析出人员清单，对清单做初步的校验。
3、调用核心系统提供的接口进行规则和金额的试算，在业务受理之前对业务处理结果进行预估，并将预估的结果展示给用户，由用户决定是否终止业务，避免产生中间状态。
4、用户确认提交后，调用受理和导入接口，正式提交核心。由于一次导入的清单数量较多，为避免用户长时间等待，导致浏览器session超时，导入操作采用异步处理方式，用户提交后本次浏览器交互结束，由后台线程处理导入操作。
5、提交结束后，订阅消息队列的通知，并将处理结果及时推送给用户。
具体的，核心业务系统可以部署在专用网络中，保证核心业务数据的安全性。核心业务系统可以提供基础的规则引擎和业务处理服务，例如：
1、提供查询和试算服务，用于正式受理前的检查，以确保受理后业务的正常处理。
2、提供保全受理服务，生成业务流水号，用于后续结果查询的凭证
3、提供清单导入服务，并在导入结束后完成所有保全受理操作，避免人工介入。
4、保全处理结束后，将处理结果推送至消息队列。
具体的，消息队列可以保存增减人业务处理结果，提供订阅服务，例如：
1、采用kafka分布式消息队列，该队列具有高性能、持久化、多副本、可横向拓展等特点。
2、kafka将消息进行分类，每一类消息称之为一个主题(topic)。核心业务系统作为生产者往topic中写消息，即将保全处理结果写入队列；互联网应用作为消费者从topic中读消息，即从消息队列中获取处理结果，并推送给用户。
3、kafka可将消息保存一段时间，以确保消息在被消费之前不会丢失。根据消费端的需求对消息的保存时长进行配置。
另外，用户确认提交后，清单导入采用异步处理，无需页面长时间等待，避免因数据量大需长时间等待导致页面超时。具体的：
1、用户在确认提交后，就完成前端页面的操作，由后台线程完成名单导入的流程。
2、使用线程池的方式处理多前端的并发，避免因线程过多而产生的调度开销，提升系统的整体性能。
各部分间的信息流程如下：
用户在客户浏览器上选择保单，然后互联网应用根据用于选择的保单，向核心业务系统请求查询契约信息。
核心业务系统接收到互联网应用的请求后，向互联网应用发送其请求的契约信息或者模板。
互联网应用接收到契约信息或者模板后，向客户浏览器返回保单信息。
客户浏览器接收到保单信息后，上传增减人员列表至互联网应用。互联网应用收到增减人员列表后，互联网应用向核心业务系统发送解析模板的请求，模板解析完成后，核心业务系统将解析结果发送至互联网应用。
核心业务系统从解析结果中获得人员清单，并根据互联网应用的请求进行人员试算，试算结束后，将试算结果返回至客户浏览器。另外，核心业务系统利用规则引擎对试算结果进行规则校验。
客户浏览器接收到试算结果后，将试算结果发送至客户浏览器，客户浏览器显示试算结果。
客户浏览器显示试算结果后，用户通过客户浏览器确认提交。
互联网应用收到确认提交的信息后，向核心业务系统发送保全受理的请求。核心业务系统收到请求后，向互联网应用返回保全流水号，并向消息队列推送保全受理的结果。
互联网应用收到保全流水号后，提供名单供核心业务系统导入。核心业务系统导入名单。
核心业务系统收到导入名单的请求后，调用规则引擎，进行规则校验，规则校验通过后，确认提交，等待保全处理。保全处理完成后，将处理结果传送至消息队列，通过消息队列进行推送。
消息队列用于推送消息，同时互联网应用也可以通过消息推送拉取订阅结构，也可以向客户浏览器推送通知。
需要说明的是，前述互联网应用的含义可以理解为与互联网应用相同或相似。
通过上述方法，可以简化团单增减人保全业务的处理流程，提升业务办理效率；也可以提升用户参与度，解决柜面工作人员人力成本；也可以使消息通知及时推送，提升用户满意度。
在一种可能的实现方式中，可以增加移动端(微信或者app)分散性信息收集入口，替代企业客户批量导入名单的操作。移动端入口由员工个人填写信息，由企业联系人进行名单的确认和提交。通过增加移动端，可以降低企业联系人的工作量，同时，因为信息由员工本人填写，可以提高信息的准确率。
在一种可能的实现方式中，可以开放api(applicationprogramminginterface，应用程序接口)，从而可以支持受理和处理业务，互联网前端由企业客户或第三方机构提供，可以提升整体方案的灵活性和可拓展性。
本说明书的一个或多个实施例，还提供一种团单处理系统，包括：
互联网应用模块，用于获取团单信息，从团单信息中解析出清单信息，并将清单信息发送至核心业务系统服务器。
核心业务系统服务器，基于业务预估规则和接收到的清单信息，对团单进行业务预估，得到业务预估结果，并将业务预估结果返回至互联网应用模块；
互联网应用模块接收用户输入的对业务预估结果的确认信息，互联网应用模块将指示确认提交团单的团单确认提交指令发送至核心业务系统服务器。
核心业务系统服务器接收团单确认提交指令，核心业务系统通过后台线程从互联网应用模块导入团单信息，基于业务处理规则处理团单信息，得到对团单的业务处理结果。
上述系统引入互联网应用模块，引入互联网应用模块，可以简化团单录入的处理流程；通过引入异步处理方式，可以提升团单的处理速度，提升业务办理效率。亦即，上述方法可以提升计算机系统对团单的处理效率。
本说明书一个或多个实施例，还提供一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现如上任意一项所述的方法。
本说明书一个或多个实施例，还提供一种非暂态计算机可读存储介质，所述非暂态计算机可读存储介质存储计算机指令，所述计算机指令用于使所述计算机执行如上任一所述方法。
需要说明的是，本说明书一个或多个实施例的方法可以由单个设备执行，例如一台计算机或服务器等。本实施例的方法也可以应用于分布式场景下，由多台设备相互配合来完成。在这种分布式场景的情况下，这多台设备中的一台设备可以只执行本说明书一个或多个实施例的方法中的某一个或多个步骤，这多台设备相互之间会进行交互以完成所述的方法。
上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。
为了描述的方便，描述以上装置时以功能分为各种模块分别描述。当然，在实施本说明书一个或多个实施例时可以把各模块的功能在同一个或多个软件和/或硬件中实现。
上述实施例的装置用于实现前述实施例中相应的方法，并且具有相应的方法实施例的有益效果，在此不再赘述。
图3为本实施例所提供的一种更为具体的电子设备硬件结构示意图，图3示出了本实施例所提供的一种更为具体的电子设备硬件结构示意图，该设备可以包括：处理器1010、存储器1020、输入/输出接口1030、通信接口1040和总线1050。其中处理器1010、存储器1020、输入/输出接口1030和通信接口1040通过总线1050实现彼此之间在设备内部的通信连接。
处理器1010可以采用通用的cpu(centralprocessingunit，中央处理器)、微处理器、应用专用集成电路(applicationspecificintegratedcircuit，asic)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本说明书实施例所提供的技术方案。
存储器1020可以采用rom(readonlymemory，只读存储器)、ram(randomaccessmemory，随机存取存储器)、静态存储设备，动态存储设备等形式实现。存储器1020可以存储操作系统和其他应用程序，在通过软件或者固件来实现本说明书实施例所提供的技术方案时，相关的程序代码保存在存储器1020中，并由处理器1010来调用执行。
输入/输出接口1030用于连接输入/输出模块，以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中(图中未示出)，也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等，输出设备可以包括显示器、扬声器、振动器、指示灯等。
通信接口1040用于连接通信模块(图中未示出)，以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式(例如usb、网线等)实现通信，也可以通过无线方式(例如移动网络、wifi、蓝牙等)实现通信。
总线1050包括一通路，在设备的各个组件(例如处理器1010、存储器1020、输入/输出接口1030和通信接口1040)之间传输信息。
需要说明的是，尽管上述设备仅示出了处理器1010、存储器1020、输入/输出接口1030、通信接口1040以及总线1050，但是在具体实施过程中，该设备还可以包括实现正常运行所必需的其他组件。此外，本领域的技术人员可以理解的是，上述设备中也可以仅包含实现本说明书实施例方案所必需的组件，而不必包含图中所示的全部组件。
本实施例的计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。
所属领域的普通技术人员应当理解：以上任何实施例的讨论仅为示例性的，并非旨在暗示本公开的范围(包括权利要求)被限于这些例子；在本公开的思路下，以上实施例或者不同实施例中的技术特征之间也可以进行组合，步骤可以以任意顺序实现，并存在如上所述的本说明书一个或多个实施例的不同方面的许多其它变化，为了简明它们没有在细节中提供。
另外，为简化说明和讨论，并且为了不会使本说明书一个或多个实施例难以理解，在所提供的附图中可以示出或可以不示出与集成电路(ic)芯片和其它部件的公知的电源/接地连接。此外，可以以框图的形式示出装置，以便避免使本说明书一个或多个实施例难以理解，并且这也考虑了以下事实，即关于这些框图装置的实施方式的细节是高度取决于将要实施本说明书一个或多个实施例的平台的(即，这些细节应当完全处于本领域技术人员的理解范围内)。在阐述了具体细节(例如，电路)以描述本公开的示例性实施例的情况下，对本领域技术人员来说显而易见的是，可以在没有这些具体细节的情况下或者这些具体细节有变化的情况下实施本说明书一个或多个实施例。因此，这些描述应被认为是说明性的而不是限制性的。
尽管已经结合了本公开的具体实施例对本公开进行了描述，但是根据前面的描述，这些实施例的很多替换、修改和变型对本领域普通技术人员来说将是显而易见的。例如，其它存储器架构(例如，动态ram(dram))可以使用所讨论的实施例。
本说明书一个或多个实施例旨在涵盖落入所附权利要求的宽泛范围之内的所有这样的替换、修改和变型。因此，凡在本说明书一个或多个实施例的精神和原则之内，所做的任何省略、修改、等同替换、改进等，均应包含在本公开的保护范围之内。
1.一种团单处理方法，其特征在于，包括：
互联网应用获取团单信息，从所述团单信息中解析出清单信息，并将所述清单信息发送至核心业务系统；
所述核心业务系统基于业务预估规则和接收到的所述清单信息，对所述团单进行业务预估，得到业务预估结果，并将所述业务预估结果返回至所述互联网应用；
响应于接收到用户输入的对所述业务预估结果的确认信息，所述互联网应用将指示确认提交所述团单的团单确认提交指令发送至所述核心业务系统；
响应于所述团单确认提交指令，所述核心业务系统通过后台线程从所述互联网应用导入所述团单信息，基于业务处理规则处理所述团单信息，得到对所述团单的业务处理结果。
2.根据权利要求1所述的方法，其特征在于，还包括：
所述核心业务系统通过kafka分布式消息队列，将指示所述业务处理结果的消息推送给所述互联网应用。
3.根据权利要求1所述的方法，其特征在于，响应于所述团单确认提交指令，所述核心业务系统通过后台线程从所述互联网应用导入所述团单信息，基于业务处理规则处理所述团单信息，得到对所述团单的业务处理结果，包括：
建立线程池，所述线程池对用于处理所述团单信息的线程进行调度，包括：
获取所述团单信息的到达时间；
查询所述线程池中是否存在空闲线程；
如果查询结果为是，则调用空闲的线程处理所述团单信息；
如果查询结果为否，则计算获得空闲线程的等待时间，根据所述团单信息的到达时间和所述空闲线程的等待时间将所述团单信息分配至对应的空闲线程等待队列。
4.根据权利要求1所述的方法，其特征在于，所述核心业务系统基于业务预估规则和接收到的所述清单信息，对所述团单进行业务预估，得到业务预估结果，并将所述业务预估结果返回至所述互联网应用，包括：
调用所述核心业务系统的接口；
通过所述核心业务系统的接口导入所述团单信息中的规则和金额，所述核心业务系统根据导入的所述团单信息中的规则和金额进行试算，将试算后的结果生成为所述业务预估结果。
5.根据权利要求1所述的方法，其特征在于，所述核心业务系统基于业务预估规则和接收到的所述清单信息，对所述团单进行业务预估，还包括：
通过所述核心业务系统的规则引擎对所述团单信息进行校验，如果所述团单信息无法通过所述规则引擎的校验，则向所述互联网应用发送警告信息；
对所述团单信息和所述清单信息进行缓存，并设立所述团单信息和所述清单信息的缓存时间，缓存时间结束后，清除所述团单信息和所述清单信息。
6.根据权利要求1所述的方法，其特征在于，基于业务处理规则处理所述团单信息，还包括：
所述核心业务系统的规则引擎对所述团单信息进行规则校验；
如果所述规则校验发生异常，则查找异常原因，将所述异常原因推送并停止处理所述团单信息；
其中，所述规则校验至少包括校验字段数量是否符合或字段间关系是否符合中的一个。
7.根据权利要求1所述的方法，其特征在于，还包括：
对所述团单的业务处理结果进行分类，获得所述团单的业务处理结果的类别；
将所述团单的业务处理结果存入与其类别对应的订阅消息队列；
所述团单的业务处理结果由其所存入的订阅消息队列推送；
对所述订阅消息队列中所述团单的业务处理结果的保存时间进行配置，如果所述保存时间结束，则删除所述团单的业务处理结果。
8.根据权利要求1所述的方法，其特征在于，还包括：
通过移动客户端搜集独立团单信息；
所述移动客户端将搜集到的所述独立团单信息发送至所述互联网应用；
所述互联网应用调度线程处理所述独立团单信息并生成所述独立团单信息的处理结果；
所述互联网应用向发送所述独立团单信息的移动客户端推动所述独立团单信息的处理结果；
所述互联网应用对多个所述独立团单信息进行整合并生成所述团单信息。
9.根据权利要求1所述的方法，其特征在于，响应于所述团单确认提交指令，所述核心业务系统通过后台线程从所述互联网应用导入所述团单信息，基于业务处理规则处理所述团单信息，得到对所述团单的业务处理结果，包括：
使用线程池进行试算，所述线程池的核心线程数为2至20个，最大线程数为20个至50个，等待队列为100至500个；
通过接口创建异步任务，并通过所述线程池异步执行清单校验任务；
所述清单校验任务完成后，将获得的试算结果返回。
10.一种团单处理系统，其特征在于，包括：
互联网应用模块，用于获取团单信息，从所述团单信息中解析出清单信息，并将所述清单信息发送至核心业务系统服务器；
所述核心业务系统服务器，基于业务预估规则和接收到的所述清单信息，对所述团单进行业务预估，得到业务预估结果，并将所述业务预估结果返回至所述互联网应用模块；
所述互联网应用模块接收用户输入的对所述业务预估结果的确认信息，所述互联网应用模块将指示确认提交所述团单的团单确认提交指令发送至所述核心业务系统服务器；
所述核心业务系统服务器接收所述团单确认提交指令，所述核心业务系统通过后台线程从所述互联网应用模块导入所述团单信息，基于业务处理规则处理所述团单信息，得到对所述团单的业务处理结果。
技术总结