Procedimentos de migração automatizadas @ L.V. Expertise X3

Introdução

Até agora, o procedimento, também automatizado, lista monolítica, o que significa :

que ela funciona em caixa negra, se lançando a partir da validação do dossier.
que ela atualiza os dados das tabelas cuja estrutura foi modificada no momento da migração
que ela está sequencial, cada fase sendo encadeada à precedente sem possibilidade de paralelizar certos tratamentos.
que em caso de erro, não tem retoma possível, a única alternativa sendo de corrigir os dados errados e de repartir ao início do orçamento, com o risco de dever recomeçar depois o inicio N vezes a cada erro.

O novo procedimento proposto com características seguintes :

Ela está cortada como segue :

Definem-se as etapas distintas cuja ordem de desenvolvimento sequêncial está imposta (Inicialização de então, depois Tronco Comum, depois Módulos, e enfim Pós-migraçâo). As etapas Módulos são anexados a um módulo funcional.
Em cada etapa, define-se as fases numeradas de 1 a 9, nos quais se lista as operações unitárias de migração, nomeados procedimento (cada procedimento levam um número de ordem)
A ordem de execução dos procedimentos está sequêncial : os procedimetos da fase N na etapa P não podem ser lançados que se todos os procedimemtos anexados às fases 1 a N+1 da etapa P, e todos os procedimentos anexados às etapas 1 a P-1, se existem, são terminadas sem erro.
Os procedimetos anexados a uma mesma etapa e fase são paralelizados. Elas portam um rang único que define a ordem de lançamento (esta informação está modificável), mas em função dos parâmetros de lançamento, várias tarefas de uma mesma etapa e fase são executáveis simultãneamente.

Ela permite acrescentar os procedimentos específicos e de os sequênciar facilmente Um anexo técnico descrito como programador de novos procedimentos.
Ela trabalha por cópia de dados mais cedo que por atualizações. Isto permite de estar mais eficaz nas operações de base de dados :

pela criação de uma tabela destino que não será indexada que em fim de cópia, o que é muito mais eficaz.
por utilização de inserções agrupadas mais rápidos.
pela possibilidade de poder recomeçar um procedimento em suprimido os dados já transcodificados em caso de erro na execução.
pela posibilidade de interromper temporáriamente um procedimento em tendo os pontos de retoma para não tratar que os dados restantes.
pela possibilidade de diferir se necessário a cópia de dados antigos cuja ausência não entraverá uma retoma em modo degradado num primeiro tempo.

Ela está baseada sobre um monitor de encadeamento, que permite visualizar as fazes e sua execução.

Principais etapas da migração

As etapas a seguir, quando se deseja migrar um dossier para passar de uma versão maior (a versão 140 ou a versão 5) versus a versão maior 6, são as seguintes :

Os controlos pré-migração no dossier de origem. Estes controlos podem ser realizados sem que exploração de ERP não seja parada.
A instalação da versão 6 num ambiente dedicado.
A extração dos dados a migrar do dossier de origem, seguimento da reintegração destes dados (a exploração deve então estar parada e retomará quando a migração será terminada). A extração dos dados se fará ao formato "prato" para os pequenos dossiers, e pela utilização de utilitários de extração de dados desde que a volumetria está mais consequente.
A revalidação do dossier no ambiente V6. Esta revalidação pode ser segmentada em várias etapas, pelo meio da parametrizaação de planos de migração. Se o dossier não está muito volumoso, a definição de planos de migração não é forçosamente útil. Ela está desde que se deseja paralelizar os tratamentos de arranque (para benefiicar da potência de um servidor multi-processador) e controlar o seu encadeamento em tendo os pontos de retoma.
Os controlos pós-migração Trata-se essencialmente da verificação e de adaptação de parametrizações.

A seguida da documentação descrita no conjunto das etapas.

Nota relativa aos dossiers tendo colocado em obra a migração Sage Integral

SEEWARNING No momento da migração do dossier em versão 6 e seguintes, a opção ao SMI (Migração Integral) será desativada, e as tabelas XI suprimidas.
É então imperativo que o processo de migração Integral seja totalmente finalizado em V5 antes de proceder à migração em V6 do seu dossier.

Etapas pré-migração

As etapas de pré-migração são lançadas sobre o ambiente de partida (versão 140 ou versão 5), e podem ser expostas no tempo, tendo a migração a propriamente falar. Elas não necessitam com efeito de paragem de exploração.

