BIG.Cube als "Beste Arbeit­geber Bayern" und "Beste Arbeit­geber in der ITK" 2023 ausge­zeichnet

Wir sind stolz darauf, zu den Siegern des dies­jährigen Wett­bewerbs „Beste Arbeit­geber in Bayern“ und „Beste Arbeitgeber in der Branche ITK“ 2023 von Great Place to Work® zu zählen. Es erfüllt uns mit großer Freude, nicht nur in der umkämpften Branche „ITK“, sondern auch branchen­unabhängig zu den besten Arbeit­­gebern im Freistaat zu ge­hören. Diese Aus­zeichnungen stellt eine weitere Be­stätigung unseres hervorragenden Arbeits­klimas und unserer Unter­nehmens­­kultur dar. Besonders die faire Be­handlung der Mitarbeiter:innen und die gelebte Work-Life-Seperation wurden in der Begründung der Great Place to Work-Jury positiv hervorgehoben. Die Aus­zeichnung spornt uns an, ständig neue Wege für eine kontinuierliche Weiter­ent­wicklung der Arbeits­platz­qualität zu gehen und somit unseren Mit­arbeitern und Kunden ein Top-Arbeits­umfeld zur Verfügung zu stellen.

Was ist Great Place to Work?

Great Place to Work unter­stützt Un­ter­­neh­men auf der gan­zen Welt dabei, ihre Unter­nehmens- und Arbeits­platz­kultur zu ana­lysie­ren, weiter­zuent­wickeln und sicht­bar zu ma­chen. Dafür werden die Mit­arbei­tenden selbst in einer ano­nymen Befra­gung nach ihrer Ein­schätzung zu ihrem Arbeit­geber und ihrer Ar­beit gefragt. In einem Online-Frage­bogen wer­den 70 Fragen zur erleb­ten Arbeits­platz­kultur, wie z.B. zur Kommu­nika­tion mit den Füh­rungs­kräften, Ver­trauen in den Arbeit­ge­ber und Freude an der Zusammen­arbeit mit ihren Kolleg­:innen ge­stellt. Die Fra­gen wer­den von Great Place to Work formu­liert und in einem un­abhängi­gen Prozess aus­gewer­tet. Das Be­son­dere hier­bei ist, dass Great Place to Work ei­nen sehr star­ken Fo­kus auf die Be­fra­gung der Mit­ar­bei­ten­den legt und die Er­geb­nisse der Be­fra­gung 75% des An­teils an der Be­wer­tung aus­machen.


Neben dieser Aus­wertung findet zusätz­lich ei­ne Analyse der Personal­maß­nahmen statt. Die­se beiden Ergeb­nisse dienen als Grund­lage für eine Zerti­fizierung als Great Place to Work. Die Aus­zeichnung steht für eine glaub­würdige, faire Füh­rung und die aktive För­derung der Mitarbei­tenden.

Wir sind stolz darauf, diese groß­artige Aus­zeichnung von Great Place to Work er­halten zu haben und sehen es als eine Bestä­tigung unserer Fir­men­­kul­tur und unse­rer Personal­maß­nahmen. Wir freuen uns sehr über die groß­artigen und ehr­lichen Ant­worten unserer Mit­arbei­tenden.

Eindrücke von den Events

Fotocredit: © BIG.Cube

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
DSAG Jahresrückblick 22

Rückblick zum DSAG Jahreskongress 2022

Diese Themen wurden auf dem DSAG Jahreskongress 2022 diskutiert.

Mehr lesen

Rückblick zum DSAG-Partnertag SAP BW/4HANA, Analytics und hybride Landschaften in Präsenz

Diese Themen wurden auf dem DSAG-Partnertagrund um BW/4, Analytics und...

Mehr lesen

Hohe Da­ten­­quali­­tät­s­an­­sprü­che an SAP BW Sys­te­me

SAP BW Sys­­te­­me sammeln Da­­ten aus un­ter­schied­li­chen Quell­sys­te­men ein. Die­se wer­den da­rauf­hin trans­for­mie­rt, in­te­grie­rt und ag­gre­gie­rt um die Da­ten dann ab­neh­men­den Sys­te­men zur Ver­fü­gung zu stellen. Dies kön­nen bei­spiels­wei­se Re­por­ting Tools oder ana­ly­ti­sche Sys­te­me sein. Da die­se Da­ten oft­mals der Ent­schei­dungs­fin­dung die­nen, ist die Si­cher­stel­lung der Da­te­nqua­li­tät in SAP BW aufgrund des mehr­stu­fi­gen Da­ten-Ver­ar­bei­tungs­pro­zesses un­ab­ding­bar.

