DOX42 and SAP Integration

DOX42 and SAP® Integration : Best Practices and Dev Hacks

SAP Connection Config

Dox42 Data source to map SAP data requires the following SAP system connection details

While it is possible to manually enter the values of SAP system parameters, this approach has following shortcomings:

  • Developers need to enter or update application server and login details every time a template is used, moved, tested, updated etc. in the different systems
  • This information needs to be maintained separately in every data map

Best Practice solution:

Maintain a separate excel file (e.g., config.xls) containing these details and add it as a separate data map of type ‚excel‘ as shown below:

Maintain a filter to dynamically pick correct system connection mapping from the excel file based on I_LOGICAL_SYSTEM as an input parameter:

This file can be used to populate Connection details in all SAP data maps as illustrated below:

Whenever there is a change in system settings or if we want use powerdoc template in a new SAP system, editing this config file is sufficient (rather than individual maintainance in the connection tab of each SAP data source for every data map)!


 

Data Mapping Limitations and Tabular Data Mapping

DOX42 data maps can handle only one structure or a table as a return data container (within which it is possible to specify field names, identical to the names used in the SAP source)

To print tabular data,

1. Create + map table parameter in the RFC to a data source as illustrated below

2. use „Repeat for Data Source“ option in the Automate Range wizard


 

Alignment for Multi-line Output

Use the insert frame feature as shown below, if you want to print a text (e.g. notes) that can overflow to the next line and if you need to maintain alignment (i.e. if you want to print line 2 below directly below line 1 while maintaining horizantal alignment)

As shown in thescreenshot below, the output data is printed on the multiple lines and text alignment is maintained (i.e. second line starts below the first line)

If you have any further questions about DOX42-SAP integration, feel free to email us :

ABAP RESTful & Fiori Elements

ABAP® RESTful & Fiori® Elements: Button in List Reports

Wenn man Anwendungen mit Fiori Elements erstellt, wird man sehr bald mit der Aufgabenstellung konfrontiert, zusätzliche Buttons zu ergänzen. Dies ist mit gewissen Einschränkungen allein durch Erweiterungen im ABAP Backend möglich.

In diesem Beispiel zeige ich, wie man die Buttons in einem List Report mit einer ABAP RESTful Implementierung verwenden kann. Eine Verwendung mit BOPF ist sehr ähnlich und Buttons können auch an anderer Stelle ergänzt werden. Vielleicht schreib ich dazu noch extra einen Blog.

Ich hab dieses Demo auf einem ABAP 1909 Trial und UI5 1.71 System umgesetzt. Es handelt sich um ein unmanaged Szenario, sollte aber ohne großartige Anpassungen auch mit einem managed Szenario funktioineren.

Ausgangssituation

Ich verwende immer sehr vereinfachte, reduzierte Beispiele. Umfangreiches oder schwer nachvollziehbares Coding soll nicht vom eigentlichen Thema ablenken. Obwohl ich ein großer Anhänger von Clean Code und Modern ABAP bin, versuche ich trotzdem in solchen Beispielen so einfach wie möglich zu arbeiten.  Wir haben hier jedenfalls eine Liste von internen Bestellungen und deren Status. Im Detail besteht die Anwendung aus folgenden Objekten. Wenn man eine Anwendung halbwegs sauber aufsetzt, hat man leider so viele Entwicklungsobjekte.

  • ZFOE_DB_ORDER – Order Datenbanktabelle
  • ZFOE_I_ORDER – Order Interface View
  • ZFOE_P_ORDER – Order Projection View
  • ZFOE_P_ORDER – Metadata Extension für Projection View
  • ZFOE_I_ORDER – Behavior Definition Interface View
  • ZBP_FOE_I_ORDER – Behavior Klasse
  • ZFOE_P_ORDER – Behavior Definition Projection View
  • ZFOE_SD_ORDER – Service Definition
  • ZFOE_SB_ORDER – Service Binding

Datenbanktabelle: ZFOE_DB_ORDER

Interface View: ZFOE_I_ORDER

Projection View: ZFOE_P_ORDER

Hier bitte darauf achten, dass die Annotation @Metadata.allowExtensions auf true ist. Dies ist notwendig, um eine Metadata Extension anzulegen.