Elas são decompostas como segue :

verificar-se-á então que o dossier de origem está ao nível de patch mínima necessária para poder empreender uma migração. Este nível, que pode ser afixada via o menu? > A propósito, deve estar ao menos:

o patch 25 para uma versão 140
o patch 10 para uma versão 5

verificar-se-á em seguida os pré-requisitos funcionais ao tratamento de migração. Estes pré-requisitos são descritos na documentação dedicada.
Poder-se-á em seguida desencadear os procedimetos automatizados sobre o dossier de origem, pelo meio de tratamemtos cujo nome começa por UU, que se lançará pela função dedicada. Estes tratamentos são fornecidos a pedido segundo a versão (140 e V5) como um patch particular dedicado à migração. Dois tipos de procedimentos são entregues :

então, os procedimentos de controlo dos dados no dossier de origem. O resultado deste lançamento pode estar colocado em evidência os erros ou incoerências que falta imperativamente corrigir antes de lançar a migração a propriamente falar. Esta fase de controlo pode ser antecipada várias semanas antes a migração, afim de deixar o tempo de corrigir os dados, mas falta relançar para verificar que tudo está bem correcto justo antes o arranque. Estes procedimentos são listados no documento correspondente.
em seguida, dos procedimentos de alimentação opcionais, que revalidam certas tabelas em lhe acrescentando os campos suplementares, depois os alimentando. Como os procedimentos são independente, elas podem ser tambem planificadas sobre várias semanas antes a migração (a exploração pode retomar desde que reacrescenta os campos está feito). O objetivo destes procedimentos está de acelerar de maneira notável as etapas de migração a propriamente falar. Mas o facto de não lançar não compromete o funcionamento dos procedimentos de migração. Estes procedimentos são listados no documento correspondente.

Plano de migração

A preparação deste ambiente se faz pela instalação da solução V6, depois integração de todas as patches existentes no dossier X3.
Não se pode e não se deve instalar uma solução V6 sobre uma solução V140 ou V5.

Desenvolvimento das operações de um plano de migração.

A terceira etapa corresponde ao início da troca A este estado, a exploração operacional da solução deve estar parada : ela retomará quando a migração será terminada

Pode-se distinguir 4 fases nesta etapa :

extração dos dados do dossier a migrar :

por extração dos dados ao formato "liso" para os pequenos dossiers. Para tal, utilizar-se-á a função de extração que cria as fichas no directório SVG por defeito.
por extração de base de dados desde que a volumetria está mais consequente (o formato depende então da base e do utilitário utilizado).

cópia dos ficheiros do dossier a migrar na solução V6,
Criação de um dossier cópia da arborescência do dossier no novo ambiente da versão 6, e importa os dados exportados no novo ambiente,
criação da ficha dossier no ambiente V6. Se importa pela consola, a ficha dossier está criada automaticamente, mas se importa foi feito pelos utilitários de base de dados, falta criar a ficha dossier manualmente após importação.

SEEINFO É agora possível de reagrupar estas etapas numa única. Falta para tal utilizar o assitente deimportação distanteproposta na consola de configuração SAFE X3.

Se utiliza a função de importação consola, o procedimento é o seguinte :

lançar a consola,
se colocar sobre a solução Sage X3 V6 desejada e afixar os ecrãs "Dossiers",
clicar sobre o botão "import" (na barra de ferramentas de ecrã), uma janela aparece,
escolher o nome de dossier a importar, o diretório contendo os dados a importar (SVG se este diretório foi utilizado para realizar a extração),preencher os outros campos,
lançar a importação pelo botão OK.

Se for caso disso, ajustar-se-á em seguida os valores códigos de atividade na ficha dossier, por exemplo para colocar em obra novas funcionalidades controladas por códigos de actividades novos.A modificação da ficha dossier, ou a sua criação, se fará em se conectando no dossier "supervisor" (X3 no caso de Sage X3).

Grandes etapas da revalidação
Utilização de planos de migração
Desenvolvimento das operações de um plano de migração.
Expurgo final das tabelas de movimento
Exemplo se sequênciamento sobre a migração dos fluxos.

Expurgo final das tabelas de movimento

