一种数据扩展的实现方法技术

本发明专利技术公开了一种数据扩展的实现方法，包括通过元数据驱动方案，动态配置元数据；所述元数据驱动方案，即通过对业务对象的数据结构元数据化描述，高度抽象实际数据的结构，借鉴MOF规范定义的概念进行设计；所述动态配置元数据，指的是对元数数据模型的配置，包括增删改一个元数据模型，并且生成最新版本号，则所有数据存储和接口服务都以最新配置在运行时自动调整，基本无需关注后端代码逻辑的修改，但可能需要对前端展示进行调整，但不包含对前端展示的元数据配置自动化适应实现。本发明专利技术通过元数据驱动方案，动态配置元数据，提高交付效率，增强业务扩展性。

【技术实现步骤摘要】
一种数据扩展的实现方法
本专利技术涉及项目应用领域，特别涉及一种数据扩展的实现方法。
技术介绍
随着业务的发展，应用的功能在不断变化，这种变化经常导致程序发生修改或能力的增加，比如某个业务对象增加了新的属性，或在原有功能之上增加了新的业务模块，或在原有功能之上增加了新的终端应用，这些无论是小范围的对象属性调整还是大面积的业务模块调整，都对开发流程带来了一定挑战，除了开发成本的消耗以及延迟响应带来的市场变动，还有随着代码改动带来未知的联动影响风险，所以面向类似有一定规律的、逻辑交互较为清晰的、对现有功能进行扩展的程序代码变动，需要从设计上让类似的功能实现能够在可控制、可配置的可视化环境下进行，从而降低影响及风险，提高产出效率。
技术实现思路
本专利技术的主要目的在于克服现有技术的缺点与不足，提供一种数据扩展的实现方法，该方法通过元数据驱动方案，动态配置元数据，提高交付效率，增强业务扩展性。本专利技术的目的通过以下的技术方案实现：一种数据扩展的实现方法，包括通过元数据驱动方案，动态配置元数据；所述元数据为业务信息的概念与连接，表示数据的数据；在逻辑层面，所述元数据驱动方案，即通过对业务对象的数据结构元数据化描述，高度抽象实际数据的结构，借鉴MOF规范定义的概念进行设计，不仅支持从数据资产进行元数据化管理，而且也能从对象、接口进行管理，从模型实例、模型、元模型、元元模型四层理论充分解耦不同业务对象的结构，使其在一套元数据框架下能够读写并且在运行时进行业务整合，从而提供业务服务；所述动态配置元数据，指的是对元数数据模型的配置，包括增删改一个元数据模型，并且生成最新版本号，则所有数据存储和接口服务都以最新配置在运行时自动调整，基本无需关注后端代码逻辑的修改，但可能需要对前端展示进行调整(如果涉及)，但不包含对前端展示的元数据配置自动化适应实现。元数据驱动方案中，所述数据资产包括表、字段。元数据驱动方案中，所述对象包括类模型、属性。元数据驱动方案中，所述接口输入接口、输出接口。在实际应用层面，所述元数据在实际设计方案中，分为元数据模型(简称元模型)及元数据实例两大部分结构；所述元数据模型又分为对象(表、接口)元数据、属性(字段、参数)元数据；元数据实例则是元数据模型描述下实际事物数据的存储。所述数据扩展包括应用对象属性扩展、业务结构扩展、虚拟应用扩展。所述应用对象属性扩展，是指：对已有的应用业务对象，满足其属性扩展需要，所述属性扩展需要包括增加部分属性描述；则增加的部分，无论在存储形式上还是接口形式上，则都通过元数据的方式存取，并且建立与原对象之前的关联。所述业务结构扩展，是指：对于应用本身不存在的业务对象，则完全依赖元数据驱动设计方案来实现业务的落地，包括在客户业务当中，随着业务发展，目前需要记录来访客户的跟进记录明细以便来精准分析客户，那么客户跟进记录则可以通过元数据驱动设计来实现数据的存取，并且建立起该对象与其他已存在的对象的关系后自动生成API接口，而基本无需再实现其他代码部分，或者如有其他复杂逻辑时，也能节省很大一部分编码时间。所述与其他已存在的对象包括已存在的其他元数据对象实例。所述虚拟应用扩展，是指：与所述业务结构扩展类似，通过元数据驱动设计，将一个应用或一个端建立在元数据模型之上，只不过复杂度有所增加，因为该应用内具有多个业务结构扩展，并且需要准确记录每个业务扩展之间的关系，然后生成API接口，以供其他服务调用或前端调用展示。所述数据扩展的实现方法，还提供可视化入口，可视化入口包括：(1)元数据本身的API管理，包括对象元数据、属性元数据本身的API管理；(2)业务元数据API，业务一旦创建，运行时便会生成具体业务的AP，而不是通过传参的方式以及元数据接口来操作业务；(3)集成API，元数据结合已有标准业务数据，统一打造集成平台，实现集成标准接口；(4)辅助API，包括索引、唯一约束、全文检索、跨表查询。所述元数据驱动方案，通过MPR(元数据处理运行时服务)来实现查询的优化和全文检索的性能问题，并且MPR也会提供业务整合能力，降低服务使用方对元数据模块的感知，保证开发体验；通过MPR的MetaAPl来提供通用解稠的完整的接口能力，为业务扩展提供标准化支持。所述MPR内部数据处理流程为：将设置的业务对象激活并初始化的地方，依次处理顺序为：生成业务API(仅首次)→创建业务上下文Context→绑定数据修改Handler→绑定辅助索引Handler→绑定辅助唯一约束；当业务运行时，则会根据注册的Handler调用handle执行；Handler执行的时候，会根据Filter依次执行，Filter为链式结构，在绑定Handler时注入；不同的Handler处理完后，会根据设置判断是否发出一个Event，该Event根据Handler类型不同而不同，Event对应的监听者为Action。所述MPR包括以下功能：MetaAPl(元数据接口服务)、业务整合、查询优化、全文检索；所述MetaAPl是元数据服务的重要组成部分，负责所有与元数据服务通信的接口管理；所述元数据服务不是一个SDK客户端组件，是需要独立部署的；同时，元数据服务没有对调用者提供SDK包，而是通过HttpRest的方式对外提供服务；MetaAPI分为“模型操作API”和“数据实例API”两部分：“模型操作API”用于元数据模型自身的数据结构维护和对应接口实现；而“数据实例API”主要用于元数据实例的维护；所述业务整合，属于MetaAPI的功能之一，是“数据实例API”的一部分，若使用了元数据的方式来存取客户，则MetaAPI的“数据实例API”中的业务整合组件就会自动生成客户API，并使其输入输出转换为客户对象的属性描述，而不是元数据格式的描述；所述全文检索是使用第三方中间件ElasticSearch来实现。所述查询优化，包括以下三种情形：(1)更新元数据模型1-1、判断当前模型的Context是否已创建：若是，则转到步骤1-2；若否，则读取模型信息，创建Context，并转到步骤1-2；1-2、读取Context，判断是否创建索引：若是，则创建元数据索引；若否，则转到元数据模型；1-3、判断是否参与全文检索，如是，则执行全文检索；(2)新增或更新元数据实例2-1、判断当前模型的Context是否已创建：若是，则转到步骤2-2；若否，则读取模型信息，创建Context，并转到步骤2-2；2-2、读取Context，判断是否更新索引：若是，则更新元数据索引；若否，则根据模型规则创建全局Data_ID，然后判断模型是否单独存储、模型是否分库分表，最后转入元数据实例并日志同步；2-3、判断是否参与全文检索，如是，则执行全文检索；(3)查询元数据实例3-1、判断当前模型的Context是否已创建：若是，则转本文档来自技高网...

