Novo Gestor de Stored Procedures – CFGX051M

O programa Gerenciador de procedures (antigo CFGX051.PRW, atual CFGX051M.PRW), do módulo Configurador (SIGACFG) passou por uma mudança significativa.
Uma das principais mudanças, além da interface totalmente remodelada, é o fato de não mais existirem os arquivos de pacotes com extensão SPS. Estes arquivos foram substituídos por arquivos de extensão ZSPS, que estarão embarcados no RPO. A atualização destes arquivos ocorrerá de maneira semelhante à atualização de qualquer artefato, ou seja, através de patchs de atualizações expedidos pela TOTVS.
Outra grande mudança é a integração com a Central de Atualizações para obtenção dos pacotes de procedures mais recentes homologados. Esta integração ocorrerá de maneira transparente visando facilitar o processo de atualização das procedures no ambiente. 

Migração para o novo modelo

Para preparar o ambiente e realizar a migração, tenha certeza de executar os seguintes passos:

Passo 1: Aplique a última release da Central de Atualizações. Para isso acesse a página de Release Notes e baixe o patch mais recente disponibilizado.

Passo 2: Aplique os patchs de Expedições Contínuas dos módulos relacionados abaixo para atualizar o RPO com os pacotes ZSPS e também as rotinas vinculadas aos processo.

Passo 3: Acesse o programa Gerenciador de procedures, através do menu Base de Dados | Dicionário | Stored Procedure. Será apresentada a seguinte interface:

As opções disponíveis são:

• Documentação: ao clicar neste botão o usuário será levado para esta documentação.
• Manter: ao clicar neste botão a rotina atual, sem as novas funcionalidades, será exibida. É importante lembrar que o modelo antigo não sofrerá nenhuma atualização, isto é, não serão expedidas atualizações em arquivos SPS, somente no novo formato ZSPS.
• Atualizar: ao clicar neste botão, ocorrerá o processo de migração. Serão realizados procedimentos que não poderão ser desfeitos, ou seja, após migrado não será possível voltar ao modelo antigo de gestão de procedures. Após realizada a migração para o novo modelo essa interface de migração não será exibida novamente.
• Fechar: a rotina não será acionada, retornando ao menu da janela principal do Protheus.

Passo 4: Clique no botão Atualizar. O processo de migração se inicia e ao ser concluído a nova interface será apresentada.

Nova interface

A principal mudança na interface será a apresentação das empresas disponíveis no ambiente e todos os processos existentes para gerenciamento ao mesmo tempo, em uma mesma janela. Não haverá necessidade de mudança de empresa para a visualização dos seus processos.

A interface possui novos botões laterais que permitem o gerenciamento dos processos de maneira prática e rápida, realizando a instalação e remoção com poucos cliques. Consulta e relatório de log de processamento e configurações adicionais também estão disponíveis. Novas abas permitem uma navegação mais simples e eficiente para visualizar os processos e empresas. Os totalizadores fornecem, de forma rápida, um resumo dos status dos processos.

Entendendo as informações exibidas no título da interface:

- Título da interface. A rotina Gestão de Procedures (programa CFGX051M.PRW) também é chamada de instalador de pacotes de procedures.

- É a data e hora do programa CFGX051M.PRW compilado no RPO em uso. Este valor será atualizado sempre que uma nova versão do programa for aplicada no RPO através de patchs de atualização.

- É a assinatura da rotina de Gestão de Procedures. Esta assinatura é utilizada para garantir que a versão do instalador seja compatível com os pacotes ZSPS utilizados para instalação de processos. Esta assinatura será atualizada (incrementada) conforme a evolução da rotina de instalação. Se o instalador não possuir a assinatura mínima exigida pelo pacote ZSPS, durante a instalação será armazenado no log de operações uma mensagem informando a existência de um problema de incompatibilidade entre o pacote ZSPS e o instalador. Nestes casos será necessário atualizar o instalador seguindo as orientações contidas no próprio log. 

- É a release da Central de Atualizações atualmente encontrada no ambiente em uso. Essa informação não determina que a Central de Atualizações está configurada no ambiente, ela apenas mostra a versão dos programas de Gestão de Procedures que por sua vez estão diretamente ligados à Central de Atualizações. 

