Verknüpfungen das Herz des SAP OM

Mit Hilfe der Verknüpfungen zwischen Objekten werden alle Strukturen im Rahmen der Personalplanung abgebildet. Verknüpfungen sind besondere Subtypen des Infotyps 1001. Für jede Verknüpfung existieren zwei Verknüpfungsarten, gekennzeichnet durch A und B. Für jede angelegte Verknüpfung (A oder B) wird automatisch die entsprechende Rückverknüpfung eingerichtet.

Wo ist der Unterschied zwischen Bottum Up und Top Down?

Eine Verknüpfung zwischen zwei Objekten kann folgendermaßen ausgerichtet sein:19

• hierarchisch
• lateral (flach)
• unilateral (einseitig)

Die Verknüpfung zwischen einer leitenden Stellung in einer Organisationseinheit und einer anderen Planstelle innerhalb derselben Organisationseinheit ist beispielsweise hierarchisch. Die leitende Stellung (B 002) ist Linienvorgesetzter der untergeordneten Planstelle (A 002), die wiederum an die übergeordnete Planstelle berichtet. Somit ist „Top Down“ die Betrachtung des Organisationsmanagements von der oberen Position nach unten. „Bottum Up“ hingegen ist die Betrachtung des Organisationsmanagement von unten nach oben.

Welche Verknüpfungen gibt es?

Im SAP Organisationsmanagement werden verschiedene Objekttypen wie Organisationseinheit oder Planstelle verarbeitet. Damit zwischen diesen Objekttypen eine Verbindung hergestellt werden kann, werden Verknüpfungen eingesetzt und somit eine Struktur aufgebaut. Die in der Tabelle vorgestellten Verknüpfungen sind im SAP Standard enthalten.

Kontaktieren Sie mich gerne, wenn Sie Fragen zum Thema Verknüpfungen im SAP Organisationsmanagement haben.

The post Verknüpfungen im SAP Organisationsmanagement (OM) appeared first on Die SAP HR/HCM Berater.

Transportieren gehört für jeden SAP-Entwickler zu den täglichen Aufgaben. Allerdings wird nicht in jedem Projekt die gleiche Art zum Transportieren verwendet. Am einfachsten ist es, einen Transportauftrag anzulegen und diesen inklusive der Aufgabe(n) freizugeben, sobald der aktuelle Stand auf dem Testsystem getestet werden soll. Wir nutzen für den Transport jedoch eine wesentlich sicherere und effizientere Lösung. Diese stelle ich Ihnen in diesem Blogartikel vor.

Warum sind Transporte im Projekt wichtig?

Mit Transporten werden neue Entwicklungen oder Anpassungen an Objekten in die weiteren Systeme Ihrer Systemlandschaft eingespielt. Mit der richtigen Vorgehensweise behalten Sie die Übersicht und Ordnung über die noch offenstehenden und schon eingespielten Objekte. Zusätzlich können Schiefstände auf den Systemen vermieden werden. Das sorgt dann auch dafür, dass es bei einem Go-Live zu keinen Fehlern mehr kommen wird, die auf nicht-transportierte Objekte zurückzuführen sind. Auch wird eine klare Dokumentation von Änderungen sichergestellt.

Richtig transportieren – diesen Weg empfehlen wir!

Wir empfehlen für jedes Projekt/Change, genau eine Transportmöglichkeit zu nutzen ­­­­­­– den Transport von Kopien (TOC). Über ihn werden die neuen Entwicklungen auf das Testsystem transportiert. Anschließend geben Sie die Aufgabe frei und entwickeln für Änderungen an einer neuen Aufgabe im alten Transport weiter. Erst wenn alles getestet wurde und das (Teil-)Projekt abgeschlossen ist, wird der ursprüngliche Transport freigegeben und in die weiteren Systeme transportiert.

Abb 1. Richtig transportieren mit Transport von Kopien (TOC).

Wie funktioniert ein Transport von Kopien (TOC)?

Meine Kollegen vom Fachbereich RZ10 haben dieser Funktion ein umfangreiches How-to gewidmet, das ich Ihnen an dieser Stelle nicht vorenthalten möchte: https://rz10.de/sap-basis/transporte-von-kopien/

Abb 2. Transportübersicht in der SE01.

Howto: Tabellen transponieren / Datentabellen „drehen“

Dieses Howto erläutert Ihnen, wie Sie eine gegebene Tabelle transponieren.

Bessere Übersicht mit den richtigen Einstellungen

Für eine bessere Übersicht der Transportaufträge empfehle ich, die benutzerspezifischen Einstellungen anzupassen. Hier haben Sie die Möglichkeit, die Aufgabenkurztexte statt des Aufgabentyps anzeigen zu lassen, sodass einzelne Aufgaben bzw. kleinere Anpassungen besser identifiziert werden können. Auch das Änderungsdatum kann hier eingeblendet werden. Die Einstellungen finden Sie unter Hilfsmittel > Einstellungen im Reiter „Transport Organizer“.

Abb 3. Mit dem Transport Organizer können benutzerspezifische Einstellungen angepasst werden.

RHMOVE30 – Transportieren von Workflow-Aufgaben und weiteren Objekten

Mit dem Report RHMOVE30 können Objekte manuell auf einen Transportauftrag geschrieben werden. Dies ist insbesondere für jene Objekte sinnvoll, die auch ohne Transportauftrag geändert werden können. Hierzu zählen beispielsweise Workflow-Aufgaben. Im Optimalfall sollten sich alle Objekte zur Produktivsetzung direkt im Transportauftrag befinden, damit später keine Nacharbeiten mehr notwendig sind.

Abb 4. Mit dem Report RHMOVE30 werden Objekte manuell auf einen Transportauftrag geschrieben.

Zögern Sie nicht, uns zu kontaktieren, wenn Sie noch weitere Fragen haben. Wir unterstützen Sie sehr gerne.

The post Richtig transportieren mit „Transport von Kopien“ (TOC) appeared first on Die SAP HR/HCM Berater.

Den SAP Standard zu erweitern ist ein heikles Thema, das in jedem Unternehmen unterschiedlich gehandhabt wird. Egal, ob es nun um die Erweiterung des Fiori-Standards geht oder um einen anderen SAP-Anwendungsfall, die Herausforderung, den Support der SAP weiterhin gewährleisten zu können, ist immer vorhanden. Nichtsdestotrotz entscheiden sich viele Kunden oft für Erweiterungen, da der reine Standard ihre Bedürfnisse nicht abdeckt.

Auch im Fiori-Umfeld sind gut durchdachte Erweiterungen, wie Sie es z. B. von Web-Dynpro-Applikationen gewohnt sind, möglich. Die Meinung, dass Fiori hier einschränkt und dies gar unmöglich macht, ist schlichtweg falsch. In diesem Blogbeitrag möchte ich dem Thema auf den Grund gehen.

Automatische Übernahme von Erweiterungen

Vielleicht haben Sie schon Erweiterungen durchgeführt oder durch ein Beratungshaus durchführen lassen und fragen sich, ob beispielsweise Ihre Sonderverbuchung im Abwesenheitsantrag nun auch im Fiori-Abwesenheitsantrag durchgeführt wird? In diesem Fall heißt es ganz klar „es kommt darauf an“. Die SAP hat darauf geachtet, dass bestimmte Standarderweiterungen in Fiori übernommen werden. Hier muss jedoch genau hingeschaut werden, ob die Erweiterungen auch für die Fiori-Applikation angedacht sind und entsprechend übernommen werden. Hierfür entweder probeweise die Applikation auf dem Testsystem einstellen und überprüfen. Oder aber Sie nutzen z. B. unsere Expertise aus vergangenen Fiori-Einführungen.

E-Book Fiori im HCM

Welche Services und Apps bietet SAP Fiori an? Wir stellen Ihnen die wichtigsten HCM Services und ihre Funktionen vor.

Eigene Erweiterungen

Vielleicht haben Sie gehört, dass bestimmte Anwendungen in SAP nicht erweiterbar sind. Diese Aussage ist falsch. Wenn Sie eine Funktionalität unbedingt auch in Fiori integrieren müssen, ist dies definitiv machbar. Wichtig ist dabei, dass Erfahrung in diesem Bereich da ist. So vermeidet man unnötige Mehraufwände. Wenn Sie Interesse an konkreten Beispielen haben, dann empfehle ich das Webinar meines Kollegen Frank Nedwed zu dem Thema: Fiori-Erweiterungen leicht gemacht . In diesem zeigt er das Standarderweiterungskonzept der SAP für Fiori-Apps.

Meine Anforderungen sind zu speziell für eine Fiori-App-Erweiterung

Im Zweifel gibt es immer noch die Möglichkeit, eine eigens entwickelte Fiori-Applikation einzusetzen oder eine SAP Standardapplikation zu kopieren und anzupassen. Von daher sind all Ihre individuellen Bedürfnisse immer abdeckbar, auch wenn sie zu speziell scheinen.

Fazit

Ich habe nun mit den Vorurteilen gegenüber Erweiterungen des Fiori-Standards aufgeräumt und Ihnen gezeigt, dass es möglich ist, alles umzusetzen, was Sie sich vorstellen können – und das im modernen, userfreundlichen und mobilen Fiori-Design. Es gibt natürlich eine Kehrseite. Durch eine erhöhte Komplexität der Fiori-Anwendungen (z. B. OData-Services) ist eine Erweiterung nicht so einfach gemacht wie noch bei Web-Dynpro-Anwendungen. Natürlich erhöhen diese die Wartung und auch eine genaue Prüfung nach Updates ist notwendig. Deswegen ist unsere Empfehlung bei jeder Anpassung, genau abzuwägen, ob diese notwendig ist und entsprechendes Budget für die Wartung einzuplanen. Dann steht Ihrem individuellen Projekt nichts im Wege und Sie können wie gewohnt Ihre kompletten Anforderungen ausleben. Gerne berate ich Sie zu dem Thema – kontaktieren Sie mich einfach.

The post Erweiterungen des Fiori-Standards appeared first on Die SAP HR/HCM Berater.

Mit der endenden Wartung des HCM ist aktuell geplant, dass auch das Reisemanagement (FI-TV) seinen Weg in die ewigen Jagdgründe finden wird. Diese Tatsache ist für viele unserer Kunden aktuell ein Grund für schlaflose Nächte, da eine gute Alternative noch nicht gefunden ist. Die 3 Module Reiseantrag, -planung und -abrechnung sind in ihrer Funktion sehr umfangreich und haben Anwendern zudem die Möglichkeit gegeben, diese weitreichend an die eigenen Bedürfnisse anzupassen.

Das war oftmals durch das großzügige Customizing der SAP möglich und konnte zudem über eigene Erweiterungen im Code individuell ergänzt werden. Viele Kunden sehen ihre Anforderungen im SAP Cloud-Nachfolger der On-Premise Lösung noch nicht abgebildet, für den öffentlichen Dienst ist Concur aufgrund der besonderen Bestimmungen (Bundes-, Landesreisekostenrecht) selten denkbar. Wie geht es also mit dem Reisemanagement in Unternehmen weiter?

Die aktuelle Faktenlage

Um eine Entscheidung für eine zukünftige Umsetzung des Corporate Travelmanagements zu treffen, lassen Sie uns zuerst die Faktenlage zum aktuellen SAP-Produkt anschauen (Stand August 2019):

• Der Support von SAP HCM in seiner jetzigen Form endet voraussichtlich im Jahr 2025.
• Im Jahr 2023 wird bis min. 2030 SAP HCM for SAP S/4HANA verfügbar sein. Das Produkt ist eine eigenständige Instanz, die auf der bestehenden Codeline basiert.
• Das Reisemanagement ist eine FI-Komponente und wird nach aktueller Planung kein Bestandteil von SAP HCM for SAP S/4HANA sein.
• Die LSO war auch kein Bestandteil von SAP HCM for SAP S/4HANA und wurde auf Drängen der DSAG in den Umfang aufgenommen.
• Die SAP hat zuletzt viel Geld in das Reisemanagement investiert (zahlreiche Neuerungen über SAP Customer Connection, Mein Reiseantrag V2, Amadeus Cytric Integration in Fiori, On-Behalf-Funktionalität).
• Reisemanagement ist in vielen Unternehmen im Personalmanagement verortet.

