Quando uma nova implementação de ERP é planejada, geralmente é um processo bem planejado, em vários estágios. Com base na minha experiência de converter dados legados no Oracle E-Business Suite, vou compartilhar algumas coisas sobre esse processo.
A propósito, passei cerca de 7 anos da minha vida convertendo dados legados no Oracle E-Business Suite para quase todos os módulos do pacote Oracle E-Business. Trabalhei com equipes nos EUA e em muitos países internacionais.
Não vou discutir as etapas gerais do planejamento e várias fases padrão do ciclo de implementação porque essas são padrão e você não pode evitá-las. No entanto, vou discutir alguns aspectos técnicos que podem fazer a implementação, um processo repetitivo e robusto.
Diga que uma organização está iniciando uma implementação de vanilla do Oracle E-Business Suite. Você planeja suas fases CRP, você planeja todas as personalizações e tudo.
Agora, quando se trata de extrair dados de sistemas legados (e a situação fica complicada quando você tem vários sistemas legados para converter), como você modela a solução?
Neste artigo, vou discutir algumas etapas que eu encontrei para ser muito eficaz em fazer todo o processo de conversão de dados, muito repetitivo e rentável.
Etapas para projetar um processo efetivo de conversão de dados.
1. O que os dados precisam de conversão?
A primeira e principal questão a responder é, quais dados você precisa migrar? Quais módulos Oracle ERP serão usados pela sua organização?
A resposta a esta questão depende da natureza dos negócios e da natureza da implementação do ERP. Mas, é uma informação importante para identificar antes de projetar a estratégia de conversão de dados.
Uma vez que você identificou os dados a serem convertidos, o próximo passo seria projetar a estratégia global de conversão de dados e projetar a solução mesmo antes de configurar o sistema Oracle ERP. Isso permite que a organização otimize o uso de recursos.
2. Projete a solução de conversão de dados.
Isso pode parecer fácil porque a compreensão básica é que o Oracle E-Business Suite vem com um conjunto de interfaces abertas e APIs para converter dados em ERP uma vez que os dados são colocados naquela tabela de interface.
No entanto, o número de validação dos dados legados para passar antes de poder ser realmente convertido, é enorme. É aí que vem a complexidade. Se você não planeja e planeja uma solução robusta, a própria conversão de dados pode tornar-se um assunto muito intensivo e oneroso.
Então, eu recomendo (com base na experiência) que você segue essas etapas de alto nível para tornar esse processo simples de entender e repetível (especialmente se você tiver vários sites da empresa para converter):
1. Defina um formato comum (como um formato de arquivo plano ou formato XML) em que dados de sistemas legados serão extraídos para conversão. O formato de dados deve ser abrangente para cobrir cada campo de dados para cada módulo.
2. Desenhe um mecanismo ETL que possa ler dados no formato definido acima e colocá-lo em uma localização central onde as validações podem ser executadas para garantir a qualidade dos dados. Isso permite que você extraia dados de sistemas de origem e comece a executar validações básicas de qualidade de dados (como campos NOT NULL, verificações de comprimento de campo, etc.), até mesmo as equipes de implementação do ERP são implantadas no site.
3. Estenda o motor ETL para tirar dados limpos da localização central e validar contra configurações ERP, transformar dados fonte em um formato que as interfaces abertas Oracle ERP aceitam e, finalmente, carregar dados válidos nas tabelas de interface aberto do Oracle.
4. Ter configurações de Oracle ERP concluídas e solicitações simultâneas prontas para executar os programas de interface aberta depois que os dados são carregados nas tabelas da interface.
5. Para interfaces que não estão prontas para executar programas de solicitação concorrentes (ou os módulos que sabem ter problemas), crie programas concorrentes usando APIs Oracle para carregar esses elementos de dados das tabelas de interface abertas ou tabelas personalizadas conforme sua situação exige.
3. Implante as equipes de conversão de dados.
Uma vez que o mecanismo de conversão de dados está pronto e os processos estão documentados, é hora de implantar os engenheiros de conversão de dados no site que precisa ser convertido.
O papel da equipe é extrair dados dos sistemas legados no formato especificado pelas especificações do mecanismo de conversão e executar as rotinas de carga e validação repetidamente até que os dados legados se qualificem para os padrões mínimos de qualidade necessários às rotinas de validação de conversão de dados.
Uma vez que a validação básica é feita e os dados seguem os padrões de qualidade mínimos, o tempo de passar para o próximo passo da ETL de conversão de dados que validará os dados legados contra as configurações do Oracle ERP para sua organização. Depois que esta etapa é corretamente concluída, os dados são empurrados automaticamente para as tabelas de interface aberta para conversão final por rotinas padrão / customizadas.
4. Final QA & amp; Cargas de Produção.
Depois de completar um par de rodadas de conversão de dados com os dados legados, dependendo do seu plano de projeto geral para o site em questão, o tempo necessário para levar esse processo para o ambiente de QA.
A conversão de dados no ambiente QA é suposto ser como se estivesse acontecendo na produção. Os dados que já foram corrigidos durante fases anteriores são passados através do mecanismo de conversão de dados ETL contra configurações de produção Oracle ERP.
Uma vez que as cobranças de QA são concluídas com sucesso, você está pronto para levar seu sistema herdado ao vivo no sistema ERP oracle.
Compartilhe esta história, escolha sua plataforma!
Sobre o autor: Kumar Gauraw.
Kumar Gauraw é um profissional sênior de TI com mais de 16 anos de experiência enquanto atua em diversas capacidades nas empresas da Fortune 500 no campo da Integração de Dados, Modelagem de Dados, Migração de Dados e arquitetura de soluções de Datawarehousing de ponta a ponta. A Kumar possui uma forte experiência em um amplo espectro de ferramentas e tecnologias relacionadas ao BI e à Integração de Dados.
Estratégia de conversão de dados Oracle
Você sabe de quantas maneiras? podemos inserir os dados na aplicação oracle. A maioria de nós pode adivinhar três maneiras diferentes como:
Os dados podem ser inseridos usando as telas do aplicativo. Os dados podem ser inseridos usando a Interface do Sistema Aberto da Oracle. Os dados podem ser armazenados diretamente na tabela do banco de dados.
Mas aqueles que trabalham em algum ambiente empresarial complexo podem descobrir alguns dos mais:
Software de terceiros (para as terceiras opções) Taviz (anteriormente SmartDB), que é a ferramenta EAI. Crossroads See Beyond (anteriormente STC) Vitria Data Loader: eles têm macro habilitado folha de cálculo tipo de ferramenta More4apps.
E há muitos mais, mas a maioria deles é usada para dados mestre e alguns casos para dados de transações via interface Open, se disponíveis.
A importância da conversão / migração de dados e das interfaces dentro de qualquer projeto de implementação de ERP não pode ser ignorada. Uma vez que a ERP trata principalmente de dados que finalmente conduzem à Informação, é igualmente importante compreender o aspecto de como os "dados" são importantes em qualquer sistema ERP na fase de implementação, independentemente da operação simples e unificada. Desde que estive envolvido em algum projeto de aplicativos de grande transformação do Oracle, por isso, é uma ótima causa para compartilhar algumas informações sobre o ponto de contato de integração, conversão / migração e desenvolvimento de interface para alguém que é muito novo para o mundo ERP, bem como para o aplicativo Oracle.
Vamos começar com alguma situação comum, temos três casos,
O Cliente está executando lá algumas aplicações de TI desenvolvidas em casa que atendem a maioria das necessidades da empresa. Agora, a administração decidiu ir para qualquer solução ERP, então a pergunta sobre o que acontecerá para os dados que já estão no aplicativo existente? Outra situação já está usando o ERP.
uma. Eles querem atualizar para a versão mais alta ... Considerando que a estrutura de algumas tabelas é alterada? Digamos 10,7 a 11i.
b. A empresa é adquirida ou fundida com alguma outra empresa e todos os dados precisam se mudar para a empresa-mãe ou filho.
c. Eles querem habilitar alguns módulos adicionais dentro da aplicação existente. Existem poucos dados que interagem com os dois casos independentemente da tecnologia de banco de dados para onde os dados estão indo e vindo com base em necessidade.
A resposta do 1 é migração de dados e 2 é mais pronunciada como conversão de dados onde, como terços, é popularmente conhecida como Interface. As maneiras como eles estão funcionando não têm muita diferença, mas é mais importante entender a definição e a necessidade. Nunca encontrei nenhuma grande diferença entre migração / conversão, a menos que exista uma enorme transformação de dados, as únicas coisas que se descobrem são a conversão pode exigir algumas etapas menores para executar, já que a suposição é que as coisas relacionadas foram já atendidas antes da execução da atividade .
Vamos entender assim: a migração de dados como um processo de movimentação de volumes necessários (e na maioria das vezes muito grandes) de dados dos sistemas existentes de nossos clientes para novos sistemas. Os sistemas existentes podem ser tudo, desde infra-estruturas de TI customizadas até planilhas e bancos de dados autônomos. A conversão de dados pode ser definida como um processo de conversão de dados de uma forma estrutural para outra, de acordo com os requisitos do sistema ao qual ela é migrada.
Deixar uma unidade profunda para entender melhor:
Por que a conversão / migração é mais importante no ERP?
Antes do Go-Live no ambiente de produção, os dados mestre necessários, os dados da transação aberta e os dados históricos da transação precisam ser importados dos aplicativos legados antigos para aplicativos Oracle. Uma vez que a estrutura de dados e o design de dados em sistemas legados são diferentes dos aplicativos Oracle, os dados precisam ser enviados / convertidos de acordo com as regras de negócios para atender o requisito da Oracle. Os dados iniciais podem ser migrados por qualquer outro meio, conforme discutido acima, dependendo do paramater como o Volumn, o uso, a complexidade, a regra do negócio etc.
Como definimos a conversão de dados.
Processo onde os dados existentes do antigo sistema do cliente são extraídos, limpos, formatados e instalados em um novo sistema. Estes podem ser manual ou automatizado. A grande diferença é que estes são um único processo único que requer testes e preparação extensivos. Eles devem ser executados e executados antes de um sistema entrar em produção.
Estes são programas para conexão entre Dois Sistemas para Sincronizar os Dados. Eles podem ser manual, em lote ou em tempo real. Usado repetidamente e, portanto, deve ser projetado e construído da forma mais eficiente possível. Estes podem ser desencadeados por um evento (como executar um programa simultâneo) ou pode ser programado para executar em determinado momento. Pode ser muito caro para construir e manter.
A conversão / migração / interface possui ciclo de vida.
Sim, eles têm, porque eles têm um esforço significativo exigido no desenvolvimento e design e implementação.
O Designer Funcional trabalha com os proprietários de empresas para determinar o mapeamento de dados e completar o design funcional usando os Modelos de Design. Se a interface / conversão for automatizada, o Designer Técnico converte os requisitos funcionais em especificações técnicas para a construção dos programas de interface. O desenvolvedor usa os designs funcionais e técnicos para criar e testar os programas de interface / conversão. Mais rodadas de testes são realizadas até que a interface / conversão seja migrada para o ambiente de produção para implantação.
A conversão é assumida como uma atividade única, mas nunca parece pequena atividade que pode ser realizada com alguns dias.
Como a conversão e a interface diferem?
Existem bons números de parâmetros nos quais eles podem ser categorizados. Pegue alguns deles:
As conversões de frequência são uma vez que as interfaces de eventos estão em curso. Ocorrência nas conversões da linha de tempo do projeto executadas antes das interfaces de produção executadas durante a produção. As conversões de execução de execução são interfaces de lote podem ser lotes ou em tempo real. A conversão de complexidade tem muito complexo, depende totalmente do mapeamento de dados atividade. Coordenando com outros sistemas tornam as interfaces mais complexas. Manutenção A modificação da interface é uma tarefa de custo médio.
Você aprendeu como a interface é diferente da Conversão / Migração. Agora, vamos ter alguns tipos de interfaces:
Normalmente em qualquer sistema, existem dois tipos de interface como:
Uma interface de entrada recebe dados de um sistema (legado) e insere em tabelas de interface aberto do Oracle. Uma interface de entrada típica seguiria estas etapas: Extraia dados do sistema antigo para um arquivo plano. Use SQL * Loader ou ferramenta equivalente para carregar informações em uma tabela temporária. Escreva um programa PL / SQL para tirar dados da tabela temporária e inserir nas Tabelas de interface aberta. Através do gerenciador concorrente em aplicativos Oracle, execute o programa Oracle Interface padrão para transformar tabelas de interface em dados Oracle.
o Uma interface de saída tira dados das tabelas do Oracle e insere-a em um sistema externo (através de tabelas ou arquivos planos).
o Uma interface de saída típica seguirá estas etapas:
- Escreva um programa PL / SQL para extrair dados de tabelas base Oracle em um arquivo plano.
- Use um programa personalizado para ler esses dados e publicá-lo no sistema herdado.
Temos alguma outra maneira padrão de fazer a interface?
Open Interface é uma interface baseada em tabela registrada como um processo simultâneo de processo de registros em lotes. gerou (Pro-C) ou programas baseados em PL / SQL. API (Application Program Interface) é um procedimento armazenado baseado em parâmetros que impacta diretamente as tabelas base de dados. pode ser chamado a partir de interfaces abertas do Oracle, Forms, Reports. O EDI (Electronic Data Interchange) usa definições de dados padrão da indústria (US / ANSI / X.12) para transmissão de documentos como PO, Faturas, Ordem de Vendas, etc. Oracle fornece algumas transações EDI através do Gateway EDI. (Enterprise Application Integration (EAI ) as soluções são frequentemente utilizadas quando existem requisitos de integração complexos.
O que é uma tabela de interface aberta (OIT)?
Para interfaces de entrada, a tabela de interface é a tabela intermediária onde os dados do aplicativo de origem reside temporariamente até ser validado e processado em uma base base Oracle através de um programa concorrente de importação padrão. Open Interface Tables são tabelas Oracle padrão. A Oracle usa as OITs para fornecer uma interface simples às tabelas de base do Oracle. Oracle possui uma lista de toda a interface aberta que o oracle ofereceu no produto.
A maioria dos módulos Oracle possui programas de importação padrão (processos simultâneos) para facilitar as interfaces de entrada personalizadas. O processamento específico realizado varia de acordo com a aplicação. Esses programas extraem dados das tabelas de interface abertas, validam os dados e, em seguida, inserem em uma ou mais tabelas base Oracle. Após a conclusão bem-sucedida do processamento, o programa exclui as linhas processadas da tabela de interface ou as marca como concluídas. Dependendo da importação, os erros podem ser vistos de várias maneiras (relatórios de exceções, tabelas de erro, formulários, etc ...).
Exemplos de programas de importação padrão:
GL: Importação de jornal AP: contas a pagar Interface aberta AR: interface do cliente INV: item Importar AR - Autoinvice.
Ok, isso é tudo sobre o briefing de Conversão e Interfaces. Vou escrever mais algumas ferramentas usadas para conversão / interface e discutirei alguns detalhes detalhados sobre um projeto de conversão / migração e compartilharemos algumas informações sobre como e onde os documentos da AIM se encaixam em projetos de conversão e migração. Então, fique atento a esse espaço para mais algumas coisas para conversões ... Até mais do que o seu comentário e requta você para compartilhar algumas informações relacionadas a essas áreas.
oi, há uma API para importação de revistas em aplicações R12.
Diga-me qualquer um dos api para importar.
Muito obrigado por publicar notas úteis no site. Eu sou um visitante regular.
A conversão de dados em uma implementação pode enfrentar 2 cenários:
1) A nova instância disponível para implementação e uma empresa vai continuar a viver na instância.
2) Uma instância já utilizada (outras unidades operacionais são configuradas, etc.). Nesse caso, provavelmente talvez devêssemos olhar para quais são os campos já utilizados (por exemplo, atributos na tabela de itens mestre para inventário)
Com o acima, talvez devêssemos trabalhar em conformidade para preparar os modelos de conversão de dados. Você tem algum documento de ajuda sobre como preparar um modelo de conversão de dados para várias entidades (por exemplo, itens, abrir pedidos de vendas)
Muito obrigado novamente & # 8230;
Por favor, deixe-me saber sobre as regras (Especificado abaixo) ao preparar o CV 40 - Functional Document como parte de Coversions (Migration).
Regras de chave estrangeira.
Regras do valor padrão.
Em detalhe, o significado dessas Regras & amp; Existência, para obter mais compreensão, faça uma conversão ex: Ar Open Invoices, neste ponto de vista como mapear esta tarefa (Ar Open Invoices) para as Regras acima mencionadas.
Encaminhe qualquer documento disponível nas conversões e amp; Regras.
Espero que seja claro, Aprecie antecipadamente todas as suas Respostas.
O que são códigos rápidos?
Como identificar os códigos rápidos, faça o mapa em perspectiva da conversão de AR Open Facturas?
Como identificar as validades da chave estrangeira para uma conversão específica, tome qualquer outro exemplo e amp; mapa.
Por favor, informe-nos sobre a validação rápida do código.
A informação fornecida aqui é realmente útil para os profissionais que são novos neste campo.
Isso realmente me ajuda a entender os conceitos básicos de migração de dados e amp; processo de conversão em aplicativos Oracle.
É exatamente o que eu estava procurando.
Muito obrigado pelos seus esforços.
Você tem um escopo completo de trabalho para ERP Preparação / limpeza de dados para a suite completa da ORACLE?
Muito Obrigado. Salma.
CV.010: migração de dados O documento Stretegy é bom para ter no começo, isso tem detalhes para preparação de dados inteira, bem como atividade de limpeza.
Se você está procurando uma amostra, posso compartilhar com você.
Gostaria de ver a amostra.
Muito obrigado, Salma.
Plz envie-me uma amostra de consulta de conversão do fornecedor.
Você pode compartilhar CV.010: documento de estratégia de migração de dados comigo também, por favor.
Gostaria muito de apreciar o seu trabalho, obrigado por compartilhar informações.
eu tenho uma pergunta.
Suponha que eu quero carregar as informações do arquivo plano para o nível do cabeçalho e nível da linha, neste caso, eu recebo um arquivo plano ou 2 arquivos planos.
Eu sou muito novo, esses aplicativos oracle, então não hesite em responder pequenas perguntas.
Mais uma pergunta é.
como fazer a validação antes de inserir na tabela de interface.
Diga com um exemplo (com validação de coluna)
desde já, obrigado.
O artigo é muito bom para iniciantes como eu. Mantenha-o com o mesmo tempo para nós.
Hi thanx para a informação exclusiva & # 8230; plz send há documentos de fluxo de trabalho com informações completas.
O artigo é muito bom para iniciantes como eu. Desejo saber mais sobre diferentes tipos de conversões, como conversão de gl, conversão de itens, etc., adicione mais tópicos sobre a conversão.
Preciso da sua ajuda se alguém puder.
Na verdade, queremos migrar dados no Oracle eBs:
1- Saldos de abertura GL.
2- Customer Master com saldos iniciais.
3- Mestre do fornecedor com saldos de abertura.
4 & # 8211; Fixed Asstes Master com saldos de abertura.
5 empregado mestre com detalhes de salário.
Alguém pode fornecer-me o Excel Templetes para esses arquivos, eu sou muito apreciado e agradecido por você.
Graças a Sanjit por fornecer informações tão importantes relacionadas às interfaces.
Eu tenho uma pergunta, você pode me ajudar a esclarecer minha dúvida & # 8230;
O que entendi a partir deste artigo que as interfaces devem transferir ou sincronizar os dados de um sistema para outro sistema.
Mas quando sincronizamos os dados dentro de aplicativos oracle de um módulo para outro (digamos OM para instalar a base ou OM para AR), esse tipo de sincronização de dados também pode ser considerado como interface e # 8230;
quando a transferência de dados feita entre aplicativos oracle com algum outro sistema legado (digamos, o cobrança de Genebra), apenas pode ser dito como interface.
Como planejar uma conversão de dados bem sucedida em seu movimento para a Fusion.
Jon Wakefield é consultor sênior da Oracle Line of Business na Velocity e tem mais de 16 anos de experiência funcional e técnica em produtos Oracle, incluindo PeopleSoft, Fusion e Taleo. Como parte da equipe de serviços profissionais da Velocity & rsquo; Jon é responsável pelo novo desenvolvimento e implementação de soluções Oracle. Ele pode ser alcançado em jonathan. wakefieldvelocity. cc.
Muitas organizações estão se movendo para os serviços da nuvem Oracle Fusion, aproveitando os níveis aprimorados de suporte e redução geral no custo de propriedade que o produto oferece. Se a sua organização se prepara para implementar o Fusion (clique aqui para obter algumas dicas úteis sobre como tomar essa decisão), há, é claro, uma série de fatores a serem considerados e planejados de acordo. Nesta publicação, vou me concentrar em um dos maiores, cujo impacto muitas vezes pode ser subestimado: conversão de dados Oracle.
Como o Fusion é um produto SaaS, você não terá acesso para atualizar nenhuma das tabelas e, em vez disso, deve aproveitar as ferramentas de conversão de dados que a Oracle fornece para preencher o Fusion com os dados da sua organização. A principal ferramenta com a qual você trabalhará é o FBL (File-Based Loader), e é crítico para levar o tempo inicial para entender como a ferramenta funciona e quais objetos de negócios ele suporta (clique aqui para o guia do usuário da Oracle e rsquo; lista de objetos).
Carregando dados no Oracle Fusion.
A chave para carregar com sucesso seus dados no Fusion é sobre como você extrai esses dados do seu antigo sistema. O FBL requer que você crie uma série de arquivos delimitados por tubos (.dat ou. csv) contendo todos os dados que deseja carregar no Fusion, formatados de acordo com as especificações do Oracle & rsquo; clique aqui para uma planilha de cada campo suportado e seu formato) . O FBL então importa esses arquivos e preenche as tabelas Fusion de acordo com os valores que você incluiu para cada campo. Você deve projetar um processo para preencher com atenção os arquivos que você considera necessários, certificando-se de que cada valor de campo esteja formatado e posicionado corretamente. Se você fizer isso, reduzirá seus possíveis erros de carga e removerá muitos riscos e estresse do processo de conversão de dados.
Você pode usar qualquer número de opções para conseguir isso, mas para você começar, I & rsquo; fornecerá três abordagens diretas que podem funcionar bem para você. Eles são orientados para o PeopleSoft, pois essa era minha principal experiência antes de aprender o Fusion, mas os conceitos básicos que conduzem cada um também são aplicáveis a outros sistemas de ERP.
3 Opções de Estratégia de Conversão de Dados para o Oracle Fusion Data Loading.
Se você não pensa, a Query pode acomodar o esforço de conversão da sua organização e você não quer criar SQRs, uma boa alternativa poderia ser & hellip;
&cópia de; 2017 Velocity Technology Solutions, Inc. Todos os direitos reservados.
Prasad Bhogle.
Estratégias de conversão de dados na implementação do Oracle E-Business Suite.
Quando se fala sobre a implementação do pacote Oracle E-Business, as questões sobre dados surgem:
Como os dados do sistema legado existentes estarão disponíveis em um novo sistema? Haverá um movimento completo do sistema OLD para o NOVO sistema ou ambos os sistemas coexistirão por algum tempo antes do corte completo? Haverá alguma comunicação necessária entre o sistema OLD e NOVO? O mais importante é como conseguir isso?
Ao discutir sobre essas questões, poucos termos se usam intercambiáveis, viz. Migração de Dados, Conversão de Dados, Interfaces, etc. Todos podem ser trazidos sob um único guarda-chuva / categoria chamado Movimento de Dados.
Este white paper fala sobre várias estratégias / tecnologias que podem ser usadas para a comunicação de dados entre o sistema antigo e o Oracle E-Business Suite. Isso dá a visão geral sobre vários componentes técnicos envolvidos em cuidar da palavra mais importante chamada "DATA".
Este white paper tenta dar uma direção para responder as perguntas acima. Para tornar os dados legados disponíveis para o novo sistema, é necessário efetuar a entrada de dados manualmente ou usar ferramentas como carregador de dados, win-runner que simulam a ação do teclado / mouse e tornam a entrada de dados mais rápida. Se os dados são enormes, a ajuda do programador / desenvolvedor é necessária para criar o programa para automatizar o carregamento de dados. Se dois sistemas vão coexistir por algum tempo e se comunicar uns com os outros, os programas que são executados em intervalos regulares para mover os dados são necessários.
Definindo várias terminologias.
A migração de dados é um processo de mover os volumes de dados necessários (e na maioria das vezes muito grandes) dos sistemas existentes de nossos clientes para novos sistemas. Os sistemas existentes podem ser tudo, desde infra-estruturas de TI customizadas até planilhas e bancos de dados autônomos.
A conversão de dados pode ser definida como um processo de conversão de dados de uma forma estrutural para outra, de acordo com os requisitos do sistema ao qual ela é migrada.
A interface é um conjunto de programas para conexão entre dois sistemas para sincronizar os Dados. Eles podem ser manual, em lote ou em tempo real. Eles são usados repetidamente e, portanto, devem ser projetados e construídos da maneira mais eficiente possível.
Embora a migração de dados, a conversão, as interfaces sejam tratadas de forma diferente, mas as pessoas técnicas não devem diferenciar entre elas. O design de todo o programa deve ser semelhante às interfaces, porque na maioria dos dados de implementação precisam ser movidos várias vezes e por algum tempo o sistema antigo e o Oracle Apps 11i estão ativos. Bottom line se os dados precisam ser movidos programaticamente, ou seja, sem usar ferramentas como carregador de dados ou entrada manual de dados, é melhor projetar o programa que pode ser executado várias vezes como um programa concorrente.
Mais artigos deste autor.
Pesquisar treinamentos.
Depoimentos totalmente verificáveis.
Apps2Fusion - Lista de eventos.
Inquire For Training.
Itens relacionados.
Obter atualizações.
Artigos Mais Recentes.
MENU RÁPIDO.
Artigos populares.
NOSSA EMPRESA.
Sobre o Apps2Fusion.
Apps2Fusion é apaixonado por Fusion Cloud E-Learning e treinamento em sala de aula. O treinamento é o nosso negócio principal e estamos fazendo isso por muitos anos. Trabalhamos duro para aconselhar os trainees com caminhos de carreira certos. Nós publicamos várias revistas Oracle Press, de cinco estrelas, cada uma delas eram as mais vendidas em sua categoria. Nós ajudamos muitos e também podemos ajudá-lo.
No comments:
Post a Comment