Metadata Extension: ZFOE_P_ORDER (UI Annotations)

Die Metadata Extension wird verwendet um die UI Annotations besser strukturieren und von den anderen DDLs besser trennen zu können. In dem Beispiel hätten wir die Annotations natürlich auch direkt im Projection View aufnehmen können. Beim Layer ist hier #CORE anzugeben. Die Ausgabeposition der 4 Felder wird hier mit den Annotations @UI.lineItem.position angegeben.

Behavior Definition für ZFOE_I_ORDER

Wir wollen später im Demo lediglich ein update ermöglichen. Daher ist hier update aktiviert. Alles andere kann derzeit deaktiviert bleiben.

Behavior Klasse ZBP_FOE_I_ORDER

In aktuellen Systemen kann die Klasse einfach  über Quick Fix angelegt werden. In älteren Systemen kann das ggf. auch manuell erfolgen.

Behavior Definition für ZFOE_P_ORDER

Service Definition ZFOE_SD_ORDER

Service Bindung ZFOE_SB_ORDER

Und hier noch eine Implementierung um 3 Testdaten in die Tabelle zu schreiben. Das geht super einfach mit dem Interface IF_OO_ADT_CLASSRUN welche in irgendeiner Helperklasse implementiert sein sollte.

So viel zu der Ausgangssituation. Wenn man die Fiori Elements Anwendung nun mit Preview startet, sollte in etwa folgende Liste dargestellt werden:

Button ergänzen

Nun wollen wir uns der eigentlichen Aufgabenstellung widmen und zwei Buttons (Ist die Mehrzahl von Button überhaupt Buttons?) ergänzen. Ein Button soll die Order genehmigen, der zweite Button soll die Order ablehnen. So eine Art Miniworkflow.

Behavior Definitionen & Implementation

Als Erstes müssen wir mal in den Behavior Definitionen von ZFOE_I_ORDER und ZFOE_P_ORDER die beiden neuen Button als Action aufnehmen. Ich hab mich für die Namen but_accept und but_decline entschieden.

In der Behavior Definition ZFOE_I_ORDER geht das ganz einfach durch action gefolgt von einem eindeutigen Namen.  In der Behavior Definition von ZFOE_P_ORDER reicht die Angabe von use und dem Namen der Action.

Natürlich brauchen wir auch später auch eine Methode in unserer Klasse. Über einen Quick Fix auf die action im Interface View kann diese automatisch angelegt werden. Vorerst lassen wir  aber die Methoden einfach leer.

Damit die neuen Buttons auch im Userinterface angezeigt werden, müssen wir zwei Annotations  in der Metadata Extension ZFOE_P_ORDER ergänzen. Dies ist durch eine Erweiterung der lineItem Annotation möglich. Mit type: #FOR_ACTION defineren wir dass es sich um eine Action handelt und in dataAction ist die zuvor angelegt Action anzugeben. Damit wir auch einen Text am Button sehen, sollten wir ein label angeben.

 

Wenn wir uns jetzt die Fiori Anwendung nochmals aktualisieren, sollten die beiden Buttons bereits vorhanden sein:

Wau – das ging ja schnell. Jetzt passiert aber noch nichts wenn man einen der Button klickt. Dafür brauchen wir noch eine Implementierung in den beiden Action-Methoden. Nachfolgendes Coding macht die Änderungen auf der Datenbank. Hinweis: Bitte Verbesserungen am Coding selber machen, für die Demo Zwecke ist die Implementierung vollkommen ausreichend.

Ein neuerlicher Test der Anwendung zeigt uns, dass das Setzen der Statusinformationen bereits funktioniert.

Die Lösung ist bis hierhin schon richtig gut, aber es geht natürlich noch etwas besser. Beispielsweise sollen die beiden Button nur aktiv sein, wenn der Status New ist. Ein bereits gesetzter Status soll nicht mehr verändert werden können.

Button dynamisch aktiv oder inaktiv

Mit den so genannten Instance Features können wir einen Button dynamisch aktiv bzw. inaktiv setzen. Um dies zu erreichen, müssen wir zuerst einmal die Behavior Definition des Interfaces Views etwas anpassen. Der Zusatz ( features: instance ) muss nach action ergänzt werden.

