PeopleSoft AWE工作流配置核心原理与实战指南

简介：本资源是一份面向PeopleSoft开发工程师与HCM系统实施人员的实战型工作流配置指南，聚焦Approval Workflow Engine（AWE）在费用报销场景中的端到端落地实践。文档以PT8.50+FSCM9.1+Oracle技术栈为基础，完整覆盖用户权限建模、基础对象（Record/Page/Component/Menu）创建、交叉引用表设计、自定义Approval Event Handler编写等核心环节，并附有可直接复用的PeopleCode与SQL代码片段。资源为单文件PDF，共1个，大小1.59MB，内容结构清晰，含详细截图指引与关键配置说明，适合作为AWE入门到进阶的实操手册。目前已有155人学习下载，特别适合需快速掌握HCM审批流定制开发、理解EOAW_CORE框架继承机制及规避常见权限与对象映射问题的中高级开发者。

1. PeopleSoft工作流配置不是“画流程图”，而是用AWE引擎驱动业务规则的实时决策闭环

很多人拿到《PeopleSoft工作流配置[整理].pdf》第一反应是打开Visio拖拽节点——结果卡在“审批人怎么动态算出来”“退回后状态不回滚”“多级会签总漏人”上。这不是流程建模问题，而是PeopleSoft Approval Workflow Engine（AWE）的运行时逻辑没对齐：它不依赖静态路径，而靠EOAW_CORE组件在事务提交瞬间解析规则、调用PeopleCode、触发异步事件。真正卡住80%实施人员的，是搞不清AWE如何把“谁审、何时审、审什么、审完干啥”这四件事编译成可执行的Workflow Definition（WD）、Workflow Step（WS）和Workflow Action（WA）三层对象。本文面向已部署PS HCM或FSCM模块、能登录Application Designer但尚未跑通一条完整审批流的工程师——你不需要重装系统，只需理解AWE的3个核心约束：① 所有步骤必须绑定到特定Component/Record；② 审批人计算必须通过PeopleCode函数返回有效User ID列表；③ 状态变更必须由AWE内置事件（如OnApprove、OnReject）驱动，而非手动Update SQL。接下来，我们从AWE对象建模开始，手把手配置一条采购申请（PO_REQ）的三级审批流。

2. 用AWE Designer构建Workflow Definition：从Component绑定到Step序列定义

AWE的配置起点不是流程图，而是Application Designer里的Workflow Definition对象。它本质是一个元数据容器，声明了“哪个业务单据触发哪套审批逻辑”。必须先确认目标Component已启用AWE支持——以PO_REQ为例，其Component ID为PO_REQ_ENTRY，Record为PO_REQ_HDR。若未启用，需在Component Properties → Use tab → 勾选“Enable Workflow”。

2.1 创建Workflow Definition并绑定业务实体

在Application Designer中新建Workflow Definition，命名为WD_PO_REQ_APPROVAL。关键字段设置如下：

字段名	值	说明
Definition Name	WD_PO_REQ_APPROVAL	必须唯一，后续PeopleCode中通过此名调用
Component ID	PO_REQ_ENTRY	指定触发该工作流的Component，AWE仅在此Component保存/更新时启动
Record Name	PO_REQ_HDR	主表Record，AWE自动提取其KEY字段（如REQ_ID）作为流程实例ID
Status Field	APPROVAL_STATUS	Record中用于存储当前审批状态的字段，类型必须为CHAR(3)，值域需预设PND(待审)、APP(已批)、RJT(拒批)等

提示：Status Field不能是STATUS这类通用字段名，必须是业务专用字段。若PO_REQ_HDR无此字段，需先用Application Designer添加，并在SQL中初始化默认值PND。

2.2 定义Workflow Step序列：用PeopleCode动态计算审批人

Workflow Step是AWE的执行单元，每个Step代表一个审批环节。以三级审批为例：部门经理→财务主管→采购总监。关键点在于：审批人不能硬编码，必须通过PeopleCode函数动态返回User ID数组。在Workflow Definition中新增3个Step：

• Step 1:STEP_DEPT_MANAGER

  • Type:Approval
  • Approver Function:GetDeptManager(%This)
  • Timeout Days:3（超时自动升级）

• Step 2:STEP_FINANCE_HEAD

  • Type:Approval
  • Approver Function:GetFinanceHead(%This)
  • Timeout Days:2