- A sigla TPH refere-se à Central de Atualizações. Pode apresentar dois valores: TPH: ON quando há conectividade, ou TPH: OFF quando não há conectividade com a Central de Atualizações. Neste caso a ausência pode ser temporária, ou seja, algum problema ocorreu durante a inicialização da interface, ou definitiva quando não há realmente nenhuma configuração no ambiente que possibilite o uso da Central de Atualizações.

Relação de empresas

Aqui serão listadas todas as empresas disponíveis no ambiente. Não há necessidade de entrar no ambiente utilizando a empresa para a qual se deseja instalar/desinstalar um processo.
Será possível marcar mais de uma empresa e realizar a ação desejada de uma só vez.

As ações disponíveis nos botões da barra lateral são:

• Instalar os pacotes selecionados nas empresas selecionadas.
• Remover os pacotes selecionados das empresas selecionadas.
• Marcar todas as empresas disponíveis no grid.
• Desmarcar todas as empresas do grid.
• Consultar o histórico de operações.
• Configurações adicionais da rotina.
• Link para a documentação oficial da rotina (esta página).

Relação de processos

Serão listados todos os processos disponíveis para instalação.

As ações disponíveis nos botões da barra lateral são:

• Marcar todos os processos disponíveis no grid.
• Desmarcar todos os processos do grid.
  
  

Guia Empresa vs Processos

A visão disponibilizada nesta guia baseia-se na navegação realizada entre as empresas disponíveis na relação de empresas.

A parte superior apresentará o nome da empresa posicionada, além dos totalizadores de cada um dos possíveis status.
Na parte inferior estarão relacionados todos os processos disponíveis e seus respectivos status na empresa posicionada.

Guia Processo vs Empresas

A visão disponibilizada nesta guia baseia-se na navegação realizada entre os processos disponíveis na relação de processos.

A parte superior apresentará o nome do processo posicionado, além dos totalizadores de cada um dos possíveis status.
Na parte inferior estarão relacionadas todas as empresas disponíveis e seus respectivos status perante o processo posicionado.

LEGENDA

Indica que o processo está atualizado.

Indica que o processo está desatualizado.

Indica que não foi possível avaliar o status do processo.

Indica que o processo não está instalado.

Indica que o processo e a rotina AdvPL possuem assinaturas incompatíveis.

Visualizando detalhes

Ao efetuar um duplo clique no grid, onde estão relacionados os processos e empresas e seus respectivos status, será exibida uma interface contendo detalhes sobre o item selecionado.

As seções apresentadas são:

Seção Detalhes:

Apresenta informações detalhadas sobre o ambiente:

• Status da integração com a Central de Atualizações (sigla TPH):
  • ON (modo online) quando conectividade está ativa ou
  • OFF (modo offline) quando não há conectividade;
• Código da empresa;
• Nome da empresa;
• Código do processo;
• Nome do processo;
• Release da Central de Atualizações do ambiente;

Seção Processo:

Apresenta informações detalhadas do processo:

• Status do processo;
• Assinatura do processo instalado (em destaque para facilitar a visualização);
• No campo Instalado: apresentará o IDSPS (identificador único do pacote), Data e hora do pacote ZSPS usado na instalação e sua assinatura;
• No campo RPO: apresentará o IDSPS (identificador único do pacote), data e hora do pacote ZSPS contido no RPO e sua assinatura;
• No campo TPH: apresentará o IDSPS (identificador único do pacote), data e hora do pacote ZSPS disponível na Central de Atualizações e sua assinatura.

Seção Rotina:

Apresenta informações detalhadas do rotina AdvPL associada ao processo:

• Status;
• Assinatura da rotina AdvPL;
• Nome da rotina/programa fonte;
• Data e hora da rotina contida no RPO;
• Data e hora da rotina disponível na Central de Atualizações;
• Botão Buscar atualização: direciona para o portal de atualização, para obtenção do patch contendo a rotina em questão. Botão disponível apenas se houver integração com a Central de Atualizações (modo online).

Seção Gestão de Procedures:

Apresenta informações detalhadas da interface de Gestão de Procedures (CFGX051M):

