News & Wissen PDF-Formulare in SAP: Tipps, Tricks und Stolpersteine

Im Blogbeitrag „Wissenswertes rund um die Erstellung von SAP Adobe Forms“ haben Sie einen allgemeinen Überblick über die PDF-Erstellung erhalten. In diesem Artikel möchte ich nun einige persönliche Tipps und Erfahrungen an meine Entwickler-Kolleg*innen weitergeben.

PDF-Vorschau in der Transaktion SFP

Welche*r Entwickler*in hat sich nicht schon mal darüber geärgert, jede kleine Änderung am Layout immer wieder ins Testsystem transportieren zu müssen, um sie zu testen? Die neue PDF-Technologie hat hierfür eine super Lösung: PDF-Vorschau in der Transaktion SFP. Hier kann man eine Beispiel-XML hinterlegen, die z. B. aus dem Testsystem kommt, wodurch sich Layout-Anpassungen sehr leicht im Entwicklungssystem testen lassen. Diese XML-Datei kann auf zwei Wegen ermittelt werden:

• Man aktiviert den „sehr ausführlichen Trace“ in der Transaktion SFP unter dem Menüpunkt „Hilfsmittel“ ->  „Einstellungen“; diese Einstellung gilt aber nur temporär für diese Sitzung.

• Man aktiviert den „sehr ausführlichen Trace“ über die Userparameter.

Beide Wege generieren als Ergebnis die XML-Datei, wenn ein PDF-Formular erzeugt wird. Die XML kann aus den Anhängen der Druckansicht gezogen werden. Dazu öffnet man im Adobe Reader die Werkzeugleiste und speichert die Datei „XFD.xml“ aus den Anlagen lokal am Rechner.

Werkzeugliste im Adobe Reader

Anlagen des PDF-Formulars

Diese XML-Datei wird nun im Layout des Formulars als Datendatei in den Formulareigenschaften, Menüpfad „Bearbeiten“ -> „Formulareigenschaften“ -> „Vorschau“, hinterlegt.

Mit dieser Einstellung können die Layout-Änderungen in der PDF-Vorschau getestet werden.

Debuggen der Schnittstelle

Fast jede Fehleranalyse endet irgendwann im Debugger, zumindest aus Entwickler*innen-Sicht. Leider ist das Debuggen eines Formulars nicht ganz so einfach, wie z. B. eines Programms. „Nicht ganz so einfach“ heißt aber nicht unmöglich, man muss nur wissen, wie.

Die elegante Lösung, wie man die Schnittstelle ändern kann, ist der Einsatz von Checkpoint-Gruppen, die über die Transaktion SAAB angelegt werden:

Am Anfang der Schnittstelle, in der Coding-Initialisierung, fügt man folgendes Coding ein, damit der Debugger hier stoppt, wenn die Breakpoints in der Gruppe aktiviert (angehalten) sind:

Falls man die Schnittstelle nicht anpassen kann, da man sich z. B. im Produktivsystem befindet und die Checkpoint-Gruppe nicht vorgesehen ist, können die Breakpoints im generierten Funktionsbaustein des Formulars gesetzt werden. Den Namen des Funktionsbausteins erhält man im jeweiligen System, indem das Formular in der Transaktion SFP getestet wird (F8):

In diesem Funktionsbaustein kann nun in der Transaktion SE37 - wie gewohnt - ein Breakpoint gesetzt werden.

Mehr Informationen und Tipps zum ABAP Debugger erhalten Sie hier.

Scripting

Teilweise sollen einzelne Werte im Formular anders formatiert oder ausgeblendet werden. Hierfür gibt es den Skripteditor. In diesem kann man entweder in der Adobe-eigenen Skriptsprache „FormCalc“ oder in der gängigeren Skriptsprache „JavaScript“ „programmieren“.

Hier zwei Anwendungsbeispiele:

• Nachkommastellen mit 0 auffüllen, z. B. möchte der Kunde immer vier Nachkommastellen (JavaScript)

• Layoutelemente ausblenden, wenn leer (FormCalc)
  Auf der Masterseite muss unten stehender Code ins Ereignis „layout.ready“
  Auf der Designseite muss unten stehender Code ins Ereignis „form.ready“

Bessere Wartbarkeit

Jede*r Entwickler*in hat einen eigenen Programmierstil, so auch in den Formularen. Meine Kolleg*innen und ich haben über die Jahre festgestellt, dass folgende Dinge aber sehr hilfreich sind:

• Teilformulare statt Tabellen
  Wenn man sich ein Standardformular der SAP als Vorlage nimmt, merkt man schnell, dass Tabellen, z. B. Positionsinfos, nicht so einfach um eine weitere Spalte erweitert werden können. Besser ist es, hier mit Teilformularen zur Positionierung und Anordnung der Spalten zu arbeiten. Das ist zwar am Anfang minimal aufwändiger, aber man wird es einem später danken.

• Strukturen statt einzelner Variablen
  Um die Schnittstelle und den Kontext übersichtlich und aufgeräumt zu gestalten, empfiehlt es sich, statt vieler einzelner Variablen, eine Struktur zu schaffen.

• Sprechende Benennungen
  Wie in der allgemeinen Programmierung auch, ist es hilfreich, die Layoutelemente, Variablen, Strukturen und Tabellen sprechend und aussagekräftig zu benennen.
• Kommentare
  Auch wenn es teilweise als lästig angesehen wird, helfen Kommentare für zukünftige Anpassungen und Fehleranalysen.

Gebietsschema erweitern

Im Artikel mit den allgemeinen Informationen zu PDF-Formularen habe ich das Thema Gebietsschema bereits erklärt. Wenn man so ein Schema nun aber erweitern möchte, weil man eine spezielle Kombination aus Sprache-Land hat oder als Tausender-Trenner kein Punkt, sondern ein Semikolon verwendet werden soll, ist der SAP-Hinweis 2696301 sehr hilfreich.

Stolpersteine

Nachfolgend nun noch ein paar Stolpersteine, über die ich in meinen letzten PDF-Formularprojekten gefallen bin und die mich einiges an Zeit und Nerven gekostet haben:

• Teilformulare müssen einen Namen haben, am besten sprechend, da sonst zum Teil die Steuerung bezüglich des Ein- und Ausblendens über den Skripteditor nicht klappt. Wenn nämlich mehrere Teilformulare ohne Namen in der Hierarchie als „(unbekannt – Teilformular)“ gekennzeichnet sind, kommt das System in der Elternzuordnung durcheinander.
• Wird ein Wert nicht angedruckt, obwohl dieser gefüllt ist, und keine Bedingung oder kein Skript es aussteuert, kann es am Layout des Layout-Elements liegen. Wenn das Feld zu niedrig ist, wird der Wert nicht angedruckt, einfach so. Das gleiche Problem gab es auch bereits in den SMARTFORMS Formularen.
• Bei einem Kunden hatte ich einen unerklärlichen Seitenüberlauf. Im Layout war alles richtig eingestellt: Textfluss, Seitenumbrüche zulassen usw. In einzelnen Fällen wurde aber kein Seitenumbruch durchgeführt, sondern der Text „floss“ über das Blatt hinaus. Nach ewigem Suchen und Rücksprache mit SAP konnte es auf die XML-Version zurückgeführt werden, mit der das Formular designed wurde (Version des LiveCycle Designers). Die XML-Version 2.4 verursachte das Problem. Nachdem ich in der XML-Ansicht in der SFP auf XML-Version 2.8 umgestellt habe (hart geändert) lief alles wie gewünscht.
• Spoolaufträge sollten am besten regelmäßig gelöscht werden, am besten per Job. Beim Generieren eines PDF-Formulars werden im Spool-Verzeichnis nämlich drei Dateien abgelegt, die je nach Inhalt des Formulars ziemlich groß sein können. Diese Dateien haben folgende Datentyp-Endungen: .cfg, .pcl und .xfd.
• Texte vom Feldformat „RichText“ werden nicht angezeigt, wenn diese mehrere Leerzeichen hintereinander beinhalten und nur eine Zeile vorhanden ist UND dieser Text im Skripteditor mit „HaseValue“ ausgesteuert wird. Behoben werden kann dieser Fehler mit Hilfe des SAP-Hinweises 2607386.

Fazit

In Sachen PDF-Formulare und LiveCycle Designer gibt es immer noch einige Bugs und man verzweifelt als Entwickler*in auch schon mal, aber es geht durchaus in die richtige Richtung und wir lieben doch alle Herausforderungen.

Ich hoffe, ich konnte Ihnen mit diesen Tipps weiterhelfen und vielleicht sogar die einen oder anderen Nerven schonen.

Stand: 11. März 2022