Transaktion SFP - Schnittstelle

Bei Adobe Forms wird die Schnittstelle separat vom Kontext und von der Formularvorlage erstellt.

In der Transaktion SFP wird sowohl die Schnittstelle definiert als auch das eigentliche Formular mit dem Kontext und der Formularerstellung, die über die integrierte Software "LiveCycle Designer" erfolgt. In diesem Beispiel heißt die Schnittstelle so wie das Formular ZSD_INVOICE. Die Schnittstelle den gleichen Namen zu geben wie das Formular, ist zu empfehlen, wenn eine Schnittstelle lediglich die Daten für ein Formular liefert.

Beziehung zwischen Formular und Schnittstelle

Im Formular wird im Feld "Schnittstelle" der Schnittstellenname eingegeben. Man kann per Doppelklick direkt zur Schnittstelle navigieren.

• Jedes Adobe Forms-Formular muss zwingend genau einer Schnittstelle zugeordet sein.

• Für jedes Formular kann eine Schnittstelle angelegt werden. Aber mehrere Formulare können auch auf die gleiche Schnittstelle verweisen.
• Es macht Sinn die gleiche Schnittstelle bei mehreren Formularen zu verwenden, wenn die benötigten Daten der Formulare sehr ähnlich sind, wie z. B. Daten einer Bestellung, eines Kundenauftrages, einer Lieferung, eines Kontraktes oder einer Rechnung. Es werden dann alle benötigten Daten in der Schnittstelle für alle Formulare geliefert. Die jeweiligen Formulare verwenden dann im Kontext nur die Daten, die sie für das spezifische Formular benötigen. Eine neuen Schnittstelle sollte angelegt werden, wenn ein Formular sehr spezielle Daten benötigt, die es bei anderen Adobe Forms-Formularen nicht ähnlich gibt.

Schnittstellenarten

XML-Schnittstelle

• Die XML-Schnittstelle referenziert direkt auf eine XML-Struktur. Sie wird benötigt, wenn ein Adobe Forms Formular über Web-Dynpro eingebunden wird. Hier muss man beachten, dass in diesem Fall der Kontext des Formulars nicht zur Verfügung steht. Alle Daten, die über das Formular ausgegeben werden, müssen über die Schnittstelle versorgt werden.

Smart Forms-Schnittstelle

• Die Smart Forms-Schnittstelle in Adobe Forms hat die gleiche Schnittstelle wie ein Smart Forms-Formular und wird gewöhnlich nur verwendet, wenn ein Smart Forms in ein Adobe Forms Formular migriert wird.

Data-Dictionary-Schnittstelle

• Die häufigste Schnittstelle ist die Data-Dictionary-Schnittstelle und sie wird hier erläutert.

Einstiegstransaktion SFP

Schnittstelle

Unter dem Ordner "Formularschnittstelle" gibt es

• Import
• Export
• Ausnahmen

Die Typisierung lässt sich wie in SAP üblich per Doppelklick anzeigen.

Importschnittstelle

Jede Schnittstelle hat zwingend den Importparameter /1BCDWB/DOCPARAMS vom Typ SFPDOCPARAMS.

Hier im Beispiel eines Rechnungformulars stehen die betriebswirtschaftlichen Daten in dem Parameter BIL_PRT_COM, was typisiert ist als tiefe Struktur INVOICE_S_PRT_INTERFACE.

Die Importdaten dürfen (wie alle Importparameter von Funktionsbausteinen) normal nicht in der Initialisierungsroutine verändert werden. Sonst führt dies zu einem Laufzeitfehler.

Allerdings ist es doch möglich Werte von einem Importparameter zu ändern, wenn ein Importparameter mit dem Attribut "Wertübergabe" versehen wird. In diesem Fall wird der Wert des Importparameters nicht als Referenz dem Funktionsbaustein übergeben, sondern es findet eine Kopie des Parameters vom aufrufenden Programm zum Funktionsbaustein statt. Dann lässt sich auch der Wert verändern und es gibt keinen Laufzeitfehler.

Hier wurde beim Importparameter IT_FPAYP die Wertübergabe aktiviert und wird dann im Coding der Schnittstelle unter einer bestimmten Datenkonstellation geringfüg verändert.

Normal sollte darauf verzichtet werden einen Importparameter zu verändern. Aber es kann einem viel Arbeit sparen, wenn z. B. ein Importparameter aus einem Standard-Druckprogramm kommt und man dann ohne Änderung des Importparameters aufwendiges Ummappen zu einer globalen Variable vornehmen müsste, und ggf. die Felder im LiveCycle Designer neu binden müsste.

Die Parameter der Importschnittstelle können auch um weitere Parameter ergänzt werden, wie im folgenden Anwendungsfall mit dem Parameter IS_NAST.

Zu beachten ist, dass für die Importparameter die maximale Länge des Vorschlagswertes lediglich 21 Zeichen hat.

Exportschnittstelle

Die Parameter der Exportschnittstelle sind vorgegeben und können nicht um weitere Parameter ergänzt werden und werden von der Laufzeitumgebung gefüllt. Der wichtigste Exportparameter ist „PDF“, der das generierte PDF enthält und manchmal benötigt wird, um z. B. das PDF per Mail zu verschicken oder in der IS-U Druck-Workbench an mehrere Belege zu archivieren.

Der Ausgabeparameter /1BCDWB/FORMOUTPUT hat die Struktur FPFORMOUTPUT.

• PDF = Enthält das erzeugte PDF
• PDL = Enthält das erzeugte PDL
• XML
• PAGES = Anzahl der Seiten des PDF
• LANGU = Ausgabesprache des Formulars

Ausnahmen

Auch die Ausnahmen dürfen nicht manuell ausgelöst werden, sondern werden lediglich über die Laufzeitumgebung aufgerufen.

Globale Definitionen

Hier werden Variablen definiert, die über die Daten der Schnittstelle hinaus Daten speichern.

Es gibt

• Globale Daten (Variablen)
• Typen
• Feldsymbole

Coding Initialisierung

• Werden im Formular zusätzliche Daten benötigt von der Datenbank, dann können Sie unter dem Ordner "Coding Initialisierung" mit einer Import- und Exportschnittstelle codiert werden. Oftmals werden die gelesenen Daten dann in globale Variablen der Transaktion SFP abgelegt.
• Es hat jedoch deutliche Einschränkungen in der Initialisierungsroutine Coding zu schreiben. Findet man umfangreiches Coding in der Initialisierungsroutine vor, sollte man dieses Coding ins Druckprogramm verlagern.

Einschränkungen Funktionalität

• Es ist deutlich unkomfortabler in der Initialisierungsroutine der SFP-Schnittstelle mit Coding zu arbeiten im Vergleich zu Form-Routinen/Methoden in Programmen, Funktionsbausteinen oder Klassen. In der SFP-Initialisierungsroutine steht vollständig gültiges ABAP, aber das Framework ist eingeschränkt. Es gibt weder Vorwärtsnavigation im Codingfenster, Verwendungsnachweis, die Neuanlage einer Form-Routine mit Doppelklick und vieles mehr.
• Ein weiterer Nachteil ist auch nicht gleich offensichtlich. Man kann zwar aus dem Initialisierungsfenster Funktionsbausteine oder globale Methoden aufrufen und nutzen, aber im Verwendungsnachweis des Funktionsbausteins, bzw. der Methode wird die SFP-Schnittstelle nicht angezeigt. Das kann bei kundeneigenen Funktionsbausteinen oder Methoden eine Gefahrenquelle sein. Der Entwickler prüft möglicherweise die Verwendung einer Methode und es wird keine Verwendung angezeigt und löscht dann mit gutem Gewissen die Methode oder benennt sie um. Die Formularausgabe wird dann im Produktiv mit einem Laufzeitfehler beendet, weil der Funktionsbaustein zum Formular nun einen Syntaxfehler hat, da der Aufruf dieser Methode auf einen nicht mehr vorhandene Methode trifft.
• Es ist zu empfehlen in die Initialisierungsroutine nur wenig Coding zu schreiben und ggf. umfangreiches Coding in der SFP-Schnittstelle in das Druckprogramm zu verlagern.

Verlagerung Coding Initialisierungsroutine ins Druckprogramm

• Findet man viel Coding in der Initialisierungsroutine vor, sollte man sich die Zeit nehmen dieses Coding ins Drucksprogramm zu verlagern, auch wenn es für den Fachbereich keinen zunächst sichtbaren Nutzen hat. Aber Coding im Druckprogramm ist wesentlich leichter zu entwickeln und zu warten als Coding in der Initialisierungsroutine der SFP Schnittstelle.
• Wenn man umfangreiches Coding verlagert, sollte man immer eine Version von der SFP-Schnittstelle ziehen vor der Verlagerung. So kann man notfalls immer noch zu diesem Stand zurückkehren. Zusätzlich sollte man ein Backup von der SFP-Schnittstelle und vom Formular machen. So kann man in die Kopie vom Formular die referenzierende Kopie der SFP-Schnittstelle eintragen und so einen direkten Vergleich des Codings/der Formularausgabe im alten Stand und im neuen Stand durchführen. Die Backups vom Formular und der SFP-Schnittstelle kann man nach Produktivtransport vielleicht noch einnen Monat bestehen lassen und wenn man sicher, dass beim Transfer des Codings keine Fehler gemacht wurden, kann man die Backups löschen.
• Werden globale Variablen in der SFP-Schnittstelle gefüllt, kann man zunächst diese globalen Variablen bestehen lassen, aber sie nach der Umstellung aus den Übergabeparametern der SFP-Schnittstelle füllen. So braucht man nicht das Formular ändern, weil das Formular weiterhin auf die gleichen Variablen referenziert und man hat eine potentielle Fehlerquelle weniger.

Form-Routinen

• In den Form-Routinen kann das Coding strukturiert werden, um das Fenster mit der Initialisierung nicht unübersichtlich werden zu lassen, sofern viel Coding dort geschrieben wurde.
• Meist sollten Form-Routinen in der SFP Schnittstelle aber ungenutzt bleiben, da umfangreiches Coding besser im Druckprogramm steht.

Schnittstellen als Kommentare einfügen

• Sehr empfehlenswert ist es die wichtigsten genutzten Importparameter als Kommentar einzufügen. Sie lassen sich mit einem Doppelklick auf den Kommentar im Debugger zur Anzeige bringen. Man spart das Nachschauen in der Schnittstelle, was die wichtigsten Parameter sind

 " BIL_PRT_COM
 " BIL_PRT_COM-HEAD_DETAIL-VBDKR
 " BIL_PRT_COM-HEAD_DETAIL

Form-Routine %GLOBAL_INIT

• In dem Funktionsbaustein generiert SAP genau wie bei Smart Forms eine Formroutine "%GLOBAL_INIT", wo man einen Breakpoint setzen kann und anschließend im Debugger die Initialisierungsroutine der Schnittstelle angesprungen wird.
• Man kann in dem Code der Form-Routine des Funktionsbausteins einen dynamischen Breakpoint setzen, ohne einen Breakpoint hart ins Coding schreiben zu müssen über "break-point" oder "break <benutzername>" oder den Breakpoint in den generierten Funktionsbaustein setzen zu müssen.

  PERFORM %GLOBAL_INIT.

Literatur

• SAP Interactive Forms by Adobe, von Jürgen Hauser, Andreas Deutesfeld, Stephan Rehmann, Thomas Szücs und Philipp Thun, 2. Auflage, S. 122ff.