Über die Quick Fix Funktion auf ZFOE_I_ORDER wird auch gleich die neue Methode GET_INSTANCE_FEATURES angelegt. Im nachfolgenden Beispiel lesen wir zuerst mit EML die Entity und setzen in der Export Tabelle den Button auf aktiv oder inaktiv.

Da wir oben mit EML die Entity lesen, sollten wir auch die read Methode implementieren.

Ein erneuter Test sollte nun zeigen, dass die Buttons nur bei Zeilen mit Status „New“ aktiv sind:

Wer es bis hier geschafft hat: Respekt! Ihr habt Euch nun einen Kaffee oder ein Bier verdient.

Button mit Popup

Die zwei Buttons sind ja eigentlich fertig, aber wie wäre es, wenn der Anwender zusätzlich einen Kommentar ergänzen könnte. Geht das einfach? Ja, auch das kann mit Fiori Elements umgesetzt werden.

Zuerst müssen wir eine abstrakte Entität definieren. Die gewünschten Attribute im Popup sind als Felder der Entität anzugeben. Nähere Informationen zu abstract entities bitte bei Bedarf selber nachlesen.

Diese abstrakte Entität müssen wir nun noch in der action der  Behavior Definition des Interface Views eintragen. Mit dem prefix parameter.

Der eingegeben Kommentar soll natürlich auch irgendwie verarbeitet werden. Dafür ist die Implementierung der Action but_decline zu erweitern. Der eingegebene Kommentar befindet sich in der Inbound Struktur keys, Substruktur %param

 

Jetzt noch ein kurzes Stoßgebet und mit etwas Glück funktioniert alles wie gewünscht. Bei Decline erscheint nun ein Popup und die dort eingegeben Message wird zusätzlich zum Status geändert.

Was (noch) nicht möglich ist und was ich vermisse

Alles nur aus Sicht, dass ich keine Anpassung im Frontend (UI5) machen will. Durch individuelle Erweiterungen am Frontend ist natürlich vieles möglicht.

Farben und Icons

Leider können keine Icons oder Farben (Criticality) verwendet werden. Soweit ich gesehen habe ändert sich dies auch in der aktuellsten UI5 Version nicht. Manchmal sind Icons oder Farben einfach hilfreich um wichtige von weniger wichtigen Buttons zu unterscheiden. Ich hoffe, dass SAP dies bald via Annotations ermöglicht.

Es gibt aber die Möglichkeit Emojis oder ASCII-Codes zu verwenden. Damit bekommt man schon Symbole rein. – Im Sinne des Fiori Designs wäre es aber natürlich wichtig die SAP Standard Icons zu untersützten.

Beispiel mit Emojis

Multiline

Action Popups für Multiline List-Reports funktionieren erst ab UI5 1.76. Aufpassen beim Testen. Wenn man z.B. über Visual Studio Code testet, wird meist die aktuellste UI5 Version verwendet. Die Preview Funktion via ADT erzeugt nur eine Anwendung mit Single-Line-Selektion. Bitte immer vorab prüfen, nicht dass dann beim Deployen ins Backend das große Erwachen kommt.

ABAP SQL Währungsumrechnung

ABAP® 7.55 – ABAP® SQL – Währungsumrechnung

In den CDS Views kann die Funktion zur Währungsumrechnung bereits seit 7.40 verwendet werden. In ABAP SQL, also direkt im SELECT, wurde diese Funktion nun mit ABAP 7.55 aufgenommen. Nachfolgend ein einfaches Beispiel in dem ein Wert ProductionCosts von Währung Currency nach USD umgerechnet werden soll:

Funktion CURRENCY_CONVERSION

Die Funktion zur Umrechnung heißt CURRENCY_CONVERSION( ) . In den Klammern gibt es einige Pflichtangaben und ein paar weitere optionale Angaben.

Parameter

Folgende Parameter müssen angegeben werden:

  • amount – Betragsfeld welches umgerechnet werden soll
  • source_currency – Ausgangswährung
  • target_currency – Zielwährung
  • exchange_rate_date – Tagesdatum mit dem die Umrechnung vorgenommen werden soll