He­raus­for­de­run­gen der Si­cher­stel­lung der Da­ten­qua­li­tät im SAP BW Sys­tem

Aus un­se­rer lang­jäh­ri­gen Er­fah­rung bei un­se­ren Kun­den lie­gen die Kern-He­raus­for­de­rung­en zur Qua­li­täts­si­che­rung der Da­ten in ei­nem SAP BW Sys­tem in den fol­gen­den Punk­ten:

  • Da­ten­feh­ler füh­ren zu fal­schen Ent­schei­dung­en und füh­ren zu Re­pu­ta­tions­ver­lust. Deshalb verlieren Fach­be­rei­che schnell das Ver­trau­en in das Re­por­ting­sys­tem
  • Da­ten­feh­ler­ko­rrek­tu­ren in ei­nem SAP BW Sys­tem sind ge­ne­rell sehr auf­wen­dig und zeit­in­ten­siv
  • Um Da­ten­feh­ler nicht erst im Re­port zu er­ke­nnen, wer­den Quality-Checks im Da­ten­fluss an ver­schie­de­nen Ebe­nen im­ple­men­tiert. In der Re­gel erfolgt dieses mit­tels ent­spre­chen­der ABAP-Pro­gra­m­mie­run­gen, di­rekt im SAP BW Sys­tem in den Trans­for­ma­tions­rou­ti­nen durch die IT Ab­tei­lung
  • Gro­ße Da­ten­men­gen in ei­nem SAP BW Sys­tem be­dingen ei­ne sehr hohe An­zahl an qua­li­täts­sichern­den Ein­zel­plau­si­bi­li­sie­run­gen
  • Er­stel­lung, Ent­wick­lung und War­tung die­ser Pro­gra­mme be­deu­ten einen hohen Aufwand für die IT
  • Fach­be­rei­che sind (da­durch) ab­häng­ig von den Ka­pa­zi­tä­ten der IT
  • Erstellung und Pflege von Quality-Checks dau­ert oft­mals (viel) zu lang

Um die­se He­raus­for­de­rung­en zu lö­sen, müss­ten Fach­be­reiche in die La­ge ver­setzt wer­den, oh­ne IT Know-how folgende Dinge selbst zu tun: 1. Qua­li­ty­Checks ei­gen­stän­dig und un­ab­häng­ig im Self-Ser­vice (also oh­ne Pro­gra­mmie­rung) er­stel­len und pflegen. Und 2. im Feh­ler­fall selbst de­fi­nie­ren können, ob die Ver­ar­bei­tung im SAP BW Sys­tem fort­ge­führt oder ab­ge­bro­chen wer­den soll.

Q-THOR: Da­­ten­­qua­­li­­täts­­si­­che­­rung in SAP BW im Self-Ser­­vice

Aus der Idee Fach­be­reichen ei­ne Lö­sung zur Ver­fü­gung zu stel­len um Quality-Checks im Self-Ser­vice ei­gen­stän­dig an­zu­le­gen und de­ren Aus­füh­rung ein­zu­pla­nen ist das Pro­dukt Q-THOR entstanden. Mit Q-THOR kann so­wohl die Qua­­li­­tät der Da­ten im SAP BW Sys­­tem si­­cher­­ge­stellt wer­den, als auch die Ver­­ar­­bei­­tung der Da­­ten ge­steu­ert wer­den:

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

Das Zusammen­spiel zwischen Q-THOR und SAP BW

Um mit Q-THOR Daten in SAP BW zu prüfen wird das SAP BW direkt in Q-THOR als Da­ten­que­lle kon­fi­gu­riert. Hier­durch können Anwender:innen die zu prü­fen­den Da­ten aus dem SAP BW Sys­tem in der Check­an­la­ge aus­wäh­len und die Plau­si­bi­li­sie­rung­en ei­gen­stän­dig de­fi­nie­ren. Im näch­sten Schritt wird dann die Ausführung die­ser Quailty-Checks in ei­nem Sche­du­ler einge­pla­nt.

