Anpassungen 
Beim Abbilden von betriebswirtschaftlichen Anforderungen auf ein ERP-System entstehen viele Standardanwendungen, die von verschiedensten Firmen eingesetzt werden können. Dies bedeutet jedoch nicht automatisch, dass auch das User Interface einer betriebswirtschaftlichen Anwendung immer gleich ist. Abhängig von den sehr unterschiedlichen Faktoren (z.B. die benötigte Funktionalität einer Anwendung, Größe oder Wirtschaftszweig eines Unternehmens) können die Anforderungen an das UI einer Anwendung stark variieren. Andererseits ist es immer häufiger nötig, Benutzern von betriebswirtschaftlichen Anwendungen die Möglichkeit zu geben, das UI, über das sie ihre Arbeit verrichten, eigenständig mitzugestalten.
Anwendungen, die mit Hilfe von Web Dynpro ABAP erstellt werden, können auf unterschiedliche Weise und von unterschiedlichen Zielgruppen angepasst werden. In Web Dynpro ABAP gibt es verschiedene Möglichkeiten, Anwendungen anzupassen:
Eine Industrielösung oder der Kunde kann über das Enhancement-Framework Änderungen – insbesondere Erweiterungen – durchführen, die als modifikationsfreie Programmierung abgespeichert werden.
Weitere Informationen: Modifikationsfreie Erweiterungen
Ein Administrator kann Änderungen am Layout vornehmen und speichern, die für alle Benutzer gelten. Hierzu zählt etwa das Ausblenden oder Vertauschen von Tabellenspalten, das Ändern von Label-Texten, das Setzen von Standardwerten und vieles andere. Er kann auch weitere UI-Elemente hinzufügen, die keine Programmierung benötigen. So kann er beispielsweise das Firmenlogo einblenden oder erklärenden Text hinzufügen.
Dies ist eine Ausprägung der Web-Dynpro-Built-In-Anpassung. Dies ist eine vom Web-Dynpro-Framework bereitgestellte Konfiguration/Customizing.
Der Benutzer kann – falls nicht vom Administrator explizit ausgeschaltet – UI-Elemente ausblenden oder Tabellenspalten vertauschen.
Dies ist eine Ausprägung der Web-Dynpro-Built-In-Anpassung. Dies ist eine vom Web-Dynpro-Framework bereitgestellte Konfiguration/Customizing.
Falls weitere Anpassungsmöglichkeiten benötigt werden, kann in der Component ein Controller als sogenannter Konfigurationscontroller definiert werden, dessen Context die Anpassungsmöglichkeiten enthält. Die Component muss dann die Daten aus dem Konfigurationscontext lesen. Das Befüllen des Contexts geschieht automatisch aus Daten, die über ein generisches Tool (Konfigurationseditor) definiert wurden. Diese Definition wird normalerweise durch SAP vordefiniert (Konfiguration) und durch den Administrator geändert (Customizing). Falls der Benutzer weitere persönliche Einstellungen machen können soll, muss die Benutzungsoberfläche dafür von der Anwendungs-Component zur Verfügung gestellt werden.
Dies ist eine Ausprägung der Component-Defined Anpassung. Dies ist eine von der Component bereitgestellte Konfiguration/Customizing.
Sowohl für die Built-In- wie auch für die Component-Defined Anpassung gibt es drei Layer:
Konfigurationslayer, der von SAP vordefinierte Einstellungen generischer Components enthält
Die Konfiguration wird von Entwicklern durchgeführt.
Customizing-Layer, der Anpassungen durch den Administrator beim Kunden aufnimmt
Das Customizing wird zentral von Administratoren durchgeführt. Hierbei handelt es sich um mandantenweite Anpassungen.
Personalisierungs-Layer, der individuelle Einstellungen jedes einzelnen Benutzers enthält
Die Personalisierung wird von Endbenutzern vorgenommen, die das UI der Anwendung ändern möchten, indem sie beispielsweise Felder ausblenden oder umsortieren.
Anpassungen
Die Daten der Konfiguration werden komplett gespeichert. Bei den anderen Layern werden nur die Änderungen zu den schon existierenden Daten abgespeichert. Dadurch wird erreicht, dass Korrekturen auf Konfigurationslayer auch bis zum Kunden gelangen, selbst wenn der Kunde eigene Anpassungen gemacht hatte. Auf dem Konfigurations- und dem Customizing-Layer können Daten als final gekennzeichnet werden. Das bedeutet, dass diese Daten nicht überschrieben werden dürfen. Selbst wenn die Daten auf einem höheren Layer schon existieren, werden sie nicht berücksichtigt.
Für die Personalisierung steht die Component-Defined Variante hauptsächlich im Rahmen des ALV zur Verfügung. In der Regel bezieht sich die Personalisierung außerhalb des ALV daher fast ausschließlich auf die Web-Dynpro-Built-In Personalisierung.
Des weiteren gibt es das BAdI WD_BADI_DOMODIFYVIEW, das zum Erweiterungsspot WD_BADI gehört und eine zusätzliche Erweiterungsmöglichkeit für die Methode WDDOMODIFYVIEW darstellt.
Hinweis
Die Anpassung von Web-Dynpro-Anwendungen findet immer, die einer Web-Dynpro-Component fast immer zur Design-Zeit statt (einzige Ausnahme hier von ist die Konfiguration einer eingebundenen ALV-Component). Im Gegensatz dazu werden Personalisierung und Customizing immer zur Laufzeit einer Anwendung durchgeführt.
Personalisierung
Im Gegensatz zur Konfiguration ist die Personalisierung eine Funktionalität, die auch dem Benutzer einer Anwendung zur Verfügung steht und ihm die Möglichkeit gibt, die Anwendung an seine persönlichen Bedürfnisse oder Präferenzen anzupassen. Der Rahmen der Variationsmöglichkeiten der Personalisierung ist weniger weit als der der Konfiguration, eine persönliche Einstellung am UI darf niemals die Lauffähigkeit einer Anwendung einschränken. Die Personalisierung einer Anwendung geschieht durch einen Anwender direkt aus der laufenden Anwendung heraus.
Customizing
Es ist möglich, Personalisierungseinstellungen auch einheitlich für größere Benutzergruppen zu pflegen. Ein Systemadministrator kann auf Grund seiner erweiterten Berechtigung Personalisierungseinstellungen bearbeiten, wenn die betreffende Anwendung im Konfigurationsmodus läuft.
Konfiguration
Die Konfiguration von betriebswirtschaftlichen Anwendungen erfolgt in zwei aufeinander folgenden Schritten:
Zunächst werden Konfigurationsdatensätze für einzelne Web-Dynpro-Components angelegt (Component-Konfiguration). Ausdrücklich benötigt werden solche Konfigurationsdatensätze beim Einsatz von generischen Components wie etwa der ALV- oder Pattern-Component. Konfigurationsdaten werden hauptsächlich von Entwicklern erstellt und bearbeitet.
Der nachfolgende Schritt ist die Anwendungskonfiguration: Für eine Anwendung wird eine Haupt-Component angelegt, welche mehrere andere Components verwendet. Jede dieser verwendeten Components wird in einer bestimmten Konfiguration benötigt. Die Anwendungskonfiguration legt fest, welche Component mit welcher Konfiguration für die Anwendung benötigt wird. Auch dieser Schritt wird hauptsächlich von Anwendungsentwicklern durchgeführt werden.
Anwendungs- und Component-Konfigurationsdaten werden mit Hilfe eines Konfigurators (Konfigurationseditor) angelegt und gepflegt.
Anwendungskonfiguration
Die oben beschriebenen Anpassungen werden auf Component-Ebene gemacht und abgespeichert. Es kann für eine Component mehrere Konfigurationen / Customizings / Personalsierungen geben. Um die richtige Component-Anpassung zu definieren, gibt es die Anwendungskonfiguration. Die Anwendungskonfiguration ist ein Entwicklungsobjekt – wird also meist von SAP definiert, und enthält für einige in der Anwendung enthaltene Components die Namen der Component-Konfigurationen. Falls eine Component-Usage nicht statisch spezifiziert wird, sondern nur das Component-Interface statisch festgelegt wurde, sollte in der Anwendungskonfiguration auch die entsprechende Implementierung des Interfaces ausgewählt werden. Des weiteren können Sie in der Anwendungskonfiguration die Werte der Anwendungsparameter festlegen.
Welche Component-Anpassung wird ausgewählt?
Beim Laden einer Component wird getestet, ob es zu der Component Anpassungsdaten gibt (Konfigurations- Customizing- oder Personalisierungsdaten). Hierbei gilt folgende Reihenfolge, welche Daten gelesen werden:
Wird bei der Erzeugung der Component eine Konfigurations-Id mitgegeben, so wird die Anpassung mit dieser Id gelesen.
Sonst: Wenn eine Anwendungskonfiguration existiert, in der für diese Component-Benutzung eine Konfigurations-Id eingetragen ist, wird diese gelesen.
Ansonsten wird aus dem Applikationsnamen und dem Pfad der Component-Usages bis zur aktuellen Usage ein Hash-Wert gebildet, der als Konfigurations-Id genutzt wird, und mit dem die Daten gelesen werden.
Dadurch wird sichergestellt, dass für eine Component, die in zwei verschiedenen Anwendungen genutzt wird, die Anpassungsdaten nur dann gemeinsam genutzt werden, wenn dies explizit gewünscht wird. Nur wenn die Konfigurations-Id für beide Component-Verwendungen gleich ist, werden die Daten gemeinsam genutzt. Ansonsten sind die Anpassungen voneinander unabhängig.
Framework-definierte Anwendungsparameter
Es gibt eine Reihe von Parametern, die an der Anwendung gefüllt werden können, die vom Framework definiert sind, und auch von der Web-Dynpro-Laufzeit verarbeitet werden.
Weitere Informationen: Applikationsparameter und URL-Parameter
Weitere Informationen
Informationen über die Bedienung der Endbenutzer- und Administrator-Personalisierungsfunktionen finden Sie unter Endbenutzer- und Administrator-Personalisierung.
Informationen über die Personalisierungmöglichkeiten, die der SAP List Viewer für Web Dynpro ABAP bietet, finden Sie unter Personalisierung im SAP List Viewer.