DevOps Advanced

AutoSys + SAP + Oracle: 3 Enterprise Integration Patterns

Q: How do you debug an SAP job that stays PENDING in AutoSys?

Step-by-step debugging for PENDING SAP jobs: 1. Check SAP agent connectivity: `autoping -m sap-agent-server`. If INACTIVE, agent is down or network blocked. 2. Check XBP user status in SAP: transaction SUIM → User → Display. Look for locked or expired password. 3. Check SAP system availability: from agent machine, `telnet sap-app-server 3300` (default RFC port). 4. Check SAP job scheduling log: In SAP transaction SM37, look for the scheduled background job. If it's not there, XBP submission failed. 5. Check AutoSys event_demon.log: `grep SAP_JOB_NAME $AUTOUSER/out/event_demon.$AUTOSERV`. Look for RFC error messages. Most common issue: XBP user password expired. Work with Basis team to reset and unlock. Add monitoring for PENDING duration > 30 minutes to alert before business impact.

📅 March 19, 2026 ⏱ 3 min read 🎯 Advanced

Where developers are forged. · Structured learning · Free forever.

📍 Part of: AutoSys → Topic 28 of 30

SAP job_type: s submits ABAP reports.

🔥 Advanced — solid DevOps foundation required

In this tutorial, you'll learn

SAP job_type: s submits ABAP reports.

SAP jobs (job_type: s) need XBP user with S_XBP_ADM. Locked user = PENDING forever. No error in AutoSys.
sqlplus wrapper is MANDATORY. Never call sqlplus directly. Check output for ORA- patterns and exit non-zero.
Oracle EBS job_type: 'o' tracks submission, not execution. Check concurrent manager logs separately.

thecodeforge.io

SAP and Oracle Integration

Autosys Integration Sap Oracle

✦ Plain-English analogy ✦ Real code with output ✦ Interview questions

⚡Quick Answer

SAP integration uses job_type: s and the SAPXPBP interface. Requires XBP user with S_XBP_ADM and S_BTCH_ADM authorisations.
Oracle EBS integration uses job_type: o to submit concurrent programs. Requires EBS agent and concurrent manager setup.
Oracle Database integration uses CMD + sqlplus. The trap: sqlplus exits 0 even on SQL errors. Add 'WHENEVER SQLERROR EXIT SQL.SQLCODE'.
The 5-step pattern: File Watcher → Database load → Stored proc → SAP job → Email report. AutoSys orchestrates across all systems.
Production failure: SAP XBP user locked after password expiry. Jobs stay PENDING. No error in AutoSys logs. Always involve Basis team in user management.

🚨 START HERE

ERP Integration — 60-Second Diagnosis

When cross-system jobs fail or silently misbehave

🟡

SAP job stuck PENDING

Immediate ActionCheck SAP agent and XBP user

Commands

autoping -m sap-agent

Check with SAP Basis: SUIM → User → XBP user status

Fix NowUnlock XBP user or restart SAP agent

🟡

sqlplus job SUCCESS but data unchanged

Immediate ActionCheck sqlplus output for errors

Commands

cat $AUTOUSER/std_out_files/JOBNAME.out

grep -i 'ORA-\|SP2-' $AUTOUSER/std_out_files/JOBNAME.out

Fix NowAdd WHENEVER SQLERROR EXIT SQL.SQLCODE to SQL script

🟡

Oracle EBS job succeeded but concurrent program failed

Immediate ActionCheck EBS concurrent manager logs

Commands

# On EBS app server: ls -la $APPLCSF/$APPLLOG/*.log

tail -100 $APPLCSF/$APPLLOG/request_<request_id>.log

Fix NowReview concurrent program definition and parameters

🟡

SAP RFC communication error

Immediate ActionTest RFC connection from SAP agent

Commands

telnet sap-app-server 3300

Check SM59 → RFC destination in SAP GUI

Fix NowRegenerate XBP user password with Basis team

Production Incident

The sqlplus 'Success' That Was Actually a Syntax Error

An Oracle stored procedure job ran nightly. AutoSys showed SUCCESS every time. The data was never updated. Six months later, a manual reconciliation found the discrepancy. The job had been failing silently the entire time.