In SAP BW be­steht die Mög­lich­keit vor je­dem Ver­ar­bei­tungs­schritt der Da­ten ei­nen Sche­du­ler in Q-THOR zur Aus­füh­rung der Qua­li­ty-Checks zu tri­ggern. Dies geschieht über ei­nen ei­ge­nen Q-THOR Pro­zess direkt in SAP BW. Der Sche­du­ler führt dann die Qua­li­ty-Checks di­rekt auf den SAP BW Da­ten aus. Über die bei der Check­an­la­ge in Q-THOR fest­ge­leg­te KPI-De­fi­ni­tion wird ein ent­spre­chen­der Re­turn-Code an das SAP BW Sys­tem zu­rück­ge­ge­ben. Die­ser Re­turn-Code wird vom SAP BW Sys­tem aus­ge­wer­tet und die wei­te­re Ver­ar­bei­tung ent­spre­chend des Er­geb­nis­ses ge­steu­ert. In Q-THOR wird der ak­tu­elle Sta­tus je Ver­ar­bei­tungs­ebe­ne in SAP BW und der Be­la­dungs­fort­schritt der Da­ten in ei­nem Dash­board überwacht.

Q-THOR ver­än­dert keine Stan­dard­pro­zes­se in SAP BW. Es ist vielmehr ein Tool, um die Da­ten­qua­li­tät von Daten au­ßer­halb des SAP BW mit den ei­gens de­fi­nier­ten Qua­li­täts­stan­dards über­wa­chen zu kö­nnen. Da­rü­ber hi­naus kön­nen be­lie­big vie­le Qua­li­ty-Gates auch schon vor der Be­la­dung ins SAP BW er­fol­gen. Dies kann ge­tan wer­den, um etwa Quell­da­ten in den Quell­sys­te­men zu prü­fen, wo sie zum er­sten Mal er­stellt wurden. Mit Q-THOR werden Fachbereiche dazu befähigt den ge­sam­ten Da­ten­fluss von Quel­le, über SAP BW Back­end bis hin zum Re­por­ting an ei­ner zen­tra­len Stel­le gra­fisch zu über­wa­chen. So­mit kön­nen Da­ten­feh­ler früh­zei­tig er­kannt und be­ho­ben wer­den.

Fazit

Durch den Ein­satz von Q-THOR zur Plau­si­bi­li­sie­rung der Da­ten in ei­nem SAP BW Sys­tem kön­nen die für IT-Abteilungen auf­wen­di­gen Um­setz­un­gen und War­tun­gen von ABAP Prog­ram­men ent­fal­len. Sämt­li­che Qua­li­ty-Checks von Da­ten kön­nen von Fach­be­reichen und Business-Usern ei­gen­stän­dig ge­pflegt und de­ren Er­geb­nis­se kon­tro­lliert wer­den. Da diese Nutzer ohnehin zumeist die Data Ow­ner sind, wer­den so­mit genau die richtigen Personen mit ei­nem sehr mäch­ti­gen Werk­zeug aus­ge­rüs­tet um schnell und effi­zient ih­re Checks anzu­le­gen und bei Be­darf an­zupas­sen.

Verfasst von Tom Schütz

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

SAP HANA Transport mit MS Azure Pipelines

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

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

Migration von SAP BW 7.01 zu SAP BW/4HANA – ein Sprung in die Virtu­ali­sierung!

Eine SAP BW/4HANA Migra­tion ist sicher kein einfa­ches Unter­fangen. Eine beson­dere Wür­ze bekommt diese jedoch, wenn sie 3.x Daten­flüsse ein­schließt. In diesem Blogbei­trag werden wir die wich­tigen Er­folgs­faktoren eines SAP BW/4HANA Migra­tions­pro­jektes dar­stellen. Dabei be­deutet erfolg­reich in diesem Zu­sammen­hang nicht aus­schließlich die tech­ni­sche Migra­tion des SAP BW-Con­tents. Es bedeu­tet, dass unter Berück­sich­tigung der An­forde­rungen des Kun­den, der tech­no­logischen Möglich­kei­ten von SAP BW/4HANA und der sys­te­mischen Restrik­tionen der Ziel­archi­tektur eine neue Lösung unter SAP BW/4HANA er­schaffen wird. In unserem Projekt migrie­ren wir ein über Jahr­zehnte ge­wachsenes SAP BW7.01 System. Dieses bein­haltet ein Daten­volumen, welches das der SAP BW/4HANA-Ziel­architektur um Faktor acht über­steigt.

SAP BW/4HANA Migration

