基于Odoo开源技术平台的ERP系统开发

摘 要： 以开源ERP Odoo为研究对象，从国内自主化的核心技术发展、当下ERP行业背景及自主化ERP的发展道路的选择问题等方面，进行了较为客观的阐述，较为系统性地从Odoo既有自带的应用功能、技术架构平台、实施部署方案、性能负载测试综合性等方面，论证了Odoo可以满足国内自主可控的先进ERP管理系统的技术要求。最后总结结论是，通过Odoo完全能够开发出一套具有世界先进水平的自主可控的ERP管理系统。

关键词： 安全可控; ERP; 企业信息化; 开源自主

中图分类号： TP 311文献标志码： A

Development of self Self Controlled ERP System Based on

the  Open Source  Technology Platform of Odoo

YANG Xunbo

（General Manager Office， Zaoyuan Information Technology （Shanghai） Co.， Ltd.， Shanghai 200030， China）

Abstract： This article uses takes open source ERP The research object of oOdoo which is the core technology as research objective， to introduce the development of localization in China， the current ERP industry background and the choice of the development path of localization ERP in China. It systematically demonstrates that odoo Odoo can meet the requirements of domestic autonomy in terms of its own application function， technical architecture platform， implementation deployment scheme， performance load test comprehensiveness， etc. Technical requirements of Odoo can satisfy the controllable advanced ERP management system in China. Finally， the conclusion is that through odooOdoo， we can  develop a set of independent and controllable ERP management system that hao advanced level in the world.

Key words： safety controllability; ERP; enterprise informatization;  open  source autonomy

0 引言

本文主要以國内自主化的核心技术发展、当下ERP行业背景及自主化ERP的发展道路的选择问题等方面，进行了较为客观的阐述，较为系统性地从Odoo既有自带的应用功能、技术架构平台、实施部署方案、性能负载测试综合性等方面，论证了Odoo可以满足国内自主可控的先进ERP管理系统的要求问题。最后总结结论是，通过Odoo完全能够开发出一套具有世界先进水平的自主可控的ERP管理系统。

1 发展自主可控的ERP系统必要性

1.1 国内企业ERP系统的现状

从笔者多年从事相关的企业信息化服务工作情况了解，在国内的大型央企、合资企业、国企、医疗、银行、教育等，均以美国企业为代表的商业ERP厂商SAP、ORACLE为主[1]，这些ERP管理系统从本质上是闭源的，以通过许可费加服务实施费的方式进行收费，其中这些系统因为对许可的授权监控影响，均在服务交互端上插入了后门程序，用于收集客户的使用信息情况，因而存在数据被监测与收集的可能。

在国内涉密类的企业采用的是国产金蝶和用友的ERP产品。以金蝶为例，其中客户端与服务端必须安装美国微软公司提供的WINDOWS 桌面版的操作系统，技术架构也就被限定的只能使用美国制定的X86技术CPU架构方案，如国内自行研制的龙芯、海光、麒麟等CPU所架构的服务端或是客户端操作系统平台无法支持，结论是虽然他们是国产的ERP管理系统，但在服务支持层上依然存在后门数据收集等安全风险问题。

1.2 自主可控的ERP系统的技术路线选择

对于国内发展自主可控ERP的管理系统设计路径有以下两种方式：

完全按照当前的安全可控的要求重新按照技术规范构建ERP管理系统。

通过开源ERP Odoo的技术技术平台，进行安全可控要求的移植与改造，转化成为安全自主可控的ERP生态与产品。

Odoo采用的开源协议是LGPL V3;LGPL是GPL的一个主要为类库使用设计的开源协议，和GPL要求任何使用/修改/衍生之GPL类库的的软件必须采用GPL协议不同，LGPL允许商业软件通过类库引用（LINK）方式使用LGPL类库而不需要开源商业软件的代码，这使得采用LGPL协议的开源代码可以被商业软件作为类库引用并发布和销售[2]。

由于Odoo是通过GITHUB进行开源共享，世界上有不少组织，包括一些欧洲的国家事业单位，如法国邮电集团通过在GIT上进行本地化的GIT版本分支，将分支的源码通过GIT分布式的技术转到法国邮电集团内部的GIT服务管理，通过内部GIT管理进行应用的重构和扩展，同时保持内核代码部分与Odoo在GITHUB上的代码一致。自己分支开发上层应用，并重新定义私自的代码分发协议，这里我们举例Odoo官方企业版的版本协议控制和分发的图来辅助上述解释，如图1所示。

