Exemplos de Política de Aprovação

Exemplo 1: Política de Aprovação no Nível de Aplicativo

Primeiramente, vamos observar um exemplo simples para mostrar como as aprovações funcionam em um nível básico. Neste exemplo, há uma política de aprovação no nível de aplicativo que declara que pelo menos duas pessoas do grupo Governo GL devem aprovar todas as alterações no plano de contas.

O grupo Governo GL consiste em Barry, Julie e Jane. Tom é o proprietário do aplicativo Fusion GL.

Workflow de aprovação:

1. Mark envia uma solicitação para adicionar uma conta e atualizar uma descrição do centro de custo.
2. Como o método de aprovação é paralelo, uma solicitação é enviada aos três membros do grupo Governo GL para aprovação.
3. Julie aprova a solicitação.
4. Barry aprova a solicitação.
5. Os requisitos da política são atendidos e a solicitação é confirmada.

Exemplo 2: Escalonamento de Deadlock

Agora, vamos observar o mesmo exemplo novamente, mas, desta vez, Barry e Jane foram transferidos do grupo Governo GL.

Somente Julie está no grupo Governo GL. Tom é o proprietário do aplicativo Fusion GL.

Workflow de aprovação:

1. Mark envia uma solicitação para adicionar uma conta e atualizar uma descrição do centro de custo.
2. Uma solicitação de aprovação é enviada à Julie.
3. Julie aprova a solicitação.

   Embora a política exija dois aprovadores do grupo Governo GL, Julie é a única pessoa nesse grupo. Uma vez que não há mais aprovadores disponíveis para atender aos requisitos da política, isso gera um deadlock. Consequentemente, a solicitação é escalonada para usuários que têm a permissão Gerente de Dados no aplicativo. Como Tom é o proprietário do aplicativo, a sua permissão Proprietário inclui a permissão Gerente de Dados.

4. A solicitação é escalonada para Tom.
5. Tom aprova a solicitação.
6. Os requisitos da política são atendidos e a solicitação é confirmada.

Exemplo 3: Política de Aprovação Serial no Nível de Dimensão

Em seguida, vamos observar uma política do tipo serial no nível de dimensão. Neste exemplo, Josh deve aprovar a solicitação, depois Frank e, por fim, alguém do grupo Contabilidade.

O grupo Contabilidade consiste em James e Heather.

Workflow de aprovação:

1. Mark envia uma solicitação para movimentar três contas.
2. Uma solicitação de aprovação é enviada a Josh.
3. Josh aprova a solicitação.
4. Uma solicitação de aprovação é enviada a Frank.
5. Frank aprova a solicitação.
6. As solicitações de aprovação são enviadas ao grupo Contabilidade (James e Heather).
7. Heather aprova a solicitação.
8. Os requisitos da política são atendidos e a solicitação é confirmada.

Exemplo 4: Política de Aprovação no Nível de Tipo de Nó e Conjunto de Hierarquias

Enquanto as políticas de aprovação no nível de aplicativo e dimensão são aplicadas a todas as ações de solicitação, as políticas no nível de tipo de nó e conjunto de hierarquias são aplicadas somente para ações de solicitação específicas. As políticas em um tipo de nó são aplicadas somente para solicitações que adicionam ou excluem nós, ou que atualizam as propriedades do nó. As políticas em um conjunto de hierarquias são aplicadas para solicitações que inserem, removem, movem ou reordenam nós em um conjunto de hierarquias, ou que atualizam as propriedades de relacionamento do nó.

Para ilustrar esses princípios, vamos observar duas solicitações para obter um exemplo que tem políticas no tipo de nó e no conjunto de hierarquias. A primeira solicitação atualiza uma propriedade de nó, de modo que somente a política no conjunto de nós é aplicada. A segunda solicitação adiciona contas, o que afeta o tipo de nó e o conjunto de hierarquias e, portanto, ambas as políticas são aplicadas.

Algumas informações adicionais sobre essas solicitações:

• O grupo Contabilidade consiste em James e Heather.
• O grupo TaxUsers consiste em Brian, Jane e Rachel.
• O grupo EssAdmins tem sete administradores (EssAdmin1 a EssAdmin7).

Primeiramente, vamos observar uma solicitação para atualizar propriedades do nó. As atualizações da propriedade do nó são afetadas por políticas apenas no tipo de nó.