• Status;
• Assinatura da rotina AdvPL de gestão de procedures;
• Nome da rotina/programa fonte;
• Data e hora da rotina contida no RPO;
• Data e hora da rotina disponível na Central de Atualizações;
• Botão Buscar atualização: direciona para o portal de atualização, para obtenção do patch contendo a rotina em questão. Botão disponível apenas se houver integração com a Central de Atualizações (modo online).

Entendendo os status dos processos e ações que podem ser realizadas

A nova interface exibe uma série de ícones para representar os status possíveis para os processos. Aqui estão relacionados os possíveis status e as ações que podem ser tomadas para cada situação.

ATUALIZADO: O processo instalado no ambiente está atualizado com a última versão disponível em comparação ao pacote que está no RPO (modo offline) ou em relação ao pacote disponível na Central de Atualizações (modo online).

Solução:

Nenhuma ação é necessária neste caso.

DESATUALIZADO: O processo instalado no ambiente não está na sua versão mais recente disponibilizada pela TOTVS. Isso significa apenas que o IDSPS do pacote instalado é inferior ao IDSPS do último pacote homologado. Um pacote que está desatualizado não representa um erro e sua atualização não é obrigatória ou urgente. Um pacote de procedures com este status pode perfeitamente ser executado por sua rotina AdvPL.

Ao encontrarmos processos com este status, devemos considerar:

Em ambientes online: A comparação é realizada com os pacotes disponíveis na Central de Atualizações. Vamos pegar como exemplo um processo desatualizado onde o IDSPS instalado é inferior ao IDSPS disponível na Central de Atualizações:

Exemplo de processo desatualizado:

Visualizando os detalhes do processo:

Note que o IDSPS do processo instalado (7) é inferior ao IDSPS do processo mais recente disponível na Central de Atualizações (691). Por este motivo o status do processo fica Desatualizado. Isto ocorre pois o processo recém homologado fica disponível para uso imediatamente à sua publicação e a ferramenta faz a leitura em tempo real, sem que nenhum patch seja aplicado no ambiente.

Em ambientes offline: A comparação é realizada com os pacotes embarcados no RPO. Vamos pegar como exemplo um processo desatualizado onde o IDSPS instalado é inferior ao IDSPS disponível no RPO:

Visualizando os detalhes do processo:

Isso pode ocorrer após a aplicação de algum patch (.PTM) contendo o pacote ZSPS mais atual. Nesta situação, como o IDSPS do processo instalado (13) é inferior ao IDSPS do processo disponível no RPO (647), o status do processo é Desatualizado.

Solução: ATUALIZAR O PROCESSO

Não será necessário obter nenhum arquivo adicional, nem realizar a aplicação de patchs de atualizações (.PTM). A própria rotina de Gestão de Procedures se encarregará de obter o pacote mais recente disponível (da Central de Atualizações para ambientes online ou do próprio RPO para ambientes offline) e realizará a instalação no ambiente. O status do processo após a instalação será alterado para Atualizado. 

Caso o processo esteja funcionando corretamente em seu ambiente, não há motivos para atualizá-lo com urgência. Avalie também a atualização da rotina AdvPL associada ao processo. Programe o melhor momento para realizar esta atualização já que, caso seja necessária, a atualização da rotina deve ser efetuada primeiro por meio do patch indicado e somente então o processo poderá ser atualizado.

NÃO AVALIADO: Neste caso o processo instalado no ambiente não pôde ser comparado com o que está embarcado no RPO (modo offline) nem com o que está disponível na Central de Atualizações (modo online). Este status é muito peculiar e não ocorrerá com frequência, exceto nas seguintes situações:

• Caso a conectividade entre a aplicação e a Central de Atualizações seja interrompida ou inexistente no ambiente durante a análise realizada pela ferramenta e
• Quando não existe nenhum arquivo de pacote de procedures embarcado no RPO (arquivos .ZSPS)

Peguemos como exemplo um processo nesta situação:

Ao analisarmos os detalhes do processo, veremos:

No exemplo acima, constatamos que não há informações sobre o pacote no RPO. Isso significa que não existe o arquivo ZSPS do processo em questão de forma embarcada. Isso pode acontecer, por exemplo, se:

• 
  
  • Não foi aplicado nenhum patch (.PTM) contendo os pacotes de procedures;
  • O arquivo ZSPS foi deletado do RPO;

Também constatamos que não há informações sobre o pacote na Central de Atualizações. O campo TPH (referente à Central de Atualizações) nem ao menos foi exibido na janela de detalhes. Isso significa que no momento em que a rotina foi executada a conectividade entre a aplicação e a Central de Atualizações foi interrompida ou é inexistente no ambiente em questão. Por estes motivos o status do processo será Não avaliado. 

Solução:

A solução neste caso envolve:

• 
  
  • Checagem da conectividade entre a aplicação e a Central de Atualizações;
  • Aplicação de patch (.PTM) contendo o pacote ZSPS do processo em questão;

Após certificar de que o ambiente está normalizado, a reabertura da interface se faz necessária para que o status do processo seja novamente analisado. Não é necessário realizar a instalação/atualização do processo. 

NÃO INSTALADO: Um processo não instalado não representa uma anormalidade ou um erro. A instalação ou não do processo deve seguir as necessidades de cada ambiente onde a responsabilidade é dividida entre o administrador do sistema e as equipes que farão uso daquele processo. As rotinas Protheus associadas aos processos (ver o tópico Visualizando detalhes) funcionam normalmente sem que os processos estejam instalados no ambiente, porém o desempenho delas não é o mesmo se comparado ao desempenho das stored procedures.

INCOMPATÍVEL: Nesta situação as assinaturas do processo e da rotina AdvPL  são incompatíveis. Isso significa que a rotina AdvPL que faz a chamada para as procedures não poderá utilizá-las. Ao tentar executar uma rotina que esteja incompatível com seu processo de stored procedures, o usuário receberá a seguinte mensagem de erro:

Exemplo de mensagem de incompatibilidade entre a rotina AdvPL e o processo:

No exemplo acima vemos que a rotina FINA410 tentou executar a stored procedure FIN003_09 e recebeu um erro. Isso ocorre porque a assinatura da rotina (013) não é a mesma assinatura da stored procedure (011). A rotina não poderá ser executada utilizando as stored procedures até que as assinaturas sejam compatibilizadas.

Podemos verificar estas informações ao visualizarmos os detalhes do processo (no caso é o processo 09).

Constatamos então que as assinaturas são diferentes.

Solução: COMPATIBILIZAR AS ASSINATURAS

A solução nestes casos envolve uma das seguintes opções:

• 
  
  • Se a assinatura do processo for inferior à assinatura da rotina AdvPL, então o processo deve ser atualizado. Para isso, opte pela solução adequada ao seu cenário:
    • Em ambientes online: Executar a instalação/atualização do processo em questão.
    • Em ambientes offline: Obter um patch (.PTM) que contenha a versão mais recente do processo em questão e realizar a instalação.
  • Se a assinatura da rotina AdvPL for inferior à assinatura do processo: deve-se aplicar o patch.

Se mesmo após a aplicação do patch (.PTM) mais atual da rotina e/ou instalação do processo mais atual disponibilizado pela TOTVS as assinaturas continuarem incompatíveis, o suporte deverá ser acionado para entender o ocorrido. Existe ainda a alternativa para solucionar o problema de incompatibilidade de assinaturas por meio da opção Forçar utilização de pacotes .ZSPS contidos no RPO. 

EMERGENCIAL: Processos com este status referem-se à situações onde foi aplicado um patch de correção (.PTM) contendo um pacote ZSPS Emergencial para correção de problemas pontuais em stored procedures. Clientes que utilizam o serviço PRIME recebem estes patchs (.PTM) com urgência. Pacotes ZSPS podem ser gerados com essa característica (Emergencial) e só são enviados aos clientes em situações específicas. Estes pacotes não são homologados pelo procedimento padrão TOTVS e sua função é a de sanar problemas pontuais ocorridos no ambiente de clientes PRIME.

A ferramenta quando encontra pacotes ZSPS do tipo Emergencial embarcados no RPO passa a se comportar de maneira distinta. No momento da instalação/atualização de processos, ao encontrar no RPO um pacote ZSPS Emergencial, a rotina fará uso dele em detrimento de pacotes encontrados na Central de Atualizações (desde que sejam mais recentes que os homologados e disponíveis na Central de Atualizações).