从图1可以得到结论：Odoo的开源的社区版是Odoo的企业版内核，而企业版是社区版的增强应用功能，在企业版的增强功能这部分应用当中所使用的是Odoo企业版自定义的协议OEEL，所以通过这个方式完全实现了商业版的自主控制分发权。如同前面所提到的法国邮电集团的例子一致，我们如果采用Odoo作为创新型的ERP技术平台也是通过类似Odoo企业版和法国邮电集团的方式一样完成自定义的内部版本分发，将自主创新的功能细分为内部协议、开源协议等多种交叉模式，如图2所示。

第二种路径方式对于国内现实情况极为适用，包括中科院的麒麟操作系统（UBUNTU LINUX分支）等开源技术平台均采用类似的第二种路径方案。在发展国内自主可控的ERP系统中，可以借鉴Odoo已有并成熟的完全开源可控的技术架构，同时将一些复杂的业务流程和配置类的ERP必须具有的属性保留，再结合国内实际企业的情况进行深入改造，我们可以通过这样的模式缩短产品研发期与推广期的问题，生态上又很容易的快速建立，结论是通过Odoo的开源技术平台发展国内自主可控的ERP管理系统，是非常适合的技术路径方案。

2 通过Odoo构建自主可控的先进ERP系统

如图3所示。

Odoo是基于PYTHON+HTML5语言所开发的快速开发平台框架所构建的具体模块化的ERP应用技术平台，我们从Odoo的平台简介和技术架构及部署方案3个层面分开阐述。

2.1 Odoo平台介绍

Odoo，以前叫OPENERP，是比利时Odoo S.A.公司开发的一个开源自由的遵守国际LGPL开源协议的企业应用软件套件，开源套件包括一个企业应用快速开发平台，以及2万个以上的第三方开发的企业生态应用市场。Odoo适用于各种类型规模的企业应用，并且由于前端采用HTML5加后台JS渲染，确保了跨平台，跨设备访问，仅需标准浏览器即可访问应用。

Odoo默认已有的基础功能包含：企业基本的进销存、采购、销售、MRP生产制造、品保质量保障、企业招聘、员工合同、休假、午餐管理、内部论坛、车队管理、内部聊天IM沟通、客诉追溯管理、CRM客户关系管理、VOIP、E-SHOP电子商务、企业网站、财务会计、银行对账、资产管理、HR工资管理、预算管理、WMS仓库库存管理、POS、社区论坛、项目管理、条码、PLM等。

Odoo是真正意义上的纯B/S架构设计理念，全网全设备覆盖，支持市面上任何一种操作系统的客户端与服务端的部署。客户端仅需通过浏览器就能自适应访问，做到真正意义上的全网互联。

基于上述的論述可以得到这样的结论，无论从平台特性还是与功能应用覆盖面上，Odoo已经处于世界领先的ERP技术范畴、超越SAP、ORACLE等欧美发达国家所创造的一流先进的ERP产品技术框架。同时彻底去客户端化，通过标准浏览器即可访问支持，更符合国内未来企业的跨设备跨平台的需求。

2.2 Odoo技术架构

Odoo已经整合了互联网最新的第三方PYTHON技术类库和JS技术类库，又同时根据自身的MVC软件工程规范逻辑进行了模块功能的解耦，将自己的数据层、逻辑层、表现层完全独立化操作，甚至在语言及方法调用上做到了彻底的分离，同时兼顾快速开发平台的高效建模的特性，又把复杂的动作方法进行标签定义。通过少量的PYTHON代码加之Odoo自身ORM的框架特性，可以快速生成一个数据表单业务的基础结构。如图4所示。

通过上述技术架构蓝图中，我们可以看到，Odoo在关系型数据库支持层采用了大型混合型开源自主可控的数据库系统POSTGRESQL系统，该数据库的最大优势是数据负载量与高并发性能，可以媲美ORACLE。这可以使国内企业未来在数据负载量与高并发性能中承担更多的数据承载服务的需求。