Ergänzend dazu können weitere Angaben für die Berechnung vorgenommen werden. Beispielsweise wie gerundet wird oder wie die Dezimalstellen berücksichtigt werden sollen. Oh ja, die Sache mit den Dezimalstellen (Wer erinnert sich an an die italienische Lire?) wurde noch im R/2 erfunden und ist auch im aktuellsten ABAP Release vorhanden.

 

SAP Hana® – das SQL Cockpit kann helfen

In den vergangenen Jahren gab es in der Software Architektur die Bestrebungen, alles zu abstrahieren. Die tatsächlichen Zugriffe auf die Datenbank wurden dadurch immer weiter in den Hintergrund gedrängt.

Das hatte den Vorteil, dass es für Entwickler leichter wurde, da die relevanten Daten schön in Objekten vorhanden waren. Auf der anderen Seite haben die Entwickler damit den Zugang zu den Daten aus den Augen verloren. Dies zeigt sich vor allem in performancekritischen Applikationen, da dort viele inperformante und oft auch zu viele unnötige Datenbankzugriffe vorhanden waren, und dies sehr schnell spürbar wurde.

SAP HANA verhilft mit seiner in Memory Technologie nun den Datenbankzugängen zu einer neuen Renaissance. Plötzlich sind SAP Berater gefordert, die Performance bereits an der Quelle (der Datenbank) zu optimieren.

Wenn man nun in einem HANA Implementierungsprojekt einen Prozess aus einem System (z.B. SAP ERP) in die in Memory Technologie verlagern möchte, dann muss man zunächst diesen Prozess und die relevanten Daten analysieren. Danach werden die Daten in das HANA System geladen und dort die Zugriffe optimiert. Für den ersten Teil (die Analyse) gibt es nur die üblichen SAP Standardmittel (die meisten Berater nehmen dann die SE16), um die Daten auszuwerten. Danach werden sie transferiert und im HANA System gibt es dann externe Tools (also schon von SAP, aber nicht innerhalb des SAP Systems, sondern als Plugin in der Java Entwicklungsumgebung Eclipse), um die SQL Zugriffe zu optimieren.

Genau bei diesen beiden Prozesschritten kann das Cadaxo SQL Cockpit aber wichtige Dienste leisten, um den Einführungsprozess wesentlich zu beschleunigen. Zuerst können die Daten bereits im Quellsystem mit SQL Syntax analysiert werden. Das ermöglicht bereits eine erste Abschätzung der Optimierungspotenziale. Und quasi als „Abfallprodukt“ sind für die SQL Optimierungen die Statements schon vorbereitet.

Der Medienbruch ist auch nicht zu unterschätzen. Für SAP Berater, die seit Jahren alle Tätigkeiten innerhalb eines Systems (SAP NetWeaver) durchführen konnten, und ohne externe Tools ausgekommen sind, ist es viel einfacher im SAP System die Daten zu analysieren, als zunächst ein externes Tool zu installieren, die Zugriffe (Security) auf das System einzurichten, um dann die Analysen durchzuführen. Auch die tiefe Integration (z..B. konsequente Vorwärtsnavigation) innerhalb eines SAP Systems verhilft einem Berater zu wesentlich schnelleren Ergebnissen, als dies durch externe Zugriffe möglich wäre.

Aus diesem Grund sind interne Applikationen externen vorzuziehen. Dies gilt zumindest bei SAP Systemen immer!  Somit wäre das SQL Cockpit (intern) für alle SAP HANA Projekte ein wesentlicher Beschleunigungsfaktor.

Beispiele zur Verwendung von ABAP® CONCATENATE

Der ABAP Befehl CONCATENATE wird sehr oft benötigt. In diesem kurzen Blog zeige ich anhand einiger Beispiele wie Zeichenketten im ABAP „concatendated“ werden können. In den Beispielen finden sich auch die „moderneren“ Formen mit && bzw. der Stringfunktion concat_lines_of. Ansonsten ist, denke ich. das Codingbeispiel eigentlich selbsterklärend und bedarf keiner weiteren Worte.

SAP® Entwickler 2.0

