Beispiele für Genehmigungs-Policys

Beispiel 1: Genehmigungs-Policys auf Anwendungsebene

Sehen wir uns zunächst ein einfaches Beispiel dazu an, wie Genehmigungen auf Basisebene funktionieren. In diesem Beispiel gibt es eine Genehmigungs-Policy auf Anwendungsebene, die besagt, dass mindestens zwei Personen aus der Gruppe "GL Govern" alle Änderungen an den Kontenplänen genehmigen müssen.

Die Gruppe "GL Govern" besteht aus Barry, Julie und Jane. Tom ist Eigentümer der Fusion GL-Anwendung.

Genehmigungsworkflow.

1. Mark leitet eine Anforderung zum Hinzufügen eines Kontos und zum Aktualisieren einer Kostenstellenbeschreibung weiter.
2. Da die Genehmigungsmethode "Parallel" lautet, wird an alle drei Mitglieder der Gruppe "GL Govern" eine Anforderung zur Genehmigung gesendet.
3. Julie genehmigt die Anforderung.
4. Barry genehmigt die Anforderung.
5. Die Policy-Anforderungen sind erfüllt, und die Anforderung wird festgeschrieben.

Beispiel 2: Deadlock-Eskalation

Sehen wir uns das Beispiel erneut an. Dieses Mal wurden Barry und Jane jedoch aus der Gruppe "GL Govern" entfernt.

Die Gruppe "GL Govern" besteht nur aus Julie. Tom ist Eigentümer der Fusion GL-Anwendung.

Genehmigungsworkflow.

1. Mark leitet eine Anforderung zum Hinzufügen eines Kontos und zum Aktualisieren einer Kostenstellenbeschreibung weiter.
2. Eine Genehmigungsanforderung wird an Julie gesendet.
3. Julie genehmigt die Anforderung.

   Obwohl für die Policy zwei Genehmiger aus der Gruppe "GL Govern" erforderlich sind, ist in dieser Gruppe nur Julie enthalten. Da es zum Erfüllen der Policy-Anforderungen keine weiteren Genehmiger gibt, kommt es zu einem Deadlock. Die Anforderung wird daher an Benutzer eskaliert, die in der Anwendung über die Berechtigung Datenmanager verfügen. Da Tom Eigentümer der Anwendung ist, enthält seine Berechtigung Eigentümer die Berechtigung Datenmanager.

4. Die Anforderung wird an Tom eskaliert.
5. Tom genehmigt die Anforderung.
6. Die Policy-Anforderungen sind erfüllt, und die Anforderung wird festgeschrieben.

Beispiel 3: Genehmigungs-Policy auf Dimensionsebene - Seriell

Sehen wir uns als Nächstes eine Policy des Typs "Seriell" auf Dimensionsebene an. In diesem Beispiel muss Josh die Anforderung als Erstes, gefolgt von Frank und einer weiteren Person aus der Gruppe "Accounting" genehmigen.

Die Gruppe "Accounting" besteht aus James und Heather.

Genehmigungsworkflow.

1. Mark leitet eine Anforderung zum Verschieben von drei Konten weiter.
2. Eine Genehmigungsanforderung wird an Josh gesendet.
3. Josh genehmigt die Anforderung.
4. Eine Genehmigungsanforderung wird an Frank gesendet.
5. Frank genehmigt die Anforderung.
6. Genehmigungsanforderungen werden an die Gruppe "Accounting" (James und Heather) gesendet.
7. Heather genehmigt die Anforderung.
8. Die Policy-Anforderungen sind erfüllt, und die Anforderung wird festgeschrieben.

Beispiel 4: Genehmigungs-Policy für Knotentyp- und Hierarchiesetebene

Während Genehmigungs-Policys auf Anwendungs- und Dimensionsebene für alle Anforderungsaktionen angewendet werden, werden Policys auf Knotentyp- und Hierarchiesetebene nur auf bestimmte Anforderungsaktionen angewendet. Policys für einen Knotentyp werden nur für Anforderungen angewendet, die Knoten hinzufügen oder löschen oder Knoteneigenschaften aktualisieren. Policys für ein Hierarchieset werden nur für Anforderungen angewendet, die Knoten in einem Hierarchieset einfügen, entfernen, verschieben, die Reihenfolge ändern oder Knotenbeziehungseigenschaften aktualisieren.

Sehen wir uns zur Verdeutlichung zwei Anforderungen für ein Beispiel an, in dem Policys für den Knotentyp und das Hierarchieset vorhanden sind. Die erste Anforderung aktualisiert eine Knoteneigenschaft. Es wird also nur die Policy im Knotenset angewendet. Die zweite Anforderung fügt Konten hinzu. Dies hat Auswirkungen auf den Knotentyp und das Hierarchieset. Daher werden beide Policys angewendet.

Weitere Hintergrundinformationen zu den Anforderungen:

• Die Gruppe "Accounting" besteht aus James und Heather.
• Die Gruppe "TaxUsers" besteht aus Brian, Jane und Rachel.
• Die Gruppe "EssAdmins" enthält sieben Administratoren (EssAdmin1 bis EssAdmin7).

Sehen wir uns zunächst eine Anforderung zum Aktualisieren von Knoteneigenschaften an. Aktualisierungen von Knoteneigenschaften sind nur von Policys für den Knotentyp betroffen.

