Bereits enthaltene Standardberechtigungen
Gleiche Berechtigungen
Der Funktionsbaustein wurde offensichtlich nicht für diese Verwendung vorgesehen, unser Vorgehen beeinflusst aber nicht den Programmablauf, und es sind uns keine Einschränkungen durch diese Nutzung bekannt. Diese Vorgehensweise können Sie auch bei anderen BTEs anwenden, die in ähnlicher Form Daten übergeben. Dabei sollten Sie aber immer Vorsicht walten lassen und prüfen, ob die Anwendung bereits Summendatensätze gebildet hat oder ob es andere Abhängigkeiten gibt. Abschließend müssen Sie noch ein von Ihnen entwickeltes Produkt (den Namen können Sie selbst definieren) in der Transaktion FIBF anlegen und dieses zusammen mit dem kundeneigenen Funktionsbaustein dem Business Transaction Event 1650 zuordnen, wie es in der folgenden Abbildung zu sehen ist. Zu einem kundeneigenen Produkt können mehrere Erweiterungen gehören. Es bildet eine logische Klammer um die Erweiterungen und sorgt so für eine bessere Übersicht. Zusätzlich ermöglicht es eine gezielte Aktivierung bzw. Deaktivierung der Implementierungen.
Sie können einem Benutzer weiterhin Rollen und Profile zuordnen, wenn Sie die entsprechenden Berechtigungen zu diesen Aktivitäten haben. Solange dem Benutzer keine Benutzergruppe zugeordnet ist, reichen die Berechtigungen für eine beliebige Benutzergruppe. Ordnen Sie dem neu angelegten Benutzer nun eine Benutzergruppe zu, werden alle Prüfungen noch einmal für diese Benutzergruppe wiederholt.
Transaktion PFUD regelmäßig einplanen
Da Entwicklerberechtigungen einer Vollberechtigung entsprechen, sollten diese nur restriktiv vergeben werden. Dies gilt vor allen Dingen für die Berechtigung zum „Debugging mit Replace“ (siehe „Gesetzes kritische Berechtigungen“). Das Risiko durch falsch vergebene Entwicklerberechtigungen ist auch durch das Wegfallen des Zusatz-Schutzes über Entwickler- und Objektschlüssel in S/4 HANA Systemen gestiegen (siehe u.a. SAP-Hinweis 2309060). Entwicklerberechtigungen für originale SAP-Objekte sollten hier also nur noch auf Antrag vergeben werden, um unautorisierte Modifikationen zu vermeiden. Falls Entwicklerschlüssel in dem vorhandenen SAP-Release also noch relevant sind, sollten zunächst die vorhandenen Entwicklerschlüssel in der Tabelle DEVACCESS überprüft und mit den für die Entwicklung vorgesehenen Benutzern abgeglichen werden.
Dabei müssen Sie die Vorlage an die Gegebenheiten in Ihrem Unternehmen anpassen, also vermutlich die Ablage der Zertifikate abhängig von der Namenskonvention für Ihre Benutzer definieren und die Prüfung der Zertifikate anpassen. Diese Prüfung der Zertifikate stellt in der Vorlage sicher, dass keine bereits vorhandenen Zertifikate hinzugefügt werden und nur ein Zertifikat zu einer E-Mail-Adresse eingetragen wird. Diese Prüfung ist notwendig, da der Versand einer verschlüsselten E-Mail abgebrochen wird, wenn mehr als ein gültiges Zertifikat zu einer E-Mail-Adresse gefunden wurde. Über dieses kundeneigene Programm können Sie Massenimporte der Zertifikate abbilden. Zusätzlich müssen Sie aber auch eine Vorgehensweise für die Verwaltung von Zertifikaten in Ihrem Unternehmen definieren, d. h. sich überlegen, wie Änderungen an den Zertifikaten in das SAP-System übertragen werden können.
Sollten Sie in die Situation geraten, dass Berechtigungen erforderlich sind, die nicht im Rollenkonzept berücksichtigt wurden, ermöglicht Ihnen "Shortcut for SAP systems" die Zuweisung der Komplettberechtigung für das jeweilige Berechtigungsobjekt.
In diesen sieben Feldern definieren Sie, welche Werte Sie auf den Registerkarten eingeben können.
Mit einem Servicebenutzer sind immer Mehrfachanmeldungen möglich, und die Regeln für die Änderung von Passwörtern greifen nicht.