ABAP RAP Nummernvergabe

ABAP RAP Nummernvergabe

Die Nummernvergabe ist ein wesentlicher Bestandteil von ABAP RAP Anwendungen. Konkret geht es bei der Nummernvergabe darum, wie die Schlüsselfelder der Entität mit Werten versorgt werden. RAP bietet uns hier verschieden Lösungsansätze, welche jedoch manchmal auch zur Verwirrung führen und ich deshalb hier kurz erläutern möchte.

Zuerst müssen wir einmal klären, was Früh/Spät und Managed/Unmanaged bei der Nummernvergabe bedeutet.

Frühe- und Späte Nummernvergabe

Bei der frühen Nummerierung geht es darum, dass die Nummer bereits durch den Consumer oder durch das RAP-Framework zu einem frühen Zeitpunkt erzeugt wird. Bei der späten Nummerierung werden die eigentlichen Keys erst zum SAVE-Zeitpunkt vergeben, wodurch eine lückenlose Nummerierung realisiert werden kann.

Managed und Unmanaged

Wenn man als Key-Feld eine Guid hat, kann man sich für eine automatische (=managed) Nummerierung entscheiden. Bei der unmanaged Nummerierung wird die Nummernvergabe durch entsprechende ABAP Codes realisiert.

Folgende Kombinationsmöglichkeiten sind vorhanden:

Frühe NummernvergabeSpäte Nummernvergabe
ExternX
ManagedXX
UnmanagedXX

Frühe externe Nummernvergabe

Bei der frühen externen Nummernvergabe werden die Key-Felder bereits durch den Consumer gefüllt. In der Behavior-Definition müssen wir dafür sorgen, dass das Feld bei der Erstellung änderbar ist, bei Änderungen jedoch nicht mehr geändert werden kann.

In der Behavior Definition ist für diese Nummerierung keine spezielle Angabe zu machen. Jedoch sollten die Key-Felder bei Updates auf readonly gesetzt werden:

field ( readonly : update ) orderId;

Frühe interne Nummernvergabe

Die frühe interne Nummernvergabe kann nur angewendet werden, wenn es sich bei dem Key-Feld um eine Guid (Raw 16) handelt. In der Behavior Definition sind auch in diesem Scenario nur zwei kleine Definitionen für das Key-Feld vorzunehmen:

field ( readonly ) orderGuid;
field ( numbering : managed ) orderGuid;

Zuerst setzen wir die Guid auf readonly und in zweiten Zeile legen wir die automatische interne Nummerierung auf die Guid fest.

Unmanaged interne Nummernvergabe

Diese unmanaged interne Nummernvergabe kann sowohl für managed als auch unmanaged RAP Business Objekte verwendet werden. Auf Entity Level müssen wir eben in der Behavior Definition diese Nummerierung mit early numbering definieren. Ebenso sollten die Key-Felder auf readonly gesetzt werden.

Nun kann man entweder über Quick-Fix oder manuell eine Implementierung für die Nummerierung vornehmen. Die Methodensignatur sieht wie folgt aus:

METHODS earlyNumberingOrder method for NUMBERING
   [IMPORTING] entities FOR CREATE business_object_entity …

In der Methode ist nun die Nummernvergabe für die Objekte in entities umzusetzen. Wichtig ist, dass die erfolgreichen Nummernvergaben in die Exporttabelle mapped bekannt gegeben werden müssen.

Unmanaged späte Nummernvergabe

Auch die unmanaged späte Nummernvergabe kann für beide RAP Szenarien verwendet werden. Auf Entity Level wird dies durch late numbering definiert. Ebenso sollten die Key-Felder auf readonly gesetzt werden.

Die Implementierung der Nummernvergabe erfolgt in einer Methode adjust_numbering, welche im Zuge der save sequence – nach dem Point of no return – aufgerufen wird. Die Methode kann man sich wieder mit einem Quick-Fix erzeugen lassen.

Die erzeugte Nummer muss über den Export-Parameter mapped mit dem internen temporären Key zugeordnet werden.

Referenzen

Cadaxo UI5 Snippet 2

Cadaxo UI5 Snippets #2 – i18n with parameters in XML View