Workflow da Aprovação para Solicitação 1:

1. Mark envia uma solicitação para atualizar três descrições de conta (atualização da propriedade do nó).
2. As solicitações de aprovação são enviadas aos grupos Contabilidade e TaxUsers.

   Nota:

   Como a atualização de uma propriedade do nó não afeta o conjunto de hierarquias, o grupo EssAdmins não obtém uma solicitação de aprovação.
3. James aprova a solicitação para o grupo Contabilidade.
4. Rachel aprova a solicitação para o grupo TaxUsers.
5. Os requisitos da política são atendidos e a solicitação é confirmada.

Em seguida, vamos observar uma segunda solicitação, desta vez, para adicionar nós. Como já foi dito, a política no tipo de nó é aplicada porque a ação de solicitação adiciona nós. Mas para essa solicitação, a política no conjunto de hierarquias também é aplicada, pois a adição de ações cria ações de inserção nos pontos de vistas baseados em hierarquia.

Workflow da Aprovação para Solicitação 2:

1. Mark envia uma solicitação para adicionar três novas contas.
2. As solicitações de aprovação são enviadas aos grupos Contabilidade e TaxUsers.
3. Como uma ação de adição em um ponto de vista baseado em hierarquia também cria ações de inserção no conjunto de hierarquias, as solicitações de aprovação também são enviadas ao grupo EssAdmins.
4. James aprova a solicitação para o grupo Contabilidade.

   Nota:

   Uma vez que James tem a permissão implícita Participante (Leitura) no tipo de nó, mas não no conjunto de hierarquias, ele deve aprovar a solicitação no Inspetor de Solicitação. Consulte Políticas e Permissões.
5. Rachel aprova a solicitação para o grupo TaxUsers.

   Nota:

   Uma vez que Rachel tem a permissão implícita Participante (Leitura) no tipo de nó, mas não no conjunto de hierarquias, ela deve aprovar a solicitação no Inspetor de Solicitação. Consulte Políticas e Permissões.
6. Cinco administradores do Essbase aprovam a solicitação.

   Nota:

   Como o grupo EssAdmins tem a permissão implícita Participante (Leitura) no conjunto de hierarquias, seus integrantes também recebem a permissão Participante (Leitura) implícita no tipo de nó. O grupo pode abrir uma exibição e procurar o conjunto de hierarquias para aprovar a solicitação. Consulte Políticas e Permissões.
7. Os requisitos da política são atendidos e a solicitação é confirmada.

Exemplo 5: Aprovação com Enriquecimento Ativado

Se o enriquecimento estiver ativado em uma política de aprovação, os aprovadores com acesso Participante (Gravação) em qualquer objeto de dados na exibição da solicitação poderão modificar a solicitação antes da aprovação.

Neste exemplo, é feita uma solicitação em uma exibição de manutenção com pontos de vista para três aplicativos: General Ledger, Planning e Consolidation. Cada aplicativo tem uma política de aprovação no nível do aplicativo, e as políticas do GL e do Planning estão com o enriquecimento habilitado.

Workflow de Aprovação:

1. Mark envia uma solicitação para adicionar um centro de custos ao aplicativo General Ledger.
2. Uma solicitação de aprovação é enviada a Josh, o administrador do GL.
3. Josh enriquece a solicitação adicionando o centro de custos ao aplicativo Planning e depois aprova-a para o aplicativo GL.
4. Como Josh adicionou um nó ao aplicativo Planning, a política de aprovação desse aplicativo está ativada, e uma solicitação de aprovação é enviada para Julie, a administradora do Planning.
5. Julie enriquece a solicitação adicionando o centro de custos ao aplicativo Consolidation e depois aprova-a para o aplicativo Planning.
6. A política de aprovação do Consolidation está ativada, e uma solicitação de aprovação é enviada para o grupo Contabilidade.
7. Barry, membro do grupo Contabilidade, aprova a solicitação para o aplicativo Consolidation. Como o enriquecimento não está ativado na política do Consolidation, Barry não consegue enriquecer a solicitação.
8. Depois que os requisitos de todas as políticas de aprovação forem atendidos, a solicitação será confirmada e o centro de custos será adicionado aos três aplicativos.