Esempi di criteri di approvazione

Esempio 1: criterio di approvazione a livello di applicazione

Analizziamo un semplice esempio per spiegare il funzionamento di base delle approvazioni. In questo esempio viene mostrato un criterio di approvazione a livello di applicazione che indica che almeno due persone del gruppo GL Govern devono approvare tutte le modifiche al piano dei conti.

Il gruppo GL Govern è composto da Barry, Julie e Jane. Tom è il proprietario dell'applicazione Fusion GL.

Flusso di lavoro di approvazione:

1. Mark sottomette una richiesta per aggiungere un conto e aggiornare la descrizione di un centro di costo.
2. Poiché il metodo di approvazione è parallelo, viene inviata una richiesta a tutti e tre i membri del gruppo GL Govern affinché la approvino.
3. Julie approva la richiesta.
4. Barry approva la richiesta.
5. I requisiti del criterio sono soddisfatti, pertanto viene eseguito il commit della richiesta.

Esempio 2: escalation di un deadlock

Analizziamo di nuovo lo stesso esempio, solo che stavolta Barry e Jane non sono più membri del gruppo GL Govern.

Il gruppo GL Govern è composto solo da Julie. Tom è il proprietario dell'applicazione Fusion GL.

Flusso di lavoro di approvazione:

1. Mark sottomette una richiesta per aggiungere un conto e aggiornare la descrizione di un centro di costo.
2. A Julie viene inviata una richiesta di approvazione.
3. Julie approva la richiesta.

   Sebbene il criterio richieda due approvatori del gruppo GL Govern, Julie è l'unica persona al suo interno. Poiché non sono disponibili altri approvatori per soddisfare i requisiti del criteri, viene generato un deadlock. Di conseguenza, la richiesta viene escalata agli utenti che dispongono dell'autorizzazione Gestione dati per l'applicazione. Poiché Tom è il proprietario dell'applicazione, la sua autorizzazione Proprietario include l'autorizzazione Gestione dati.

4. La richiesta viene escalata a Tom.
5. Tom approva la richiesta.
6. I requisiti del criterio sono soddisfatti, pertanto viene eseguito il commit della richiesta.

Esempio 3: criterio di approvazione seriale a livello di dimensione

Adesso diamo un'occhiata al criterio di tipo seriale a livello di dimensione. In questo esempio, la richiesta deve essere approvata prima da Josh, quindi da Frank e infine da qualcuno nel gruppo Accounting.

Il gruppo Accounting è composto da James e Heather.

Flusso di lavoro di approvazione:

1. Mark sottomette una richiesta per spostare tre conti.
2. A Josh viene inviata una richiesta di approvazione.
3. Josh approva la richiesta.
4. A Frank viene inviata una richiesta di approvazione.
5. Frank approva la richiesta.
6. Al gruppo Accounting (James e Heather) vengono inviate le richieste di approvazione.
7. Heather approva la richiesta.
8. I requisiti del criterio sono soddisfatti, pertanto viene eseguito il commit della richiesta.

Esempio 4: criterio di approvazione a livello di tipo di nodo e set di gerarchie

Mentre i criteri di approvazione a livello di applicazione e dimensione vengono applicati a tutte le azioni della richiesta, i criteri a livello di tipo di nodo e set di gerarchie vengono applicati solo per azioni specifiche della richiesta. I criteri per un tipo di nodo vengono applicati solo per le richieste che prevedono azioni di aggiunta o eliminazione dei nodi oppure l'aggiornamento delle proprietà del nodo. I criteri per un set di gerarchie vengono applicati dopo le richieste che prevedono azioni di inserimento, rimozione, spostamento o riordinamento dei nodi in un set di gerarchie o oppure l'aggiornamento delle proprietà delle relazioni dei nodi.

Per descrivere questi principi, esaminiamo due richieste di un esempio con criteri sia per il tipo di nodo che per il set di gerarchie. La prima richiesta aggiorna una proprietà del nodo, perciò viene applicato solo il criterio per il set di nodi. La seconda richiesta aggiunge conti, il che interessa sia il tipo di nodo che il set di gerarchie, pertanto vengono applicati entrambi i criteri.

Alcune informazioni aggiuntive su queste richieste:

• Il gruppo Accounting è composto da James e Heather.
• Il gruppo TaxUsers è composto da Brian, Jane e Rachel.
• Il gruppo EssAdmins comprende sette amministratori (da EssAdmin1 a EssAdmin7).

Analizziamo per prima una richiesta di aggiornamento delle proprietà del nodo. Gli aggiornamenti delle proprietà dei nodi sono interessati solo dai criteri per il tipo di nodo.

