JeecgBoot多租户模式下自定义SQL下拉组件租户隔离问题解析

在JeecgBoot报表系统3.7.3版本中，当项目配置为多租户模式(saasMode: tenant)时，开发人员可能会遇到一个典型问题：使用自定义SQL作为数据源的下拉列表组件无法自动实现租户数据隔离。本文将深入分析该问题的技术背景、解决方案以及最佳实践。

问题现象分析

在多租户架构设计中，数据隔离是核心需求。JeecgBoot通过配置saasMode: tenant启用了租户级别的数据隔离机制。然而，当报表设计中使用自定义SQL作为下拉列表的字典数据源时，系统不会自动在SQL中注入租户过滤条件。

例如，开发人员配置了如下字典查询SQL：

SELECT `code` as value,`name` as text 
FROM wms.wms_warehouse_master 
WHERE del_flag=0

在理想的多租户场景下，此SQL应当自动附加租户过滤条件，但实际上并未实现这一功能。

技术原理探究

JeecgBoot的多租户隔离机制主要通过以下方式实现：

1. 自动SQL改写：系统会对标准数据源查询自动添加租户字段过滤条件
2. 上下文注入：当前租户信息存储在请求上下文中
3. 拦截器机制：通过MyBatis拦截器实现SQL改写

然而，自定义SQL字典查询存在以下特殊性：

• 属于动态SQL片段，不经过标准数据源处理流程
• 执行时机早于租户过滤器
• 缺乏明确的租户字段标识

解决方案详解

方案一：使用系统变量拼接租户条件

JeecgBoot提供了系统变量机制，可以在SQL中直接引用预定义的变量：

SELECT `code` as value,`name` as text 
FROM wms.wms_warehouse_master 
WHERE del_flag=0 
AND tenant_id = #{sys.tenant_id}

其中#{sys.tenant_id}会自动替换为当前用户的租户ID。

方案二：自定义系统变量扩展

对于更复杂的需求，可以扩展自定义系统变量：

1. 实现ISysVariablesService接口
2. 注册自定义变量处理器
3. 在SQL中使用#{custom.xxx}格式引用

例如创建租户代码变量：

public class TenantVariableService implements ISysVariablesService {
    @Override
    public String execute(String varName) {
        return TenantContext.getCurrentTenant();
    }
}

方案三：前端过滤处理

作为备选方案，可以在获取数据后通过前端JavaScript进行过滤：

function filterByTenant(data) {
    const tenantId = getCurrentTenant();
    return data.filter(item => item.tenant_id === tenantId);
}

最佳实践建议

1. 表设计规范：确保所有需要隔离的表都包含tenant_id字段
2. SQL编写规范：显式包含租户条件，即使系统可能自动添加
3. 测试验证：在多租户环境下充分测试数据隔离效果
4. 性能考虑：为tenant_id字段建立索引提高查询效率
5. 异常处理：考虑租户ID不存在时的降级方案

总结

JeecgBoot报表系统的多租户功能为SaaS应用提供了良好的基础架构支持。理解自定义SQL组件与租户隔离机制的交互原理，能够帮助开发人员构建更安全、可靠的多租户应用。通过本文介绍的解决方案，开发人员可以灵活应对各种业务场景下的数据隔离需求。