【技术保护点】
1.一种数据扩展的实现方法，其特征在于，包括通过元数据驱动方案，动态配置元数据；/n所述元数据为业务信息的概念与连接，表示数据的数据；/n在逻辑层面，所述元数据驱动方案，即通过对业务对象的数据结构元数据化描述，高度抽象实际数据的结构，借鉴MOF规范定义的概念进行设计，不仅支持从数据资产进行元数据化管理，而且也能从对象、接口进行管理，从模型实例、模型、元模型、元元模型四层理论充分解耦不同业务对象的结构，使其在一套元数据框架下能够读写并且在运行时进行业务整合，从而提供业务服务；/n所述动态配置元数据，指的是对元数数据模型的配置，包括增删改一个元数据模型，并且生成最新版本号，则所有数据存储和接口服务都以最新配置在运行时自动调整，基本无需关注后端代码逻辑的修改，但可能需要对前端展示进行调整，但不包含对前端展示的元数据配置自动化适应实现。/n

【技术特征摘要】
1.一种数据扩展的实现方法，其特征在于，包括通过元数据驱动方案，动态配置元数据；
所述元数据为业务信息的概念与连接，表示数据的数据；
在逻辑层面，所述元数据驱动方案，即通过对业务对象的数据结构元数据化描述，高度抽象实际数据的结构，借鉴MOF规范定义的概念进行设计，不仅支持从数据资产进行元数据化管理，而且也能从对象、接口进行管理，从模型实例、模型、元模型、元元模型四层理论充分解耦不同业务对象的结构，使其在一套元数据框架下能够读写并且在运行时进行业务整合，从而提供业务服务；
所述动态配置元数据，指的是对元数数据模型的配置，包括增删改一个元数据模型，并且生成最新版本号，则所有数据存储和接口服务都以最新配置在运行时自动调整，基本无需关注后端代码逻辑的修改，但可能需要对前端展示进行调整，但不包含对前端展示的元数据配置自动化适应实现。


