金色的SAP PO管理平台（永久保存SAP PO中间件消息之六）

伴随着公司ESB（企业服务总线）一期项目的结束，我针对SAP-PO的特点开发了一个“ESB管理平台”，它采用C#  web、FineUI前端，EntityFrame、LINQ技术，它的卖点如下：

一、平台的出现，消除了PO中间件消息抢占HANA数据库内存资源的痛点

        现在企业部署SAP S4 HANA的主流架构是使用HANA数据库2.0的多租户模式，即多个应用的数据库部署在一个大库里，共用HANA一体机硬件上的物理内存资源。要知道经过SAP认证的一体机并不便宜，服务器上的物理内存也还是非常昂贵，所以多租户模式的好处是显而易见，集中管理降低成本。多个数据库挤在一个房间里，经过一段时间的运维，群里有好些BASIS管理员开始担忧了，因为大家发现，数据库的增长不好控制或者说控制不住。

        在HANA一体机物理内存总量无法随时扩展的前提下：如果某个数据库的增长偏离了最初的设计，就会对其它数据库构成威胁。有一些BASIS在群里反馈，他们的PO数据库暴涨，威胁到了ERP的S4数据库。我想可能是因为他们的PO数据库一直保存了每天上万条的接口消息没有删除。但直接把消息清除，好像有些不妥，在有需要详细查看报文内容的场景出现，这样会显得系统管理运维的能力不足，使管理员处于劣势。

        在这个点上，有没有解决办法呢？有的。其实PO的数据库可以这样来管理，定制PO的后台作业，定期的归档（删除）掉PO数据库中的消息报文；把PO每天上万条的的消息报文，放在我的管理平台自己的数据库中，就能解决了这个问题。

二、平台的出现，低成本实现中间件消息报文的永久落地

        HANA内存数据库很快，因为数据都放在内存中，但是数据都放在内存中，占用内存的代价很昂贵，中间件的消息报文，本质就是一些流水账，对这些报文的内容查询只有在接口故障追溯的时候才会用到，这种场景很少发生。这些冷数据就应该放到廉价的磁盘中，而非内存。所以我把PO上消息报文统统都拿出来，放到传统的关系型数据库中，保存在磁盘上，甚至连磁盘空间我也想省一省，所以我还对这些消息报文再加了压缩（取的时候再解压就行）。这样最终，我发现在管理平台中，以极小的代价保存了每天上万条的消息报文，保存一年消息报文的磁盘空间只需要100~200GB。关于技术实现，可以参看我之前的博文专题。

三、平台的出现，无限扩展ESB平台的管理功能

我们都知道SAP的PO是一个商业套件，你无法在上面扩展你想要的其它功能；

SAP PO的底层功能很强大，但数据可视化这块很简陋，就连基本的消息查询只有一个报表，解决即时出现的问题是可以的，但如果需要复杂一点的查询或报表展示就没有了。接口消息底层的数据，其实就是对接口消息数据的记录，每一条消息，从请求方，到应答方，在返回请求方，这一连串节点的消息记录。我们从PO的数据库拿到了这些数据，放到自己的数据库中，后续的功能，就可以自己来了。

ESB管理平台，采用C#的asp.net环境，选用FineUI前端，对后端SQLserver数据库的操控是使用微软的EntityFrame框架和面向对象的LINQ查询语法。这些组件构成了真正的低代码平台，因为.net的强大，开发人员只需要很小的工作量，就可以快速实现很强大的功能。

类似SAP的用户权限管理：

类似SAP报表的查询功能：

数据展示1：

数据展示2：

四、平台的出现，真正从接口开发的全生命周期管理接口

        本次宝能汽车ERP项目，我们有2个开发团队，一个在深圳总部，一个在昆山，都在独立开发，很快产生了一个问题，接口编号需要统一管理来产生。

        某日，团队A新建了一个接口，直接按命名规则JK0069这个号命名，并在PO中配置这个接口。这时正好团队B也新建了一个接口，自己按命名规则也用到了JK0069这个号，并且完成了一些配置。最后，同一个JK0069，被定义到2个接口上，真是傻傻分不清啊，怎么避免这种情况？

        我开发了一个小功能，并且规定2个团队都必须到我们管理平台定义接口。平台有一个新建接口页面，提供接口的定义功能，JK00XX的编号，是页面自己流水产生，这样我们只有一个源头产生接口编号，从根本上杜绝了重号的发生。这只是平台提供的其中一个小功能。