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.
|