简介面向PeopleSoft开发与运维人员的中文技术文档围绕人力系统中的Application Engine批量处理、定时任务与模块集成展开。内容基于Enterprise PeopleTools 8.50 PeopleBook整理翻译涵盖应用引擎概述、实施步骤、程序元素与Meta-SQL并延伸到栏目、阶梯、行动等结构定义以及并发执行、错误恢复、日志记录与性能优化等机制。第一章从开始使用应用引擎讲起介绍基础概念、创建配置与数据源设置第二章深入内部机制与高级特性便于对照实践。资源为单个PDF文件压缩包约2.25MB便于本地检索与日常查阅适合需要理解后台作业调度、数据更新、报表生成和接口同步逻辑的中高级开发者。文档还包含许可限制、保修声明、危险应用与第三方内容等法律及安全提示能帮助读者在合规前提下开展实施与调试。目前已有341人学习下载可作为PeopleSoft中文学习与查参的补充材料。1. 从一份看不懂的 Application Engine 报错说起第一次接手 PeopleSoft 的人大概率会在同一天撞上两件事打开 Application Designer 看到一堆AE_开头的定义然后打开官方文档发现全是英文而且写得像法律条文。更麻烦的是Application Engine 的报错信息经常只有一句 Program failed at step XXX连是哪一行 PeopleCode 抛的都不告诉你。这份所谓「中文文档」要解决的就是这个断层把 Application Engine 的执行模型、状态机、临时表规则、重启逻辑这些必须搞懂才能排错的东西用中文讲清楚并落到可以直接抄的命令和配置上。适合三类人刚转过来做 PeopleSoft 二次开发的工程师、需要写批处理接口的 ERP 运维、以及被AEREQUEST表里一堆状态码搞懵的 DBA。后面几章会从执行模型讲到 Section 与 Step 的配合再到临时表、重启恢复和性能排查。2. Application Engine 的执行模型与最小可跑程序2.1 Application Engine 到底在跑什么Application Engine 不是解释器它是一套「编译成 SQL PeopleCode 混合体」的批处理框架。你在 Application Designer 里保存一个AE_程序时它会生成一份元数据运行时由PSAESTART、PSAESTEPDEFN这类表驱动实际执行的是AERUNCONTROL那条控制记录。理解这一点很关键程序不是「跑一个脚本」而是「一条控制记录驱动 N 个 Section每个 Section 按 Step 顺序往下走」。执行顺序可以概括成启动时调用Start段接着循环执行Main段最后走End段。每个 Step 有四种类型——SQL、PeopleCode、Call Section、Log Message。Step 执行失败会触发On Return或直接终止取决于 Action 的设置。这里的 Action 有Continue、Break、Abort、Skip Step几种选错 Action 是新手最常见的坑明明是想「出错就停」结果设成了Continue程序一路跑到底数据错得悄无声息。2.2 用 Application Designer 建一个最小可跑程序先建一个只做一件事的程序往一张自定义日志表插一条记录。步骤是先在 Application Designer 里File New App Engine Program命名为AE_HELLO然后加一个 SectionMainSection 类型选Prepare Only之外的那类即可通常选默认的Main。在 Section 里加一个 StepStep 类型选SQL录入-- 往自定义日志表插一条启动记录 INSERT INTO PS_AE_HELLO_LOG (OPRID, RUN_DTTM, RUN_STATUS) VALUES (:1, %CurrentDateTimeIn, STARTED)这里的:1是绑定变量绑定值在 Step 的Bind属性里设置成%OperatorId。%CurrentDateTimeIn是 PeopleCode 的元变量写成 SQL 里也能被 Application Engine 展开。改完保存右键Run选一个 Run Control程序就跑起来了。2.3 用命令行跑同一个程序很多人只知道在 PIA 里点按钮其实命令行更好排错。在应用服务器或批处理服务器上执行# 用 psae 直接跑一个 Application Engine 程序 cd $PS_HOME/appserv ./psae -CT ORACLE -CD DBNAME -CO USER -CP PWD \ -R INSTANCE -AI AE_HELLO参数含义-CT是数据库类型-CD是数据库名-CO/-CP是账号密码-R是应用服务器的实例名-AI是 Application Engine 程序名。跑完去PS_AE_HELLO_LOG里查能看到一条STARTED记录说明最小链路通了。注意命令行跑之前确认Tuxedo或psappsrv进程已启动否则会报Cannot connect to application server这个报错和程序本身无关别浪费时间在代码上。2.4 执行状态存在哪张表每跑一次Application Engine 会往PS_AERUNCONTROL写一条运行控制记录往PS_AESTEPDEFN写每个 Step 的定义PS_AERUNSTATE则记录当前跑到哪个 Step。状态码常见的是1运行中、2成功、3失败、4已重启。查一次运行结果-- 查最近 10 次 AE_HELLO 的运行状态 SELECT AE_APP_ID, PROCESS_INSTANCE, RUN_STATUS, RUN_CNTL_ID, RUN_DTTM FROM PS_AERUNCONTROL WHERE AE_APP_ID AE_HELLO ORDER BY RUN_DTTM DESC FETCH FIRST 10 ROWS ONLYPROCESS_INSTANCE是关键它贯穿AEREQUEST、AERUNCONTROL、AERUNSTATE重启时靠它找回现场。很多人排错只会看AEREQUEST的消息文本其实AERUNSTATE才能告诉你精确停在哪个 Step。3. Section、Step 与 Action 的配合规则3.1 Section 的四种类型怎么选Application Engine 的 Section 类型决定了它什么时候被 System 调用。Start在程序开始时跑一次Main是主体循环End在收尾时跑Prepare Only只做数据准备不做业务。实际项目里最常见的组合是一个Start做初始化一个Main做核心循环一个End做汇总和清理。Section 类型执行时机典型用途Start程序启动时一次初始化变量、打开文件Main主循环核心业务逻辑End收尾时一次汇总写回、释放资源Prepare Only仅准备阶段临时数据预装载一个反直觉的点Main段里如果写了Do While循环循环变量必须在Start段初始化否则每次重跑会叠加。常见做法是在Start段把计数器I设成 0再在Main里递增。3.2 Step 里的 Action 到底怎么设每个 Step 有On Return和On Error两类 Action。On Return控制正常返回后做什么On Error控制出错后做什么。最容易被误用的是On Error设成Continue结果一个 SQL 插入失败程序继续往下跑后面的逻辑全在脏数据上执行。推荐设成核心写操作On Error用Abort日志类操作可以用Continue。判定标准很简单——这一步失败后后续步骤的输出还有意义吗没有就Abort。另外Break只跳出当前循环不结束程序适合批量处理里跳过坏数据。3.3 Call Section 的传参方式把逻辑拆成多个 Section 后常用Call Section来复用。传参有两种一是通过%Bind传状态二是通过共享变量。更可靠的是用 Application Engine 的State Record——一个物理表或派生记录所有 Step 都能读写。-- 在 State Record 里记录当前处理到的 key UPDATE PS_AE_HELLO_STATE SET LAST_KEY :1 WHERE PROCESS_INSTANCE :2LAST_KEY在重启时起大作用下次从LAST_KEY往后继续而不是从头再来。这是 PeopleSoft 增量批处理的标配做法几乎每个成熟程序都有这么一张状态表。3.4 用 State Record 做断点续传State Record 可以设成Physical或Derived。物理表能跨进程、跨重启保留派生记录只在本次运行有效。批量程序建议用物理表字段至少包含PROCESS_INSTANCE、LAST_KEY、STATUS、UPD_DTTM。重启时的逻辑是在Start段先查 State Record如果STATUS Rrestart就取LAST_KEY否则初始化为起点。然后在Main的循环条件里用LAST_KEY做过滤避免全表扫描。这套模式配合psae -AI的Restart选项使用能省掉大量重复计算。4. 临时表、重启与常见失败的排查手法4.1 临时表的三种类型与选择PeopleSoft 的 Application Engine 临时表不是数据库临时表而是「按进程实例隔离」的普通表。清理方式决定了类型Non-Shared每个进程一份Shared所有进程共用Dedicated每个实例一份但需要显式清理。选错了会出现数据串号。类型隔离方式清理时机Non-Shared按进程实例程序结束时自动删Shared全局共用手动清理Dedicated按实例显式删除或按条件清常见坑是用Shared表存放用户级中间结果两个进程同时跑就互相覆盖。判断标准如果这张表的数据只属于当前这次运行就用Non-Shared如果多个程序要共享才用Shared而且必须自己管清理。4.2 用 TRUNCATE 还是 DELETE 清临时表清理临时表时TRUNCATE比DELETE快得多但TRUNCATE会重置高水位之后插入可能变慢而且不能回滚。小表用DELETE更安全大表用TRUNCATE提速。-- 清理当前进程实例的临时数据 DELETE FROM PS_AE_HELLO_TMP WHERE PROCESS_INSTANCE :1PROCESS_INSTANCE绑定%ProcessInstance只清自己那份不影响别的进程。如果用了Non-Shared类型程序结束时会自动清但显式删一次更保险尤其是程序异常中断的情况下。4.3 重启失败的三个常见原因重启时最常报的是Step not found或State record mismatch。原因通常有三一是程序定义改了Step 编号变了旧的状态记录对不上二是 State Record 的字段被改过三是临时表被清空了重启时找不到中间数据。排查顺序是先查PS_AERUNSTATE看STEP_NAME和当前程序定义是否一致再查 State Record 的LAST_KEY是否还在有效范围内最后确认临时表的进程实例数据是否完整。-- 查当前运行状态 SELECT AE_APP_ID, PROCESS_INSTANCE, STEP_NAME, RUN_STATUS, RUN_CNTL_ID FROM PS_AERUNSTATE WHERE PROCESS_INSTANCE :1拿到STEP_NAME后对照 Application Designer 里的 Step 定义就能定位到是定义变了还是数据变了。4.4 SQL 超时与锁等待的处理批量程序跑久了常见两类问题SQL 超时和行锁等待。超时通常是 SQL 没走索引用执行计划确认锁等待多是多个程序同时更新同一批数据。-- 查当前会话的锁等待情况 SELECT SID, SERIAL#, EVENT, WAIT_TIME, SECONDS_IN_WAIT FROM V$SESSION WHERE EVENT LIKE %enq%Oracle 下enq: TX - row lock contention是最常见的行锁等待。处理方式是错峰跑批或者在 SQL 里加FOR UPDATE SKIP LOCKED跳过被锁的行。SKIP LOCKED在 PeopleSoft 里支持但要确认数据库版本别在旧版本上硬写。5. 把 Application Engine 批处理跑稳的进阶技巧5.1 用 ReUse 与 ReCycle 控制资源Application Engine 有两个容易被忽略的属性ReUse和ReCycle。ReUse保留数据库连接不关闭适合连续跑很多 Step 的程序ReCycle定期重建连接避免长时间占用导致内存膨胀。选法很直接短平快的程序用ReUse省连接开销跑几个小时的大批处理用ReCycle配合Commit Frequency一起调。Commit 太频繁会拖慢速度太久又会在回滚段堆积。常见取值是几千行提交一次具体看单行 update 的代价。5.2 用 Trace 定位到具体 Step程序出错又没明细时开 Trace 是最快的手段。命令行加-TRACE 7 -TOOLSTRACESQL 31会在$PS_HOME/appserv/下生成 trace 文件里面按 Step 打印执行的 SQL 和 PeopleCode 行号。# 开 SQL 和 PeopleCode 双 trace ./psae -CT ORACLE -CD DBNAME -CO USER -CP PWD \ -R INSTANCE -AI AE_HELLO \ -TRACE 7 -TOOLSTRACESQL 31-TRACE 7是 Application Engine 的 trace 级别7 表示输出所有 Step-TOOLSTRACESQL 31输出 SQL 文本和绑定变量。trace 文件会很大记得跑完删掉不然磁盘会满。看到Error in Step: XXX时对应的 SQL 就在下面几行。5.3 批量程序的验证清单跑完批处理别只看「成功了」至少核对这几项AERUNCONTROL的状态是不是 2目标表行数对不对State Record 的LAST_KEY是不是终点值临时表是否已清空。这四项过了程序才算真的跑对。如果要在 CI 里做自动化验证可以把AERUNCONTROL的状态查询封装成脚本状态不等于 2 就退出码非零让流水线直接失败。这一步做了之后很多低级错误在上线前就能拦住比事后翻日志快得多。本文还有配套的精品资源点击获取
简介面向PeopleSoft开发与运维人员的中文技术文档围绕人力系统中的Application Engine批量处理、定时任务与模块集成展开。内容基于Enterprise PeopleTools 8.50 PeopleBook整理翻译涵盖应用引擎概述、实施步骤、程序元素与Meta-SQL并延伸到栏目、阶梯、行动等结构定义以及并发执行、错误恢复、日志记录与性能优化等机制。第一章从开始使用应用引擎讲起介绍基础概念、创建配置与数据源设置第二章深入内部机制与高级特性便于对照实践。资源为单个PDF文件压缩包约2.25MB便于本地检索与日常查阅适合需要理解后台作业调度、数据更新、报表生成和接口同步逻辑的中高级开发者。文档还包含许可限制、保修声明、危险应用与第三方内容等法律及安全提示能帮助读者在合规前提下开展实施与调试。目前已有341人学习下载可作为PeopleSoft中文学习与查参的补充材料。1. 从一份看不懂的 Application Engine 报错说起第一次接手 PeopleSoft 的人大概率会在同一天撞上两件事打开 Application Designer 看到一堆AE_开头的定义然后打开官方文档发现全是英文而且写得像法律条文。更麻烦的是Application Engine 的报错信息经常只有一句 Program failed at step XXX连是哪一行 PeopleCode 抛的都不告诉你。这份所谓「中文文档」要解决的就是这个断层把 Application Engine 的执行模型、状态机、临时表规则、重启逻辑这些必须搞懂才能排错的东西用中文讲清楚并落到可以直接抄的命令和配置上。适合三类人刚转过来做 PeopleSoft 二次开发的工程师、需要写批处理接口的 ERP 运维、以及被AEREQUEST表里一堆状态码搞懵的 DBA。后面几章会从执行模型讲到 Section 与 Step 的配合再到临时表、重启恢复和性能排查。2. Application Engine 的执行模型与最小可跑程序2.1 Application Engine 到底在跑什么Application Engine 不是解释器它是一套「编译成 SQL PeopleCode 混合体」的批处理框架。你在 Application Designer 里保存一个AE_程序时它会生成一份元数据运行时由PSAESTART、PSAESTEPDEFN这类表驱动实际执行的是AERUNCONTROL那条控制记录。理解这一点很关键程序不是「跑一个脚本」而是「一条控制记录驱动 N 个 Section每个 Section 按 Step 顺序往下走」。执行顺序可以概括成启动时调用Start段接着循环执行Main段最后走End段。每个 Step 有四种类型——SQL、PeopleCode、Call Section、Log Message。Step 执行失败会触发On Return或直接终止取决于 Action 的设置。这里的 Action 有Continue、Break、Abort、Skip Step几种选错 Action 是新手最常见的坑明明是想「出错就停」结果设成了Continue程序一路跑到底数据错得悄无声息。2.2 用 Application Designer 建一个最小可跑程序先建一个只做一件事的程序往一张自定义日志表插一条记录。步骤是先在 Application Designer 里File New App Engine Program命名为AE_HELLO然后加一个 SectionMainSection 类型选Prepare Only之外的那类即可通常选默认的Main。在 Section 里加一个 StepStep 类型选SQL录入-- 往自定义日志表插一条启动记录 INSERT INTO PS_AE_HELLO_LOG (OPRID, RUN_DTTM, RUN_STATUS) VALUES (:1, %CurrentDateTimeIn, STARTED)这里的:1是绑定变量绑定值在 Step 的Bind属性里设置成%OperatorId。%CurrentDateTimeIn是 PeopleCode 的元变量写成 SQL 里也能被 Application Engine 展开。改完保存右键Run选一个 Run Control程序就跑起来了。2.3 用命令行跑同一个程序很多人只知道在 PIA 里点按钮其实命令行更好排错。在应用服务器或批处理服务器上执行# 用 psae 直接跑一个 Application Engine 程序 cd $PS_HOME/appserv ./psae -CT ORACLE -CD DBNAME -CO USER -CP PWD \ -R INSTANCE -AI AE_HELLO参数含义-CT是数据库类型-CD是数据库名-CO/-CP是账号密码-R是应用服务器的实例名-AI是 Application Engine 程序名。跑完去PS_AE_HELLO_LOG里查能看到一条STARTED记录说明最小链路通了。注意命令行跑之前确认Tuxedo或psappsrv进程已启动否则会报Cannot connect to application server这个报错和程序本身无关别浪费时间在代码上。2.4 执行状态存在哪张表每跑一次Application Engine 会往PS_AERUNCONTROL写一条运行控制记录往PS_AESTEPDEFN写每个 Step 的定义PS_AERUNSTATE则记录当前跑到哪个 Step。状态码常见的是1运行中、2成功、3失败、4已重启。查一次运行结果-- 查最近 10 次 AE_HELLO 的运行状态 SELECT AE_APP_ID, PROCESS_INSTANCE, RUN_STATUS, RUN_CNTL_ID, RUN_DTTM FROM PS_AERUNCONTROL WHERE AE_APP_ID AE_HELLO ORDER BY RUN_DTTM DESC FETCH FIRST 10 ROWS ONLYPROCESS_INSTANCE是关键它贯穿AEREQUEST、AERUNCONTROL、AERUNSTATE重启时靠它找回现场。很多人排错只会看AEREQUEST的消息文本其实AERUNSTATE才能告诉你精确停在哪个 Step。3. Section、Step 与 Action 的配合规则3.1 Section 的四种类型怎么选Application Engine 的 Section 类型决定了它什么时候被 System 调用。Start在程序开始时跑一次Main是主体循环End在收尾时跑Prepare Only只做数据准备不做业务。实际项目里最常见的组合是一个Start做初始化一个Main做核心循环一个End做汇总和清理。Section 类型执行时机典型用途Start程序启动时一次初始化变量、打开文件Main主循环核心业务逻辑End收尾时一次汇总写回、释放资源Prepare Only仅准备阶段临时数据预装载一个反直觉的点Main段里如果写了Do While循环循环变量必须在Start段初始化否则每次重跑会叠加。常见做法是在Start段把计数器I设成 0再在Main里递增。3.2 Step 里的 Action 到底怎么设每个 Step 有On Return和On Error两类 Action。On Return控制正常返回后做什么On Error控制出错后做什么。最容易被误用的是On Error设成Continue结果一个 SQL 插入失败程序继续往下跑后面的逻辑全在脏数据上执行。推荐设成核心写操作On Error用Abort日志类操作可以用Continue。判定标准很简单——这一步失败后后续步骤的输出还有意义吗没有就Abort。另外Break只跳出当前循环不结束程序适合批量处理里跳过坏数据。3.3 Call Section 的传参方式把逻辑拆成多个 Section 后常用Call Section来复用。传参有两种一是通过%Bind传状态二是通过共享变量。更可靠的是用 Application Engine 的State Record——一个物理表或派生记录所有 Step 都能读写。-- 在 State Record 里记录当前处理到的 key UPDATE PS_AE_HELLO_STATE SET LAST_KEY :1 WHERE PROCESS_INSTANCE :2LAST_KEY在重启时起大作用下次从LAST_KEY往后继续而不是从头再来。这是 PeopleSoft 增量批处理的标配做法几乎每个成熟程序都有这么一张状态表。3.4 用 State Record 做断点续传State Record 可以设成Physical或Derived。物理表能跨进程、跨重启保留派生记录只在本次运行有效。批量程序建议用物理表字段至少包含PROCESS_INSTANCE、LAST_KEY、STATUS、UPD_DTTM。重启时的逻辑是在Start段先查 State Record如果STATUS Rrestart就取LAST_KEY否则初始化为起点。然后在Main的循环条件里用LAST_KEY做过滤避免全表扫描。这套模式配合psae -AI的Restart选项使用能省掉大量重复计算。4. 临时表、重启与常见失败的排查手法4.1 临时表的三种类型与选择PeopleSoft 的 Application Engine 临时表不是数据库临时表而是「按进程实例隔离」的普通表。清理方式决定了类型Non-Shared每个进程一份Shared所有进程共用Dedicated每个实例一份但需要显式清理。选错了会出现数据串号。类型隔离方式清理时机Non-Shared按进程实例程序结束时自动删Shared全局共用手动清理Dedicated按实例显式删除或按条件清常见坑是用Shared表存放用户级中间结果两个进程同时跑就互相覆盖。判断标准如果这张表的数据只属于当前这次运行就用Non-Shared如果多个程序要共享才用Shared而且必须自己管清理。4.2 用 TRUNCATE 还是 DELETE 清临时表清理临时表时TRUNCATE比DELETE快得多但TRUNCATE会重置高水位之后插入可能变慢而且不能回滚。小表用DELETE更安全大表用TRUNCATE提速。-- 清理当前进程实例的临时数据 DELETE FROM PS_AE_HELLO_TMP WHERE PROCESS_INSTANCE :1PROCESS_INSTANCE绑定%ProcessInstance只清自己那份不影响别的进程。如果用了Non-Shared类型程序结束时会自动清但显式删一次更保险尤其是程序异常中断的情况下。4.3 重启失败的三个常见原因重启时最常报的是Step not found或State record mismatch。原因通常有三一是程序定义改了Step 编号变了旧的状态记录对不上二是 State Record 的字段被改过三是临时表被清空了重启时找不到中间数据。排查顺序是先查PS_AERUNSTATE看STEP_NAME和当前程序定义是否一致再查 State Record 的LAST_KEY是否还在有效范围内最后确认临时表的进程实例数据是否完整。-- 查当前运行状态 SELECT AE_APP_ID, PROCESS_INSTANCE, STEP_NAME, RUN_STATUS, RUN_CNTL_ID FROM PS_AERUNSTATE WHERE PROCESS_INSTANCE :1拿到STEP_NAME后对照 Application Designer 里的 Step 定义就能定位到是定义变了还是数据变了。4.4 SQL 超时与锁等待的处理批量程序跑久了常见两类问题SQL 超时和行锁等待。超时通常是 SQL 没走索引用执行计划确认锁等待多是多个程序同时更新同一批数据。-- 查当前会话的锁等待情况 SELECT SID, SERIAL#, EVENT, WAIT_TIME, SECONDS_IN_WAIT FROM V$SESSION WHERE EVENT LIKE %enq%Oracle 下enq: TX - row lock contention是最常见的行锁等待。处理方式是错峰跑批或者在 SQL 里加FOR UPDATE SKIP LOCKED跳过被锁的行。SKIP LOCKED在 PeopleSoft 里支持但要确认数据库版本别在旧版本上硬写。5. 把 Application Engine 批处理跑稳的进阶技巧5.1 用 ReUse 与 ReCycle 控制资源Application Engine 有两个容易被忽略的属性ReUse和ReCycle。ReUse保留数据库连接不关闭适合连续跑很多 Step 的程序ReCycle定期重建连接避免长时间占用导致内存膨胀。选法很直接短平快的程序用ReUse省连接开销跑几个小时的大批处理用ReCycle配合Commit Frequency一起调。Commit 太频繁会拖慢速度太久又会在回滚段堆积。常见取值是几千行提交一次具体看单行 update 的代价。5.2 用 Trace 定位到具体 Step程序出错又没明细时开 Trace 是最快的手段。命令行加-TRACE 7 -TOOLSTRACESQL 31会在$PS_HOME/appserv/下生成 trace 文件里面按 Step 打印执行的 SQL 和 PeopleCode 行号。# 开 SQL 和 PeopleCode 双 trace ./psae -CT ORACLE -CD DBNAME -CO USER -CP PWD \ -R INSTANCE -AI AE_HELLO \ -TRACE 7 -TOOLSTRACESQL 31-TRACE 7是 Application Engine 的 trace 级别7 表示输出所有 Step-TOOLSTRACESQL 31输出 SQL 文本和绑定变量。trace 文件会很大记得跑完删掉不然磁盘会满。看到Error in Step: XXX时对应的 SQL 就在下面几行。5.3 批量程序的验证清单跑完批处理别只看「成功了」至少核对这几项AERUNCONTROL的状态是不是 2目标表行数对不对State Record 的LAST_KEY是不是终点值临时表是否已清空。这四项过了程序才算真的跑对。如果要在 CI 里做自动化验证可以把AERUNCONTROL的状态查询封装成脚本状态不等于 2 就退出码非零让流水线直接失败。这一步做了之后很多低级错误在上线前就能拦住比事后翻日志快得多。本文还有配套的精品资源点击获取