2.根据权利要求1所述数据扩展的实现方法，其特征在于，所述数据扩展包括应用对象属性扩展、业务结构扩展、虚拟应用扩展。


3.根据权利要求2所述数据扩展的实现方法，其特征在于，所述应用对象属性扩展，是指：对已有的应用业务对象，满足其属性扩展需要，所述属性扩展需要包括增加部分属性描述；则增加的部分，无论在存储形式上还是接口形式上，则都通过元数据的方式存取，并且建立与原对象之前的关联。


4.根据权利要求2所述数据扩展的实现方法，其特征在于，所述业务结构扩展，是指：对于应用本身不存在的业务对象，则完全依赖元数据驱动设计方案来实现业务的落地，包括在客户业务当中，随着业务发展，目前需要记录来访客户的跟进记录明细以便来精准分析客户，那么客户跟进记录则可以通过元数据驱动设计来实现数据的存取，并且建立起该对象与其他已存在的对象的关系后自动生成API接口，而基本无需再实现其他代码部分，或者如有其他复杂逻辑时，也能节省很大一部分编码时间。


5.根据权利要求2所述数据扩展的实现方法，其特征在于，所述虚拟应用扩展，是指：与所述业务结构扩展类似，通过元数据驱动设计，将一个应用或一个端建立在元数据模型之上，只不过复杂度有所增加，因为该应用内具有多个业务结构扩展，并且需要准确记录每个业务扩展之间的关系，然后生成API接口，以供其他服务调用或前端调用展示。


6.根据权利要求1所述数据扩展的实现方法，其特征在于，还提供可视化入口，可视化入口包括：
(1)元数据本身的API管理，包括对象元数据、属性元数据本身的API管理；
(2)业务元数据API，业务一旦创建，运行时便会生成具体业务的API，而不是通过传参的方式以及元数据接口来操作业务；
(3)集成API，元数据结合已有标准业务数据，统一打造集成平台，实现集成标准接口；
(4)辅助API，包括索引、唯一约束、全文检索、跨表查询。


7.根据权利要求1所述数据扩展的实现方法，其特征在于，所述元数据驱动方案，通过MPR来实现查询的优化和全文检索的性能问题，并且MPR也会提供业务整合能力，降低服务使用方对元数据模块的感知，保证开发体验；通过MPR的MetaAPl来提供通用解稠的完整的接...

【专利技术属性】
技术研发人员：李楠，胡正洋，江威，
申请(专利权)人：广州云徙科技有限公司，
类型：发明
国别省市：广东;44