一种业务模型生成方法及装置与流程

本申请涉及软件技术领域，特别涉及一种业务模型生成方法及装置。

背景技术：

现有软件开发中有这样的场景，从其它若干个模型获取数据，并最终通过计算以生成新的模型，例如支付宝的安全检查模型就需要从单据模型、用户模型、终端模型等很多模型中获得数据，通过从单据模型中获得例如订单号、商品信息、付款金额等数据，从用户模型中获得例如用户ID、手机号码等数据，从终端模型中获得例如移动设备国际识别码(IMEI：International Mobile Equipment Identity)、国际移动用户识别码(IMSI：International Mobile Subscriber Identification Number)等数据，通过这些数据进行安全检查，从而确定用户的安全等级。在上述过程中，从各个模型获取数据需要以代码实现，当安全检查模型需要增加新的模型数据或者变更某些用于计算的模型数据时，需要将线上服务器的代码变更，然后重新打包发布，这样做使得软件开发流程较繁琐，线上运维成本较高。

技术实现要素：

为了解决现有技术中由固定代码实现从多个数据模型中获得数据生成业务模型时，当业务模型需要变更时，需要重新编写代码并打包发布，造成整个流程十分繁琐，线上运维成本较高，本申请实施例提出了一种业务模型生成方法及装置，通过配置文件的方式生成业务模型，从而当业务模型需要变更时，只需要配置配置文件即可实现生成新的业务模型的目的，简化了现有技术中业务模型代码编写、打包、发布的繁琐过程，并且降低了线上运维成本。

本申请实施例具体提供了一种业务模型生成方法，包括，

接收外围调用装置的业务模型请求；

根据所述业务模型请求获得相关数据模型的配置文件和数据；

根据所述配置文件和数据得到相应业务模型；

将所述业务模型传送给所述外围调用装置。

本申请实施例还提供了一种业务模型生成装置，包括，

接收单元，用于接收外围调用装置的业务模型请求；

匹配单元，用于根据所述业务模型请求获得相关数据模型的配置文件和数据；

生成单元，用于根据所述配置文件和数据得到相应业务模型；

发送单元，用于将所述业务模型传送给所述外围调用装置。

由以上本申请实施例提供的技术方案可见，本申请实施例的方案可以不在外围调用装置中写入如何构建业务模型的编码，通过本申请装置以配置文件的方式生成业务模型，可以根据实际业务的需要实时的改变业务模型，避免了现有技术中发布代码的复杂步骤，节省人力成本和时间成本，灵活的实现了业务模型可配置化的目的。

当然实施本申请的任一产品或者方法必不一定需要同时达到以上所述的所有优点。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1所示为本申请实施例一种业务模型生成方法的流程图；

图2所示为本申请实施例一种业务模型生成装置的结构示意图；

图3所示为本申请实施例支付宝安全检查系统的数据流图；

图4所示为本申请实施例用户系统中存储的用户模型数据的示意图；

图5所示为本申请实施例业务模型与配置文件的映射表的示意图；

图6所示为本申请实施例淘宝优惠系统的数据流图。

具体实施方式

本申请实施例提供一种业务模型生成方法及装置。

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

如图1所示为本申请实施例一种业务模型生成方法的流程图，在该图的实施例中业务模型可以为多种模型，例如安全检查模型、优惠发放模型或者广告模型等，这些业务模型的特点在于需要多个数据模型的数据输入，例如需要单据模型、用户模型、终端模型或者渠道模型等数据模型的数据输入，从而可以根据这些数据模型的数据得到相应的业务模型，例如通过用户模型、单据模型和终端模型的数据得到判断电子交易是否安全的安全检查模型，本申 请实施例中的业务模型可以有很多业务场景，根据不同的业务场景，当某个业务模型需要的数据模型改变或者获取数据模型中的属性数据(例如用户ID或者电话号码等)改变，不必重新生成和发布代码，只需要改变相应的配置文件就可以生成新的业务模型，节省了大量的对于重新生成业务模型和代码发布的系统开销。

本实施例具体包括，步骤101，接收外围调用装置的业务模型请求。

步骤102，根据所述业务模型请求获得相关数据模型的配置文件和数据。

步骤103，根据所述配置文件和数据得到相应业务模型。

步骤104，将所述业务模型传送给所述外围调用装置。