Lange Zeit hat sich die Welt eines ABAP Entwicklers nicht wesentlich geändert. Da wurde mal ein Report erstellt, dort ein Funktionsbaustein. Manchmal wurde ein Userexit implementiert und selten auch einmal eine ganze Dynpro Transaktion. Ja es war sogar lange Zeit möglich die objektorientierte Welt mit geringem Aufwand zu umschiffen.

Die Zeiten sind nun definitiv vorbei!

Gerade in den letzten Jahren hat die Programmiersprache ABAP eine enorme Weiterentwicklung erlebt. Insbesondere mit ABAP 7.40 und ABAP 7.50 wurden eine ganze Reihe moderner Konzepte aus anderen Programmiersprachen in ABAP übernommen. Ergänzend dazu stehen neue Tools, Frameworks und Entwicklungsumgebungen einem SAP Entwickler zur Verfügung.

S/4 HANA Programmiermodell

Bei der SAP TechEd 2016 in Las Vegas wurde erstmals vom neuen S/4 HANA Programmiermodell gesprochen. Das Programmiermodell besteht aus mehren Schichten und vereint die gängigen Technologien eines SAP Entwicklers:

Modernes ABAP

Wie weiter oben erwähnt, wurde und wird ABAP durch die SAP kontinuierlich weiterentwickelt. Es gibt eine große Anzahl von Büchern, Kursen, Blogeinträgen, … die sich mit modernen ABAP Themen beschäftigen, deshalb erspare ich mir hier eine exakte Aufzählung. Nachfolgend eine Auflistung von Themen die für mich unter modernes ABAP fallen und jeder Entwickler im SAP kennen sollte:

  • Objektorientiertes Design
  • Open SQL Expressions
  • String Expressions
  • Table Expressions
  • Regular Expressions
  • Class Based Exceptions
  • Enhancement Framework
  • CDS Views
  • ABAP Shared Objects
  • ABAP Push Channels, ABAP Message Channels

Unabhängig von ABAP selber sollte sich ein Entwickler zumindest noch mit folgenden Themen beschäftigen:

  • Clean Code
  • Unit Tests & TDD
  • Design Patterns

Weiterführende Informationen

Title Bereich Details
ABAP 7.50 Releasenotes Cadaxo Webinar http://www.cadaxo.com/high-class-development/webinar-abap-7-50-releaseabhaengige-aenderungen/
Clean Code in ABAP Cadaxo Webinar http://www.cadaxo.com/high-class-development/webinar-clean-code-abap/
Boost Your ABAP Cadaxo Webinar http://www.cadaxo.com/high-class-development/webinar-boost-abap/
SDN Community ABAP SDN http://www.sap.com/community/topic/abap.html
SAP Press SAP Press Bücher https://www.sap-press.com/programming

ABAP Development Tools (ADT) & SAP Web IDE

ADT (=ABAP for Eclipse) ist SAP’s state-of-the-art IDE für ABAP. Obwohl das ADT nicht wirklich neu ist, entwickelt die überwiegende Mehrheit der ABAP Entwickler nach wie vor ausschließlich in der SE80.

Und das, obwohl Entwicklungen mit ADT meist einfacher und schneller umgesetzt werden können. ADT bietet in der Handhabung generell viele Vorteile, aber ein wichtiges Featureset sind die Refactoring Funktionen, welche gerade im Bereich der agilen Software Entwicklung wesentlicher Bestandteil sind.

Einzelne Entwicklungsobjekte wie z.B. die CDS Views können bisher ausschließlich mit ADT bearbeitet werden. Andere Objekte wie z.B. BOPF Objekte bieten in ADT wesentlich intuitivere Modellierungsmöglichkeiten.

Ein professioneller ABAP Entwickler sollte sowohl in der ABAP Workbench (SE80) als auch im ADT zu Hause sein, um je nach Aufgabenstellung das passende Entwicklungstool zu wählen.

Für die Erstellung von SAPUI5 bzw. Fiori Anwendungen hat SAP ergänzend zu den ABAP Development Tools die cloudbasierte SAP Web IDE zur Verfügung gestellt.

Weiterführende Informationen

