Trans­port­mög­lich­kei­ten für eine SAP HANA Da­ten­bank

Ne­ben den gäng­igen Trans­port Tools von SAP, z.B. das er­wei­ter­te Change and Trans­port Sys­tem (CTS+) oder die Trans­ak­tion SCTS_HTA in ABAP, bie­tet auch Mi­cro­soft ei­ne Trans­port­mög­lich­keit für die SAP HANA Da­ten­bank an. In die­sem Blog­bei­trag wird das Trans­port Tool MS Azure Pipe­lines für die SAP HANA Da­ten­bank tech­nisch grob prä­sen­tiert. Des Weiteren wird die Mög­lich­keit der In­­te­gra­tion von wei­te­ren MS Azure Tools (MS Azure Boards, MS Azure Repos und MS Azure Test Plans) für ein er­folg­rei­ches Pro­jekt­ma­nage­ment eben­falls kennt­lich ge­macht.

Ein­schrän­kun­gen von CTS+ und SCTS_HTA

Ein Nach­teil von dem Tool er­wei­ter­tes Chan­ge and Trans­port System (CTS+) ist, dass bei einem Transport alle Ent­wick­lungs­ob­jek­te in ei­ner Delivery Unit transportiert werden. Es ist nicht möglich einzelne Ent­wick­lungs­ob­jek­te, die im selben Paket liegen, aus einer De­li­very Unit zu entfernen. Al­so wer­den ent­we­der alle Ent­wick­lungs­ob­jek­te ei­nes Pa­kets trans­­por­tiert, welches einer Delivery Unit zu­ge­ordnet ist, oder gar keine. Der Nachteil von SCTS_HTA ist, dass hier ein ABAP-Sys­tem benötigt wird, da bei der Syn­chro­ni­sie­rung mit der Transaktion SCTS_HTA die aus­gewählten SAP HANA Objekte und Pakete aus dem SAP HANA Re­pository in das HTA-Re­po­sitory in ABAP übertragen und einem Trans­port­auftrag hinzugefügt werden.

Al­ter­na­ti­ve zu CTS+ und SCTS_HTA

In den meisten Fällen findet das Deployment auf der SAP HANA Datenbank im Rahmen ei­nes Pro­jekts statt, da so ein Pro­jekt mittels eines Projektmanagement Tools überwacht, gesteuert und ge­testet werden muss. Mi­cro­soft bietet für das Pro­jekt­management, De­ploy­ment und Testen die nö­tige Software un­ter einem Dach an. Für das Pro­jekt­ma­nage­ment steht die MS Azure Boards zur Ver­fü­gung und die MS Azure Test Plans deckt das Testen in einem Projekt ab. Die Kombination aus MS Azure Repos und MS Azure Pipelines wird für das Deployment verwendet.

Trans­port­kon­zept mit MS Azure Pipe­lines

Für den Trans­port wer­den so­ge­nann­te MS Azure Re­pos aus MS Azure Pipe­lines kon­su­miert. Die MS Azure Re­pos ste­llen in die­sem Kon­text die SAP HANA Work­spa­ces dar, d.h. pro SAP HANA Sys­tem wird ein Branch in MS Azure Re­pos er­stellt. So­mit ist für die­se Va­rian­te von Mi­cro­soft Azure Re­po­si­to­ry Bran­ches pro SAP HANA Sys­tem not­wen­dig. Die Bran­ches spie­geln die Da­ten­bank­ob­jekt­ver­sio­nen der je­wei­li­gen SAP HANA Da­ten­bank­ob­jek­ten wider. Der Trans­port­fluss von der Ent­wick­lungs­­branch bis zum Pro­duk­tiv­branch kann mi­ttels Mi­cro­soft Tools auf­ge­baut wer­den. Dies wird in der fol­gen­den Gra­fik ge­zeigt.

Alle Bilder auf dieser Seite © 2022. BIG.Cube GmbH. Alle Rechte vorbehalten.

Die Ent­wick­lung fin­det wei­ter­hin wie ge­wohnt auf dem Ent­wick­lungs­sys­tem statt. So­bald die Ent­wick­lung fer­tig ist, wird sie von der oder dem je­wei­li­gen Ent­wick­ler:in in den Ent­wick­lungs­branch hoch­ge­la­den. Das Hoch­la­den kann mit der Ver­sions­kon­tro­lle Soft­ware Git er­fol­gen. Der nächs­te Schritt ist die Ent­wick­lung via ei­nes Pull Re­quests in den Qua­li­täts­branch zu trans­por­tie­ren. Ein Pull Re­quest wird für das Trans­por­tie­ren von Ob­jekt­ver­sio­nen von ei­nem Quell Branch zu ei­nem Ziel Branch ver­wen­det.

De­ploy­ment auf den Sys­temen

Zuerst muss der Pull Re­quest von der oder dem Auf­trag­ge­ber:in ge­neh­migt wer­den. Nach­­dem der Pull Re­quest ab­ge­schlo­ssen ist, lan­det die Ent­wick­lung in dem Qua­li­täts­branch und im An­schluss wird die MS Azure Pipe­line ge­tri­ggert und das De­ploy­ment auf dem Qua­li­täts­sys­tem durch­ge­führt. Das De­ploy­ment auf dem Qua­li­täts­sys­tem er­folgt über ei­nem Ser­ver (z.B. MS Ser­ver), auf dem ein:e tech­ni­sche:r Be­nu­tzer:in (Agent) exis­tiert, der oder die das De­ploy­ment auf der SAP HANA Da­ten­bank mit Hil­fe der Soft­ware regi.exe durch­führt. Je­doch ist für die Ak­ti­vie­rung der Da­ten­bank­ob­jek­te auf dem SAP HANA Sys­tem ist ein:e tech­ni­sche:r Da­ten­bank­be­nu­tzer:in mit ent­sprech­en­den Da­ten­bank­be­rech­ti­gun­gen not­wen­dig. So­bald alle Da­ten­bank­ob­jek­te auf dem Test­sys­tem er­folg­reich ak­ti­viert wurden, wird das De­ploy­ment auf Qua­li­tät ge­prüft. Wenn die Test­fä­lle auf dem Qua­li­täts­sys­tem er­folg­reich aus­ge­führt wor­den sind, kann die Ent­wick­lung zum Pro­duk­tiv­branch tran­spor­tiert wer­den. Der Trans­port er­folgt wie­der mit ei­nem Pull Re­quest, das De­ploy­ment auf dem Pro­duk­tiv­sys­tem ge­schieht a­na­log zum Test­sys­tem. Nach­­dem De­ploy­ment auf die pro­duk­ti­ve SAP HANA Da­ten­bank ist die Live­setzung ei­ner Ent­wick­lung ab­ge­schlo­ssen.

