Januar 2026
Einführung
Lösungsansatz
Berechtigungspflege im BW und mapping BW – User zu SAC User
In unserem Beispiel gehen wir von einer Einzelpflege der Berechtigungen für Buchungskreise aus. Dies haben wir über ein planungsbereites aDSO mit den Schlüsselfeldern „BW User“ und „Company“ sowie dem planungsrelevanten Attribut „Flag Valid“ umgesetzt. Das Flag verwenden wir, um Berechtigungen zurückzunehmen, da Zeilen nicht einfach gelöscht werden können.
Um das Mapping zu abweichenden BW‑Usernamen zu ermöglichen, haben wir dem Merkmal „BW User“ einfach das Attribut „SAC‑User“ hinzugefügt. Dieses muss einmalig für jeden User gepflegt werden.
Abbildung 1: Beispiel zur Pflege der Benutzerberechtigung
Wird eine Berechtigung auf Hierarchieknoten, bzw. einer zeitabhängigen Pflege benötigt, ist das Szenario entsprechend zu erweitern, ändert aber die grundsätzliche Logik nicht.
BW – Berechtigung aus der Tabelle ableiten
Abbildung 2: Coding der Exit – Variable für die BW – Berechtigung
Nun muss nur noch ein BW‑Berechtigungsobjekt angelegt werden, und die Berechtigung wird für die gewünschten InfoProvider mithilfe der Exit‑Variable dem entsprechenden Merkmal zugeordnet (siehe nächste Abbildung).
Abbildung 3: BW – Berechtigungsobjekt für die Einschränkung über die Exit – Variable ZCOMPANY4AUTH
Abbildung 4: Beispiel BW – Bericht ohne Einschränkung
Und einen Bericht, bei dem die Berechtigung angewandt wird:
Abbildung 5: Der selbe Bericht für einen Benutzer mit Einschränkungen
Synchronisation mit der SAP Analytics Cloud
In der SAC ist der Buchungskreis entsprechend dem BW als öffentliche Dimension angelegt:
Abbildung 6: Öffentliche berechtigungsrelevante SAC Dimension
Zusätzlich wird die Datenzugriffsberechtigung vergeben. Für das weitere Beispiel betrachten wir nur die Write‑Berechtigung, parallel wäre jedoch auch Read möglich – oder eine Kombination aus beiden.
Um die Berechtigungsinformationen in der SAC bereitzustellen, benötigen wir eine Query, die alle erlaubten Zugriffe auflistet. Das berechtigungsrelevante Attribut (hier ZCOMPANY) sowie alle User – entscheidend ist am Ende der SAC‑Username – müssen als Liste dargestellt werden.
In unserem Beispiel sieht das in der SAC folgendermaßen aus:
Abbildung 7: BW Bericht in der SAC mit allen Berechtigungen
Dieser Aufriss ist notwendig, da die Zuordnung zwischen Buchungskreis und User mit dem Attribut SAC User über das Result Set im Script gelesen wird, um die Berechtigungen auf die SAC Dimension zu übertragen.
Die eigentliche Synchronisierung findet im Script statt. Dieses wird durch einen einfachen Button getriggert. Dies ruft die Methode „f_setAuthoriation“ auf.
Abbildung 8: Definition der Funktion, um die Berechtigungen zu übertragen
Innerhalb dieser Methode werden zunächst einige Variablen definiert
// Get result set from table data source
var tableResultSet = p_Table.getDataSource().getResultSet();
// Reference planning model
var planningModel = PlanningModel_1;
// Get all members of the given dimension
var planningModelMembers = planningModel.getMembers(p_Dimension);
// Array for members to be updated
var members = ArrayUtils.create(Type.PlanningModelMember);
// Array to store BW member–user combinations (DIM$USER)
var dimensionMembersBW = ArrayUtils.create(Type.string);
// Temporary variables
var dimensionMember = "";
var dimensionUser = „“;
var dimensionKey = „“;
// Array to store unique dimension members from BW
var dimensionArrayBW = ArrayUtils.create(Type.string);
Danach werden zwei Schleifen durchlaufen. Die erste Schleife läuft durch das Result Set und baut einen künstlichen Schlüssel zwischen Buchungskreis und Nutzer auf. Außerdem wird ein Array mit den einzelnen Buchungskreisen befüllt.
// Extract dimension members and users from BW result set
for (var j = 0; j < tableResultSet.length; j++) {
// Get dimension member ID
dimensionMember = tableResultSet[j][p_Dimension].id;
// Get BW user mapped to SAC user
dimensionUser = tableResultSet[j][p_User].properties["ZBW_USER.ZSAC_USER.DISPLAY_KEY"];
// Build DIM$USER key if user exists
if (dimensionUser !== „#“) {
dimensionKey = dimensionMember + "$" + dimensionUser;
dimensionMembersBW.push(dimensionKey);
}
// Store unique dimension members
if (dimensionArrayBW.includes(dimensionMember) === false) {
dimensionArrayBW.push(dimensionMember);
}
}
In „dimensionKey“ haben wir die kombinierten Schlüssel aus dem BW, die eine Schreibberechtigung haben sollen.
Die zweite Schleife durchläuft die Planungsmodellelemente des Buchungskreises in der Analytics Cloud. Dabei wird geprüft, ob der Buchungskreis aus dem BW mit dem aus der Analytics Cloud übereinstimmt. Gleichzeitig sollen vorhandene Teams unverändert bleiben. In dieser Variante werden alle Nutzer entfernt und durch die im BW definierten Nutzer ersetzt, während alle Teams bestehen bleiben.
// Loop through planning model members
for (var n = 0; n < planningModelMembers.length; n++) {
// Process only members found in BW result set
if (dimensionArrayBW.includes(planningModelMembers[n].id) === true) {
// Remove existing user writers but keep team writers
for (var i = 0; i <= planningModelMembers[n].writers.length; i++) {
var member = planningModelMembers[n].writers.pop();
if (member !== undefined && member.type === UserType.Team) {
planningModelMembers[n].writers.push(member);
}
}
// Add users as writers based on BW mapping
for (var k = 0; k < dimensionMembersBW.length; k++) {
if (planningModelMembers[n].id === dimensionMembersBW[k].split(„$“)[0]) {
planningModelMembers[n].writers.push({
id: dimensionMembersBW[k].split(„$“)[1],
type: UserType.User
});
}
}
// Collect updated member
members.push(planningModelMembers[n]);
}
}
Die angepassten Buchungskreise stehen in „members“. Um die Berechtigungen anzupassen muss nur noch das Planungsmodel aktualisiert werden.
// Update dimension members with new authorizations
planningModel.updateMembers(p_Dimension, members);
Nachdem die Funktion lief, sieht der Buchungskreis folgenderweise aus:
Abbildung 9: SAC Dimension nach Übernahme der BW – Berechtigungen
Beide Nutzer sind auf die Buchungskreise berechtigt, die dem Wert in der Query entsprechen.
Die Synchronisierung der Berechtigungen beider Systeme ist damit möglich, es gibt aber einige Fallstricke. Wenn die BW nicht 1:1 dem SAC User Namen entsprechen, muss der SAC User Name als Attribut angefügt und entsprechend mit gepflegt werden. Sollte der Name im BW falsch gepflegt sein, wird der Nutzer dennoch in die Berechtigung übernommen. Dies wirft einen Fehler in der Dimension selber mit folgender Fehlermeldung:
Abbildung 10: Fehlermeldung, wenn ein nicht gültiger SAC – User übertragen wird
SAC schlägt vor, die falschen Benutzer zu entfernen. Eine Korrektur und Pflege der gewünschten User muss dann noch manuell durchgeführt werden.
Das Script muss immer ausgeführt werden, wenn Änderungen der Berechtigungen übertragen werden müssen. In der vorgestellten Variante ist es dem Nutzer selbst überlassen, wann die Änderungen vorgenommen werden soll.
Laufzeit
Da diese Funktion in ein Skript hinter einem Button liegt, darf die SAC Seite während des Abgleichs nicht geschlossen werden, bis das Skript durchgelaufen ist!
Die Laufzeit hängt von der Anzahl der Ausprägungen für das berechtigungsrelevante Attribut ab. Hat dies über 1000 Einträge, was z.B. bei einer Berechtigung auf Kostenstelle vorkommen kann, muss mit Laufzeiten von einigen Minuten gerechnet werden, die linear mit der Menge an Einträgen steigt.
Da das Result Set im Script die aktuelle Selektion nimmt, kann mit einem Filter die Datenmenge angepasst werden. So kann der Administrator einen Abgleich gezielt für die gerade geänderten Kombinationen durchführen, was entsprechend kurze Laufzeiten ermöglicht.
Abbildung 11: Beispiel des SAC – Berichtes mit eingeschränkter Anzeige auf einen User
Fazit
Der Aufwand einer Berechtigungssynchronisierung ist relativ gering. Mit wenig Coding kann die Information der Berechtigungen aus dem BW in die SAC überführt werden. Sollten die Nutzer die gleiche ID in beiden Systemen haben, wird nicht mal das Attribut am BW Objekt benötigt. Allerdings gibt es noch keine gute Möglichkeit zu prüfen, ob die übertragenden Nutzer und Buchungskreise auch in der SAC entsprechend vorhanden sind. Sollte ein Buchungskreis im BW vorhanden sein, in der SAC aber nicht, würde entsprechende Berechtigung nicht berücksichtigt. Es muss also sichergestellt werden, dass die Stammdaten des berechtigungsrelevanten Attributs idealerweise identisch mit denen im BW sind am besten direkt aus dem BW geladen und dass die entsprechenden Nutzer auch in der SAC existieren.