Internationalization in UI5 – using i18n properties files – is the way to translate text into other languages. In this blog post I will share you the way, how to use i18n text with parameters in XML Views.

Define i18n File

/webapp/i18n/i18n.properties

Using in XML View

To display defined text with parameters you can use following snippet

Set parameters in Controller

Define JSON Model in manifest.json file

Do not forget to define ‚myModel‘ as it is not possible to input the parameter as a hard-coded strings. Either in the View or in manifest.json file

Let me know how you work with i18n parameters in Frontend or leave a comment if you found this blog post useful!

Georg Grabner, SAP Service Portfolio Manager bei WienIT über den Einsatz des SQL Cockpits

Einsatz des SQL Cockpits bei WienIT

Das SQL Cockpit for SAP Systems hat sich in der Praxis bereits mehrfach bewährt. Das Resultat ist eine mittlerweile enge Zusammenarbeit mit unseren langjährigen, zufriedenen Kunden. Unter diesen befindet sich die WienIT.

Wir haben mit Georg Grabner, SAP® Service Portfolio Manager bei WienIT, über das SQL Cockpit und dessen Einsatz im Unternehmen gesprochen.

In diesem Interview erfahren Sie, in welchem Umfang unser Tool derzeit bei der WienIT eingesetzt wird, welche Features ganz besonders geschätzt werden sowie Details über unsere Zusammenarbeit.

Was war vor dem SQL Cockpit deine größte Herausforderung bei der WienIT?

Aus meiner Sicht war der ganze administrative Teil einer Produktivsetzung immer sehr umfangreich. Den kann ich mir durch den Einsatz mit dem SQL Cockpit ersparen, da ich nun sehr schnell und effizient Datenauswertungen direkt auf einem Produktivsystem durchführen kann. Zusätzlich kann ich bereits im Zuge der Entwicklung einerseits die Korrektheit meiner Selektion und andererseits die Performance prüfen.

Wie und wo wird das SQL Cockpit bei der WienIT eingesetzt?

Einerseits nutzen hauptsächlich unsere Entwickler und Business Consultants das Tool, um Auswertungen durchzuführen und Reports zu generieren. Zusätzlich arbeiten unsere Applikationsspezialisten mit dem SQL Cockpit, um periodisch Qualitätschecks des Systems durchzuführen.

Das SQL Cockpit ist sehr vielseitig einsetzbar und man muss kein SQL-Profi sein, um damit zu arbeiten. Man ist relativ schnell firm in der Anwendung.

Gab es ein spezielles Feature, das dich direkt überzeugt hat?

Mich hat vor allem die Grundfunktionalität der Selektionen überzeugt. Der SAP® Standard stellt bekanntlich kein Tool zur Verfügung, mit dem man direkt SQL Statements absetzen sowie hochkomplexe Selektionen durchführen kann. Natürlich gibt es Mittel und Wege, aber in dieser Art und Weise und ohne Einschränkungen gab es das vorher nicht. Damit hat die Cadaxo eine Marktlücke geschlossen.

Ein weiterer großer Vorteil ist die Möglichkeit der sauber dokumentierten Datenmanipulation. Es ist manchmal einfach notwendig, Daten entweder punktuell oder massenhaft „gerade zu ziehen“. Das geht mit dem SQL Cockpit sehr gut und vor allem unkompliziert. Zusätzlich ist das gesamte Vorgehen der Datenmanipulation von einem Wirtschaftsprüfer abgenommen und zertifiziert.

Würdest du das SQL Cockpit weiterempfehlen?

Ich würde es definitiv weiterempfehlen. Wir haben das SQL Cockpit auf allen unseren Systemen, die wir betreuen, im Einsatz. Ich finde es immer sehr amüsant, wenn wir mit externen Beratern oder Entwicklern zusammenarbeiten, die mühsam mit SAP® Standard Tools Daten selektieren wollen. Wenn ich ihnen dann das SQL Cockpit vorstelle, stoße ich immer wieder auf Begeisterung, dass es ein derartiges Tool auf dem Markt gibt.

Kannst du etwas besonders Positives hervorheben in Bezug auf deine Zusammenarbeit mit Cadaxo?