Fazit

Das Trans­por­tie­ren mit MS Azure Pipe­lines ist so­wohl für SAP HANA XS Cla­ssic Da­ten­bank­ob­jek­te als auch für SAP HANA XS Ad­vanced App­­li­ka­tio­nen ge­eig­net. Falls auf der SAP HANA Da­ten­bank ei­ne An­wen­dung läuft, die so­wohl XSC als auch XSA be­nö­tigt, braucht man so­mit nur ein Tool für die bei­den SAP HANA XS Ver­sio­nen. Für die Trans­por­te von SAP HANA XSA An­wen­dun­gen ist ne­ben MS Azure Pipe­lines ei­ne zu­sätz­li­che Soft­ware nö­tig, wie z.B. das MBT Tool.

Verfasst von Veli Hasanca

Beitrag teilen

Weitere spannende Themen aus unserem Newsroom

Shortcuts für SAP BW in Eclipse

In diesem Blogbeitrag werden fünf einfache Shortcuts erläutert, mit denen...

Mehr lesen
Erfolgsfaktoren BW/4HANA Migration

Erfolgsfaktoren für eine SAP BW/4HANA Migration

In diesem Beitrag wird aufgezeigt, welche Erfolgsfaktoren bei einer SAP...

Mehr lesen
DSAG Jahresrückblick 22

Rückblick zum DSAG Jahreskongress 2022

Diese Themen wurden auf dem DSAG Jahreskongress 2022 diskutiert.

Mehr lesen

SAP HANA Daten­bank als Grund­lage für be­stehende SAP BW In­stalla­tionen

Immer mehr Anwender von SAP Systemen imple­men­tieren die SAP HANA Daten­bank als Grund­lage für die be­stehende SAP BW In­stalla­tionen. Der Vor­teil einer SAP HANA Daten­bank für ein BW System ist, dass beim An­legen von BW Ob­jekten SAP HANA-Views gen­eriert werden können. Alle gene­rierten SAP HANA Views sind vom Typ Calculation View. Durch die Gene­rierung von SAP HANA Views werden BW Daten nach SAP HANA publiziert, wobei diese SAP HANA Views direkt auf die Daten und Ta­bellen zeigen. Damit können die BW Daten direkt in SAP HANA kon­sumiert werden. Es ist nicht em­pfohlen, von BW Systemen er­stellte Calculation Views auf der SAP HANA Datenbank zu ändern, da die Calculation Views jederzeit vom BW System erneut über­schrieben werden können (Quelle: help.sap.com).

Manu­elle Zu­wei­sung von Privi­legien sorgt für hohen Auf­wand und ist fehler­an­fällig

Um nun die Calculation Views selek­tieren zu können, be­nötigt ein Be­nutzer auf der SAP HANA Daten­bank die ent­sprechenden HANA Privi­legien. Die Zu­weisung des Privi­legs erfolgt manuell über einem Ad­mini­strator. Eine manuelle Zu­weisung von Berech­tigungen ist nicht sehr performant und kann, je nach Anzahl von zu be­rechtigenden Calculation Views, sehr schnell mehrere Stunden oder sogar Tage in An­spruch nehmen.
In diesem Blog­beitrag stellen wir eine Mög­lich­keit vor, wie das Be­rechtigen von Calculation Views auto­matisiert erfolgen kann. Dieser Auto­mati­sierungs­prozess gilt auch für die Calculation Views, die direkt auf der SAP HANA Daten­bank er­stellt werden.

Be­nötigte Daten­bank­objekte

Um das Be­rechtigen von Calculation Views auf der SAP HANA Daten­bank zu auto­matisieren, müssen einige SAP HANA Daten­bank­objekte angelegt und ent­sprechend konfiguriert werden. Die folgende Tabelle lieft hierzu die nötige Übersicht und Be­schreibung.
SAP HANA Datenbankobjekt Beschreibung

Calculation View

Die Calculation View wird aus dem BW-System auf der SAP HANA Datenbank erstellt.

CSV

Durch die CSV Datei wird die Wartung von (neuen) Calculation View Berechtigungen vereinfacht. Hier werden die Rollen an die zu berechtigenden Calculation Views zugeordnet.

HDBTable

Durch die HDBTABLE wird eine Datenbanktabelle erzeugt, die den Inhalt der CSV Datei reflektiert.

HDBTI

Das HDBTI Objekt füllt die HDBTABLE mit dem Inhalt aus der CSV Datei.

HDBSchema

Für einige Datenbankobjekte muss ein HDBSCHEMA Objekt angelegt werden, z.b. Stored Procedure oder HDBTABLE.

Role

In die HANA Rollen werden die SELECT Rechte von Calculation Views entsprechend der Zuordnungstabelle (CSV) hinzugefügt.

Stored Procedure

Die Prozedur ermittelt die nicht berechtigten Calculation Views und führt die Berechtigung durch.

XS Job

Der XS Job ruft die Stored Procedure auf.

XS Job Schedule

Ein XS Job Schedule steuert die Ausführung des XS Jobs mittels eines XS Crons.

Technical User

Der Technischer User führt den XS Job aus.

Beispiel­szenario

Die Repository Rolle authorization.roles.calulationview::SELECT_CALCULATION_VIEW soll mit einem SELECT Privileg für die Calculation View MyCalcView er­weitert werden. Der Zustand der Repository Rolle vor der Zu­weisung verfügt über keine Objekt Privi­legien. Dies kann in HANA Studio unter HANA Ad­mini­str­ations­sicht wie folgt geprüft werden.
Die Repository Rolle authorization.roles.calulationview: :SELECT_CALCULATION_VIEW soll mit einem SELECT Privileg für die Calculation View MyCalcView er­weitert werden. Der Zustand der Repository Rolle vor der Zu­weisung verfügt über keine Objekt Privi­legien. Dies kann in HANA Studio unter HANA Ad­mini­str­ations­sicht wie folgt geprüft werden.
  1. Filtern der Runtime Rollenname unter Security/Role
  2. Öffnen der Objekt Privilegien Tab der Runtime Rolle

Die zu berechtigende Calculation View befindet sich in der Repository unter dem Pfad bigcube.app.vha und wird wie folgt in die Steuerungstabelle eingetragen.

  1. CATALOG_ROLE_NAME: Hier muss die Rollen­name ohne Wildcard ein­getragen werden.
  2. CALCULATION_VIEW_PATH: Hier wird der Pfad ein­getragen (Wildcard möglich)
  3. CALCULATION_VIEW_NAME: Hier wird der Name der Calculation View ein­getragen (Wildcard möglich).