Diese Informationen zu deuten, ist sicherlich nicht einfach, aber folgende Aussagen scheinen mir naheliegend:

• Da die aktuelle Lösung noch bis min. 2025 weiterläuft, können sich geringfügige Investitionen im bisherigen System auch vor 2025 rechnen.
• Es ist nicht unwahrscheinlich, dass auch das Reisemanagement eine Gnadenfrist bis 2030 durch SAP HCM for SAP S/4HANA bekommt. (Hintergrund: Analog Learning Solution, hohe Investitionen seitens der SAP in der letzten Zeit, fachliche Nähe zu HR).

E-Book Fiori im HCM

Welche Services und Apps bietet SAP Fiori an? Wir stellen Ihnen die wichtigsten HCM Services und ihre Funktionen vor.

Reisemanagement in Fiori

„Run Simple & Go Cloud“ ist der SAP-Ansatz der heutigen Zeit. Dies wird zum einen in den hoch spezialisierten Cloud-Anwendungen, wie z. B. Concur oder auch SuccessFactors deutlich: komplexe personalwirtschaftliche Szenarien können mit dem Smartphone durchgeführt werden. Andererseits findet eine Entwicklung im On-Premise-Markt in Form von Fiori-Anwendungen statt. Genau hier hat sich im Reisemanagement in der letzten Zeit vieles getan, was bei den Kunden gut ankommt: Wir führen neuerdings vergleichsweise viele Fiori-FI-TV-Einführungsprojekte durch. Dies war in den vergangenen Jahren, seit der Fiori-Boom begann, nicht der Fall. Die neuen Versionen der Fiori-Anwendungen entstanden zudem durch Customer-Connection-Projekte (https://influence.sap.com/sap/ino/#/campaign/112), was dafür spricht, dass viele Kundenwünsche umgesetzt sind, die auch Ihnen gefallen könnten. Jetzt aber zu den neuen Funktionen:

Die Neuerungen auf einen Blick

Es gibt 2 neue Apps im Reisemanagement: Mein Reiseantrag (V2) und Meine Spesenabrechnungen (V2).

Folgende Features wurden für die beiden Anwendungen umgesetzt:

• Reisevorschüsse können erfasst werden
• Weitere Reiseziele können erfasst werden
• Assistenzfunktion: Erfassung im Namen eines anderen Mitarbeiters (on-behalf)
• Erweiterte Feldkontrolle mittels FITVFELD_WEB
• Reisenummer wird im Antrag/der Abrechnung angezeigt
• Anlagen in Form von Business Documents (ArchiveLink) können in der Reise abgelegt werden
• Zuletzt genutzte Adressen und vordefinierte Reiseziele werden als Dropdown für eine neue Reise angeboten
• Alle Kontierungsobjekte werden analog Web Dynpro unterstützt
• Integration in Third-Party-Buchungssysteme (Amadeus Cytric Standard Integration)

Folgende Features stehen zudem in der Anwendung Meine Reiseabrechnungen (V2) zur Verfügung:

• Ein Spesenbeleg kann auf mehrere Positionen aufgeteilt werden
• Privatanteile kann für Belege angegeben werden
• Der Wechselkurs für Fremdwährungen kann bei Bedarf angepasst werden
• Die Kreditkartenbelege können durchsucht und angezeigt werden
• Anhänge können zu genehmigten Reisen hinzugefügt werden
• Kostenzuordnung für weitere Reiseziele
• Detaillierte Adresserfassung für Fahrtstrecken
• Externe Teilnehmer können erfasst werden

Wie Sie sehen, handelt es sich um vollkommen neue Möglichkeiten des Reisemanagements in SAP: Reisen können mittels der neuen Funktionen sowohl mobil beantragt, ein Reiseplan erstellt und die Abrechnung mit dem Smartphone angelegt werden. Lange vermisste Funktionen, wie die Assistenzfunktion oder weitere Reiseziele, sind nun standardmäßig verfügbar. Die Lösung in Fiori hat zudem einen besonderen Charme: Standardnahe Umsetzungsprojekte lassen sich in 2 Wochen durchführen – kostensparend für Sie, ein schneller Mehrwert für Ihre Mitarbeiter.

Ein Lösungsvorschlag für das Reisemanagement der nächsten Jahre

Sie sehen Ihre Zukunft im Reisemanagement eher On-Premise als in der Cloud? Sie sind im öffentlichen Dienst tätig und die Cloud kann Ihnen noch keine adäquate Lösung anbieten? Dann ist das Reisemanagement in Fiori in Kombination mit Cytric Ihre Alternative.

In der Fiori-Anwendung „Mein Reiseantrag“ erstellen Sie den Reiseantrag, in dem Sie sowohl mehrere Ziele als auch Reisevorschüsse erfassen können. Die automatisch nach Cytric übertragene Reisenummer und Zielinformationen nutzen Sie, um dort Hotels, Flüge und Bahnreisen zu buchen. In der App „Meine Reiseabrechnungen“ können die entstandenen Kosten erfasst und an den Mitarbeiter ausgezahlt werden. Wahlweise kann zudem mittels einer zwischengeschalteten A1-Anwendung die Beantragung der A1-Genehmigung automatisiert werden.

Der hier beschriebene Lösungsweg ist günstig und erlaubt es Ihnen trotzdem, Schritte in die mobile Zukunft zu gehen.

Was geht noch?

Sicherlich gibt es auch im Reisemanagement so viele Umsetzungsmöglichkeiten, wie es Customizingtabellen in SAP gibt. Deshalb interessiert mich besonders, wie Sie sich für die Zukunft in diesem Bereich aufstellen und welche Technologien Sie dabei einsetzen werden. Setzen Sie sich doch gerne mit mir in Kontakt und wir tauschen uns über gegenseitige Erfahrungen aus.

The post Reisemanagement in Fiori als Alternative zu SAP Concur appeared first on ActivateHR.

Heute will ich euch vormachen, wie ihr einen ODATA Service anlegen und testen könnt.

Dabei erkläre ich zuerst einmal das ODATA Model mit Entitätstypen und EDM-Typen. Danach zeige ich euch, wie ihr alle 5 Standard-Methoden des ODATA Services implementieren und testen könnt. Ich zeige euch hierbei mein Best-Practice vorgehen zum Arbeiten mit ODATA und weise gelegentlich auf weitere Alternativen hin.

ODATA Model

Das ODATA Model bildet das Daten Modell eines ODATA Services ab. Der ein oder andere kennt den Begriff „Entität“ sicherlich noch aus alten Datenbankvorlesungen. Falls nicht, auch nicht schlimm. Das Ganze ist schnell erklärt: Einen Entitätstypen könnt ihr euch wie eine ABAP Struktur vorstellen. Ihr definiert Felder mit den entsprechenden Datentypen und einigen weiteren Eigenschaften. Allerdings habt ihr hierfür nicht die ABAP Datentypen zur Verfügung.

ODATA ist eine Schnittstellentechnologie, welche nicht nur von SAP verwendet wird. Daher gelten hier die EDM-Datentypen. In den meisten Fällen gibt es im entsprechenden SAP Backend auch eine Struktur mit genau den selben Feldern und SAP Datentypen, die dem Entitätstypen gleicht. Aber genug der Theorie, nun zeige ich euch, wie ihr euren ersten Entitätstypen anlegen könnt.

Entitätstyp anlegen

Es gibt verschiedene Möglichkeiten, einen Entitätstypen anzulegen. Ihr könnt die Felder beispielsweise manuell einpflegen und mappen, oder direkt aus einer entsprechenden SAP Struktur importieren. Ich erspare mir gerne die Arbeit und importiere die Felder. Dafür muss ich mir also zunächst eine entsprechende ABAP Struktur in der Transaktion SE11 anlegen:

Für mein Beispiel will ich eine Fiori Anwendung schreiben, welche mit Personen arbeitet. Dafür habe ich mir eine Struktur angelegt, welche eine Personalnummer, verschiedene Namensfelder und das Geburtsdatum enthält. Auf Basis dieser Struktur will ich jetzt einen Entitätstypen anlegen. Dafür gehe ich in die Transaktion SEGW und lege mir erst einmal ein ODATA Projekt an.

Ihr solltet nun ein neues ODATA Projekt mit 4 automatisch generierten Unterordnern vor euch haben. Mit Rechtsklick auf „Data Model“ bekommt ihr nun die Optionen, einen neuen Entitätstypen frei anzulegen oder aus einer ABAP-Dictionary-Struktur zu importieren:

Zuerst geben wir den Namen eures Entitätstypen an und die eben angelegte Dictionary-Struktur, aus der wir die Felder importieren möchten:

Im Anschluss legen wir fest, welche Felder aus der Struktur mit in den ODATA Service übernommen werden sollen:

Als letztes legen wir den Schlüssel für die Entität fest. Dieser Schritt wird später großen Einfluss haben. Wichtig ist, dass später jedes Entity eindeutig über den Schlüssel identifiziert werden kann. Ich versuche immer, dafür mit so wenigen Feldern wie möglich auszukommen, um es mir später nicht unnötig kompliziert zu machen. In diesem Falle reicht mir die Personalnummer aus, um jede Person eindeutig zu identifizieren:

Unseren ersten Entitätstypen haben wir hiermit bereits angelegt. Er sollte nun im Ordner „Data Model“ unter „Entitätstypen“ sichtbar sein. Unter eurem Entitätstypen sehr ihr nun Eigenschaften und Navigationseigenschaften. Für uns interessant sind erst einmal die Eigenschaften. Mit einem Doppelklick können wir uns ansehen, welche Felder mit welchen Entitätstypen wir im Entitätstypen haben, welche Eigenschaften dazu gehören und zu welchem Feld unserer Struktur diese gemapped sind. Das Mapping von ABAP-Datentyp zu EDM-Typ wurde beim Erstellen automatisch vorgenommen.

EDM-Typen

Wie ihr sehen könnt, weichen die EDM-Typen etwas von den ABAP-Typen ab. Mit F4 (Suchhilfe) auf eines der EDM-Coretyp Felder, könnt ihr euch alle vorhandenen EDM-Typen anzeigen lassen:

In sehr vielen Fällen wird der ABAP Datentyp auf den Edm.String Typen abgebildet. Häufig passt das auch gut für die Datenübertragung. Allerdings habe ich festgestellt, das zum Beispiel der ABAP Boolean als Char1 auch als String und nicht als Edm.Boolean abgebildet wird. Das korrigiere ich immer nachträglich, ansonsten benötigt ihr ein zusätzliches Mapping sowohl im Frontend, als auch im Backend, um mit dem Feld weiterarbeiten zu können.

Auch bei der Übertragung von Daten solltet ihr aufpassen. ODATA hat keinen Datentyp für ein normales Datum. Es gibt nur den Typen Edm.DateTime, welcher neben dem Datum auch noch die Uhrzeit und die Zeitzone überträgt. Übertragt ihr ein normales Datum aus dem Backend, werden die fehlenden Informationen einfach standardmäßig aufgefüllt. Im Frontend müsst ihr das Datum dann wieder in das gewünschte Format bringen und die zusätzlichen Informationen wieder rausfiltern. Bei der Übertragung vom Frontend ans Backend kann es aufgrund der Zeitzonen zu einer Verschiebung des Datums um einen Tag kommen. Das sollte dann im Besten Fall direkt im Frontend vor der Datenübertragung schon korrigiert werden. Bei Daten ist es auch wichtig, den Haken bei der Eigenschaft „Nullwerte möglich“ zu setzen. Ansonsten müsst ihr zwangsläufig immer einen Wert mitliefern.

Nachdem alle Eigenschaften korrigiert sind, klickt ihr oben auf den Button „Laufzeitobjekte generieren“. Dieser prüft das Projekt auf Konsistenz und erzeugt die für die Datenübertragung benötigten Klassen mit den entsprechenden Schnittstellen:

Service registrieren

Euer Service ist im Backend nun angelegt, kann aber von außen noch nicht gesehen werden. Um dies zu ermöglichen, müssen wir ihn noch registrieren. Hierfür gibt es wieder verschiedene Möglichkeiten. Normalerweise wird der Service entweder in der Sap Cloud Plattform (SCP) registriert, oder auf einem Gateway-System. Die Services direkt auf dem Backend-SAP System zu registrieren funktioniert auch, wird meist aber aus Sicherheitsgründen nur zu Testzwecken genutzt. Ich werde die Services im Folgenden auf einem extra Gateway System registrieren.

Also melde ich mich entsprechend am Gateway System an und starte die Transaktion /n/IWFND/MAINT_SERVICE . Dort füge ich den Service über die entsprechende Schaltfläche hinzu:

Im ersten Schritt wähle ich nun das Backend-System aus, auf dem ich meinen ODATA Service implementiert habe:

Sollte euer System nicht in der Suchhilfe zu finden sein, sind noch Konfigurationen am System notwendig. Darauf werde ich in diesem Tutorial nicht näher eingehen. Nachdem ihr euer System ausgewählt habt, sucht ihr in der Liste euren Service und fügt diesen dann hinzu. Im folgenden Fenster spezifiziert ihr noch das Entwicklungspaket, schon ist der Service erfolgreich registriert:

ODATA Services

Wir haben jetzt unseren Entitätstypen angelegt und die Eigenschaften der Felder entsprechend unserer Wünsche angepasst. Nun wird es Zeit, die Datenübertragung zu ermöglichen. Dafür gibt es die bereits erwähnten 5 Standard-Methoden. Im folgenden werden wir alle 5 Methoden kurz besprechen und für unser Beispiel kurz implementieren. Dafür doppelklicken wir den Ordner „Laufzeitartefakte“ im ODATA Projekt (auf dem Backend-System) und öffnen die ABAP-Klasse, welche auf „DPC_EXT“ endet. Ganz wichtig ist hierbei, dass ihr diese Klasse nehmt. In der Klasse, welche auf „DPC“ endet findet ihr die selben Methoden. Eure Änderungen werden hier aber jedes Mal komplett überschrieben, wenn ihr die Laufzeitobjekte neu generiert nach einer Änderung am Datenmodell. Die „DPC_EXT“ Klasse ist eine Erweiterung der „DPC“ Klasse. Daher habt ihr hier die Möglichkeit, alle geerbten Methoden zu redefinieren.

Die 5 Service-Implementierungen werden aus der Klasse …_DPC geerbt und werden entsprechend in der Methoden-Übersicht der Klasse aufgeführt:

GET_ENTITYSET

GET_ENTITYSET liefert eine Menge von Entitäten zurück. Dies wird zum Beispiel häufig verwendet, um eine Liste von Elementen zu befüllen. In unserem Fall der SplitApp verwenden wir den Service dafür, die Masterliste auf der linken Seite des Bildschirms zu befüllen. Hierfür rufen wir den Service aus dem Frontend ohne Filter auf und steuern im Backend, welcher Benutzer welche Personen sehen soll.

Nachdem wir in den Änderungsmodus gewechselt sind, können wir die Methode GET_ENTITYSET für unseren Entitätstypen redefinieren. Dadurch legen wir in der Klasse DPC_EXT eine eigene Implementierung zu der geerbten Methode an:

Innerhalb dieser Methode können wir nun die vom Frontend übergebenen Filter auslesen, die Anfragen im Backend verarbeiten und die Ergebnisse wieder in die Schnittstelle füllen. Da in unserem Fall kein Filter benötigt wird, sparen wir uns das an dieser Stelle. Aber keine Sorge, auf die Filter werde ich in den nächsten Services noch eingehen. Für die Methode GET_ENTITYSET steht die Tabelle et_entityset als Container für die Ergebnisdaten zur Verfügung. Diese müssen wir also in unserer Methode befüllen.

Ich habe mir eine eigene Klasse für den Entitätstypen angelegt, welche ich zum Befüllen der Schnittstelle verwenden werde. Theoretisch könnt ihr den Quellcode natürlich einfach in die Methode GET_ENTITYSET implementieren, aus meiner Sicht ist eine Trennung an dieser Stelle allerdings sauberer. Die Tabelle et_entityset basiert auf dem Entitätstypen, welcher wiederum auf unserer ursprünglich angelegten Struktur basiert. Wir können also einfach einen Tabellentyp dieser Struktur als Rückgabe für unsere Methode wählen und das et_entityset somit direkt befüllen. Sollten wir nicht alle Felder aus der Struktur übernommen haben, oder weitere Felder zum Entitätstypen hinzugefügt haben, wäre an dieser Stelle noch ein Mapping notwendig.

Unsere erste Serviceimplementierung ist nun fertig gestellt. Aber funktioniert das auch alles so, wie wir uns das vorstellen? Wir wollen unseren neuen Service natürlich direkt testen, bevor wir das Frontend dazu fertig gestellt haben. Hierfür loggen wir uns wieder im Gateway System ein und starten die Transaktion /n/iwfnd/maint_service. Hier haben wir die Möglichkeit, den Service über den SAP Gateway Client zu testen:

Hier ist automatisch die HTTP Methode „GET“ und die zu unserem ODATA Service passende Request-URI voreingestellt. Den ersten Test starten wir, indem wir die vorhinterlegten Einstellungen ausführen. Hat bis hierhin alles gut funktioniert, sollten wir den Status Code 200 OK in einem grün hinterlegten Fenster sehen. Zusätzlich steht im Fenster rechts unten die Antwort, welche alle von uns hinterlegten Entitätstypen enthält:

Sollte das bei euch nicht funktioniert haben, probiert mal die Transaktion /n/iwfnd/error_log aus. Hier findet ihr meist hilfreiche Debugging-Informationen, wenn ODATA Aufrufe fehlgeschlagen sind.

Um den gerade implementierten Service GET_ENTITYSET zu testen, müssen wir lediglich die URL hinter dem _SRV abändern. Hier tragen wir einfach das Set des eben von uns erstellten Entitätstypen ein: PersonSet

Hier bekomme ich nun für jede Person, die meine Methode GET_ENTITYSET zurückliefert, einen Eintrag:

Falls ihr hierbei nicht den Code 200, sondern einen Fehler bekommt, empfehle ich 2 Möglichkeiten zum Debugging. Ihr könnt direkt am Anfang der Methode GET_ENTITYSET einen externen Breakpoint setzen. Solltet ihr erst gar nicht bis dahin kommen, hilft wieder die Transaktion /n/iwfnd/error_log auf dem Gateway System. Sobald bei euch auch der grüne Statuscode und die richtigen Personen im Ergebnis stehen, habt ihr es geschafft! Unser GET_ENTITYSET funktioniert!

GET_ENTITY

GET_ENTITY liefert als Ergebnis ein einziges, spezielles Entity anstelle einer Ergebnismenge. Bei diesem Service muss der eindeutige Schlüssel mitgegeben werden, um das Entity zu identifizieren. Um den Service zu implementieren, redefinieren wie die Methode GET_ENTITY aus unsere DPC_EXT Klasse analog zum vorigen Vorgehen.

Innerhalb der Methode müssen wir zuerst die mitgegebene ID auslesen. Die regulär übergebene ID ist in der Tabelle IT_KEYTAB als Key-Value-Pair zu finden. Der Schlüssel ist hierbei die Bezeichnung des jeweiligen Attributs. In unserem Falle „Pernr“, da wir dies als Schlüssel unseres Entitätstypen definiert haben. Der entsprechende Wert dazu steht dann im „Value“ Attribut des Tabelleneintrages. Ich lese die PerNr in diesem Falle wie folgt aus:

Die Ergebnismenge aus dem Backend wird am Ende in den Export-Parameter er_entity geschrieben. Hierbei handelt es sich um eine Struktur vom Typ des ODATA Entitätstypen. Für die Backend-Logik ist es an euch, den passenden Personensatz zur übergebenen Personalnummer aufzubereiten.

Zum Testen der Implementierung gehe ich wieder in den SAP Gateway Client auf meinem Gateway-System und passe die URL etwas an, sodass ich die entsprechende URL übergebe zu meinem Personenset: /sap/opu/odata/sap/ZFTENT_HOWTO_ODATA_SRV/PersonSet(‚12345678‘). Wenn alles fehlerfrei ist, bekomme ich den grünen Code 200 zurück und in dem xml-Dokument die Details zu meiner Person:

CREATE_ENTITY

Create Entity soll einen neuen Datensatz im Backend anlegen. Dafür müssen vom Frontend natürlich alle relevanten Eigenschaften mitgegeben werden. Um den Service zu implementieren, redefinieren wir die Methode CREATE_ENTITY der DPC_EXT Klasse analog zu den vorigen Malen. Im der Methode suchen wir diesmal nicht nach einem Key, sondern nach allen relevanten Informationen, um den neuen Datensatz anzulegen. Dafür wird uns das Objekt io_data_provider mitgeliefert. Mit der Methode read_entry_data() bekommen wir alle vom Frontend übergebenen Daten zurück.

Für den Export-Parameter er_entity müssen wir eine Struktur vom Typ des ODATA Entitätstypen mitgeben. Die ausgelesenen Daten können wir nun im Backend verwenden, um einen entsprechenden Datensatz zu erstellen. Wichtig hierbei ist, dass wir den Export-Parameter er_entity vor Ende der Methode befüllen, da ansonsten der HTTP Fehlercode 500 zurückgegeben wird. Normalerweise werden einige Eigenschaften im Backend generiert und können nach Erstellung dann an das Frontend zurückgegeben werden. Da dies bei mir nicht der Fall ist, übergebe ich einfach die selben Daten wieder zurück:

Zum Testen müsst ihr dementsprechend natürlich Informationen für den zu erstellenden Backend-Datensatz mitgeben. Im Gateway-Client könnt ihr euch dafür einfach behelfen: Verwendet erst den vorhin beschriebenen GET_ENTITY Aufruf, um einen Datensatz im rechten xml Ergebnisfeld zu haben. Dann könnt ihr einfach rechts oben in der Leiste auf „Als Anf. verwenden“ klicken, um die xml Struktur im linken Feld zu sehen:

In der xml-Struktur auf der linken Seite löscht ihr nun alles zwischen dem <entry> und dem <content> Tag. Jetzt sollte der verbleibende Teil etwa so aussehen:

Den verbliebenen Datensatz könnt ihr anpassen, sodass er eurem neu einzufügendem Satz entspricht. Nun müssen wir nur noch die HTTP auf „Post“ stellen und die selbe URL wie für den Test vom GET_ENTITYSET verwenden: /sap/opu/odata/sap/ZFTENT_HOWTO_ODATA_SRV/PersonSet

Wenn alles funktioniert habt, solltet ihr jetzt den grünen HTTP Statuscode 201 – Created sehen und den zurückgelieferten Datensatz im Ergebnis auf der rechten Seite:

UPDATE_ENTITY

Für die UPDATE_ENTITY Methode übergeben wir sowohl einen Schlüssel zur Identifizierung des Datensatzes, als auch jede Menge Attribute für das Update. Dafür lesen wir die it_keytab analog zur GET_ENTITY Methode aus und die übergebenen Daten analog zu CREATE_ENTITY. Nach welchem Schema ihr das Update nun in eurem Backend durchführt, ist euch überlassen. Falls ihr euch das Auslesen aus der Keytab an dieser Stelle sparen wollt, findet ihr den Schlüssel auch in den ausgelesenen Attributen eurer Entität.

Ihr könntet nun auch analog zu vorigen Methoden Rückmeldung zum Erfolg der Methode geben, aber auch ohne einen Rückgabewert zu befüllen, läuft der erfolgreiche HTTP Request auf eine grüne 204:

Zum Testen im Gateway-Client habe ich mir analog zu CREATE_ENTITY einen Datensatz vorbereitet, die HTTP Methode auf „Put“ gestellt und in der URL wieder eine ID mitgeliefert:

DELETE_ENTITY

Der letzte ODATA Service befasst sich mit dem Löschen eines Datensatzes. Hierfür müsst ihr lediglich eine ID übergeben. Das vorgehen in der DELETE_ENTITY Methode ist daher wieder ein Auslesen der it_keytab analog zu GET_ENTITY. Bei Bedarf könnt ihr auch hier wieder Informationen über den gelöschten Datensatz ans Frontend übergeben, andernfalls kommt ihr analog zum Update auf den HTTP Code 204:

Zum Testen im Gateway-Client setzt ihr die HTTP Methode auf „Delete“ und wählt die URL mit ID analog zu GET_ENTITY:

Nun haben wir alle 5 ODATA Services kennen gelernt, für unser Beispiel implementiert und im Gateway-Client getestet. Im nächsten Teil der Reihe werden wir diesen ODATA Service weiterverwenden und die entsprechende Fiori Anwendung dafür entwerfen.

Wenn der OData Service zu Fehlern führt [Whitepaper]

Mit der App-Entwicklung in Fiori hat sich eine Sache grundlegend geändert: Es ist ein Zugriff über die OData Services notwendig.

Hat es dir gefallen?

Wenn es dir gefallen hat, schau doch gerne bei der ODATA Grundlagen Reihe vorbei. Dort gibt es weitere Grundlagen praktisch erklärt!

SAPUI5: ODATA Grundlagen in der praktischen Verwendung

The post ODATA Grundlagen: Services anlegen und testen appeared first on ActivateHR.

Die wohl interessanteste und wichtigste Nachricht auf dem DSAG Jahreskongress 2019 war, dass die Forderung der DSAG Arbeitsgruppe Personalwesen die SAP bewegt hat Ihre Strategie für SAP HCM zu überdenken.

Anstatt 2023 wird es nun 2022 mit dem SAP HCM for S/4HANA. 

Anstatt das ein Carve Out, also eine separate SAP HCM Instanz dafür notwendig ist, ist nun SAP HCM im ERP S/4 Kontext als embedded Lösung möglich.

Aber was heißt das nun für die Unternehmen?

1. Für alle die SAP HCM im ERP integriert auf einer Maschine betreiben bedeutet dies, dass Sie kein teures Carve Out Projekt machen müssen. Gut für Kunden, schlecht für die Beraterwelt
2. Wartung und Support Zusage der SAP orientiert sich nun an die Wartung und Support Zusage der gesamten S/4 Suite. Bedeutet mit jedem Release das nach 2025 raus kommt wird 5 Jahre Wartung und Support zugesagt. (Aktueller Stand). Das bedeutet wiederum, dass eine Payroll und Zeitwirtschaft wohl über 2030 hinaus supportet bleiben.
3. Wenn man sich nun die technologische Weiterentwicklung der SAP Cloud Plattform (SCP) anschaut mit dem neuen Event Bus und dem Zentralen Data Hub Ansatz, würde ich behaupten, dass ein SuccessFactors Employee Central für viele Unternehmen noch weniger Sinn machen wird. Denn die Stammdaten können zentral in der SCP liegen oder via Eventsteuerung live fortgeschrieben werden.

Was müssen Sie nun machen?

Nach der Strategie ist vor der Strategie. Im Grunde müssen Sie nun Ihre SAP HCM Strategie auf diese Neuerung anpassen. Ihre Projektroadmap überarbeiten und geplante Projekte vielleicht einstampfen.

Gerne helfen wir Ihnen aber dabei, eine neue Strategie für Ihre SAP HCM Prozesse und Systemlandschaft aufzustellen.

The post DSAG JK 2019 – SAP HCM ab 2022 in S/4HANA ERP embedded – Was bedeutet das für Sie? appeared first on ActivateHR.

Mit SAP ECC PS oder S/4HANA PS arbeiten viele Unternehmen strukturiert an der Umsetzung ihrer Projekte. Die Ressourcenplanung und effektive Nutzung insbesondere der Personalressourcen stellen dabei einen wesentlichen Anteil dar, der den Projekterfolg maßgeblich beeinflusst. Im Folgenden möchte ich kurz beschreiben, welche Integration der

Mit meinen Kunden kümmere ich mich viel um Planungsszenarien rund um den Bereich der Personaleinsatzplanung. Ein beliebtes Feld ist dort natürlich auch die Anbindung an das SAP Projektsystem. Dort wird die Ressourcenplanung durch den Transfer der Daten zwischen SAP PS und weiteren SAP Daten und Module optimiert.

Kontaktieren Sie mich gerne um Ihr individuelles Szenario zu besprechen.

Ressourcenplanung in der Praxis

Für diese Planung nutzen wir eine Fiori Applikation, die genau diese Aufbereitung der Daten und das Anreichern durch Prüfungen, Pflegemöglichkeiten und Darstellungen vereinfacht. Wir legen großen Wert auf die Bedienbarkeit und Einbeziehung aller Nutzergruppen. Die Grundfunktionalitäten und Detailaktivitäten sind sicherlich in SAP PS gut abgebildet. Das Bilden der Projektstrukturpläne, Planung der Einzelaktivitäten, Aufbau der Netzpläne und vieles mehr sind sicherlich in den Modulen aktuell gut abgebildet. Durch die häufig hohe Komplexität der Projekte ist es allerdings schwierig die Planung der Einzelnen Ressourcen sicherzustellen und dem User näher zu bringen.

Ich erarbeite mit meinen Kunden ganz spezifisch auf welcher Ebene die Planung der Ressourcen im Detail stattfindet. Nicht alle Projekte bedürfen eines Netzplans, für andere ist es unumgänglich, so ist die Detailebene sehr unterschiedlich. Daher um so wichtiger, dass in der alltäglichen Arbeit mit den Projekten nur die relevanten Informationen schnell und einfach abgerufen werden können.

Hierzu reduzieren wir massiv die Daten um für jede der betroffenen Usergruppen die richtigen Daten anzuzeigen. Hierzu kann jeder Unternehmensbereich individuell und sogar jeder User festlegen, welche Daten für ihn wirklich relevant sind um seiner Aufgabe gerecht zu werden. Auf diesem Weg schaffen wir es, dass für die Planung der Kapazitäten und Ressourcen die wichtigen Infos im Vordergrund stehen. Über die Planung des Personals und individuelle Prüfungen stellen wir dann sicher, dass die geplanten Ressourcen auch tatsächlich zur Verfügung stehen bzw. bei Krankheiten oder ähnlichem die Konsequenzen schnell transparent werden.

Integration in die SAP Landschaft

Als zentrale Komponente bildet das Projekt im SAP PS natürlich schon eine gute Schnittstelle. Durch die Personaleinsatzplanung greifen bei der Planung der Ressourcen dann HR – PS und weitere Module ineinander und bieten dem Anwender ein zentrales Bild. Die Reduktion der Komplexität durch die Kompakte Darstellung und proaktive Hinweise und Prüfungen seitens des Systems sorgen für eine deutlich bessere Nutzung der Ressourcen und damit schnellere und bessere Abwicklung der Projekte.

Lange Rede kurzer Sinn…

Wir haben mit unseren Kunden gute Erfahrung gemacht, dass sich eine Konsolidierte Sicht auf die aktuelle Ressourcenplanung lohnt. Die Daten aus HR, PS, PP und viele mehr für eine optimale Planung des Personals und weiterer Ressourcen zusammenzubringen, erhöht die Produktivität massiv und sorgt durch Komplexitätsreduktion für einen besser Überblick.

The post Ressourcenplanung im SAP Projektsystem (PS) mit SAP Fiori appeared first on ActivateHR.

Kiosk Systeme mit SAP Fiori werden vor allem interessant, wenn sie Mitarbeitergruppen im Unternehmen haben, die keinen Zugang zu eigenen Computern besitzen. Häufig ist das zum Beispiel in der Produktion der Fall. Unsere Lösung ist ideal für solche Konstellationen und benötigt noch dazu keinerlei Schnittstellen zu den SAP-Systemen.

Unsere Komplettlösung

Um Kunden eine komplette Kiosk-PC Lösung anbieten zu können, haben wir eine Partnerschaft mit DataFox geschlossen. DataFox ist Hersteller für Terminals und Kiosk Systeme und bietet hochwertige Endgeräte in allen Größen und Ausprägungen an.

Datafox EVO IPC 12

Die touchfähigen Endgeräte bieten ein einfaches Interface für den Mitarbeiter. Über die Sensorik können auch Karten, Chips, Fingerabdruck etc. verwendet werden, um eine einfache Authentifizierung herzustellen. Auch den Support für die Hardware können sie direkt über uns mit beauftragen, sodass sie eine Komplettlösung für ihr gesamtes System erhalten.

Zusammenspiel von Hardware und Software

Kiosk Systeme mit SAP Fiori ermöglichen das Nutzen von Self-Service Lösungen an den Kiosk PC’s. Die Systeme laufen mit Windows Installationen, sodass wir mühelos das Fiori-Launchpad aufrufen können. Der Mitarbeiter identifiziert sich dann mit Fingerabdruck, Chip oder via Passworteingabe. Die Fiori Anwendungen sind für Eingaben via Touch optimiert, wodurch sie sich einfach und intuitiv bedienen lassen. So bringen sie Abwesenheiten, Zeitbuchungen etc. schnell und einfach in Bereiche ohne eigene PC Arbeitsplätze.

Unser Auto-Logout Add-On sorgt außerdem dafür, dass nicht versehentlich ein Logout vergessen wird und ein anderer Mitarbeiter dadurch Einblick in die sensiblen Personaldaten des Kollegen erhält.

The post Kiosk Systeme mit SAP Fiori und DataFox appeared first on ActivateHR.

In diesem E-Book möchten wir Ihnen eine Einführung in ein essentielles Element der Vergütung im Bereich SAP SuccessFactors geben: SuccessFactors Compensation. 

Mit dem Modul Compensation können Vergütungspläne, Budgets und jährliche Bonuszahlungen abgebildet werden. Für die meisten Unternehmen lohnt sich das System bereits deshalb, weil die Gehälter oftmals die größten Ausgaben erfordern.

Unternehmen können ein leistungsorientiertes und faires Entlohnungssystem problemlos einrichten. Für Angestellte sind die Vergütungsregeln dabei stets transparent.

Mit dieser Lösung steht Unternehmen eine Anwendung zur Verfügung, mit der sie Angestellte fair entlohnen und die Unternehmensleistung steigern. Mitarbeiter und Manager profitieren von transparenten Vergütungen, da sie die Motivation und damit die Qualität der Arbeit steigern. Unternehmen verfügen zudem über eine bessere Kontrolle über das Personalbudget, denn Gehälter und Bonuszahlungen können so eingerichtet werden, dass sie sich unter anderem an den Geschäfts- und Finanzergebnissen orientiert.

The post SuccessFactors Compensation appeared first on ActivateHR.

Gehören Sie zu den Unternehmen, in denen Berechtigungen historisch gewachsen sind? Beschleicht Sie mit jedem Jahr mehr das Gefühl, dass Sie Ihr System nicht ausreichend abgesichert haben? Wenn es Ihnen so geht wird es Zeit für ein neues Berechtigungskonzept oder ein Redesign.

Ein SuccessFactors Berechtigungskonzept dient der Abbildung von einschlägigen Rechtsnormen (z.B. EU DSGVO) und unternehmensinternen Regelungen(z.B. Betriebsvereinbarungen) auf die technischen Schutzmöglichkeiten innerhalb eines SAP Systems. Berechtigungskonzepte sind der Schlüssel zum optimalen Schutz Ihres SuccessFactors Systems und Ihrer Daten, sowohl nach außen als auch nach innen. Ein durchdachtes Berechtigungskonzept bietet Ihnen die Möglichkeit, wenig Aufwand in die Administration des Systems zu investieren und gleichzeitig alle rechtlichen Auflagen zu erfüllen.

Aufteilung der Berechtigungen in SuccessFactors

Kontrolle des Konzeptes

Um unberechtigte Zugriffe zu vermeiden, ist das Berechtigungskonzept regelmäßig zu prüfen. Diese Überprüfung geschieht durch ein Soll/Ist-Vergleich. Der Soll-Stand entspricht dabei einem dokumentierten Stand, der Ist-Stand wird aktuell aus dem System bestimmt. Im Rahmen der Prüfung werden Abweichungen festgestellt und dokumentiert. Je nach Klassifizierung der Abweichung wird im Nachgang entweder das Soll-Konzept aktualisiert oder der Ist-Stand im System angeglichen.

Bei Bedarf Durchführung eines Berechtigungsredesigns

Die Durchführung eines Berechtigungsdesign erfordert eine gute Planung sowie ein strukturiertes Vorgehen. In der Praxis hat sich ein Vorgehen in fünf Schritten zur Einführung eines Berechtigungskonzepts bewährt.

1. Analyse und Erarbeitung des Berechtigungskonzepts

Im ersten Schritt muss das eigentliche Konzept erstellt werden. Ein gutes Berechtigungskonzept ist verständlich geschrieben und beantwortet alle Fragen nach den Berechtigungen umfassend. Es trennt fachliche Funktionen von Personen.

2. Entwurf von Funktionsrollen

In einem zweiten Schritt werden die Funktionsrollen entworfen. Business- oder auch Arbeitsplatzrollen ermöglichen es, einer Berechtigung einen aussagekräftigen Namen zu geben. Zum Erstellen von Funktionsrollen sind unterschiedliche Schritte notwendig. Angefangen bei der Einteilung in Gruppen von Mitarbeitern einer Abteilung bis hin zur Auswertung der Gruppen bis für jede einzelne eine Liste von Transaktionen vorliegt.

3. Fachbereichs-Workshops und Umsetzung in Rollen

Im dritten Schritt werden die Listen aus dem vorherigen Schritt dem Fachbereich vorgelegt. So kann eine Feinabstimmung erfolgen und können eventuell auftretende Funktionstrennungskonflikte überprüft werden. Die erstellten Listen werden dann in Rollen übertragen. Anschließend wird ein Basis-Funktionstest durchgeführt.

4. Simulation und Anpassung der neuen Rollen

Im nächsten Schritt werden die Rollen, die den Basis-Funktionstest bestanden haben, dem Fachbereich für Simulation übermittelt. Die Ergebnisse der Simulation werden dann von den Berechtigungsentwicklern ausgelesen und für die Weiterentwicklung der neuen Rollen verwendet.

5. Abgesicherter Go-Live

Nachdem alle Berechtigungen die Abnahme durch den Fachbereich durchlaufen haben, kann im letzten Schritt der Go-Live vorbereitet werden. Dafür wird als zusätzliches Sicherheitsnetz für definierte Anwender ein abgesicherter Go-Live konfiguriert. So wird vermieden, dass wichtige Geschäftsprozesse ausfallen, weil Berechtigungen falsch vergeben wurden und der Service Desk diese nicht schnell zurückändern kann. Nach diesen fünf Schritten liegt ein überarbeitetes, revisionssicheres und schriftliches Berechtigungskonzept vor, das ohne nennenswerten Ausfall in Betrieb genommen werden kann.

Als guten Zeitpunkt für eine Überarbeitung der Berechtigungen haben sich die >>heißen<< Zeiten, wie zum Beispiel ein anstehender Jahreswechsel, als besonders geeignet herausgestellt. Ein Redesign muss ebenso nicht in einem Projekt überarbeitet werden, sondern kann auch in einzelnen Teilschritten durchgeführt werden.

The post SuccessFactors Berechtigungskonzept / Redesign appeared first on ActivateHR.

Kennen Sie das? Sie entwickeln eine eigene SAPUI5/Fiori App und im Backend tritt ein Fehler auf. Falls Sie diesen nicht behandeln und propagieren, erhalten Sie in Ihrer Anwendung oft dieses Bild:

Wenn Sie wissen möchten, wie Sie auf die unterschiedlichsten Dinge im Backend reagieren können, schauen Sie sich diesen Beitrag an. Hier erkläre ich Ihnen, welche Möglichkeiten Sie haben, das ErrorHandling im Backend anzugehen und Fehler als hilfreiche Meldung ans Frontend zu propagieren.

Vorbereitung des Frontends

Zunächst benötigen wir frondendseitig die Möglichkeit, mit Fehlermeldungen umzugehen, die aus dem Backend kommen. Dafür wird in einigen Templates die ErrorHandler.js gleich mitgeliefert. Sollten Sie diese in Ihrer aktuellen Anwendung nicht eingebunden haben, können Sie diese einfach aus diesem Beitrag kopieren und einfügen. Achten Sie dabei dann unbedingt darauf, die ID Ihrer App an der entsprechenden Stelle zu ersetzen.

E-Book: Entwicklung Ihrer persönlichen Fiori App

Lernen Sie in diesem E-Book, wie Sie Ihre eigene persönliche Fiori App entwickeln.

ErrorHandler.js

sap.ui.define([
"sap/ui/base/Object",
"sap/m/MessageBox"
], function (UI5Object, MessageBox) {
"use strict";

return UI5Object.extend(„ID_IHRER_APP.controller.ErrorHandler“, {

/**
* Handles application errors by automatically attaching to the model events and displaying errors when needed.
* @class
* @param {sap.ui.core.UIComponent} oComponent reference to the app’s component
* @public
* @alias sap.Test123.controller.ErrorHandler
*/
constructor : function (oComponent) {
this._oResourceBundle = oComponent.getModel(„i18n“).getResourceBundle();
this._oComponent = oComponent;
this._oModel = oComponent.getModel();
this._bMessageOpen = false;
this._sErrorText = this._oResourceBundle.getText(„errorText“);

this._oModel.attachMetadataFailed(function (oEvent) {
var oParams = oEvent.getParameters();
this._showServiceError(oParams.response);
}, this);

this._oModel.attachRequestFailed(function (oEvent) {
var oParams = oEvent.getParameters();
// An entity that was not found in the service is also throwing a 404 error in oData.
// We already cover this case with a notFound target so we skip it here.
// A request that cannot be sent to the server is a technical error that we have to handle though
if (oParams.response.statusCode !== „404“ || (oParams.response.statusCode === 404 && oParams.response.responseText.indexOf(„Cannot POST“) === 0)) {
this._showServiceError(oParams.response);
}
}, this);
},

/**
* Shows a {@link sap.m.MessageBox} when a service call has failed.
* Only the first error message will be display.
* @param {string} sDetails a technical error to be displayed on request
* @private
*/
_showServiceError : function (sDetails) {
if (this._bMessageOpen) {
return;
}
this._sErrorText = JSON.parse(sDetails.responseText).error.message.value;
this._bMessageOpen = true;
MessageBox.error(
this._sErrorText,
{
id : „serviceErrorMessageBox“,
//details : sDetails,
styleClass : this._oComponent.getContentDensityClass(),
actions : [MessageBox.Action.CLOSE],
onClose : function () {
this._bMessageOpen = false;
}.bind(this)
}
);
}

});

}
);

Ein weiterer wichtiger Schritt ist, den ErrorHandler in der Component.js zu registrieren (auch hier achten Sie bitte auf die ID Ihrer Anwendung):

Component.js


sap.ui.define([
"sap/ui/core/UIComponent",
"sap/ui/Device",
"ID_IHRER_APP/model/models",
"ID_IHRER_APP/controller/ListSelector",
"ID_IHRER_APP/controller/ErrorHandler"
], function (UIComponent, Device, models, ListSelector, ErrorHandler) {
"use strict";

return UIComponent.extend(„ID_IHRER_APP.Component“, {

metadata : {
manifest : „json“
},

/**
* The component is initialized by UI5 automatically during the startup of the app and calls the init method once.
* In this method, the FLP and device models are set and the router is initialized.
* @public
* @override
*/
init : function () {
this.oListSelector = new ListSelector();
this._oErrorHandler = new ErrorHandler(this);

// set the device model
this.setModel(models.createDeviceModel(), „device“);
// set the FLP model
this.setModel(models.createFLPModel(), „FLP“);

// call the base component’s init function and create the App view
UIComponent.prototype.init.apply(this, arguments);

// create the views based on the url/hash
this.getRouter().initialize();
},

/**
* The component is destroyed by UI5 automatically.
* In this method, the ListSelector and ErrorHandler are destroyed.
* @public
* @override
*/
destroy : function () {
this.oListSelector.destroy();
this._oErrorHandler.destroy();
// call the base component’s destroy function
UIComponent.prototype.destroy.apply(this, arguments);
},

/**
* This method can be called to determine whether the sapUiSizeCompact or sapUiSizeCozy
* design mode class should be set, which influences the size appearance of some controls.
* @public
* @return {string} css class, either ’sapUiSizeCompact‘ or ’sapUiSizeCozy‘ – or an empty string if no css class should be set
*/
getContentDensityClass : function() {
if (this._sContentDensityClass === undefined) {
// check whether FLP has already set the content density class; do nothing in this case
if (jQuery(document.body).hasClass(„sapUiSizeCozy“) || jQuery(document.body).hasClass(„sapUiSizeCompact“)) {
this._sContentDensityClass = „“;
} else if (!Device.support.touch) { // apply „compact“ mode if touch is not supported
this._sContentDensityClass = „sapUiSizeCompact“;
} else {
// „cozy“ in case of touch support; default for most sap.m controls, but needed for desktop-first controls like sap.ui.table.Table
this._sContentDensityClass = „sapUiSizeCozy“;
}
}
return this._sContentDensityClass;
}

});

}
);

Mehr müssen wir nun in der Anwendung erst einmal nicht tun. Wir können uns nun also dem Backend widmen.

Vorbereitung des Backends

Zunächst empfiehlt es sich eine Ausnahmeklasse anzulegen. In dieser können wir dann verschiedene Attribute, Interfaces, Texte und Methoden definieren bzw. angeben.

Als Attribute können wir hier beispielsweise unsere Ausnahmetexte angeben.

Wichtig sind die abgebildeten Interfaces. Diese benötigen wir innerhalb der Ausnahmeklasse.

Zu den Texten, die wir ebenfalls bereits als Attribute gepflegt haben, können wir im Bereich „Texte“ jeweils einen sprechenden Langtext definieren.

Neben den Methoden aus den Interfaces und dem Constructor habe ich hier noch eine weitere Methode „Raise“ angelegt. In dieser wird die entsprechende Exception geworfen. Zwingend benötigt ist diese jedoch nicht, bietet sich allerdings im Sinne der Kapselung an.

Wir starten unsere Reise der Fehlerbehandlung in diesem Szenario in der Methode „Header_Entityset_Get_Entity“ (also einer GET-Methode eines OData-Services). Hier haben wir die folgenden Ausnahmen hinzugefügt:

Die eigentliche Behandlung der Fehlermeldungen kann über die sogenannten Try-Catch-Blöcke stattfinden. Diese befinden sich in unserem Fall direkt innerhalb der genannten Methode. Wichtig: In jeder Methode, die eine Exception werfen kann, muss auch die Ausnahme angegeben sein, wenn diese propagiert werden soll. Gleiches gilt auch für „weiterreichende“ Methoden. Durch das Raise Exception in der „untersten“ Methode und die hinzugefügte Ausnahme in allen Methoden wird die Exception weitergereicht, bis sie behandelt wird. Beispielhaft dargestellt wird dies in den folgenden Abbildungen:

Hier wird eine Methode innerhalb des Try-Blocks aufgerufen, die unter Umständen eine Exception raised. Sollte dies der Fall sein, wird der Catch-Block abgehandelt. Innerhalb dieses Blocks wird die Methode „Handle_Status_Error“ aufgerufen. Diese sieht wie folgt aus:

Wir sehen, dass in dieser Methode die Ausnahme „/IWBEP/CX_MGW_BUSI_EXCEPTION“ angegeben wurde.
Alternativ zur Behandlung in einer weiteren Methode, können Sie natürlich die Fehlerbehandlung direkt im Catch-Block vornehmen:

In diesem Fall wird der Funktionsbaustein ADD_MESSAGE_TEXT_ONLY genutzt, um den Fehlertext zu ermitteln. Wir sollten beachten, dass Code, der sich nach dem Try-Catch-Block befindet ausgeführt wird, solange hier keine weitere Exception geraised wird. Dies ist in vielen Fällen sinnvoll, manchmal aber auch hinderlich.

Schon am Anfang das Ende im Sinn haben

Sie sehen also, dass vom Werfen einer Ausnahme bis zur Anzeige einer sprechenden Fehlermeldung im Frontend einiges zu tun ist. Ich empfehle Ihnen, die Grundsteine für das ErrorHandling möglichst früh zu legen. Dann können Sie im weiteren Verlauf Ihrer Entwicklung immer wieder darauf zurückgreifen. Sollte Ihnen noch etwas unklar geblieben sein, zögern Sie bitte nicht, mich zu kontaktieren.

The post Ui ui ui ui ui – ErrorHandling in SAPUI5/Fiori Apps appeared first on ActivateHR.

Anpassungen im SAP HCM durch Eigenentwicklung und Customizing sind das taglich Brot eines jeden Entwicklers und Berater. SAP bietet im Standard ein umfangreiches Tool welches nahezu beliebig erweitert werden kann. Mit SuccessFactors sieht die Welt etwas anders aus. Erfahren Sie im Blog was Sie noch selbst in der Hand haben und wofür Sie Unterstützung benötigen.

Entwicklung im SAP HCM

Ihr Standard-SAP-System kann mehr! Wir helfen Ihnen durch individuelle Anpassungen Ihrer Software dabei, dass Ihr SAP-System die Kernkompetenzen Ihres Unternehmens optimal unterstützt. So oder so ähnlich lautet die Divise jedes Beratungshauses. Das klassische SAP On-Premise kennt kein nein im Bereich Entwicklung.

Entwicklung in SuccessFactors

The post SuccessFactors. Mehr Eigenständigkeit oder mehr Abhängigkeiten? appeared first on ActivateHR.

Vielleicht sind Sie auf der Suche nach einer Partner Lösung schon mal über den Begriff SAP App Center gestoßen, doch was ist das eigentlich genau? Und welche Möglichkeiten bietet ihnen das App Center? Hier finden sie die Antwort!

Was ist das SAP App Center?

Das SAP App Center ist ein digitaler Marktplatz der von der SAP SE bereitgestellt wird. Hier finden Sie mehrere hunderte Partnerlösungen für ihr SAP System. Wie vom AppStore der Smartphones bekannt sind die Lösungen in verschiedene Kategorien eingeteilt. Beispielsweise können sie nach Branchen, Lösungstypen und Technologien filtern. Alternativ können sie auch mittels dem Suchfeld an die gewünschte Lösung gelangen. Wie auf dem Smartphone werden die Lösungen dann genauer auf einer Detailseite vorgestellt. Hier können Sie unter anderem die Beschreibung, Fotos, Videos, Fragen anderer Nutzer und Rezensionen zur Lösung und dem Entwickler abrufen.

Einmal gefunden können sie die Lösung dann auch direkt im App Center testen, kaufen und verwalten. Somit wird das App Center zu ihrer zentralen Stelle zur Kommunikation mit IT-Anbietern, der Verwaltung von Rechnungen und Lizenzen. So können sie einfach und unkompliziert den Funktionsumfang ihres SAP Systems erweitern.

Beispielhafte Detailseite einer Partnerlösung im App Center

Das SAP App Center bietet darüber hinaus einen zweistufigen Einkaufsprozess. Zunächst können Mitarbeiter in dem mehr als 1000 Apps umfassenden Katalog nach einer passenden Lösung suchen. Ist diese gefunden kann direkt aus dem App Center der Kaufantrag an das Beschaffungswesen gesendet werden. Die Mitarbeiter des Beschaffungswesen können die Drittanbieterlösungen nun direkt im App Center verwalten. Darüberhinaus können Administratoren die Lösungen direkt an Nutzer verteilen und Lizenzfristen verlängern.

E-Book: Entwicklung Ihrer persönlichen Fiori App

Lernen Sie in diesem E-Book, wie Sie Ihre eigene persönliche Fiori App entwickeln.

Für welche Plattformen finde ich Lösungen im SAP App Center?

Im SAP App Center werden Lösungen für das gesamte Portfolio der SAP bereitgestellt. Inklusive SuccessFactors, S/4HANA,  Hybris, Analytics und Ariba. Dabei ist es egal ob das Zielsystem ein reines Cloud System ist oder On Premise gehalten wird.

Wie komme ich zum SAP App Center?

Das SAP App Center ist unter der Adresse sapappcenter.com zu erreichen.

The post Der Appstore von SAP: Das SAP App Center appeared first on ActivateHR.

Das SCP4HR (SCP = SAP Cloud Plattform) Event ist eine Veranstaltung der SAP. Kunden erhalten dort einen Einblick in die neusten Entwicklungen rund um die SAP Cloud Plattform und haben die Möglichkeit spannende Projekte zu präsentieren. Das Event findet halbjährlich statt und diesmal waren wir mit dabei.

Wieso ist das SCP4HR Event für Sie wertvoll?

Aufmerksam geworden bin ich auf das für SAP Verhältnisse eher kleine Event durch die Organisatoren. E-Mail Marketing funktioniert scheinbar noch immer ;). Von der Idee der Veranstaltung war ich schnell überzeugt. Dies hat mehrere Gründe:

1. Das Thema SAP Cloud Plattform wird immer stärker nachgefragt. Bei uns meistens zur Umsetzung von Self-Services mithilfe des Portal-Services, aber auch zum Beispiel für Erweiterungsszenarien von SuccessFactors.
2. Es waren viele Großkunden angemeldet, die spannende Eigenentwicklungen und Szenarien vorstellten, sodass ich viel Input für meine Kunden erhalten habe.
3. Der Gedanke des Events ist „von Kunden für Kunden“. Ein Ansatz den wir auch mit unseren eigenen Events verfolgen und der eine offene und ehrliche Atmosphäre schafft. Daraus resultiert ein wertvoller Erfahrungsaustausch von dem wir als Partner sehr profitieren.
4. Wir konnten selbst eine umfangreiche Eigenentwicklung im Cloud-Umfeld mitbringen und gemeinsam mit unserem Kunden vorstellen.

Diese Punkte des SCP4HR Event sind für mich ausschlaggebend um zu sagen: „Das lohnt sich für jeden Kunden“. Selbst wenn die Cloud (noch) kein Thema für Sie ist kann dort fachlicher Input mitgenommen werden.

Welche Strategie verfolgt die SAP im Cloud Umfeld?

Die SCP wird derzeit in zwei Varianten angeboten. Erstens das Neo-Enviroment, welches die ursprünglich von der SAP ins Leben gerufene Cloud ist. Die Neo-Umgebung basiert auf von der SAP entwickelten Strukturen und Techniken und wurde ab ~2008 angeboten. Zweitens die Cloud-Foundry Umgebung, welche auf offene Cloud Standards setzt und seit ~2015 angeboten wird.

