Histórico da Página
...
- FAT (Faturamento) - https://suporte.totvs.com/portal/p/10098/download?e=1080341
- COM (Compras) - https://suporte.totvs.com/portal/p/10098/download?e=1080335
- FIS (Fiscal) - https://suporte.totvs.com/portal/p/10098/download?e=1080345
- FIN (Financeiro) - https://suporte.totvs.com/portal/p/10098/download?e=1080343
- EST (Estoque) - https://suporte.totvs.com/portal/p/10098/download?e=1080339
- CTB (Controladoria) - https://suporte.totvs.com/portal/p/10098/download?e=1080337
Nota | ||
---|---|---|
| ||
Os patchs de Expedição Contínua dos módulos acima são necessários para que o RPO seja atualizado com os pacotes de procedures no novo formato .ZSPS, além das rotinas associadas às stored procedures. A aplicação destes patchs é obrigatória, caso contrário poderão ocorrer erros durante a instalação/desinstalação de processos. |
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.
...
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. Para mais detalhes sobre o log de operações, veja os itens Instalando/Atualizando pacotes de procedures e Consultando o histórico de operações.
- É 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. Para mais informações sobre a Central de Atualizações clique aqui.
- 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.
...
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).
...
As ações disponíveis nos botões da barra lateral são:
...
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.
...
Nota | ||
---|---|---|
| ||
Esta guia somente estará visível caso exista mais de uma empresa/grupo de empresas disponível no ambiente. |
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.
O detalhamento dos status está no tópico Entendendo os status dos processos e ações que podem ser tomadas.
...
As seções apresentadas são:
Seção Detalhes:
Apresenta informações detalhadas sobre o ambiente:
...
- ON (modo online) quando conectividade está ativa ou
- OFF (modo offline) quando não há conectividade;
...
- 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.
Nota | ||
---|---|---|
| ||
Um processo com IDSPS negativo no campo Instalado (no exemplo acima -17) significa apenas que ele é legado, ou seja, já estava devidamente instalado no ambiente previamente à migração para o novo modelo de Gestão de Procedures. Isso não caracteriza problema ou erro. Processos legados, em sua maioria, estão Desatualizados perante aos novos pacotes ZSPS contidos no RPO ou na Central de Atualizações. Contudo, estes processos podem ser utilizados normalmente por suas rotinas AdvPL, desde que possuam assinaturas compatíveis. |
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).
...
- 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).
...
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.
...
Versão 12.1.2310
- FAT (Faturamento) - https://suporte.totvs.com/portal/p/10098/download?e=1123877
- COM (Compras) - https://suporte.totvs.com/portal/p/10098/download?e=1123869
- FIS (Fiscal) - https://suporte.totvs.com/portal/p/10098/download?e=1123881
- FIN (Financeiro) - https://suporte.totvs.com/portal/p/10098/download?e=1123879
- EST (Estoque) - https://suporte.totvs.com/portal/p/10098/download?e=1123875
- CTB (Controladoria) - https://suporte.totvs.com/portal/p/10098/download?e=1123873
- ATF (Ativo Fixo) - https://suporte.totvs.com/portal/p/10098/download?e=1123865
- PCO (Planejamento e Controle Orçamentário) - https://suporte.totvs.com/portal/p/10098/download?e=1123883
Nota | ||
---|---|---|
| ||
ROTINAS ATUALIZADAS E PACOTES DE PROCEDURES NO FORMATO ZSPS Os patchs de Expedição Contínua dos módulos acima são necessários para que o RPO seja atualizado com os pacotes de procedures no novo formato .ZSPS, além das rotinas associadas às stored procedures. A aplicação destes patchs é obrigatória, caso contrário poderão ocorrer erros durante a instalação/desinstalação de processos. |
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.
Âncora | ||||||
---|---|---|---|---|---|---|
|
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. Para mais detalhes sobre o log de operações, veja os itens Instalando/Atualizando pacotes de procedures e Consultando o histórico de operações.
- É 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. Para mais informações sobre a Central de Atualizações clique aqui.
- 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.
Nota | ||
---|---|---|
| ||
A Central de Atualizações não é item obrigatório. A ausência (temporária ou definitiva) de conectividade não atrapalha em nada o funcionamento da rotina de Gestão de Procedures. |
Âncora | ||||||
---|---|---|---|---|---|---|
|
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).
Âncora | ||||||
---|---|---|---|---|---|---|
|
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.
Âncora | ||||||
---|---|---|---|---|---|---|
|
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.
Âncora | ||||||
---|---|---|---|---|---|---|
|
A visão disponibilizada nesta guia baseia-se na navegação realizada entre os processos disponíveis na relação de processos.
Nota | ||
---|---|---|
| ||
Esta guia somente estará visível caso exista mais de uma empresa/grupo de empresas disponível no ambiente. |
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.
O detalhamento dos status está no tópico Entendendo os status dos processos e ações que podem ser tomadas.
Âncora | ||||||
---|---|---|---|---|---|---|
|
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: os possíveis status estão detalhados em Entendendo os status dos processos e ações que podem ser tomadas.
- Assinatura do processo instalado (em destaque para facilitar a visualização): exemplo na imagem 003
- No campo Instalado:
- IDSPS (identificador único do pacote): exemplo na imagem (-17)
- Data e hora do pacote ZSPS instalado: exemplo na imagem 21/01/2020 14:24:14
- Assinatura do pacote ZSPS instalado: exemplo na imagem [003]
- No campo RPO:
- IDSPS (identificador único do pacote): exemplo na imagem (998)
- Data e hora do pacote ZSPS contido no RPO : exemplo na imagem: 20/03/2023 08:09:32
- Assinatura do pacote ZSPS contido no RPO: exemplo na imagem: [003]
- No campo TPH:
- IDSPS (identificador único do pacote): exemplo na imagem (1171)
- Data e hora do pacote ZSPS disponível na Central de Atualizações : exemplo na imagem: 03/05/2023 18:20:42
- Assinatura do pacote ZSPS disponível na Central de Atualizações: exemplo na imagem: [004]
Nota | ||
---|---|---|
| ||
Um processo com IDSPS negativo no campo Instalado (no exemplo acima -17) significa apenas que ele é legado, ou seja, já estava devidamente instalado no ambiente previamente à migração para o novo modelo de Gestão de Procedures. Isso não caracteriza problema ou erro. Processos legados, em sua maioria, estão Desatualizados perante aos novos pacotes ZSPS contidos no RPO ou na Central de Atualizações. Contudo, estes processos podem ser utilizados normalmente por suas rotinas AdvPL, desde que possuam assinaturas compatíveis. |
Seção Rotina:
Apresenta informações detalhadas do rotina AdvPL associada ao processo:
- Status da rotina compilada no RPO:
- Atualizado: a rotina está na sua versão mais recente disponibilizada pela TOTVS.
...
- Desatualizado: significa
...
- que a rotina AdvPL compilada no RPO não é a mais recente disponibilizada pela TOTVS. Existe(m) patch(s) de atualização (.PTM) com uma versão mais recente disponível.
Obs.
Ao encontrarmos processos com este status, devemos considerar:
...
: A comparação é realizada com
...
a Central de Atualizações.
...
Exemplo de processo desatualizado:
Visualizando os detalhes do processo:
...
Em ambientes offline essa comparação não é possível, ou seja, o status da rotina será sempre Não avaliado.
- Assinatura da rotina AdvPL: é utilizada para garantir a compatibilidade entre a rotina AdvPL e o processo (Stored Procedure);
- 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 (
...
- exibido somente se o ambiente estiver online);
- 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 da rotina compilada no RPO:
- Atualizado: a rotina está na sua versão mais recente disponibilizada pela TOTVS.
- Desatualizado: significa que a rotina AdvPL compilada no RPO não é a mais recente disponibilizada pela TOTVS. Existe(m) patch(s) de atualização (.PTM) com uma versão mais recente disponível.
Obs.: A comparação é realizada com a Central de Atualizações. Em ambientes offline essa comparação não é possível, ou seja, o status da rotina será sempre Não avaliado.
- Assinatura da rotina AdvPL de gestão de procedures: é usada para garantir a compatibilidade entre a rotina de gestão de procedures (instalador) e os pacotes 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).
Âncora | ||||||
---|---|---|---|---|---|---|
|
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
Nota | ||
---|---|---|
| ||
Os pacotes de procedures ficam disponíveis na Central de Atualizações assim que é feita a homologação dos mesmos. Essa etapa ocorre simultaneamente à expedição dos patchs de atualizações (.PTM) publicados e disponibilizados no Portal de Downloads. Por esse motivo, em um ambiente integrado à Central de Atualizações a interface pode indicar, a qualquer momento, que um determinado processo está Desatualizado. Contudo, isso não indica necessariamente um problema, já que pacotes Desatualizados podem ser utilizados normalmente por suas rotinas AdvPL. |
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
Para atualizar o processo basta realizar o procedimento descrito no tópico a seguir Instalando/Atualizando pacotes de procedures.
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 (recomendamos a leitura do tópico Migração para o novo modelo);
- 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.
Solução:
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.
Nota | ||
---|---|---|
| ||
Os pacotes de procedures ficam disponíveis na Central de Atualizações assim que é feita a homologação dos mesmos. Essa etapa ocorre simultaneamente à expedição dos patchs de atualizações (.PTM) publicados e disponibilizados no Portal de Downloads. Por esse motivo, em um ambiente integrado à Central de Atualizações a interface pode indicar, a qualquer momento, que um determinado processo está Desatualizado. Contudo, isso não indica necessariamente um problema, já que pacotes Desatualizados podem ser utilizados normalmente por suas rotinas AdvPL. |
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
Para atualizar o processo basta realizar Caso seja necessário instalar um processo, basta seguir o procedimento descrito no tópico a seguir Instalando/Atualizando pacotes de procedures.
INCOMPATÍVEL: Nesta situação as assinaturas do processo e da rotina AdvPL (consulte tópico Visualizando detalhes) 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 (.PTM) contendo a versão mais atualizada da rotina em questão (consulte tópico Visualizando detalhes, subitem Seção Rotina);
- 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:
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 (consulte tópico Visualizando detalhes, subitem Processo) e identificar se as assinaturas da rotina e do processo embarcado no RPO são compatíveis. Veja os detalhes do funcionamento desta opção em Configurações adicionais da rotina.
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.
Nota | ||
---|---|---|
| ||
Pacotes Emergenciais só existem de maneira embarcada no RPO. Eles não estão disponíveis na Central de Atualizações. A única maneira de utilizar um pacote ZSPS Emergencial é através da aplicação de patchs de correção (.PTM) contendo o arquivo ZSPS com essa característica. São totalmente funcionais e podem ser executados normalmente por suas rotinas AdvPL. Este tipo de pacote não aparece nos totalizadores da interface. Pode-se atualizar o RPO com um novo patch (.PTM) contendo uma versão mais nova do pacote ZSPS Emergencial. Caso ocorra a atualização do RPO com um pacote ZSPS Emergencial mais antigo que o pacote ZSPS Emergencial instalado no ambiente, a utilização deste arquivo ZSPS (mais antigo) será bloqueada pela ferramenta. Isso garante que as correções não sejam perdidas por uma atualização indevida. |
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.
Nota | ||
---|---|---|
| ||
Pacotes Piloto só existem de maneira embarcada no RPO. Eles não estão disponíveis na Central de Atualizações. A única maneira de utilizar um pacote ZSPS Piloto é através da aplicação de patchs de atualização (.PTM) contendo o arquivo ZSPS com essa característica. São totalmente funcionais e podem ser executados normalmente por suas rotinas AdvPL. Este tipo de pacote não aparece nos totalizadores da interface. Pode-se atualizar o RPO com um novo patch (.PTM) contendo uma versão mais nova do pacote ZSPS Piloto. Caso ocorra a atualização do RPO com um pacote ZSPS Piloto mais antigo que o pacote ZSPS Piloto instalado no ambiente, a utilização deste arquivo ZSPS (mais antigo) será bloqueada pela ferramenta. Isso garante que as inovações não sejam perdidas por uma atualização indevida. |
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.
...
Nota | ||
---|---|---|
| ||
Não é necessário obter nenhum arquivo de extensão .SPS. Eles são obsoletos e não são mais utilizados por esta rotina. |
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 (para constatar isso, consulte o tópico Visualizando detalhes), 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).
...
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 (recomendamos a leitura do tópico Migração para o novo modelo);
- 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.
Solução:
Caso seja necessário instalar um processo, basta seguir o procedimento descrito no tópico a seguir Instalando/Atualizando pacotes de procedures.
INCOMPATÍVEL: Nesta situação as assinaturas do processo e da rotina AdvPL (consulte tópico Visualizando detalhes) 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:
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.
Nota | ||
---|---|---|
| ||
Esta interface tem como objetivo proteger o sistema, impedindo que ocorram errorlogs. A checagem de compatibilidade é uma tarefa executada sempre que uma stored procedure é acionada a partir do sistema, ou seja, esse mecanismo sempre será ativado independente de ações do usuário, parametrização do sistema, etc. Não há como evitar que essa mensagem seja exibida quando houver incompatibilidade. A única forma de evitar a exibição desta mensagem é garantir que os processos de stored procedures estejam sempre compatíveis com suas respectivas rotinas AdvPL. Essa checagem não tem relação com o novo modelo de Gestão de Procedures. Ela sempre existiu, desde as primeiras releases Protheus disponibilizadas com a funcionalidade de stored procedures. |
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 (.PTM) contendo a versão mais atualizada da rotina em questão (consulte tópico Visualizando detalhes, subitem Seção Rotina);
- 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:
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 (consulte tópico Visualizando detalhes, subitem Processo) e identificar se as assinaturas da rotina e do processo embarcado no RPO são compatíveis. Veja os detalhes do funcionamento desta opção em Configurações adicionais da rotina.
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.
Nota | ||
---|---|---|
| ||
Pacotes Emergenciais só existem de maneira embarcada no RPO. Eles não estão disponíveis na Central de Atualizações. A única maneira de utilizar um pacote ZSPS Emergencial é através da aplicação de patchs de correção (.PTM) contendo o arquivo ZSPS com essa característica. São totalmente funcionais e podem ser executados normalmente por suas rotinas AdvPL. Este tipo de pacote não aparece nos totalizadores da interface. Pode-se atualizar o RPO com um novo patch (.PTM) contendo uma versão mais nova do pacote ZSPS Emergencial. Caso ocorra a atualização do RPO com um pacote ZSPS Emergencial mais antigo que o pacote ZSPS Emergencial instalado no ambiente, a utilização deste arquivo ZSPS (mais antigo) será bloqueada pela ferramenta. Isso garante que as correções não sejam perdidas por uma atualização indevida. |
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.
Nota | ||
---|---|---|
| ||
Pacotes Piloto só existem de maneira embarcada no RPO. Eles não estão disponíveis na Central de Atualizações. A única maneira de utilizar um pacote ZSPS Piloto é através da aplicação de patchs de atualização (.PTM) contendo o arquivo ZSPS com essa característica. São totalmente funcionais e podem ser executados normalmente por suas rotinas AdvPL. Este tipo de pacote não aparece nos totalizadores da interface. Pode-se atualizar o RPO com um novo patch (.PTM) contendo uma versão mais nova do pacote ZSPS Piloto. Caso ocorra a atualização do RPO com um pacote ZSPS Piloto mais antigo que o pacote ZSPS Piloto instalado no ambiente, a utilização deste arquivo ZSPS (mais antigo) será bloqueada pela ferramenta. Isso garante que as inovações não sejam perdidas por uma atualização indevida. |
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.
Âncora | ||||||
---|---|---|---|---|---|---|
|
Nota | ||
---|---|---|
| ||
Não é necessário obter nenhum arquivo de extensão .SPS. Eles são obsoletos e não são mais utilizados por esta rotina. |
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 (para constatar isso, consulte o tópico Visualizando detalhes), 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:
Âncora | ||||||
---|---|---|---|---|---|---|
|
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
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 desinstalar processos).
Será exibida uma janela com alguns avisos solicitando a confirmação da desinstalação:
O procedimento de instalação 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 instalaçãodesinstalação:
Ao final do procedimento surgirá uma janela contendo o Resumo das operações realizadas durante a instalaçãodesinstalaçã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çãodesinstalaçã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:
Âncora |
---|
...
|
...
|
...
|
...
|
...
|
Para visualizar o histórico das operações realizadas
Para realizar a desinstalação:
- Selecionar em quais empresas os processos serão desinstalados:
- Selecionar quais processos serão desinstalados:
...
, 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:
Âncora | ||||||
---|---|---|---|---|---|---|
|
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:
Nota | ||
---|---|---|
| ||
Utilize a opção Planilha para gerar um arquivo em formato Excel. Dessa forma é possível enviar o log para equipes de suporte TOTVS. Estas informações são fundamentais para a equipe iniciar a análise de problemas. |
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.
...
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:
Âncora | ||||||
---|---|---|---|---|---|---|
|
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 Para isso, basta visualizar os detalhes do log e seguir as instruções nele contidas.
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:
Cenário 1: Rotina AdvPL com assinatura inferior
Neste exemplo o problema de incompatibilidade ocorreu porque as assinaturas são divergentes. A 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 A solução proposta para o problema : Atualizar é 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 É indicado o link para download do 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 a aplicação de deste 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 indicado 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 (consulte tópico Visualizando detalhes, subitem Processo) e identificar se as assinaturas da rotina e do processo embarcado no RPO são compatíveis. Veja os detalhes do funcionamento desta opção em Configurações adicionais da rotina. Se isso ocorreracontecer, 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, compatibilização.
Cenário 2: Processo com assinatura inferior
Neste exemplo a assinatura do processo ser (010) é inferior à assinatura da rotina (011). Esta situação é descrita no tópico Entendendo os status dos processos e ações que podem ser tomadas.
A solução proposta para o problema é atualizar o processo, compatibilizando as assinaturas. É importante lembrar que se . 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.
Problema reportado: Incompatibilidade de assinaturas entre processo e rotina CFGX051M.PRW (instalador de procedures):
Neste exemplo o problema é entre o processo e a rotina que faz a instalação (o próprio instalador, CFGX051M.PRW).
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 as assinaturas sejam incompatíveis. 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.
Nota | ||
---|---|---|
| ||
O link para download dos patchs (.PTM) somente serão exibidos nas mensagens do log em ambientes online, ou seja, com a integração com a Central de Atualizações configurada e ativa no momento da instalação/desinstalação. |
...
Se o ambiente for offline, então a obtenção do patch (.PTM) conforme as instruções do log deve ser realizada.
Se mesmo após a aplicação do patch (.PTM) indicado as assinaturas continuarem incompatíveis, o suporte deverá ser acionado para entender o ocorrido. Se isso ocorrer, significa que o processo em questão não foi devidamente compatibilizado com a rotina à qual ele está associado, e isso deverá ser informado na abertura do chamado. Dessa forma a área responsável poderá identificar o problema e providenciar a compatibilização.
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 ocorre porque os arquivos ZSPS exigem uma assinatura mínima do instalador para serem utilizados. Essa assinatura garante que os pacotes ZSPS construídos para serem utilizados por uma determinada versão do instalador não gerem errorlog caso o instalador esteja desatualizado.
Esse mecanismo é necessário pois a construção das procedures segue um padrão pré-estabelecido pela TOTVS. 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 uma procedure possa ser lida e processada corretamente pelo programa instalador. Por este motivo o programa instalador deve estar sempre atualizado (consulte tópico Visualizando detalhes, subitem Seção Gestão de Procedures);
Note que, assim como nos exemplos anteriores, existem neste log a causa do problema e uma solução proposta para ele. E da mesma forma, um link que, ao ser acionado nos levará 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 todos os casos descritos acima o mais importante é ressaltar que, mesmo sem acionar o suporte TOTVS, alguns problemas podem ser solucionados apenas seguindo 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.
Nota | ||
---|---|---|
| ||
O link para download dos patchs (.PTM) somente serão exibidos nas mensagens do log em ambientes online, ou seja, com a integração com a Central de Atualizações configurada e ativa no momento da instalação/desinstalação. Se o ambiente não possuir integração com a Central de Atualizações, então o portal de downloads deve ser acionado e os patchs de correções (.PTM) devem ser obtidos individualmente ou por meio dos pacotes de Expedições Contínuas |
...
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:
Nota | ||
---|---|---|
| ||
Utilize a opção Planilha para gerar um arquivo em formato Excel. Dessa forma é possível enviar o log para equipes de suporte TOTVS. Estas informações são fundamentais para a equipe iniciar a análise de problemas. |
Âncora | ||||||
---|---|---|---|---|---|---|
|
...