In-Place und Remote-Conver­sion schlie­ßen wir auf Grund der erläu­terten Gege­ben­hei­ten aus. Zudem haben wir fest­gestellt, dass wir nicht alle Daten aus dem Alt­system nach SAP BW/4HANA über­nehmen kö­nnen, was wir aber auch nicht mü­ssen. Bei ge­nau­e­rer Ana­lyse wurde er­kannt, dass ältere Daten auch nicht in­Memory benö­tigt werden. Also ver­stän­digten wir uns im Projekt darauf, die Da­ten der vergang­enen drei Jahre nach SAP BW/4HANA zu über­nehmen. Zudem haben wir im Projekt be­schlossen, alle älteren Daten im Alt­­system zu be­lassen, dieses aber als eine Art Cold-Store via SDI an das SAP BW/4HANA an­zu­bin­den. Das soll aber nicht The­ma dieses Blogs sein. Viel­mehr geht es darum, wie wir die Shell Conver­sion ge­zielt für unserer Sze­­nario genutzt haben. Zudem erläutern wir, welche Objek­te wir konver­tiert haben, welche nicht und warum diese nicht konvertiert wurden.

Step by Step vs. BigBang

In einem der­­artig gewach­­senen System wie in un­se­rem Anwen­­dungs­­fall finden wir nicht nur viele Daten, son­dern eben auch histo­risch gewach­sene Struk­turen. Darüber hinaus ergeben sich viele verschie­dene Lösungs­an­sätze für unter­­schied­lich schwie­rige Problem­stellungen. Um nicht in der Komple­xität der Migra­tion zu ver­sinken, haben wir uns ent­­schieden, das Ganze Step by Step anzu­gehen. Wir haben gar nicht erst ver­sucht, den gan­zen Content mit einem Mal oder sogar noch mit Daten (Remote Conver­sion) zu migrie­ren. Anfäng­liche Ana­lysen des Alt­systems zeig­ten große Opti­mierungs­poten­tiale hin­sicht­lich des Designs, der Perfor­mance und der Möglich­keiten der Vir­tua­lisie­rung (welche sich durch den techno­logischen Fort­schritt unter SAP BW/4HANA erge­ben). Aus diesem Grund und weil jede noch so steile Lern­kurve bei 0 ihren Ur­sprung hat, haben wir mit den Low Hanging Fruits be­gonnen.

Geziel­ter Ein­satz der Shell Con­ver­sion

Begi­nnend mit den Con­version Guides, der Ein­richtung der System­land­schaft (Sys­tem­­ver­bin­dun­gen, Trans­port­schiene, ODP-Frei­gabe der Data­Sourcen, etc.) und der Defi­nition des Scopes für unsere erste Itera­tion, haben wir zu­nächst alle rele­vanten Info-Objekte, inkl. aller ab­hängigen Info-Objekte und Attr­ibute mi­griert. Das funktio­nierte problem­los, weil keine Konver­tierung not­wendig war. Nicht migriert haben wir Daten­flüsse und Info­Provider trans­aktionaler Da­ten. An dieser Stelle besteht unserer Ansicht nach das größ­te Poten­tial mit SAP BW/­4HANA-Techno­logie zu opti­mieren, bzw. zu virtua­lisieren. Unse­rer Meinung nach werden wir nur auf diese Weise den Projekt­anfor­derungen hin­sicht­lich Per­formance, Wart­bar­keit und Daten­menge gerecht. Eine Über­sicht dessen, was wir letzt­lich mit dem Pro­gramm der Shell Con­version migriert haben, und was nicht, sehen Sie in den nach­folgenden Ab­bildungen.

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

Expli­zit zu er­wähnen ist die Migra­tion der Query-Ob­jekte. Das stellte uns An­fangs vor Pro­bleme, da das Pro­gramm bei der Aus­wahl der gewün­schten Query den dazu­gehörigen Multi­provider selek­tierte. Dieser muss in einen Compo­site Provider konver­tiert wer­den. Es prüft – egal ob aktiv oder in­aktiv – alle be­tei­­ligten Info-Objek­te, Calcu­lated Key Fi­gures, Varia­blen, InfoCubes, etc. und die davon ab­hängi­gen Objekte, und wiederum die davon ab­hängigen Objek­te usw.. Stellen Sie sich vor, was es bedeu­tet, eine Query, die eine Varia­ble für 0CALYEAR bein­haltet, zu migrie­ren. Unserer Erfah­rung nach ist es – je nach Kom­plexi­tät ein­facher, eine Kopie von zu mi­grie­renden Multi­pro­viders inkl. der Query im Alt­system zu machen. (Achtung: Sie benö­tigen min­des­­tens einen betei­ligten InfoCube, aber nicht die Daten­flüsse!)