Strategisch werden die Investments und weitere Entwicklungen ausschließlich in die Cloud-Foundry Umgebung fließen. Die Vorteile sind eine einfachere Integration von Services anderer Cloud-Anbieter wie Google, Amazon usw. und die Nutzung von offeneren Standards.

Was mache ich jetzt mit meiner SCP Neo?

Die Neo-Umgebung ist nicht mehr zukunftsfähig. Wenn Sie also mit dem jetzigen Stand zufrieden sind, kann die Umgebung zwar weiterhin genutzt werden, Innovation werden Sie dort aber nicht mehr erfahren. Die SAP hat außerdem Tools zur einfachen Migration von Neo in die Cloud-Foundry angekündigt. Diese Tools befinden sich aber noch in der Entwicklung.

Positionierung der SAP auf dem Cloud-Markt

Die SAP positioniert sich dort, wo Sie sich am wohlsten fühlt – im Business Kontext. Mit Services und Bezahlmodellen für die Geschäftswelt möchte sich die SAP von anderen Anbietern abheben. Es soll möglichst einfach werden Erweiterungen für SuccessFactors, S/4 oder andere SAP Produkte zu erstellen. Die Servicepalette umfasst heute bereits 60 Services. Die Abbildung zeigt die Extension Factory der SAP, also das Modell mit dem Erweiterungen in Zukunft einfach möglich sein sollen.