Genehmigungsworkflow für Anforderung 1:

1. Mark leitet eine Anforderung zum Aktualisieren von drei Kontenbeschreibungen (Aktualisierung von Knoteneigenschaften) weiter.
2. Genehmigungsanforderungen werden an die Gruppen "Accounting" und "TaxUsers" gesendet.

   Hinweis:

   Da eine Aktualisierung der Knoteneigenschaft keine Auswirkungen auf das Hierarchieset hat, erhält die Gruppe "EssAdmins" keine Genehmigungsanforderung.
3. James genehmigt die Anforderung für die Gruppe "Accounting".
4. Rachel genehmigt die Anforderung für die Gruppe "TaxUsers".
5. Die Policy-Anforderungen sind erfüllt, und die Anforderung wird festgeschrieben.

Sehen wir uns als Nächstes eine zweite Anforderung an, dieses Mal zum Hinzufügen von Knoten. Wie zuvor wird die Policy im Knotentyp angewendet, da die Anforderungsaktion Knoten hinzufügt. Bei dieser Anforderung wird jedoch auch die Policy im Hierarchieset angewendet, da Aktionen zum Hinzufügen Aktionen zum Einfügen in hierarchiebasierten Ansichtspunkten erstellen.

Genehmigungsworkflow für Anforderung 2:

1. Mark leitet eine Anforderung zum Hinzufügen von drei neuen Konten weiter.
2. Genehmigungsanforderungen werden an die Gruppen "Accounting" und "TaxUsers" gesendet.
3. Da durch eine Aktion zum Hinzufügen in einem hierarchiebasierten Ansichtspunkt auch Aktionen zum Einfügen im Hierarchieset erstellt werden, werden Genehmigungsanforderungen auch an die Gruppe "EssAdmins" gesendet.
4. James genehmigt die Anforderung für die Gruppe "Accounting".

   Hinweis:

   Da James über die implizite Berechtigung Teilnehmer (lesen) für den Knotentyp, jedoch nicht für das Hierarchieset verfügt, muss er die Anforderung im Anforderungsinspektor genehmigen. Informationen hierzu finden Sie unter Policys und Berechtigungen.
5. Rachel genehmigt die Anforderung für die Gruppe "TaxUsers".

   Hinweis:

   Da Rachel über die implizite Berechtigung Teilnehmer (lesen) für den Knotentyp, jedoch nicht für das Hierarchieset verfügt, muss sie die Anforderung im Anforderungsinspektor genehmigen. Informationen hierzu finden Sie unter Policys und Berechtigungen.
6. Die Anforderung wird von fünf Essbase-Administratoren genehmigt.

   Hinweis:

   Da die Gruppe "EssAdmins" über die implizite Berechtigung Teilnehmer (lesen) für das Hierarchieset verfügt, verfügt sie auch über die implizite Berechtigung Teilnehmer (lesen) für den Knotentyp. Die Gruppe kann eine Ansicht öffnen und das Hierarchieset durchsuchen, um die Anforderung zu genehmigen. Informationen hierzu finden Sie unter Policys und Berechtigungen.
7. Die Policy-Anforderungen sind erfüllt, und die Anforderung wird festgeschrieben.

Beispiel 5: Genehmigung mit aktivierter Anreicherung

Wenn die Anreicherung in einer Genehmigungs-Policy aktiviert wird, können Genehmiger mit dem Zugriff Teilnehmer (schreiben) auf ein beliebiges Datenobjekt in der Ansicht für die Anforderung vor der Genehmigung ändern.

In diesem Beispiel wird eine Anforderung in einer Verwaltungssicht mit Ansichtspunkten für drei Anwendungen gestellt: General Ledger, Planning und Consolidation. Jede Anwendung hat eine Genehmigungs-Policy auf Anwendungsebene, und für die GL- und Planning-Policys ist die Anreicherung aktiviert.

Genehmigungsworkflow:

1. Mark übermittelt eine Anforderung zum Hinzufügen einer Kostenstelle in der General Ledger-Anwendung.
2. Eine Genehmigungsanforderung wird an Josh, den HB-Administrator, gesendet.
3. Josh reichert die Anforderung an, indem er die Kostenstelle zur Planning-Anwendung hinzufügt und die Anforderung dann für die HB-Anwendung genehmigt.
4. Da Josh einen Knoten zur Planning-Anwendung hinzugefügt hat, wird die Planning-Genehmigungs-Policy aktiviert, und eine Genehmigungsanforderung wird an Julie gesendet, die Planning-Administratorin.
5. Julie reichert die Anforderung weiter an, indem sie die Kostenstelle zur Consolidation-Anwendung hinzufügt und die Anforderung dann für die Planning-Anwendung genehmigt.
6. Die Consolidation-Genehmigungs-Policy wird aktiviert, und eine Genehmigungsanforderung wird an die Buchhaltungsgruppe gesendet.
7. Barry, ein Mitglied der Buchhaltungsgruppe, genehmigt die Anforderung für die Consolidation-Anwendung. Da die Anreicherung in der Consolidation-Policy nicht aktiviert ist, kann Barry die Anforderung nicht weiter anreichern.
8. Wenn die Policy-Anforderungen aller Genehmigungs-Policys erfüllt sind, wird die Anforderung festgeschrieben, und die Kostenstelle wird zu allen drei Anforderungen hinzugefügt.