Ich kenne Föß* und Domi** gut. Ich weiß, dass sie viel unter Dampf stehen und unter Wasser sind. Ich finde es großartig, wie schnell sie dennoch immer reagieren und Bereitschaft zeigen, kleine Bugs zu beheben und Verbesserungsvorschläge anzunehmen. Wir waren auch bereits als Beta-Tester für zusätzliche Features im Einsatz. Das ist für uns natürlich auch ein Vorteil, da wir so schon vorab neue Releases erhalten.

Hier können Sie Georg Grabner finden: LinkedIn | Xing

Das ist die WienIT

„WienIT ist der digitale Backbone der Wiener Stadtwerke-Gruppe. Wir digitalisieren die, die Wien zur l(i)ebenswertesten Stadt der Welt machen. Als zentraler IT & Business Partner bringen wir so die Wiener Linien ins Rollen, Wien Energie zum Leuchten und bilden das Network der Wiener Netze. Wir finden Lösungen für konzernweite Cases – egal ob IT-Pionierarbeit, Personalprozesse oder Print-Jobs. Wir schaffen smarte Services und machen so Wien gemeinsam futureproof. #dedicatedtoprogress für die Wiener Stadtwerke. Und für dich.“

SQL Cockpit for SAP Systems – So nah waren Sie Ihren Daten noch nie

Das einzigartige Datenbank-, Abfrage-, Vergleichs- und Modifikationstool für Ihr SAP System. Direkte ABAP® SQL Abfragen absetzen ohne eine einzige Zeile Code zu schreiben? Komplexe Joins, Unions, CDS Views, DB Hints, uvm. ganz ohne ADT, aber mit umfangreichem Berechtigungskonzept? Das alles und noch viel mehr ermöglicht das SQL Cockpit for SAP® Systems.


*Johann Fößleitner: CEO & Co-Founder, ABAP®, UI5/ SAP Fiori® und dox42® Integration | **Domi Bigl: SAP® Senior Consultant, ABAP® Programmierung, Konzeption technischer Lösungen

Constants

Cadaxo UI5 Snippets #1 – How to define constants

During the work on some Freestyle UI5 Apps I always look for a way how to save constants in Frontend. I would like to share following practice with you, which I use currently.

Define JSON File with Constants

I am going to create a new File in my project root folder. In this file all constant and values will be stored as a JSON Object.

/webapp/model/constants.json

   

Define JSON Model in manifest.json file

I my project manifest.json, I am going to define a new JSON Model with created JSON file in URI

Using Constants in View

From now on it is possible to use the constant model in View:

Using Constants in Controller

And of course also in Controllers. For example like this:

Let me know how you save constants in Frontend or leave a comment if you found this blog post useful!

Low_NoCode Header

Low-Code / No-Code – Die Lösung für die S/4HANA® Migration?

Wer mich kennt weiß, dass ich Low-Code/No-Code Lösungen mit einer gewissen Skepsis betrachte. Nicht weil es sich dabei um schwache Lösungen handelt. Low-Code / No-Code Anwendungen können durchaus den Flaschenhals des „Fachkräftemangel“ lindern.

SAP® und Low-Code/No-Code – Eine Reise durch die Zeit

Als ich mich mit dem Blogbeitrag erstmals auseinandergesetzt hab, ist mir schnell bewusst geworden, dass ich eigentlich vor 30 Jahren als Low-Code ABAP Entwickler angefangen habe. Ich habe damals im R/2 Reports erstellt. Diese wurden mit Hilfe von logischen Datenbanken realisiert. Ein Entwickler musste lediglich ein paar wenige Kommandos wie GET, CHECK oder WRITE verwenden.

Eigentlich sehr genial, denn damals konnten wir Business-Anforderungen teilweise noch in wenigen Stunden umsetzen. Für Transaktionen konnten wir einen einfachen Screen Painter verwenden und mit PBO und PAI wurde eine sehr simple Dynprologik implementiert.

Schnittstellen wurden mit Hilfe von Batch-Input Mappen auf die Transaktionen realisiert. Eine einheitliche Schnittstellentechnologie für alle – wirklich alle – SAP-Transaktion. Genial!