SAP Cloud Extension Factory

Eine klare Positionierung bedeutet auch, dass unpassende Angebote weichen müssen. Services wie PostgreSQL oder MongoDB, die sich nicht direkt an das Business wenden und bereits von anderen Cloud-Anbietern zahlreich angeboten werden, sollen ab 2020 nicht länger verfügbar sein (aktuelle Infos).

Fazit

Mir hat das Event sehr gut gefallen und ich würde es jedem Kunden, der sich mit Entwicklungen und Erweiterungen im SAP Cloud (besonders auch SuccessFactors/SAPUI5) Umfeld beschäftigt, empfehlen. Gerade weil es zum Beispiel verglichen mit der SuccessConnect keine Verkaufsveranstaltung ist und Einblicke in Projekte anderer Kunden bietet. Außerdem ist es ein sehr spannendes und sich schnell veränderndes Thema, indem es gilt sich auf aktuellem Stand zu halten.

Wenn Sie Fragen oder Anmerkungen zur Entwicklung in der Cloud haben, kommen Sie gerne auf mich zu oder entdecken Sie hier unsere Angebote im Bereich SuccessFactors oder Fiori-Umfeld.

The post Neuigkeiten vom SCP4HR Event der SAP appeared first on ActivateHR.

Nachdem der OData Service in der Transaktion SEGW angelegt und im Gateway Client ausführlich getestet wurde, verlassen Sie endgültig die vertraute SAP Backend Umgebung. Jetzt kommt es darauf an, den Service auch entsprechend aus dem Frontend nutzen zu können.

