Architektur

Aus SAP-Wiki
Wechseln zu: Navigation, Suche

Formularwesen ist komplex und erfordert viel Zeit, bis neue Formulare perfekt ausgegeben werden.

Es gibt aber auch ein paar grundlegende Entscheidungen, um sich die Arbeit stark zu vereinfachen.

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. Dem 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.
  • Beim Aufruf des Funktionsbausteins im Rahmenprogramm wird gewöhnlich die Tabelle genutzt, die der Funktionsbaustein zurückgibt und dem Formular übergeben. Häufiger wird aber direkt im Formular ein Adressknoten genutzt, der die Adresse dann 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.
  • Für die Anzahl der maximalen Adresszeilen hat sich die Zahl 7 bewährt.
  • Der Funktionsbaustein ADDRESS_INTO_PRINTFORM kann auch durch eine Customizing und eine Kundenerweiterung angepasst werden.

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.

Klassenvererbung1.JPG

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 sehr schwer zu warten und oftmals werden SAP-Entwickler diese Technologie nicht mehr kennen.
  • Smart Forms-Formulare sind einfacher zu erstellen als Adobe Forms-Formulare. der Adobe LiveCycle Designer, der in Adobe Forms für die Layoutgestaltung verantwortlich ist, ist sehr komplex und folgt keinen SAP-Standards. Es 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 und es kann sehr zeit- und nervenraubend sein aufgrund der Menge der Möglichkeiten im Adobe LiveCycle Designer den entscheidenden Fehler zu finden.
  • Adobe Forms ist als Formulartechnologie jedoch alternativlos, wenn man Formulare interaktiv haben möchte.
  • Mit Adobe Forms setzt man auch auf die neueste Formulartechnogie von SAP/Adobe auf und mehr und mehr Formulare stellt SAP auch intern auf diese Formulartechnologie um.

Liste 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.
  • Liste 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.

  • 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
  • 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.

Nomenklatura

Es sollte über die Formulare hinweg sehr darauf geachtet werden gleiche Dinge auch gleich zu benennen. Es kostet nur Sekunden gleiohe Objekte auch bewußt gleich in den Formular zu benennen, bzw. zu korrigieren, aber je öfter und einheitlicher dies erfolgt, umso mehr kann sich der Entwickler diese Objekte merken und so deutlich schneller die jeweils relevanten Objekte im Formular finden

  • Masterseiten
  • Inhaltsbereiche
  • Seiten
  • UI-Elemente
  • Teilformulare
  • Inhaltsbereiche
  • Kontextelemente
  • Schnittstellenparameter

und in den Programmen

  • Variablen
  • Klassen
  • Methoden
  • Form-Routinen
  • Includes

Schachtsteuerung

  • Der Ausgabeschacht wird über die Masterseite und die zugeordnete Papierart bestimmt. So könnte eine Papierart für einen Schacht eingestellt sein, wo eine Druckvorlage (Firmenlogo, Fußzeile, ..) liegt und eine Papierart für den Ausgabeschacht mit einem rein weißen DIN-A4-Blatt.
  • Es ist einfach, wenn eine Papierart für das gesamte Formular gilt. Werden für ein Formulardruck verschiedene Papierschächte angesteuert, muss es auch verschiedene Masterseiten geben mit der jeweiligen Papierart. Das macht es schon komplizierter als bei lediglich einem Papierschacht.
  • Noch einmal deutlich komplizierter wird es, wenn im Duplex gedruck wird. Das bedeutet, dass eine Masterseite mit einer Druckvorlage beim Überlauf einer Ausgabeseite nicht auf den anderen Papierschacht verweisen darf. Dann würde die Rückseite der Druckvorlage nicht benutzt. Es muss dann schon 3 Masterseiten geben: 1 Masterseite für die Vorderseite (mit Druckvorlage), 1 Masterseite für die Rückseite (mit Druckvorlage) und mindestens eine weitere Masterseite (ohne Druckvorlage). Das bewirkt eine sehr komplizierte Überlaufsteuerung mit Teilformularen auf der 2. Masterseite.
  • Fazit ist, dass es nach Möglichkeit vermieden werden sollte mehrere Papierarten/Schächte in einem Formular zu mischen. Es ist fehlerträchtig und kostet meist viel Zeit und ist auch bei der Pflege oft schwierig zu durchschauen, wo welcher Seitenwechsel erfolgt.
  • Auch die Verwendung von Duplex mag helfen die Papierkosten helfen zu verringern. Es wird aber deutlich die Komplexität des Formulars erhöhen. Daher sollte gut überlegt sein, ob man Duplex für erforderlich hält.

Stil

  • Smart Forms Stil (Style Builder) für Formulare Smart Forms und Adobe Forms
  • Projektbeispiel 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 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.

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 auch nicht mandantenabhängig.
  • 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.

Infoblock1.JPG

Testflag

  • Oft werden die Formularentwickler auf einen Drucker drucken, auf den die Anwender auch Zugriff haben. Häufig sind Mitarbeiter aus dem Fachbereich sowohl produktiv tätig sind, als auch bei der Testunterstützung für die Formularentwickler. Hier kann es passieren, dass ein Anwender z. B. eine Bestellung von einem Test findet und diese in Unkenntnis des Tests an einen Lieferanten schickt. Daher sollte ein Testdruck auch als solches erkennbar sein auf dem Ausdruck.
  • Hier bietet es sich an im Abhängigkeit vom verwendeten SAP-System eine Grafik oder großen Schriftzug "T E S T D R U C K" oder ähnliches auszugeben auf jeder Formularseite in der Nähe des Adressfensters.
  • Nützlich für die SAP-Entwickler wäre es auch, wenn im Testdruck System und Mandant mit ausgegeben werden. Dann fällt bei einem PDF-Anhang vom Fachbereich die Frage weg aus welchem System dieser PDF-Druck stammt. Das System steht in der Systemvariablen SY-SYSID; der Mandant in der Systemvariablen SY-MANDT.
  • Die Ausgabe des Testflags kann in Abhängigkeit von der Systemvariablen SY-SYSID erfolgen. Zum Beispiel "If sy-sysid(1) <> 'P'. Ausgabe .. endif." Es kann dann im Rahmenprogramm in einer zentralen Methode/Funktionsbaustein auf diese Variable abgefragt werden, die jedes Formular aufruft und dann ggf. den Inhalt eines Feldes mit dem Inhalt "T E S T D R U C K (<system>.<mandant>)" füllen.
  • Die Schriftfarbe des Teststrings sollte etwas dezenter als die normale Schriftfarbe sein, damit es beim Test vom eigentlich zu testenden Inhalt nur wenig ablenkt.
  • Der Text für den Testflag sollte aus dem Rahmenprogramm aus einer zentralen Routine den Formularen übergeben werden. So braucht bei einer Änderung des Textes nur diese zentrale Routine angepasst werden, anstatt aller Formulare.

Testflag1.JPG


Hier Ausgabe im Qualitätssystem mit System (SY-SYSID) und Mandant (SY-MANDT).

Testflag3.JPG