Title Bereich Details
Webinar – ABAP Entwicklung in Eclipse & SAP Web IDE Einführung Cadaxo Webinar http://www.cadaxo.com/uncategorized/webinar-abap-entwicklung-eclipse-sap-web-ide-einfuehrung/
ABAP Development User Guide help.sap.com http://help.sap.com/saphelp_nw75/helpdata/en/4e/c0ca886e391014adc9fffe4e204223/frameset.htm
ABAP Development Tools Eclipse help.sap.com http://help.sap.com/saphelp_nw74/helpdata/en/a3/314a7fd9384ce8a40eff2d3b144628/frameset.htm
ABAP Development Tools Tutorials SDN Blog https://blogs.sap.com/2012/09/18/abap-development-tools-tutorials-learn-how-to-use-abap-in-eclipse/
Get Started with the ABAP Development Tools SDN Blog https://blogs.sap.com/2012/06/19/get-started-with-the-abap-development-tools-for-sap-netweaver/
What is SAP Web IDE developer.sap.com http://www.sap.com/developer/topics/sap-webide.html
ABAP to the Future SAP Press Book ISBN 978-1-4932-1411-2
ABAP-Entwicklung in Eclipse SAP Press Book ISBN 978-3-8362-3040-7

ABAP Units & Test Driven Development

Als Entwickler ist es uns natürlich ein Anliegen, fehlerfreie Software zu erstellen. Traditionell geschehen Unit Tests in SAP oft mit eigens erstellten Testprogrammen oder einer Testausführung von Klassen/Methoden bzw. Funktionsbausteinen. Also völlig unstrukturiert, undokumentiert und schwer reproduzierbar.

Mit den ABAP Units steht jedoch auch im ABAP ein Test-Framework zur automatisierten Ausführung und Analyse von Unit Tests zur Verfügung.

Der Einsatz von ABAP Unit Tests reduziert die Hemmschwelle eines Entwicklers produktives Coding zu optimieren. Eine Testausführung würde ihm sofort direktes Feedback geben ob trotz der Optimierung das Coding weiterhin einwandfrei funktioniert.

ABAP Units verfügen über eine enge Integration in andere Tools wie z.B. dem Code Inspector bzw. ATC.

Die Steigerungsform von Unit Tests wäre Test Driven Development. Vom Ansatz her ist TDD genial, in der ABAP Community wird darüber kontrovers diskutiert.

Weiterführende Informationen

Title Bereich Details
TDD mit ABAP Units Cadaxo Webinar http://www.cadaxo.com/high-class-development/webinar-tdd-mit-abap-units/
ABAP Unit help.sap.com http://help.sap.com/abapdocu_750/de/index.htm?file=ABENabap_unit.htm

Business Object Processing Framework (SAP BOPF)

Aktuell (noch) relativ unbekannt ist das sogenannte SAP Business Object Processing Framework. SAP BOPF ist ein auf ABAP basierendes Framework zum Modellieren und Entwickeln von Geschäftsobjekten. Bisher gab es in SAP Systemen (Ausnahme SAP CRM mit BOL/GENIL) nichts Ähnliches, alles musste „zu Fuß“ ausprogrammiert werden.

SAP BOPF nimmt einem Entwickler zeitraubende und meist auch langweilige Implementierungsaufgaben ab und ermöglicht einem Entwickler sich auf die wesentlichen Businessanforderungen zu konzentrieren.

Die größten Vorteile von SAP BOPF wären:

  • Klare Trennung von UI und Business Logik
  • Ermöglicht verteilte Entwicklung durch mehrere Entwickler
  • Beschleunigt den Entwicklungsprozess enorm
  • Bereits viele Verwender (Gateway, FPM, BRFplus, … ) vorhanden
  • Einfache Integration in Eigentwicklungen

Weiterführende Informationen

Title Bereich Details
SAP BOPF Cadaxo Webinar http://www.cadaxo.com/high-class-development/webinar-sap-bopf/
BOPF Modelling in ADT SDN Blog https://blogs.sap.com/2014/05/09/bopf-modelling-in-eclipse
ABAP to the Future SAP Press Book ISBN 978-1-4932-1411-2