A interface passa a realizar uma série de controles específicos para garantir, por exemplo, que um pacote Emergencial não seja substituído por um outro pacote cujo conteúdo ainda não tenha sofrido as mesmas correções efetuadas no pacote recebido em caráter emergencial. Dessa forma garantimos que o ambiente não perca as correções contidas no pacote Emergencial, fundamentais para o correto funcionamento das rotinas.

Solução: AGUARDAR EXPEDIÇÃO OFICIAL CONTENDO CORREÇÕES EMERGENCIAIS

Quando a TOTVS concluir as correções em carater oficial e realizar a expedição de um novo pacote ZSPS do processo envolvido, este ficará disponível na Central de Atualizações e também no patch de correção (.PTM) gerado pela expedição realizada. A partir deste momento o processo poderá ser atualizado pela ferramenta, seja de maneira online ou offline.

Ao homologar um novo pacote ZSPS contendo todas as correções feitas no pacote ZSPS Emergencial, garantimos que as correções emergenciais estão presentes de forma oficial nos processos disponibilizados. Assim ao efetuar a atualização do processo Emergencial, a ferramenta identifica que o pacote mais recente homologado pode ser usado para substituir o pacote Emergencial do ambiente. Quando isso ocorre, o status do processo passa a ser Atualizado.

PILOTO: Processos com este status referem-se à processos que estão em testes por clientes Piloto. Somente com o consentimento e acordo entre Cliente e TOTVS é que um patch de atualização (.PTM) contendo um arquivo ZSPS Piloto é enviado ao cliente. Clientes considerados Pilotos estão em acordo com a TOTVS para realizarem testes de novos processos de procedures e/ou novas funcionalidades em processsos já existentes. Estes pacotes não são homologados pelo procedimento padrão TOTVS e sua função é a de proporcionar ao cliente um ambiente de testes, no qual as rotinas e stored procedures envolvidas ainda estão sendo testadas.

A ferramenta quando encontra pacotes ZSPS do tipo Piloto embarcados no RPO passa a se comportar de maneira distinta. No momento da instalação/atualização de processos, ao encontrar no RPO um pacote ZSPS Piloto, a rotina fará uso dele em detrimento de pacotes encontrados na Central de Atualizações (desde que sejam mais recentes que os homologados e disponíveis na Central de Atualizações).

A interface passa a realizar uma série de controles específicos para garantir, por exemplo, que um pacote Piloto não seja substituído por um outro pacote cujo conteúdo não contenha as mesmas inovações efetuadas no pacote recebido em caráter de inovação. Dessa forma garantimos que o ambiente não perca as atualizações contidas no pacote Piloto, fundamentais para a realização dos testes das rotinas e stored procedures envolvidas.

Solução: AGUARDAR EXPEDIÇÃO OFICIAL CONTENDO AS INOVAÇÕES

Quando a TOTVS concluir, em conjunto com os Clientes Piloto, os testes das inovações em carater oficial e realizar a expedição de um novo pacote ZSPS do processo envolvido, este ficará disponível na Central de Atualizações e também no patch de atualização (.PTM) gerado pela expedição realizada. A partir deste momento o processo poderá ser atualizado pela ferramenta, seja de maneira online ou offline.

Ao homologar um novo pacote ZSPS contendo todas as inovações feitas no pacote ZSPS Piloto, garantimos que as inovações criadas estão presentes de forma oficial nos processos disponibilizados. Assim ao efetuar a atualização do processo Piloto, a ferramenta identifica que o pacote mais recente homologado pode ser usado para substituir o pacote Piloto do ambiente. Quando isso ocorre, o status do processo passa a ser Atualizado.

Instalando/Atualizando pacotes de procedures

Em ambientes offline: Os arquivos necessários para a instalação estarão presentes de forma embarcada no RPO. Estes arquivos possuem a extensão .ZSPS e contém todas as informações necessárias para que o procedimento seja realizado de maneira offline (sem integração com a Central de Atualizações). Caso o processo a ser instalado não possua o referido arquivo .ZSPS embarcado no RPO, será necessário aplicar um patch (.PTM) que contenha o arquivo.