Die CSV Datei kann mit Microsoft Excel ge­öffnet werden. Das Prozent Zeichen dient in der Excel Tabelle als eine Wild­card. Der Pfad wird hier mit einem Wildcard ver­sehen und der Name des Calculation Views wird am Ende mit einer WildCard ein­getragen. Der Wild­card ist für die Spalten CALCULATION_VIEW_PATH und CALCULATION_VIEW_NAME be­liebig ein­setzbar, zum Bei­spiel auch im View Namen MyCalcView%. Nachdem die Steuerungs­tabelle fertig ge­pflegt ist, muss die CSV Datei ge­speichert und aktiviert werden. Erst danach ist das Mapping gültig.

Der XS Job wird nun das Mapping gemäß der Steuerungs­tabelle durch­führen. Sobald das Mapping durch­geführt wurde, wird die Rolle um das ent­sprechende Calculation View Be­rechtigung (SELECT) automatisch er­weitert.
  1. Filtern der Runtime Rollen­name unter Security/Role
  2. Öffnen der Objekt Privi­legien Tab der Runtime Rolle
  3. Öffnen von Objekt Privi­legien des aus­gewählten Objekts (Calculation View)
Jede Ausführung eines XS Jobs erzeugt einen Log­eintrag in der Log­tabelle. Damit die Log­tabelle auch ent­sprechend aufgeräumt wird, muss für das Auf­räumen der Log­tabelle gesorgt werden. Das Auf­räumen kann in der Stored Procedure, die durch dem Tech­nischen User aufgerufen wird, er­folgen.

Fazit

Die anzulegenden HANA Native Daten­bank­objekte müssen je nach Kunden­an­forderung an­gepasst und definiert werden.

  • HDBSchema
  • HDBTable
  • HDBTI
  • CSV
  • XS Job
  • Technical User

Die folgenden HANA Native Daten­bank­objekte werden je nach Kunden­anforderung imple­mentiert. In diesen Ob­jekten wird die Logik der Auto­mati­sierung inte­griert. Hierbei unter­stützen Sie gerne unsere Experten aus dem Team SAP Basis (mehr über SAP Basis und Hana Platform Services erfahren >>).

  • Stored Procedure
  • XS Job Schedule
  • HDBRole

Mit diesem Prozess können nun die Calculation Views auf der SAP HANA Daten­­bank auto­­matisiert be­rechtigt werden. Die Steuerung der Calculation View Berechtigungen er­folgt an einer zen­tralen Stelle in Form einer Excel Tabelle. Somit kann man sich den manuellen Auf­wand, um neue Calculation Views zu be­rechtigen sparen. Die Auto­mati­sierung ist auch für andere HANA Native Objekte möglich, zum Beispiel HDBSchema, HDBView, HDBTable, HDBdd …

Verfasst von Veli Hasanca

Jetzt Kontakt aufnehmen

Beitrag teilen

Weitere spannende Themen aus unserem Newsroom

Wir sind nach ISO 22301 zertifiziert

BIG.Cube ist ein verlässlicher Partner und Arbeitgeber auch in Krisensituationen...

Mehr lesen

Wir gehören zu „Deutschlands besten Arbeitgebern“

Als einer der Top-100-Arbeitgeber Deutschlands mit erneuter „Great Place to...

Mehr lesen

Unser Herzensprojekt: Die Stiftung AKM in München

Schon seit einiger Zeit unterstützten wir als BIG.Cube GmbH die...

Mehr lesen

Ent­wicklung von SAPUI5 Custom Controls - Bei­spiele aus der Praxis​

In einem vor­herigen Blog­bei­trag wurde auf­ge­zeigt, welche Vor­be­rei­tung die Er­stellung von SAPUI5 Custom Controls ben­ötigt und wie diese dann Schritt für Schritt ent­wickelt werden >>.
Das sich auch komplett neue Controls mit einfachen HTML und CSS Kennt­­nissen rea­­lisieren lassen, wird im nach­folgenden Beitrag auf­ge­zeigt. Wie das genau funkt­ioniert stellen wir anhand von zwei Bei­spielen aus aktuellen Kunden­proj­ekten vor­. Bei der ersten Ent­wicklung handelt es sich um eine Er­weiterung eines be­stehenden Controls. Bei der zweiten ist es eine komplette Neu-Entwicklung mit eigener renderer-Funktion.

Er­weiterung eines SAPUI5 Custom Controls

Die Er­weiterung kommt von einer Desktop-Applikation, welche für mobile End­geräte nicht zur Ver­fügung steht. Das Design-Team im Projekt wollte einen Button, der auf Mouse-Hover unter­schiedliche Farben und Icons dar­stellt. Links sieht man ein Icon / Button mit einem Haken als Icon. Hovert man mit der Maus über dieses Icon, tauscht es sich zu einem Blei­stift-Icon aus.
SAPUI5 Custom Controls
SAPUI5 Custom Controls
SAPUI5 Custom Controls
Bei dem vor­liegen­dem Bei­spiel bietet es sich an, ein be­stehendes Control zu er­weitern. So können die be­stehenden Funk­tionalitäten wie z.B. Properties, Events oder Aggregations normal weiter­ver­wendet werden. Wir haben uns für eine Er­weiterung des Controls sap.ui.core.Icon en­tschieden, da dort bereits das Property für hoverColor vor­handen ist. Somit musste ledig­lich ein Aus­tausch des Icons vor­genommen werden.
Das sap.ui.core.Icon besitzt bereits das Property „src“ für die Angabe eines Icons. In unserem Custom Control haben wir zwei neue Properties er­zeugt, die „defaultSrc“ und „hoverSrc“ heißen. Sobald das Mouse-Event „onmouseover“ aus­gelöst wird, wird der Wert aus dem hoverSRC in das be­stehende src ge­schrieben. Wird im Anschluss wieder das „onmouseout“ aus­geführt, wird das defaultSRC in src ge­schrieben. Durch die Ver­wendung der bereits bes­tehenden setSrc-Funktion aus dem Ursprungs­control muss das Rendering nicht ange­passt werden. Es wird im Hinter­grund nur das Icon aus­getauscht.

Durch die Ausführung einer Setter-Funktion eines Controls wird immer die renderer-Funk­tion ge­triggert. Daher muss hier in den ent­sprechen­den mouse-Events dies nicht selbst ausgelöst werden.

