🗜️ 🙅🏼 👩🏻‍🔬 Como migrar um processo grande do IBM BPM para Camunda e não parar o desenvolvimento de recursos 📫 ⛵️ 🎋

Olá, meu nome é Denis, trabalho na Tinkoff e faço sistemas de BPM. Neste artigo, mostrarei como migrar do legado de sistemas do IBM BPM para o mecanismo de processo Camunda de código aberto, usando o exemplo de um processo grande. E no final, vou convidá-lo para a quarta reunião em Camunda, que será realizada em 27 de fevereiro em Tinkoff, em Moscou (metrô Vodny Stadion) à noite.

Sistemas BPMS e BPMN como forma de programá-los

A ideia de que através da programação pode ser programada é bem vendida , o mercado está crescendo de ano para ano. Algumas empresas obtêm resultados realmente interessantes.
Para fazer bons projetos e vender com sucesso, os sistemas BPMS, além de "comer" os arquivos BPMN, também devem ser capazes de:

Identifique artistas específicos nos processos
Fornecer interfaces para usuários, implementadores e administradores
Ligue para serviços externos, envie e ouça eventos, etc. Em geral, seja capaz de "cair" no código
Fornecer modelagem e armazenamento de dados
Siga as regras de negócios
Teste tudo o que foi criado

Usamos o IBM BPM BPMS em Tinkoff, o que nos ajudou a desenvolver devido à sua complexidade e cobertura aceitável desses recursos. Mas decidimos recusar.

Razões para abandonar o IBM BPM

Percebemos que, a partir da grande funcionalidade do sistema BPMS, usamos apenas:

Interpretação de arquivos bpmn
Caindo no código

Outras coisas foram transferidas para outros sistemas, por exemplo:

, — , , . , BPMS. , — CRM Siebel.
Siebel CRM-. Siebel , — - UI.
O armazenamento de dados em algum lugar foi transferido para o Siebel - em situações em que muitos consumidores precisam de operações CRUD nos dados e em algum lugar - em aplicativos separados. O IBM BPM permite simular dados em um estilo relacional, ele cria as placas para o modelo. Mas ele armazena tudo em um banco de dados para todos os processos, o que cria conectividade e carga adicionais no banco de dados.
Para regras de negócios, tradicionalmente usamos o IBM ODM e agora estamos começando a usar nossa estrutura Kotlin.
Normalmente, no estilo de desenvolvimento, não aprendemos como testar aplicativos no IBM BPM.

Houve perguntas gerais que não gostamos:

Mudamos para Kotlin e Spring, o que é difícil no IBM BPM.
Muito poucos especialistas ou aqueles que desejam trabalhar com este produto.
Dificuldades no desenvolvimento conjunto de esquemas \ código, essencialmente um modo monopolista de desenvolvimento.
4 3 ( ~40 ), .

Separadamente, vale a pena mencionar o problema de vizinhos barulhentos - as restrições de licenciamento nos forçaram a empurrar muitos produtos em um cluster. Tentamos reutilizar o código comum em diferentes processos de negócios, o que criou dificuldades com sua modificação.

Por exemplo, havia um código de envio de SMS usado por dois produtos - serviços de liquidação financeira e contabilidade terceirizada. Anteriormente, o texto era codificado no nível do componente, mas agora o processo de "contabilidade de terceirização" queria transferir o texto do SMS do processo. Mas o processo CSC não queria isso, mas é necessário fazer alterações em todos os lugares.

Ou bugs banais podem colocar toda a base para que muitos produtos não funcionem, embora não sejam os culpados.

Por que eles escolheram Camunda, meu colega Nikolai escreveu em um post anterior.

O que é um grande processo

Decidimos transferir o grande processo da IBM (no início, porém, treinamos em um pequeno):

Mais de 100 mil instâncias por mês.
Mais de 70 quadrados
Mais de 30 integrações com outros sistemas
Retorno em rápido crescimento