Vir­tuali­sierung ist Key!

Wie im Ab­schnitt zuvor erläu­tert, ent­spricht es nicht dem An­spruch des Projek­tes, die Daten­flüsse und Info­Pro­vi­der der transak­tionalen Daten 1:1 zu migrie­ren. Was bringt uns das Chassis eines Ferraris mit dem Motor eines VW Golf’s? Wir haben uns ent­schie­den – dort wo möglich und sinnvoll – be­steh­en­de Lösungsansätze zu virtualisieren. Die fol­gen­de Abbildung zeigt eine schematische Ge­gen­über­stellung der Problematik zur Auflösung der „Bill of Ma­terial“.

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

Die „Bill of Mate­rial“ (kurz BOM) ist aus techni­scher Sicht eine simple 1:n Ver­knüpfung zwischen Ma­teri­a­lien und Kompo­nenten, welche wiederum Materia­lien sind. Diese Kom­ponen­ten können jedoch auch ein­zeln ver­kauft wer­den, d.h. nur ein Bruch­teil der Materia­lien wird durch eine BOM auf­ge­löst. In SAP BW 7.01 wurde die Auf­lösung der BOM mangels Möglich­keiten in einer ABAP-Routine mit zahl­reichen LOOP’s imple­mentiert. Die gesamten Ver­­kaufs­­zahlen, auch die Daten, die nicht in der BOM aufgelöst werden, werden ein zusätzliches Mal per­sis­tiert. Diese zu­sätzliche Persistierung hat nicht nur zur Folge, dass die doppel­te Spei­cher­ka­pazität benötigt wird, son­dern auch zu­sätzliche War­tungs­auf­wän­de. Denn, was passiert, wenn die Bill of Material sich für ein Material än­dert? Die per­sis­tier­ten Daten müssen korrigiert werden. Durch die vollständige Virtualisierung dieser Pro­blem­stellung geben wir nicht nur Spei­cher­ka­pazität frei, wir erhalten darüber hinaus ein stets auf der aktuellen BOM basierendes Reporting, ohne diese manuelle berichtigen zu müssen.

Fazit zur SAP BW/4 HANA Migration

In diesem Bei­trag wurden die Faktoren und Erfahrungs­werte einer erfolg­reichen SAP BW/4HANA Migra­tion aufge­zeigt. Die Ent­schei­dung, die Shell Conversion ge­zielt zu nutzen, anstatt mit der Remote Conversion ganze Daten­flüsse inklu­sive Daten zu mi­grieren, haben wir be­wusst ge­troffen. Dem techno­logischen Fort­schritt von SAP BW/­4HANA zu SAP BW 7.01 wollen wir Rech­nung tragen und die Lösungs­ansätze des Alt­sys­tems neu designen. Dabei ha­ben wir vor allem auf die zahl­reichen Möglich­keiten der Virtua­lisierung gesetzt.

Verfasst von Christian Schultz

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
DSAG Jahresrückblick 22

Rückblick zum DSAG Jahreskongress 2022

Diese Themen wurden auf dem DSAG Jahreskongress 2022 diskutiert.

Mehr lesen

Augmented Analytics Funktionen in der SAP Analytics Cloud (SAC)

Mit der SAC durch Augmented Analytics und Predictive Analytics Funk­tionen...

Mehr lesen

Rückblick zum DSAG Jahres­kongress 2022

„Auf der Suche nach … Erfolg“ lautete das Motto vom DSAG Jahres­kon­gress 2022, welcher vom 10.-13.10 in Leipzig statt­fand. Mit über 3.000 Besucher und Besucher­innen und 125 Aus­stellern stellt der DSAG Jahres­kongress einen wichtigen Termin dar, um sich gegen­seitig aus­zutauschen und um Neuig­keiten direkt von der SAP zu erfahren. Gleichzeitig wurden aber auch Forder­ungen an die SAP gestellt. In diesem Jahr war die BIG.Cube mit einem Stand vor Ort. Dabei stellten wir neben unserem kom­pletten Port­folio besonders die zwei Fokus­themen ESG Reporting mit SAP Analytics und Daten­qualität mit Q-THOR in den Vordergrund. So hat es wunder­bar gepasst, dass wir das Thema „Die Daten­qualität als Erfolgs­faktor im daten­getriebenen Unter­nehmen“ im Zuge einer Espresso-Session vor­stellen konnten.