Neu-Ent­wicklung eines Controls

In einem weiteren Bei­spiel sollte ein be­stimmtes Chart ge­baut werden, welches im Standard von SAPUI5 so nicht vor­kommt.

Dieses Chart zeigt immer einen Wert zwischen 0 und 100 an, be­steht aus einem Farb­verlauf im Balken, soll die Y-Achse in 20er Schritten dar­stellen und eigene Farben und X-Achsen­be­schrif­tungen ent­gegen­nehmen können.
In einfaches HTML runter­ge­brochen ist dies kein großes Hexenwerk. Es sind ledig­lich ein paar Labels, Linien und ein Rech­teck mit einem Gradienten. Daher wurde hier auf die Verwendung eines Charts-Framework (z.B. D3.js) ver­zichtet und dies als ein eigenes Custom Control entwickelt. Als Parameter wurden 5 ver­schiedene Farben, sowie ein Wert und eine X-Achsen Be­schriftung erwartet:

  • colorBarRGB (Die Farbe, auf welche der trans­pa­rente Gradient auf­gebaut werden soll)
  • colorBarAccentRGB (Die Farbe, welche die oberste Linie auf dem Balken dar­stellen soll)
  • colorNumberRGB (Die Farbe, in welcher die an­ge­zeigte Zahl dar­ge­stellt werden soll)
  • colorXAxisRGB (Die Farbe, in welcher die X-Achse dar­ge­stellt werden soll)
  • colorXAxisDescRGB (Die Farbe, in welcher die X-Achsen­be­schrei­bung dar­gestellt werden soll)
  • value (Der Wert, auf deren Basis der Balken auf­gebaut wird)
  • xAxisName (Die an­zu­zeigende X-Achsen Beschriftung)
Die Renderer-Funktion sieht zunächst folgender­maßen aus:
Der übergebene oRM steht für den RenderManager von SAPUI5. Das über­gebene oControl ist die Custom Control Instanz, aus der die Properties aus­gelesen werden können. Zunächst beginnt man mit einem div, welches am Ende wieder ge­schlossen wird. In das Div selbst werden noch die ControlData und CSS-Classes ge­schrieben, welche über das XML über­geben werden können. Innerhalb der beiden Div-Tags kann nun das eigene HTML ge­schrieben werden, welches das Custom Control mit Leben befüllt. Dies wurde hier in drei eigene Methoden aus­gelagert. Innerhalb der Methoden wurden wiederum einzelne Divs erzeugt, Styles hinzu­gefügt und am Ende an die Haupt-Renderer Funktion zurück über­geben. Um nicht umständliche String-Konkatenationen durch­führen zu müssen, werden in den drei aus­gelagerten Methoden Div-Objekte erzeugt. Diese werden von jQuery in einen HTML-String um­gewandelt und so an die write-Funktion über­geben. Hier ist als Bei­spiel die Funktion zu sehen, welche für den Hinter­grund und die X- und Y-Achsen verant­wortlich sind.

Fazit

In diesem Beitrag wurde anhand zweier aktueller Kundenbeispiele aufgezeigt, dass die Ent­wicklung von Custom Controls nicht mit einem enormen Aufwand ver­bunden sein muss. Oftmals können diese einfach erweitert werden. Auch Neu-Entwicklungen lassen sich mit einfachen HTML und CSS Kennt­nissen schnell und bequem rea­lisieren – und das ohne große Budgets und lang­fristi­gen Ressourcen­ein­satz.

Verfasst von Martika Möller

Beitrag teilen

Weitere spannende Themen aus unserem Newsroom

Shortcuts für SAP BW in Eclipse

In diesem Blogbeitrag werden fünf einfache Shortcuts erläutert, mit denen...

Mehr lesen
Datenqualität SAP Q-THOR

Datenqualität in SAP BW: Daten ohne Programmierung plausibilisieren

Unsere Standard-Software Q-THOR kann die Datenqualität in SAP BW Systemen...

Mehr lesen

SAP HANA Transport mit MS Azure Pipelines

In diesem Beitrag wird das Transport Tool MS Azure Pipelines...

Mehr lesen

Warum sich für eigene SAPUI5 Custom Controls entscheiden?

Je mehr SAPUI5 App­li­ka­tionen Sie ent­wickeln, desto mehr lernen Sie die Grenzen und Ein­schränkungen kennen. Diese weisen entweder die SAP Fiori Guide­lines oder die Controls selbst auf. Schnell kommt in einem Kunden­projekt die Aussage: „Kann das nicht irgendwie umgesetzt werden?“ Hier lautet oftmals die schnelle Antwort, dass dies zu teuer oder nicht möglich sei.

Das muss jedoch nicht sein! Wer sich einmal mit SAPUI5 Custom Controls be­schäftigt, kann schnell einschätzen, welche An­forder­ungen trotz Eigen­ent­wicklung im Hand­um­drehen realisiert werden können.

Nicht einfach los­legen

Als erstes und wichtigstes To-do sollten Sie bei Kunden­projekten die Veran­twort­lichen in­for­mieren, dass diese spezielle An­forder­ung nicht mit Standard­mitteln der SAP zu lösen ist. Da Unter­nehmen häufig Richt­linien bezüglich Eigen­ent­wicklung haben, muss dies vor dem Start der Ent­wick­lung des Custom Controls geklärt werden.

Weiterhin ist es sinnvoll, über die Risiken und Folgen auf­zu­klären. Je nachdem, welche Funkt­io­nali­tät das Custom Control bereit­stellt oder welche be­stehen­den Controls es er­weitert, muss bei einem SAPUI5-Versions Upgrade die Funktions­fähig­keit sicher­ge­stellt werden. Im schlechtes­ten Fall müssen an dem SAPUI5 Custom Control An­passungen vor­ge­nommen werden, damit es mit der neuen SAPUI5 Version identisch aussieht bzw. sich identisch verhält.

Nachdem die For­malitäten geklärt sind, geht es an die eigent­liche Arbeit. Hierbei gilt es, die An­forder­ung an die Eigen­ent­wicklung genau zu ver­stehen. Im Folgenden werden die Grundlagen der Er­stellung von SAPUI5 Custom Controls be­leuchtet. In unserem nächsten Beitrag stellen wir zwei Beispiele aus unseren Kunden­projekten vor.

Wie werden SAPUI5 Custom Controls erstellt