Flusso di lavoro di approvazione per la richiesta 1:

1. Mark sottomette una richiesta per aggiornare la descrizione di tre conti (aggiornamento delle proprietà del nodo).
2. Ai gruppi Accounting e TaxUsers vengono inviate le richieste di approvazione.

   Nota:

   Poiché un aggiornamento delle proprietà del nodo non interessa il set di gerarchie, il gruppo EssAdmins non riceve alcune richiesta di approvazione.
3. James approva la richiesta per il gruppo Accounting.
4. Rachel approva la richiesta per il gruppo TaxUsers.
5. I requisiti del criterio sono soddisfatti, pertanto viene eseguito il commit della richiesta.

Adesso diamo un'occhiata alla seconda richiesta, questa volta per aggiungere i nodi. Come nel caso precedente, il criterio per il tipo di nodo viene applicato perché l'azione della richiesta prevede l'aggiunta di nodi. Per questa richiesta, però, viene applicato anche il criterio nel set di gerarchie poiché le azioni di aggiunta creano azione di inserimento nelle angolazioni vista basate su gerarchia.

Flusso di lavoro di approvazione per la richiesta 2:

1. Mark sottomette una richiesta per aggiungere tre nuovi conti.
2. Ai gruppi Accounting e TaxUsers vengono inviate le richieste di approvazione.
3. Poiché un'azione di aggiunta in un'angolazione vista basata su gerarchia crea anche azioni di inserimento nel set di gerarchie, le richieste di approvazione vengono inviate anche al gruppo EssAdmins.
4. James approva la richiesta per il gruppo Accounting.

   Nota:

   Poiché James dispone dell'autorizzazione implicita Partecipante (lettura) per il tipo di nodo, ma non per il set di gerarchie, deve approvare la richiesta nell'inspector delle richieste. Fare riferimento a Criteri e autorizzazioni.
5. Rachel approva la richiesta per il gruppo TaxUsers.

   Nota:

   Poiché Rachel dispone dell'autorizzazione implicita Partecipante (lettura) per il tipo di nodo, ma non per il set di gerarchie, deve approvare la richiesta nell'inspector delle richieste. Fare riferimento alla sezione Criteri e autorizzazioni.
6. Cinque amministratori Essbase approvano la richiesta.

   Nota:

   Poiché il gruppo EssAdmins dispone dell'autorizzazione implicita Partecipante (lettura) per il set di gerarchie, gli verrà concessa anche l'autorizzazione implicita Partecipante (lettura) per il tipo di nodo. Possono aprire la vista e sfogliare il set di gerarchie per approvare la richiesta. Fare riferimento alla sezione Criteri e autorizzazioni.
7. I requisiti del criterio sono soddisfatti, pertanto viene eseguito il commit della richiesta.

Esempio 5: approvazione con arricchimento abilitato

Se l'arricchimento è abilitato in un criterio di approvazione, gli approvatori con accesso di tipo Partecipante (scrittura) a qualsiasi oggetto dati nella vista per la richiesta potranno modificare la richiesta prima dell'approvazione.

In questo esempio viene effettuata una richiesta in una vista di manutenzione con angolazioni vista per tre applicazioni: General Ledger, Planning, e Consolidamento. Ogni applicazione ha un criterio di approvazione a livello di applicazione e l'arricchimento è abilitato per i criteri GL e Planning.

Flusso di lavoro di approvazione:

1. Mark sottomette una richiesta per aggiungere un centro di costo nell'applicazione General Ledger.
2. Una richiesta di approvazione viene inviata a Josh, l'amministratore GL.
3. Josh arricchisce la richiesta aggiungendo il centro di costo all'applicazione Planning e quindi approva la richiesta per l'applicazione GL.
4. Poiché Josh ha aggiunto un nodo all'applicazione Planning, il criterio di approvazione di Planning viene attivato e una richiesta di approvazione viene inviata a Julie, l'amministratore di Planning.
5. Julie arricchisce ulteriormente la richiesta aggiungendo il centro di costo all'applicazione di consolidamento e quindi approva la richiesta per l'applicazione Planning.
6. Il criterio di approvazione di consolidamento viene attivato e una richiesta di approvazione viene inviata al gruppo Contabilità.
7. Barry, un membro del gruppo Contabilità, approva la richiesta per l'applicazione di consolidamento. Poiché l'arricchimento non è abilitato nel criterio di consolidamento, Barry non può arricchire ulteriormente la richiesta.
8. Quando vengono soddisfatti i requisiti di tutti i criteri di approvazione, viene eseguito il commit della richiesta e il centro di costo viene aggiunto a tutte e tre le applicazioni.