Recomendações
Recomendamos que atualização da solução Senior seja realizada por um profissional credenciado e com conhecimento das ferramentas. Desta maneira antes de iniciar o processo, verifique se todos os pré-requisitos, gerais e por produto, foram atendidos e se estão disponíveis todas as informações necessárias para realizar esse procedimento.
Em caso de dúvidas, a Senior disponibiliza o serviço de gestão de Tecnologia da Informação, que oferece apoio à organização, montagem e execução da solução de infraestrutura.
Importante
- A Senior não recomenda e nem se responsabiliza caso sejam utilizados outros aplicativos que não sejam os disponibilizados e indicados nesta documentação para efetuar a atualização.
- Recomendados que antes de realizar uma atualização, seja feita uma consistência de base para evitar erros durante o processo.
Melhores práticas para evitar problemas e corrompimentos de regras durante processos de atualização ou modificação do sistema
Para que não haja corrompimento de regras LSP, que possam ocasionar erros diversos em rotinas que utilizam as regras após a atualização, como por exemplo: Não foi possível carregar o binário das regras e Regra XX: Erro de sintaxe, o Caractere X é inválido, existem melhores práticas que devem ser atendidas, as quais serão descritas a seguir.
Pré-requisitos para que não haja corrompimento das regras
- Desconectar todos os usuários que estão conectados no sistema e na base.
Para verificar se existem usuários conectados na base de dados, verifique as informações presentes no artigo ERP - Proprietária - Como verificar as conexões de usuários ativas na base do sistema e as licenças que estão sendo consumidas por cada usuário. - Parar todo e qualquer serviço que esteja conectado à base de dados do sistema que está sendo atualizado ou modificado.
Exemplos de serviços que devem ser paralisados: SeniorMiddleware, Serviço de Informação da Instalação, Senior Integrador (ETL), AppManager (que instância ERP_Service) e Integrador Wiipo.
Os pré-requisitos indicados acima devem ser respeitados para as seguintes operações:
- Atualização de versão;
- Aplicação de BPLs/Alfas ou qualquer arquivo que modifique o sistema;
- Operações realizadas dentro do CBDS como: consistência de base, personalização de base e recriação de objetos (triggers, procedures, views e tabelas).
Importante
Caso o sistema esteja disponibilizado em ambiente Cloud Senior, a equipe de IT Services da Senior é responsável pela atualização dos componentes e aplicação de modificações no ambiente e seguirá esses pré-requisitos.
Agora se o sistema for disponibilizado no ambiente Cloud Senior e tenha acesso para realização de operações no CBDS citadas anteriormente, é importante ficar atento aos pré-requisitos também, pois precisará alinhar junto com a equipe de IT Services o atendimento dos pré-requisitos, como por exemplo, parada de Serviços do ambiente, afim de evitar problemas com as regras LSP.
Backup e restauração das regras LSP
Como boa prática, é recomendado que seja realizado o backup das regras LSP antes que grandes alterações sejam realizadas no sistema. Exemplo: atualização da versão.
As regras serão disponibilizadas no diretório configurado na Central de Configuração Senior (SeniorConfigCenter).
Caso ocorra alguma falha no processo que ocasione o corrompimento de um ou mais arquivos de regras LSP, o backup poderá ser retornado para a mesma pasta, e as regras poderão ser recompiladas novamente.
Ativação de Logs para compilação das regras
Como um ponto adicional de análise de eventual situação envolvendo a compilação de regras, seja corrompimento ou qualquer outro incidente, existe a possibilidade de utilização da rotina de Log de compilação das regras. Para maiores informações, verifique a documentação dessa funcionalidade.
Restore de backup
Em casos de problemas durante a atualização de um ambiente com as soluções, é essencial que seja realizado o restore do backup da base de dados e arquivos do ambiente que apresentou problemas. Em decorrência da criticidade dessas ações, é recomendável que o backup sempre seja realizado antes de iniciar qualquer alteração no ambiente em produção.
Para realizar backup do ambiente do Portal Corporativo, é necessário verificar as configurações do arquivo <domínio>/applications/liferay-portal-6.1.1/WEB-INF/classes/portal-ext.properties e realizar o backup das pastas correspondentes às seguintes propriedades:
- resource.repositories.root;
- liferay.home;
- lucene.dir;
- jcr.jackrabbit.repository.root;
- dl.hook.file.system.root.dir;
- jdbc.default.jndi.name=jdbc/LiferayPool:
- caso esta esteja comentada, com o caractere #, realize o backup da base configurada ou da pasta de acordo com as propriedades abaixo.
- jdbc.default.driverClassName;
- jdbc.default.url;
- jdbc.default.username;
- jdbc.default.password.
- caso não esteja comentada, somente realize o backup da base configurada no GlassFish. Para isso, pode-se consultar a documentação referente à configuração da conexão JDBC.
- caso esta esteja comentada, com o caractere #, realize o backup da base configurada ou da pasta de acordo com as propriedades abaixo.
Em versões mais antigas o diretório será: <domínio>\applications\autodeploy\liferay-portal-6.1.1\WEB-INF\classes\.
Nota
Verifique também os diretórios referentes as seguintes propriedades:
com.sun.aas.instanceRoot = Pasta do domínio;
com.sun.aas.installRoot = Pasta de instalação do GlassFish;
con.sun.aas.javaRoot = pasta do Java.
Caso a pasta de domínio do Portal possua customizações, esta deverá ser copiada para o novo domínio do GlassFish. Caso contrário, pode ser realizada uma atualização apontando para o novo domínio do GlassFish e o Portal será inserido neste domínio, exceto o Liferay-Portal, que deve ser deployado e configurado conforme as documentações sobre a Instalação do Portal - ambiente GlassFish 3 ou superior/Liferay 6, configuração da conexão JDBC e Configurações Gerais.
Também deve ser realizado um backup do diretório dos arquivos das páginas HTMLs de cada aplicação. O diretório pode ser consultado em Central de Configurações Senior > Middleware > Web 5.0 > Aplicativos, no campo Diretório dos arquivos das páginas HTML.
Descontinuidade do Modo Compatibilidade
A partir da versão 5.8.7, os aplicativos do modo de compatibilidade do Middleware, conversor do Middleware e o de instalações da versão 5.6.5 ou inferior, foram descontinuados.
Lista de aplicativos descontinuados:
- GMS.exe, SGA.exe, SGAsrv.exe, MDConfig.exe, GMSDebug.exe, SGADebug.exe
- caseappsv.exe, caseview.exe, HTTPWizard.exe
- SeniorConverter.exe, SeniorConvertInfo.exe
- conector.exe, conector.tgz
Procedimentos de atualização
Os procedimentos de atualização se aplicam aos clientes com versão 5.6.5 ou inferior e aos que utilizam o Middleware em modo compatibilidade (GMS e/ou CASE).
Atualização de versão 5.6.5 ou inferior: caso utilize uma versão 5.6.5 ou inferior, é necessário migrar para a versão 5.8.6, respeitando as dependências entre as versões, antes de atualizar para uma versão 5.8.7 ou superior.
Atualização de ambientes com Middleware em modo compatibilidade: caso utilize uma versão entre 5.7.1 e 5.8.6 e ainda utilize o Middleware em modo compatibilidade, é necessário realizar uma conversão para o novo Middleware(SeniorMiddleware.exe) antes de atualizar para uma versão 5.8.7 ou superior.
Para fazer esta conversão é possível utilizar o Conversor (SeniorConverter.exe) da mídia da versão utilizada. Caso a mídia não esteja mais disponível, atualize para a versão 5.8.6, faça a conversão para o novo Middleware e depois atualize para a versão desejada.
Particularidades por produto
E uma versão cliente-servidor do sistema Gestão de Pessoas | HCM, caso esteja em uma versão igual ou anterior à 5.6.5 do Instalador, é necessário primeiramente atualizar o sistema para a versão 5.8.6 e depois para versão desejada. Caso esteja a partir da 5.7.2, atualize para a versão 5.8.6 e depois para a versão mais recente do sistema.
Atualização de produtos com versões diferentes
Caso desejar manter as soluções que possui em versões diferentes, ou seja utiliza o Instalador com uma versão diferente, a sua instalação deve ser feita separadamente. Este processo é necessário para que não existam quebra de protocolo entre Middleware e instâncias, ou chaves de configuração.
Exemplo:
- Gestão de Pessoas | HCM 6.10.4 (Instalador 5.10.4);
- Gestão Empresarial | ERP: 5.10.4 (Instalador 5.10.4).