Ein Custom Control ist zunächst sehr ähnlich zu einem Controller auf­gebaut. Im oberen Teil wird defi­niert, welche anderen Controls be­nötigt werden oder welche Files im­portiert werden sollen. Auf Basis eines der über­gebenen Controls wird mittels der „extend“-Funktion eine Er­weiter­ung gebaut.

Sollte sich kein ge­eignetes Control finden, welches er­weitert werden kann, wird das sap.ui.core.Control heran­ge­zogen. Dieses Control stellt die Basis aller anderen Controls dar. Der Name des Custom Controls setzt sich aus dem Namespace der App und einem spe­zifisch­en Namen zusammen. Um nicht durch­einander zu geraten, sollte auch die js-Datei den selben Namen tragen.
Der „extend“-Funktion wird noch ein Objekt über­geben, bei dem sich z.B. neue Properties oder Events defi­nieren lassen. Wichtig bei jedem Custom Control ist, dass die „renderer“-Funktion vo­rhanden ist. Hierbei bietet sich oft die „renderer“-Funktion des zu er­weiterten Controls an. Alternativ muss diese selbst geschrieben werden (beide Arten werden in dem weiteren Blogbeitrag aufgegriffen).

Ver­wen­dung eines SAPUI5 Custom Control

Soll das Custom Control innerhalb des Views ver­wendet werden, muss zunächst wie bei einer zu­sätzlichen SAPUI5-Library der Pfad und ein Kürzel defi­niert werden.
In diesem Bei­spiel gibt es im root-Pfad einen Ordner, der sich „controls“ nennt. Inner­halb dieses Ordners liegt eine MeinCustomControl.js Datei, welche das Custom Control wider­spieg­elt. Inner­halb des XMLs stehen zum einen alle ver­erbten, als auch alle neuen Properties, Events, Aggregations und Associations zur Verfügung. Daher kann es wie ein normales Control der SAPUI5 Library ver­wendet werden.

Hin­zu­fügen weiterer Properties

Benötigt ein Custom Control ein wei­teres Property, wird dies inner­halb des Properties-Objekts defi­niert. Im folgenden Bei­spiel heißt das Property „secondText“ und ist vom Typ ein „string“. Zus­ätzlich lässt sich noch ein defaultValue defi­nie­ren, welcher hier ein leerer String ist.
Für Properties stehen die bekannten SAPUI5-Types zur Verfügung:
  • string
  • boolean
  • int
  • float
  • any
  • object
  • arrays wie z.B. string[]
  • spe­zielle SAPUI5-Types wie z.B. „sap.ui.core.CSSSize” oder andere Con­trols
Der DefaultValue ist kein Pflichtfeld und kann somit auch leer­ge­lassen werden. Das SAPUI5 Frame­work erzeugt auto­ma­tisch aus dem neuen Property Setter und Getter Methoden. Diese können sowohl inner­halb des Custom Controls, als auch inner­halb eines Controllers ver­wendet werden. In unserem Bei­spiel heißen die er­zeug­ten Methoden setSecondText und getSecondText.

Hin­zu­fü­gen weiterer Events

Benötigt ein Custom Control ein wei­teres Event, wird dies inner­halb des Event-Objekts defi­niert. Im fol­gen­den Bei­spiel wurden zwei Events defi­niert: hoverIn und hoverOut, welche auf den Mousecursor rea­gieren sollen.

Neue Events lösen sich aller­dings nicht von alleine aus. Viel­mehr müssen diese aktiv ge­triggert werden. Da in unserem Bei­spiel ein MouseHoverIn und Out ge­wünscht ist, muss das Custom Control auf die Mouse-Events hören.

Das SAPUI5 Frame­work gene­riert auch für Events neue Me­tho­den, welche zum Aus­lösen (Fire) des Events ge­hören. So kann innerhalb des Custom Controls auf die Browser-Mouse­events gehört und das eigene neue Event ausgelöst (gefired) werden.

Fazit

In diesem Beitrag wurde aufgezeigt, dass die Vor­teile von Custom Controls im Ver­gleich zu einer los­ge­lösten jQuery oder JavaScript Kompo­nente enorm sind. SAPUI5 kümmert sich um das Rendern und um die be­ste­hen­den Funk­tio­na­li­tä­ten, ohne dass sich selbst jemand damit be­s­chä­ftigen muss. Lassen sich be­stehen­de SAPUI5 Controls durch Properties oder Events so er­weitern, so dass die An­forder­ungen erfüllt werden, lässt sich das durch wenige Code Zeilen rea­li­sie­ren. Auch komplett neue Controls lassen sich mit einfachen HTML und CSS Kennt­nissen rea­lisieren. Wie das um­ge­setzt wird, erfahren Sie in unserem nächsten Blog­beitrag!

Verfasst von Martika Möller

Beitrag teilen

Weitere spannende Themen aus unserem Newsroom

Wir sind nach ISO 22301 zertifiziert

BIG.Cube ist ein verlässlicher Partner und Arbeitgeber auch in Krisensituationen...

Mehr lesen

Wir gehören zu „Deutschlands besten Arbeitgebern“

Als einer der Top-100-Arbeitgeber Deutschlands mit erneuter „Great Place to...

Mehr lesen

Unser Herzensprojekt: Die Stiftung AKM in München

Schon seit einiger Zeit unterstützten wir als BIG.Cube GmbH die...

Mehr lesen

Live-Re­porting auf SAP HANA für unter­schied­liche Reporting Tools er­mög­lichen

Unser Kunde aus dem Finanz­bereich wollte den Ad Hoc Berichts­an­forder­ungen der Fach­bereiche gerecht werden. Ziel war es, neben dem eta­blierten Standard­reporting flexible Möglich­keiten für schnelle Analysen schaffen.

Das Setting

Der Kunde hatte mehrere Zu­liefer­systeme an eine SAP HANA an­ge­schlossen. Diese wiederum gibt ihre Daten in ein Data Warehouse weiter. Aufgrund der Speicher­größe (6TB), der an­ge­bun­denen daten­liefernden Systeme und der Per­formance sollte die SAP HANA als Reporting Platform für diese Analysen ver­wendet werden.

© 2021. BIG.Cube GmbH. Alle Rechte vorbehalten.

Heraus­forderung

Die An­forderung seitens des Kunden war die Imple­men­tierung einer ge­nerischen Schnitt­stelle dieser Reporting Platform, die von mehreren Tools ver­wendet werden konnte. Zusätzlich sollten über diese Schnitt­stelle nur die Objekte sichtbar sein, die für die zu­greifende Person frei­gegeben waren.

