现在有很多机构都开始建设统一的数据平台，对应用提供数据都是用服务形式了，比如 Webservice、Restful ，不再直接把数据库暴露给应用，这样做好处多多，规范，安全，方便管理…

但是，对于报表开发来说，就不太好了，报表做起来更费劲儿了

首先怎么连接服务层的数据就是个麻烦，很多报表工具都没有直接提供 Webservice、Restful 接口，只能是通过自定义数据集写代码来访问

即使提供了访问接口，报表做起来也并不轻松

因为没有 SQL 了，原本可以在 SQL 中完成的查询计算，现在做不了了，只能在报表端来完成

如果数据量比较小，也不用过多计算，还好一点，取完数报表算一下然后呈现就可以

如果数据量大，计算又复杂，那就会很麻烦，报表里可以做一些简单的计算，复杂的并不擅长，那就得在自定义数据集中，通过 JAVA 硬编码来写计算，WebService 和 Restful，格式通常是多层的 Json 和 XML，多层数据可以承载更丰富的信息，但结构上比传统的二维数据复杂，计算难度也更大，需要高级人员耗费很多工作量才能完成，计算的麻烦，要远比取数严重的多，而且JAVA 程序还有一个很大的弊端，那就是会和应用高度耦合，有新增或者改动时，都得拖着整个应用一起停摆编译重启才可以，根本做不到热切换，会严重影响应用的稳定性

还有些时候，用 JAVA 做计算的工作量太大忍受不了了，甚至不得不再搞个前置或嵌入的数据库，把数据导入到这个数据库中，然后利用 SQL 的计算能力算完再给到前端报表，这样做更麻烦，会导致架构非常臃肿，报表也没有实时性可言了

虽然也有 XPath/JsonPath、Python Pandas、Scala 这类专业的技术来处理 json/XML，但这些技术有的计算能力不强，有的不易于集成，报表工具本身已经是第三方的东西，现在又需要多一个第三方的工具来辅助，还得考虑架构问题，对于报表和整个应用来说，都不是一个好选择

报表工具直接可以处理、计算这些服务层的数据才是好的方案

润乾报表就有这样的能力！不需要自定义数据集硬编码，不需要其他工具辅助，直接在报表内就把这些难题解决了

独有数据准备层

润乾报表有独有的数据准备计算层（基于流行的集算器 SPL 计算工具开发）

它支持各类数据源，包括 Webservice、Restful，可以在报表的脚本数据集中直接连接各类数据源进行取数计算，而且支持混算，以及复杂运算

直接访问取数

SPL 脚本中，内置了 Webservice、Restful 接口，直接可以访问取数，并解析成报表可以使用的结构化数据

比如访问 WebService 接口：直接在脚本数据集中用函数连接取数就可以

函数 ws_client 建立 WebService 客户端，函数 ws_call 查询 WebService 服务

访问 Restful 接口

函数 httpfile 用于访问 url 网址，可指定端口、Header、字符集、IPV4/V6、Post/Get，支持 Cookie 或令牌的鉴权方式

经过 SPL 的函数解析后，原本的 Json 格式数据

{EID:1,NAME:“Rebecca”,SURNAME:“Moore”,GENDER:“F”,STATE:"California",
BIRTHDAY:1974-11-20,HIREDATE:2005-03-11,DEPT:“R&D”,SALARY:7000},

{EID:2,NAME:“Ashley”,SURNAME:“Wilson”,GENDER:“F”,STATE:“New York”,
BIRTHDAY:1980-07-19,HIREDATE:2008-03-16,DEPT:“Finance”,SALARY:11000},

{EID:3,NAME:“Rachel”,SURNAME:“Johnson”,GENDER:“F”,STATE:“New Mexico”,
BIRTHDAY:1970-12-17,HIREDATE:2010-12-01,DEPT:“Sales”,SALARY:9000}

就变成了这样的结构化数据，就直接可以给报表用，或者经过计算后再给报表用了

快速高效运算

SPL 计算层，不仅可以访问取数，还可以代替 SQL，JAVA 进行计算

比如解析多层 Json 后得到多层结构化数据（序表），然后就可以针对这个序表进行各种 SQL 式的计算了，把各类指标计算完成后，再把结果给到报表使用

SPL 还支持分步计算、有序计算、分组后计算等逻辑较复杂的计算，很多时候还比 SQL，JAVA 的性能要好很多，不仅写起来简单，而且算的更快，比如：找出销售额累计占到一半的前 n 个大客户，并按销售额从大到小排序：

SPL 独有的函数也很丰富，能有效简化很多计算，比如

季度增减： elapse@q("2020-02-27",-3) // 返回 2019-05-27

N 个工作日之后的日期： workday(date("2022-01-01"),25) // 返回 2022-02-04

字符串类函数，判断是否全为数字：isdigit("12345") // 返回 true

取子串前面的字符串： substr@l("abCDcdef","cd") // 返回 abCD

按竖线拆成字符串数组： "aa|bb|cc".split("|") // 返回 \["aa","bb","cc"\]

这些原本需要在 JAVA 中费劲才能准备和计算好的数据，用润乾报表的 SPL 计算层，简短几个函数、表达式就都搞定了

低耦合热切换

而且 SPL 计算层的脚本是存在报表模板里的，不会和原始应用发生耦合，有改动和新增的时候，更新一下报表模板就可以，不需要重新编译，不需要重启应用，随时更新随时访问，这就能做到热切换，避免了 JAVA 代码的高耦合、一改动就得整个应用跟着停摆重启的麻烦

技术创新与时俱进

访问数据服务层的数据做报表，这样的需求和场景已经越来越多，毕竟是架构的潮流，好的报表工具，应该对这样的新需求保持敏感，时刻感知用户的难点，关注新的技术趋势，保持创新，与时俱进才可以

润乾报表，专注报表行业 20 年，作为主流的专业报表工具，一直在与时俱进，积极的探索和解决这些用户的新需求和困难，它的 SPL 计算层，可以在工具内轻松解决这个难题，省去用户手工写代码的麻烦，大幅度提升了开发效率，也给用户省出更多人工成本

而且润乾报表 SPL 计算层，也远不止访问计算服务层数据这一点功能，它还可以解决很多报表数据准备阶段的难题，比如各类多源混算，复杂多步过程式计算，实时 T+0 报表等等，把大数据时代报表遇到的新难题：数据准备困难给解决了，这是报表未来技术的发展方向，也是报表行业的第二次技术革命

报表工具的二次革命

有了 SPL 数据准备层，原本复杂的、需要耗费大量成本手工去做的数据准备工作，就都可以用工具来快速完成了，整个报表从数据准备到表样制作全部工具化了，再也不怕报表做起来没完没了了

“凌波五步”解决报表没完没了

有连接数据服务层不方便的同学，或者给报表准备数据各种费劲头疼的同学，可以下载试试了，看看用润乾报表的 SPL 数据准备层来做，能比原先快多少，方便多少，另外这个 SPL 计算层，并不需要额外多花费成本，在润乾 2W 的脚本版中就自带了