• Step 3:STEP_PROCURE_DIR

  • Type:Approval
  • Approver Function:GetProcureDirector(%This)
  • Timeout Days:5

其中%This是AWE传入的当前Workflow Instance对象，包含REQ_ID等主键值。PeopleCode函数必须返回&approverList = CreateArrayRept("", 0)格式的数组。

2.2.1 编写GetDeptManager函数（关键逻辑）

Function GetDeptManager(&wfInstance As object) Returns array of string Local array of string &approverList; Local string &reqId, &deptId; Local SQL &sql; /* 1. 从Workflow Instance获取REQ_ID */ &reqId = &wfInstance.GetField("REQ_ID").Value; /* 2. 查询PO_REQ_HDR获取DEPTID */ &sql = CreateSQL("SELECT DEPTID FROM PS_PO_REQ_HDR WHERE REQ_ID = :1", &reqId); If &sql.Fetch(&deptId) Then /* 3. 根据部门ID查对应经理的User ID（假设存于DEPT_TBL）*/ &sql = CreateSQL("SELECT MANAGER_ID FROM PS_DEPT_TBL WHERE DEPTID = :1 AND EFFDT = (SELECT MAX(EFFDT) FROM PS_DEPT_TBL WHERE DEPTID = :1 AND EFFDT <= %CurrentDateIn)", &deptId); If &sql.Fetch(&managerId) Then &approverList = CreateArrayRept(&managerId, 1); Else /* 4. 无经理时回退到部门HRBP */ &approverList = CreateArrayRept("HRBP_DEFAULT", 1); End-If; Else &approverList = CreateArrayRept("ADMIN_DEFAULT", 1); End-If; Return &approverList; End-Function;

注意：函数必须放在EOAW_CORE或PO业务包下的PeopleCode库中，且权限需开放给PTAF用户组。若返回空数组，AWE将报错No approvers found for step。

2.3 配置Workflow Action：定义审批动作的业务后果

Workflow Action定义“审批通过后做什么”。在Step 1后添加ActionACT_UPDATE_STATUS_TO_APP：

字段	值	说明
Action Name	ACT_UPDATE_STATUS_TO_APP	动作标识符
Action Type	PeopleCode	调用自定义代码
PeopleCode Function	UpdateReqStatusToApp	函数名，需与Step绑定
Trigger Event	OnApprove	仅当该Step被批准时触发

2.3.1 实现UpdateReqStatusToApp函数（状态同步核心）

Function UpdateReqStatusToApp(&wfInstance As object) Returns boolean Local string &reqId; Local SQL &sql; &reqId = &wfInstance.GetField("REQ_ID").Value; /* 关键：使用AWE内置事务上下文，避免脏读 */ &sql = CreateSQL("UPDATE PS_PO_REQ_HDR SET APPROVAL_STATUS = 'APP', LASTUPDDTTM = %CurrentDateTimeIn WHERE REQ_ID = :1", &reqId); /* 同步更新关联表（如PO_REQ_LINE） */ &sql = CreateSQL("UPDATE PS_PO_REQ_LINE SET APPROVAL_STATUS = 'APP' WHERE REQ_ID = :1", &reqId); /* 触发下游事件（如生成采购订单） */ &wfInstance.FireEvent("PO_REQ_APPROVED", &reqId); Return True; End-Function;

提示：FireEvent发送的事件名需在Event Registry中预注册，否则下游监听器收不到。此处PO_REQ_APPROVED是自定义事件，非AWE内置事件。

3. 在PO_REQ_ENTRY Component中启用AWE：从页面按钮到后台触发链

Workflow Definition建好后，必须在Component的SavePostChange事件中显式触发AWE引擎，否则点击“提交”按钮不会启动流程。这是90%配置失败的根源——以为绑定Component就自动生效。

3.1 修改PO_REQ_ENTRY的SavePostChange PeopleCode

打开ComponentPO_REQ_ENTRY→ PagePO_REQ_ENTRY→ FieldSAVE_PB（保存按钮）→ Events → SavePostChange。添加以下代码：