SymptomAutoSys job shows SUCCESS. The downstream job that depends on this Oracle data doesn't complain — it just processes stale data. No errors in AutoSys logs. No alerts. The business continues on outdated information for months.

AssumptionThe team assumed that because AutoSys showed SUCCESS, the Oracle job worked. They didn't know that sqlplus returns exit code 0 for ALL scenarios unless you explicitly configure error handling.

Root causeThe sqlplus command in the CMD job was: sqlplus user/pass@DB @/scripts/update_proc.sql. The SQL script had a syntax error — a missing semicolon. sqlplus parsed the script, printed 'SP2-0042: unknown command', then exited with code 0. AutoSys saw code 0 and marked the job SUCCESS. The database never executed the stored procedure call because the script didn't parse. No rows were updated. The DBA team never saw an error because the job 'succeeded' from AutoSys's perspective.

Fix1. Add to every SQL script header: WHENEVER SQLERROR EXIT SQL.SQLCODE WHENEVER OSERROR EXIT 9 2. Also check for parsing errors: WHENEVER SQLERROR EXIT SQL.SQLCODE catches runtime errors. For syntax errors, sqlplus exits 0 unless you use -r option? Actually, syntax errors still return 0. The real fix: wrap sqlplus in a shell script that checks for 'ORA-' or 'SP2-' in the output and exits non-zero. 3. Example wrapper: ``

bash
   sqlplus -s user/pass@DB @script.sql > sqlplus.out 2>&1
   if grep -qi 'ORA-\|SP2-' sqlplus.out; then
     echo "SQL error detected"
     exit 1
   fi


4. Always set

