Adobe Forms Part 9: ADS Configuration and Troubleshooting
Understand and troubleshoot Adobe Document Services: ADS on SAP NetWeaver Java or the SAP BTP Forms service, the RFC/HTTP destination (ADS / FP ICF DATA <SID ), service user ADSUSER/ADS AGENT, FP TEST 00 and FP CHECK DESTINATION SERVICE, typical errors and traces.
Explanation
📌 KEY POINTS
✅ ADS is a separate rendering service: traditionally on a NetWeaver AS Java, today often the SAP Forms service by Adobe on SAP BTP.
✅ ABAP calls ADS via an HTTP destination (SM59, commonly named ADS); ADS calls back into ABAP via ICF service FP_ICF_DATA_<SID> with a service user.
✅ Test programs: FP_TEST_00 (render a test form), FP_CHECK_DESTINATION_SERVICE (destination check), FP_PDF_TEST_* reports in some releases.
⚠️ When all Adobe outputs fail at once, the cause is almost always ADS connectivity or credentials — not the forms.
━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Parts 1–8 assumed ADS works. This lesson covers the infrastructure you must check when it doesn't.
━━━━━━━━━━━━━━━━━━━━
▶ 1. ARCHITECTURE
- ABAP (driver + generated FM) → HTTP destination "ADS" (SM59 type G) → ADS renders.
- ADS → ABAP callback (ICF service FP_ICF_DATA_<SID>, destination FP_ICF_DATA_<SID> in the Java/BTP side) to fetch form templates/data.
- Users: ADSUSER (on the Java side, used by ABAP to call ADS) and ADS_AGENT (on ABAP, used by ADS for callback) in classic setups.
- BTP Forms service: OAuth-based destination, configured per SAP note/guide for the release.
━━━━━━━━━━━━━━━━━━━━
▶ 2. CHECKS
- SM59 → ADS → Connection test (HTTP 200 / 401 indicates reachability vs credentials).
- FP_TEST_00: generates a test PDF; errors show ADS messages.
- FP_CHECK_DESTINATION_SERVICE: checks destination with/without service.
- SICF: service FP_ICF_DATA_<SID> active.
- SU01: service users not locked, passwords valid.
━━━━━━━━━━━━━━━━━━━━
▶ 3. TYPICAL ERRORS
- "ADS: com.adobe.ProcessingException…" rendering error in layout (script, font) → check with ADS trace.
- HTTP 401/403 → credentials/roles of ADSUSER or OAuth client.
- Connection refused/timeout → host/port, Java stack down, network/firewall.
- SSL errors → certificates in STRUST.
- Printer-specific errors → device type (XDC) not supported.
━━━━━━━━━━━━━━━━━━━━
▶ 4. TRACES AND LOGS
- Trace level in output parameters / SFP settings; ADS trace returned in result.
- Java side logs (NWA) or BTP service logs.
- SM21 / ST22 on ABAP for callback errors.
━━━━━━━━━━━━━━━━━━━━
▶ 5. OPERATIONS
- Monitor ADS availability (daily FP_TEST_00 job or alert).
- Include ADS in system copy and patch checklists (destinations, users, certificates).
━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP
- SM59: test the ADS destination.
- Run FP_TEST_00 and FP_CHECK_DESTINATION_SERVICE.
- Check SICF service FP_ICF_DATA_<SID> and the service users' status.
✅ CHECKPOINT: you can verify the ADS chain and diagnose connectivity and rendering errors.
Code example
* ===== ADS health check (schedule daily, alert on failure) =====REPORT zads_health_check. DATA: lv_fm TYPE rs38l_fnam, ls_outpar TYPE sfpoutputparams, ls_docpar TYPE sfpdocparams, ls_result TYPE fpformoutput. START-OF-SELECTION. ls_outpar-getpdf = 'X'. " render only, no printing ls_outpar-nodialog = 'X'. CALL FUNCTION 'FP_JOB_OPEN' CHANGING ie_outputparams = ls_outpar EXCEPTIONS OTHERS = 1. IF sy-subrc <> 0. MESSAGE 'ADS check: job open failed' TYPE 'E'. ENDIF. TRY. CALL FUNCTION 'FP_FUNCTION_MODULE_NAME' EXPORTING i_name = 'ZAF_HEALTHCHECK' " tiny test form IMPORTING e_funcname = lv_fm. CATCH cx_fp_api_repository cx_fp_api_usage cx_fp_api_internal. MESSAGE 'ADS check: test form missing' TYPE 'E'. ENDTRY. ls_docpar-langu = sy-langu. CALL FUNCTION lv_fm EXPORTING /1bcdwb/docparams = ls_docpar IMPORTING /1bcdwb/formoutput = ls_result EXCEPTIONS OTHERS = 1. IF sy-subrc <> 0 OR ls_result-pdf IS INITIAL. MESSAGE ID sy-msgid TYPE 'E' NUMBER sy-msgno WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4. " job fails -> alert ENDIF. CALL FUNCTION 'FP_JOB_CLOSE' EXCEPTIONS OTHERS = 1. WRITE: / 'ADS OK'. * ===== Manual checks =====* SM59 : destination ADS (HTTP) -> connection test* SICF : FP_ICF_DATA_<SID> active* SU01 : ADS_AGENT (ABAP) / ADSUSER (Java) not locked* STRUST: certificates for HTTPS* Reports: FP_TEST_00, FP_CHECK_DESTINATION_SERVICEReal project scenario
After a QA refresh from production, all Adobe forms in QA failed with HTTP 401. The ADS destination in QA still pointed to the production ADS host with production credentials that QA did not have.
Basis corrected the destination to the QA ADS, reset ADS_AGENT, and added ADS to the post-copy checklist. A daily health-check job now alerts before users notice problems.
Common mistakes
- Debugging forms when ADS is down.
- Locked or expired service users.
- Wrong destination after system copies.
- Missing certificates for HTTPS.
- No ADS monitoring.
Best practices
- Check ADS first when all forms fail.
- Daily health-check job.
- Post-copy and patch checklists include ADS.
- Document destination and users.
- Use traces for rendering errors.
Interview angle
Questions: "What is ADS?", "All Adobe forms fail — what do you check?", "How does ABAP communicate with ADS?"
Strong answer: ADS renders PDFs (NetWeaver Java or BTP Forms service); ABAP calls via HTTP destination ADS, ADS calls back via FP_ICF_DATA_<SID> with service user; checks SM59 test, FP_TEST_00, FP_CHECK_DESTINATION_SERVICE, SICF, user locks, certificates; errors 401 credentials, timeouts connectivity, processing exceptions layout; monitor with health check.
Practice this lesson
Quick check
1. All Adobe forms fail with HTTP 401 after a password policy change. What is the cause?
2. ADS communicates with SAP via:
3. If all Adobe Forms fail suddenly, what should be checked first?
Interview questions
1. All production Adobe forms suddenly failed after months of stable operation. How do you analyse it?
Answer it in your own words first, then compare.
2. All Adobe Forms suddenly fail in production. How would you analyze?
Answer it in your own words first, then compare.
Reference-verified: the steps are checked against official SAP documentation and tutorials, and object and field names in the sample code are checked for consistency. The code has not been compiled or run on an SAP system by ERPClimb. Syntax marked release-dependent varies by SAP release, so check it in your own system.
More lessons in this topic
- Adobe Forms Part 1: What SAP Interactive Forms by Adobe Are
- Adobe Forms Part 10: Migrating Smart Forms to Adobe Forms
- Adobe Forms Part 2: SFP Form Design and Layout Basics
- Adobe Forms Part 3: Print Runs, Interactive Forms and Troubleshooting Overview
- Adobe Forms Part 4: Interface and Context Design
- Adobe Forms Part 5: The Driver Program Pattern
- Adobe Forms Part 6: Tables, Subforms and Repeating Item Data
- Adobe Forms Part 7: Texts, Logos, Barcodes and Images