A revalidação de dossier vai transformar a estrutura do dicionário X3, depois as tabelas de parametrização, depois as tabelas de dados, da versão 140 ou 5 para conduzir ao nível da V6, em transferindo à passagem os dados. Ela se desencadeia por apoio do botão Validação depois a gestão de dossiers.

Ela realiza a migração supervisor e funcionalidade do dossier, em comparando o dicionário da nova versão e o dicionário da versão a migrar.

Grandes etapas da revalidação

A revalidação de dossier encadeia as etapas seguintes sobre o dossier a migrar :

expurgo de certas tabelas temporárias ou de acumulado cuja reconstituição será feita nas etapas posteriores. As tabelas supervisor afetadas por este expurgo são as tabelas seguintes :
    ALSTRD
    ALISTER
    AWRKLOG
    AWRKLOGIND
    AWRKLOGMES
    ATMPTRA
Outras tabelas temporárias funcionais são igualmente expurgadas (no caso de Enterprise Management, as tabelas são : LABELPRN, PRTSCRWRK, BALANCE, BALANA, GLCONSO, BALCONSO, GAJOUSTA, FUP, FUPTOT, BATCH, TMPEXPENSE).
migração de cobertura, quer dizer do dicionário de dados e das tabelas do supervisor necessários ao funcionamento de base (conexão, gestão dos utilizadores, ambiente de desenvolvimento e de parametrização mínima). A partir do momento onde esta migração é feita, uma conexão está teoricamente possível, mesmo se as tabelas contendo os dados aplicativos de fluxo são por momentos vazio.
migração funcional : Para cada tabela cuja estrutura altera, o procedimento vai proceder às alterações necessárias, se for o caso disso em dando os valores por defeito idóneos, por procedimentos encadeados em etapas e em fases. É a parte longa da migração, aquela que depende do volume de dados a migrar.
tratamento de pós-migração (são essencialmente res sincronizações de tabelas de acumulados). Certas destas etapas podem ser diferentes, e exploração retomar, ao preço de funcionamento degradado do software na fase intermédia. Elas deverão ter sido passadas para que a migração seja considerada como terminada.
supressão final das tabelas temporárias. Esta fase é manual, poderá, por razões de segurança, ser diferente tanto que não está absolutamente que sobre a totalidade dos dados de fluxo foram corretamente migrados.

Utilização de planos de migração

Esta migração funcional pode estar muito longa quando o dossier é muito volumoso. Por outro lado, certas tabelas atualizadas são potencialmente independentes, e poderão então ser migradas em paralelo, tirando assim partido das arquitecturas multi-processadores para acelerar esta fase.

Para permitir de sequenciar ao melhor esta migração, poder-se-á definir AVANT de lançar a validação de dados um plano de migração personalizada. Este plano de migração está descrito pela função nomeada procedimento de migração (que se chamará depois o dossier supervisor). Esta função permite definir as etapas, fases e procedimentos da migração funcional e supervisor. Mais precisamente, um plano de migração corresponde a uma definição dos parâmetros precisos da migração (dossier afetado, número de procedimentos podendo ser paralelizados, política de encadeamento das tarefas, lista de execução). Um plano de migração está criado por recópia de conjunto dos elementos ativos do porcedimento de migração. Este conjunto completo de procedimentos está fornecido em standard, permitindo de encadear de maneira exaustiva os tratamemtos realizados pelo software na fase de migração. A descrição sucinta dos procedimentos está descrita num documento dedicado.

É possível , nesta lista, de definir os procedimentos específicos médio no registo de tratamentos complementares conforme à metodologia definida no anexo seguinte. Estes procedimentos específicos serão inseridos entre os procedimetos standard de maneira apropriada.

Desde logo que um plano de migração foi definido, pode-se, depois este plano, proceder ao seu lançamento, à sua interrupção temporária, na retoma de sua execução, na visualização do seu estado de avanço.

Quando um dossier é um dossier de uma volumetria razoável, cuja migração não necessita de planificação particular, é inútil de criar um plano de migração. Com efeito, na ausência de plano de migração definido, a operação de validação do servidor vai criar automaticamente um plano de migração. Este plano de migração terá por código do dossier, exceto se este código correspone já a um plano de migração que não esteja no estatuto Em espera. Se isso é o caso, o plano será criado com um código pré-definido sob a forma MIGmmddM##, mme dd sendo os números do mês e do dia de lançamento, ## sendo um número sequencial.