Diese Trends wurden auf dem DSAG Jahres­kongress 2022 deutlich:

  • SAP-On-Premise immer noch Nr. 1: Die Bedeutung von SAP-On-Premise-Lösungen wird zwar weiter ab­nehmen, aber dennoch auf einem hohen Niveau ver­harren
  • Da gleich­zeitig Cloud-Lösungen wichtiger werden, ist ein Trend zu erkennen: Die Zukunft ist hybrid
  • Neben der technischen Heraus­forderungen stehen viele Unter­nehmen vor Ver­änderungen, die die Digi­talisierung, die Trans­formation und der Umbruch der heutigen Zeit mit sich bringen
  • Im Bereich SAP Analytics zeigte sich auf dem DSAG Jahres­kongress, dass die SAP mit der SAP BW Bridge ein autom­atisiertes Konvertierungs­tool für den Übergang von SAP BW in die SAP Data Warehouse Cloud bereit stellt
  • In der Praxis stehen viele Unter­nehmen allerdings zunächst vor einer Migration auf BW on HANA oder BW/4HANA
  • Auch das Thema Nach­haltigkeit fand in ver­schiedensten Facetten Anklang auf dem DSAG Jahres­kongress. Von der Umsetzung einzelner Maßnahmen zB. bei der deutschen Post bis hin zum aussage­kräftigen ESG Reporting

Wir freuen uns bereits auf den DSAG Jahres­kongress 2023!

Eindrücke aus Leipzig

Fotocredit: © BIG.Cube

Jetzt Kontakt aufnehmen

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 die Arbeit mit dem Tool...

Mehr lesen
Erfolgsfaktoren BW/4HANA Migration

Erfolgsfaktoren für eine SAP BW/4HANA Migration

In diesem Beitrag wird aufgezeigt, welche Erfolgsfaktoren bei einer SAP BW/4HANA Migration bestehen.

Mehr lesen

Rückblick zum DSAG-Partnertag SAP BW/4HANA, Analytics und hybride Landschaften in Präsenz

Diese Themen wurden auf dem DSAG-Partnertagrund um BW/4, Analytics und hybride Landschaften diskutiert.

Mehr lesen

Rückblick zum DSAG-Partner­tag SAP BW/4HANA

Auf dem DSAG-Partner­tag SAP BW/4HANA, Ana­lytics und hybride Land­schaften in St. Leon-Rot drehte sich alles um das Thema SAP BW/4HANA. Ins­besondere wurde thema­tisiert, wie erfolg­reiche Migra­tionen ab­laufen, wie sich ana­lytische Sze­narien im heu­tigen BW4-Umfeld lösen lassen und welche Ansätze die aktuellen Data-Management-Platt­formen unter­stützen. Auch wir durften in einem spannenden Vortrag auf­zeigen, wie wir die Migration von BW 7.01 zu SAP BW/4HANA bei einem unserer Kunden auf­gesetzt haben.

Der Aus­tausch mit Gleich­gesinnten lieferte intere­­ssante Ein­­blicke in ähnliche Migrations­projekte. Zudem gab die SAP einen aktuellen Stand über ihr Produkt­portfolio.

Diese Trends wurden auf dem DSAG Partner­tag deutlich:

  • Die SAP Business Technology Plattform ist die Grund­lage des intelli­genten und nach­haltigen Unter­nehmens. Data Warehousing, Analytics und Planning sind weiterhin ein fester Bestand­teil der SAP Business Technology Plattform
  • Das SAP BW/4HANA leistungs­stärker und skalier­barer als sein Vor­gänger. Daher sicherte die SAP eine War­tung bis in das Jahr 2040 zu
  • Die Roadmap der SAP geht klar in Rich­tung Cloud Services und Applika­tionen, ins­besondere fürs Data Ware­housing liegt der Fokus auf der Data Warehouse Cloud
  • Bei Migra­­tionen von älteren BW Ver­sionen in das SAP BW/4HANA ist darauf zu achten, nicht alles zu mi­grieren, damit nicht das alte System im neuen Wieder­ge­spiegelt wird, ohne die Vorteile der neuen Tech­nologien zu nutzen
  • Mit der SAP BW Bridge wird eine autom­atisierte Bereit­stellung von Kon­ver­tierungs­tools für den Übergang von SAP BW in die SAP Data Warehouse Cloud an­ge­boten
  • Auch hybride Ansätze als Kombi­nation von SAP BW bzw. BW/4HANA und Data Warehouse Cloud sind mög­lich
  • Die SAP Analytics Cloud (SAC) bietet ver­besser­te und smarte Planungs­funktio­nali­täten sowie die Mög­lich­keiten der ein­fachen Er­stellung von Pro­gnosen und Visuali­sierungen
