Publicação e acesso aos Portais

O painel Publicação reúne releases, estado de publicação e permissões do Portal. As operações mostradas dependem da permissão individual, do papel no Projeto e das funcionalidades configuradas pelo administrador da plataforma.

Preparar uma release

Antes da publicação:

1. salvar todas as alterações;
2. executar Valida e corrigir os erros;
3. testar o rascunho com Preview;
4. selecionar Publicar para abrir o painel;
5. criar uma Nova build release.

A release é uma cópia imutável da revisão verificada. Alterar posteriormente o rascunho não altera as releases já criadas.

Compreender e gerir artefactos

Cada build bem-sucedida produz um artefacto: o documento HTML executável do Portal, completo de layout, estilos compilados e runtime dos widgets. Ao documento está associado um manifesto que lista revisão de fonte, tamanho, capability e dependências utilizadas.

O valor hexadecimal mostrado após a build é o hash SHA-256 do conteúdo. Não é uma senha nem um código a inserir noutro lado: identifica de forma única o artefacto e permite ao Sybot verificar a sua integridade.

No painel Publicação → Build e artefactos é possível:

• consultar build preview e releases com estado e revisão;
• abrir Detalhes para ler hash completo, tamanho, manifesto e diagnóstico;
• usar Abrir artefacto para inspecionar o documento gerado;
• cancelar uma build ainda na fila ou em execução.

Os artefactos bem-sucedidos não são apagados manualmente pelo editor: uma release pode depender exactamente desse conteúdo imutável. A gestão ordinária ocorre através de aprovação, deploy, revogação e rollback das releases.

Um Publisher ou Owner pode aprovar uma release bem-sucedida. A aprovação não altera o rascunho e torna a release seleccionável para publicação nas destinações já disponibilizadas. O estado é actualizado sem recarregar a página.

Se nenhuma destinação estiver disponível, contactar o proprietário do Projeto ou o administrador da plataforma. Não tente reutilizar uma destinação que pertença a outro Projeto.

Publicar no primeiro destino

1. aprovar a release criada;
2. como Owner do Portal e do Projeto, criar o destino com a origem exata, por exemplo https://portals.example.com, sem caminho;
3. se a release contiver Power BI App owns data, abrir Gerir perfis e relatórios, criar um endpoint para o destino ou para o fallback do respetivo ambiente e executar Diagnóstico até ao estado verificado;
4. selecionar a release aprovada e o destino e iniciar Deploy;
5. aguardar o estado ativo e usar Abrir para testar o Portal.

Produção e pré-produção exigem HTTPS. HTTP está disponível apenas para um destino de desenvolvimento em localhost. Se uma build for concluída com sucesso mas o painel não atualizar, use Atualizar e verifique a lista antes de criar outra release.

Se a release usar Qlik OAuth impersonation, o perfil e endpoint também devem ter diagnóstico positivo. Para um destino Agent remoto, o administrador deve ter preparado a máquina: após o deployment, o estado permanece A aguardar Agent até a release ser verificada e ativada. A versão anterior continua disponível. Consulte Integrações governadas.

O que esperar de um destino Agent remoto

Ao usar Abrir, o runtime remoto pode redirecionar para a página de acesso da instalação Sybot proprietária do Portal. Após a autenticação, o navegador volta automaticamente ao Portal; não é necessária uma segunda configuração no editor.

O layout, os estilos e o conteúdo estático provêm da release ativada no destino. Os widgets que usam dados, Vistas de Utilizador, Workflows, BPMN, Power BI ou Qlik continuam a aplicar em tempo real as permissões e a configuração da instalação Sybot proprietária. Por isso podem ficar temporariamente indisponíveis quando a plataforma não está acessível, mesmo que a parte estática do Portal já esteja visível.

Verificar a publicação

Durante a activação o painel mostra o estado actual. Quando a operação está concluída aparece Abrir, que permite testar o Portal com os mesmos controles de acesso aplicados aos utilizadores finais.

Num destino remoto, Último contacto do Agent confirma que o Agent comunicou com o Sybot. Isto não substitui o teste dos widgets dinâmicos.

Durante a validação, compare a posição, a largura e a altura dos widgets com a Pré-visualização da mesma revisão. A geometria faz parte do artefacto imutável: após uma actualização que altere a apresentação do Portal, crie uma nova build e uma nova release; voltar a implementar a mesma release não a recompila.

Uma publicação não bem-sucedida não substitui a versão já activa. Ler a mensagem mostrada, corrigir a causa indicada e repetir a operação com uma release válida.

Quando está disponível uma versão anterior, o Publisher pode usar Rollback para reactivá-la sem alterar ou reconstruir o rascunho actual.

Gerir colaboradores e audiência

O Owner encontra no painel Acesso duas áreas:

• Colaboradores, para atribuir ou revogar a permissão individual dos membros do Projeto;
• Audiência runtime, para autorizar os papéis de aplicação que podem abrir o Portal publicado.

A audiência não substitui a pertença ao Projeto. A remoção de um membro, a revogação da permissão ou a remoção do papel da audiência impede as aberturas subsequentes não mais autorizadas.

Resolução de problemas

• A build não inicia ou fica em espera: actualizar o painel e, se o estado não mudar, comunicar a mensagem ao administrador.
• A release não é aprovável: verificar se tem permissão Publisher ou Owner e se a build foi bem-sucedida.
• O Portal publicado não abre: verificar pertença ao Projeto, permissão ou audiência e estado activo.
• O destino remoto regressa repetidamente à página de acesso: feche os separadores obsoletos, volte a abrir o Portal com Abrir e comunique o ciclo ao administrador se continuar, sem partilhar links de autenticação.
• O destino remoto abre, mas os widgets dinâmicos não respondem: verifique se a plataforma Sybot está acessível; o conteúdo estático visível não confirma por si só a disponibilidade de dados e integrações.
• Os widgets publicados aparecem comprimidos ou fora da grelha: criar uma nova build e uma nova release com a versão actual e implementá-la; voltar a implementar a release anterior mantém o artefacto antigo.
• Dados ou Workflow são negados: verificar se o objecto ligado ainda está acessível e se a release utiliza uma configuração actual.
• O deployment com Power BI está bloqueado: verificar se cada associação e variante App owns data tem um endpoint ativo e diagnosticado para o destino ou para o respetivo ambiente.
• Aparece um identificador de diagnóstico: copiá-lo sem adicionar dados confidenciais e fornecê-lo ao suporte.