需求描述

基于微服务接口，制作如下报表：按地区城市、销售人员统计全部产品的销售情况
涉及服务接口有三个
订单服务接口：http:// 111.198.29.168:8503/getOrders/bDate/eDate，其中 bDate 与 eDate 为路径参数，直接在 URL 中拼接即可，参数代表查询的起始和结束日期
雇员服务接口：http:// 111.198.29.168:8503/getEmp
产品服务接口：http:// 111.198.29.168:8503/getProducts
返回的数据均为为 JSON 格式：

报表呈现效果如下：

问题分析

这个报表本身制作和取数计算都不是很难，如果数据来源是数据库，用一句类似下面的 SQL 就可以搞定

SELECT M.*,产品.产品名称 
FROM (
    SELECT P.*,雇员.姓氏||雇员.名字 姓名,雇员.职务 
    FROM(
        SELECT 订单.雇员ID,订单.货主地区,订单.货主城市,订单.订购日期,订单.订单ID,
           订单明细.产品ID,订单明细.单价*订单明细.数量*订单明细.折扣 商品金额
        FROM 订单 JOIN 订单明细 ON 订单.订单ID=订单明细.订单ID
        WHERE 订购日期 BETWEEN '2012-08-01'AND '2013-09-01') AS P
    RIGHT JOIN 雇员 ON 雇员.雇员ID = P.雇员ID) AS M
RIGHT JOIN 产品 ON M.产品ID=产品.产品ID

但数据来源是微服务时就比较麻烦了，微服务一般通过 Webservice、Restful 等形式对外提供服务接口，只会提供少量固定的参数，即不会暴露数据库访问接口（甚至就不知道有没有数据库），更没有灵活的 SQL 了
1. 连接服务麻烦
很多报表工具都没有直接提供 Webservice、Restful 接口，怎样连接服务层的数据就是个麻烦，只能是通过自定义数据集写代码来访问
2. 读取解析麻烦
连接后，像上面数据服务中返回的这种 JSON 格式数据，怎么读取、解析也是个难题
连接和解析虽然麻烦，但毕竟还是一次性的，写一段程序对所有微服务都可以用，但是：
3. 复杂计算麻烦
读取数据后，因为用不了 SQL，原本可以在 SQL 中完成的查询计算，现在做不了了，只能把数据取到报表里来算，但报表计算能力有限，复杂的，还是得用 JAVA 来硬编码，怎么算更是个麻烦
这些麻烦，最后都会导致：
4. 项目维护麻烦
都用 JAVA 来写，报表本身因为业务原因又总需要修改或者新增，有点改动就得改 JAVA，就得重启应用，做不了热切换还影响应用稳定，项目管理上又是很大的麻烦

润乾报表基于 SPL 提供了脚本数据集，脚本数据集内置了 Webservice、Restful 接口，可以直接针对微服务架构访问取数，并进行各类计算，支持热切换，能很好的为报表做数据准备

实践过程

用润乾报表脚本数据集直接对接微服务接口，进行取数解析和计算，然后把数据供报表展现
订单数据接口：可获取地区、城市、雇员 ID、产品 ID、订购日期、商品金额，预留有订购日期的开始与结束时间参数入口，可查询某段时间内订单；
销售人员数据接口：获取全部销售人员信息，含雇员 ID、姓名、职务；
产品信息接口：获取所有产品 ID 及产品名称

（1）新建报表模板并制作基本格式，设置参数

参数

（2）新增、定义脚本数据集，并设置报表取数表达式

脚本数据集完整文本信息如下

此步骤为关键步骤！！！
A1 A2 为微服务登录验证
A3 A6 A8 用 httpfile 函数直接获取数据
A4 A7 A9 用 json 函数把多层数据转化为二维表，然后在脚本中直接进行计算
定义报表取数表达式，如下：

报表结果：

至此，基于微服务的报表制作就完成了
原本需要用 JAVA 硬编码连接服务取数，解析 JSON，进行计算，费很长时间才能做好的报表，现在轻松几句脚本就搞定了，而且脚本是存在报表文件中的，有什么需要改动的，直接改了脚本，刷新报表就是最新结果了，不需要重新编译，不需要重启服务，用起来更方便简单

总结

润乾报表的脚本数据集，可以轻松应对微服务架构下的报表制作难题
1. 能直接连接数据服务获取数据
2. 能轻松解析多层 JSON
3. 能代替 SQL 和 JAVA 进行高效计算
4. 能降低和应用的耦合度，做到热启动，能放大微服务构架的优势

原本需要高级人员来写 JAVA 搞定微服务报表，现在简短几句脚本就搞定了。润乾报表也很便宜，三万一年随便用，接近于开源软件了，可以很低成本下载实践