Esse é o processo de abertura de uma conta atual no Tinkoff Business. Não foi possível transferir esse processo em uma abordagem, seria necessária uma pausa de 3-4 meses no desenvolvimento, o que não é muito adequado para o ritmo do desenvolvimento dos negócios.
Decidimos mudar para peças e refatorar tudo o que está à mão. E para resolver o problema de vizinhos barulhentos, fizemos um pedido separado, responsável apenas pelos pedidos de serviços de liquidação financeira.

No nível superior, o processo é assim:
imagem

Regras de transição

No. 1: Parou de cavar

Decidimos parar de criar novos recursos no aplicativo antigo. Quando a tarefa apareceu na lista de pendências, tentamos identificar a caixa \ componente \ serviço ao qual ela se relaciona e reescrever essa coisa do zero no Camunda. Às vezes, a um custo, era 1,2x (x - se eles estavam fazendo na IBM), às vezes - 3x ou 5x.

# 2: Camunda não sabe nada sobre a IBM

Após a refatoração, queríamos apenas desativar o aplicativo antigo, por isso decidimos criar novos recursos no Camunda para que ele não soubesse nada sobre a IBM. Duas coisas nos ajudaram:

Dados comerciais armazenados no Siebel
APIs prontas da Camuda que ajudam a entender completamente como e como o processo terminou.

Como resultado, fizemos um processo na IBM que inicia e recebe o resultado da Camunda:
imagem

No. 3: Longas "tarefas manuais" e processos de colagem

Primeiro, movemos chamadas síncronas simples e de uma etapa para Camunda e tudo funcionou bem. Depois disso, começamos a colar essas coisas nos “processos de negócios” normais, onde as expectativas dos usuários começaram a aparecer.
Os usuários podem realizar suas tarefas por anos, então começamos a ter várias tarefas para corrigir manualmente os processos a partir da lixeira. Vencemos dessa maneira - começamos a considerar o tipo de uma tarefa específica em Camunda e não consideramos o lixo nas tarefas em que é possível uma longa espera.

No. 4: Recurso alternando no garfo

Alguns trechos de código estavam tão confusos que era mais fácil escrever do zero e ver se funcionava bem. Para fazer isso, introduzido no recurso da IBM, alternando com gateways. Enviamos um pequeno fluxo de aplicativos para Camuda e olhamos as canetas, está tudo bem.
imagem

Migrando Instâncias da IBM para Camunda

Por fim, o processo na IBM consistia apenas em chamadas para Camunda e três níveis de processos foram coletados em Camunda. Os processos de negócios em si não mudaram muito, portanto, conseguimos transferir as instâncias antigas da IBM para Camunda para os mesmos pontos de espera. E desligue a IBM.
imagem

O que fazer se você tiver uma situação semelhante

Se você deseja mudar para Camunda com o legado BPMS, então:

Mova o contexto para um banco de dados separado.
Mova interfaces de usuário para um aplicativo separado.
Pare de codificar novas funcionalidades no aplicativo antigo.
Use chamadas unidirecionais para que o Camunda não conheça o sistema antigo.
Comece com caixas pequenas, mas não se esqueça de tarefas personalizadas longas.

Essa abordagem nos ajudou a reduzir o número de incidentes em 14 vezes, o tempo de regressão em 4 vezes, possibilitou a liberação diária e reduziu o custo do teste manual em 4 vezes. Agora, 5 pessoas estão trabalhando no projeto e realizando a mesma quantidade de trabalho que 9 pessoas na IBM. Espero que seus resultados não sejam piores.

Convite para mitap No. 4 por Camunda

27 de fevereiro de 2020 (quinta-feira) às 19:30 em Moscou, Golovinskoye Shosse 5A, Centro de Negócios Vodny, realizaremos outra reunião em Camunda. Você pode se registrar e ler sobre os palestrantes no link . Venha!

Como migrar um processo grande do IBM BPM para Camunda e não parar o desenvolvimento de recursos