丸子·张（OnesZhang） - 一位热爱分享的小小IT工程师，提供实用技巧、软件推荐、网站资源、踩坑经验和泛微OA相关内容，探索更多精彩！
[泛微 EC9] WorkflowToModeFormulaUtil 公式工具类使用指南
泛微OA E9 中用于工作流字段公式转换的工具类，所有方法 public static，零外部依赖，可独立使用。 适用场景 向第三方系统动态传参时，字段类型不一致需要公式转换；脱离流程上下文做数值/日期/文本计算。 类信息项目说明包路径weaver.formmode.interfaces.action类名WorkflowToModeFormulaUtil依赖无外部依赖，纯 Java 工具类返回值所有方法返回 String，异常返回 ""方法一览 日期类数值类文本类 year — 提取年份WorkflowToModeFormulaUtil.year("2025-06-01") // → "2025" WorkflowToModeFormulaUtil.year("2025/6/1") // → "2025" WorkflowToModeFormulaUtil.year("") // → ""month — 提取月份（1-12）WorkflowToModeFormulaUtil.month("2025-06-01") // → "6" WorkflowToModeFormulaUtil.month("2025-12-31") // → "12" 注意：返回 1-12，不是 Calendar 的 0-11。 day — 提取日WorkflowToModeFormulaUtil.day("2025-06-15") // → "15" WorkflowToModeFormulaUtil.day("2025-06-05") // → "5"days — 两日期天数差// 两个重载：String 参数 / List 参数 WorkflowToModeFormulaUtil.days("2025-01-01", "2025-06-01") // → "151" WorkflowToModeFormulaUtil.days("2025-06-01", "2025-01-01") // → "-151" // List 用法 List<String> dates = Arrays.asList("2025-01-01", "2025-06-01"); WorkflowToModeFormulaUtil.days(dates); // → "151" 支持带时间格式："2025-01-01 08:00:00"，计算时只取日期部分。 datedelta — 日期加减天数WorkflowToModeFormulaUtil.datedelta("2025-06-01", 10) // → "2025-06-11" WorkflowToModeFormulaUtil.datedelta("2025-06-01", -5) // → "2025-05-27" WorkflowToModeFormulaUtil.datedelta("2025-12-31", 1) // → "2026-01-01"sum — 求和// 可变参数（至少2个） WorkflowToModeFormulaUtil.sum(1.0, 2.0, 3.0) // → "6.0" // List 参数 List<Double> list = Arrays.asList(100.5, 200.3, 300.2); WorkflowToModeFormulaUtil.sum(list); // → "601.0"abs — 绝对值WorkflowToModeFormulaUtil.abs(-123.45) // → "123.45" WorkflowToModeFormulaUtil.abs(123.45) // → "123.45"average — 平均值// 可变参数（至少2个） WorkflowToModeFormulaUtil.average(2.0, 4.0) // → "3.0" // List 参数 List<Double> list = Arrays.asList(100.0, 200.0, 300.0); WorkflowToModeFormulaUtil.average(list); // → "200.0" average 的可变参数版本计算分母是 num3.length + 2，传 2 个以上参数时注意。 concatenate — 字符串拼接// 可变参数（至少2个） WorkflowToModeFormulaUtil.concatenate("姓名:", "张三", " 工号:", "001") // → "姓名:张三 工号:001" // List 参数 List<String> list = Arrays.asList("A", "B", "C"); WorkflowToModeFormulaUtil.concatenate(list); // → "ABC"replace — 子串替换// replace(原字符串, 起始位置, 替换长度, 新字符串) WorkflowToModeFormulaUtil.replace("Hello World", 7, 5, "Java") // → "Hello Java" 坑点 startnum 从 1 开始，不是从 0 开始！"Hello World" 的第 7 个字符是 W。 完整调用示例示例1：日期计算 — 合同到期提醒import weaver.formmode.interfaces.action.WorkflowToModeFormulaUtil; // 计算合同剩余天数 String startDate = "2025-01-01"; String endDate = "2025-12-31"; String remainDays = WorkflowToModeFormulaUtil.days( new java.text.SimpleDateFormat("yyyy-MM-dd").format(new java.util.Date()), endDate ); // 到期前30天的日期 String warnDate = WorkflowToModeFormulaUtil.datedelta(endDate, -30); // 提取年份用于日志 String year = WorkflowToModeFormulaUtil.year(endDate); System.out.println(year + "年合同，剩余" + remainDays + "天");示例2：数值聚合 — 费用汇总// 模拟从第三方获取的费用数据 double travelFee = 1500.0; double hotelFee = 2800.0; double mealFee = 600.0; // 求和 String total = WorkflowToModeFormulaUtil.sum(travelFee, hotelFee, mealFee); // → "4900.0" // 取绝对值（退款场景） String refund = WorkflowToModeFormulaUtil.abs(-350.5); // → "350.5" // 平均日均费用 int days = 5; String dailyAvg = WorkflowToModeFormulaUtil.average( Double.parseDouble(total) / days, Double.parseDouble(total) / days );示例3：文本拼接 — 生成编号String prefix = "PO"; String year = WorkflowToModeFormulaUtil.year("2025-06-01"); // "2025" String seq = "001"; String orderNo = WorkflowToModeFormulaUtil.concatenate(prefix, year, seq); // → "PO2025001"与 ExpressionEvaluator 组合使用 最佳实践 WorkflowToModeFormulaUtil 做类型转换，ExpressionEvaluator 做表达式计算，两者搭配覆盖大多数公式场景。 import org.wltea.expression.ExpressionEvaluator; import org.wltea.expression.datameta.Variable; import weaver.formmode.interfaces.action.WorkflowToModeFormulaUtil; // 1. 用 FormulaUtil 做预处理 String yearStr = WorkflowToModeFormulaUtil.year("2025-06-15"); // "2025" String daysStr = WorkflowToModeFormulaUtil.days("2025-01-01", "2025-06-15"); // "165" // 2. 组装变量 List<Variable> vars = new ArrayList<>(); vars.add(Variable.createVariable("amount", 50000.0)); vars.add(Variable.createVariable("days", Integer.parseInt(daysStr))); vars.add(Variable.createVariable("threshold", 10000)); // 3. 用 ExpressionEvaluator 计算表达式 Object result = ExpressionEvaluator.evaluate( "amount / days * 30 > threshold", vars ); // → true（月均 > 1万）注意事项要点说明返回类型全部返回 String，数值场景需手动 Double.parseDouble()异常处理所有方法内部 try-catch，异常返回空字符串 ""日期格式自动兼容 - 和 / 分隔符，可带 HH:mm:ssmonth 返回值1-12，不是 Calendar 的 0-11replace 起始位置从 1 开始，不是从 0线程安全所有方法无状态，线程安全独立使用不依赖流程ID、表单ID、配置项，可脱离流程上下文直接调用
概述通过 ViewRequestForwardSPA.jsp 查看目标流程时，系统在 RequestAuthenticationService.verifyRequest() 中进行权限校验。共有 14 条校验路径，按优先级依次检查，命中任意一条即授予查看权限。核心入口JSP入口: workflow/request/ViewRequestForwardSPA.jspSPA路由: /spa/workflow/static4form/index.html?_rdm={timestamp}#/main/workflow/req?{params}JSP路由: /workflow/request/ViewRequest.jsp?haveVerifyForward=true&{params}权限校验类: com.api.workflow.service.RequestAuthenticationService校验方法: verifyRequest()路由差异路由权限校验方式authStr参数desrequestid参数SPA (LoadParamCmd)RequestAuthenticationService.verify()有效不需要JSP (ViewRequest.jsp)Session机制 (resrequestid{N})不用于校验URL参数被忽略，仅读Session全部校验路径（按简单到复杂排列）1. 共享权限（无条件检查，0个参数）// RequestAuthenticationService if (getRequestWfShareRight(info, requestid)) { return true; }URL: ViewRequestForwardSPA.jsp?requestid=1908315条件: 用户对目标流程有共享权限校验逻辑: WFShareAuthorization.getWorkflowShareJurisdiction(requestid, user)前置条件: 管理员或其他操作人已将流程共享给当前用户参数: 0个额外参数2. 操作者权限（无条件检查，0个参数）// RequestAuthenticationService if (getRequestUserRight(info, requestid)) { return true; }URL: ViewRequestForwardSPA.jsp?requestid=1908315条件: 用户是目标流程的当前操作人校验逻辑: 查询 workflow_currentoperator 表前置条件: 用户在流程的当前操作人列表中参数: 0个额外参数3. 创建者权限（SPA层额外检查，0个参数）// LoadParamCmd if (creater == userid && creatertype == usertype) { canview = true; }URL: ViewRequestForwardSPA.jsp?requestid=1908315条件: 用户是流程创建人校验逻辑: 比对 workflow_requestbase.creater 字段前置条件: 用户创建了该流程参数: 0个额外参数4. 监控权限（1个参数）// RequestAuthenticationService if (ismonitor == 1 && getRequestMonitorRight(info, requestid)) { return true; }URL: ViewRequestForwardSPA.jsp?requestid=1908315&ismonitor=1条件: 用户是目标流程的监控人校验逻辑: WFUrgerManager.getMonitorViewRight(requestid, userid)前置条件: 流程配置了监控人，且当前用户在监控人列表中参数: 1个（ismonitor=1）5. 督办权限（1个参数）// RequestAuthenticationService if (urger == 1 && getRequestUrgerRight(info, requestid)) { return true; }URL: ViewRequestForwardSPA.jsp?requestid=1908315&urger=1条件: 用户是目标流程的督办人校验逻辑: SuperviseManagerBiz.hasWorkflowViewRight(user, requestid)前置条件: 流程配置了督办人，且当前用户在督办人列表中参数: 1个（urger=1）6. 干预权限（1个参数）// RequestAuthenticationService if ("1".equals(isintervenor) && getRequestInterventorRight(info, requestid)) { return true; }URL: ViewRequestForwardSPA.jsp?requestid=1908315&isintervenor=1条件: 用户是目标流程的干预人校验逻辑: SysWFLMonitor.getWFInterventorRightBymonitor(userid, requestid)前置条件: 流程配置了干预人，且当前用户在干预人列表中参数: 1个（isintervenor=1）7. 相关交流权限（1个参数）// RequestAuthenticationService if (fromCommunication > 0 && getRequestCommunicationRight(info, requestid)) { return true; }URL: ViewRequestForwardSPA.jsp?requestid=1908315&fromCommunication=12345条件: 流程有相关交流记录校验逻辑: WorkflowCommunicationBiz.hasWfResourceRight(requestId, fromCommunication)前置条件: 流程存在相关交流，且交流ID匹配参数: 1个（fromCommunication={交流ID}）8. 主子流程权限（1个参数）// RequestAuthenticationService if ((isrequest.equals("2") || isrequest.equals("3") || isrequest.equals("4")) && getRequestSubMainRight(info, requestid)) { return true; }URL: ViewRequestForwardSPA.jsp?requestid=1908315&isrequest=2条件: 目标流程是当前流程的主流程/子流程/平行流程校验逻辑: 查询 workflow_subwfrequest 表isrequest值: 2=主流程, 3=子流程, 4=平行流程前置条件: 流程之间存在主子关系参数: 1个（isrequest=2/3/4）9. 建模关联授权（4个参数）// RequestAuthenticationService if (formmodeflag.equals("formmode_authorize") && getModeRight(info, requestid)) { return true; }URL: ViewRequestForwardSPA.jsp?requestid=1908315&formmode_authorize=formmode_authorize&authorizemodeId=5501&authorizefieldid=403885&authorizeformmodebillId=202514条件: 建模数据字段值包含目标流程requestid校验逻辑: ModeRightInfo.isFormModeAuthorize()校验步骤:检查用户对建模模块是否有查看权限查询 ModeFieldAuthorize 表确认字段配置了关联授权查询建模数据表中该字段的值是否包含目标requestid前置条件: 建模模块已配置关联授权，且数据字段值正确参数: 4个formmode_authorize=formmode_authorize（标识位）authorizemodeId={建模模块ID}authorizefieldid={关联授权字段ID}authorizeformmodebillId={建模数据ID}10. 相关流程权限（2-3个参数）// RequestAuthenticationService if ((isrequest.equals("1") || "1".equals(isfromTd)) && getrelateRequestRight(info, requestid)) { return true; }URL（方式A）: ViewRequestForwardSPA.jsp?requestid=1908315&isrequest=1&desrequestid=1908325URL（方式B）: ViewRequestForwardSPA.jsp?requestid=1908315&isrequest=1&desrequestid=1908325&fieldid=373385条件: A/B流程有共同操作人 + 表单字段值匹配校验逻辑: getrelateRequestRight()校验步骤:防篡改校验：A/B流程操作人取交集，必须有共同操作人字段值校验：查询A流程表单字段值是否包含B流程requestid或签字意见校验：查询A流程 workflow_requestlog.signworkflowids 是否包含B流程requestid前置条件: 两个流程有共同操作人，且表单数据关联正确参数: 2-3个isrequest=1（标识位）desrequestid={源流程requestid} 或 authStr + authSignatureStrfieldid={表单字段ID}（可选，指定具体字段）11. 计划会议权限（2个参数）// RequestAuthenticationService if ((("workplan".equals(fromModul) || "meeting".equals(fromModul)) && modulResourceId > 0) && getPlanMeetingRight(info, requestid)) { return true; }URL: ViewRequestForwardSPA.jsp?requestid=1908315&fromModul=workplan&modulResourceId=12345条件: 流程关联了日程/会议，且用户有共享权限校验逻辑: WorkPlanShareUtil.chkWFInWP() 或 MeetingShareUtil.chkWFInMT()前置条件: 流程被关联到某个日程或会议，且用户对该日程/会议有共享权限参数: 2个fromModul=workplan 或 fromModul=meetingmodulResourceId={日程/会议ID}12. 流程分享权限（3个参数）// RequestAuthenticationService if (isfromchatshare == 1 && getRequestShareRight(info, requestid)) { return true; }URL: ViewRequestForwardSPA.jsp?requestid=1908315&isfromchatshare=1&sharer=2094&sharegroupid=xxx条件: 通过IM分享的流程链接校验逻辑: ChatResourceShareManager.authority()前置条件: 流程通过IM分享给当前用户参数: 3个isfromchatshare=1sharer={分享人ID}sharegroupid={分享组ID}13. 协作权限（2个参数）// RequestAuthenticationService if (iscowork == 1 && getRequestCoworkRight(info, requestid)) { return true; }URL: ViewRequestForwardSPA.jsp?requestid=1908315&iscowork=1&coworkid=12345条件: 流程关联了协作区校验逻辑: CoworkCommonUtils.getWfRightByCowork()前置条件: 流程关联到协作区，且用户在协作区成员中参数: 2个iscowork=1coworkid={协作区ID}14. 报表权限（2个参数）// RequestAuthenticationService if (("1".equals(isfromreport) || "2".equals(isfromreport) || "1".equals(isfromflowreport)) && getReportRequestRight(info, requestid)) { return true; }URL: ViewRequestForwardSPA.jsp?requestid=1908315&isfromreport=1&reportid=xxx条件: 从报表入口查看，且有报表权限校验逻辑: ReportAuthorization.checkReportPrivilegesByRequest()前置条件: 用户有对应报表的查看权限参数: 2个isfromreport=1（或2、isfromflowreport=1）reportid={报表ID}最短路径总结排名方式URL参数个数前置条件1共享权限0用户已被共享该流程2操作者权限0用户是流程操作人3创建者权限0用户是流程创建人4监控/督办/干预1用户已被配置为监控/督办/干预人5相关交流1流程有相关交流记录6主子流程1流程之间存在主子关系7建模关联授权4建模数据字段值包含目标requestid8相关流程2-3A/B流程有共同操作人 + 表单字段值匹配E9签名令牌机制（authStr / authSignatureStr）原理E9使用签名令牌替代明文 desrequestid，防止URL参数被篡改。authStr: Base64编码的权限属性字符串，包含 viewChain（查看链）、mainid（入口流程ID）等authSignatureStr: 对authStr的签名，基于用户ID和User-Agent生成工作流程用户从流程A点击链接跳转到流程B系统生成 authStr（包含 viewChain=A的requestid）和签名跳转到B时，RequestAuthenticationService.verify() 验证签名验证通过后，检查用户对A的权限，再检查A→B的关联关系全部通过则授予B的查看权限代码位置签名生成: RequestAuthenticationService签名验证: RequestAuthenticationService查看链机制: RequestAuthenticationService底层SQL查询详情Path 1: 共享权限 → getRequestWfShareRight()调用链: getRequestWfShareRight() → WFShareAuthorization.getWorkflowShareJurisdiction()SQL 1 — 查询共享范围记录:SELECT permissiontype, departmentid, deptlevel, deptlevelMax, roleid, rolelevel, roleseclevel, roleseclevelMax, seclevel, seclevelMax, userid, subcompanyid, sublevel, sublevelMax, jobid, joblevel, jobobj, jobobjid FROM Workflow_SharedScope WHERE requestid = '{requestid}'SQL 2 — 校验流程是否开启共享:SELECT wb.isshared FROM workflow_base wb, workflow_requestbase wr WHERE wb.id = wr.workflowid AND wr.requestid = {requestid}判定条件: 存在任一 Workflow_SharedScope 记录匹配当前用户属性（部门/角色/安全级别/分部/岗位/指定人员），且 workflow_base.isshared = '1'。涉及表: Workflow_SharedScope, workflow_base, workflow_requestbasePath 2: 操作者权限 → getRequestUserRight()调用链: getRequestUserRight() → ServiceUtil.calculateCurrentNodeSql()SQL:SELECT isremark, isreminded, preisremark, id, groupdetailid, nodeid, takisremark, takid, workflowid, handleforwardid, agenttype, agentorbyagentid, (CASE WHEN isremark=9 THEN 0.99 WHEN isremark=8 THEN 1.2 WHEN isremark=11 THEN 0.98 WHEN (isremark=1 AND takisremark=2) THEN 0.9 WHEN (preisremark=1 AND isremark=2) THEN 1.9 WHEN (isremark=0 AND takisremark=-2 AND isInMultiTak=1) THEN 2 ELSE isremark END) AS orderisremark FROM workflow_currentoperator WHERE requestid = {requestid} AND userid = {userid} AND usertype = {usertype} ORDER BY orderisremark, id参数: requestid, userid, usertype（0=内部, 1=外部, 2=其他）判定条件: 遍历结果集，若任一行 isremark ∈ {0,1,5,7,8,9,11}（其中 isremark=0 需 nodetype≠3），则 canview=true。涉及表: workflow_currentoperatorPath 3: 创建者权限 → LoadParamCmdSQL（存储过程）:{call workflow_Requestbase_SByID({requestid})}等价于:SELECT * FROM workflow_requestbase WHERE requestid = {requestid}判定条件: creater == userid AND creatertype == usertype涉及表: workflow_requestbasePath 4: 监控权限 → getRequestMonitorRight()调用链: getRequestMonitorRight() → WFUrgerManager.getMonitorViewRight() → Monitor.getMonitorInfo()SQL 1 — 获取请求创建者和流程ID:SELECT creater, workflowid FROM workflow_requestbase WHERE requestid = {requestid}SQL 2 — 检查是否管理员:SELECT 1 FROM hrmresourcemanager WHERE id = {userid}SQL 3 — 获取创建者虚拟组织:SELECT subcompanyid1, departmentid FROM HrmResourceVirtualView WHERE id = {createrId}SQL 4 — 主查询：查找监控配置（SQL Server版本）:SELECT * FROM workflow_monitor_info a WHERE EXISTS ( SELECT 1 FROM ( SELECT 1 jktype, id FROM hrmresource WHERE id = {userid} UNION SELECT 2 jktype, id FROM hrmroles WHERE id IN ({roleids}) UNION SELECT 3 jktype, id FROM hrmresourcemanager WHERE id = {userid} ) t WHERE a.jktype = t.jktype AND ',' + a.jkvalue + ',' LIKE '%,' + CAST(t.id AS VARCHAR) + ',%' ) AND EXISTS ( SELECT 1 FROM workflow_monitor_detail b WHERE a.id = b.infoid AND workflowid IN ({allVersionWfids}) )Oracle: INSTR(','||a.jkvalue||',' , ','||t.id||',') > 0MySQL: CONCAT(',',a.jkvalue,',') LIKE CONCAT('%,',t.id,',%')SQL 5 — 获取监控权限明细:SELECT * FROM workflow_monitor_detail WHERE infoid IN ({infoids}) AND workflowid IN ({allVersionWfids})参数: userid, roleids（用户角色ID列表）, allVersionWfids（流程所有版本ID）判定条件: 用户匹配监控配置（jktype: 1=人员, 2=角色, 3=管理员），fwtype 范围校验通过（1=总部, 2=同分部, 5=同部门, 10=指定人员等），且 workflow_monitor_detail.isview = '1'。涉及表: workflow_requestbase, hrmresourcemanager, HrmResourceVirtualView, hrmresource, hrmroles, workflow_monitor_info, workflow_monitor_detailPath 5: 督办权限 → getRequestUrgerRight()调用链: getRequestUrgerRight() → SuperviseManagerBiz.hasWorkflowViewRight()SQL:SELECT 1 FROM WORKFLOW_SUPERVISEOPERATOR WHERE userid = {userid} AND requestid = {requestid}判定条件: 查询返回至少一行。涉及表: WORKFLOW_SUPERVISEOPERATORPath 6: 干预权限 → getRequestInterventorRight()调用链: getRequestInterventorRight() → SysWFLMonitor.getWFInterventorRightBymonitor() → Monitor.getMonitorInfo()SQL 与 Path 4 基本相同，额外查询:SQL — 获取干预权限:SELECT * FROM workflow_monitor_detail WHERE infoid IN ({infoids}) AND workflowid IN ({allVersionWfids})判定条件: workflow_monitor_detail.isintervenor = '1'（与 Path 4 的 isview 不同）涉及表: 同 Path 4，额外关注 workflow_monitor_detail.isintervenor 字段Path 7: 相关交流权限 → getRequestCommunicationRight()调用链: getRequestCommunicationRight() → WorkflowCommunicationBiz.hasWfResourceRight()SQL 1 — 查询交流内容中关联的流程:SELECT relatedwf FROM workflow_communicationcontent WHERE communicationid = {communicationId}SQL 2 — 查询交流回复中关联的流程:SELECT relatedwf FROM workflow_communicationreply WHERE contentid IN ( SELECT id FROM workflow_communicationcontent WHERE communicationid = {communicationId} )判定条件: 收集所有 relatedwf 值，判断 {requestid} 是否在其中。涉及表: workflow_communicationcontent, workflow_communicationreplyPath 8: 主子流程权限 → getRequestSubMainRight()场景一: isrequest=2（验证主流程）SQL 1:SELECT sub.mainrequestid FROM workflow_subwfrequest sub LEFT OUTER JOIN workflow_requestbase req ON req.requestid = sub.mainrequestid WHERE sub.subrequestid = '{requestid}'SQL 2（回退）:SELECT mainrequestid FROM workflow_requestbase WHERE requestid = '{requestid}'场景二: isrequest=3（验证子流程）SQL 3:SELECT sub.mainrequestid requestid FROM workflow_subwfrequest sub LEFT OUTER JOIN workflow_requestbase req ON req.requestid = sub.subrequestid WHERE sub.subrequestid = '{mainRequestid}'场景三: isrequest=4（验证平行流程）SQL 4:SELECT sub.subwfid, sub.isSame, sub.mainrequestid, req.requestname FROM workflow_subwfrequest sub LEFT JOIN workflow_requestbase req ON req.requestid = sub.mainrequestid WHERE sub.subrequestid = {requestid}SQL 5:SELECT sub.subrequestid requestid, req.requestname FROM workflow_subwfrequest sub LEFT JOIN workflow_requestbase req ON req.requestid = sub.subrequestid WHERE sub.mainrequestid = {mainrequestid} AND sub.subwfid = {subWfSetId} AND sub.subrequestid <> {requestid}判定条件: 查询结果中 requestid 与目标 requestid 匹配。涉及表: workflow_subwfrequest, workflow_requestbasePath 9: 建模关联授权 → getModeRight()调用链: getModeRight() → ModeRightInfo.isFormModeAuthorize()SQL 1 — 查询建模权限规则:SELECT righttype, orgrelation, sharetype, relatedid, rolelevel, showlevel, joblevel, jobleveltext, hrmCompanyVirtualType, layoutid, layoutid1, layoutorder FROM moderightinfo WHERE modeid = {modeId} AND ((sharetype IN (1,2,3,5,6) AND (conditionsql IS NULL OR conditionsql = '')) OR (sharetype = '4' AND isrolelimited <> '1' AND (conditionsql IS NULL OR conditionsql = ''))) AND righttype IN (1,2,3) AND (showlevel <= {seclevel} AND {seclevel} <= ISNULL(showlevel2, 9999))SQL 2 — 查询共享明细表（动态表名）:SELECT sourceid, MAX(sharelevel) sharelevel FROM modeDataShare_{modeId} WHERE sourceid = {formmodebillId} AND ( (type=1 AND content={userid}) OR (type=2 AND content={subcompanyid} AND seclevel<={seclevel} AND {seclevel}<=ISNULL(showlevel2,9999)) OR (type=3 AND content={departmentid} AND seclevel<={seclevel} AND {seclevel}<=ISNULL(showlevel2,9999)) OR (type=4 AND content IN ({roleIds}) AND seclevel<={seclevel}) OR (type=5 AND content=1 AND seclevel<={seclevel}) OR (type=6 AND content={jobtitle} AND seclevel<={seclevel}) OR (type=7 AND content={userid}) ) GROUP BY sourceidSQL 3 — 查询字段授权配置:SELECT a.*, b.fieldname, b.fielddbtype, b.fieldhtmltype, b.type, b.detailtable FROM ModeFieldAuthorize a, workflow_billfield b WHERE a.fieldid = b.id AND b.billid = {formId} AND a.modeid = {modeId} AND a.formid = {formId} AND a.fieldid = {fieldid}SQL 4 — 读取建模数据字段值（主表）:SELECT {fieldname} FROM {maintablename} WHERE id = {formmodebillId}SQL 5 — 读取建模数据字段值（明细表）:SELECT {fieldname} FROM {detailtable} WHERE mainid = {formmodebillId}判定条件:用户对建模模块有查看权限（moderightinfo 或 modeDataShare_{modeId} 匹配）ModeFieldAuthorize 表中存在该字段的关联授权配置建模数据字段值中包含 {requestid}（格式: fieldValue.indexOf("," + requestid + ",") > -1）涉及表: moderightinfo, modeDataShare_{modeId}（动态）, ModeFieldAuthorize, workflow_billfield, {maintablename}（动态）, {detailtable}（动态）Path 10: 相关流程权限 → getrelateRequestRight()SQL 1 — 获取主流程 workflowid:SELECT workflowid FROM workflow_requestbase WHERE requestid = {requestid}SQL 2 — 防篡改校验（操作人交集）:SELECT userid, usertype FROM workflow_currentoperator WHERE requestid = {mainRequestid} SELECT userid, usertype FROM workflow_currentoperator WHERE requestid = {requestid} -- Java层取交集 retainAll()，交集为空则拒绝SQL 3 — 签字意见关联校验（isfromresource=1 或 fieldid=0 时）:-- Oracle/PostgreSQL: SELECT 1 FROM workflow_requestlog WHERE requestid = {mainRequestid} AND ','||signworkflowids||',' LIKE '%,{requestid},%' -- MySQL: SELECT 1 FROM workflow_requestlog WHERE requestid = {mainRequestid} AND CONCAT(',',signworkflowids,',') LIKE '%,{requestid},%' -- SQL Server: SELECT 1 FROM workflow_requestlog WHERE requestid = {mainRequestid} AND ','+signworkflowids+',' LIKE '%,{requestid},%'SQL 4 — 获取字段定义（isbill=1）:SELECT billid, fieldname, viewtype, detailtable FROM workflow_billfield WHERE id = {fieldid} SELECT tablename FROM workflow_bill WHERE id = {billid}SQL 5 — 获取字段值:-- 主表 (viewtype=0): SELECT {fieldname} FROM {tablename} WHERE requestid = {mainRequestid} -- 明细表 (viewtype>0): SELECT {fieldname} FROM {detailtable} WHERE mainid IN (SELECT id FROM {tablename} WHERE requestid = {mainRequestid})判定条件:A/B流程操作人有交集（防篡改）签字意见 signworkflowids 包含目标 requestid，或表单字段值包含目标 requestid涉及表: workflow_requestbase, workflow_currentoperator, workflow_requestlog, workflow_billfield, workflow_bill, {tablename}（动态）, {detailtable}（动态）Path 11: 计划会议权限 → getPlanMeetingRight()子路径A: WorkPlanSQL 1 — 检查日程是否关联流程:SELECT * FROM workplan WHERE id = {workId} AND (requestid = '{requestId}' OR requestid LIKE '{requestId},%' OR requestid LIKE '%,{requestId},%' OR requestid LIKE '%,{requestId}')SQL 2 — 检查日程交流是否关联流程:SELECT * FROM Exchange_Info WHERE type_n = 'WP' AND sortid = {workId} AND (requestids LIKE '%,{requestId},%' OR relatedwf LIKE '%,{requestId},%')SQL 3 — 获取日程共享级别:SELECT workId, MAX(shareLevel) AS shareLevel FROM WorkPlanShareDetail WHERE workid = {workplanId} AND ( (objId={userId} AND shareType='1') OR (objId=0 AND shareType='5' AND securityLevel<={seclevel} AND securityLevelMax>={seclevel}) OR (objId IN ({compid}) AND shareType='2' AND securityLevel<={seclevel}) OR (objId IN ({deptid}) AND shareType='3' AND securityLevel<={seclevel}) OR (objId={jobid} AND shareType='8') OR (objId={roleid} AND shareType='4' AND securityLevel<={seclevel} AND {roleLevel}>=rolelevel) ) GROUP BY workId子路径B: MeetingSQL 4 — 检查会议是否关联流程:SELECT * FROM meeting WHERE id = {meetingId} AND ({fieldname} LIKE '%,{requestId},%' OR requestid = '{requestId}')SQL 5 — 检查会议共享:SELECT * FROM Meeting_ShareDetail WHERE meetingid = {meetingid} AND userid IN ({allUser}) AND sharelevel IN (1,2,4,5)SQL 6 — 检查会议成员:SELECT * FROM Meeting_Member2 WHERE meetingid = {meetingid} AND (membermanager IN ({allUser}) OR ','||othermember||',' LIKE '%,{userId},%')判定条件: 流程关联了日程/会议，且 getShareLevel > -1。涉及表: workplan, Exchange_Info, WorkPlanShareDetail, meeting, Meeting_ShareDetail, Meeting_Member2, Meeting_Topic, Meeting_DecisionPath 12: 流程分享权限 → getRequestShareRight()调用链: getRequestShareRight() → ChatResourceShareManager.authority()SQL 1 — 验证分享人为流程操作者:SELECT userid, usertype FROM workflow_currentoperator WHERE requestid = {resourceid} AND userid = {sharer} AND usertype = {sharertype}SQL 2 — 检查当前用户是否在分享范围内:SELECT 1 FROM mobile_ChatResourceShareScope a INNER JOIN mobile_chatresourceshare b ON a.shareid = b.id WHERE b.resourcetype = 0 AND b.resourceid = {requestid} AND b.sharer = {sharer} AND a.resoueceid = {currentUserid} AND a.resouecetype = 0判定条件: 分享人是流程操作者，且当前用户在分享范围内。涉及表: workflow_currentoperator, mobile_chatresourceshare, mobile_ChatResourceShareScopePath 13: 协作权限 → getRequestCoworkRight()调用链: getRequestCoworkRight() → CoworkCommonUtils.getWfRightByCowork()SQL 1 — 检查协作审批状态:SELECT approvalatatus FROM cowork_items WHERE id = {coworkId}SQL 2 — 获取协作参与者:SELECT * FROM coworkshare WHERE sourceid = {coworkId} ORDER BY srcfrom DESC, type ASCSQL 3 — 获取退出协作者:SELECT userid FROM cowork_quiter WHERE itemid = {coworkId}SQL 4 — 检查协作主项关联流程（Oracle版本）:SELECT relatedwf FROM cowork_items WHERE id = {coworkId} AND relatedwf IS NOT NULL AND ','||relatedwf||',' LIKE '%,{requestid},%'SQL 5 — 检查协作讨论关联流程:SELECT relatedwf FROM cowork_discuss WHERE coworkid = {coworkId} AND (isdel <> 1 OR isdel IS NULL) AND ','||relatedwf||',' LIKE '%,{requestid},%'判定条件: 用户是协作参与者/管理者，且协作主项或讨论中关联了目标流程。涉及表: cowork_items, coworkshare, cotype_sharemanager, cowork_deftypeshare, cowork_quiter, cowork_discussPath 14: 报表权限 → getReportRequestRight()子路径A: 自定义报表 (isfromreport=1)SQL 1 — 验证报表共享权限:SELECT shareType, userid, departmentid, subcompanyid, roleid, rolelevel, allowlook, sharelevel, mutidepartmentid, seclevel, seclevel2 FROM WorkflowReportShare WHERE reportid = {reportid}SQL 2 — 获取报表关联的流程:SELECT reportwfid FROM Workflow_Report WHERE id = {reportid}SQL 3 — 获取当前请求的流程ID:SELECT workflowid FROM workflow_requestbase WHERE requestid = '{requestid}'判定条件: 用户有报表查看权限（allowlook='1'），且当前请求的 workflowid 在报表的 reportwfid 列表中。子路径B: 新版报表 (isfromreport=2)SQL 4 — 获取表单信息:SELECT formid, isbill FROM workflow_base a LEFT JOIN workflow_requestbase b ON a.id = b.workflowid WHERE b.requestid = {requestid}SQL 5 — 获取报表数据权限配置:SELECT type, objid, allowsub, minlevel, maxlevel, rolelevel, joblevel, joblevelobjid, competencelevel, competenceobjid, dimension, dimensionval, allowlook FROM workflow_report_competence WHERE formid = {formid} AND isbill = {isbill} AND allowlook = '1'判定条件: 按 type 匹配用户（1=人员, 2=部门, 3=分部, 4=角色, 5=所有人, 6=岗位），安全级别在范围内。涉及表: WorkflowReportShare, Workflow_Report, workflow_requestbase, workflow_base, workflow_report_competence, HrmresourceVirtual涉及的核心数据库表汇总表名用途涉及路径workflow_requestbase流程请求基础表1,3,4,6,8,10,14workflow_currentoperator流程当前操作者表2,10,12workflow_base流程定义表1,14Workflow_SharedScope流程共享范围表1workflow_monitor_info流程监控配置表4,6workflow_monitor_detail流程监控权限明细表4,6WORKFLOW_SUPERVISEOPERATOR督办操作者表5workflow_subwfrequest主子流程关系表8workflow_requestlog流程操作日志表10workflow_billfield表单字段定义表9,10workflow_bill表单定义表10moderightinfo建模权限规则表9modeDataShare_{modeId}建模数据共享表（动态）9ModeFieldAuthorize字段授权配置表9workflow_communicationcontent流程交流内容表7workflow_communicationreply流程交流回复表7workplan日程表11WorkPlanShareDetail日程共享明细表11meeting会议表11Meeting_ShareDetail会议共享明细表11mobile_chatresourceshareIM分享记录表12mobile_ChatResourceShareScopeIM分享范围表12cowork_items协作主项表13coworkshare协作共享表13cowork_discuss协作讨论表13WorkflowReportShare报表共享权限表14Workflow_Report报表定义表14workflow_report_competence报表数据权限表14hrmresource人力资源表4,6hrmroles角色表4,6hrmresourcemanager系统管理员表4,6HrmResourceVirtualView虚拟组织视图4,6注意事项SPA vs JSP路由差异: authStr 仅在SPA路由中用于权限校验，JSP路由使用Session机制防篡改校验: 相关流程权限会校验A/B流程是否有共同操作人，无交集则拒绝字段值校验: 建模关联授权和相关流程权限都会校验表单字段值是否包含目标requestid无条件检查: 共享权限和操作者权限是无条件检查的，不需要任何URL参数动态表名: 建模共享表 modeDataShare_{modeId} 和业务表 {tablename} 是动态生成的数据库差异: 部分SQL因数据库类型（Oracle/MySQL/SQL Server/PostgreSQL）而有不同写法，主要是字符串拼接方式的差异
[泛微 Ecology10] E10使用ESB动作流&连接器使用doCreateRequest创建流程接口
写在前面 本方案仅出于丸子当时自己的即时想法，并非官方最佳实践方案。仅供技术交流参考，如你有更优雅的实现方式，欢迎随时交流！ E10 多租户互通方案中，通过 E10 开放平台连接器，可以实现当前组织与 E10 其他组织的数据互通。本文将重点介绍如何使用 ESB 动作流配合 doCreateRequest 接口实现跨组织的流程创建。1. 准备阶段在开始配置前，请确保已查阅官方开发文档。 接口基础信息 接口地址：http://url:port/papi/openapi/api/workflow/core/paService/v1/doCreateRequesthttp://url:port/papi/openapi/api/workflow/core/paService/v2/doCreateRequest前置要求： 参照 "后台管理中心" -> "开放平台" -> "接口示例"，完成应用的创建与鉴权配置。 ESB 连接器配置进入 "ESB 中心" -> "内置" -> "E10 开放平台" 。新建“连接”以及“接口”（注：系统默认并未内置新建流程接口，需要自行创建）。创建字段映射表准备好源流程（触发源）与目标流程（被写入目标）为了保证后续代码的通用性与可维护性，强烈建议维护一张映射表。2. ESB 动作流构建整个动作流的核心逻辑主要由“流程触发”与“自定义逻辑计算”组成。流程逻辑图核心自定义函数在此处使用 解析JSON/XML文本 节点，配置自定义函数 buildMappingResult：JavaScriptfunction buildMappingResult(flowDataStr, mappingStr, sourceKeyCol, targetKeyCol, specialTypeCol) { var flowData = JSON.parse(flowDataStr); var mapping = JSON.parse(mappingStr); var result = []; for (var i = 0; i < mapping.length; i++) { var mapItem = mapping[i]; var sourceId = mapItem[sourceKeyCol]; var targetId = mapItem[targetKeyCol]; var specialType = mapItem[specialTypeCol]; if (!sourceId || !targetId) continue; // 逻辑处理 if (flowData[sourceId] !== undefined) { var mainRow = { "targetId": targetId, "targetValue": flowData[sourceId] }; if (specialType !== undefined) mainRow["specialType"] = specialType; result.push(mainRow); } else { // 明细表处理 for (var key in flowData) { if (flowData.hasOwnProperty(key)) { var fieldData = flowData[key]; if (Object.prototype.toString.call(fieldData) === '[object Array]') { for (var j = 0; j < fieldData.length; j++) { var detailItem = fieldData[j]; if (Object.prototype.toString.call(detailItem) === '[object Object]' && detailItem[sourceId] !== undefined) { var detailRow = { "targetId": targetId, "targetValue": detailItem[sourceId] }; if (specialType !== undefined) detailRow["specialType"] = specialType; if (detailItem["dataIndex"] !== undefined) detailRow["dataIndex"] = detailItem["dataIndex"]; result.push(detailRow); } } } } } } } return JSON.stringify(result); }3. 创建流程实例：核心参数解析在“创建流程实例”节点中，传参的配置是重中之重。 关键点提示 fieldId 使用原则： 如果是明细字段 ID，仅需传 dataIndex，无需传 subFormId。文件上传： 使用 uploadType: loadUrl，配合 GENERATEFILEDOWNURL 函数转换下载链接。附件权限： 若涉及附件字段，needCopy 参数务必设置为 true。 formData 传参对照表字段逻辑说明dataDetails放置【解析 JSON/XML 文本】的数据解析结果fieldId依据值 (dataDetails)：targetIddataIndex依据值 (dataDetails)：dataIndexcontent依据值 (dataDetails)：targetValuedataOptions特殊类型字段赋值：IF(NOTEMPTY(specialType), targetValue, null)optionId多选下拉框：IF((specialType=1), dataOptions依据值本身, null)接口报文结构参考 点击查看 JSON 结构模板 JSON{ "access_token": "", "workflowId": "", "isnextflow": "", "dataDetails": [ { "fieldId": "", "dataKey": "", "dataIndex": "", "content": "", "subFormId": "", "matchByName": "", "dataOptions": [ { "optionId": "", "fileByte": "", "content": "", "uploadParam": { "uploadType": "", "base64Url": "", "loadUrl": "" } } ], "needCopy": "" } ], "formData": {}, "userid": "" } 如果有更好的方案，欢迎评论区留言
一、事件背景近期在测试 OA 创建流程接口（/api/workflow/paService/doCreateRequest）时，遇到一个比较隐蔽的问题：业务侧传入的附件内容采用 base64 方式提交，接口返回 PARAM_ERROR，错误信息指向“生成附件失败”。表面上看，这类问题通常会先怀疑以下几种方向：图片文件本身损坏base64 转换过程出错请求体过长导致截断OA 附件服务解析失败但这次问题的特殊之处在于：同一张图片在本地可以正常解码base64 长度、补位、MD5 都正常错误并不是稳定出现在所有图片上，而是只出现在部分附件内容上这意味着问题不太像“通用性格式错误”，更像“特定内容触发了某种中间处理逻辑”。二、问题现象业务调用 OA 创建流程接口时，附件字段通过 base64: 前缀方式上传，接口返回类似错误：{ "code": "PARAM_ERROR", "errMsg": { "field_xxx": "生成附件失败,参数为：fieldid:xxxx,annexId:-3,fileValue:[...]" } }从附件服务语义上看，annexId:-3 的含义基本可以理解为：附件内容在进入保存逻辑后，Base64 解码失败。但关键问题是，业务侧原始 base64 在本地验证完全正常。三、第一次排查：先排除“文件坏了”第一步做的是最基础的校验：提取原始请求中的 base64校验长度是否为 4 的倍数检查是否只包含合法 Base64 字符本地执行解码对解码后的文件做 MD5 校验结果很明确：原始 base64 串合法本地可以成功解码解码后的图片与原始附件 MD5 一致也就是说，问题不在业务系统生成附件这一步。四、第二次排查：不是所有 Base64 都失败为了避免被“单个样本”误导，我们做了几组对照实验。1. 安全样例传一个很短、内容简单的 base64，结果成功。2. 含特定片段的样例构造一些很短但包含特定文本片段的 base64，例如：4or+4and+4union+4select+结果发现，这类请求会稳定失败。更关键的是，OA 返回报文中回显出来的附件内容，已经不是原始值，而是被改写成了全角字符，例如：4or+ 变成 4ｏｒ+4and+ 变成 4ａｎｄ+一旦 base64 内部出现全角字符，后续解码必然失败。这一步已经把问题从“附件坏了”收缩到“请求进入 OA 后被改写了”。五、第三次排查：到底是什么条件会触发改写如果只是“出现 or 就失败”，那很多正常图片都应该大量失败，但事实并不是这样。于是我们继续做边界实验，只改变命中关键词左右两边的字符。实验样例如下：会失败：4or+会成功：Aor+会成功：4orA会成功：AorA同样地：会失败：4and+会成功：AandA这说明触发条件不是“只要包含 or / and 就拦截”，而是更接近：当某些敏感关键词左右两边都不是字母时，会被安全规则命中。这类模式与常见 SQL 注入拦截规则高度一致。六、第四次排查：回到真实失败图片做验证为了避免“小样本实验不代表真实图片”的质疑，我们又对真实失败图片做了反向验证。结论如下：原始图片 Base64 上传失败回显内容中，只有其中一处 or 被改写为 ｏｒ这处命中的上下文正好是 4or+然后我们只做一个极小改动，不改整张图片，只改这一处附近的边界字符：原始：4or+ -> 请求失败改成：Aor+ -> 请求成功改成：4orA -> 请求成功这一步的意义非常大，因为它证明：不是图片太大导致失败不是图片整体内容有问题不是 Base64 长度问题不是附件服务偶发异常而是图片 Base64 中某个刚好命中安全规则的片段，触发了请求内容改写。七、最终结论这次事件的根因可以明确归纳为：OA 在接收 application/x-www-form-urlencoded 请求参数时，安全过滤链会对命中的敏感关键词进行全角替换；当附件 base64 恰好包含类似 or、and、union、select 等关键词，并且其左右边界满足规则时，原始 base64 会被污染，最终导致附件解码失败。换句话说：业务系统生成的附件 Base64 没问题图片本身没问题问题发生在 OA 接收请求后的安全处理阶段这是一个典型的“安全规则误杀二进制文本内容”问题。八、为什么这个问题隐蔽这个问题很难第一时间定位，原因有三个：1. 现象看起来像附件服务失败接口只返回“生成附件失败”，很容易让人先怀疑附件服务或图片本身。2. 不是所有附件都失败只有当 Base64 内部恰好出现特定关键词组合时才触发，因此问题呈现出明显的“偶发性”。3. 原始请求侧看不到污染业务侧生成的 Base64 完全正常，真正的问题发生在请求进入 OA 后的处理中间层。九、排查经验总结这次事件里，最有效的不是一开始盯着大日志翻，而是做了几轮最小化实验：先验证原始 Base64 是否真的合法再用短样本确认问题是否与特定内容有关再通过边界变体判断触发规则最后回到真实图片做反向验证这套方法的价值在于：能快速排除“文件坏了”这类低价值方向能把问题从“偶发失败”收敛成“稳定可复现”能把结论从“怀疑安全拦截”推进到“确认是关键词边界命中”十、后续建议如果后续要彻底解决，建议从以下几个方向评估：1. 调整 OA 对附件类字段的安全过滤策略对于明确承载 base64 附件内容的字段，应考虑：增加字段级白名单增加接口级豁免在安全过滤前识别并跳过合法 Base64 内容2. 优化附件上传方式如果接口支持，优先考虑：先上传附件，再传附件 ID使用 multipart/form-data避免把大段二进制文本直接放进普通表单字段3. 建立关键故障样本库像这次命中的 4or+、4and+ 这种片段，建议沉淀成回归样本，避免后续升级或策略调整时再次踩坑。十一、结语这次故障表面上是“附件 Base64 失败”，本质上却是“安全规则误杀了 Base64 文本内容”。它提醒我们一件事：当接口处理的不是普通业务文本，而是承载二进制内容的编码字符串时，安全策略如果仍按普通文本规则处理，就很容易把合法数据当成攻击特征误拦。很多“看起来像解析失败”的问题，最后都不是解析器本身有问题，而是数据在到达解析器之前，已经被别的环节悄悄改写了。问题解决，解决方案如下（2026年6月9日11:30）：问题： OA 流程接口 Base64 附件被安全规则误改写，附件生成失败解决方案： 将附件weaver_security_custom_rules_skip_for_workflow_base64.xml放到/ecology/WEB-INF/securityXML/下，用sysadmin登录，访问下oa地址+/updateRules.jsp访问成功之后显示complete之后可以关闭此页面,然后等三分钟左右测试是否正常。(如果是集群环境，需要复制到每个服务器，然后每个节点都访问下该地址）weaver_security_custom_rules_skip_for_workflow_base64.xml内容如下：<?xml version="1.0" encoding="UTF-8"?> <root> <skip-any-check-list> <url>/api/workflow/paService/doCreateRequest</url> <url>/api/workflow/paService/submitRequest</url> </skip-any-check-list> <need-execute-cls-rule-urls> <url>/api/workflow/paService/doCreateRequest</url> <url>/api/workflow/paService/submitRequest</url> </need-execute-cls-rule-urls> </root>
[泛微EC9] 丸子喂饭篇: restful 新建流程接口详解(/api/workflow/paService/doCreateRequest)
AI 辅助制作标识 该文章由丸子引导 AI 辅助制作生成，如有改进意见，欢迎评论区留言。 引言这个接口可以说是泛微 E9 里用得最多的 REST 接口之一了——新建流程实例。不管是做系统集成、数据迁移、还是定时任务自动发起流程，都绕不开它。但官方文档嘛……懂的都懂，参数一堆，示例不够，踩坑不少。今天丸子就把这个接口掰开了揉碎了讲一遍，争取让你看完就能用。一眼看明白：直接上 curl 如果你对泛微接口已经有一定了解，直接看这段就够了。当然，下面有详细解释，需要的话可以继续往下翻~。curl -X POST 'https://your-oa-domain.com/api/workflow/paService/doCreateRequest' \ -H 'Content-Type: application/x-www-form-urlencoded' \ -H 'token: your_token_here' \ -H 'appid: your_appid_here' \ -H 'userid: your_encrypted_userid_here' \ -d 'workflowId=388024' \ -d 'requestName=测试流程标题' \ -d 'remark=测试意见' \ -d 'requestLevel=2' \ -d 'mainData=[{"fieldName":"cswb","fieldValue":"2978"}]' \ -d 'detailData=[{"tableDBName":"formtable_main_1356_dt1","workflowRequestTableRecords":[{"recordOrder":0,"workflowRequestTableFields":[{"fieldName":"dhwb","fieldValue":"第一行"},{"fieldName":"drl","fieldValue":"2978"}]}]}]' \ -d 'otherParams={"isnextflow":0,"delReqFlowFaild":0}'返回成功示例：{ "code": "SUCCESS", "data": { "requestid": 1699718 }, "errMsg": {}, "reqFailMsg": { "keyParameters": {}, "msgInfo": {}, "otherParams": {} } }拿到 requestid 就说明流程创建成功了，这个 ID 就是流程实例的唯一标识。小白专区：一步一步来如果上面的 curl 你看得一头雾水，别慌，丸子下面一个一个讲。第一步：这个接口是干嘛的？简单说：通过代码自动新建一条泛微流程。平时你在 OA 系统里点"新建流程"，选流程、填表单、点提交——这个接口就是把这个过程用 HTTP 请求来完成。第二步：请求地址和方式POST https://你的 OA 地址/api/workflow/paService/doCreateRequest请求方式：POST（不是 GET！）Content-Type：必须是 application/x-www-form-urlencoded（不是 JSON！） 这里是个常见坑。很多人习惯用 JSON 格式发请求，但这个接口要求的是表单格式。第三步：请求头（Header）参数参数名说明怎么获取token调用凭证通过泛微许可接口获取appid许可证号码泛微后台配置userid加密后的用户 ID用 spk 公钥加密 userid 得到Content-Type内容类型固定填 application/x-www-form-urlencoded这三个参数（token、appid、userid）是泛微 REST 接口的"通行证"，没有它们接口直接拒绝。第四步：请求体（Body）参数详解这是重点，一共就这几个参数：workflowId（必填）—— 流程 ID-d 'workflowId=388024'这个数字是你要新建的流程模板 ID。怎么找？在 OA 系统里打开流程设计器，URL 里一般就有，或者查数据库 workflow_base 表。requestName（必填）—— 流程标题-d 'requestName=测试流程标题'就是流程发起后显示的标题，随便填。mainData（必填）—— 主表数据这个稍微复杂点，它是一个 JSON 数组，每个元素代表一个字段：[ { "fieldName": "cswb", "fieldValue": "2978" }, { "fieldName": "csfjsc", "fieldValue": [ { "fileName": "通用测试模板.xls", "filePath": "base64:AAA..." }, { "fileName": "通用测试 pdf.pdf", "filePath": "https://example.com/sample.pdf" } ] } ]fieldName：字段的数据库名称（不是显示名称！）。去表单设计器里看，或者查 workflow_formfield 表。fieldValue：字段值。普通字段直接填字符串，附件字段比较特殊，需要传数组，每个附件包含 fileName（文件名带后缀）和 filePath（base64 编码或 URL）。 怎么找字段的数据库名称？进入表单设计器 → 点击字段 → 查看属性 → 有个"数据库字段名"就是了。detailData（可选）—— 明细表数据如果你的流程有明细表，就用这个参数：[ { "tableDBName": "formtable_main_1356_dt1", "workflowRequestTableRecords": [ { "recordOrder": 0, "workflowRequestTableFields": [ { "fieldName": "dhwb", "fieldValue": "第一行" }, { "fieldName": "drl", "fieldValue": "2978" } ] }, { "recordOrder": 0, "workflowRequestTableFields": [ { "fieldName": "dhwb", "fieldValue": "第 2 行" }, { "fieldName": "drl", "fieldValue": "2978" } ] } ] } ]tableDBName：明细表的数据库名，格式一般是 formtable_main_xxx_dt1。workflowRequestTableRecords：每一行明细数据。recordOrder：行序号，从 0 开始。workflowRequestTableFields：和主表一样，fieldName + fieldValue。 多个明细表怎么办？ 在数组里加另一个 tableDBName 的对象就行。remark（可选）—— 签字意见-d 'remark=测试意见'流程发起时的签字意见，不填就用流程默认的。requestLevel（可选）—— 紧急程度-d 'requestLevel=2'数字越大越紧急，具体取值看你们流程的配置。otherParams（可选）—— 扩展参数-d 'otherParams={"isnextflow":0,"delReqFlowFaild":0}'这是一个 JSON 对象，支持以下参数：参数名说明可选值isnextflow新建后是否自动流转到下一节点0：不流转，1：流转（默认）delReqFlowFaild新建失败是否自动删除流程0：不删除，1：删除（默认）isVerifyPer是否验证用户创建权限0：不验证，1：验证（默认）requestSecLevel流程密级需开启密级功能才生效 isnextflow=0 什么意思？ 就是流程创建后停留在第一个节点，不自动往下走。有时候你还需要在第一个节点做点操作，就可以设成 0。第五步：返回值怎么判断？{ "code": "SUCCESS", "data": { "requestid": 1699718 } }code 为 SUCCESS → 成功，data.requestid 就是新建的流程 ID。code 为 PARAM_ERROR → 参数有错，看 errMsg 里的具体提示，当然，一般没有，慢慢调吧~code 为 NO_PERMISSION → 没有权限，检查 workflowId 对应的流程是否允许当前用户创建。code 为 SYSTEM_INNER_ERROR → 服务端异常，看 OA 日志。常见错误排查错误现象可能原因workflowId 返回 -1mainData 格式不对，多了 } 或 ]mainData: 新建流程主表数据不允许为空mainData 没传或者为空error_param_xxx: '值'某个字段名写错了，或者值不合法返回 NO_PERMISSION当前用户没有该流程的创建权限返回 PARAM_ERROR 但 errMsg 为空检查 Content-Type 是不是 application/x-www-form-urlencoded小结这个接口其实不难，核心就三个东西：请求头：token、appid、userid（泛微接口三件套）主表数据：mainData，字段名一定要和表单里的数据库字段名一致明细表数据：detailData，结构比主表多一层"表名"和"行记录"记住一个原则：字段名写错 = 报错，格式不对 = 报错，权限没有 = 报错。好了，丸子喂饭完毕，希望你能吃饱~有问题欢迎评论区留言~参考资料与致谢泛微官方文档： 泛微E9后端接口说明（https://e-cloudstore.com/ec/api/applist/index.html#/）
同一日期字段为什么会显示两种格式？泛微国际化与 displayFormat 冲突排查实录（Ecology10 v10.0.2512.01）这次踩坑很典型。同一个流程、同一个节点、同一个日期字段，一个请求显示 March 3, 2026，另一个却是 17-02-2026。结论先说：不是数据源问题，是“全局国际化日期”与“字段 displayFormat”在前端渲染链路冲突了。如果你也在做泛微国际化，尤其还叠加了 ecode，这篇基本可以直接对照排查。 你可以直接拿走的结论 前端先按全局规则预格式化日期，再按字段 displayFormat 二次格式化；二次解析对部分值失败后会回退原值，导致同一日期字段出现两种显示格式，甚至月日互换。 环境信息产品基线版本：10.0.2512.01全局设置：范围国际化日期开启 MM-DD-YYYY字段设置：日期字段开启显示格式 MMMM D, YYYY自定义适配：已用 ecode 适配 MMM（英文简写月）对比请求：1240131189385469953，显示 March 3, 20261234471942773547020，显示 17-02-2026问题现象同一个日期字段，显示结果不一致：一条请求是英文月份格式：March 3, 2026另一条请求是数字格式：17-02-2026第一眼很像“后端给了不同格式的数据”。但这次不是。排查过程1) 先看 DOM：是不是同一个组件在渲染两个页面都是同一个 widget：#widget_1083772471125450753值都在 .weapp-form__display-format-view > span说明不是“一个是日期组件、一个是文本组件”的差异。2) 再看 API：字段配置是否漂移核心接口：POST /api/ebuilder/flow/form/core/getFormDataAndLayout?formId=1134626576188694691&dataId=...两条请求里，日期字段配置一致：{ "fieldId": "1083772471125450753", "dataKey": "letter_date", "columnName": "letter_date", "format": "yyyy-MM-dd", "displayFormatConfig": { "formatter": { "type": "date", "setting": { "type": "MMMM D, YYYY" } } } }只有原始值不同：124013... -> content = 2026-03-03123447... -> content = 2026-02-17所以可以排除“数据源不一致”和“字段配置不一致”。3) 最后看 JS：前端到底怎么格式化前端关键链路（weappFormbuilder 运行时模块）：// 简化逻辑 h = formatByConfig(rawValue, config.format) // 先预格式化 y = Convert.parse(h, displayFormat) // 再二次格式化Convert.parseDate 内部是 dayjs(e).format(...)。如果 e 解析失败，就会原样回退 e。 核心冲突点 全局国际化先把值改造成了某种字符串形态，字段 displayFormat 再次解析时并不总是成功。成功了就显示英文月名，失败了就回退原串。 为什么一个能转，另一个不能转？直观看两个值：2026-03-03预处理后是 03-03-2026，前端还能“猜”成有效日期，最后渲染出 March 3, 2026。也就是说：2026-02-17预处理后是 17-02-2026，前端解析失败（17 不能当月份），于是回退成 17-02-2026。这就是“同一日期字段，两种格式”的直接原因。这事不只是显示不统一，还可能显示错误日期模拟结果里还能看到月日互换风险：2026-12-01（12月1日）会被转换为 January 12, 2026（1月12日）这已经不是样式问题，是语义错误。为什么这次 ecode 没兜住针对泛微当前版本的国际化日期转换只能支持MM、DD固定的组合方式，我们用 ecode 适配了MMM、MMMM英文月份格式, ecode 适配本身没问题。问题在于这条链路里，前端在某些值上先“退化成普通字符串输出”，导致后续不再稳定走日期组件的转换路径。所以表现就是：你写了转换，但它没机会生效。 关键点：宿主前端在“国际化 + 字段格式”叠加时，输出路径不稳定。 总结这次问题本质上是格式链路冲突，不是数据源问题。全局国际化、字段 displayFormat、ecode 三者叠加时，10.0.2512.01 这条链路确实有适配缺口。真正的修复方向不是继续补字符串转换，而是统一日期输入语义和格式化入口。一句话收尾：日期问题出现“双重格式化”时，别猜，直接抓 DOM + API + 运行时函数，效率最高。
问题描述在更新到基线 10.0.2512.01 后，出现了角色权限缓存问题：应用或菜单已经给了角色或群组权限人员也已经加入到对应的角色或群组但访问资源时仍然提示："对不起，没有使用权限"原因分析这是由于权限缓存未及时更新导致的。系统虽然已经分配了权限，但缓存中的权限信息没有同步刷新。 彻底解决问题，建议客服及技术协调处理 注意！当前文章中的方案仅是临时处理方案，如果想要彻底解决该问题，需要联系总部客服以及技术协调处理排查处理～（当然，如果是由于二次开发导致的问题，可以尝试调用刷新权限接口，希望本文能给你一些启发） 解决办法直接访问以下 API 接口来刷新权限缓存：/api/app/basicserver/data/permission/cache/sourceIdCache/reloadEmployee?tenantKey=xxxx&employeeId=xxxx参数说明tenantKey：租户 IDemployeeId：权限存在问题的人员 ID示例假设租户 ID 为 txzzkwa3op，问题人员 ID 为 1134278335853099999，则访问：/api/app/basicserver/data/permission/cache/sourceIdCache/reloadEmployee?tenantKey=txzzkwa3op&employeeId=1134278335853099999访问后，该人员的权限缓存会立即刷新，问题即可解决。更新时间：2026-02-12
今天是个值得纪念的日子——我的博客正式进入"AI 辅助创作"时代。发生了什么？简单来说，我给自己配了个 AI 助手（OpenClaw + Claude），现在它可以：帮我写博客文章自动发布到网站支持 Markdown 和各种短代码24/7 随时待命听起来很酷对吧？但别担心，我还是那个丸子。为什么要这么做？ 效率质量乐趣 说实话，写博客最大的障碍不是没东西写，而是懒得动手。有了 AI 助手，我可以：口述想法，它帮我整理成文提供关键点，它帮我扩展细节遇到技术问题，它帮我记录解决过程从想法到发布，时间缩短了 80%。AI 不会累，不会烦，不会"今天不想写"。它可以：保持统一的写作风格自动添加代码高亮和格式化检查错别字和语法问题确保文章结构清晰当然，内容还是我把关。AI 只是工具，不是替代品。最重要的是，这很好玩。看着 AI 理解我的想法，然后用我的风格写出来，这种感觉就像："哇，这就是我想说的，但它说得比我更清楚！"而且，我可以把更多时间花在思考和实践上，而不是纠结怎么措辞。 AI 会取代我吗？不会。AI 是工具，不是作者。它可以帮我：整理思路优化表达提高效率但它不能：替我思考替我踩坑替我积累经验这个博客的灵魂还是我的，AI 只是帮我更好地表达。你会看出区别吗？可能会，也可能不会。AI 辅助的文章会：结构更清晰格式更统一更新更频繁但内容、观点、经验，都是我的。如果你觉得某篇文章"不像我写的"，欢迎留言告诉我。我会调整 AI 的风格，让它更像"丸子"。技术细节既然是技术博客，简单说说实现： 点击展开技术栈 核心组件：OpenClaw：开源的 AI Agent 框架Claude：Anthropic 的 AI 模型Typecho：博客系统XML-RPC：自动发布接口工作流程：我告诉 AI 想写什么AI 生成 Markdown 草稿我审阅并修改AI 自动发布到博客代码：# 简化版发布流程 result = publish_to_typecho( title="文章标题", content="Markdown 内容", category="分类", slug="url-别名" )整个系统跑在我的服务器上，完全自主可控。 未来计划有了 AI 助手，我打算：更新频率提升：从"想起来就写"到"每周至少 2 篇"内容更丰富：不只是技术文章，还有想法、经验、踩坑记录互动更多：AI 可以帮我整理评论、回复问题当然，这些都需要时间验证。写在最后这篇文章本身就是 AI 辅助完成的。我提供了想法和结构，AI 帮我扩展和润色。你觉得怎么样？如果你也在用 AI 辅助创作，或者对这个话题感兴趣，欢迎留言交流！ 彩蛋：这篇文章从构思到发布，总共用了不到 5 分钟。效率拉满！ 相关阅读：OpenClaw 配置 AI 模型：5 分钟搞定 User-Agent 问题OpenClaw 官网：https://openclaw.ai欢迎来到 AI 辅助创作的新时代！
最近在给 OpenClaw 配置自定义 AI 模型时，遇到了一个 403 错误。折腾了一会儿才发现是 User-Agent 的问题。这篇文章记录一下解决过程，希望能帮到遇到同样问题的朋友。问题现象配置好自定义 AI 模型（NEW API）后，测试时一直报错：403 Forbidden - Your request was blocked模型配置看起来没问题，API 端点也能访问，但就是无法正常调用。问题原因原来是代理服务器把 OpenClaw 的请求识别成了爬虫，直接拦截了。很多 AI 模型的代理服务为了防止滥用，会检查请求的 User-Agent。如果 User-Agent 看起来不像正常的 API 客户端，就会被拦截。解决方案给模型配置添加自定义 User-Agent 就行了。方法一：命令行配置（推荐）openclaw config set models.providers.wong.headers '{"User-Agent": "OpenClaw-Agent/1.0 (compatible; Anthropic-API-Client)"}' --json 注意 --json 参数很重要，告诉 OpenClaw 这是 JSON 格式User-Agent 可以自定义，但最好看起来像个正经的 API 客户端 方法二：直接编辑配置文件如果你喜欢手动编辑，也可以直接改配置文件：vim ~/.openclaw/openclaw.json找到对应的 provider，添加 headers 字段：{ "models": { "providers": { "wong": { "endpoint": "https://your-api-url", "apiType": "anthropic-messages", "headers": { "User-Agent": "OpenClaw-Agent/1.0 (compatible; Anthropic-API-Client)" } } } } }重启网关配置修改后，记得重启 OpenClaw 网关：openclaw gateway restart或者直接：kill -HUP $(pgrep openclaw-gateway)验证结果重启后，再测试一下模型调用，应该就正常了。你可以用 OpenClaw 的测试命令：openclaw test model wong/claude-haiku-4-5-20251001或者直接在对话里试试，看看模型是否能正常响应。其他可能遇到的问题1. 配置没生效？确认一下：配置文件格式是否正确（JSON 语法）是否重启了网关检查日志：openclaw gateway logs2. 还是 403？可能需要调整 User-Agent 的内容。试试这些：Mozilla/5.0 (compatible; OpenClaw/1.0) OpenClaw-Client/1.0 Anthropic-API-Client/1.03. 其他错误码？401：API Key 错误429：请求太频繁，被限流了500：服务器问题，等等再试写在最后OpenClaw 的配置系统很灵活，支持给每个 provider 单独设置 headers。这次遇到的 User-Agent 问题只是一个小例子。如果你也在用 OpenClaw 配置自定义模型，遇到类似的问题，不妨试试添加自定义 headers。 小贴士：OpenClaw 的配置文件在 ~/.openclaw/openclaw.json，建议定期备份。 相关链接：OpenClaw 官网：https://openclaw.aiOpenClaw GitHub：https://github.com/openclaw/openclaw文档：https://docs.openclaw.ai有问题欢迎留言交流！
这是一篇由 OpenClaw AI 助手自动发布的测试文章。测试内容支持 Markdown 格式支持 Mirages 短代码 这是一个测试提示框 如果你看到这篇文章，说明自动发布功能已经正常工作了！测试时间：2026-02-12 02:28