Fiori/SAPUI5 & Floorplan Manager/Web Dynpro for ABAP

User Interfaces haben bei der SAP historisch einen schlechten Ruf. Lange Zeit mussten sich Anwender mit veralteten SAP Gui Anwendungen abmühen. Längst bietet SAP alternative Technologien für die Realisierung moderner User Interfaces.

SAPUI5 basiert technisch auf etablierten Webstandards (Javascript, HTML5, …) und liefert die technische Grundlage für moderne Fiori Anwendungen. SAPUI5 / Fiori ist DIE UI Strategie der SAP, sprich zukünftige Oberflächen in den SAP Systemen (OnPremise oder Cloud) werden – Stand Jänner 2017 – in Form von SAPUI5 / Fiori realisiert.

Web Dynpro for ABAP (WDA) ist (zumindest war) bereits seit vielen Jahren quasi der Standard für die Erstellung von transaktionalen Anwendungen in einem SAP System. Um die Realisierung von Web Dynpro Anwendungen zu beschleunigen und zu standardisieren wurde der darauf aufbauende Floorplan Manager (FPM) entwickelt. Web Dynpro for ABAP bzw. der Floorplan Manager richten sich eher an Power User, an interne Mitarbeiter eines Unternehmens.

Ein professioneller ABAP Entwickler sollte in jedem Fall beide Technologien kennen und einsetzen können.

Weiterführende Informationen

Title Bereich Details
What is SAPUI5 developer.sap.com http://www.sap.com/developer/topics/ui5.html
User Interface Developer developer.sap.com http://www.sap.com/developer/topics/ui-development.html
Web Dynpro ABAP and Floorplan Manager Community developer.sap.com http://www.sap.com/community/topic/web-dynpro-abap-and-floorplan-manager.html
ABAP to the Future SAP Press Book ISBN 978-1-4932-1411-2
SAPUI5 Das umfassende Handbuch SAP Press Book ISBN 978-3-8362-4456-5

SAP Gateway (OData)

Im Jahr 2011 hat SAP SAP Gateway auf den Markt gebracht. SAP Gateway öffnet ABAP Systeme um eine standardisierte und zentralisierte Schnittstelle mit der Außenwelt.

Technisch setzt SAP Gateway auf verbreitete Standards wie REST, Atom und OData wodurch die Kommunikation mit anderen Systemen die ebenfalls diese Standards nutzen denkbar einfach realisiert werden kann. SAPUI5 bzw. Fiori Anwendungen nutzen ebenfalls SAP Gateway für die Kommunikation mit den Backendsystemen.

Weiterführende Informationen

Title Bereich Details
SAP Gateway Community developer.sap.com http://www.sap.com/community/topic/gateway.html
SAP Gateway Developer Guide help.sap.com https://help.sap.com/saphelp_gateway20sp10/helpdata/en/56/d0cc05b564411e841141f68294e29f/content.htm
SAP Gateway und OData SAP Press Book ISBN 978-3-8362-4019-2

CDS Views

Die CDS Views zählen für mich zu den innovativsten ABAP Neuheiten der letzten Jahre. Durch die regelmäßigen Funktionserweiterungen handelt es sich hier nicht mehr nur um eine neue Form von Datenbank Views.

Durch Annotations können CDS Views um weitere technische und semantische Eigenschaften ergänzt werden. So können beispielsweise seit ABAP 7.50 Gateway oder BOPF Objekte generiert werden.

Ebenfalls ab 7.50 können implizite Berechtigungsprüfungen mit der sogenannten Data Control Language (DCL) abgebildet werden.

Weiterführende Informationen

Title Bereich Details
CDS Views help.sap.com http://help.sap.com/abapdocu_750/en/abencds.htm
CDS Annotations 7.50 help.sap.com http://help.sap.com/abapdocu_750/en/abencds_f1_view_entity_annotations.htm
CDS Annotations 7.51 help.sap.com http://help.sap.com/abapdocu_751/en/index.htm?file=abencds_annotations_abap.htm
CDS Views SDN Blog https://blogs.sap.com/2015/07/20/cds-one-model-two-flavors
ABAP to the Future SAP Press Book ISBN 978-1-4932-1411-2