Am Anfang von R/3 gab es erstmals modulspezifische Berichtsfunktionen (z.B. Report Writer/Report Painter), welche bald durch SAP Query bzw. Quick Viewer ergänzt wurden. Nur zur Verdeutlichung, wir reden hier von einer Zeit vor der 2000er Wende. GuiXT sollte man auch nicht unerwähnt lassen. Ein Tool, mit dem man SAP Gui Screens einfach adaptieren/optimieren konnte.

Und Mitte der 2000er Jahre hat SAP mit dem Visual Composer bzw. dem Composite Application Framework erstmals einen (meiner Meinung nach erfolglosen) Versuch in Richtung Low-Code/No-Code Applikation gestartet.

Aktuelle Low-Code/No-Code Tools der SAP®

Derzeit zählen Tools wie Screen Personas, Fiori Elements oder ganz aktuell SAP AppGyver zu den Low-Code/No-Code Tools der SAP. Im nachfolgenden Teil gehe ich ganz kurz auf diese Anwendungen ein und stelle wie immer weiterführende Links zur Verfügung.

Screen Personas

Ziel von Screen Personas ist es bestehende SAP Gui Transaktionen – auch Kundenentwicklungen – in ein modernes, zeitgemäßes Erscheinungsbild zu bringen. Diese können auch ganz einfach in ein Fiori Launchpad integriert werden. Die Möglichkeiten von Screen Personas sind überschaubar, können aber durch Scripts erweitert werden.

Fiori Elements

Fiori Elements kann man auch zu den Low-Code Tools zählen. Die Darstellung und das Verhalten von Fiori Elements Anwendungen wird rein durch Metadaten (lokal oder vom Backend) gesteuert. Die Daten werden mittels OData (z.B. ABAP RAP oder CAP) prozessiert. SAP selber liefert viele ihrer Fiori Anwendungen in Form von Fiori Elements aus.

Fiori Elements werden mit dem Business Application Studio oder Visual Studio Code erstellt und können bei Bedarf mit Hilfe von den Fiori Tools auch relativ einfach erweitert werden.

SAP® AppGyver

Das ist der jüngste Zukauf der SAP aus dem Jahre 2021. Der finnische Anbieter ist ein weltweit bekannter Anbieter von No-Code Tools und wird derzeit von der SAP sehr gepusht. Auf den ersten Blick sieht das Tool interessant aus. Aber da die Erweiterungsmöglichkeiten sehr, sehr eingeschränkt sind, bin ich nicht sicher ob sich dieses Tool zum Erstellen von Apps für S/4HANA eigenen kann.

Low-Code Plattformen anderer Hersteller

Natürlich bietet nicht nur SAP Low-Code Tools (für SAP) an. Ich möchte hier drei bekannte Anbieter aufzählen, die ebenfalls im Low-Code Teich fischen. Alle Anbieter gehören eher zu den Low-Code Anbietern, sprich die erstellten Anwendungen können mehr oder weniger individuell erweitert werden. Wie genau, muss man sich von Hersteller zu Hersteller speziell ansehen. Und natürlich sind hier extra Lizenzen für die Hersteller zu entrichten.

Neptune

Neptune wurde bereits 2011 von zwei erfahrenen SAP-Beratern gegründet. Von Anfang an mit dem Fokus das Leben eines SAP Developers einfacher zu gestalten. Neptune ist in über 40 Ländern im Einsatz und verfügt über 600 Kunden.

Interessant ist Neptune deshalb, da es weder Gateway noch RAP für die Erstellung von SAPUI5 Anwendungen benötigt und direkt im SAP als Transaktion verfügbar ist.

Simplifier

Simplifier bzw. die Vorgängerfirm iTiZZiMO ist seit 2012 am Markt und verfügt laut eigenen Angaben über viele produktive Referenzen. Simplifier scheint auf den ersten Blick auch für eine Pro-Entwickler interessant zu sein, da es viele Erweiterungsmöglichkeiten gibt.

Mendix

