Für einwertige Symbole kann jetzt ein Datenelement definiert werden. Wenn möglich, wird der eingegebene Wert mittels Konvertierungsexit in den internen Wert geändert. Dies ist für vollständige Literale und Werte möglich.
Die 3 Partner-Symbole haben über das Datenelement BU_PARTNER (bzw. dessen Domäne BU_PARTNER) eine Länge von 10 Zeichen und die Konvertierungsroutine ALPHA zugewiesen. Bevor der SELECT ausgeführt wird, werden die Symbolwerte entsprechend angepasst:
‚112‘ => ‚0000000112‘
113 => 0000000113
1234567890123 => 1234567890
Filtern nach Benutzern in der Rollenpfelge
Die Benutzer in der Cockpit Rollen Pflege (Admin-Funktion) können jetzt über die Benutzer-ID und den Benutzernamen gefiltert werden:
Filter aufrufen
Filtern nach Benutzer-ID
Gefilterte Liste und zurücksetzten des Filters
Cockpit-Rollen für Referenzuser
Auch Referenzbenutzer können jetzt Cockpit-Rollen zugewiesen werden. Die Rollen sind auch für alle Benutzer gültig, die auf dem Referenzbenutzer basieren.
Listvergleich
Eine Checkbox in der Legende des Tabellenvergleichs gibt Aufschluss darüber, ob es sich um eine gespeicherte List handelt.
Mapping im Tabellenvergleich
Saved List Kennzeichnung im Vergleich
Editorbereich teilen
Das SQL Cockpit wurde in diesem Release für eine API vorbereitet, um Daten (SQL SELECTS, Listen, Symbolwerte,…) aus verschiedenen Quellen in das Cockpit schicken zu können.
Vorerst wird darauf aber nur innerhalb des Cockpits zugegriffen: „Editor teilen“ und „Meine Queue“:
Mit Hilfe des ersten Buttons kann der User seinen derzeitigen Inhalt des SQL Bereich mit einem anderen User teilen: Ich möchte über einen SELECT mit einem Kollegen diskutieren oder Feedback dazu einholen.
SELECT (Editorbereich) teilen
Der zweite Button zeigt den „Posteingang“ des des Benutzers an.
Per Doppelklick wird der geschickte Inhalt in den Editorbereich übernommen.
Wird eine Eintrag nicht mehr benötigt, kann er gelöscht werden.
Premium Version – PDF Attachments Erweiterung
Ab jetzt kann ein Administrator eine maximale Größe von PDF-Dokument SQL Cockpit – Admin Bereich festlegen. Wird diese Größe überschritten, wird das PDF Dokument auf mehrere aufgeteilt und als separate Mail verschickt.
Der Änderunglog kann jetzt auch als Attachment an das Solution Manager Ticket gehängt werden. Entweder als Textdokument oder als PDF-Dokumente mit der entsprechenden Maximalgröße.
Premium Edition – Admin Bereich
Zwei verschiedene Formulare stehen ab jetzt zur Verfügung:
You might have heard about our Cadaxo SQL Cockpit already – it is an Add-on to your SAP System. Here is an animated video which shows very nice overview about it:
In this blog post I am not going to describe every possible use case and feature of the SQL Cockpit. I think everybody needs to find the beauty of the SQL Cockpit by himself/herself. This is how I found mine.
I am professionally the youngest guy in our Cadaxo Team but I adopted the usage of SQL Cockpit super-fast. Here are my 7 reasons why you should use Cadaxo SQL Cockpit as well.
1. Writing complicated queries has never been easier
When I started with ABAP couple years ago I was sometimes going crazy with the limitations of SE16 and other transactions. Now I read data from the database almost every time by writing a simple SELECT to SQL Cockpit.
But it is not only about simple SELECTs of course. As an ABAP Developer when I run into very complicated SELECT with JOINs or WHERE conditions I simply copy the SELECT from my code to SQL Cockpit and see the results/error immediately. It saves my time with beloved debugger.
2. Generating Reports
Not only that all queries stay in History for later usage, it is also possible to generate reports out of your queries. It is really simple – there is a wizard for it. You don’t need any ABAP skills to write cool Reports very fast with select-options and everything you need.
3. Comparing Results on Site
Do you remember last time when you copied/exported data from one table to your spreadsheet, then from another table and another table… and then visually compared the results?
Well, in SQL Cockpit I just run two or more SQL statements next to each other and can compare the results with our Compare result list function, while staying on the same site. No CTRL+C, no CTRL+V, no Excel 😊
4. Modern Up-To-Date ABAP
SQL Cockpit supports Open SQL Expressions, Functions, Host Expressions, Unions… (more info here)
5. CDS Views Supported
… and yes, (one of the FAQ these days) even access to CDS Views works very well.
6. Talk about performance
As a developer, I like to think about my code before saving it. In SQL Cockpit I can see the time needed to perform my SQL statement. I can even write two SQL statements and compare its performance. (Usually the first thought – the first query – is slower 😉
7. Overall user experience and support
I must say, I really like working with SQL Cockpit. We at Cadaxo do care about User Experience, all features are just one click away.
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…
Für die Version 3.2 unseres SQL Cockpits haben wir neben einigen kleineren Verbesserungen und Korrekturen ein paar sehr interessante Features eingebaut bzw. erweitert.
Vergleichen von Ergebnislisten
Der Vergleich von Ergebnislisten wurde komplett runderneuert. Nun können beliebige Ergebnislisten miteinander verglichen werden. Über eine komfortable Mappingoberfläche können die zu vergleichenden Felder verlinkt werden. Es spielt dabei keine Rolle, ob es sich dabei um neu erstellte Ergebnislisten oder um gespeicherte Listen handelt.
Tipp: Gespeicherte Listen können exportiert bzw. importiert werden. Dadurch ist ein systemübergreifender Ergebnislistenvergleich möglich!
Open SQL Features 7.50
SAP hat mit 7.40 SP5 / SP8 bzw. 7.50 umfangreiche Erweiterungen für den ABAP Open SQL Syntax aufgenommen. Das Cadaxo SQL Cockpit 3.2 unterstützt alle diese neuen SQL Features.
Nachfolgend eine Aufstellung der wichtigsten ABAP Open SQL Features:
Open SQL Expressions
Open SQL Functions
Host Expressions
Unions
Zugriff auf CDS Views
Pfadausdrücke für Assoziationen von CDS-Views
CDS-Views mit Eingabeparametern
Integration ADT
Über die Usersettings kann sich nun jeder Anwender einstellen, ob die Vorwärtsnavigation bei einem Doppelklick auf eine Tabelle wie bisher innerhalb des SAP Gui oder ob die Anzeige mit den ADT (ABAP Developer Tools = Eclipse!) erfolgen soll.
Beispielsweise können CDS Views nur mit den ABAP Developer Tools gepflegt werden. Innerhalb von SAP Gui ist lediglich eine Anzeige möglich.
Elementinfo für CDS Views
Die Anzeige der CDS Views wurde in die Elementinfo aufgenommen. Die Element Info sorgt für eine bessere Usability im SQL Cockpit. Notwendige Informationen zu einer DB-Tabelle werden einfach angezeigt, wenn man einen Moment mit dem Mauszeiger über einen Tabellen- oder CDS-View-Namen fährt.
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.
Das Sommer-Release des Cadaxo SQL Cockpits ist da! Bei der neuen 3.1 Version wurde der Fokus ganz klar auf Bug-Fixing gelegt, um den komplett neuen Parser, der alle neuen Open SQL Features am ABAP 7.40 unterstützt, noch stabiler zu machen.
Der Report Generator wurden ebenfalls auf Vordermann gebracht. Es können nun alle SQL Statements, die die neue Open SQL Syntax enthalten oder Zugriff auf CDS Views bieten, auf Knopfdruck in ein gewöhnlichen ABAP Report übernommen werden.
Neue Features
Auch diese neuen Features sind Bestandteil des brandneuen Cockpit Releases 3.1
Element Info
Die Element Info sorgt für eine noch bessere Usability im SQL Cockpit und lässt Sie noch schneller Ihre SQL Statements gestalten. Sie können sich nun alle notwendigen Informationen zu einer DB-Tabelle anzeigen lassen, indem Sie nur mit dem Mauszeiger über den Tabellen-Namen fahren.
Sie sehen alle wichtigen Informationen, wie Spaltennamen und die dazugehörige Beschreibung auf einen Blick. Mit Doppelklick oder Drag&Drop können Sie die Spaltennamen einfach in den Editor-Bereich des SQL Cockpits übernehmen uns sparen so wertvolle Zeit, indem Sie nicht selbt die Spaltennamen suchen und eintippen müssen.
Dieses kurze Video zeigt das neue Feature auf einen Blick: Element Info Video
Vergleichen von Ergebnislisten
Ab sofort können nun nicht nur gleiche Ergebnislisten miteinander verglichen werden, sondern auch Listen, die nicht den komplett gleichen Aufbau haben. Es müssen lediglich die Schlüsselfelder übereinstimmen. Alle namensgleichen Spalten werden gegenübergestellt und die Differenzen aufbereitet dargestellt.
Dabei können auch gespeicherte Listen, die einen unaktuellen Datenbestand zeigen, mit aktuell ausgewerteten Ergebnislisten verglichen werden.
Das Vergleichstool des SQL Cockpits bietet zudem eine komfortable Oberfläche mit vielen Funktionen, um die Differenzen des Vergleichs besser auswerten zu können.
Mit den folgenden Informationen und Video-Tutorials können auch Sie von den Vorteilen des SQL Cockpits profitieren.
Cockpit Überblick
Sie wollen keine Zeit verschwenden und sofort mit Ihren Auswertungen losstarten? Nehmen Sie sich einen Augenblick Zeit und sehen Sie mit diesem Video alle wichtigsten Funktionen des Cockpits auf einem Blick. Nutzen Sie das volle Potential des Cockpits, um schnell zu Ihren Daten zu kommen.
SQL
Unendliche Möglichkeiten beim Auswerten mit den SQL Cockpit. Durch Ausführen mehrerer SELECTs gleichzeitig, lassen sich auch die komplexesten Datenkonstellationen auf einem Blick auswerten. Hier ein kurzes Video!
Varianten
Mit den SQL Cockpit Varianten können Sie nicht nur ihre SELECT-Statements speichern, sondern auch mit anderen teilen. Hier ein kurzes HowTo-Tutorial.
Symbole
Verfeinern Sie ihre SQL Statements und sparen Sie Zeit mit Hilfe von Symbolen. Neben eigenen Variablen, die Sie selbst definieren und in Ihrem SELECT-Statement verwenden können, lassen sich auch Systemsymbole verwenden. Verschaffen Sie sich hier einen Überblick.
Historie
Sie wollen ein SELECT-Statement, dass Sie vor einer Woche abgesetzt haben, nochmal ausführen, haben jedoch vergessen es zu speichern? Kein Problem – im SQL Cockpit sehen Sie alle Ihre abgesetzten Statements und können es immer wieder ausführen. Hier sehen Sie wie!
Batch
Langläufer? Kein Problem – Jede Abfrage lässt sich auch als ein Hintergrund-Job definieren. Komfortabel erstellen Sie in Sekunden einen richtigen Batch-Job und müssen sich anschließend nicht durch die Spool-Aufträge quälen, sondern können bequem das Erlebnis im SQL Cockpit anschauen. Hier zum Video!
Trace
Falls Sie Ihre SQL Statements analysieren und optimieren möchten, steht bei jedem ausgeführten Statement auch die Laufzeit. Wenn Ihnen das nicht reicht, können Sie noch den SQL-Trace einschalten, um Ihre Statements zu analysieren. Hier sehen Sie wie.
Report Generator
Das Cockpit hat für jeden was. Auch Endanwender bzw. Benutzer ohne Open SQL Kenntnisse können vom Cockpit profitieren. Mit einem Mausklick lassen sich alle Datenabfragen als ein ABAP Report generieren. Durch Klicken auf den Template-Button (Zauberstab) öffnet sich ein Wizard, mit dem Sie den Report so bauen können, dass alle Anforderungen erfüllt sind. Vorgefertigtes Coding, selbst für komplexere Anforderungen, wie z.B. ALV Ereignishandler usw.
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.