Hierfür zeige ich Ihnen in diesem Beitrag die wichtigsten Varianten für die Verwendung der Services direkt aus der XML View und aus dem JavaScript Controller heraus. Als Szenario verwende ich hierfür eine UI5 SplittApp, welche den im vorigen Beitrag implementierten Service nutzt, um Personendaten zu übertragen. Die SplittApp hat dafür auf der linken Seite eine Masteransicht, auf der eine Übersicht aller zur Verfügung stehenden Personen zu sehen sein soll. Auf der rechten Seite können neue Entitäten angelegt und ans Backend übertragen werden, oder aber Details der vorhandenen Personen eingesehen werden. Auf die Details der SplittApp gehe ich in diesem Beitrag nicht ein, heute soll der Fokus auf der Verwendung von OData Standard Methoden liegen.

Inhalte

• Einrichten des OData Service als Datenquelle für die App
• DataBinding in der XML View
• Ansteuern der OData Standard Methoden
• Lesen und Ändern der Model Attribute
• Templating im Javascript

Einrichten des OData Service als Datenquelle für die App

Um einen OData Service aus der UI5 App verwenden zu können, muss dieser zuerst als Datenquelle für die Anwendung angelegt werden. Eine Möglichkeit dafür ist, in die Datei „manifest.json“ zu gehen. Dort findet sich unter dem Reiter „Data Sources“ die Möglichkeit, einen neuen Odata Service zu hinterlegen. Hier können Sie einfach nach dem Gateway System suchen, auf dem Sie den Service registriert haben und anschließend nur noch bestätigen. Der Service sollte nun als Datenquelle eingerichtet und als Default Model hinterlegt sein.

Zur Überprüfung können Sie im Reiter „Models“ schauen, ob das Default Model befüllt ist. Damit ich im weiteren Verlauf alle Operationen zeigen kann, habe ich die Einstellungen des Default Models wie folgt eingerichtet:

DataBinding in der XML View