Por contra, se deseja personalizar as opções de encadeamento de migração, poderá criar um plano de migração cujo código corresponde obrigatóriamente ao nome do dossier. Esta criação será feita no dossier supervisor antes lançamento da validação de dossier. Desde logo que um tal plano de migração existe com o estatuto Em espera, será utilizado pela migração funcional do dossier.

Nota : Um plano criado com um nome diferente do nome a migrar, não será jamais utilizado pelos automatismos da validação do dossier. Um tal plano está reservado para um lançamento manual.

Desenvolvimento das operações de um plano de migração.

Um plano de migração está caracterizado por um código dossier, e 4 parâmetros :

um intitulado indicativo
o número de procedimentos susceptíveis de serem lançados simultâneamente Este número constitui um máximo possível Apenas os procedimentos paralelizados serão lançados simultâneamente. Atenção, este número está limitado pelo número de tarefas batch susceptíveis de serem executados simultâneamento (definidos na função de parâmetrização do servidor batch),
Um indicador especificando se os procedimentos devem ser lançados automaticamente em se encadeando segundo a lógica definida pelo plano. Se não é o caso, o encedeamento dos procedimentos descritos no plano deverá ser feito manualmente.
Um indicador assinalando se os procedimentos pós-migração devem ser encadeados na migração ela mesmo. Estas operações são caracterizadas a seguir.

Se o plano de migração está criado por defeito na revalidação do dossier, é criado com os valores :

Número de tarefas simultâneasao valor do parâmetro NBRTACSIM ou (se não existe) a 2,
encadeamento automático a Sim,
Operações pós-migração a Sim.

Será sempre permitido ao utilizador de modificar estes valores depois a função de controlo do plano de migração.

No ecrã associado ao plano de migração, encontra-se a lista ordenada dos porcedimentos do plano. Botões lhe permitem de controlar globlamente a execução do plano :

em lançado sua execução.
em suspendendo o lançamento de novos procedimentos
em interrompendo todos os procedimentos em curso
em lançado sua execução.

Cada linha do plano materializado uma etapa de execução, caracterizada por :

O código do procedimento, e seu intitulado.
a etapa e a fase cujo faz parte o procedimento.
O módulo funcional ao qual está afixado o procedimento.
A fila de execução.

As etapas da migração permitem cortar a migração funcional. Tanto que ao menos um procedimemnto ligado a uma dada fase não está terminada, as fases seguintes não podem ser lançadas. As fases são anexadas às etapas seguintes :

A etapa de inicialização é um etapa preliminar que se executa em tudo primeiro. Ela não está utilizada a este dia e permite a procedimentos específicos de se executar antes a migração ela mesmo.
A etapa de tronco comum permite de migrar os dados utilizados pelas etapas seguintes.
A etapa módulo permite realizar as migrações ligadas a cada módulo funcional. Uma operação desta etapa está associada a um módulo funcional : esta associação está puramente documentário, e não constrange a execução. Assim, das migrações de dados ligados a módulos diferentes podem ser executado em paralelo se eles estão na mesma fase. O seu lançamento se fará na ordem dos módulos, depois as filas de execução.
A etapa pós-migração permite realizar as operações de sincronização ou das atualizações secundárias cuja execução não é obrigatória para recomeçar a funcionar em modo menos degradado. Ela pode ser utilizada por exemplo para diferir as migrações de dados antigos. Falta todavia notar que, mesmo se ela não é obrigatória para retomar a exploração, ela deverá mesmo assim ser realizada posteriormente para que a lista de um dossier seja considerado como completamente migrado. Estas operações pós-migração são lançadas por defeito num plano de migração, mas podem ser desengatadas. Elas estão listadas num parágrafo dedicado do anexo descrevendo os procedimentos de migração

Numa etapa, encontram-se os procedimentos unitários organizados em fases e filas :

Dois procedimentos definidos na mesma fase são reputados ser executáveis simultâneamente, e devem então ser independentes. A afetação de um procedimento standard a uma fase dada não pode ser alterada. Tanto que todos os procedimentos de uma fase não são terminadas, a fase seguintes não pode ser lançada.
A ordem de fila está simplemente uma ordem preferencial de lançamento, mas pode ser alterado, compreendido por procedimentos standard, no momento da definição do plano.

Expurgo final das tabelas de movimento