Von Mendix habe ich zuerst vor 3 oder 4 Jahren bei einer TechEd erstmals im Zusammenhang mit SAP gehört. Laut eigenen Angaben zählt Mendix zu den Weltmarktführern im Low-Code Bereich und wurde 2018 von Siemens übernommen. In letzter Zeit habe ich jedoch nicht mehr so oft von SAP & Mendix gehört.

Low-Code/No-Code – Einbahn?

Generelles Risiko von Low-Code/No-Code ist die eingeschränkte oder überhaupt unmögliche Erweiterung durch individuelles Coding. Sobald man sich für einen Low-Code/No-Code Ansatz entscheidet muss man sich diesem Risiko bewusst sein.

Beispielsweise kann ich aus eigener Erfahrung bestätigen, dass man die Fiori Elements umfangreich erweitern kann. Bei AppGyver ist dies laut meinem Kenntnisstand derzeit nicht oder nur in sehr geringem Ausmaß möglich.

Hat irgendwer Zeit unsere alten Listen S4 tauglich zu machen

Hat irgendwer Zeit unsere alten Listen S/4 tauglich zu machen

Mitten in der S/4HANA Einführung kommen die Anforderungen aus dem Fachbereich. „Wir brauchen aber die Lagerstandsauswertung XY nach VKORG unbedingt auch. Ohne der können wir nicht arbeiten.“
Verständlich, denn die Mitarbeiter beschäftigen sich jetzt intensiv mit dem neuen System und versuchen ihre bestehenden Prozesse nachzuspielen.

Aber da fehlt jetzt was.
Klar, die bestehenden Auswertungen und Listen, die in jedem alten R/3 System vorhanden sind. Ohne sie wird der weitere Prozess schwierig.

Aber das Projekt ist bereits in vollem Gange, die Aufwände sind budgetiert und die Ressourcen eingeteilt. Klar, man will immerhin rechtzeitig fertig werden.

Und der Druck wird größer. Auch wenn man im neuen System vielleicht eine andere Herangehensweise an die Prozesse hat, die Leute aus dem Fachbereich wollen dennoch eine gewisse Stabilität. Vielleicht wird man einige dieser Listen im Laufe der Zeit wieder los – vielleicht aber auch nicht. Jedenfalls jetzt – kurz vor GoLive – wo alle nervös sind und die Lage angespannt ist, ist der falsche Zeitpunkt dafür. Also werden die wichtigsten dieser Reports in die neue Fiori Oberfläche übertragen.

Aber wer kennt sich genau aus, wie der Report funktioniert? Wie die Daten gelesen werden? 3000 Zeilen Spaghetti Code aus dem Jahre 1998 wollen auch erst einmal neu gebaut werden.

Genau hier hilft unser Rapid Report Generator.

  • Mit etwas Customizing wird der Report einfach in eine moderne Fiori Applikation verwandelt.
  • Die Logik der Datenbeschaffung bleibt im Report. Der Selektionsbildschirm und die Ergebnisliste werden transformiert.
  • Die Navigation in Business Objekte kann auch durch Fiori Links ersetzt werden.
  • Auch der „Warenausgang“ kann gebucht werden. Sowie beliebige andere Aktionen können ausgeführt werden.

UI38 (so war unser interner Arbeitstitel) kann aber noch viel mehr. Sie haben eine zentrale Stelle, um auch neue Reports anzulegen. Egal ob CDS View basiert, oder in Methoden ausprogrammiert, mit simplem Customizing bekommen Sie diese schnell und einfach in Ihr Fiori Launchpad. Die Arbeit des Rapid Report Generators ist also mit der Einführung noch nicht zu Ende. Im Gegenteil, er ist das zentrale Tool, um Informationen aus dem ERP System schnell an die gesamte Belegschaft zu übermitteln!

Fazit

Unserer Erfahrung nach gibt es diese absolut notwendigen Reports in jedem Unternehmen. Mal sind es 7, mal 100 Listen. Das ist von Unternehmen zu Unternehmen unterschiedlich. Mit dem Rapid Report Generator bekommen Sie diese, unabhängig von der Anzahl, in kürzester Zeit in die Fiori Oberfläche. Somit sparen Sie jede Menge Zeit und kostbare Nerven bei der Integration und können sich um die wesentlichen Dinge kümmern!