根据本申请的一个实施例，在根据所述业务模型请求获得相关数据模型的配置文件和数据之前还包括，接收数据系统发送的数据模型的数据。其中，所述数据系统是指生成并采集各个数据模型中数据的系统，例如单据系统采集该单据系统中由于用户交易生成的单据数据，用户系统采集该用户系统中存储的用户数据，终端系统采集用户的终端数据等，这些数据系统中有了数据就会传送给本申请实施例的装置。

根据本申请的一个实施例，在根据所述业务模型请求获得相关数据模型的配置文件和数据之前还包括，接收外围调用装置发送的数据模型的数据。其中，外围调用装置包括例如安全系统、优惠系统、广告系统等，利用数据系统中的数据对用户或者交易进行控制和业务操作的系统，这里外围调用装置发送的数据模型的数据包括了某个数据模型中所有的数据，从而如果在后期业务模型需要改变时，可以直接改变配置文件即可得到相应的业务模型。

根据本申请的一个实施例，根据所述业务模型请求获得相关数据模型的配置文件和数据进一步包括，获得与所述业务模型请求相关的所有数据模型的配置文件，根据所述配置文件获得所述数据模型中的至少部分数据。其中，不同的业务模型可能需要不同的数据模型，例如安全检查模型和优惠模型可能所需的数据模型就不同，安全检查模型可能需要单据模型的数据，用户模型的数据，终端模型的数据，用以分析该用户的安全等级，从而判断交易的可靠性，而优惠模型可能需要用户模型的数据，渠道模型的数据，用以分析该用户是否是通过特定的渠道付款，如果通过特定渠道付款则可以得到总价9折的优惠。每种业务模型都需要相关的一个或者多个数据模型，每个数据模型都具有多个属性数据(例如用户模型中具有用户名、电话号码、性别、家庭住址、密码、验证问题等等)，每个相关的数据模型都有与该业务相关的配置文件，也就是说，例如安全检查模型需要的用户模型数据中需要用户名、身份证号、手机号码等数据，而在优惠模型需要的用户模型数据中可能只需要用户名即可，所述的配置文件记录有该业务模型涉及的数据模型中具体需要哪些属性数据。

根据本申请的一个实施例，根据所述配置文件和数据得到相应业务模型进一步包括，解 析所述配置文件，根据所述配置文件将所述数据转换为业务模型。其中，配置文件可以使用XML(可扩展标记语言)形式，所述配置文件中记录有应该将哪些数据以何种格式输出给外围调用装置的配置信息，解析所述配置文件的XML文件获得相应代码，然后根据该代码组织、整合相关数据，最终形成业务模型。

通过上述本申请的方法，可以不在外围调用装置中写入如何构建业务模型的编码，通过本申请装置以配置文件的方式生成业务模型，可以根据实际业务的需要实时的改变业务模型，避免了现有技术中发布代码的复杂步骤，节省人力成本和时间成本，灵活的实现了业务模型可配置化的目的。

如图2所示为本申请实施例一种业务模型生成装置的结构示意图，本实施例中的装置可以由特殊的芯片或者电子电路实现，也可以由通用的处理器实现，可以运行于高性能计算机之中，其中的各个功能模块或者单元可以独立运行于一台计算机(或者一个处理器核)中，也可以共同运行于一台计算机(或者一个处理器核)中，在本实施例的装置中运行上述方法的处理过程，根据对业务模型的需求修改配置文件，根据配置文件来获取数据，形成业务模型，从而避免了软件发布的问题。

在本实施例中具体包括，接收单元201，用于接收外围调用装置的业务模型请求。

匹配单元202，用于根据所述业务模型请求获得相关数据模型的配置文件和数据。

生成单元203，用于根据所述配置文件和数据得到相应业务模型。

发送单元204，用于将所述业务模型传送给所述外围调用装置。

根据本申请的一个实施例，所述接收单元还用于，接收数据系统发送的数据模型的数据。

根据本申请的一个实施例，所述接收单元还用于，接收外围调用装置发送的数据模型的数据。

根据本申请的一个实施例，所述匹配单元进一步用于，获得与所述业务模型请求相关的所有数据模型的配置文件，根据所述配置文件获得所述数据模型中的至少部分数据。

根据本申请的一个实施例，所述生成单元进一步用于，解析所述配置文件，根据所述配置文件将所述数据转换为业务模型。

