É isso, brincadeiras à parte - vamos falar sobre o eterno. Neste post, você não encontrará um jato de alegria ou um indício da facilidade de ser. Porque é para quem lutou e procurou, passando cada nova rodada de atualização do Siebel. Desde 2013, a Oracle realiza uma campanha para modernizar fundamentalmente seu sistema de CRM. Até agora, já experimentamos sete (de IP13 a IP19) pacotes de inovação. Até 2013, os lançamentos eram lançados a cada 2 a 3 anos, os últimos 5 a 6 anos as atualizações do Siebel eram publicadas com muito mais frequência, mantendo um cronograma claro: lançamentos menores (patchset) eram lançados mensalmente, versões fundamentalmente novas (principais) eram publicadas anualmente e, muitas vezes, isso significava a necessidade do cliente processamento global ou mesmo "reintrodução" do seu sistema. Para simplificar as atualizações do Siebel, o fornecedor desenvolveu o IRM (Incremental Repository Merge) - uma funcionalidade que facilita o processo de instalação de novas versões com pacotes de inovação. Será discutido.
Princípio IRM
Para atualizar o sistema para uma nova versão com o Pacote de Inovação, você deve atualizar o repositório do sistema. Para fazer isso, mesclar com o repositório da nova versão.
O repositório são os metadados do sistema, ou seja, Esquemas de tudo o que é sua funcionalidade. Durante o projeto, os desenvolvedores consultores (clientes do Siebel) fazem milhares de alterações no repositório. No entanto, na entrega da versão da Oracle, essas alterações estão ausentes e o próprio fornecedor, modificando o sistema, adiciona novos metadados e geralmente pode processar completamente um esquema de objeto específico.
Obviamente, é necessário um mecanismo aqui que permita combinar perfeitamente as alterações feitas pelo consumidor do sistema com os novos desenvolvimentos da Oracle. Para isso, o IRM foi criado.
Tarefas resolvidas durante a atualização do Siebel- Preparando repositórios e ambientes para consolidação.
- Integração direta em um ambiente de atualização (DEV) (IRM).
- Análise e resolução de conflitos.
- Aplique alterações ao ambiente de atualização.
- Teste de regressão.
- Correção de todos os defeitos que apareceram durante a atualização.
- Migrando de um ambiente de atualização para a pré-produção e para a produção.
Quais são os benefícios de mudar para IP17 +- Novo mecanismo: OpenUI - a capacidade de configurar mais profundamente a interface, aumentando a usabilidade do sistema.
- A análise da funcionalidade do comportamento do usuário no sistema (Usage Pattern Tracking) criará um UX exclusivo.
- Suporte entre navegadores: o IE não é mais uma limitação - agora você pode trabalhar no Edge, Firefox, Chrome e Safari.
- A ferramenta WebTools (Composer) permite fazer alterações na interface e na lógica de negócios do sistema a partir de um navegador, sem a necessidade de uma reinicialização do servidor, ou seja, sem tempo de inatividade. A prototipagem de desenvolvimento é mais rápida.
- Tecnologia CI / CD, automação de transferência de patches, desenvolvimento paralelo, autoteste.
- Suporte à tecnologia de integração REST, que é bem aplicável ao integrar com portais de clientes.
- Inovações do setor: da criação de belos painéis analíticos na popular biblioteca JS às tecnologias de Big Data e Machine Learning.
A chave para uma atualização bem-sucedida
O IRM define um conjunto de discrepâncias em objetos e propriedades presentes no repositório original, na versão do cliente e na nova versão. A funcionalidade permite, com base na decisão do desenvolvedor, escolher um método para combinar objetos e, no último estágio, iniciar um processo efetivo de migração do repositório atualizado do ambiente de atualização para o produtivo.
Durante a fusão, surgem
conflitos , ou seja, diferenças entre as propriedades do objeto do repositório atual e o mesmo objeto do repositório da nova versão.
Conflitos não críticos são discrepâncias em objetos que não foram afetados pelo cliente, ou seja, discrepâncias entre o repositório original e o novo. 99% desses conflitos são resolvidos em favor de um novo repositório.
Conflitos críticos são diferenças de objeto entre o repositório do cliente e o novo repositório.
Se você seguir a metodologia Oracle desde o início do projeto, as atualizações subsequentes exigirão custos mínimos. Infelizmente, porém, muitas vezes as melhores práticas da Oracle são sacrificadas ao atender a determinados requisitos do cliente. Por exemplo, as tabelas do sistema às vezes são alteradas diretamente pelo banco de dados, que não é corrigido no repositório Siebel. Ou eles alteram as chaves do usuário (Reino Unido), dimensões e tipo de colunas padrão de tabelas padrão, o que a Oracle recomenda enfaticamente que não faça. Isso torna impossível reconstruir automaticamente a tabela durante a migração para a produtiva e exigirá muitas manipulações manuais com as tabelas e os dados. Além disso, alterar as chaves e colunas padrão pode afetar o desempenho de novos processos desenvolvidos para a nova versão do Siebel.
Portanto, é importante que o sistema seja implementado sob a supervisão de profissionais certificados com ampla experiência em implementação.
No entanto, o mais importante no projeto de atualização é o planejamento competente do processo, durante o qual é necessário resolver vários problemas ao mesmo tempo.
Infraestrutura da solução- Quem configurará a infraestrutura:
- implantar servidores
- definir o SO
- configurar o RBS
- Descrição do ambiente de atualização. Onde faremos o IRM?
- Descrição do ambiente de teste. Como vamos testar (incluindo sistemas externos e integração)?
- Descrição do ambiente de implementação. Atualizaremos o produto atual ou configuraremos um ambiente de produção paralelo?
Plano detalhado do projeto (levando em consideração a distribuição de responsabilidades entre o cliente e o contratado)- Deve-se levar em conta que será necessário “congelar” o trabalho de introdução de novas funcionalidades no produtivo.
- Incluindo você precisa considerar que precisará reinstalar todos os pacotes funcionais que entraram no produtivo após o início do projeto de atualização.
Plano de teste- Scripts de teste de regressão necessários.
- Identifique os responsáveis e determine a equipe de testadores do CRM e dos sistemas externos.
Plano de implementação- Faça uma lista de verificação do trabalho de introdução da atualização no produtivo.
- Faça um plano de reversão (sim, sim!;), Caso ocorra um acidente durante a atualização.
Separadamente, faz sentido realizar uma auditoria completa do sistema (ou mesmo solicitá-lo a um fornecedor) para descobrir quais violações de metodologia e erros técnicos de implementação foram cometidos pelo desenvolvedor. A auditoria é conduzida por especialistas certificados da Oracle, os resultados são registrados na forma de protocolos "proprietários" do Oracle Siebel:
- Relatório de configuração (erros ou violações na configuração da lógica de negócios)
- Relatório de integração (erros ou violações nos objetos de integração)
- Relatório de script (erros ou violações em módulos programáveis)
- Erros nos processos (erros no fluxo de trabalho e funções automatizadas)
O fato é que erros podem ocorrer na funcionalidade modificada. No estágio de teste de regressão da solução combinada, será necessário entender exatamente qual erro apareceu como resultado da combinação e qual foi originalmente.
Problemas mais importantes de atualização do SiebelIRM mais recente ou Como atualizar para o Siebel (IP19) mais recente
Nos últimos 2 anos, grandes mudanças ocorreram no sistema Siebel, o que também levou a uma mudança na abordagem de atualização do sistema.
As principais alterações estão relacionadas ao lançamento do IP17 em 2017 e suas atualizações subsequentes.- O modelo de dados do sistema foi reformulado, o fornecedor recusou os arquivos de compilação SRF usados na inicialização do servidor. Um Repositório de Tempo de Execução apareceu, o que permite que você faça alterações na configuração do sistema sem reinicializá-lo.
- O Siebel Web Server se tornou um componente autônomo do Siebel; a partir desse momento, componentes como IIS e Apache de fabricantes terceirizados não são mais necessários. O Siebel WebServer é chamado Application Interface (AI), que é executado com base no Tomcat-container. Todas as conexões com o AI são feitas apenas via HTTPS, ou seja, todo o tráfego é criptografado por padrão. A AI tem suporte total ao REST para solicitações de entrada e saída (a tecnologia REST oferece grande flexibilidade na instalação de melhorias no sistema e no processo de atualização de repositórios).
- O componente Gateway foi atualizado (agora é chamado de Gateway Dinâmico). Destaca-se o balanceamento interno entre componentes reprojetado. O Gateway (Gateway Elastic Load Balancer) agora é responsável por ele, o que torna o sistema de balanceamento de carga mais flexível - anteriormente essa função era executada pelo servidor de aplicativos.
- O sistema suporta oficialmente o banco de dados Oracle 12 (o suporte para o banco de dados Oracle 11g está completo).
Em 2018, a Oracle mudou a política de lançamento do Siebel CRM- Todas as inovações e correções futuras serão entregues como atualizações, ou seja, conjuntos de patches instalados do kit de distribuição para a versão atual (começando com IP17). Eles conterão inovações indicadas anteriormente pelo fornecedor na estratégia de desenvolvimento do sistema.
- Os nomes do conjunto de patches ficarão mais claros, porque as versões são lançadas mensalmente: por exemplo, o número 18.4 significa "abril de 2018".
- O novo modelo de entrega começará com a versão 18.4. A versão mais recente do modelo antigo era 17.6. Para ir de 17.6 a 18.4, você só precisa instalar o kit de distribuição (como um patch e não como uma atualização do IRM). As atualizações mensais subsequentes podem conter funcionalidades para as quais você precisa baixar um pequeno pacote de alterações por meio de um utilitário especial. Além disso, todas as atualizações serão cumulativas.
- Devido à mudança no modelo, os clientes que mudaram para o IP17 não enfrentarão mais o problema da falta de um patch para sua versão do sistema. Ao mesmo tempo, o processo de atualização do sistema é bastante simplificado, o custo do suporte é reduzido e a introdução de funcionalidades inovadoras é acelerada.
- Para atualizar, por exemplo, para a versão 19 de versões anteriores do Siebel (até 17), será necessário implementar uma atualização padrão para a versão 17 e, em seguida, usar o novo modelo de atualização.
Alterações na abordagem para atualizar para IP17 +
Ao projetar a infraestrutura e realizar o dimensionamento, é necessário considerar a nova infraestrutura de servidor IP17. Os requisitos de ferro serão aumentados, porque Repositório de tempo de execução requer mais recursos. O balanceamento à prova de falhas dos novos componentes Application Interface e Gateway recomenda 3 componentes em vez de 2. Você precisará revisar e migrar a configuração e os perfis do servidor para a nova arquitetura IP17.
Também será necessário transferir todos os artefatos da web, como modelos HTML, JS, CSS, etc., para o novo servidor da web da Interface do Aplicativo. A propósito, todos os artefatos da web acabarão sendo movidos para o repositório do sistema.
As próximas etapas são atualizar o sistema operacional e o banco de dados para as versões suportadas (é necessário verificar a guia de certificação do software Siebel para obter suporte Oracle) e emitir o certificado HTTPS correto.
Por fim, você precisará iniciar o IRM pela última vez, e outras atualizações de versão passarão simplesmente pela instalação de patches.
Se, paralelamente à atualização para o IP17 +, você estiver desenvolvendo novas funcionalidades na versão atual do sistema, será necessário testar novamente e atualizar a documentação que o acompanha. E desenvolvedores e administradores são treinados para trabalhar com a tecnologia Workspace, a Ferramenta de Migração e o novo Siebel Infrastructure Management Console.
Você pode determinar a abordagem da atualização, que depende da sua versão atual, nesta tabela:
*** Para obter mais informações sobre as versões SEA e SIA Siebel CRM, consulte o artigo
1514115.1 do My Oracle Support.
Moral
Obviamente, esses projetos exigem o envolvimento de consultores experientes (bem, sem eles), capazes de prever e contornar armadilhas, planejar com competência um processo de atualização no qual o cliente não ficará com nada. I.e. minimizar e até eliminar os riscos de inatividade prolongada do sistema, perda de dados, erros críticos nos processos de negócios após uma atualização. Por exemplo, a escolha incorreta de uma chave de tabela pode levar ao processamento em larga escala de processos no sistema - e, em seguida, uma simples atualização corre o risco de se transformar em um projeto por vários meses.
Maxim Chugunkin, chefe do grupo de arquitetura de sistemas, Jet Infosystems