Em ambientes online: Durante o procedimento de instalação em ambientes integrados com a Central de Atualizações, os processos mais recentes homologados e disponibilizados pela TOTVS serão obtidos de maneira online e serão utilizados na instalação (desde que sejam mais recentes que os disponíveis no RPO).

Dessa forma garantimos que o ambiente esteja sempre atualizado com os processos de procedures mais recentemente homologados e disponibilizados pela TOTVS e/ou presentes no ambiente (de forma embarcada no RPO).

Para realizar a instalação/atualização:

• Selecionar em quais empresas os processos serão instalados/atualizados:
  

• Selecionar quais processos serão instalados/atualizados:
  

Após selecionar as empresas e processos, basta clicar no botão (instalar processos).

Será exibida uma janela com alguns avisos solicitando a confirmação:

O procedimento de instalação somente poderá ocorrer se os processos selecionados não estiverem em uso por outra rotina neste momento.
Ao confirmar, surgirá uma outra janela exibindo o andamento da instalação:

Ao final do procedimento surgirá uma janela contendo o Resumo das operações realizadas durante a instalação:

Nesta interface constam as seguintes informações:

• 
  
  • Total de operações: Quantidade total de ações a serem realizadas, baseadas nas Empresas/Grupo de Empresas e processos selecionados para instalação;
  • Sucessos: Quantidade de ações realizadas com sucesso;
  • Ignoradas: Quantidade de ações não realizadas/ignoradas;
  • Falhas: Quantidade de ações com falhas/problemas durante sua execução;

Ainda na janela de Resumo, ao clicar no botão Ver detalhes o detalhamento das ações será exibido:

No botão Outras Ações é possível gerar o relatório deste log.

Ao fechar a janela de Resumo (ou de log), a interface principal será atualizada para refletir o status atual:

Desinstalando pacotes de procedures

O procedimento para desinstalação de pacotes é semelhante ao de instalação. É necessário apenas que os processos envolvidos não estejam em uso. Este procedimento necessita de acesso exclusivo em algumas tabelas do banco de dados e por isso não pode haver concorrência.

Para realizar a desinstalação:

• Selecionar em quais empresas os processos serão desinstalados:
  

• Selecionar quais processos serão desinstalados:
  

Após selecionar as empresas e processos, basta clicar no botão (desinstalar processos).
Será exibida uma janela com alguns avisos solicitando a confirmação da desinstalação:

O procedimento de desinstalação somente poderá ocorrer se os processos selecionados não estiverem em uso por outra rotina neste momento.
Ao confirmar, surgirá uma outra janela exibindo o andamento da desinstalação:

Ao final do procedimento surgirá uma janela contendo o Resumo das operações realizadas durante a desinstalação:

Nesta interface constam as seguintes informações:

• 
  
  • Total de operações: Quantidade total de ações a serem realizadas, baseadas nas Empresas/Grupo de Empresas e processos selecionados para desinstalação;
  • Sucessos: Quantidade de ações realizadas com sucesso;
  • Ignoradas: Quantidade de ações não realizadas/ignoradas;
  • Falhas: Quantidade de ações com falhas/problemas durante sua execução;

Ainda na janela de Resumo, ao clicar no botão Ver detalhes o detalhamento das ações será exibido:

No botão Outras Ações é possível gerar o relatório deste log.

Ao fechar a janela de Resumo (ou de log), a interface principal será atualizada para refletir o status atual:

Consultando o histórico de operações

Para visualizar o histórico das operações realizadas, basta clicar no botão (Histórico de operações) da interface principal:

As informações na parte superior desta interface se referem às ações de instalação e desinstalação realizadas, contendo entre elas:

• ID da ação (sequencial e de uso interno apenas);
• Data e hora de execução;
• Tipo da ação (instalação ou desinstalação);
• Modo: on-line ou off-line (integração com a Central de Atualizações ativa ou não);
• Código e nome do usuário que executou a ação;
• Dados do ambiente: nome, alias, tipo de banco, IP e porta de comunicação com DBAccess;
• Totalizadores: empresas selecionadas, processos selecionados, execuções a realizar, sucessos, falhas e ignoradas;

