RUP no UPDDISTR
Produto: | Microsiga Protheus | |||||||||||||||||||||||||||||||||||
Versões: | 12 | |||||||||||||||||||||||||||||||||||
Passo a passo: | A equipe de Framework implementou no UPDDISTR a capacidade de executar funções de compatibilização e/ou conversão de dados para as tabelas do sistema. Esse processo já existe na atualização de versão (MP710TO120), assim, com essa implementação este processo também será possível nas atualizações de Release. A partir de agora o UPDDISTR irá procurar no RPO por uma FUNCTION iniciadas por “RUP_” + <sigla do módulo>, por exemplo: RUP_GPE, RUP_FAT, RUP_PFS, etc. Se a função existir no RPO, ela será chamada.
Serão passados para essa função RUP_”, 5 parâmetros: cVersion : Versão do Protheus, Ex. ‘12’
Os parâmetros referentes a Release serão passados com “0” para facilitar a programação/comparação. A função irá ser chamada de 2 formas: Uma vez para cada Grupo de Empresas e Uma vez para cada Empresa/Filial. Imaginemos um SIGAMAT com os seguintes registros:
A chamada das funções “RUP_” se comportará da seguinte forma:
No exemplo as funções ‘RUP_” serão chamadas 8 vezes, variando o conteúdo do parâmetro cMode. Estas chamadas serão iniciadas depois de terminada a atualização dos dicionários e consequentemente a atualização da estrutura das tabelas. Um ponto importante para entender o uso da função, é que não importa quantos Releases estão sendo atualizados, o processo de chamar as “RUP_” é feito apenas uma vez. Por exemplo, o cliente está atualmente no Release 12.1.6 e está rodando o UPDDISTR para o Release 12.1.17. Mesmo sendo atualizados vários Releases, o processo será executado uma vez só. Com isso, se houver a necessidade, pode-se otimizar a lógica para compatibilização. O desenvolvedor pode tratar de uma vez só ou Release a Release.
#Include 'Protheus.ch'
//-------------------------------------------------------------------
/*{Protheus.doc} RUP_FAT
Função exemplo de compatibilização do release incremental. Esta função é relativa ao módulo faturamento.
Serão chamadas todas as funções compiladas referentes aos módulos cadastrados do Protheus
Será sempre considerado prefixo "RUP_" acrescido do nome padrão do módulo sem o prefixo SIGA.
Ex: para o módulo SIGACTB criar a função RUP_CTB
@param cVersion - Versão do Protheus
@param cMode - Modo de execução. 1=Por grupo de empresas / 2=Por grupo de empresas + filial (filial completa)
@param cRelStart - Release de partida Ex: 002
@param cRelFinish - Release de chegada Ex: 005
@param cLocaliz - Localização (país). Ex: BRA
@Author Framework
@since 28/01/2015
@version P12
*/
//-------------------------------------------------------------------
Function RUP_FAT( cVersion, cMode, cRelStart, cRelFinish, cLocaliz )
Local cRelLoop
Local nRelease := 0
// Regra geral : só executar atualização quando release de partida diferente do release de chegada
// A decisão, no entanto, cabe ao desenvolvedor
// A decisão de executar ou não pode estar condicionada a outros fatores
//If !( cRelStart == cRelFinish )
ConOut( "Executei o update do faturamento")
ConOut( "Modo - " + If( cMode == "1", "Grupo de empresas", "Grupo de empresas + filial" ) )
ConOut( "Grupo de empresas " + cEmpAnt ) // cEmpAnt está disponível
ConOut( "Localização (país) " + cLocaliz ) // Pode-se tomar decisões baseado no país
If cMode == "2"
// Através do controle de cModo, é possível escolher entre processos que devem rodar para
// todo o grupo de empresa ( cModo = 1 ) ou processos que serão disparados por grupo + filial
// Ambas as opções serão executadas cabendo ao desenvolvedor escolher
ConOut( "Filial " + cFilAnt ) // cFilAnt está disponível
EndIf
// A versão é passada ( Ex "12" ) e pode ser necessária no futuro
ConOut( "Versão - " + cVersion )
// Os releases de partida (início) e chegada (fim) são no formato caractere com 3 dígitos.
// Exemplo : 001, 003
ConOut( "Release de partida - " + cRelStart )
ConOut( "Release de chegada - " + cRelFinish )
// Neste FOR é feita a varredura do release de partida ao release de chegada
// Isso é necessário pois podemos atualizar do release 002 direto para o 005, por exemplo
// Às vezes, o desenvolvedor pode optar por usar Val( cRelStart ) + 1 como início do FOR
// Isso impede que dado processo seja executado duas vezes, visto que o release de "chegada" de uma
// atualização fatalmente será o release de "partida" da próxima
// For nRelease := Val( cRelStart ) + 1 to Val( cRelFinish ) // Contrução alternativa. Ver comentário acima
For nRelease := Val( cRelStart ) to Val( cRelFinish )
// Aqui é criado o código de release que está processando "no momento"
cRelLoop := StrZero( nRelease, 3 )
ConOut( "Processando update - " + cRelLoop )
If cRelLoop == "003"
// Aqui escolhi processar algo só do release 003
ConOut( "Disparando processo do release 003 !!!" )
ConOut( SA1->( LastRec() ) )
EndIf
If cRelLoop == "004"
// Aqui escolhi processar algo só no release 004
ConOut( "Disparando processo do release quatro !!!" )
ConOut( SA2->( LastRec() ) )
EndIf
Next nRelease
//EndIf
Return NIL
Centralizando nesta função, teremos um controle melhor do que está sendo forçado e maior facilidade para eventuais manutenções.
|
Visão Geral
Import HTML Content
Conteúdo das Ferramentas
Tarefas