1. 先搞清楚SM36跑的是什么后台作业运行机制1.1 后台作业与前台程序有什么不一样每次登录SAP GUI你在事务码框里敲一个T-code程序就在你的会话里前台执行你盯着屏幕等结果这叫前台运行。你敲的SM36本身也是个前台程序但SM36干的事是把别的程序安排到后台去执行。SM36创建的定时作业完全不同你把一个程序、一个日期、一个时间告诉系统系统在后台一个人默默执行不需要你守在屏幕前也不用一直占着一个会话。哪个该前台跑哪个该后台跑大体上交互复杂、需要人临时输入的前台数据量大、耗时长、逻辑固定、定时重复的一律塞进后台。比如计提折旧、运行MRP、每天汇总报表、月结外币评估这些操作动辄跑几十分钟放前台你得一直占着对话会话非常浪费。我碰到过不少顾问刚接触SAP时总觉得“后台作业”和“前台运行”只是执行位置不同其实两者连执行会话都是独立的。你在前台跑一个程序如果你把GUI关了程序也就中断了。但后台作业不一样你把作业建好释放之后哪怕你立刻关机走人作业到点照样跑跑完日志照写。这正是定时作业的核心价值人要下班业务不能下班。1.2 Batch进程与SAP逻辑处理流程后台作业必须通过系统里的批处理进程Batch Process来执行。在SAP系统里你说的“后台作业”本质上就是调度器Dispatcher把一段任务分配给后台工作进程Dialog Work Process中的批处理类型进程执行完把日志和结果写进作业日志和假脱机Spool系统。你不需要管进程到底有多少个但你要知道它是有数量限制的。如果一个时间点排的作业太多超过Batch进程数量系统就会把后面的作业放入队列排队前面的不跑完后面的就一直等着。实际项目里最常遇到的现象就是作业确实在计划时间内触发了但一直处于“已计划”或者“准备”状态原因多半是进程排队。做BASIS的朋友应该清楚服务器上的“当前进程数”直接决定并发能力。很多小型项目只有三五个后台进程一到月底结账各个模块的作业全挤在一起后面的作业就只能在队列里干等。这时候别慌先看进程是不是被一个大作业占满了再决定是等还是调整作业优先级。作为模块顾问不需要去调参数但得看得懂这个现象否则你会在“作业为什么不跑”这个问题上浪费大半天。1.3 定时作业的典型应用场景我做过不少项目后台作业用得最多的场景大概五类批量数据接口例如定时从外围系统拉数据、跑RFC接口常见于SAP与SRM、MES、OA系统对接。批处理报表每天凌晨算前一天的数据比如销售日报、库存周转报表。月结年结程序比如外币评估、物料分类账、资产折旧、成本结算这些在月末集中跑一个作业跑完另一个接着跑。SAP标准程序调度比如MRP运行、订单结算、重估库存都和物料需求计划和生产执行强相关。外部命令或外部程序比如通过操作系统命令清理日志、压缩文件、调用外部脚本。这些场景的共同特点就是重复、可预测、时间固定。你稍微花十分钟把作业建好以后每天就不用再手动敲一遍程序。特别是月结的时候以前手工一个个T-code跑一忙就是两三个小时把流程做成定时作业之后到了时间自动跑你只需要第二天早上看一眼SM37的结果出错再介入。这就是为什么我一直建议项目里尽量把重复性工作作业化。2. 动手实操SM36创建定时作业的标准流程2.1 打开SM36后面前的界面一眼看明白SM36初始界面其实很简洁。顶部是一个包含多个字段的区段从上到下分别是作业名、作业类、作业状态、目标服务器下方就是两个核心标签页“步骤”和“起始条件”。很多人第一次打开SM36不知道从哪开始其实流程特别固定先定义一个唯一的作业名再定义步骤再定义起始条件然后保存完事。作业名建议按规范命名比如Z_RUN_MRP_DAILY、Z_DEPRECIATION_MONTH_END之类我见过太多项目用TEST1、JOB2这种名字到月末根本分不清是哪个作业最后只能打开挨个看步骤效率极低。这里顺带说下“作业类”字段。作业类在SAP里通常用A、B、C来区分优先级A类优先级最高C类最低。一般日常报表作业用B类就够了月结的敏感作业我会设成A类因为这时候系统忙、进程紧张得让它优先抢到Batch进程。如果你把所有作业都设成A那其实等于没有优先级所以别滥用。还有一个容易漏掉的字段是“目标服务器”。如果系统是多应用服务器集群你可以把作业固定在某台服务器上跑。比如某个作业需要读取特定应用服务器的本地文件那就必须指定目标服务器。大多数情况下留空或者用“服务器组”就行系统会自动分配。2.2 第一步定义作业步骤选程序、变式、输出设备点“步骤”按钮进入步骤定义界面。这里的关键是“用户”和“程序”的组合。系统会让你定义这个作业在哪个用户下运行然后填程序名也就是你要运行的ABAP程序、外部命令或外部程序。这里有一个极其重要的建议作业运行用户统一用专用服务账号不要用个人账号。为什么如果你用自己的账号跑账号密码过期、被锁、离职删号作业直接就跪了。而且作业日志会显示成你的名字如果出问题审计追查到的是个人。我在一个项目里就遇到过某财务接口作业因为密码过期连续三天凌晨没跑业务早上来问我们查了半天发现运行用户居然是一个早就不在公司的离职同事这就是典型的管理漏洞。在步骤界面里程序名可以直接填也可以用搜索帮助查找。你要运行的是ABAP程序填入程序名如果是外部命令或外部程序切换到对应页签。外部命令常用于调用操作系统脚本比如在Unix服务器上跑一个清理临时文件的命令。这部分需要BASIS配合定义外部命令权限普通顾问一般不建议直接碰。这一步最重要的就是“变式”Variant。同样的报表程序你跑今天的和跑昨天的很多时候只是参数不同变式就是为了解决这个问题。你可以在创建作业时直接新建变式也可以先把变式维护好在SE38或SA38里到SM36里选。变式一旦定下来程序每次跑都会按变式里的参数来不会出现明明连了测试环境却用了生产参数这种低级事故。顺带说一下步骤界面里还能设置输出的Spool参数。比如程序输出到打印机的可以指定输出设备、打印份数。如果业务需要自动打印报表这个设置就很有用。否则程序跑到最后生成一个Spool请求没人管它过几天就被系统自动清理了。2.3 第二步设置起始条件立即执行/定时执行/周期执行步骤定义完点“起始条件”按钮。这里有几个选项我逐个说。第一是“立即”就是保存后系统尽最大努力立刻去跑一般做一些临时补跑或者手动触发时才用。第二是“日期/时间”指定某年某月某日的某个时间点作业只跑一次。这种一般用于一次性任务比如你下周五要跑一次特殊报表。第三是“周期作业”它是真正的定时器能设定从某时刻开始每间隔多少时间运行一次。这里要提醒的是在SAP里精确到秒的调度说实话没必要绝大多数周期作业你设到分钟级就够了。系统的作业调度最小单位是分钟你可以设成每30分钟跑一次或者每6小时跑一次。如果业务要求必须精确到秒你需要额外检查应用服务器与数据库服务器的时间同步否则你设定的“08:00:00”和实际出发的“08:00:十几秒”会有偏差虽然通常不影响结果但扣时间逻辑的程序就必须注意了。起始条件界面里还有“作业后运行框架”等高级选项其中包含“其它作业”和“事件”调度。意思是可以让这个作业在另一个作业结束后触发或者在某个事件发生时触发。这部分我会在后面进阶部分展开新手第一阶段先掌握日期时间和周期就够用。2.4 第三步设置周期每日/每周/每月自动化周期周期作业设置界面里有两个组成部分日期和周期。日期定义在哪天开始运行、在哪天结束周期定义每隔多久跑一次。这里最容易踩的坑是很多人只知道填“周期”不知道用“标准周期”。在SAP里有一个“标准周期”按钮点开之后弹出“每日/每周/每月/其他周期”的快捷模板。你想每天跑选“每天”系统会自动在“周期值”里写一个时间间隔你想每个工作日跑就得手工决定是否排除周末。举个例子我想让作业每天凌晨2点跑一次。你可以选标准周期里的“每天”它会自动生成一个周期模式代表“每1天运行一次”然后你在下面的“开始时间”填02:00:00。如果想每周一早上6点跑就选“每周”系统会让你选择星期几。这里我特别想强调SAP对周期作业有一个隐形的“备份冗余”机制你创建周期作业时SAP会默认在周期前自动生成一个冗余作业下一次运行时间会顺延。有些顾问第一次看到作业列表里多了个状态为“已计划”的作业名字和你自己的差不多以为系统错乱了。这个其实非常正常。SAP这么设计是为了保证周期计算的稳定性不要手动去删那个带Redundancy标记的作业删了会影响周期自动延续。另外还要提一句周期作业的“期间开始”和“期间结束”是两个很容易被忽略的字段。如果你只填了开始日期没填结束日期作业会一直周期性跑下去。如果填了结束日期到了那天之后作业就静默退场不报错SM37里也看不到了。所以每次查看周期作业都要顺手确认一下结束日期。2.5 保存作业前的最后检查清单保存作业之前按我这几年练出来的习惯建议过一遍以下检查点作业名是否规范可辨识。运行用户是否为服务账号且该账号拥有程序执行权限。变式是否已保存有内容且变式用户与运行用户是否一致。目标服务器是否指定尤其多应用服务器集群环境。起始条件是定时还是周期时间值是否正确。需要输出时是否指定了假脱机输出设备。这套检查不用太长时间但能帮你挡住绝大多数低级问题。我为什么强调变式用户一致因为变式是按用户保存的创建变式的用户是A而作业运行用户是BB在运行时如果没有该变式的授权作业会直接报“变式不存在”错误而这个问题在作业启动前完全看不出来。你只能等作业跑了才发现报错白浪费一个晚上。很多项目里的作业日志一打开全是红字十有八九就是这种变式授权问题排查起来还特别隐蔽。3. 作业建好了不等于万事大吉SM37监控与问题排查3.1 SM37怎么看作业是否正常跑完定时作业的“定时”只是安排表真正验证成果总归要回到SM37。SM37是整个后台作业监控的总控室。打开SM37后报表选择屏幕里有“作业名”“用户名”“作业状态”等条件最常用的是按作业名和日期范围筛选。点执行后你能看到所有符合条件作业的列表列包括作业名、状态、开始日期/时间、最后运行过程、计划开始时间等等。判断一个作业跑没跑完看状态即可“已计划”表示还没到时间或者正在排队“已释放/已计划”一般表示已触发等待运行“完成”表示运行结束“取消的”表示出问题了“激活”表示正在运行。真正的超时和异常往往要通过“运行过程中的步骤”和“作业日志”进一步看。这里有个小细节SM37的列表可以双击作业进入作业定义界面里面有“作业日志”标签打开后能看到程序运行时写到日志里的每一条消息这是排查的第一现场。很多程序会把关键的报错信息写进日志如果你看到日志里出现红色的消息基本可以断定程序执行出了问题。还要记住作业显示“完成”不代表业务结果正确。SAP里所谓“完成”只代表程序正常结束时没有崩溃。如果程序逻辑里查不到数据、更新条数为0它照样正常结束、照样显示完成。所以我一般会在作业后的第二天早上让业务人员确认一下结果数据或者写一段简单的SQL去核对关键表里的记录数。3.2 作业没按计划运行的排查顺序我在生产中处理“作业没跑”这类工单一般按这样的顺序排查第一SM37查作业有没有在计划时间被触发。如果作业还是“已计划/释放”检查Batch进程够不够不够就等或调优先级。这一步解决的是“排队卡住”的问题。第二如果作业触发了但很快报错看作业日志最常见是程序权限、变式不存在、数据库锁。第三如果作业显示完成但业务说没效果去查程序日志和Spool输出有些程序“作业完成”仅仅是程序正常结束但里面的数据更新逻辑没满足条件。第四如果作业当天完全没出现查是不是有人误删或改了周期设置以及该作业的“最后运行日期”是否到期。周期作业有结束日期到了就真的静默退场了不会报错。这套顺序看上去简单但真按顺序查90%的问题十分钟内能定位。最怕的是不看SM37直接猜原因一会怀疑权限一会怀疑程序被改实际可能只是进程满了没轮上。还有一个经常被忽略的地方某些程序会直接通过SM36创建并释放作业但程序本身在运行过程中又动态创建了后续作业。这种作业的作业名可能带有动态编号你在SM37里按业务关键词搜可能搜不到还会以为是系统漏了。遇到这种情况要看主作业的日志或者查表TBTCO作业定义表和TBTCP作业步骤表这两个表里记录了所有后台作业的完整轨迹。3.3 常见的作业状态含义对照我把日常最常遇到的状态整理成一张速查表贴在下面。以后看到SM37里诡异状态先来对一下能省不少事。状态含义下一步动作已计划Released作业已到计划时间等待后台进程执行检查Batch队列耐心等待或调整优先级激活Active正在运行正常等待太久没结束则查DB锁或评估程序效率完成Finished成功运行完毕结合日志确认数据结果是否真的符合预期取消Canceled运行中断双击查作业日志定位程序或系统错误已计划/正在准备Scheduled已提交但未触发检查计划起始时间是否在未来已解除Released作业被手动释放看谁释放的可能被误操作除了这些我还想提醒一句关于“假脱机”的状态。如果作业生成了Spool输出但输出设备有问题作业本身可能显示完成但Spool状态是“有错误”。假脱机问题通常不影响程序数据更新但会影响打印报表需求方如果一直没收到打印件会来问你怎么回事。排查时别忘了看一眼Spool列表事务码SP01和SM37里都能看到。4. 进阶玩法与高频踩坑作业变式、周期运算、依赖调度4.1 作业变式让同一程序用不同参数跑进阶部分我想先讲变式因为它是后台作业最被低估的功能。变式Variant说白了就是程序参数的“打包”。你打开一个报表程序选了公司代码、时间区间、输出格式选完点保存就能存成一个变式。在SM36创建作业时选择这个变式作业每次跑起来就会自动用这一套参数。项目里最常见的做法是同一个程序按不同公司代码或不同工厂建多个变式再分别建多个作业。比如生产数据导出程序华东区一个变式、华南区一个变式两个作业每天各自跑各自的数据。这样互不干扰某一个跑挂了只影响一个区域。操作上有一个入口区别在程序选择屏幕的工具栏上“保存变式”按钮可以把当前参数保存成变式。如果你不想进SE38直接在SA38里运行程序也可以维护变式。SM36里创建作业时变式栏旁边有一个新建图标可以直接跳过去维护非常方便。这里我想提醒一个容易出错的点变式有“仅后台”属性如果程序里有选择屏幕字段被标记为“仅后台”前台执行时你看不到它但后台作业里会用到默认值。有时候作业参数怎么调都不对很可能就是这个字段的默认值被某个历史变式固定住了。排查方法很简单在变式维护界面里把所有字段都显示出来逐项检查那些你平时看不到的字段值。4.2 周期作业的“再加一次”与跨期调度接着说周期作业的一个隐藏机制。SAP创建的周期作业在作业列表里你会经常看到两个作业一个是你命名的原周期作业另一个名字带“RED”或者类似标识的冗余作业这是系统自动生成的目的是防止作业周期计算失真。不要手动删掉RED作业删了周期作业就不会自动继续了。要延长或修改周期直接在原始作业上改即可系统会自己重算下次运行时间。还有跨期调度的问题如果你建作业时设置的周期是每月1日跑但作业的结束日期是去年年底那它今年其实就静默不跑了。这类问题运维人员最容易忽略因为作业看着还在名字也在SM36打开也在但SM37里现在日期范围内什么都搜不到。判断周期是否有效最直接的方法是看SM37列表里的“计划开始时间”如果下一行永远是空的或者停留在很久以前就要怀疑周期已经终止了。另外SAP里对周期作业的“下一次开始时间”计算有一些鲜为人知的规则。比如你设定“每5分钟跑一次”你可能以为分秒不差实际上SAP会找到一个最小的整分钟倍数的起始点。这不算漏洞但在对接外部系统、按时间戳校验数据时会产生一些微小的偏差写接口程序时最好允许前后几分钟的容差。4.3 串行作业与事件调度有些任务要按顺序来比如先跑数据导出再跑数据转换最后再跑报表。这时候有几种做法第一种在一个作业里把多个步骤挨个加进去。后一个步骤何时启动由系统按顺序自动接续。这种最简单两个程序之间没有复杂的依赖关系只是人工顺序执行。第二种用“作业后运行框架”把后续作业设为前一个作业的后续作业条件是前一个作业运行成功或取消后再触发。第三种用事件调度程序运行中通过事件Event触发另一个作业。优先级和复杂程度从低到高。我个人的经验是能在同一个作业里多步骤解决的就尽量别拆成多作业。拆太多了依赖关系一旦断掉排查就是一场灾难。但反过来如果两个程序的内存占用都很高又必须串行拆成两个作业更稳哪怕它们用同一个Batch进程也不会挤在一起因为后一个作业必须等前一个完成才触发。事件调度适合那种“程序内部跑到某个点才发现需要触发另一个功能”的场景。说白了它是程序级联需要开发配合写代码触发事件。一般业务排程用不上如果项目里有人提议用事件调度先问一句“直接用后续作业行不行”大多数时候答案是肯定的。4.4 常见问题与避坑速查表这个表是我从多个项目教训里总结出来的基本覆盖了80%的SM36使用问题现象最常见原因处理建议作业没跑周期结束日期过期、作业被删、Batch进程不够查SM37计划时间和TBTCO表作业重复跑周期值设太小、作业被复制过查“最后运行过程”确认上次运行时间作业报错日志一片红变式不存在、运行用户权限不足、程序更新冲突从第一条红色消息往前倒查作业显示完成但数据没更新程序筛选条件无数据、更新逻辑未执行核对业务数据条件和变式参数作业找不到作业名是动态生成的、被误删查TBTCO/TBTCP表按用户和日期搜Spool有错误输出设备失效、打印格式缺失用SP01查看输出请求状态大家以后遇到类似问题直接照表排查基本上能少走很多弯路。不过要记住这些只能定位“作业层面”的问题如果程序本身的逻辑有错后台作业是救不了的还得回到代码层面去查。5. 最后说点实在话我踩过的坑和现在坚持的规矩最后聊一点个人体会。我最早学SM36的时候以为把程序、周期、日期填好就完事了直到有一个月末作业连续两次跑飞才发现问题出在“运行用户”和“变式用户”因为密码过期导致权限失效。从那以后我给自己立了三条规矩。第一所有生产环境后台作业统一挂到一个专用服务账号上。这个账号不干别的就是跑后台作业密码由BASIS统一管理每季度定期改。跑作业和改密码是分开的两拨人账号出事不会影响业务用户。第二每个作业的说明栏写清楚业务用途、运行频率、责任人。作业名可以简短但说明栏一定要写全。不然半年后你自己都想不起来这个Z_JOB_001是干嘛用的更别说新接手的同事了。第三定期用SM37列一次全部作业清单核对周期和最后运行情况。我一般建议每月第一周做一次不需要花太多时间但能在问题爆发前发现很多隐患比如某个周期作业悄悄停了、某个作业已经连着三天报错没人管。这三点听起来很基础但在实战里带来的安稳感比任何花哨技巧都值钱。定时作业这东西做得好了业务每天睁眼看到数据是齐的没人觉得你厉害做得不好凌晨的告警群消息会帮你把存在感拉满。希望这篇文章能帮你少踩几个坑把后台作业这个基本功练扎实关键时候不掉链子。