Wir freuen uns bereits auf weitere DSAG Part­nertage sowie auf den DSAG Jahres­kongress!

Eindrücke aus St. Leon-Rot

Fotocredit: © BIG.Cube

Jetzt Kontakt aufnehmen

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 die Arbeit mit dem Tool...

Mehr lesen
Erfolgsfaktoren BW/4HANA Migration

Erfolgsfaktoren für eine SAP BW/4HANA Migration

In diesem Beitrag wird aufgezeigt, welche Erfolgsfaktoren bei einer SAP BW/4HANA Migration bestehen.

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

BIG.Cube ist ein Great Place to Work – Bayern und ITK

Die BIG.Cube wurde dieses Jahr von Great Place to Work...

Mehr lesen

Shortcuts für SAP BW in Eclipse

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

Mehr lesen

Eisstockschießen mit der BIG.Cube

Die Mitarbeitenden der BIG.Cube waren gemeinsam nach der Arbeit Eisstockschießen....

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

BIG.Cube ist ein Great Place to Work – Bayern und ITK

Die BIG.Cube wurde dieses Jahr von Great Place to Work...

Mehr lesen

Shortcuts für SAP BW in Eclipse

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

Mehr lesen

Eisstockschießen mit der BIG.Cube

Die Mitarbeitenden der BIG.Cube waren gemeinsam nach der Arbeit Eisstockschießen....

Mehr lesen

Q-THOR – Zertifi­ziert von der SAP

Die SAP hat unsere Standard­software zur nach­haltigen Steiger­ung und Sicher­stellung der Daten­qualität „Q-THOR“ offiziell für den Ein­satz auf SAP HANA 2.0 über das SAP Integrations­szenario HANA-APP 2.0 zerti­fi­ziert. Mit dieser Zerti­fi­zierung stellt die SAP sicher, dass Lösungen von externen An­bietern sicher in SAP Land­schaften inte­griert werden können. Die Software ist nun offi­ziell im SAP certified solutions directory zu finden. Welche Schritte Q-THOR dabei in dem Zerti­fi­zierungs­pro­zess durch­laufen hat und was die Zerti­fi­zierung für uns und unsere Kunden be­deutet, erfahren Sie im folgenden Blog­beitrag.

Folgenden Zertifizierungs­prozess hat Q-THOR durch­laufen​

Im Zuge des Q-THOR Zertifizierungs­prozesses wurden von der SAP u.a. die nach­folgenden Prozess­schritte an­gefordert und über­prüft:

Vorteile der Zertifizierung für (künftige) Anwender

All diese Schritte wurden erfolg­reich durch­laufen, so dass am Ende des Pro­zesses Q-THOR von der SAP zerti­fiziert wurde. Somit ist sicher­ge­stellt und von der SAP attes­tiert, dass sich Q-THOR problem­los in­stallieren lässt. Zudem stellt die SAP sicher, dass sich die Software reibungs­los in die System­landschaft inte­grieren lässt und Q-THOR ver­lässlich auf der HANA läuft.

Dieser Qualitäts­stempel macht uns stolz und ist neben der Auf­nahme des Pro­duktes in den SAP Store und der Förder­ung vom Bundes­ministerium für Bil­dung und For­schung eine weitere Aus­zeich­nung für die Quali­tät unseres Pro­duktes. So erzeugen wir für unsere Kun­den einen echten Mehr­­wert. Denn durch den Ein­satz von Q-THOR er­möglichen wir den Kunden das Thema Daten­­qua­lität, wel­ches Unter­­nehmen in den kommenden Jahr­­zehn­ten heraus­fordern wird, er­folgreich mana­gen zu können.

Die ge­nerische Archi­tektur von Q-THOR unter­stützt Sie auch auf Non-SAP Land­schaften