模型层的快速建模的工作原理是通过ORM数据持久支持层作为数据库交互通讯的接口，ORM API接口调用方法如：如记录集方法@API.MULTI、单例记录方法@API.ONE、类静态方法@API.MODEL、动作触发方法@API.

ONCHANGE及@API.DEPENDS计算型方法等。

笔者编写的代码示例，可以看到通过@API.ONCHANGE方法来进行系统反馈时间与服务器当前日期的比对进行错误异常的JSON格式化文件的提醒抛出的具体编写规范实例。

@API.ONCHANGE（'MEMBER_ID'）

DEF ONCHANGE_MEMBER_ID（SELF）：

TODAY = FIELDS.DATE.TODAY（）

IF SELF.REQUEST_DATE ！= TODAY：

SELF.REQUEST_DATE = FIELDS.DATE.TODAY（）

RETURN {

'WARNING'：{

'TITLE'： 'CHANGED REQUEST DATE'，

'MESSAGE'： 'REQUEST DATE CHANGED TO TODAY.'

}

}

由于Odoo的ORM层承担着开发平台最重要的核心开发框架，但基于这之上还需要其他的公共应用容器模组进行封装，如MESSAGE层承担着各功能模块间信息通讯的作用，Odoo自带的每个表单模型默认继承MESSAGE层的技术应用，将单据的所有操作记录都写入到MESSAGE数据表单之中。如图5所示。

从图5可以看到每个的单据工作变更记录都写入到MESSAGE数据表单，MESSAGE自带推送机制，可以实现IM或是邮件的信息推送与数据交互。通过CONTROLLERS层进行不同间的APP支持应用层的通讯完成模块数据的交互。CONTROLLERS层是主要通过内部API规范进行数据间的互动调用来确保数据交互与模组间的安全分割。

以上测试集代码用于搜索客户及建立销售合同、确认销售合同及合同打款单最具实际业务高并发的场景，用于测试Odoo依照线性访问的性能优势。采用硬件测试环境，测试Odoo应用服务器的硬件配置： I5双核CPU，16G内存，SSD硬盘;Odoo数据库服务器硬件配置：12核CPU，16G内存。按照之前测试代码和OdooLOCUST用户并发数模拟，最终测试结果如图8所示。

1） 1个并发用户和50个并发用户，系统响应速度几乎没有变化，5个操作的响应时间都在2秒上下;

2） 当100个并发用户时，系统响应速度略有下降，响应速度在2秒至2.5秒之间;

3） 从100个并发用户到200个并发用户，系统响应速度略有波动，但都在2秒至3秒之间;

4） 以大型企业的用户数800为例，连接用户数200为例，平均并发用户数50为例，峰值并发用户数71的情况下，系统常见操作的响应时间在2.5秒以下;

5） 考虑到将来的发展，如果用户总数翻一倍，用户数1600，连接用户数400，平均并发用户数100，峰值并发用户数达到142人，系统常见操作的响应时间在3秒以内;

6） 正常情况下，系统响应时间在4秒内（考虑增加1秒的网络延迟）。根据用户响应时间标准，这个响应时间属于“比较不错”的用户体验。

通过上述结论，Odoo从部署架构与性能测试的结果，完全可以承担大型企业级的应用，如果将POSTGRESQL的NOSQL特性发挥出来并进行功能深入的改造，可以有更大性能提升，如达到上述假设，将完全可以承担国家级工业互联网平台化访问并发量的需求。

3 总结

通过上述文中阐述，我們可以看到无论Odoo自身的开源技术特性、既有可移植使用的功能、先进的平台技术架构、灵活的部署方案、性能压力测试等关键性技术指标，已经可以得到Odoo各方面的技术要求是足以满足发展及构建国内自主可控ERP系统较为优秀的技术路线方式。

参考文献

[1] 冯明丽，陈志彬. 基于电信运营商的大数据平台及去IOE应用研究[J]. 电信技术 ，2015（9）：25-28.

[2] 周荣茂. 五种开源协议的比较（BSD，APACHE，GPL，LGPL，MIT）[J]. 开源时代， 2010.

[3] 周爱武，汪海威，李知兵. 计算机操作系统教程[M].北京： 清华大学出版社，2005.

（收稿日期： 2020.07.20）

作者简介：

杨浔波（1986-），男，本科，助理工程师，研究方向： Odoo ERP实施、开发、部署架构等相关企业信息服务。