通过上述本申请的装置，可以不在外围调用装置中写入如何构建业务模型的编码，通过本申请装置以配置文件的方式生成业务模型，可以根据实际业务的需要实时的改变业务模型，避免了现有技术中发布代码的复杂步骤，节省人力成本和时间成本，灵活的实现了业务模型可配置化的目的。

如图3所示为本申请实施例支付宝安全检查系统的数据流图，在该图中包括了外围调用装置(安全系统)，业务模型生成装置，多个数据系统，其中多个数据系统包括了单据系统、 用户系统、终端系统等多个数据系统，每个数据系统中包括了多个属性数据，在该数据系统中存储有大量的数据，如图4所示为本申请实施例用户系统中存储的用户模型数据的示意图，其它的数据系统也可以以类似的形式进行存储，或者数据系统还可以有其它形式，该数据系统的特点是能够提供用于生成业务模型，从而可以完成安全系统进行安全风险评价的目的即可，在本申请技术方案中不做过多的限制。

在该图中所有步骤之前，由各个数据系统将数据传送给业务模型生成装置，作为一个实施例，在数据系统闲时将该数据系统中的数据完整的传送给业务模型生成装置，例如用户系统在闲时将全部用户模型的数据传送给业务模型生成装置，单据系统在闲时将全部单据模型的数据传送给业务模型生成装置，终端系统在闲时将全部终端模型的数据传送给业务模型生成装置。其中，用户模型数据包括用户ID、手机号码、性别、家庭住址、身份证号等数据，单据模型数据包括订单ID、商品类型、交易金额、商家信息、送货地址等数据，终端模型数据包括终端类型、IP地址、MAC地址、终端使用软件版本等数据。在业务模型生成装置中保存有各个数据系统传送过来的数据。当然，业务模型生成装置也可以在后面步骤302中获得所有相关联数据系统的数据。

在生成安全模型的过程中具体包括步骤301，安全系统发送安全模型请求。

在本步骤中安全系统发送的安全模型请求中包括了要求业务模型生成装置生成业务模型的种类，例如可以包括识别码、标识符等指明生成业务模型种类的字符或者字符串，或者还可以为直接指明生成业务模型种类的名称。

步骤302，业务模型生成装置根据安全模型请求获取相应的配置文件和数据。

在本步骤中，假设安全模型需要用户模型的数据，单据模型的数据，终端模型的数据，其中用户模型的数据来自于用户系统，单据模型的数据来自于单据系统，终端模型的数据来自于终端系统，在业务模型生成装置中包括有一个业务模型与配置文件的映射表，该表可以例如图5所示，该映射表记录有业务类型与其需要哪些数据模型配置文件的映射关系，通过该映射表可以获得该安全模型所需的所有数据模型的配置文件。

或者，还可以以配置文件名作为数据模型的配置文件与业务模型关联的匹配条件，例如，配置文件名可以按照“安全模型_用户模型.xml”、“安全模型_单据模型.xml”、“安全模型_终端模型.xml”命名，然后根据文件名就可以得到与安全模型相关联的数据模型配置文件。

根据上述的描述，在本步骤中可以获得用户模型的配置文件，单据模型的配置文件，终端模型的配置文件，在每个配置文件中都包括了从该数据模型中以何种方式获取哪些数据，例如在用户模型的配置文件中记载了获取用户ID，在单据模型配置文件中记载了获取订单ID、交易金额、商品类型，在终端模型配置文件中记载了获取终端的类型、IP地址、MAC地 址。

业务模型生成装置根据上述配置文件在各个数据系统传送来的数据中查找相应的数据。

步骤303，业务模型生成装置根据配置文件和数据生成相应的安全模型。

在本步骤中，根据配置文件中记载的将这些数据输出到安全模型中的位置，结合多个数据模型的配置文件可以将安全系统所需的全部数据结合、转换生成安全模型。例如在用户模型的配置文件中记载了安全模型.某个位置.put(用户模型.某个位置.get用户Id)，表示在安全模型的某个位置置入用户模型中用户ID，其它的数据模型的配置文件也可以参照。

与现有技术相比较，在本申请的技术方案中，如果需要修改安全模型中所需的用户模型的属性数据，例如，除了用户ID以外，安全模型中还需要用户电话号码，则只需要在用户模型的配置文件中加入从用户模型中获取用户电话号码的信息，以及在转换生成安全模型时该用户电话号码的插入位置即可。

步骤304，业务模型生成装置将安全模型发送给安全系统。