/* 1. 检查是否满足启动条件（如金额>10万才走三级审批） */ Local number &reqAmount; &reqAmount = &rs(1).PO_REQ_HDR.AMT.Value; If &reqAmount > 100000 Then /* 2. 创建Workflow Instance并启动 */ Local object &wfInstance; &wfInstance = CreateObject("Workflow"); &wfInstance.SetDefinitionName("WD_PO_REQ_APPROVAL"); /* 对应WF Definition名 */ &wfInstance.SetKey("REQ_ID", &rs(1).PO_REQ_HDR.REQ_ID.Value); /* 设置主键 */ &wfInstance.SetField("APPROVAL_STATUS", "PND"); /* 初始化状态 */ /* 3. 启动引擎（关键！） */ &wfInstance.Start(); /* 4. 更新UI提示 */ MessageBox(0, "", 0, 0, "采购申请已提交审批，流程ID：%1", &wfInstance.GetID()); Else /* 金额小则直过 */ SQLExec("UPDATE PS_PO_REQ_HDR SET APPROVAL_STATUS = 'APP' WHERE REQ_ID = :1", &rs(1).PO_REQ_HDR.REQ_ID.Value); End-If;

注意：&wfInstance.Start()是启动AWE的唯一入口。若此处遗漏，所有WF配置均为无效。GetID()返回的流程ID格式为WD_PO_REQ_APPROVAL_20240520142301_12345，可用于日志追踪。

3.2 配置AWE监控页面：实时查看流程实例状态

AWE提供标准监控页面EOAW_MONITOR，但需手动添加到导航栏。路径：Setup HRMS → Product Related → Workflow → Monitor Workflow。访问该页面后，输入WD_PO_REQ_APPROVAL可查看所有实例：

Instance ID	Status	Current Step	Last Updated	Approver
WD_PO_REQ_APPROVAL_20240520142301_12345	In Progress	STEP_DEPT_MANAGER	2024-05-20 14:23:01	JSMITH
WD_PO_REQ_APPROVAL_20240520142517_67890	Completed	—	2024-05-20 14:25:17	—

若状态卡在In Progress超过Timeout Days，AWE自动执行升级逻辑（需在Step中配置Escalation Step）。

3.3 测试验证：用真实数据触发并检查数据库变更

配置完成后，按以下步骤验证：

1. 前端提交：登录PS，进入PO_REQ_ENTRY页面，填写金额150000的采购申请，点击保存；
2. 检查AWE日志：查看PS_EOAW_LOG表，筛选WD_DEFN_NAME = 'WD_PO_REQ_APPROVAL'，确认LOG_LEVEL = 'INFO'且无ERROR记录；
3. 验证状态更新：查询PS_PO_REQ_HDR，确认APPROVAL_STATUS = 'PND'且LASTUPDDTTM已更新；
4. 模拟审批：用审批人账号登录，进入My Worklist→Approvals，找到该申请并批准；
5. 终态检查：再次查PS_PO_REQ_HDR，APPROVAL_STATUS应变为APP，且PS_EOAW_STEP表中对应Step的STATUS为COMPLETED。

提示：若审批后状态未更新，检查UpdateReqStatusToApp函数中的SQL是否被事务回滚——常见原因是PS_PO_REQ_HDR表锁冲突，建议在函数开头加SQLExec("SELECT 1 FROM PS_PO_REQ_HDR WHERE REQ_ID = :1 FOR UPDATE", &reqId)显式加锁。

4. EOAW_CORE深度调优：解决超时升级、会签冲突与性能瓶颈

AWE默认配置在高并发场景下易出现超时堆积、会签重复通知、查询缓慢等问题。这些问题根植于EOAW_CORE组件的设计逻辑，必须通过参数调整和代码加固解决。

4.1 处理超时升级：用Escalation Step替代人工催办

AWE的超时机制默认只发邮件提醒，不自动转交。需在Step中配置Escalation Step实现自动升级。以STEP_DEPT_MANAGER为例：

• Escalation Step:STEP_HRBP_ESCALATION
• Escalation Days:3（与Timeout Days一致）
• Escalation Action:Reassign（重新分配）

对应的STEP_HRBP_ESCALATION需定义Approver FunctionGetHRBPForDept(%This)，确保升级路径明确。关键点：Escalation Step的Reassign动作会覆盖原Step的审批记录，因此PS_EOAW_STEP表中STEP_NAME字段将从STEP_DEPT_MANAGER变为STEP_HRBP_ESCALATION，避免状态混乱。

4.2 解决会签冲突：用AND Split模式保证全员通过

多级会签（如财务+法务并行审批）需用AND SplitStep Type。配置时注意：