Na parte inferior são apresentados os detalhes de cada tarefa:

• ID da tarefa (sequencial e de uso interno apenas);
• Tipo: Pode conter um dos seguintes valores [INFO], [OK], [SKIP], [ERRO];
• Log: descritivo da tarefa realizada;
• Detalhes: armazenará os detalhes dos problemas encontrados durante a execução da tarefa;

A legenda da grid inferior apresentará:

INFO - Informações genéricas;

OK - Ação realizada com sucesso;

SKIP - Ação ignorada;

ERRO - Ação com falha/problema na execução; 

Ao encontrar uma ação com o tipo ERRO note que haverá o texto "Duplo clique em Memo para detalhes" na descrição do log. Nesta situação, basta efetuar um duplo clique na coluna Detalhes para visualizar a mensagem completa com a falha/problema ocorrido:

Conteúdo da coluna Detalhes:

Resolução de problemas pontuais sem necessidade de contato com suporte TOTVS

Alguns problemas ocorridos durante o procedimento de instalação/desinstalação podem ser resolvidos pelo próprio cliente, sem a necessidade de abertura de chamado e/ou contato com o suporte TOTVS. Para isso, basta visualizar os detalhes do log e seguir as instruções.

Os exemplos abaixo demonstram erros ocorridos durante a instalação de processos. São apresentadas as causas dos problemas e também as soluções propostas para os casos.

Problema reportado: Incompatibilidade de assinaturas entre rotina AdvPL e processo

Neste exemplo o problema de incompatibilidade ocorreu porque as assinaturas são divergentes. A assinatura da rotina MATA280.PRX (no exemplo 003) é inferior à assinatura do processo (no exemplo 004). Esta situação é descrita no tópico Entendendo os status dos processos e ações que podem ser tomadas.

Repare que é proposta uma solução para o problema: Atualizar a rotina MATA280.PRX, compatibilizando as assinaturas. A solução ainda oferece um link direcionando o cliente para o portal de downloads, diretamente para o patch (.PTM) mais recente disponível que contém a referida rotina.

Ao acessar este link, o cliente poderá baixar o patch, e seguindo as instruções contidas no log, após a aplicação do mesmo a rotina estará em sua versão mais atual. Espera-se que com essa aplicação de patch, a assinatura da rotina passe a ser idêntica à assinatura do processo (no caso 004).

Se mesmo após a aplicação do patch (.PTM) mais atual da rotina e/ou instalação do processo mais atual disponibilizado pela TOTVS as assinaturas continuarem incompatíveis, o suporte deverá ser acionado para entender o ocorrido. Existe ainda a alternativa para solucionar o problema de incompatibilidade de assinaturas por meio da opção Forçar utilização de pacotes .ZSPS contidos no RPO. Entretanto deve-se analisar os detalhes do processo, subitem Processo) e identificar se as assinaturas da rotina e do processo embarcado no RPO são compatíveis.

Se isso ocorrer, significa que a rotina em questão não foi devidamente compatibilizada com o processo ao qual ela está associada, e isso deverá ser informado na abertura do chamado. Dessa forma a área responsável poderá identificar o problema e providenciar a correção para a incompatibilidade. O inverso pode ocorrer também, ou seja, a assinatura do processo ser inferior à assinatura da rotina. Neste caso a obtenção de um pacote ZSPS atualizado se faz necessária. Se o ambiente estiver integrado à Central de Atualizações e esta não oferecer um processo com a assinatura compatível, o contato com o suporte também se faz necessário. Se o ambiente for offline, então a obtenção de um patch (.PTM) contendo um pacote ZSPS mais atual através do portal de downloads se faz necessária. Este é o conjunto completo de todos os pacotes de procedures do novo formato .ZSPS utilizados pela nova interface. 

Problema reportado: Incompatibilidade de assinaturas entre processo e rotina CFGX051M.PRW (instalador de procedures):

Neste exemplo o problema de incompatibilidade é entre o processo e a rotina CFGX051M.PRW (o próprio instalador).

