The setup
My organization performs periodical inspection (audit) of NWA installations. During inspection of ADS instance (Adobe Document Services) the following case was discovered. Every time a PDF form was generated by request from S/4HANA a warning entry in system logs was generated:
$$$/com/adobe/document/XMLForm/msg.XFA=[30923] Invalid version: The current version of the XFA template model exceeds the capability of Acrobat / Adobe Reader 7.0.5.Followed by the following 54 identical warning messages:
$$$/com/adobe/document/XMLForm/msg.XFA=[30923] Invalid version: rid is not a valid attribute of text for the target version of the document.The issue was linked to a mismatch of default ADS configuration and PDF print forms (XDP forms by Adobe). Below is the my journey to fix inconsistency between ADS configuration and S4/HANA print forms.
Every log message has a reason
Before we begin we need to be familiar with PDF versioning and Reader compatibility schema (helpful source) in order to better understand ADS configuration settings and the issue we were facing.
| PDF version | Compatible Adobe Reader | Release year |
| 1.6 | 7.0 | 2004 |
| 1.65 | 7.0.5 | 2005 |
| 1.7 | 8.0 | 2006 |
| 1.7 extension level 1 | 8.1 | 2008 |
| 1.7 extension level 3 | 9.0 | 2008 |
| 1.7 extension level 5 | 9.1 | 2009 |
| 1.7 extension level 6 | 9.1 | 2009 |
| 1.7 extension level 8 | 10 (X) | 2011 |
Each print form is represented in Adobe XML Form (XDP) file format that is an XML-based description of the print form. Every form Is designed with specific set of features in mind so it bears target PDF version inside which supports those set features. An example below is a SAP form created with Adobe LiveCycle Designer 9.0.
Contents of XDP file
Each print form is created and edited with specialized Adobe LiveCycle Designer software. This software package is distributed by SAP and can be downloaded from SAP Software Center. Latest available release as of the time of writing is Adobe LiveCycle Designer 11.0 PL25 (last updated 24.05.2023). However if you create a new form using Designer 11.0 you will face an issue that XML Form can only be created compatible with Adobe Reader 9.0 or higher.
List of target versions in Adobe Designer 11.0
If you open a print form created for Adobe Reader 8.0 or lower then LiveCycle Designer 11.0 will show a warning message and will update the form to a new target version.
LiveCycle Designer warning when opening older XDP files
This means that using latest software from Adobe distributed by SAP it is not possible to create Adobe XML Form compatible with Reader 8 or lower.
We decided to fix discrepancy by aligning our ADS server configuration to match Adobe Designer 11.0 compatibility levels. This way all the features form developer decided to use inside XDP form template they would work as expected.
Finding a path to success
ADS instance was configured with default (out-of-the-box) parameters. That is with default configuration of producing PDF version 1.65. This version of PDF is compatible with Acrobat Reader 7.0.5 or higher. There is a way to change ADS configuration to higher version as described in official SAP documentation. The problem is that it is limited to PDF version 1.7 (Reader 8.0). No mention of upgrading to higher PDF version.
PDF document properties when vesion = 1.7 is used
Since ADS component is basically a wrapper to Adobe XML Forms library I also looked through official Adobe documentation. Official Adobe documentation did not describe the ways to set up higher PDF version.
Target value was in the end deduced by looking at XDP form which has configuration options similar (in the same namespace) as those described in ADS configuration file.
Version info for XDP file version 1.7 extension level 3
We finally settled on version 1.7 and extension level 5 (Reader 9.1). This configuration was applied to ADS server in test environment. Unit tests were performed on some print forms without any visible problems with rendering. These tests were performed by developers only since it was only a technical update without any changed to business logic of the source system. Generated PDF document's properties also confirmed that correct version was applied to the PDF:
PDF document properties after setting ADs version 1.7 extension level 5
Also we checked NWA log file, error messages about PDF version mismatch were missing. So we decided to deploy this change to production environment.
First time a failure
Deploying ADS setting without proper regression testing was a big mistake. Next morning incidents were coming in concerning PDF print forms . Some users were experiencing issues with some of the print forms. Examples of the problems are available below:
Target (expected) print form
Broken form -- most of the static text is missing
Broken form -- PDF viewer update required
Since this issue affected everyday business operations we rolled ADS configuration back. Further study of rendering issue was necessary.
We should have a talk
In the aftermath of this change we consulted with functional teams whose users were facing this issue. We tried to pin-point the source of the problem. Functional teams highlighted that this issue affected editable PDF forms only. Non-editable forms (even same forms in non-editable mode) for the same users were working without any issues.
We developed a test program to verify which options during ADS call from S/4HANA were causing the issue. Two possibly relevant options in Form Processing calls stood out: FILLABLE and DYNAMIC.
PDF render options
Available options for DYNAMIC attribute
Available options for FILLABLE attribute
We rendered some editable forms with all combinations of these two parameters. Below are our findings.
Setting parameter DYNAMIC was the reason for the issue. Issue is not present only if you use Adobe Reader to open the PDF. Using web-based PDF viewer (for example, Chrome built-in viewer) will result in errors as described above. Using DYNAMIC with specific value of FILLABLE (for example, value X) will result in PDF with a message to update to newest PDF reader, as shown above.
Setting ADS configuration to PDF 1.7+ version made the problem visible when ABAP programs were using print forms with parameter DYNAMIC = X. When ADS uses PDF 1.6 version then option DYNAMIC = X is ignored by ADS server and issue does not present itself.
Interactive or dynamic PDF forms -- aren't they the same?
Interactive PDF forms are the forms which give limited modification capability to end-user -- usually there are empty areas which can be manually filled in by the user.
Dynamic forms on the other hand will force print form to be rendered on client side (for example, browser, Adobe Reader) instead of server side (ADS). Detailed list of differences between static and dynamic PDF forms is outlined in in an old Adobe document Understanding the Differences Between Static and Dynamic PDF Forms. Also dynamic PDF forms (also called XFA forms) are not supported by default in Chromium browsers (Chrome, Edge, Opera, Firefox). Rendering such forms requires installing and enabling special Adobe plugin.
Given our business requirements and PDF use cases we were convinced that DYNAMIC = X should not be set for all editable PDF forms. This way PDF files can be edited with any PDF reader including Edge browser. The last one is important going forward since Microsoft Edge can be enabled in SAP GUI as default browser control. Setting Edge as browser control will force PDF files to be displayed using built-in PDF viewer instead of Adobe Reader.
SAP GUI Browser Control options
Second time a blast
We found all customer developments which included editable PDF forms. All of them were updated to remove DYNAMIC attribute from the code leaving only FILLABLE attribute as-is.
Changed done to customer code
Also we discovered some SAP-provided reports in Russia localization package (reports J_3RF_CORRINV_A, J_3RF_INV_A) which were used in our solution. These reports have the same mistake of setting DYNAMIC = X attribute as well as FILLABLE when "editable" option was requested by end-user.
Error in SAP code while setting both FILLABLE and DYNAMIC to make print form editable
There are no SAP notes to fix the issue, and we had no time to wait for a note to be released. So we fixed the issue ourselves directly.
Manual correction done to SAP print form in S/4HANA
After applying all the changes to SAP and customer code thorough unit testing and regression testing were performed. Functional teams were involved in developing test scenarios and performing tests themselves. Print forms were tested with target ADS configuration (1.7 extension level 5) and legacy ADS configuration (1.65) to ensure they can be deployed to production system ahead of ADS configuration change.
Once all the forms were updated in production environment our BASIS team changed ADS configuration to use target PDF version. No further issues with PDF output were registered.
Success!
Consequences
As the result of this changes to ADS configuration those warning messages "The current version of the XFA template model exceeds the capability of Adobe Reader" and "rid is not a valid attribute" are now missing from ADS logs. Also overall number of ADS warning messages dropped tenfold once the change was implemented.
Comparison between two business days: number of warning log entries BEFORE and AFTER ADS configuration changes
Conclusion
As closing statement I would recommend changing your ADS configuration in order to align ADS and Adobe Designer capabilities in your organization. You will:
- benefit from all PDF features as supported by Adobe Designer
- PDF rendering will be consistent between Designer (design-time) and ADS (run-time)
- less trash log records will be written to ADS logs.
During your implementation project please mind the DYNAMIC attribute of PDF forms, which may requires fixes to be applied. Also prepare for proper testing with functional teams upfront. Collect PDF forms usage statistics in production environment as outlined in Note 2714231 --- this will enable you to accurately outline the scope of print forms to be tested and fixed.
Good luck!
- SAP Managed Tags:
