Architektur Formularwesen

Siehe Kategorie:Formularwesen Architektur.

Formularwesen ist komplex und erfordert viel Zeit bei umfangreichen Formularen, bis diese perfekt ausgegeben werden.

Es gibt aber auch ein paar grundlegende Entscheidungen bezüglich der Softwarearchitektur der Formulare, um die Formularentwicklung und Wartung stark zu vereinfachen, fehlerrobuster und kostengünstiger zu gestalten.

Diese Techniken haben sich über 10 Jahre in Formularprojekten herauskristallisiert.

Adressaufbereitung

Immer wieder sieht man es in der Praxis, dass eine Adresse direkt im Formular in der Form ausgegeben wird.

<variable_name1>
<variable_name2>
<variable_strasse_hausnummer>
<variable_plz> <variable_ort>

• Das ist fast nie zu empfehlen. Sowohl in SAPscript, als auch in Smart Forms und Adobe Forms gibt es spezielle Adressaufbereitungsroutinen, die genutzt werden können.
• Diese Adressaufbereitungsroutinen nutzen den SAP-Standardfunktionsbaustein ADDRESS_INTO_PRINTFORM. Diesem Funktionsbaustein gibt man neben der Adressnummer fast nur die Anzahl der Zeilen mit, mit denen der Adressbaustein auskommen soll - und dann gibt der Funktionsbaustein die Adresse in verschieden aufbereiteten Formaten wieder zurück.
• Meist wird direkt im Formular ein Adressknoten genutzt, der die Adresse direkt auf dem Formular ausgibt. Dies berücksichtigt dann auch alle länderspezifischen Besonderheiten, um die sich der Formularentwickler dann nicht mehr kümmern muss. Dieser Adressknoten kommt weitgehend mit der Adressnummer aus von der auszugebenen Adresse.
• Für die Anzahl der maximalen Adresszeilen hat sich die Zahl 7 bewährt. Minimal sollten 4 Zeilen vorgesehen werden.
• Der Funktionsbaustein ADDRESS_INTO_PRINTFORM kann auch durch Customizing und eine Kundenerweiterung angepasst werden.

Dynamische Breakpoints (Checkpoint-Gruppen)

• Als Formularentwickler wird man sehr häufig die Datenselektion im Rahmenprogramm debuggen. Sehr praktisch und schnell gemacht ist es, wenn man direkt vor jedem Formularaufruf (oder bei Adobe Forms in der Schnittstelle SFP) einen dynamischen Breakpoint, bzw. eine Checkpoint-Gruppe setzt mit Hilfe der Transaktion SAAB. Hier kann man auch immer den gleichen Namen verwenden, da ein Formular in aller Regel genau ein Rahmenprogramm mit dem Formularaufruf hat.
• In der Transaktion SAAB wird der Breakpoint angelegt. Er heißt hier Checkpoint-Gruppe, weil die Checkpoint-Gruppe nicht nur dynamische Breakpoints anlegen kann, sondern auch Variablen protokollieren und Assertions im Coding prüfen kann. Hier wird jedoch nur der dynamische Breakpoint benötigt.
• Hier wird in der Transaktion die Checkpoint-Gruppe mit dem Namen Z_TEST angelegt.
• Der dynamische Breakpoint wird im Coding angesprochen mit

break-point id ztest.

• Der dynamische Breakpoint kann in jedem System jeweils mit der Gültigkeit für einen Tag (Default) oder länger aktiviert werden.
• Ebenso praktisch kann es sein, wenn z. B. in jeder Adobe Forms-Schnittstelle SFP in der Initialisierungsroutine ein dynamischer Breakpoint eingefügt wird. Auch hier gibt es sehr häufig Debuggingbedarf.
• So spart man sich das Heraussuchen der relevanten Schnittstelle/Rahmenprogramm und kann den dynamischen Breakpoint auch jederzeit über die Transaktion SAAB wieder deaktivieren.

Formulartechnologie für neue Formulare

• SAPscript-Formulare sollten neu nicht mehr erstellt werden. Die Formulare sind gerade im Zusammenspiel Druckprogramm und Formulare schwer zu warten und oftmals werden SAP-Entwickler diese alte Technologie nicht mehr kennen.
• Smart Forms-Formulare sind einfacher zu erstellen als Adobe Forms-Formulare, wenn der Formularentwickler wenig oder keine Kenntnisse im Adobe LiveCycle Designer hat. Der Adobe LiveCycle Designer ist in Adobe Forms für die Layoutgestaltung verantwortlich ist. Er ist sehr komplex und folgt keinen SAP-Standards. Er bietet mächtigere Möglichkeiten als Smart Forms, aber erfordert viel Zeit alle Feinheiten dieses Tools zu lernen. Treten aufgrund der Arbeit mit dem Adobe LiveCycle Designer Effekte auf, die sich der SAP-Entwickler nicht erklären kann, ist die Fehlersuche schwierig. Das Rendering der Formulare lässt sich nicht debuggen. Innerhalb vom LiveCycle Designer kann man im Coding auch nicht mit ABAP arbeiten, sondern mit FormCalc oder JavaScript, da der LiveCycle Designer unabhängig von SAP entwickelt wurde und letztlich ein Windows-Programm ist, was lediglich in SAP eingebettet ist. Kennt man den LiveCycle Designer sehr gut und kann auch mit FormCalc und JavaScript fortgeschrieben programmieren, kann man mit Adobe Forms die gleiche Entwicklungsgeschwindigkeit wie unter Smart Forms erreichen.
• Adobe Forms ist als Formulartechnologie auch alternativlos, wenn man Formulare interaktiv haben möchte. Diese Funktion bieten SAPscript und Smart Forms nicht.
• Mit Adobe Forms setzt man auch auf die neueste Formulartechnogie von SAP/Adobe auf und eine zunehmende Anzahl von Formularen stellt SAP auch intern auf diese Formulartechnologie um.

Übersichtsliste Formulare

• Bei der Formularentwicklung gibt es viele relevante Entwicklungsobjekte und es ist eine herausfordernde Aufgabe hier die Übersicht zu behalten. Eine konsequent gepflegte Liste in einer Tabellenkalkulation ist essentiell.
• Tabellenliste Formulare

Nutzung Netzlaufwerk/Contentmanagementsystem zur Dateiablage

• Zentrale Dokumente sollten auf einem Netzlaufwerk abgelegt werden, wo sowohl die Keyuser, das Projektmanagement als auch die Formularentwickler Zugriff haben. Alternativ kann auch ein Wiki oder ein anderes Contentmanagementsystem genutzt werden, auf die alle Verantwortlichen Zugriff habenb.
• Für jedes Formular sollte es eine Formularvorlage geben, die in Abstimmung zwischen dem Fachbereich, dem Projektmanagement und den verantwortlichen Formularentwicklern erstellt wurde.
• Im direkten Vergleich der Formulare werden Inkonsistenzen leichter auffallen, als wenn es keine Formularvorlagen gibt oder sie nicht an zentraler Stelle gespeichert sind.

Formularvorlage und Standards

• Es ist dringend empfehlenswert bei allen Formularen Standards einzuhalten, wie z. B.
  • Maße für Abstand vom linken Rand, oberen Rand, rechten Rand, unteren Rand, Position Adresse, Position Infobereich, Position Logo, Position Fußzeile, ..
  • Gleiche Adressaufbereitung über zentrale Adressaufbereitung
  • Benennung von Variablen und UI-Elementen
  • Nutzung von gemeinsam genutzten Textbausteinen
• Es sollte ein Formular bestimmt werden, was als Vorlage für die anderen Formulare dient. Wenn eine Änderung an allen Formularen nötig ist, sollte zuerst dieses Formular angepasst werden. Man sollte ein Formular nehmen, was nicht ständig durch Änderungsaufträge gesperrt ist und übersichtlich ist. Es sollten hier nicht komplexe Formular wie Rechnung oder Bestellung als Formularvorlage dienen. Besser sind übersichtlichere Formulare, die selten geändert werden, wie z. B. das Mahnungsformular.
• Nutzen die Formulare viele gemeinsame Standards, wird die Erstellung eines neuen Formulars deutlich beschleunigt durch copy&paste von der Mustervorlage; es mindert Fehler, da die Komplexität der Formulare vermindert wird und die Entwickler brauchen weniger Zeit, um sich in andere Formulare einzudenken.
• Haben sich Standards für die SAP-Entwicklung (Ausgabe von Logo/Grafiken, Kopfbereich, Fußbereich, Info/Impressum, Adressermittlung, Seitenabstände, etc.) herausgebildet, sollten diesen dokumentiert werden und von den Formularentwicklern genutzt und weiter gepflegt werden.
• Stellt man bei der Arbeit an Formularen fest, dass sie z. T. die Standards nicht einhalten, sollte man bei jeder Änderung an diesen Formularen sie auch ein wenig näher an die Standards bringen. Hier sollte man vorsichtig sein, da es manchmal gute Gründe gibt warum bestimmte Formulare einen Sonderweg verfolgen. Aber diese Vorgehensweise folgt dem Grundsatz einen Code immer etwas besser zurückzulassen als man ihn vorgefunden hat.

Datenselektion über Klassen

• Das Rahmenprogramm besteht mindestens aus der Selektion der betriebswirtschaftlichen Daten für das Formular und die druckspezifische Bestimmung der Druckparameter (Drucker, Spooljob, Archivierung, etc.).
• Einige betriebswirtschaftliche Daten werden für alle Formulare benötigt und andere hängen vom Formular, bzw. vom Anwendungsbereich ab. Die für alle alle Formulare benötigten Daten lassen sich sehr gut in einer zentralen Formularklasse kapseln über die Transaktion Transaktion SE24 (Class Builder).
• Jeder Anwendungsbereich (Rechnung, Bestellung, Lieferung, Kontrakte etc.) bekommt auch eine eigene Klasse, in der die Daten gelesen werden, die für diesen Anwendungsbereich relevant sind. Diese "Anwendungsklasse" kann von der zentralen Formularklasse erben.
• So stehen jeder Anwendungsklasse die spezifischen Methoden der Anwendungsklasse und die allgemeinen Methoden der Formularklasse zur Verfügung. Dies macht die Pflege der Leseroutinen sehr übersichtlich und gut wartbar.

Zentrale Formularklasse

Nutzen einer zentralen Funktionsklasse

• Es bietet sich an alle Funktionen, die in jedem Formular, bzw. den meisten Formularen benötigt werden, in einer zentralen Formularklasse zu kapseln.
• So braucht man eine Funktionalität nur 1 x programmieren und die Formulare beschränken sich auf den Aufruf der jeweiligen Methoden.
• Anpassungen müssen nur an einer Stelle vorgenommen werden und dieses Coding kann sehr gut dokumentiert werden.
• Man sieht durch den Verwendungsnachweis der Methode in welchen Druckprogrammen die Methode verwendet wird. In der SFP Schnitstelle sollten die Methoden nicht aufgerufen werden, da der Verwendungsnachweis diese Verwendung nicht findet und diese Verwendung bzw. später nötige Anpassungen dieses Methodenaufrufs dann vergessen werden kann.

Gefahr der Nutzung einer zentralen Formularklasse

• Das Speichern der Entwicklungsobjekte der Formularklasse (inklusive genutzter Datenelemente, Domänen etc.) sollte man mit besonderer Sorgfalt vornehmen. Wird z. B. eine Methode der Formularklasse in einem Transportauftrag gespeichert, aber eine verwendete Domäne in einem anderen Transportauftrag und es geht dann zuerst der Transport mit der Methode der Formularklasse ins Produktivsystem, wird es zu einem Syntaxfehler in der Formularklasse kommen und einem Returncode 8 beim Transport. Im schlimmsten Fall kann dann kein Formular mehr ausgegeben werden, sofern jedes Formular mindestens eine Methode der zentralen Formularklasse nutzt. Der Versuch der Ausgabe eines solchen Formulars wird mit verbunden mit einem Shortdump die Formularausgabe und das Druckprogramm beenden.
• Kommen solche Fehler vor und es dauert es ein paar Stunden, bis diese Fehler behoben sind, wird es einige Unruhe in die Firma bringen und es könnte dann passieren, dass einem die Nutzung der zentralen Formularklasse verboten wird, um solch einen parallelen Ausfall aller Formulare vorzubeugen. Das wäre dann aus der Sicht der Wartbarkeit der Formulare sehr bedauerlich und sollte unbedingt verhindert werden.

Tipps für die Nutzung einer zentralen Formularklasse

• Man sollte alle Entwicklungsobjekte, die die zentrale Formularklasse betreffen (Definition der Klasse, Implementierungen der Methoden, genutzte Datenelemente, Domänen, Strukturen, Tabellen, ...) in einem separaten Transportauftrag speichern und vor anderen Produktivtransporten (mit Änderungen an Druckprogrammen) ins Produktiv transportieren.
• Bei Transporten mit Änderungen an der zentralen Formularklasse sollte man auf jeden Fall im Büro sein, um mögliche Fehler schnell zu beheben. Es wäre für die Kollegen sehr undankbar, wenn die sich um diesen Fehler kümmern müssten ohne genaue Kenntnisse über die vorgenommenen Änderungen in der Formularklasse.
• Man sollte solche Transporte sehr zeitnah monitoren, ob sie sauber reingelaufen sind und wenn nicht, dann alles andere stehen lassen und sich mit höchster Priorität sofort um die Fehlerbehebung kümmern.
• Nach Möglichkeit sollten Transporte, die die zentrale Formularklasse betreffen am Abend ins Produktivsystem transportiert werden, wenn man zwar selber als Formularentwickler noch im Büro ist, aber nur noch wenige Leute im Produktivsystem arbeiten. Der Transport sollte aber nicht erfolgen, wenn Jobs laufen, die bei einem Fehler in der zentralen Formularklasse zu einem Abbruch der Verarbeitung führen.
• Ist man sich unsicher, ob alle geänderten Methoden und die Definition in einem Transportauftrag sind, kann man die gesamte Klasse transportieren mit dem Entwicklungsobjekt:

Programm-ID = R3TR
Objekttyp   = CLAS
Objektname  = <klassenname>

Beispiele für Methoden in der zentralen Formulareklasse

• Funktionsbausteinaufruf FP_JOB_OPEN
• Funktionsbausteinaufruf FP_JOB_CLOSE
• Funktionsbausteinaufruf FP_FUNCTION_MODULE_NAME
• Füllen Druckparameter (DOCPARAMS)
• Füllen Druckparameter (OUTPUTPARAMS)
• Füllen Teststring zur Anzeige Formular im Testystem
• Füllen NAST_PROTOCOL_UPDATE
• u. a.

Logo

• Eine Grafik kann in Adobe Forms lokal vom PC ins Formular hochgeladen werden und dort "eingebettet" werden. Dies ist allerdings nicht zu empfehlen. Das funktioniert nur, wenn beim Formular lediglich ein Logo verwendet wird. Oft wird in Abhängigkeit vom Buchungskreis auch andere Logos (z. B. Tochterfirmen vom Konzern) verwendet.
• Daher sollte meist die Grafikreferenz dem Formular übergeben werden und das Formular liest sich dann vom Applikationsserver zur Laufzeit die Grafik und stellt sie dar.
• Vorgehensweise bei Adobe Forms.

Migration bestehende Formulare auf neue Formulartechnologien

• Auch wenn es für den Anwender selten sichtbar ist, in welcher Technologie ein Formular erstellt wurde, gibt es sehr große technische Unterschiede zwischen Formularen in den Technologien
  • SAPscript
  • Smart Forms
  • Adobe Interactive Forms
• Der Aufwand ein bestehendes Formular in einer alten Formulartechnologie wie SAPscript auf Smart Forms oder Adobe (Interactive) Forms umzustellen, lohnt sich meist nicht. Der Aufwand ist hoch, fehleranfällig und der spätere Zeitgewinn bei der Pflege bestehender Formulare gering. Die Unterschiede zwischen Smart Forms und Adobe sind dabei deutlich geringer als zwischen SAPsript und Smart Forms und Adobe Forms. Beim Sprung von Smart Forms zu Adobe Forms kann zumindest das Rahmenprogramm weitgehend unverändert bleiben.
• Die meisten Formulare, die über einen längeren Zeitraum produktiv laufen, werden später nur noch selten angepasst. Die Anpassung bestehender Formulare erfordert auch deutlich weniger Kenntnisse als ein komplexes Formular neu zu erstellen.
• Man sollte bestehende Formulare in aller Regel in der Formulartechnologie belassen, in der sie erstellt wurden.
• Eine Ausnahme können hier einfache Formulare sein. Hier ist es ist dann meist empfehlenswert diese Formulare neu zu erstellen. Es könnte auch eine gute Übung für den Formularentwickler sein, der sich z. B. in Adobe Forms einarbeiten will, und bisher nur SAPscript-Kenntnisse hat. Hier ist das Ziel klar definiert das Formular so zu erstellen, dass es die gleichen Ausgaben liefert wie das alte Formular und solange dies nicht abgenommen wurde vom Fachbereich, kann das alte Formular weiter produktiv laufen und steht auch hinterher immer noch als Fallback-Formular zur Verfügung. Diese Idee des Know-how-Gewinns sollte aber nicht bei Formularen wie eine Bestellung oder Rechnung angewendet werden. Hier dürfte der benötigte Zeitaufwand der Umstellung weit die Schätzung übertreffen.
• Der Gedanke ein SAPscript-/Smart Forms-Formular auf Adobe Interactive Forms umzustellen, um 1 oder mehr Felder interaktiv zu haben, ist nachvollziehbar, aber aufgrund des Aufwands bei komplexen Formular aus obigen Gründen sehr kostenintensiv, was selten bezahlt werden wird.

Nomenklatur

• Nomenklatur

Schachtsteuerung

• Schachtsteuerung bei Adobe Forms

Smart Forms -und SAPscript-Stil

• Smart Forms Stil (Style Builder) für Formulare Smart Forms und Adobe Forms
• Standard Smart Forms Stil
• Stilkonflikt bei Einbindung von Standard-Textbausteinen in Adobe Forms
• Textbausteine sind ein zentrales Element von Formularen.
• Das einheitliche Layout von Textbausteinen fällen sehr viel leichter, wenn die Textbausteine den gleichen Stil haben. Im Stil werden v. a. Absatzformate und Zeichenformate definiert.
• Verändert sich z. B. im Corporate Design eine Schriftart, dann ändert man die Schriftart im Stil und sofort wird die neue Schriftart auf alle zugeordneten Textbausteine und die entsprechenden Inhalte auf den Formularen vererbt. Das macht die einheitliche Formatierung von Textbausteinen/Texten sehr viel einfacher, schneller und weniger fehlerträchtig.
• Ein SAPscript-Text wird in der Transaktion SE72 gepflegt.

Schriftarten

• Eine Firma sollte sich bei Ausgabe von Formularen möglichst auf eine Schriftart beschränken.
• Es ist bei der Nutzung von unterschiedlichen Schriftarten für die Tester und Formularentwickler sehr schwer merkbar, an welcher Stelle welche Schriftart auszugeben ist.
• Bewährt haben sich als Standardschriftart Arial und Helvetica.

Textbausteine

• Nur SAPscript-/Standardtextbausteine lassen sich im Produktivsystem vom Anwender ändern. Ist die Möglichkeit der Änderbarkeit im Produktivsystem für die Anwender erforderlich, müssen SAPscript-Textbausteine statt Smart Forms-Textbausteine vorgezogen werden.
• Smart Forms Textbausteine sollten im Allgemeinen bevorzugt werden. Sie sind regulär Transportobjekte und fordern bei der Anlage/beim Ändern einen Transportauftrag an, lassen sich einfacher übersetzen und sind mandantenübergreifend.
• Alle Smart Forms-Textbausteine lassen sich auch über die Tabelle STXFTXT durchsuchen. Das ist sehr praktisch, wenn man den Ausgabetext im Formular sieht und so sehr schnell den/die Textbausteine identifizieren kann über eine einfache Suche in SE16. Die Textbausteine sollten hier konsequent im gleichen Namensraum benannt werden, um so die Suchmenge passend einschränken zu können.
• Es ist auch denkbar für einen Text, der im Formular auszugeben ist, sowohl Smart Forms-Textbausteine als auch SAPscript-Texte vorzusehen. Im Allgemeinen wird ein Smart Forms-Textbaustein erstellt werden, aber er könnte durch eine Customizingtabelle mit einem SAPscript-Text übersteuert werden. Dann hätten die Anwender die Möglichkeit diese Texte im Produktivsystem direkt und zeitnah zu ändern. Im Formular gibt es für diese Alternativen in Smart Forms und Adobe Forms den Knotentyp "Alternative". Es kann im Rahmenprogramm auch der jeweils passende Inhalt vom Smart Forms-Textbaustein oder dem SAPscript-Text ausgelesen werden und in eine dynamische Tabelle gefüllt werden, die dann in Smart Forms oder Adobe Forms ausgegeben wird. Hierdurch würde man sich im Formular die Alternativknoten ersparen und die Leseroutine könnte in einer Methode einer Klasse (oder Funktionsbaustein) gekapselt werden, damit man der Methode nur noch die die Namen des Smart Forms-Textbausteins und/oder des SAPscript-Textes übergeben werden muss, um die Tabelle mit dem dynamischen Text zurückzubekommen.

Textbaustein für Info-Fenster und Fußzeile

• Fast jedes Formular hat einen Infoblock, wo Ansprechpartner, Telefonnummer etc. von der Firma genannt werden. Diese Angaben sind in fast allen Formularen identisch oder sehr ähnlich. Das Gleiche gilt für die Fußzeile, wo häufig Angaben zur Geschäftsführung, Steuernummer und Bankdaten stehen.
• In beiden Fällen bietet es sich an diese Angaben nicht hart im Formular als Text zu codieren, sondern Textbausteine zu verwenden. In diesen Textbausteinen können die Angaben dann direkt erfasst werden, wenn sie für alle Formulare identisch sind, wie z. B. Geschäftsführer der Firma. Unterscheiden Sie sich leicht, wie z. B. Supportnummern von verschiedenen Fachabteilungen, können hier auch Variablen in Textbausteinen genutzt werden.
• Ändert sich nun z. B. ein Geschäftsführer in der Firma, müssen nicht alle Formulare angepasst werden, sondern nur ein Textbaustein und automatisch geben alle Formulare die richtigen Geschäftsführer aus.
• Sind die Unterschiede zwischen einzelnen Formularen doch so deutlich, dass sie keinen gemeinsamen Textbaustein verwenden können, kann hier noch eine Customizingtabelle erstellt werden, die in Abhängigkeit vom Formular den korrekten Textbausteinnamen zurückgibt.
• Für den Kopfbereich des Formulars wird es in aller Regal schwer sein Textbausteine zu verwenden, da hier meist das Logo ausgegeben wird. In einen Textbaustein lassen sich für Smart Forms und Adobe Forms keine Grafiken in Textbausteinen nutzen. Das ist nur für SAPscript-Texte für ein Formular in SAPscript möglich.

Testflag

• Anzeige Test im Formular