In der Detail View meiner SplittApp habe ich mir eine Struktur mit einem Form aufgebaut, damit die Einträge ordentlich untereinander angeordnet sind. Später werde ich eine Entität meines OData Services an die View binden. Hierfür richte ich im XML bereits das entsprechende Data Binding ein, um die Attribute anzeigen zu können:

In dieser View binde ich Attribute von 2 verschiedenen Models: Zum einen meine OData Entität, welche ich später an die View binden werde. Diese steuere ich einfach mit „{Attributname}“ an. In diesem Fall zeige ich die Attribute jeweils im Form Field als Text an. Die Namen der Attribute müssen natürlich 1:1 mit den Namen übereinstimmen, welche im Entitätstypen in der Transaktion SEGW auch zu sehen sind. Bitte beachten Sie hierbei auch Groß- und Kleinschreibung.

Das zweite Model ist  i18n. Hier sind all meine freien Texte gespeichert, um Mehrsprachigkeit und Übersetzungen zu vereinfachen. Dieses steuere ich mit „{i18n>Attributname}“ an. In meinem Beispiel habe ich die Labels, also die Bezeichnungen meiner Felder alle damit umgesetzt.

Ansteuern der ODATA Standard Methoden

Bislang ist das Data Binding zwar in der Detail View vorbereitet, allerdings wird der OData Service noch nicht aufgerufen und dementsprechend gibt es auch keine Daten zum Anzeigen. Dafür zeige ich Ihnen im Folgenden, wie Sie die 5 OData Standart Methoden GET_ENTITYSET, GET_ENTITY, UPDATE_ENTITY, DELETE_ENTITY und CREATE_ENTITY aus der UI5 Anwendung aufrufen können.

GET_ENTITYSET

Der Aufruf von GET_ENTITYSET kann ganz einfach aus der XML View getätigt werden. Dafür erstelle ich in der Master View eine Liste, in welcher die Ergebnisse des Aufrufs angezeigt werden sollen. In der Liste wird über items=“{/PersonSet}“ automatisch eine GET_ENTITYSET Anfrage ans Backend gesendet. Die Ergebnisse werden dann in der Liste aufgeführt. Damit feststeht, welche Attribute der Ergebnismenge eigentlich angezeigt werden sollen, können Sie wieder DataBinding verwenden. In diesem ObjectAttribute ist das DataBinding noch etwas aufwändiger, da ich das Datum anzeigen möchte und hierfür neben dem reinen Pfad auch noch Optionen zur Formatierung übergebe:

Ich habe also pro Eintrag der Ergebnismenge einen Eintrag in meiner Master Liste, zu dem mir der Name als Titel und das Geburtsdatum als Zusatzinformation angezeigt werden:

GET_ENTITY

Aktuell werden mir alle Ergebnisse vom GET_ENTITYSET in der Master Liste angezeigt. Nun möchte ich, dass ein GET_ENTITY Aufruf gestartet wird, sobald ich einen der Einträge in der Liste anklicke und das Ergebnis rechts in der Detail Ansicht zu sehen ist. Das notwendige Data Binding in der Detail View ist bereits vorbereitet. Um den Backend Aufruf zu starten, starte ich im Detail Controller den Aufruf „bindElement()“ auf die entsprechende View. Hierfür übergebe ich in der Navigation den angeklickten Pfad. Hierfür gibt es verschiedene Möglichkeiten. In meinem Fall ist alles schon vorbereitet, sodass „(‚Pernr‘)“ in meiner Variable sPath steht. Diese füge ich nur noch an /PersonSet an, schon habe ich den aus dem ersten Teil bekannten Aufruf von GET_ENTITY:

Klicke ich beispielsweise links auf eine Person mit der Personalnummer 12345678, so liefert mir der obige Ausdruck oEvent.getParameter(„arguments“).path bereits „(‚12345678‘)“ zurück. Der komplette Pfad für den Backend Aufruf ist in dem Falle dann /PersonSet(‚12345678‘).

Das Ergebnis des Aufrufs wird als Model an die View gebunden. Dadurch wird das Data Binding der Detail View aktiv und zeigt uns die entsprechenden Attribute an. Wenn alles funktioniert, sieht das Ergebnis wie folgt aus:

Durch klicken auf einen Eintrag in der Master Liste wird im Detail Controller der Aufruf „bindElement()“ gestartet. Dieser ruft die Methode GET_ENTITY des OData Services auf. Das Ergebnis des Aufrufes wird an der Detail View hinterlegt und durch DataBinding werden die entsprechenden Attribute auf der Oberfläche sichtbar.

UPDATE_ENTITY

Mit GET_ENTITYSET und GET_ENTITY haben Sie bereits die rein lesenden Operationen kennengelernt. UPDATE_ENTITY ist nun der nächsten Schritt: Es werden auch Daten ins Backend geschrieben. Für den Test im Gatway Client haben Sie im vorigen Beitrag eine GET_ENTITY Anfrage gestartet, das Ergebnis „als Anfrage verwendet“ und vor dem PUT Request die Daten entsprechend abgeändert. Nach dem selben Schema funktioniert es auch aus dem Frontend:Die Details zu einer Person werden in die Detail View geladen, die Werte dann entsprechend angepasst und das Ergebnis geht dann zurück ans Backend.

Hierfür habe ich alle Text Controls der Detail View durch Input oder DatePicker ersetzt. Zusätzlich habe ich einen Button im Footer erstellt, um das Update starten zu können:

In der Methode „onUpdateEntityButtonPressed“ in Detail Controller sorge ich nun dafür, dass ein UPDATE_ENTITY Aufruf ans Backend gestartet wird. Hierfür hole ich mir den Eintrag, welcher an meine Detail View gebunden ist und rufe einfach nur die Methode „submitChanges()“ auf. Diese geht dann direkt ans Backend und startet den UPDATE_ENTITY Befehl:

In einem etwas größeren Projekt würden Sie bei dem Aufruf natürlich auch noch Fehler und Erfolgsmeldungen an den Benutzer ausgeben.

DELETE_ENTITY

Zum Löschen habe ich einen weiteren Button in den Footer aufgenommen. Dieser ruft die Methode onDeleteEntityButtonPressed() im DetailController auf. Im Gateway Client wird dafür die HTTP Methode auf „Delete“ gestellt und der Pfad /PersonSet(‚Pernr‘) verwendet. Auch hier ist das Vorgehen in der UI5 App analog:

Über den Binding Context hole ich mir den Pfad der aktuell an der Detail View gebunden Entität. Dieser ist analog zum oben genannten Pfad aus dem Gateway Client. Entsprechend wird „remove“ auf das entsprechende Model aufgerufen und der Pfad übergeben. Dadurch wird ein DELETE Request mit dem Pfad der Entität ans Backend gesendet und durch die Implementierung von DELETE_ENTITY ausgeführt:

CREATE_ENTITY

Für die Erstellung eines neuen Eintrages, habe ich mir eine weitere View erstellt. Sobald ich durch Routing zu dieser View navigiere, erstelle ich mir einen neuen Eintrag mit der createEntry(„/PersonSet“) Methode und binde den entstandenen BindingContext an meine View. Dadurch steht mir sozusagen ein „leerer“ Eintrag zur Verfügung, der an der View gebunden ist und über DataBinding befüllt werden kann. Sobald ich auf den entsprechenden Button klicke, lade ich mir die Daten über den BindingContext und sende sie dann mit „create“ auf das OData Model ab. Dabei gebe ich den Pfad meines OData Service und die entsprechenden Daten mit. Hierdurch wird im Backend die CREATE_ENTRY Methode aufgerufen. Falls ihr dabei auf einen Fehler lauft, die CREATE_ENTRY Methode aber im Gateway-Client erfolgreich testen könnt, empfehle ich die Metadaten vom Model Eintrag vor dem Absenden zu löschen. Das kann je nach Version erforderlich sein.

Lesen und Ändern der Model Attribute

Wenn Sie bis hierhin durchgehalten haben, können Sie bereits alle 5 OData Standard Methoden aus dem UI5 Frontend aufrufen und die Ergebnisse über DataBinding entsprechend an der Oberfläche anzeigen. Jetzt wird es Zeit, die Daten über JavaScript zu manipulieren. Dies kann besonders hilfreich sein, wenn Daten falsch ans Backend übertragen werden, oder Sie noch zusätzliche Informationen mitgeben möchten.

Über den Binding Context haben Sie die Möglichkeit, alle Attribute meines gebundenen Eintrags auszulesen und beliebig abzuändern. Zum Auslesen wird die Methode „getProperty()“ auf das Model angewandt, zum Ändern die Methode „setProperty()“. Für dieses Beispiel habe ich die UpdateEntity Methode von eben im Javascript etwas angepasst. Vor dem Update lese ich den vollständigen Namen der Person aus, verändere ihn und setze den neuen Namen. So steht ab jetzt nach jedem Update „(modified)“ hinter dem eigentlichen Namen:

Ändere ich jetzt über das Update einen bestehenden Eintrag, steht automatisch „(modified“) hinter dem geänderten Datensatz:

Templating im Javascript

Zuletzt möchte ich Ihnen noch ein einfaches Beispiel von Templating vorstellen. Hierfür habe ich die Create View von vorhin wieder aufgegriffen und um ein weiteres Form Element erweitert:

Beim Laden der Seite sehe ich nur den Button und direkt daneben ein leeres Dropdown-Menü. Dieses soll mit dem entsprechenden Button gefüllt werden. Im CreateController implementiere ich mir also die onLoadPersonButtonClicked Methode dafür:

Im ersten Schritt hole ich mir das leere Select Control, welches ich mit Werten befüllen möchte über die vergebene ID. Anschließend lege ich mir das Template zum Anzeigen der Ergebnisse an. Dies funktioniert analog zum ObjectAttribute, welches in der Master View als Template hinterlegt ist. Im Controller wird festgelegt, welche Eigenschaft der Schlüssel für die angezeigten Elemente sein soll und welches Attribut als Text im Menü dienen soll. Die Personalnummer ist hier der Schlüssel und der vollständige Name wird dem Benutzer angezeigt. Mit dem Aufruf „bindItems()“ auf das entsprechende Select Control wird die GET_ENTITYSET Methode des OData Service angesteuert, genauso wie auch im XML der Master View zu sehen war. Zusätzlich wird das Template zum Anzeigen der Ergebnisse mitgegeben. Folgendes Ergebnis erscheint nach Klicken des Buttons:

Hat es Ihnen gefallen?

In diesem Beitrag habe ich Ihnen vorgestellt, wie Sie die Standard Methoden Ihres OData Service aus einer UI5 Anwendung aufrufen können, wie Sie die Daten an der Oberfläche anzeigen können und wie sie mit JavaScript Änderungen vornehmen können. Wenn es Ihnen gefallen hat, schauen Sie doch gerne bei der ODATA-Grundlagenreihe vorbei. Dort gibt es weitere Themen praktisch erklärt!

SAPUI5: ODATA Grundlagen in der praktischen Verwendung

The post ODATA Grundlagen: Services aus der UI5 App verwenden appeared first on ActivateHR.

In LMS können Daten aller Art manuell eingepflegt und bearbeitet werden. Da dies jedoch teilweise sehr aufwendig ist können Konnektoren eine Abhilfe schaffen. Mit einen Konnektor können Schnittstellen aus dem LMS, Textdateien mit Daten von einem Server abgerufen und die Datensätze eingespielt werden.

In unserem Whitepaper informieren wir Sie über Konnektoren im SuccessFactors Learning.

Wir berichten erstens, über die Funktion eines Konnektors, zweitens zeigen wir auf welche Konnektoren es gibt und drittens zeigen wir Ihnen schrittweise, wie Sie einen User Connector für SuccessFactors einrichten und was Sie bei der Einrichtung alles beachten müssen.

The post How-to: Konnektoren im SuccessFactors LMS konfigurieren appeared first on ActivateHR.