Esta fase é manual Ela será desencadeada pela execução do tratamento TRTMIGDEL depois a função de execução de tratamento. Sua execução provoca a supressão de todas as tabelas levando o código atividade MIG.

Como esta fase é irreversível, importa de ser bem assegurada previamente que os tratamentos de migração se são bem desenvolvidos.

Na medida onde falta guardar as tabelas temporárias no dossier não constitui em nada um obstáculo a retoma normal de exploração (isto supõe bem entendido de dispor de suficiente espaço em disco), tudo a fazer permitido de guardar estas tabelas em linha durante algumas semanas de exploração. Poderá assim, em caso de problema reencontrado algumas semanas após a migração, dispor dados de origem com fins de comparação ou de análise.

Exemplo se sequênciamento sobre a migração dos fluxos.

Sejam as operações seguuintes :

na etapa inicialização, 7 operações :

IN1, IN2 na fase 1 (de filas 3 e 7),
IN3 e IN4, IN5 e IN6 na fase 2 (e de filas sucessivas 1 3, 5 9),
IN7 na fase 3,

na etapa tronco comum, 6 operações :

TC1, TC2, TC3, todas as 3 na fase 1, com as filas 3, 6, 9,
TC4 na fase 2,
TC5 e TC6 na fase 3,

na etapa Módulo, 5 operações :

a etapa MO1, no módulo Contabilidade, com a fase 2 e a fila 1,
as etapas MO2 e MO3, no módulo Stocks, nas fases respetivas 1 e 2, com as filas respectivas 1 e 2,
as etapas MO4 e MO5 , no módulo Vendas, com as fases respetivas 1 e 2, com filas 1,
as etapas MO6 e MO7 , no módulo Compras, com as fases respetivas 1 e 5, com filas 1,

Supomos ao presente que o plano de migração seja lançado com um encadeamento das tarefas, e um número máximo de 2 procedimentos em volta simultâneamente. O encadeamente poderá então ser o seguinte :

Os procedimentos IN1 e IN2 são lançados nesta ordem.
Supomos que o procedimento IN2 se termina o primeiro. Tanto que o procedimento IN1 não está terminado, nenhum outro procedimento será lançado, porque os procedimentos estão numa fase onde uma etapa de fila superior.
quando o procedimento IN1 será acabado. os procedimentos IN3 e IN4 serão lançados na ordem.
Se o procedimento IN4 se termina antes o procedimento IN3, o procedimento IN5 será lançado Se ela termina antes que o procedimento IN3 esteja terminado, o procedimento IN6 será lançado e voltará ao mesmo tempo que o procedimento IN3 continua.
Quando os procedimentos IN3 e IN6 serão terminados todos os dois (e apenas a este momento), a etapa de inicialização será terminada.
Os procedimentos da primeira fase da etapa Tronco comum poderão então se lançar : Então os procedimentos TC1 e TC2, depois TC3, que se lançará desde que um dos dois procedimentos procedentes terá terminado. Atender-se-á que os três procedimentos TC1, TC2, TC3 sejam todos terminados para lançar TC4, que retornará apenas poisque não há outro nesta fase. Em seguida, lançar-se-á TC5 e TC6 que voltarão em paralelo.
Quando os procedimentos TC5 e TC6 serão todos os dois terminados, poder-se-á passar às tarefas da etapa módulos.
Lançar-se-á então os procedimentos MO2, depois MO6 (na ordem, estes procedimento girando em paralelo); depois, desde que um dos procedimentos MO2 e MO6 será terminado, o procedimemto MO4, que é o seguinte na ordem fase/módulo/fila, será lançada em paralelo com aqueles dos procedimentos MO2 e MO6 que não está terminada.
Entender-se-á em seguida que os procedimentos precedentes sejam finitos, depois lançar-se-á os procedimentos MO1 e MO3, procedimentos da fase 2. Depois enterder-se-á a todas as tarefas precedentes sejam terminadas.
Lançar-se-á então MO7, que é a única na fase 5.

Exemplo se sequênciamento sobre a migração dos fluxos.

Desde logo que a revalidaação do dossier se está bem terminada, o dossier está acessível sem restrição pela sua utilização (pode estar de maneira restrita se certas operações pós-migração foram deferidas).

Resta então a verificar e a adptar certas parametrizações funcionais. Isto está descrito no documento descrevento os pós-requisitos funcionais.