Aufgrund der vielen anderen Termine im Herbst, findet unser nächstes Webinar erst im Jänner 2020 statt. Das Thema wird noch vor Weihnachten fixiert, aber natürlich kann man sich jederzeit registrieren.
Ab dem Release ABAP 7.51 und den ABAP Development Tools 2.68 gibt es eine Format-Funktion für DDL Source Codes. Es besteht die Möglichkeit sich sein eigenes Profil zu definieren, das SAP Standardprofil oder ein Teamprofil je Entwicklungspaket zu verwenden.
Formatieren eines DDL Source Code
Das Formatieren eines DDL Source Codes kann wie folgt aufgerufen werden:
Shortcut SHIFT + F1
Menü bzw. Context Menü: Source Code – Format
Automatisch beim Speichern
Formatierungseinstellungen
Die Formatierungseinstellungen können in den Preferences unter ABAP Development – Editors – Source Code Editors – DDL Formatter angepasst werden. Es sind 3 unterschiedliche Gültigkeitsbereiche möglich.
SAP Standard Profil – SAP liefert eine nicht veränderbare Voreinstellung aus. Diese steht sofort zur Verfügung.
Eigenes Profil – Wenn das Standardprofil nicht ausreicht, kann ein eigenes Profil definiert werden. Eigene Profile können mit der Export- bzw. Import Funktion mit anderen Entwicklern und Systemen ausgetauscht werden.
Team Profil – Das SAP Standardprofil kann auf Basis von ABAP Paketen zentral am Server überschrieben werden. Dies ist eine Möglichkeit um unterschiedliche Profile je System oder Paket zu definieren. Technisch erfolgt die Steuerung der Profile im Backend durch eine Implementierung auf den BADI SDDIC_ADT_DDLS_PP_CONF.
Formatierungsdetails
Die Formatierung des DDL Source Codes kann sehr detailliert eingestellt und angepasst werden. Um ein einheitliches Aussehen innerhalb des Systems zu gewährleisten, sollte ein einheitlicher Standard definiert und angewendet werden. Die Verteilung dieser Variante kann entweder über Export/Import erfolgen oder über den oben erwähnten BADI zentral vorbelegt werden.
Domi Bigl war bei Cadaxo der Erste, der sich ausführlich mit den ABAP Development Tools beschäftigt hat. In der Zwischenzeit verwendet er seit langer Zeit fast ausschließlich ADT für die ABAP Entwicklung. Grund genug, ihm mal ein paar Fragen zu den ABAP Development Tools zu stellen:
Du bist ja bekanntlich ein Early Adopter der ABAP Development Tools. Seit wann verwendest Du ADT und was hat dich zum Umstieg bewogen?
Eclipse verwende ich schon sehr lange für alle möglichen Programmiersprachen. Im SAP Umfeld wurde es als Netweaver Developer Studio schon für z.B. Portal Entwicklungen am Java-Stack eingesetzt. Seit HANA, SAPUI5 und CDS Views ist Eclipse auch für den ABAP-Stack notwendig geworden. Mit den ADT war dann endlich auch ABAP Programmierung im Eclipse möglich – das wollte ich natürlich sofort ausprobieren!
Ging der Umstieg für dich einfach oder hattest Du in gewissen Bereichen Schwierigkeiten?
Mit Eclipse war ich ja schon vertraut, hatte also keine Probleme mit dem generellen Handling, Views, Perspektiven usw. Gewöhnungsbedürftig war der „quelltextbasierte Class Builder“, im GUI habe ich immer den formularbasierten verwendet. Und der Doppelklick. Die Funktionen von Doppelklick und Strg-Klick sind genau andersrum wie im GUI, dass muß einem einmal einfallen ;-). Der Debugger ist auch noch etwas unhandlich und kommt manchmal mit dem GUI durcheinander.
Bekanntlich werden noch nicht alle Entwicklungsaufgaben durch ADT unterstützt. Beispielsweise können derzeit noch keine Enhancements gepflegt werden und der Debugger verfügt auch noch nicht über die gleichen Möglichkeiten wie der SE80 Debugger?
Stimmt, aber in einem Enhancement sollte man ja ohnehin nur einen Methodenaufruf einer Z-Klasse drinnen haben, das ist dann nicht so das Problem, außerdem kommt das ja mit 752! Der Debugger wird auch ständig verbessert – und als der neue Debugger im GUI kam, hat anfangs auch beinahe jeder auf den alten Debugger umgeschalten, oder?
In eine Ähnliche Richtung gehen Entwicklungen von z.B. SAP CRM. Dort gibt es eigene Tools welche ausschließlich in SAP Gui lauffähig sind. Wie gehst Du damit um?
Ich verwende auch z.B. für die Component Workbench den embedded SAP GUI. Per Doppelklick öffnen sich die Klassen oder Methoden dann wieder im ADT Editor. Das funktioniert einwandfrei. Es wird ja auch für andere Objekte der embedded GUI aufgerufen: Tabellen (und Strukturen) bzw. DDIC generell – je nach Release halt, oder Berechtigungsobjekte oder … . Was noch fehlt, ist der Transaktionsbaum – also SESSION_MANAGER aus dem GUI, man muss die Transaktionen wissen bzw eben irgendwie suchen und eingeben – Tx SE93 oder Tabelle TSTCT… Es gibt auch ein cooles Plugin: ABAP Favorites (https://abapblog.com/)
Was würdest Du einem klassischen ABAP Entwickler, der in die ADT Welt einsteigen möchte, raten? Hast Du Tipps wie der Einstieg optimal verlaufen kann?
Einfach starten! Jetzt! Und mit jetzt mein ich vor 5 Monaten! Nein, im Ernst: wer jetzt noch nicht nicht mit ADT arbeitet, darf sich nicht mehr ABAP Entwickler nennen. Und die Basis-, Software- oder Securityteams als Ausrede zu verwenden, zählt einfach nicht mehr: ADT gehört zur SAP Entwicklung, wie sonst wollt ihr schnell und Clean-Code konform entwickeln, oder CDS Views erstellen oder auch nur anschauen – außer mit dem SQL Cockpit vielleicht ;-)? Und gerade wenn man noch nicht mit CDS Views, UI5 Apps, HANA Views und dergleichen zu tun hat, für die (zumindest) Eclipse notwendig sind, sollte man sich doch mit Altbekanntem – ABAP Programmierung – an eine neue IDE gewöhnen und nicht CDS, DDL, DCL, Javascript, einerseits… UND eine neue Umgebung andererseits kennen lernen müssen!
Die ABAP Development Tools werden kontinuierlich verbessert, gibt es dennoch Dinge die deiner Meinung nach fehlen und dringend eingebaut werden sollten?
Wie schon erwähnt: der SESSION_MANAGER fehlt schon etwas. Und dass eine Klasse in einem Auftrag gesperrt wird, obwohl ich nur Methoden-Coding ändere? Zwei Methoden in jeweils unterschiedlichen Transportaufträgen und die Klasse ist mit ADT nicht bearbeitbar?!?! Ähnliches gilt für Enhancements – nur weil eine Methode Erweitert wurde, muss man doch nicht die ganze Klasse tabu sein! Zum Glück trifft einen das nur selten – vor allem, wenn andere Teammitglieder noch die SE24 bevorzugen… Die meiste Zeit freut man sich über 7 neben-, über-, und untereinander offenen Objekte oder die Quickfixes, Quickinfos, Refactoring Möglichkeiten, … und hofft, dass der Debugger diesmal im Eclipse aufgeht – oder vielleicht doch besser im GUI 😉
Gibt es sonst noch etwas dass Du zum Thema ABAP Development Tools sagen möchtest?
Die Zeiten von Report mit 5k Zeilen mit FORMs und vielleicht auch noch ohne INCLUDEs sind vorbei – OOP, TDD, CI, ARP, CDS, SAPUI5, SAP Cloud Platform ABAP Environment, Git… Das sind nicht nur schöne Schlagworte – damit verändert sich auch die Art wie, wo und was ein ABAP Entwickler implementiert und mit welchen Tools. Die SE80 ist dafür nicht mehr zeitgemäß, die WebIDE wird (zumindest derzeit) nicht für ABAP Entwicklung erweitert werden – damit bleiben nur die ADT in Eclipse! Aus meiner Sicht werden zumindest die nächsten 5-10 Jahre die ADT DIE IDE für ABAP/SAP Development sein! Probiert es aus, freundet euch damit an und nach einer Woche werdet ihr die SE38/SE24/SE80/… nicht mehr vermissen!
Core Data Service Views – CDS Views – sind die neue Form der DDIC (SE11)-Datenbankview – aber absolut nicht vergleichbar!
CDS Views werden mit der Data Definition Language – DDL – in den Abap Development Tools definiert und können mit der Data Control Language – DCL – um Berechtigungen bzw. Zugriffsbeschränkungen erweitert werden.
Sie sind eine Möglichkeit des Code Push-Down im ABAP und zentraler Bestandteil des S/4 HANA ABAP-Programmiermodels (mehr Details gibt’s in den Folien zum Webinar).
Die hier gezeigten Beispiele wurden in unserem Webinar ABAP CDS Views verwendet und basieren auf Geschäftspartner-Beziehungen. Als System diente SAP NETWEAVER 750 SP1, bei niedrigeren Releases (ab 740 SP5/SP8) stehen manche Funktionen noch nicht zu Verfügung!
Und hier noch die Datenbasis aus der Geschäftspartnerpflege:
Schritt 1 – Ein erster CDS View mit JOIN
Definition eines CDS Views mittels DDL
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
@AbapCatalog.sqlViewName:'ZWB_BUT050_TX1D'
@AbapCatalog.compiler.compareFilter:true
@AccessControl.authorizationCheck:#NOT_REQUIRED
@ClientDependent:true
@EndUserText.label:'BUT050 with Texts'
define view Zwb_But050_Txt_E asselect from but050
left outer join tbz9a ascattx
on but050.reltyp=cattx.reltyp{
key but050.partner1,
key but050.partner2,
key but050.date_to,
key but050.reltyp,
but050.date_from,
@Semantics.language:true
@EndUserText.label:'Sprache'
cattx.spras,
cattx.bez50,
cattx.bez50_2
}
Wir haben hier einem LEFT OUTER JOIN der BUT050 mit TBZ9A (Alias cattx) und den Viewfeldern Partner1, Partner1, Date_to, Reltyp, Date_from aus der Tabelle BUT050 und Spras, Bez50 und Bez50_2 aus der Tabelle TBZ9A. Als Ergebnis erhalten wir alle Beziehungen aus der BUT050 und den entsprechenden Texten zum Beziehungstyp aus der TBZ9A.
Das ist jetzt noch nicht wirklich aufregend und, abgesehen vom Syntax, auch nicht neu. Das schafft man auch mittels SE11-Datenbankview.
Wir wollen dieses einfache Beispiel aber nutzen, um die verschiedenen Bereiche, Befehle und Tools genauer zu beschreiben.
DDL Bereiche
Objekte und Namen
CDS Entity Name (Datenquellenobjekt ): Die CDS Entity wird als Datenquelle z.B. im ABAP Open SQL Statement verwendet. CDS Datenbank View (generierter SE11 Datenbankview): Für jede Entity wird ein SE11 Datenbankview mit entsprechendem Namen generiert. CDS Viewname (Sourcecode): Name des DDL Sourcecode Objekt.
Generierter DDL View in der SE11:
Annotiations
Annotations bieten die Möglichkeit Eigenschaften, Einstellungen und Metadaten für einem CDS View zu definieren. Diese Werte werden z.B. von der ABAP Runtime oder diversen Frameworks (u.a. Gateway/OData Service, BOPF,…) ausgelesen und steuern deren Verhalten bzw. die Ausgabe.
Annotations gelten entweder für den gesamten View – View Annotations:
1
2
3
4
5
6
@AbapCatalog.sqlViewName:'ZWB_BUT050_TX1D'
@AbapCatalog.compiler.compareFilter:true
@AccessControl.authorizationCheck:#NOT_REQUIRED
@ClientDependent:true
@EndUserText.label:'BUT050 with Texts'
...
Oder für einzelne Elemente/Felder – Element Annotations:
1
2
3
4
5
6
7
8
9
10
11
...
key but050.reltyp,
but050.date_from,
@Semantics.language:true// Definition VOR dem Element
@EndUserText.label:'Sprache'
cattx.spras
@<EndUserText.quickInfo:'Sprache',// Definition NACH dem Element
cattx.bez50,
...
Natürlich gibt’s auch Code Completion:
Annotations zu CDS Entitäten bzw. deren Feldern können mit der API Klasse CL_DD_DDL_ANNOTATION_SERVICE ausgelesen werden. Es wird auch die Möglichkeit kundeneigener Annotations geben (derzeit noch nicht offiziell unterstützt).
Die Select Liste (Datenbankfelder, Literale, Parameter, Funktionen, Systemfelder,…) kann entweder VOR oder NACH den Datenquelle angegeben werden:
Datenquellen
Als Datenquellen können Datenbanktabellen, SE11-Datenbankviews und andere CDS Entitäten angegeben werden. Für ON-Bedingungen von Joins gelten ähnliche Regeln, wie im Open SQL. Vor allem ist auch hier noch kein CAST möglich.
Die Ergebnisse eines CDS Views kann in den ADT über die Data Preview angezeigt werden. Der Aufruf erfolgt über das Kontextmenü im DDL Code oder im Project Explorer oder direkt mittels F8:
Die Ausgabe der Data Preview:
Über Add filter kann, ähnlich der SE16, auf einzelne Feldwerte eingeschränkt werden:
In der SQL Console kann der abgesetzte SQL SELECT Befehl angezeigt und angepasst werden:
Cadaxo SQL Cockpit
Um den ABAP Open SQL Aufruf bzw. Syntax zu zeigen, wird das Cadaxo SQL Cockpit verwendet. Die angeführten SELECT Statement können genauso in ABAP Coding verwendet werden. Einzig der Befehl
1
...INTO TABLE@DATA(lt_but050_txt)...
muss an den entsprechenden Stellen eingefügt werden.
Die CDS Views biete eine ganze Fülle von eingebauten Funktionen, mit denen z.B. mathematische Funktionen und Stringopperationen ausgeführt, Währungs- und Mengeneinheiten umgerechnet, Zeit- und Datumsangaben geprüft oder Datumsintervalle berechnet werden können.
Hier wird die eingebaute Funktion DATS_DAYS_BETWEEN verwendet, um die Gültigkeit jeder Beziehung in Tagen zu berechen, und als Viewfeld Period bereitzustellen:
1
SELECT *FROM ZWB_BUT050_TEXT1_E."View mit eingebauter Funktion
Im Ergebnis sehen wir die unterschiedlich langen Gültigkeitsbereiche in der Spalte PERIOD.
Schritt 3 – Views mit Parametern
Für CDS Views können Parameter definiert werden, die beim SELECT übergeben bzw. befüllt werden müssen:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
@AbapCatalog.sqlViewName:'ZWB_BUT050_TX4D'
@AbapCatalog.compiler.compareFilter:true
@AccessControl.authorizationCheck:#CHECK
@EndUserText.label:'BUT050 with Texts with Parameter'
Der SELECT wurde um zwei JOINs auf die BUT000 erweitert, um Details zu den Partner zu ermitteln. Durch die beiden CASE Anweisungen werden auch Name_last bzw Name_org1 aus dem entsprechenden BUT000-Eintrag geliefert (natürlich sollte hier das Feld BUT000-TYPE zur Fallunterscheidung verwendet werden, zur Demonstration der Funktionalität reicht uns aber die Prüfung <> “).
Der interessante Teil ist aber die Definition des Parameters p_langu mit dem Datentype abap.lang (entspricht dem ABAP Dictionary Type LANG). Der Parameterwert wird in der ON-Bedingung des JOINs verwendnet, um die Einträge auf die gewünschte Sprache einzuschränken. Er kann aber genauso in die WHERE-Bedingung geschrieben werden. Die beiden Schreibweisen $parameters.p_langu und :p_langu sind gleichwertig und austauschbar.
Beim Aufruf der Data Preview erscheint jetzt zuerst ein Popup für die Parametereingabe:
Die Ergebniszeilen werden entsprechend eingeschränkt und auch die CASE Anweisung arbeitet richtig:
Der Open SQL Aufruf erfolgt ähnliche einem Methodenaufruf:
Über spezielle Parameter Annotations, die Environment Annotationen, können Systemfelder (z.B. SY-UNAME) als Defaultwerte für Parameter definiert werden. Wird der SELECT im ABAP ausgeführt, kann der Parameter weggelassen werden und wird auf den aktuellen Systemwert gesetzt:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
@AbapCatalog.sqlViewName:'ZWB_BUT050_TX4D'
@AbapCatalog.compiler.compareFilter:true
@AccessControl.authorizationCheck:#CHECK
@EndUserText.label:'BUT050 with Texts with Parameter'
Das ist zwar nett, kann aber auch über eine Where-Bedingung erreicht werden. Wirklich lustig werden Parameter aber, wenn man mit ihnen Logik in die CDS Views bring:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
@AbapCatalog.sqlViewName:'ZWB_BUT050_TX5D'
@AbapCatalog.compiler.compareFilter:true
@AccessControl.authorizationCheck:#CHECK
@EndUserText.label:'BUT050 with Texts with Parameter 1'
Wir legen einen weiteren Parameter p_name_first an und verwenden ihn in einer CASE Anweisung. Wird der Parameter mit dem Wert ‚F‘ übergeben, soll für Personen der Vorname (name_first) geliefert werden. Bei jedem anderen Wert kommt wie bisher der Nachname (name_last):
Die Ergebnislisten der beiden Select enthalten die erwarteten Namen:
Schritt 4 – Associations
Associations sind am einfachsten als „JOINs On Demand“ zu beschreiben. Durch Associations können Abhängigkeiten zwischen CDS View Entitäten (also Datenbanktabellen) abgebildet und damit komplexe Datenmodelle definiert werden. Datenbankseitig entsprechen sie JOINs. Die JOIN Bedingung wird aber nur ausgeführt, wenn wirklich Daten über die Associations gelesen werden müssen, also ein Feld aus der Association in der Select-Liste oder Where-Klausel verwendet wird.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
@AbapCatalog.sqlViewName:'ZWB_BUT050_TX6D'
@AbapCatalog.compiler.compareFilter:true
@AccessControl.authorizationCheck:#CHECK
@EndUserText.label:'BUT050 with Texts with Association'
define view Zwb_But050_Txt_Asso_E
with parameters@Environment.systemField:#SYSTEM_LANGUAGE p_langu:abap.lang
asselect from but050
// left outer join tbz9a as cattx
association[0..*]totbz9a as_cattx
on but050.reltyp=_cattx.reltyp
// and _cattx.spras = $parameters.p_langu // jetzt als FILTER!
// inner join but000 as partner1
association[1]tobut000 as_partner1
on but050.partner1=_partner1.partner
// inner join but000 as partner2
association[1]tobut000 as_partner2
on but050.partner2=_partner2.partner
{
key but050.partner1,
key but050.partner2,
key but050.date_to,
key but050.reltyp,
but050.date_from,
_cattx[spras=$parameters.p_langu].spras,
_cattx[spras=$parameters.p_langu].bez50,
_cattx[spras=$parameters.p_langu].bez50_2
_cattx[spras='D'].bez50 asbez50_d,
_cattx[spras='D'].bez50_2 asbez50_2_d,
_partner1,
_partner2
}
Zunächst modellieren wir unsere JOINs als Associations und definieren die entsprechende Kardinalität. In unserem Fall [1..1] für die Partner Beziehung und [0..*] für die Text Beziehung. Die Kardinalität dient derzeit noch hauptsächlich rein zur Abbildung des Datenmodells und wird durch die Syntaxprüfung nur teilweise berücksichtigt. Eine Ausnahme ist die Verwendung in der WHERE-Klausel, wo als Kardinalität nur [0..1] oder [1..1] erlaubt ist.
Wir verwenden hier einige Felder aus der Association _cattx mit einem FILTER auf das Feld Spras. Damit werden nur Einträge geliefert, die auch dem Filter entsprechen („Where-Klausel“). Die Texte zum Beziehungstyp werden einerseits zu übergebenen Sprache im Parameter p_langu gelesen, aber zusätzlich auch für Deutsch. Wir sehen hier auch eine Warnung bezüglich der Kardinalität ([0..*] für TBZ9A), können den View aber trotzdem ausführen:
Auch im ABAP:
Interessanterweise erhalten wir aber mehr Zeilen als über die JOIN-Verknüpfung in Schritt 3!?!
Das liegt daran, dass Associations standardmäßig als LEFT OUTER JOIN gebildet werden. Das kann aber übersteuert werden:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
@AbapCatalog.sqlViewName:'ZWB_BUT050_TX6D'
@AbapCatalog.compiler.compareFilter:true
@AccessControl.authorizationCheck:#CHECK
@EndUserText.label:'BUT050 with Texts with Association'
define view Zwb_But050_Txt_Asso_E
with parameters p_langu:abap.lang@<Environment.systemField:#SYSTEM_LANGUAGE
asselect from but050
// left outer join tbz9a as cattx
association[0..*]totbz9a as_cattx
on but050.reltyp=_cattx.reltyp
// and _cattx.spras = $parameters.p_langu // jetzt als FILTER!
// inner join but000 as partner1
association[1]tobut000 as_partner1
on but050.partner1=_partner1.partner
// inner join but000 as partner2
association[1]tobut000 as_partner2
on but050.partner2=_partner2.partner
{
key but050.partner1,
key but050.partner2,
key but050.date_to,
key but050.reltyp,
but050.date_from,
_cattx[1:inner where spras=$parameters.p_langu].spras,
_cattx[1:inner where spras=$parameters.p_langu].bez50,
_cattx[1:inner where spras=$parameters.p_langu].bez50_2,
_cattx[1:inner where spras='D'].bez50 asbez50_d,
_cattx[1:inner where spras='D'].bez50_2 asbez50_2_d,
_partner1,
_partner2
}
Über die Angabe inner in den Filterwerten, mit dem Zusatz where, wird nun ein INNER JOIN generiert. Die ebenfalls neue Anweisung 1: setzt die Kardinalität für diese Verwendung auf [0..1]. Die Warnung wird nicht mehr angezeigt:
Das Ergebnis ist wieder gleich der JOIN Variante:
Associations veröffentlichen – Pfadzugriffe
Wer sich bisher gewundert hat, warum in der SELECT-Liste der Viewdefintion die beiden Associations _partner1 und _partner2 (Alisasnamen für Associations sollten mit ‚_‘ beginnen) angegeben sind, in der Ergebnisliste aber nicht wirklich aufscheinen: Damit wird Association nur veröffentlicht. Sie kann also „von außen“ durch einen Aufrufer verwendet werden. Der Zugriff auf Associations mittels Open SQL erfolgt über Pfade:
1
2
Select PARTNER,TYPE,NAME_ORG1,NAME_LAST,MC_NAME1
from Zwb_But050_Txt_Asso_E\_partner2
Hier wird über die Entität Zwb_But050_Txt_Asso_E selektiert, es werden aber nur Felder der Association _partner2 abgerufen, also Felder aus der Datenbanktabelle BUT000. Im SQL Trace (Transaktion ST05) ist der abgesetzte SELECT Befehl ersichtlich:
Es wird also zur Laufzeit ein JOIN mit der ON-Bedingung der Association gebildet.
Natürlich kann man auch nur einzelne Felder über Pfadausdrücke ansprechen:
1
2
3
4
5
Select Zwb_But050_Txt_Asso_E~*,
\_partner2-PARTNER asp2_partner,
\_partner2-TYPE asp2_type,
\_partner2-MC_NAME1 asp2_mc_name1
from Zwb_But050_Txt_Asso_E
Oder in der Where-Klausel verwenden:
1
2
3
4
5
6
SELECT zwb_but050_txt_asso_e~*,
\_partner2-partner ASp2_partner,
\_partner2-type ASp2_type,
\_partner2-mc_name1 ASp2_mc_name1
FROM zwb_but050_txt_asso_e
WHERE\_partner1-partner<>'0000000013'
Der Zugriff auf nicht veröffentlichte Associationen von außen ist nicht möglich:
Compare Filter
Wir haben bisher immer die View-Annotation
1
@AbapCatalog.compiler.compareFilter:true
verwendet, diese aber noch nicht erklärt. Um zu verstehen, was diese macht, müssen wir uns den generierten, technischen SQL Befehl anschauen. Das ist über das Kontextmenü möglich:
Wir erkennen, dass für die Association _cattx (technischer Alias A0) nur eine JOIN Verknüpfung angelegt wird.
Setzen wir den Annotationwert auf false und betrachten den technischen SQL Befehl erneut:
Jetzt wird für jedes Association-Feld eine JOIN-Bedingung definiert!
Kardinalitätsfehler in der Where-Klausel
Für das Beispiel wurde auch die Assiocation _cattx nach außen veröffentlicht.
Schritt 5 – Viewerweiterungen
SAP bietet auch die Möglichkeit CDS Views modifikationsfrei zu erweitern. Dazu kann über einen Extend View eine Entität um zusätzliche Assiciations und Felder erweitert werden:
1
2
3
4
5
6
7
8
9
10
11
12
@AbapCatalog.sqlViewAppendName:'ZWB_BUT050_TX7D'
@EndUserText.label:'View Extend'
extend view Zwb_But050_Txt_Asso_E with Zwb_But050_Txt_Ext1_E
association[0..*]tobut100 as_roles
on _roles.partner=but050.partner2
{
but050.relnr,
_roles
}
Die Entität Zwb_But050_Txt_Asso_E liefert jetzt auch das Feld Relnr der Tabelle BUT050 und es gibt die Association _roles:
Die Data Preview bietet auch die Möglichkeit auf Assiocaitions zuzugreifen:
Daten der hinzugefügten Association _roles für eine Ergebniszeile der Entität.
Und auch im ABAP:
1
2
3
4
5
SELECT partner2 aspartner,
reltyp asreltyp,
\_partner2-mc_name1 asname,
\_roles-rltyp asroletyp
FROM ZWB_BUT050_TXT_ASSO_E.
Schritt 6 – einfach ausprobieren
CDS Views erscheinen auf den ersten Blick vielleicht etwas fremd und komplex. Aber jeder ABAP Entwickler, der bereits über ein SELECT * FROM table hinausgekommen ist und etwas Erfahrung mit ADT hat, findet sich sehr schnell zurecht! Einfach mal ein paar Beispiele ausprobieren und die Templates zum Anlegen verwendet – dann wird man die CDS Views kennen und lieben lernen! Zumindest wars bei mir so 😉
Und spätestens mit S/4 HANA kommen wir an CDS Views nicht mehr vorbei…
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:
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
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.
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
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.
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.
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.
We use cookies on our website to give you the most relevant experience by remembering your preferences and repeat visits. By clicking “Accept All”, you consent to the use of ALL the cookies. However, you may visit "Cookie Settings" to provide a controlled consent.
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. These cookies ensure basic functionalities and security features of the website, anonymously.
Cookie
Dauer
Beschreibung
cookielawinfo-checkbox-analytics
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".
cookielawinfo-checkbox-functional
11 months
The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".
cookielawinfo-checkbox-necessary
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".
cookielawinfo-checkbox-others
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.
cookielawinfo-checkbox-performance
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".
viewed_cookie_policy
11 months
The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data.
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