• Step Type:AND Split
• Branches: 添加两个Branch，分别指向STEP_FINANCE_HEAD和STEP_LEGAL_COUNSEL
• Join Condition:All Branches Complete（所有分支完成才进入下一环节）

此时AWE会为每个Branch创建独立Step实例，PS_EOAW_STEP中将出现两条记录，INSTANCE_ID相同但STEP_NAME不同。PeopleCode中需用&wfInstance.GetStepStatus("STEP_FINANCE_HEAD") = "COMPLETED"逐个校验，而非依赖单一状态字段。

4.3 性能优化：索引与缓存策略

EOAW_CORE高频查询表需针对性优化：

表名	必建索引	说明
PS_EOAW_INSTANCE	IDX_EOAW_INST_WDDEFN(WD_DEFN_NAME,STATUS)	加速监控页面按定义名查询
PS_EOAW_STEP	IDX_EOAW_STEP_INSTID(INSTANCE_ID,STATUS)	加速Step状态更新
PS_EOAW_LOG	分区按LOG_DATE	避免日志表膨胀拖慢查询

在EOAW_CORE的PeopleCode中，对常用查询启用缓存：

/* 缓存部门经理映射关系，减少DB查询 */ Local string &cacheKey = "DEPT_MANAGER_" | &deptId; Local string &managerId = %Session.GetCache(&cacheKey); If &managerId = "" Then &managerId = FetchManagerFromDB(&deptId); /* 实际DB查询 */ %Session.PutCache(&cacheKey, &managerId, 3600); /* 缓存1小时 */ End-If;

提示：%Session.PutCache的TTL单位为秒，生产环境建议不超过3600，避免缓存脏数据。

5. 排查AWE配置失效的5个关键检查点：从日志定位到代码断点

当工作流不触发、审批人为空或状态不更新时，按以下顺序排查，95%问题可在10分钟内定位：

5.1 检查Workflow Definition是否激活

AWE要求WF Definition必须处于Active状态。在Application Designer中打开WD_PO_REQ_APPROVAL，确认右下角Status显示Active。若为Inactive，右键→Activate。注意：激活操作需PeopleSoft Administrator角色权限，普通开发人员无法执行。

5.2 验证Component的Workflow Enable Flag

在ComponentPO_REQ_ENTRY的Properties → Use tab中，确认Enable Workflow复选框已勾选。若未勾选，AWE引擎完全不监听该Component的Save事件，所有配置无效。

5.3 查看PS_EOAW_LOG中的ERROR级别日志

执行一次提交操作后，立即查询：

SELECT LOG_MESSAGE, LOG_LEVEL, LOG_TIME FROM PS_EOAW_LOG WHERE LOG_TIME > SYSDATE - 1/24 AND LOG_LEVEL = 'ERROR' ORDER BY LOG_TIME DESC;

典型错误：

• No approvers found for step STEP_DEPT_MANAGER→GetDeptManager函数返回空数组
• Workflow definition WD_PO_REQ_APPROVAL not found→ Definition名拼写错误或未激活
• Invalid key field REQ_ID for record PO_REQ_HDR→PO_REQ_HDR表中REQ_ID字段类型非VARCHAR2(10)或为空

5.4 调试PeopleCode函数的执行路径

在GetDeptManager函数首行添加：

&wfInstance.LogMessage("DEBUG: GetDeptManager called for REQ_ID=" | &reqId, "INFO");

然后在PS_EOAW_LOG中搜索DEBUG:，确认函数是否被调用。若无日志，说明Workflow Instance未正确创建或Step未绑定函数。

5.5 检查PS_EOAW_STEP表的Step Status流转

查询该流程实例的所有Step：

SELECT STEP_NAME, STATUS, APPROVER_ID, START_DT, END_DT FROM PS_EOAW_STEP WHERE INSTANCE_ID = 'WD_PO_REQ_APPROVAL_20240520142301_12345';

正常流转应为：

• STEP_DEPT_MANAGER→IN_PROGRESS→COMPLETED
• STEP_FINANCE_HEAD→IN_PROGRESS（等待审批）

若STEP_DEPT_MANAGER长期为IN_PROGRESS，检查审批人JSMITH是否在PSOPRDEFN表中ACTIVE_FLAG = '1'且EMPLID有效。

注意：AWE的Step状态机严格遵循IN_PROGRESS→COMPLETED/REJECTED→TERMINATED三态，任何中间状态异常都意味着事务未正常提交。

本文还有配套的精品资源，点击获取