Q-THOR überzeugt durch eine voll­ständig gene­­rische Archi­tektur und inte­griert sich einfach in die System- und Daten­land­schaft, ohne diese zu verändern.

Die Land­­schaft kann sowohl SAP-basiert als auch Non-SAP-basiert sein. Dabei kann die Datenbeladung und -integration für Q-THOR auf verschiedene Arten erfolgen, abhängig beispielsweise von Ihrer Systemlandschaft und Ihren Anforderungen an die Verfügbarkeit. 

Sie möchten mehr über Q-THOR erfahren?

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

Success-Story: Datenqualitätsmanagement in der MEAG mit Q-THOR

So stellt die MEAG seit 2016 ein erfolgreiches Datenqualitätsmanagement mit...

Mehr lesen

Mi­gration beim Uni­versi­täts­klinikum Ulm: Eine Success-Story

Im Zuge der Ums­tellung seiner SAP-Land­schaft auf S/4 HANA er­setzte das Uni­versi­täts­klini­kum Ulm (UK Ulm) die be­stehende Microsoft MS SQL 2017 Daten­bank durch eine HANA DB 2.0. Ziel war es, das Business Ware­house auf BW on HANA zu migrieren. Somit konnte das bis dahin nicht am UK Ulm ver­wendete Suse Linux Enterprise for SAP sowie die HANA DB eingeführt werden.

Der BIG.Cube Standard-Prozess für Mi­gra­tions­projekte. © 2021. Alle Rechte vorbehalten.

Bei dieser Um­stellung unters­tützte die BIG.Cube vom Kickoff bis hin zur tatsächlichen Migration. Auch die technische In­stalla­tion der Ziel­umge­bung, die Mi­gra­tions­vor­be­rei­tung und das Projektmanagement waren Bestandteile der BIG.Cube-Leistung. Des Weiteren übernimmt die BIG.Cube von nun an auch Support und Wartung.

Alle Be­teiligten der UK Ulm und der BIG.Cube be­wiesen im Projekt eine sehr gute Zusammen­arbeit. Das ziel­ge­richtete Arbeiten ermöglichte eine Um­stellung inner­halb des ge­planten Zeit­plans.

Dabei wurden folgende Leis­tungen er­folg­reich um­gesetzt:

Technische Migra­tion ein voller Erfolg

Im Er­gebnis weist die tech­nische Migra­tion eine groß­artige Erfolgs­bilanz auf: Durch das temporäre Ver­größern der Hardware, die Online-Migration der größten Ta­bellen und der Test­migra­tion konnte die Downtime von 20 Stunden auf nur 4 Stunden redu­ziert werden. Dazu wurde die produk­tive Daten­bank um 75% ver­klei­nert.

Screenshots aus dem Migra­tions­prozess bei der UK Ulm (links: Konfi­gura­tion der „Near Zero Downtime“, rechts: „Aktive DMO Tabelle­nmigra­tion“) © 2021. Alle Rechte vor­be­halten.

Screenshots aus dem Migra­tions­prozess bei der UK Ulm (oben: Konfi­gura­tion der „Near Zero Downtime“, unten: „Aktive DMO Tabelle­nmigra­tion“) © 2021. Alle Rechte vor­be­halten.

UK Ulm macht mit der BIG.Cube weiteren Schritt in der
Digi­tali­sie­rung

UK Ulm macht mit der BIG.Cube weiteren Schritt in der Digi­tali­sie­rung

„Die tech­nische Migra­tion führt zu einer er­heb­lichen Ver­besserung aller unserer Systeme. Die BIG.Cube hat unsere Er­wartungen in diesem Projekt voll­umfänglich er­füllt und die tech­nische Migra­tion in time, in budget und in quality aus­geführt“, so Michael Ducke, SAP Basis Projekt­leiter beim Uni­versi­täts­klinikum Ulm. Die UK Ulm geht durch die Ein­führung der HANA DB 2.0 und die an­schließende Migra­tion auf BW on HANA einen weiteren Schritt in der Digi­tali­sierung. Mithilfe der BIG.Cube kann nun nach der Installation auch der stabile Betrieb der SAP Basis & HANA Land­schaft sicher­ge­stellt werden.

Beitrag teilen

Weitere spannende Themen aus unserem Newsroom

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
DSAG Jahresrückblick 22

Rückblick zum DSAG Jahreskongress 2022

Diese Themen wurden auf dem DSAG Jahreskongress 2022 diskutiert.

Mehr lesen