Der Kauf und die Pflege von SAP Lizenzen kann eine sehr komplizierte Tätigkeit werden. Die SAP gliedert regelmäßig Ihre Lizenzpakete um und gleichzeitig verändern sich die Anforderung an die SAP Software. Beides führt dazu, dass Einsparungen meist nicht wahrgenommen werden und einmal erworbene Pakete erst einmal hingenommen werden. Bei den Vermessungen kommt meistens ans Licht, dass Abweichungen aufgetreten sind . Wir unterstützen Sie beim Erwerb und der Betreuung Ihrer SAP Cloud Lizenzpakete.

SAP Lizenzen kaufen – Ihre Möglichkeiten

Gerade mit den neuen Lizenzmodellen von SAP zum Cloud Business verlieren viele Kunden schnell den Überblick im Lizenzdschungel. Wir unterstützen Sie dabei das für Sie optimale Lizenzmodell zu finden.

Wir geben Ihnen eine aktuelle Übersicht über Ihre SAP Lizenzen sowie SAP Lizenzkosten. Ebenso können wir mit Ihnen die aktuelle SAP Preisliste besprechen und Sie bei der Wahl des besten Lizenzmodells für Ihr Unternehmen unterstützen.

Gerne zeigen wir Ihnen Wege, Optionen und Best Practices einer Softwaremodernisierung im Zuge der Digitalisierung und der wachsenden Verfügbarkeit von Softwarealternativen in der Cloud auf.

Sollten wir das Management Ihrer Lizenzen übernehmen versprechen wir Ihnen eine stetige Kontrolle Ihres Lizenzbestandes. Auch die Optimierung Ihres aktuellen Lizenzportfolios können wir Ihnen transparent zur Verfügung stellen.

SAP Cloud Lizenzen

SAP bietet Ihren Kunden heute eine Vielzahl von IT-Services aus der Cloud an. Das Angebot reicht vom sogenannten Infrastructure-as-a-Service (IaaS), über Platform-as-a-Service (PaaS) und endet beim sogenannten Software-as-a-Service (SaaS). Je nach Ihren Anforderungen kann die eine oder andere Lösung für Ihr Unternehmen mehr oder weniger Sinn machen. Häufig ist für viele Kunden auch eine Kombination der einzelnen Produkte sehr interessant. Beispielsweise können Sie mithilfe von SuccessFactors ihre HR Prozesse digitalisieren und über die SAP Cloud Intergration das HR System mit weiteren Systemen aus Ihrer IT-Infrastruktur koppeln.

Vorgehen

In einem ersten Gespräch verschaffen wir uns einen Überblick über Ihre aktuelle Lizenzsituation. Anschließend nehmen wir mit Ihnen den Entwicklungsplan der Lizenzen auf. Abschließend erstellen wir einen möglichen Transitionsplan fest.

Gerne stellen wir den Kontakt mit SAP für sie her und unterstützen Sie bei den einzelnen Lizenzmodellen um Ihnen eine gewisse Transparenz zu bieten.

Auch nach dem Kauf von Lizenzen unterstützen wir sie gerne kontinuierlich bei der Verwaltung der Lizenzen um so Mehraufwände in Ihrem Unternehmen zu reduzieren.

The post SAP Cloud Lizenzen appeared first on ActivateHR.

6SuccessFactors ist die next Gen Stufe des SAP HCM. Und soll ab spätestens 2030 das SAP HCM auf R/3 und bald auch auf S/4 Basis beerben. Der Hauptinvest der SAP richtet sich nur noch in Cloud Software im HR/HCM Bereich. Doch was ist das Cloud Gegenstück zu den einzelnen HR Modulen? Welches Modul in SuccessFactors beerbt welche SAP HCM on-Premise Module?

Das SAP HCM heute

SAP SuccessFactors

SAP SuccessFactors ist eine umfassende Cloud-Lösung, mit der Unternehmen die gesamte Personalarbeit verbessern können. Ihren Schwerpunkt besitzt die Software der SAP im Bereich Talentmanagement – die etablierte Lösung mit hoher Performanz ebnet dem Personalwesen den Weg zum Erfolg.

E-Book SAP HCM im Überblick

Dieses E-Book beinhaltet die 5 Stufen der Evolution des SAP HCM sowie aktuelle Trends.

SAP SuccessFactors bietet Ihnen folgende Funktionen für Ihr Talentmanagement:

• Recruiting und Bewerberverwaltung
  • Gewinnen Sie zielgerichtet Fach- und Führungskräfte für Ihr Unternehmen. Durch die direkte Steuerung von Stellenausschreibungen und die Bewertung von Bewerbern erhalten Sie mit SuccessFactors Recruiting ein umfassendes Bild des Recruitings in Ihrem Unternehmen.
• Zentrales Personaldatenmanagement
  • Die Verwaltung der Personaldaten des Unternehmens erfolgt im Employee Central – zentral und global zugänglich – und trotzdem geschützt.
• Onboarding
  • SuccessFactors unterstützt sie bei der Einarbeitung neuer Mitarbeiter. Diese kann gezielt geplant und gesteuert werden, sodass Sie jederzeit ein Bild des neuen Mitarbeiters gewinnen und eine drohende Kündigung in der Einlernphase vermeiden können.
• Lernmanagement-System
  • Wissen ist in der modernen Arbeitswelt ein Wettbewerbsvorteil. Das Management der Weiterbildung Ihrer Mitarbeiter ist in SAP SuccessFactors gezielt möglich: Sie können Fortbildungen planen, Zertifikate einsehen und sich an Termine erinnern lassen.
• Leistungsbeurteilung und Goal Management
  • Durch zentral gespeicherte Performance-Beurteilungen und Vereinbarungen aus Mitarbeitergesprächen können Sie mit SuccessFactors Ihre Talente gezielt fördern und haben einen Überblick über das Know-how in Ihrem Unternehmen.
• Nachfolge, Entwicklungsplanung und Workforce Analytics
  • Verlässt ein Mitarbeiter Ihr Unternehmen, ist es wichtig diese Lücke schnell zu schließen. Im System erkennen Sie frühzeitig das Ausscheiden von Mitarbeitern (z. B. durch Rente) und sehen wer als Nachfolger für eine Stelle geeignet ist. Mit SAP SuccessFactors können Sie flexibel auf sich verändernde Geschäftsbedingungen reagieren und durch gezieltes Workforce Planning frühzeitig aktiv werden.

Der Vergleich von SAP HCM zu SAP SuccessFactors

Wie sie Sehen liegt die Zukunft des SAP HCM in SuccessFactors. Die alte Modulsuite findet sich in der neuen Suite wieder oder wird sogar durch neue Funktionen ergänzt wie beispielsweise Künstliche Intelligenz. Haben Sie Fragen zu SuccessFactors ? Kommen Sie gerne auf uns zu.

The post SuccessFactors als SAP HCM 2.0? appeared first on ActivateHR.

Viele Aufgaben in Personalabteilungen werden manuell bearbeitet. Mitarbeiter warten dadurch oftmals mehrere Wochen auf die Bearbeitung von Anträgen, Anfragen und ähnlichem. Gleichzeitig sind die Mitarbeiter der Personalabteilung häufig überarbeitet und gestresst. Viele dieser Prozesse beinhalten wiederkehrende und monotone Aufgaben. Diese Prozesse eignen sich hervorragend, um Ihre Mitarbeiter durch Robotic Process Automation zu entlasten. Neben der Entlastung der Mitarbeiter führt die Automatisierung auch zu einer Steigerung der Effizienz, Reduktion der Bearbeitungskosten und -zeiten und letztlich zur Steigerung der Zufriedenheit all Ihrer Mitarbeiter.

Welche Vorteile bietet der Einsatz von RPA im Personalwesen?

Der Einsatz von Robotic Process Automation bietet viele Vorteile. Einige davon sind:

• Reduktion von Fehlern
• Reduktion der Bearbeitungskosten
• Reduktion der Bearbeitungszeiten
• Steigerung der Effizienz durch standardisierte Prozessabläufe
• Steigerung der Mitarbeiterzufriedenheit
• Mehr Zeit für Wertschöpfung

Was kann automatisiert werden?

Im Folgenden möchte ich Ihnen zwei Beispiele nennen, bei denen sich der Einsatz von Robotic Process Automationen anbietet.

Onboarding

Nachdem der Bewerbungsprozess abgeschlossen und der Arbeitsvertrag unterschrieben ist, beginnt der Onboarding-Prozess. Dabei müssen unter anderem User- sowie Mail-Accounts angelegt werden, Ausstattung wie PC, Telefon etc. bestellt und Rollen und Rechte vergeben werden.
Selbst wenn es zu jedem dieser Punkte offiziell ein standardisiertes Vorgehen geben mag, schleichen sich doch oftmals Fehler ein. Möglicherweise kommt es zu Verzögerungen oder sogar zu Informationslücken, die dazu führen, dass beispielsweise ein Nutzer-Account nicht angelegt wird.
Durch die Automatisierung über RPA können all diese Probleme vermieden werden und der neue Mitarbeiter kann bereits am ersten Tag direkt loslegen.

Stammdatenverwaltung

Einige Informationen zu Ihren Mitarbeitern ändern sich im Laufe ihrer Anstellung. Sei es eine Adressänderung, eine Namensänderung durch Heirat, die Änderung der Bankverbindung oder etwas anderes. Zwar gibt es mittlerweile viele Produkte, die dabei unterstützen können, manueller Aufwand entsteht dabei allerdings dennoch. Auch hier bietet sich die Automatisierung der Aufgaben durch RPA an.

Wie Ihr Unternehmen von Künstlicher Intelligenz (KI) profitieren kann

In unserem E-Book erfahren Sie die wichtigsten Inhalte rund um das Thema künstliche Intelligenz & wie Sie davon profitieren können!

Nächste Schritte

Darüber hinaus gibt es natürlich noch unzählige weitere Anwendungsmöglichkeiten. Wenn Sie wissen möchten, welche Prozesse bei Ihnen durch RPA automatisiert werden können, kontaktieren Sie mich gerne!

The post RPA im Personalwesen appeared first on ActivateHR.

Interessieren Sie sich für die Einführung einer günstigen Stempeluhr? Dann ist unser Stempeluhr Plugin genau das Richtige für Sie!

Die Stempeluhr im Launchpad eingebunden

Die Stempeluhr im Detail

Ihre Bedürfnisse im Vordergrund

Was erwarten Sie von unserer Stempeluhr?

Die Stempeluhr auf einen Blick

Natürlich sieht der Mitarbeiter direkt, wann seine letzte Buchung war. Außerdem kann individuell gesteuert werden, welche Zeitarten angezeigt werden. So hat ihr Mitarbeiter beispielsweise seinen Gleitzeitstand direkt mit im Überblick.

Schnelle Einführung unserer Stempeluhr-Lösung

Durch unser standardisiertes Produkt können wir gewährleisten, dass wir innerhalb kürzester Zeit die Stempeluhr bei Ihnen einführen können und so den Stempelprozess verbessern und weniger anfällig für Fehler machen. Ersparen Sie sich Zeitaufwand, z. B. für Korrekturbuchungen, durch eine einfache und intuitive Handhabung.

Aufwände sparen

Nicht nur durch die einfache Handhabung lässt sich bares Geld sparen. Entlasten Sie auch ihre Führungskräfte: Da nur zur aktuellen Uhrzeit gebucht werden kann, ist kein Genehmigungsverfahren notwendig.

Haben Sie Fragen zur App?
Kontaktieren Sie mich per E-Mail klempien@activate-hr.de oder nutzen Sie unsere unverbindliche Telefonberatung 0211 9462 8572-45, um Ihre Fragen zu klären. Ich nehme mir gerne Zeit für Ihr Anliegen, spreche mit Ihnen über Ihre Ausgangslage und zeige Ihnen mögliche nächste Schritte auf.

Sie wollen doch lieber eine eigenständige Applikation für das Stempeln? Dann ist vielleicht unsere Stempeluhr App das Richtige für Sie. Auch wenn Sie Ideen für neue Lösungen haben, unterstützen wir Sie gerne.

The post Stempeluhr Plugin für Fiori – jetzt im Fiori Launchpad appeared first on ActivateHR.