std_out_file and std_err_file` in the job definition to capture sqlplus output.

Key Lesson

sqlplus returns 0 on success AND on SQL errors. Never trust it alone.Wrap sqlplus in a script that checks output for error patterns.WHENEVER SQLERROR EXIT SQL.SQLCODE helps but doesn't catch syntax errors.Capture stdout and stderr to files and inspect them in monitoring.

Production Debug Guide

When SAP or Oracle jobs don't behave, check these first

SAP job stays in PENDING state indefinitely→Check SAP agent connectivity: autoping -m sap-agent-server. Verify XBP user is not locked in SAP (SUIM transaction). Check SAP system availability and job scheduling permissions.

Oracle EBS concurrent program shows 'Success' in AutoSys but didn't run or failed internally→Check concurrent manager logs in Oracle EBS. AutoSys only tracks submission success, not execution success. The concurrent program may have errored after start. Review $APPLCSF/$APPLLOG for details.

sqlplus job shows SUCCESS in AutoSys but database changes didn't happen→Check sqlplus output in std_out_file/std_err_file. Look for ORA- (Oracle errors) or SP2- (sqlplus errors). Add error detection wrapper script.

SAP job fails with 'RFC communication error'→Verify RFC destination in SAP is active (SM59). Check network connectivity between SAP agent and SAP application server. Confirm XBP user has RFC authorisations.

AutoSys orchestrates across SAP, Oracle, file systems, and databases in one workflow. That's the value proposition.

The mechanics are simple: special job types for SAP ('s') and Oracle EBS ('o'), plus regular CMD jobs for sqlplus. But the failure modes are not obvious.

sqlplus exits 0 even when your SQL has a syntax error. SAP XBP users expire and jobs silently wait. Oracle EBS concurrent programs return 'Success' even when the program logic failed. This article covers the integration patterns and the gotchas that don't appear in the docs.

AutoSys and SAP — the SAPXPBP interface

AutoSys integrates with SAP R/3 and S/4HANA through the SAP XBP (External Background Processing) interface, also called SAPXPBP. This allows AutoSys to: - Submit SAP background jobs (ABAP programs, reports) - Monitor SAP job status and intercept completion events - Chain SAP jobs with non-SAP jobs in the same workflow

The SAP agent (a specialised AutoSys agent) handles the communication with the SAP application server. Behind the scenes, it uses RFC calls to the XBP function module.

Critical: The XBP user account must have specific authorisations (S_XBP_ADM, S_BTCH_ADM). If the password expires or the account locks, AutoSys jobs will stay PENDING forever with no error in AutoSys logs. The only signal is 'job not starting'.

sap_job.jil · BASH

123456789101112131415161718

/* SAP job type — triggers an ABAP program in SAP */
insert_job: PRD_SAP_FI_EOD_CLOSE
job_type: s                       /* 's' = SAP job type */
sap_server_name: PRDSAP           /* SAP system/instance name */
sap_report_name: RFBIBL00         /* ABAP report to run */
sap_report_variant: EOD_VARIANT   /* variant (parameter set) */
sap_client: 100                   /* SAP client number */
machine: sap-agent-server-01      /* machine with SAP agent installed */
owner: sapbatch
date_conditions: 1
days_of_week: mon-fri
start_times: "18:00"
condition: success(PRD_TRADING_LOAD_DAILY)  /* runs after trading load */
alarm_if_fail: 1
description: "SAP FI end-of-day period close"

/* SAP job with external command (optional) */
sap_external_command: Y_AUTOSYS_CALLBACK   /* RFC callback after completion */

⚠ SAP job failures are silent in AutoSys logs

If the XBP user is locked or the SAP system unreachable, the SAP job stays PENDING. No error in event_demon.log. The job just never starts. Always monitor PENDING duration and coordinate SAP user management with Basis team.

📊 Production Insight

A financial month-end close failed because the SAP month-end job didn't run. AutoSys showed the job as PENDING. No errors in any log. The team spent 4 hours checking Event Server, Event Processor, network connectivity.

The actual issue: The XBP user's password expired 3 days ago. SAP locked the user. AutoSys's SAP agent couldn't authenticate, so it never submitted the job. AutoSys had no way to know — it just waited for a response that never came.

Fix: Set XBP user password to never expire (coordinate with SAP security policy). Add monitoring for jobs in PENDING state longer than expected. Create a weekly check with Basis team to verify XBP user status.

Rule: SAP integration requires joint monitoring with SAP Basis. AutoSys can't see SAP-side authentication failures.

🎯 Key Takeaway

SAP integration uses job_type: s with XBP interface.

Requires Basis team for XBP user setup and ongoing maintenance.

XBP user locked = PENDING forever. No AutoSys error.

Monitor PENDING duration as proxy for SAP auth failures.

Which SAP integration method to use?

IfYou need to run ABAP reports or background jobs in SAP

→

UseUse job_type: s with SAP agent. Standard pattern for most integrations.

IfYou just need to check if a file exists in SAP application server

→

UseUse File Watcher on SAP application server (if agent installed) — simpler than XBP.

IfYou need two-way SAP-to-AutoSys triggering (SAP starts AutoSys job)

→

UseUse sap_external_command with RFC callback. Requires custom ABAP development.

IfSAP team won't set up XBP authorisations

→

UseFallback to CMD job calling sapftp file transfer + external process. Less reliable.

AutoSys and Oracle — database job types

AutoSys can trigger Oracle stored procedures, SQL scripts, and Oracle E-Business Suite (EBS) concurrent programs. The approach depends on whether you're calling Oracle Database directly or Oracle ERP application layer.

For Oracle Database: The most common method is a CMD job calling sqlplus. But sqlplus has a fatal flaw: it returns exit code 0 even on SQL errors. You cannot trust its exit code alone.

For Oracle EBS: Use job_type: 'o' to submit concurrent programs directly. This sends the request to Oracle EBS concurrent manager. AutoSys tracks submission success, but not execution success. The concurrent program can fail after start and AutoSys will still show SUCCESS.

oracle_job.jil · BASH

123456789101112131415161718192021222324252627282930313233

/* Method 1: CMD job calling sqlplus with proper error handling */
insert_job: PRD_ORA_RECONCILE_DAILY
job_type: CMD
command: "/usr/bin/sqlplus_wrapper.sh batchuser/pass@ORCL /scripts/oracle/reconcile.sql"
machine: db-server-01
owner: orabatch
condition: success(PRD_TRADING_LOAD_DAILY)
alarm_if_fail: 1
std_out_file: /logs/autosys/PRD_ORA_RECONCILE_DAILY.out
std_err_file: /logs/autosys/PRD_ORA_RECONCILE_DAILY.err

/* sqlplus_wrapper.sh content */
#!/bin/bash
sqlplus -s $1 @$2 > sqlplus.out 2>&1
if grep -qi 'ORA-\|SP2-\|PLS-' sqlplus.out; then
  echo "SQL error detected"
  cat sqlplus.out
  exit 1
fi
exit 0

/* Method 2: Oracle E-Business Suite concurrent program */
insert_job: PRD_ORA_EBS_PAYROLL
job_type: o                        /* 'o' = Oracle EBS job type */
oebs_server_name: PRDEBS
oebs_responsibility: GL_SUPER_USER
oebs_program_short_name: XLAFSNAPR
oebs_argument1: 2026
oebs_argument2: 03
machine: oebs-agent-server
owner: ebsbatch
alarm_if_fail: 1
std_out_file: /logs/autosys/PRD_ORA_EBS_PAYROLL.out

⚠ sqlplus returns 0 on SQL errors — wrap it immediately

Never call sqlplus directly in a CMD job. Always wrap it in a shell script that checks output for ORA- and SP2- error patterns. AutoSys trusts the exit code. sqlplus lies.

📊 Production Insight

A nightly Oracle stored procedure job ran for 18 months. AutoSys showed SUCCESS every night. The database team occasionally saw 'ORA-00942: table or view does not exist' in the logs but assumed it was resolved because AutoSys said SUCCESS.

The table had been renamed 18 months ago. The stored procedure was calling a table that no longer existed. The job did nothing every night for a year and a half.

Root cause: The sqlplus command had no error checking. The SQL script had a syntax error. sqlplus printed an error and exited 0. AutoSys moved on.

Fix: Deployed sqlplus wrapper script to all database jobs. Added monitoring that checks for any ORA- errors in stdout, regardless of exit code. The wrapper is now mandatory for all new jobs.

Rule: Add sqlplus wrapper script to your CI/CD pipeline for AutoSys job definitions. Enforce it in code review.

🎯 Key Takeaway

Oracle DB: CMD + sqlplus + ERROR CHECKING WRAPPER — never naked sqlplus.

Oracle EBS: job_type: 'o' for concurrent programs.

sqlplus wrapper must grep for ORA-, SP2-, PLS- and exit non-zero.

AutoSys tracks EBS submission success, not execution success. Check concurrent manager logs.

Practical integration patterns

The most common enterprise AutoSys flow that involves SAP and Oracle typically looks like this: 1. File Watcher detects upstream data file (trade file from external counterparty) 2. CMD jobs load data into staging database (Oracle external table or SQL*Loader) 3. Oracle stored procedure processes data, validates, transforms 4. SAP job runs the period-close or posting ABAP report (using validated data) 5. CMD job generates confirmation report and emails finance team

All five steps are orchestrated by AutoSys with dependency conditions between each step — if any step fails, everything downstream stops and the team is alerted.

Production pattern: Add a validation job after each ERP call. For SAP, check that the XBP user is active before submitting. For Oracle, verify that the stored procedure actually processed rows (check output table counts). Never assume success.

integration_pattern.jil · BASH

123456789101112131415161718192021222324252627282930313233343536373839404142

/* Complete 5-step enterprise workflow */

/* Step 1: File Watcher */
insert_job: FW_WATCH_TRADE_FILE
job_type: FW
watch_file: /data/inbound/trades_*.csv
min_file_size: 1024
machine: landing-server
run_window: "06:00 - 20:00"

/* Step 2: Load to staging */
insert_job: CMD_LOAD_STAGING
job_type: CMD
command: /scripts/load_trades_to_staging.sh
machine: db-server
condition: success(FW_WATCH_TRADE_FILE)

/* Step 3: Oracle stored procedure */
insert_job: ORA_VALIDATE_TRADES
job_type: CMD
command: /scripts/oracle_wrapper.sh @/sql/validate_trades.sql
machine: db-server
condition: success(CMD_LOAD_STAGING)
std_out_file: /logs/validate_trades.out

/* Step 4: SAP month-end close */
insert_job: SAP_MONTH_CLOSE
job_type: s
sap_server_name: PRDSAP
sap_report_name: Z_MONTH_CLOSE
sap_client: 100
machine: sap-agent
condition: success(ORA_VALIDATE_TRADES)

/* Step 5: Confirmation email */
insert_job: CMD_SEND_REPORT
job_type: CMD
command: /scripts/send_confirmation.sh
machine: mail-server
condition: success(SAP_MONTH_CLOSE)

alarm_if_fail: 1 on all jobs

🔥The validation pattern saves weeks of debugging

After each Oracle stored procedure, run a SELECT COUNT(*) query to verify rows were processed. After each SAP job, check that the background job completed successfully in SM37. Add these as separate AutoSys validation jobs with their own alarms.

📊 Production Insight

A bank's end-of-day workflow had no validation steps after the Oracle stored procedure. The procedure ran but processed 0 rows because the staging table was empty (upstream load failed silently). The job 'succeeded' and triggered the SAP month-end close. SAP closed the period with no trade data. The bank had to manually re-open the period and reprocess — a 3-day operational nightmare.

Root cause: No validation between Oracle and SAP. The team assumed that if the Oracle job succeeded, it had processed data.

Fix: Added a validation job after each Oracle stored procedure. The job runs a simple SELECT COUNT(*) query and exits non-zero if row count = 0. The validation job blocks SAP until data is confirmed.

Pattern: Insert a validation job after EVERY data processing step. Count rows, check for existence of expected values, verify foreign keys. If validation fails, the workflow stops and alarms immediately.

Rule: In cross-system workflows, never trust that 'success' means 'data was processed'. Always validate independently.

🎯 Key Takeaway

5-step pattern: File Watcher → Load → Oracle proc → SAP job → Report.

Add validation jobs after every data transformation step.

Don't chain SAP directly to Oracle without row-count validation.

Cross-system failures cascade silently. Each step needs its own error detection.

🗂 ERP Integration Methods — At a Glance

Each integration target uses different job types and has different failure modes

Integration target	Job type code	What AutoSys can do	Failure detection	Prerequisite
SAP R/3 / S/4HANA	s (SAP)	Submit ABAP jobs, monitor completion via RFC	Silent — PENDING if XBP user fails	SAP agent + XBP user with S_XBP_ADM
Oracle EBS	o (Oracle)	Submit concurrent programs, monitor request ID	Partial — tracks submission, not execution	Oracle EBS agent installed
Oracle Database (sqlplus)	CMD (sqlplus)	Run SQL scripts, call stored procs	Broken — sqlplus returns 0 on errors	sqlplus client + wrapper script
Oracle Database (wrapper)	CMD (custom)	Run SQL with error checking	Full — exits non-zero on ORA-	Wrapper script + AutoSys std_out capture

🎯 Key Takeaways

SAP jobs (job_type: s) need XBP user with S_XBP_ADM. Locked user = PENDING forever. No error in AutoSys.
sqlplus wrapper is MANDATORY. Never call sqlplus directly. Check output for ORA- patterns and exit non-zero.
Oracle EBS job_type: 'o' tracks submission, not execution. Check concurrent manager logs separately.
Add validation jobs after every ERP call. Verify row counts, business keys, and completion statuses.
Capture stdout/stderr for all ERP integration jobs. That's where the real errors live.
Cross-system failures cascade silently. Each integration point needs independent error detection.

⚠ Common Mistakes to Avoid

✕Calling sqlplus directly without error checking wrapper

Symptom

AutoSys shows SUCCESS, but database didn't change. SQL errors are printed to stdout/stderr but ignored. Data inconsistency propagates for days or months.

Fix

Always wrap sqlplus in a shell script that grep's for ORA- and SP2- patterns. Make the wrapper exit non-zero on any database error. Enforce wrapper usage in code review.

✕Not coordinating SAP XBP user lifecycle with Basis team

Symptom

SAP jobs suddenly stop running. AutoSys shows PENDING. No errors in event_demon.log. The issue is an expired password or locked XBP user in SAP.

Fix

Set XBP user password to never expire (secure password with rotation via credential manager). Add monthly check with Basis team. Monitor PENDING duration as alert trigger.

✕Assuming Oracle EBS concurrent program success means business logic succeeded

Symptom

AutoSys shows SUCCESS. Concurrent program submitted. The program executed but failed internally (missing data, permission error). AutoSys has no visibility.

Fix

Add post-execution validation job that checks for expected outcomes in Oracle EBS (e.g., check request log for 'Completed with errors', verify output tables updated).

✕Not capturing sqlplus stdout/stderr in AutoSys files

Symptom

Job fails or succeeds incorrectly. No output to review. Engineer has to rerun job manually to see the error.

Fix

Always set std_out_file and std_err_file in JIL for sqlplus jobs. Capture everything. These files are the first place to look for ORA- errors.

✕Chaining SAP job directly after Oracle job without validation

Symptom

Oracle job 'succeeded' but processed 0 rows due to upstream empty file. SAP runs anyway on empty data set. Business process continues with missing data.

Fix

Add a validation job between Oracle and SAP that checks row count or business key existence. Only trigger SAP if validation passes.

Interview Questions on This Topic

QHow does AutoSys integrate with SAP?Mid-levelReveal
AutoSys integrates with SAP R/3 and S/4HANA through the SAP XBP (External Background Processing) interface using job_type: 's' in JIL. A specialised SAP agent on the AutoSys side communicates with SAP via RFC/BAPI calls to submit ABAP background jobs and monitor their completion. Prerequisites: SAP agent installed, XBP user with S_XBP_ADM and S_BTCH_ADM authorisations, RFC destination configured in SAP (SM59). Failure mode: If XBP user password expires or account locks, AutoSys jobs stay PENDING indefinitely with no error in AutoSys logs. Requires SAP Basis team intervention to resolve.
QWhat is the SAP XBP interface?SeniorReveal
XBP (External Background Processing) is an SAP interface that allows external schedulers like AutoSys to submit and monitor background jobs in SAP systems. It consists of function modules (XBP_* functions) exposed via RFC. AutoSys uses XBP to: - Submit ABAP programs with variants - Get job status and completion events - Retrieve spool output and job logs The XBP user requires specific authorisations (S_XBP_ADM for interface access, S_BTCH_ADM for background job management). The RZ11 profile parameter 'bgxbp_allowed' must be set to enable XBP in SAP.
QWhat job type code is used for SAP jobs in JIL?JuniorReveal
job_type: s (lowercase 's') for SAP background jobs. Example JIL snippet: ``insert_job: SAP_MONTH_CLOSE job_type: s sap_server_name: PRDSAP sap_report_name: Z_MONTH_CLOSE sap_report_variant: STANDARD sap_client: 100 machine: sap-agent-server`` Other ERP job types: 'o' for Oracle EBS concurrent programs, 'c' for PeopleSoft (legacy), and standard 'CMD' for database sqlplus calls.
QHow do you call an Oracle stored procedure from AutoSys?Mid-levelReveal
Primary method: CMD job calling sqlplus with a wrapper script. Example: ``bash #!/bin/bash sqlplus -s user/pass@DB <<EOF > sqlplus.out 2>&1 WHENEVER SQLERROR EXIT SQL.SQLCODE; BEGIN my_stored_proc(:param1, :param2); COMMIT; END; / EXIT; EOF if grep -qi 'ORA-' sqlplus.out; then echo "Database error detected" cat sqlplus.out exit 1 fi exit 0`` Critical: sqlplus returns exit code 0 even on SQL errors. Always wrap it with error detection. The wrapper must grep for ORA-, SP2-, PLS- patterns and exit non-zero when found.
QWhat is the gotcha with sqlplus and exit codes in AutoSys?SeniorReveal
sqlplus returns exit code 0 in almost all scenarios — including SQL syntax errors, runtime errors (ORA-), and even when a script fails to parse. It only returns non-zero for fatal errors like connection failure or missing SQL file. This means an AutoSys job calling sqlplus directly will show SUCCESS even when the SQL completely fails. The job log may contain ORA- errors, but AutoSys ignores them. Fix: Never call sqlplus directly. Always wrap it in a shell script that: 1. Captures output to a file 2. Greps for error patterns (ORA-, SP2-, PLS-) 3. Exits 1 if any error pattern found 4. Exits 0 only if no errors AND row count expectations met Additionally, include WHENEVER SQLERROR EXIT SQL.SQLCODE in SQL scripts, but note this only catches runtime errors, not syntax errors.
QHow do you handle cross-system failure cascades in an AutoSys workflow?SeniorReveal
Cross-system workflows (File system → Oracle → SAP → Email) have multiple failure domains. A failure in Oracle shouldn't trigger SAP. A failure in SAP shouldn't trigger the email. Pattern: Insert validation jobs between each integration point: 1. After file load: Verify row count > 0 before triggering Oracle. 2. After Oracle stored procedure: Run SELECT COUNT(*) to confirm data processed. Fail if zero rows. 3. Before SAP job: Check that XBP user is active (via RFC ping). Check that data validation flags are set. 4. After SAP job: Check SM37 in SAP that background job completed without errors (via RFC query). 5. Before email: Verify report generation actually created output. Each validation job should have its own alarm_if_fail and clear documentation. The workflow should stop at the first validation failure, and the alert should pinpoint exactly which system failed and why.

Frequently Asked Questions

How does AutoSys integrate with SAP?

AutoSys integrates with SAP R/3 and S/4HANA through the SAP XBP (External Background Processing) interface. A specialised SAP agent on the AutoSys side communicates with SAP via RFC/BAPI calls to submit ABAP background jobs and monitor their completion.

Job type: 's' in JIL. Prerequisites: SAP agent installed, XBP user with S_XBP_ADM and S_BTCH_ADM authorisations, RFC destination configured in SAP (transaction SM59).

Failure mode: If XBP user password expires, jobs stay PENDING with no AutoSys error. Coordinate user lifecycle with SAP Basis team.

What job type do you use for SAP jobs in AutoSys JIL?

Use job_type: s (lowercase 's') for SAP jobs. This job type requires the SAP agent to be installed on the specified machine and the SAP XBP interface to be configured in the SAP system.

Attributes specific to SAP jobs include: sap_server_name (SAP system ID), sap_report_name (ABAP program name), sap_report_variant (parameter set), sap_client (client number), and optionally sap_external_command for RFC callbacks.

How do you call an Oracle stored procedure from AutoSys?

The simplest method is a CMD job that invokes sqlplus via a wrapper script. Example wrapper:

``bash #!/bin/bash sqlplus -s user/pass@DB @/scripts/call_proc.sql > sqlplus.out 2>&1 if grep -qi 'ORA-' sqlplus.out; then exit 1 fi exit 0 ``

Critical: sqlplus returns exit code 0 even on SQL errors. Never call sqlplus directly. Always wrap it with error detection that checks output for ORA- patterns.

Why does sqlplus exit 0 even when SQL fails?

By design, sqlplus returns exit code 0 for successful parsing and execution attempts, even if SQL statements inside the script fail. It only returns non-zero for fatal errors like cannot connect to database, cannot open SQL file, or out of memory.

This means an AutoSys job calling sqlplus directly will show SUCCESS even when your stored procedure raises ORA-00942 (table not found).

Fix: Add WHENEVER SQLERROR EXIT SQL.SQLCODE to SQL scripts to catch runtime errors. For syntax errors, wrap sqlplus in a shell script that greps the output for error patterns. The wrapper pattern is mandatory for production jobs.

What permissions does the SAP user need for AutoSys integration?

The SAP user (typically a technical Basis user) needs XBP authorisations including: - S_XBP_ADM (XBP Administration — allows external scheduling) - S_BTCH_ADM (Background Processing Administration — allows job submission) - S_RFC (RFC access to XBP function modules)

The exact profile should be set up by your SAP Basis team following SAP Note guidance for XBP. The user should have password never expire (or secure rotation via credential manager) and should be monitored for lock status.

How do you debug an SAP job that stays PENDING in AutoSys?

Step-by-step debugging for PENDING SAP jobs:

Check SAP agent connectivity: autoping -m sap-agent-server. If INACTIVE, agent is down or network blocked.
Check XBP user status in SAP: transaction SUIM → User → Display. Look for locked or expired password.
Check SAP system availability: from agent machine, telnet sap-app-server 3300 (default RFC port).
Check SAP job scheduling log: In SAP transaction SM37, look for the scheduled background job. If it's not there, XBP submission failed.
Check AutoSys event_demon.log: grep SAP_JOB_NAME $AUTOUSER/out/event_demon.$AUTOSERV. Look for RFC error messages.

Most common issue: XBP user password expired. Work with Basis team to reset and unlock. Add monitoring for PENDING duration > 30 minutes to alert before business impact.

🔥

Naren Founder & Author

Developer and founder of TheCodeForge. I built this site because I was tired of tutorials that explain what to type without explaining why it works. Every article here is written to make concepts actually click.

About Naren Get in touch

Forged with 🔥 at TheCodeForge.io — Where Developers Are Forged