步骤305，安全系统利用安全模型进行安全计算，得到安全评价结果。

如图6所示为本申请实施例淘宝优惠系统的数据流图，在该图中包括了外围调用装置(优惠系统)，业务模型生成装置，多个数据系统，所述数据系统包括了终端系统、用户系统、渠道系统等多个数据系统。

在该图中包括步骤601，优惠系统发送优惠模型请求。

在本例中，优惠模型请求中包括了优惠模型的名称。

步骤602，优惠系统将采集到的各个相关数据系统的数据发送给业务模型生成装置。

在本步骤中，优惠模型需要用户模型的数据，终端模型的数据，渠道模型的数据，其中用户模型的数据、终端模型的数据、渠道模型的数据由优惠系统分别到用户系统、终端系统、渠道系统中采集并发送给业务模型生成装置，优惠系统通过与各个数据系统的接口获取用于生成优惠模型的数据，此时从各个数据系统中获取的数据为该数据系统的全量数据，由优惠系统事先存储入所述业务模型生成装置，即在优惠系统发送优惠模型请求之前就获取各个数据系统中的数据，并将这些数据存储入业务模型生成装置，或者实时的存储入业务模型生成装置。

步骤603，业务模型生成装置根据优惠模型请求获取相应的配置文件和数据。

在本实施例中，获取相应的配置文件可以通过遍历业务模型生成装置中所有配置文件的方式实现，在每个配置文件中都记载有与哪个业务模型相关，如果与优惠模型相关，则将获取该配置文件。

或者，还可以遍历配置文件的文件名来确定数据模型的配置文件与哪个业务模型相关， 例如出模型是优惠模型，输入模型是用户模型，配置文件名为“优惠模型_用户模型.xml”。

所述业务模型生成装置根据优惠模型请求匹配到所有相关的配置文件，并根据所有相关的配置文件获得相应的数据，在本例中，业务模型生成装置获取用户模型配置文件中记载的用户ID，获取在终端模型配置文件中记载的终端类型，获取渠道模型配置文件中记载的付款方式。

步骤604，业务模型生成装置根据配置文件和数据生成相应的优惠模型。

在本步骤中，根据配置文件中记载的将这些数据输出到优惠模型中的位置，结合多个数据模型的配置文件可以将优惠系统所需的全部数据结合、转换生成优惠模型。

步骤605，业务模型生成装置将优惠模型发送给优惠系统。

步骤606，优惠系统利用优惠模型进行优惠计算，得到该给哪些用户享受优惠。

在本步骤中举例来说，优惠计算可能需要根据用户进行电子交易时使用的终端类型和付款方式来判断是否给用户以优惠，例如，如果终端类型为手机，付款方式为信用卡方式则可以给该用户ID的用户以优惠折扣。

通过上述本申请实施例中的方法及装置，可以不在外围调用装置中写入如何构建业务模型的编码，通过本申请装置以配置文件的方式生成业务模型，可以以集中的方式对各种外围调用装置生成业务模型，使得整个系统结构更加合理，并且可以根据实际业务的需要实时的改变业务模型，避免了现有技术中发布代码的复杂步骤，节省人力成本和时间成本，灵活的实现了业务模型可配置化的目的。

对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(Programmable Logic Device,PLD)(例如现场可编程门阵列(Field Programmable Gate Array，FPGA))就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片PLD上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片2。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(Hardware Description Language，HDL)，而HDL也并非仅有一种，而是有许多种，如ABEL(Advanced Boolean Expression Language)、AHDL(Altera Hardware Description Language)、Confluence、CUPL(Cornell University Programming Language)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(Ruby Hardware Description Language)等，目前最普遍使用的是VHDL(Very-High-Speed Integrated Circuit Hardware Description Language)与Verilog2。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。

控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20以及Silicone Labs C8051F320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。

本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。

为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本申请可用于众多通用或专用的计算机系统环境或配置中。例如：个人计算机、服务器计算机、手持设备或便携式设备、平板型设备、多处理器系统、基于微处理器的系统、置顶盒、可编程的消费电子设备、网络PC、小型计算机、大型计算机、包括以上任何系统或设备的分布式计算环境等等。

本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

虽然通过实施例描绘了本申请，本领域普通技术人员知道，本申请有许多变形和变化而不脱离本申请的精神，希望所附的权利要求包括这些变形和变化而不脱离本申请的精神。