Da viele Systeme an die Reporting Platform als Daten­zulieferer an­ge­schlossen waren, sollte die Schnitt­stelle auch für große Daten­mengen und viele Abfragen opti­miert werden. Und das unter optimaler Aus­nutzung der Performance der HANA. Zuletzt musste sicher­ge­stellt werden, dass der Betrieb anderer, paralleler Anwendungen auf der HANA nicht be­ein­flusst wurde.

Lösung

Von der An­bindung mit SAP SDI bis hin zu einer UI5 App, um den Status zu über­blicken, haben wir eine ganz­heitliche Lösung konzi­piert und imple­men­tiert. Erfahren Sie in den fol­genden Schritten, wie die An­forder­ungen an die SAP HANA Reporting Platform von uns um­gesetzt wurden:
1. Wahl der Zugriffs­art
Die schnellste Art des Zu­griffs er­folgte über JDBC/ODBC Zu­griffe. Da der Kunde die SAP HANA bereits als Um­gebung für native HANA Ent­wicklung nutzte und so bereits ein User­management für die HANA imple­men­tiert hatte, wurde dieser Ansatz gewählt. Die beim Kunden ein­ge­setzten Frontend­tools unter­stützten alle diese Lösung.
2. Datenban­kuser – Wer verw­al­tet die Rollen?
Normaler­weise ist in solchen Fällen zu­sätzlich ein ABAP System mit installiert. Hier jedoch handelte es sich um ein rein HANA Nativ gen­utztes System, welches bereits an die User Inter­face Schnitt­stelle des Unter­nehmens ange­schlossen war. Zudem lief auf der Daten­bank eine HANA Native An­wendung. Daher war sowohl das Wissen als auch die Technik bereits vor­handen.
3. Daten­räume schaffen

Mit Privi­legien auf unter­schiedliche Daten­gruppen wurde der Daten­raum je Nutzer­gruppe aufge­teilt und zu­gänglich gemacht. Dabei wurden sowohl all­gemeine Rechte auf Tabellen als auch ana­lytische Privilegien zur Redu­zierung der bereit­gestellten Daten auf Zeilen­ebene vergeben.

4. Calculation Views-Per­formance Boost
Um die Daten aus den Zu­liefer­systemen mit denen aus der HANA Nativen App zu ver­binden, wurden  Calculation Views benutzt. Zudem wurde auch dort für die Zugriff­steuerung mit Analytischen Privilegien ge­arbeitet. Eine weitere Nutzung der Calculation Views war der Aufbau von immer wieder ver­wendeten Daten­räumen, die für Ab­fragen benutzt wurden. Durch die Calculation Views und deren Input Parameter, konnte die Be­rechnung des Er­gebnisses auf der HANA durch­ge­führt werden und musste nicht durch die Front­end­tools erfolgen. So konnte eine deutliche Performance­steigerung bei der Berichts­aktualisierung er­zielt werden.
5. Ver­schiedene Fron­tend Tools
Von den unter­schied­lichen Fach­bereichen und den ver­wendeten Tools konnte unsere Schnitt­stelle gleicher­maßen ver­wendet werden. Zum Bei­spiel Microsofts Power BI, R mit Shiny Apps sowie alle anderen Tools mit ODBC/JDBC Verbindungs­möglich­keit.
6. HANA Work­load Mana­ge­ment

Die Größe der Re­porting HANA mit 6TB reinem InMemory Speicher plus die zu­sätzlichen Cold Storages mit 4TB haben es er­möglicht, in der Pilot­phase auf größere Ein­griffe in das Work­load­mana­gement zu ver­zichten. Trotzdem sind Limits bei der Ab­frage­größe (hier 256GB) ges­etzt worden. Das System wird laufend über­wacht. Sollte eine steigende Aus­lastung fest­gestellt werden, werden die Workload Klassen aktiviert und somit auch die System­stabilität weiter­hin sicher­ge­stellt.

Alle Bilder auf dieser Seite © 2021. BIG.Cube GmbH. Alle Rechte vorbehalten.

Fazit

Durch unseren ge­nerischen Ansatz konnten alle Tools über die gleiche Schnitt­stelle Daten be­ziehen. Mit dem Aufbau der durch Calculation Views vor­be­rei­teten Daten­räume konnten über 90 Prozent der An­fragen schnell mit optimaler Aus­nutzung der HANA ver­ar­beitet werden. Zudem wurde durch die Verfüg­barkeit des kompletten Daten­haushalts höchste Flexi­bilität für mögliche Ab­fragen ge­schaffen – ohne dass
die IT unter­stützend tätig werden musste.

Verfasst von Daniel Fröhler

Beitrag teilen

Weitere spannende Themen aus unserem Newsroom

Wir sind nach ISO 22301 zertifiziert

BIG.Cube ist ein verlässlicher Partner und Arbeitgeber auch in Krisensituationen...

Mehr lesen

Wir gehören zu „Deutschlands besten Arbeitgebern“

Als einer der Top-100-Arbeitgeber Deutschlands mit erneuter „Great Place to...

Mehr lesen

Unser Herzensprojekt: Die Stiftung AKM in München

Schon seit einiger Zeit unterstützten wir als BIG.Cube GmbH die...

Mehr lesen

Daten­zu­liefer­ungen stan­dar­di­sie­ren, auf­bereiten und qualitäts­sichern mit SAP SDI Realtime

Unser Kunde aus dem Finanz­­bereich wollte Daten­­zu­lieferun­gen in sein Data Ware­house stan­dardi­sieren und sie in einem zwischen­geschalteten HANA Sys­tem auf­­bereiten und qualitäts­­sichern. Ziel war es, alles für ein Near­time Repor­ting im Data Ware­house und Ad Hoc Re­porting­möglich­keiten für die Fach­be­reiche in der HANA DB vor­zube­reiten.

Hier zeigen wir einen Ausschnitt aus der Gesamtarchitektur, die im Rahmen vieler weiterer Projekte umgesetzt worden ist. Im Folgen­den lesen Sie, wie wir aus einem Oracle System ca. 700 Ta­bellen mit einer Quell Grö­ße von ca. 2TB in nahezu Echtzeit angebunden haben und welchen Herausforderungen wir uns hierbei stellen mussten. Zum Zeit­punkt dieses Aus­schnit­tes war bereits ein MSSQL System über Log-basierte Smart Data Integration (SDI) Replikation in die Archi­tek­tur ein­gebaut worden.

© 2021. BIG.Cube GmbH. Alle Rechte vorbehalten.

Herausforderungen: Beladung regulieren – Veränderungen erkennen

