BTP - User Anlage per API
Wie kannst du eigentlich den Employee und den Business User per API im ABAP Environment anlegen? In diesem Artikel gehen wir auf die Details und die Implementierung ein.
Inhaltsverzeichnis
In diesem Artikel schauen wir uns die Anlage von Benutzern im ABAP Environment über die aktuell zur Verfügung gestellte API an und wie du damit in Zukunft die Anlage vereinfachen kannst.
Einleitung
Als das ABAP Environment vor einigen Jahren eingeführt wurde, änderte sich damit auch das Konzept, wie User im System angelegt werden und welche Stammdaten ein User hat. Bevor der eigentliche Business User (klassisch SU01) im System angelegt werden kann, benötigt dieser einen Mitarbeiterstamm (Employee), erst dann kann der User mit den entsprechenden Berechtigungen angelegt werden. Dies wird aktuell über die entsprechenden Apps im ABAP Environment gemacht.
User
Bevor wir in das Thema automatische Anlage einsteigen, noch eine kurze Erklärung des User Konzepts das im ABAP Environment verwendet wird. Der Mitarbeiter (Employee) ist der Userstammsatz und hält Informationen zum Namen, der Mail oder der Adresse. Aus diesem User wird das ein Business User im System erzeugt, diesem werden dann auch die Rollen zugeordnet. Soll der User sich nicht mehr anmelden, würdest du auf dieser Ebene die Sperre setzen.
Employee
Dazu legen wir einen Dummy User an und gehen Schritt für Schritt durch den Anlageprozess. Im ersten Schritt benötigen wir einen Mitarbeiter. Über die App "Maintain Employees" (F2288A) legen wir unseren User an, dabei sind die Felder ID, Name, Vorname und E-Mail im ersten Schritt relevant.
Über den List Report filtern wir dann nach dem Speichern auf unseren neuen User und können über die Aktion "Maintain Bussinses User" den Business User anlegen und die die nächste App abspringen.
In der App "Maintain Business Users" (F1303) müssen wir dann nur den User Namen hinterlegen, dieser wird in den meisten Fällen für die Anmeldung im Backend benötigt. Im Anschluss können wir dem User seine Rollen zuordnen, in diesem Fall legen wir einen Entwickler im System an.
Hinweis: Mit dem Employee wird im System ein Business Partner im Hintergrund angelegt. Im Business User findest du die neue ID, die aber pro System unterschiedlich ist. Aktuell gibt es keine Lösung für einheitliche Business Partner Nummern pro User und das Feld SY-UNAME liefert diese nicht eindeutige ID.
API
In diesem Kapitel wollen wir die API implementieren und nutzen, um die User wie oben beschrieben im System anzulegen und automatisch zu berechtigen. Eine API würde sich zum Beispiel sehr gut eignen, um sie aus einer Process Automation heraus zu verwenden oder innerhalb des Systems anzusprechen.
Business Accelerator Hub
Zuerst einmal benötigen wir die richtige API für diesen Fall. Mit etwas Recherche haben wir die SOAP API SAP_COM_0093 (technischer Name MANAGEBUSINESSUSERIN) gefunden. Dazu finden wir im SAP Business Accelerator Hub (ehemals API Hub) weiterführende Informationen und unter SAP Help Informationen zur Befüllung der Schnittstelle. Die Dokumente findest du unten verlinkt, können aber auch über den Business Accelerator Hub abgerufen werden.
Konfiguration
Im nächsten Schritt müssen wir die Schnittstelle im System konfigurieren, da wir die API von außen triggern müssen bzw. sie auch für externe Aufrufer, wie SAP Build Process Automation, zur Verfügung stellen wollen. Dazu richten wir ein Communication Arrangement mit Communication System und User ein, den wir für den Zugriff von außen benötigen. Weitere Details zur Konfiguration eines Arrangements und dazugehöriger Objekte findest du in diesem Artikel.
Im Anschluss wollen wir eine Destination mit den entsprechenden Daten anlegen. Dazu musst du in den Subaccount gehen, wo du die Verbindung benötigst. Dabei verwenden wir den Communication User und Passwort, um uns am System anzumelden.
Wichtig ist dabei die Verwendung des kompletten Pfads aus dem Communication Arrangement (Business User), sonst klappt die Verbindung zum System nicht. Stell also sicher, dass der folgende Pfad hinter der System-URL zu finden ist.
/sap/bc/srt/scs_ext/sap/managebusinessuserin
Hinweis: Mehr zum Thema Inbound und Outbound Kommunikation im ABAP Environment, findest du in diesem Artikel.
Implementierung
Im nächsten Schritt müssen wir die ABAP Artefakte im System generieren, um den Service aufrufen zu können. Dann bauen wir einen Wrapper um die Klasse, um die API ganz einfach im System verwenden zu können.
Consumption Model
Dazu benötigen wir die WSDL Datei mit der Beschreibung der Schnittstelle und Artefakte. Du kannst die Datei über das Communication Arrangement herunterladen oder findest diese auch im Business Accelerator Hub. Im nächsten Schritt müssen wir im System ein Consumption Model anlegen, dazu kannst du einfach auf das entsprechende Paket gehen und im Project Explorer per Rechts-Klick "New -> Other ABAP Repository Object" wählen. Im nächsten Schritt suchen wir nach Consumption Modellen.
Wir wählen das Service Consumption Model aus der Liste und füllen im nächsten Dialog die Felder aus. Das Objekt bekommt einen Namen und eine Beschreibung und als Typ Web Service, unter den SOAP fällt.
Im letzten Schritt geben wir den Dateipfad zur WSDL Datei an und definieren einen Prefix für die zu generierenden ABAP Artefakte aus. Im Anschluss beginnt die Generierung der Artefakte im System, dabei werden knapp 170 Artefakte im System angelegt. Damit ist der Web Service, wie bereits On-Premise, nicht unbedingt der sparsamste, wenn es um ABAP Artefakte geht.
Wrapper
Ist das Consumption Model im System angelegt, können wir den Service Aufruf in einem Wrapper modellieren, um diesen im System und unseren Prozessen wiederverwenden zu können. Deshalb definieren wir im ersten Schritt eine Struktur in Form eines abstrakten CDS Views. Über diesen View wollen wir die benötigten Daten in unsere Klasse bekommen.
@EndUserText.label: 'Create User in System'
define abstract entity ZBS_S_DMOCreateUser
{
UserID : abap.string(0);
FirstName : abap.char(150);
LastName : abap.char(150);
EMailAddress : abap.char(250);
ValidTo : abap.dats;
}
Im nächsten Schritt legen wir eine Klasse an. Diese soll den Employee und den Business User im System anlegen. Im ersten Schritt legen wir in der Klasse eine Struktur für die Konfiguration an und einige Konstanten, die wir für die Verarbeitung benötigen. Der Action Code und die Partner Rolle, die über die API angesprochen werden können, sind in der Dokumentation unten beschrieben.
TYPES action TYPE c LENGTH 2.
TYPES role TYPE c LENGTH 6.
TYPES: BEGIN OF configuration,
application_log TYPE REF TO object,
cloud_destination TYPE string,
communication_arrangement TYPE if_com_management=>ty_cscn_id,
END OF configuration.
CONSTANTS: BEGIN OF action_code,
create TYPE action VALUE '01',
update TYPE action VALUE '02',
delete TYPE action VALUE '03',
END OF action_code.
CONSTANTS: BEGIN OF partner_role,
employee TYPE role VALUE 'BUP003',
contingent_worker TYPE role VALUE 'BBP005',
END OF partner_role.
Dazu übergeben wir unsere Konfiguration an die Klasse, diese entscheidet dann, ob wir über eine Destination oder ein Communication Arrangement den Proxy erzeugen wollen. Mit erzeugter Destination wird dann unsere Proxy Klasse erzeugt und als Ergebnis an den Aufrufer gegeben.
DATA destination TYPE REF TO if_proxy_destination.
IF configuration-cloud_destination IS NOT INITIAL.
destination = cl_soap_destination_provider=>create_by_cloud_destination(
i_name = configuration-cloud_destination ).
ELSEIF configuration-communication_arrangement IS NOT INITIAL.
destination = cl_soap_destination_provider=>create_by_comm_arrangement( configuration-communication_arrangement ).
ELSE.
RAISE EXCEPTION NEW cx_soap_destination_error( ).
ENDIF.
RETURN NEW zbs_dmo_co_manage_business_use( destination = destination ).
Im nächsten Schritt befüllen wir die Struktur über unsere übergebenen User Informationen. Wichtig ist dabei, dass wir den Action Code an den nötigen Stellen befüllen und die Partnerrolle für Employee befüllen.
INSERT INITIAL LINE INTO TABLE result-business_user_bundle_maintain-business_user REFERENCE INTO DATA(business_user).
business_user->validity_period = VALUE #( start_date = cl_abap_context_info=>get_system_date( )
end_date = COND #( WHEN user-ValidTo IS NOT INITIAL
THEN user-ValidTo
ELSE '29991231' ) ).
business_user->personal_information = VALUE #( first_name = user-FirstName
last_name = user-LastName
action_code = action_code-create ).
business_user->person_external_id = user-UserID.
business_user->user = VALUE #(
user_name = user-UserID
validity_period-start_date = business_user->validity_period-start_date
validity_period-end_date = business_user->validity_period-end_date
action_code = action_code-create ).
business_user->workplace_information = VALUE #( email_address = user-EmailAddress
action_code = action_code-create ).
business_user->action_code = action_code-create.
business_user->business_partner_role_code = partner_role-employee.
Als letzten Schritt können wir dann das Fehlerprotokoll auswerten und in unser Application Log übernehmen. Im Ergebnis des Aufrufs finden wir auch unsere neue Business Partner ID, die wir noch für den Folgeprozess verwenden können.
LOOP AT response-business_user_bundle_maintain-business_user INTO DATA(response_log).
result = response_log-person_id.
LOOP AT response_log-log-item INTO DATA(item).
DATA(severity) = SWITCH #( item-severity_code
WHEN '1' THEN if_bali_constants=>c_severity_status
WHEN '2' THEN if_bali_constants=>c_severity_warning
WHEN '3' THEN if_bali_constants=>c_severity_error
ELSE if_bali_constants=>c_severity_status ).
configuration-application_log->add_msg_text( id_type = severity
id_text = item-note ).
ENDLOOP.
ENDLOOP.
Berechtigungen
Erhalten wir von der Schnittstelle dann keine Fehler mehr, wurde der Business Partner im System angelegt. Im letzten Schritt können wir ihm die Entwicklerrolle zuordnen. Dazu verwenden wir die Standard ABAP Klasse CL_IAM_BUSINESS_USER_FACTORY und die BP Nummer oder User ID aus dem Schritt zuvor, über die wir den User einlesen und neue Rollen zuordnen können. Die API würden wir aber in diesem Artikel nicht näher beschreiben, da wir uns auf die User API beschränken wollen.
Vollständiges Beispiel
Die Beispiele in diesem Artikel findest du bei uns in den Code Snippets im GitHub Repository. Dort findest du den Core Data Service für die Übergabe der Daten und die Klasse für den Aufruf und die Befüllung des Services.
Unser Standard Application Log Objekt wirst du dort nicht finden, alles in diesem Zusammenhang musst du durch ein dir passendes Objekt austauschen, wir verwenden dabei einen Wrapper der Standardklasse.
Fazit
Die Einrichtung der SOAP API im System kostet etwas an Zeit, die Implementierung der Klasse sollte dafür aber recht einfach gehen, da wir eine voll typisierte Schnittstelle erhalten. Mit unserem Tipp solltest du nun automatisiert User im System und von außen anlegen können.
Quelle:
SAP Help - Business User
SAP Community - How to call local SOAP API in ABAP Environment
SAP Developers - Consume SOAP Based Web Services
