Open the menu

    Gerenciador de Projetos

    Permite o gerenciamento de projetos no portal.
    Projetos são entidades utilizadas para isolar dados no LumisXP.
    Cada projeto é composto por:
    Identificador
    É um identificador criado automaticamente ao se criar um novo projeto.
    Nome
    É um nome amigável para o projeto. Tipicamente, utilizado na administração para facilitar identificar os projetos.
    Canal
    É uma referência opcional para um canal do portal.
    Caso o projeto tenha uma referência para um canal, o seu identificador será adicionado automaticamente como uma area tag desse canal.
    Aqueles subcanais de um canal de um projeto, terão o mesmo projeto também adicionado a suas area tags. Porém, em um sub canal que tenha um projeto próprio, o projeto do canal pai não será herdado.

    Um exemplo


    Exemplo de estrutura com projetos
    Exemplo de estrutura com projetos


    Nesse exemplo, temos os seguintes canais:

    Portal

    É a raiz da estrutura. Possui um projeto associado e uma area tag definida. Dessa forma, ele possui as area tags (que seria o identificador do projeto ) e .


    Canal 1

    Filho do canal Portal. Está herdando a area tag e o projeto Projeto Portal. Possui as area tags Projeto Portal - id e AT-Portal.


    Canal 1.1

    Filho do Canal 1. Nesse canal, a opção "Herdar tags" está desmarcada. Assim, a area tag não estará aplicada nesse canal. E como esse canal não possui projeto próprio, ele herda o projeto do canal pai. Possui a area tag .


    Canal 2

    Filho do canal Portal. Está herdando a area tag . Como esse canal possui projeto próprio, ele não herda o projeto do canal pai. Possui as area tags (que seria o identificador de seu projeto ) e .


    Canal 2.1

    Filho do Canal 2. Nesse canal, a opção "Herdar tags" está desmarcada e ele define uma area tag própria . Como esse canal não possui projeto próprio, ele herda o projeto do canal pai. Possui as area tags e .



    O compartilhamento de dados nessa modelagem ficaria:
    Uma instância de serviço no canal Portal, teria acesso às áreas de compartilhamento e . Ou sejam uma instância no canal Portal poderia acessar dados dos seguintes canais:
    • Portal
    • Canal 1
    • Canal 1.1
    • Canal 2


    Uma instância de serviço no Canal 1, teria acesso às áreas de compartilhamento e . Ou sejam uma instância no Canal 1 poderia acessar dados dos seguintes canais:
    • Portal
    • Canal 1
    • Canal 1.1
    • Canal 2


    Uma instância de serviço no Canal 1.1, teria acesso à área de compartilhamento . Ou sejam uma instância no Canal 1 poderia acessar dados dos seguintes canais:
    • Portal
    • Canal 1
    • Canal 1.1


    Uma instância de serviço no Canal 2, teria acesso às áreas de compartilhamento e . Ou sejam uma instância no Canal 2 poderia acessar dados dos seguintes canais:
    • Portal
    • Canal 1
    • Canal 2
    • Canal 2.1


    Uma instância de serviço no Canal 2.1, teria acesso às áreas de compartilhamento e . Ou sejam uma instância no Canal 2.1 poderia acessar dados dos seguintes canais:
    • Canal 2
    • Canal 2.1


    Um isolamento mais simples

    Na maioria das situações, o projeto será utilizado para isolar os dados completamente. Com a mesma estrutura do exemplo anterior, suponha que deseja-se isolar os canais Canal 1 e Canal 2 completamente. Também deseja-se deixar o canal Portal isolado dos outros dois canais.

    Para isso, area tags explícitas não se fazem necessárias. Somente o uso de projetos é suficiente.
    Para tal, cria-se um projeto no canal Portal, um no Canal 1 e um no Canal 2:

    Exemplo simples de estrutura com projetos
    Exemplo simlpes de estrutura com projetos


    O compartilhamento de dados nessa modelagem ficaria:
    Uma instância de serviço no canal Portal, teria acesso à área de compartilhamento . Ou sejam uma instância no canal Portal poderia acessar dados dos seguintes canais:
    • Portal


    Uma instância de serviço no Canal 1, teria acesso à área de compartilhamento . Ou sejam uma instância no Canal 1 poderia acessar dados dos seguintes canais:
    • Canal 1
    • Canal 1.1


    Uma instância de serviço no Canal 1.1, teria acesso à área de compartilhamento . Ou sejam uma instância no Canal 1 poderia acessar dados dos seguintes canais:
    • Canal 1
    • Canal 1.1


    Uma instância de serviço no Canal 2, teria acesso à área de compartilhamento . Ou sejam uma instância no Canal 2 poderia acessar dados dos seguintes canais:
    • Canal 2
    • Canal 2.1


    Uma instância de serviço no Canal 2.1, teria acesso à área de compartilhamento . Ou sejam uma instância no Canal 2.1 poderia acessar dados dos seguintes canais:
    • Canal 2
    • Canal 2.1


    E porque não usar somente area tags?

    Todo esse isolamento apresentado nos exemplos acima poderia ser implementado usando somente area tags. Então porque utilizar projetos ao invés de area tags?

    A resposta está não no isolamento, mas sim no restante da história. As area tags são utilizadas para isolar, entre outras coisas, dados nos modos Análise de Dados e Segmentação de Usuários. O framework de monitoramento já está preparado para armazenar (e inferir) o identificador do projeto adequado nos eventos que ocorrem no LumisXP e nos usuários, de forma que esses possam ser filtrados adequadamente.
    A REST API de Monitoramento também está preparada para receber ou inferir o projeto a partir dos dados da coleta do evento.



    Projetos padrões

    Há dois projetos padrão pré cadastrados: System e Legacy. Esses dois projetos não podem ser excluídos nem alterados.

    O projeto System é utilizado por aqueles processos que não possuem relacionamento com nenhum item da estrutura do portal. Por exemplo, uma tarefa agendada que seja executada e que não possua nenhuma contextualização em relação à estrutura do portal, deve utilizar esse projeto nos eventos adicionados ao framework de monitoração. Para que esses dados sejam acessíveis, basta adicionar o identificador desse projeto (LUM_SYSTEM_PROJECT_ID) como uma area tag nas áreas que se deseja que possam acessar esses dados.

    O projeto Legacy é utilizado na migração de dados de eventos coletados de versões anteriores à versão 12.4.0 do LumisXP. Na atualização de uma versão anterior a essa, os dados dos eventos tem seu identificador do projeto preenchido. Aqueles eventos coletados que não puderam ter seu identificador de projeto inferido, receberão o identificador do projeto Legacy (LUM_LEGACY_PROJECT_ID).
    Dessa forma, caso se deseje deixar esses dados disponíveis, basta adicionar esse identificador como uma area tag naquela área que teria acesso a tais dados.

    Há um terceiro projeto criado durante a instalação associado ao canal Portal. Esse projeto tem o nome de Portal e pode ser alterado e/ou excluído.

    Permissionamento

    • Gerenciar instância de serviço: Permite gerenciar todos os dados dessa instância de serviço, incluindo apagar ele como todo.
    • Editar conteúdo de instância de serviço: Permite gerenciar todos os dados dessa instância de serviço com perfil de publicador.
    • Visualizar instância de serviço: Permite visualizar dados públicos dessa instância de serviço.