Der Zugriff durfte nur auf den Standby Knoten des Oracle Systems statt­finden, um den Haupt­knoten nicht zu belasten. Dieser Standby Knoten war nur Read Only geöffnet. Die SAP SDI Standard­möglich­keiten für Realtime erfordern einen Schreib­zugriff auf dem Quell­system. Für die Datenanbindung musste eine Möglichkeit im SAP Kontext gefunden werden, die trotz Read Only Mode des Sekundärknotens eine schnelle Verbindung sicherstellt. Zudem musste für das Folgesystem ersichtlich sein, welche Daten sich durch die Beladung geändert haben.

Lösung - Smart Delta!

Von der Anbindung mittels SAP SDI bis hin zu einer UI5 App zum Monitoring des Status. Wir haben eine ganzheitliche Lösung entwickelt. Erfahren Sie in den folgenden Schritten, wie die Heraus­forderungen gelöst wurden.

Anbindung mit SAP SDI
Für die An­bindung wurde mit SAP SDI eine SAP eigene in die HANA inte­grier­te Lö­sung zur Daten­­anbin­dung gewählt, die bereits für die An­­bin­dung eines MSSQL Systems ver­wendet wurde. Da­durch konnte die Lade­tech­no­lo­gie verein­heit­licht und Betriebs­­auf­wände gespart werden.
Auslastung steuern, Geschwindigkeit erhöhen
Um die Date­nmen­ge, welche über­­tra­gen wird zu re­duzie­ren und die Geschwin­dig­­keit zu erhöhen, wurde das Delta­feld im Quell­­system bestimmt und basie­rend darauf eine Delta­­logik implemen­tiert. Diese lädt ledig­lich die ge­­änder­ten Daten seit der letzten Extrak­­tion. Um die Be­las­tung des Agen­ten und der HANA zu steuern, wurden die Tabellen mittels T-Shirt Sizes in Klassen von S bis XL ein­­geteilt. Durch Ein­­stellun­gen der maxi­mal parallel lau­fenden Größen kann je nach verfügbarer Hard­ware die Aus­­las­tung des Systems und die Geschwin­dig­­keit der Daten­­aktuali­sierung ge­steuert werden. Ebenfalls ein­stell­­bar ist die erwartete Fre­­quenz von Delta und Delete Ab­holung. Auch hier kann ab­hän­gig von der Infra­s­truk­tur die Per­for­mance opti­miert werden.
Beladung mit SDI Flowgraphen
Für die Be­la­dung wurden SDI Flow­graphen verwendet, die optimal für die Filte­rung der Da­ten und teilweise kompli­zierte Delta­ermitt­lung geeignet sind. Die letzte Beladun­g wurde als Input in den Flowgraphen über­­geben, der dann die Ergebnisse in die HANA ge­laden hat. Die Ergeb­nisse wurden um ein Änderung­s­datum an­ge­reichert, welches das darauf auf­­bauende Data Warehouse weiter ver­­wenden kann.
UI5 App zur automatischen Datenanbindung
Um die Betriebs­­aufwände und die Auf­­wände für neu an­zubindende Tabe­llen zu re­du­zie­ren, wurde eine SAP UI5 App ent­wickelt. Die­se legt auto­­matisiert die Flow­graphen an und er­stellt dazu­gehörige .hdbviews sowie Calcu­lation Views bzw. passt diese an. So sind die Auf­­wände bei Änderun­gen der Da­ten­­struktur minimal. Zudem hat sich der Auf­wand im Betrieb für die Er­­stellung und Wartung der Flow­graphen, Tabellen und Calcu­lation Views deutlich reduziert.
UI5 Statusdashboard

Damit auch der Über­blick über den Sta­tus der Daten­­anbin­dung jeder­zeit gewähr­­leistet ist, wurde hier ebenfalls eine UI5 App er­stellt. Diese ist zusätzlich noch an eine auto­ma­tische Ticket­­erstellung in Azure DevOps sowie an einen Mail­versand an­­geschlossen. Gerade durch den Switch des Kunden von HANA 1 auf HANA 2 mit Ver­bleib auf XS Classic Objek­ten und dem Weg­­fall des klassischen Admin Cockpits war ein Über­blick über die Rep­­lika­tion drin­gend nötig. In das Cockpit wurden aber auch weitere Funk­t­ionen inte­griert wie z.B. die T-Shirt Size der Tabellen ändern, die Tabellen Prio­ri­täten fest­legen, Tabellen­­gruppen­­defini­tion oder schneller Zugriff auf eventuelle Fehler­­meldun­gen.

 

Alle Bilder auf dieser Seite © 2021. BIG.Cube GmbH. Alle Rechte vorbehalten.

Wiederverwendbarkeit

Bei unseren Lösun­gen achten wir stets auf eine hohe Wieder­verwend­barkeit bei unseren Kunden. Hier war archi­tekto­nisch SAP SDI bereits ge­setzt und für alle geplan­ten Szena­rien ein­setz­bar. Bei der Ent­wicklung wurde be­reits auf die Kompatibili­tät HANA 1 zu HANA 2 geachtet sowie der mög­liche XSA Ein­satz vor­bereitet. Mittels SAP SDI wurden MSSQL, Oracle, S4/HANA sowie BW on HANA Systeme an die HANA Zwischen­schicht an­geschlossen. Zudem wurde neben dem Delta­ver­fahren der SAP Standard für Realtime Connection ver­wendet. Dieser Standard ist ebenfalls über das Tools steuer­bar.

Fazit

Mit unserer Smart Delta Lösung war es uns in wenigen Schritten mög­lich, die Daten­­zu­lieferun­gen unseres Kunden in sein Data Ware­­house zu standar­di­sieren. Dazu konnten wir die Da­ten in einem zwischen­­ge­schalte­ten HANA System auf­­bereiten und quali­täts­­sichern – und das in Neartime.

Verfasst von Daniel Fröhler

Beitrag teilen

Weitere spannende Themen aus unserem Newsroom

Wir sind nach ISO 22301 zertifiziert

BIG.Cube ist ein verlässlicher Partner und Arbeitgeber auch in Krisensituationen...

Mehr lesen

Wir gehören zu „Deutschlands besten Arbeitgebern“

Als einer der Top-100-Arbeitgeber Deutschlands mit erneuter „Great Place to...

Mehr lesen

Unser Herzensprojekt: Die Stiftung AKM in München

Schon seit einiger Zeit unterstützten wir als BIG.Cube GmbH die...

Mehr lesen

Berechtigungs­fehler schnell und effizient er­mitteln