Isso pode ocorrer porque os arquivos ZSPS contém uma informação que é a assinatura mínima exigida para o instalador poder utilizá-los. Essa assinatura garante que os pacotes ZSPS construídos para serem utilizados por uma determinada versão do instalador não gerem errorlog durante a sua instalação caso o instalador esteja desatualizado. Esse mecanismo é necessário pois a construção das procedures segue um padrão pré-estabelecido pela TOTVS. Essa construção leva em consideração uma série de requisitos que por sua vez fazem parte do mecanismo de instalação. Por estarmos sempre em evolução, o programa instalador sofre alterações para se adequar à forma como as procedures são escritas. Diante disso, precisamos garantir que caso uma procedure tenha sido escrita sob novas regras de construção, o instalador esteja preparado para ler esta procedure e entenda o que foi escrito nela. Por isso devemos sempre manter o programa instalador (CFGX051M.PRW) atualizado.

Note que, assim como no exemplo anterior, existem neste log a causa do problema e uma solução proposta para ele. E da mesma forma, existe um link que, ao ser acionado direcionará para a página de downloads diretamente para o patch (.PTM) contendo a versão mais recente disponível. Após aplicado, a assinatura do instalador estará compatível com a assinatura mínima exigida. Caso isso não ocorra, então o suporte deverá ser acionado.

Em ambos os casos o mais importante é ressaltar que, sem acionar o suporte TOTVS, o próprio cliente poderá solucionar alguns problemas de acordo com as instruções contidas nos detalhes do log. Salientamos com isso a importância de sempre verificar as ocorrências do tipo ERRO no log de operações.

Relatório de Log

No botão Outras Ações da janela de Log é possível gerar um relatório completo de todas as operações contidas no log. Também é possível efetuar filtros e personalizar o relatório.

Ao selecionar a opção Relatório, a seguinte interface é exibida. Nesta janela é possível definir, entre outras opções, o tipo de arquivo gerado:

No exemplo acima foi selecionada a opção Planilha:

Configurações adicionais da rotina

O botão (Configurações adicionais da rotina) está disponível na interface principal, na barra lateral:

Ao ser acionado, exibe uma interface onde é possível configurar o comportamento da rotina com as seguintes opções:

• Forçar reinstalação de pacotes atualizados: Com esta opção marcada, mesmo o pacote com status Atualizado será novamente instalado no ambiente. Isso implica na realização das seguintes ações:
  • Remoção das stored procedures atualmente instaladas;
  • Instalação das stored procedures na base de dados a partir do pacote ZSPS utilizado para a instalação;
  • Atualização das informações de controle na base de dados;

• Forçar utilização de pacotes .ZSPS contidos no RPO: Com esta opção marcada, o processo de instalação utilizará o pacote ZSPS embarcado no RPO, mesmo que este não seja o mais recente disponível. Esta opção permite, por exemplo, que seja utilizado um pacote antigo que esteja presente no RPO ao invés de utilizar o pacote disponível na Central de Atualizações.

Exemplo: Processo com status Atualizado 

No exemplo acima vemos que o processo está Atualizado, pois o pacote instalado possui IDSPS 691, que é exatamente o mais recente disponível na Central de Atualizações.

Se marcarmos esta opção e realizarmos a instalação deste processo, veremos que o pacote com IDSPS 7 presente no RPO será utilizado ao invés do IDSPS 691.

Após instalar o processo com esta opção ativa, veremos nos detalhes que o pacote utilizado foi o que está contido no RPO (IDSPS 7):

• Forçar utilização de pacotes .ZSPS disponíveis na Central de Atualizações: Esta opção estará disponível apenas se houver integração com a Central de Atualizações. Ela muda o comportamento padrão da rotina no que se refere à utilização de pacotes ZSPS não homologados (Piloto e/ou Emergencial) com prioridade. O comportamento padrão da rotina é o de utilizar estes tipos de pacotes com prioridade, porém caso esteja ativa, o procedimento de instalação sempre utilizará o pacote ZSPS disponível na Central de Atualizações. Caso o pacote ZSPS não possa ser obtido na Central de Atualizações, a rotina não fará uso do pacote embarcado no RPO e armazenará uma mensagem no log de processamento contendo os detalhes do ocorrido.

Ao encerrar a interface de Gestão de Procedures estas opções ficam desativadas (comportamento padrão). Elas devem ser reconfiguradas sempre que necessário.