Schon seit HANA 1.0 bis hin zur HANA 2.0 SPS 03 waren die Analysen für Berechtigungs­fehler in der SAP HANA Datenbank nur durch mühsame Recherchen in den Traces und Logs möglich. Damit die Berechtigungs­fehler in den Logs zu finden waren, musste das Tracing entsprechend aktiviert werden. Als Konsequenz musste man mit Performance­einbußen, die je nach Tracinglevel variieren, rechnen.

Erleichterung mit der SAP HANA Version 2.0 SPS 04

Nun hat die SAP mit der SAP HANA Version 2.0 SPS 04 die Analyse von Datenbank Berechtigungsfehlern enorm erleichtert. In dem Daten­bank Schema SYS gibt es nun eine Prozedur „SYS.GET_INSUFFICIENT_PRIVILEGE_ERROR_DETAILS“, die anhand der GUID die zu berechtigenden Daten­bank­objekte ermittelt. Nachfolgend zeigen wir Ihnen in einfachen Schritten, wie Sie Berechtigungs­fehler in der SAP HANA Datenbank ermitteln und sich somit Zeit und Aufwand sparen.

Nun hat die SAP mit der SAP HANA Version 2.0 SPS 04 die Analyse von Datenbank Berechtigungsfehlern enorm erleichtert. In dem Daten­bank Schema SYS gibt es nun eine Pro­zedur
SYS.GET_INSUFFICIENT_PRIVILEGE_ERROR_DETAILS„, die anhand der GUID die zu be­rechtigenden Daten­bank­­objekte ermittelt. Nachfolgend zeigen wir Ihnen in einfachen Schritten, wie Sie Ber­echtigungs­fehler ermitteln und sich somit Zeit und Aufwand sparen.

In drei einfachen Schritten zum Erfolg

Der Schlüs­sel zum Erfolg liegt im Datenbankobjekt „SYS.GET_INSUFFICIENT_PRIVILEGE_ERROR_DETAILS“.

Der Schlüs­sel zum Erfolg liegt im Datenbankobjekt „SYS.GET_INSUFFICIENT_PRIVILEGE_ERROR_DETAILS„.
Zuweisen der benötigten Datenbankrechte

Damit Sie die Prozedur zur Fehleranalyse von Datenbankberechtigungen ausführen können, benötigen Sie die folgenden Rechte:

  • Privileg: EXECUTE
  • Datenbankobjekt: SYS.GET_INSUFFICIENT_PRIVILEGE_ERROR_DETAILS
  • Die Prozedur wird wie folgt aufgerufen:„CALL SYS.GET_INSUFFICIENT_PRIVILEGE_ERROR_DETAILS(“, ?)“
  • Eingabeparameter: GUID (wird in der Konsole angezeigt)
  • Ausgabeparameter: ? (Berechtigungsobjekt)

Quelle: https://help.sap.com/viewer/bed8c14f9f024763b0777aa72b5436f6/2.0.04/en-US/9a33043bc2c14981a92bf0f09c794789.html

Erkennen des aufgetretenen Berechtigungsfehler

Der Anwender versucht eine Calculation View zu selektieren, worauf er keine Zugriffsrechte hat und erhält die Fehlermeldung “insufficient privilege” mit einer zugehörigen GUID.

Auswerten des Berechtigungsfehlers mittels GUID

Die GUID wird nun in die Prozedur als Eingabeparameter übergeben und die Prozedur ausgeführt.

CALL SYS.GET_INSUFFICIENT_PRIVILEGE_ERROR_DETAILS (‚5842EF7AAEA79D408D8C70FA37156F36‘, ?);“

Wie man sieht fehlt dem Anwender das Privileg SELECT für den Calculation View _SYS_BIC.bigcube.app.test.vha/MyCalcView„.

Alle Bilder auf dieser Seite © 2021. BIG.Cube GmbH. Alle Rechte vorbehalten.

Zuweisen der benötigten Daten­bank­rechte

Damit Sie die Prozedur zur Fehleranalyse von Datenbankberechtigungen ausführen können, benötigen Sie die folgenden Rechte:

  • Privileg: EXECUTE
  • Datenbankobjekt: SYS.GET_INSUFFICIENT_PRIVILEGE_ERROR_DETAILS
  • Die Prozedur wird wie folgt aufgerufen:„CALL SYS.GET_INSUFFICIENT_PRIVILEGE_ERROR_DETAILS(“, ?)“
  • Eingabeparameter: GUID (wird in der Konsole angezeigt)
  • Ausgabeparameter: ? (Berechtigungsobjekt)

Quelle: https://help.sap.com/viewer/bed8c14f9f024763b0777aa72b5436f6/2.0.04/en-US/9a33043bc2c14981a92bf0f09c794789.html

Erkennen des auf­ge­tretenen Berechtigungs­fehler

Der Anwender versucht eine Calculation View zu selektieren, worauf er keine Zugriffsrechte hat und erhält die Fehlermeldung “insufficient privilege” mit einer zugehörigen GUID.

Auswerten des Berechtigungs­fehlers mittels GUID

Die GUID wird nun in die Prozedur als Eingabeparameter übergeben und die Prozedur ausgeführt.

CALL SYS.GET_INSUFFICIENT_PRIVILEGE_ERROR_DETAILS (‚5842EF7AAEA79D408D8C70FA37156F36‘, ?);

Wie man sieht fehlt dem Anwender das Privileg SELECT für den Calculation View _SYS_BIC.bigcube.app.test.vha/MyCalcView„.

Alle Bilder auf dieser Seite © 2021. BIG.Cube GmbH. Alle Rechte vorbehalten.

Fazit

Mit einfachen Schritten ist es nun möglich zu analysieren, welche Ber­echtigungs­objekte einem Anwender fehlen. Aufwand und Performance­einbußen durch die Suche in den Daten­bank Traces bzw. Logs werden hierdurch reduziert.

Verfasst von Veli Hasanca

Jetzt Kontakt aufnehmen

Beitrag teilen

Weitere spannende Themen aus unserem Newsroom

Wir sind nach ISO 22301 zertifiziert

BIG.Cube ist ein verlässlicher Partner und Arbeitgeber auch in Krisensituationen...

Mehr lesen

Wir gehören zu „Deutschlands besten Arbeitgebern“

Als einer der Top-100-Arbeitgeber Deutschlands mit erneuter „Great Place to...

Mehr lesen

Unser Herzensprojekt: Die Stiftung AKM in München

Schon seit einiger Zeit unterstützten wir als BIG.Cube GmbH die...

Mehr lesen