⏫ 🥘 👩🏽‍🤝‍👨🏼 Cómo migrar un gran proceso de IBM BPM a Camunda y no detener el desarrollo de funciones 📯 ✊🏼 👍🏼

Hola, mi nombre es Denis, trabajo en Tinkoff y hago sistemas BPM. En este artículo, le diré cómo migrar del legado de sistemas a IBM BPM al motor de procesos de código abierto Camunda usando el ejemplo de un proceso grande. Y al final los invitaré a la cuarta reunión en Camunda, que se celebrará el 27 de febrero en Tinkoff, en Moscú (metro Vodny Stadion) por la noche.

Sistemas BPMS y BPMN como una forma de programarlos

La idea de que a través de la programación se puede programar está bien vendida , el mercado está creciendo año tras año. Algunas empresas obtienen resultados realmente geniales.
Para hacer buenos proyectos y vender con éxito, los sistemas BPMS, además de "comer" archivos BPMN, también deben ser capaces de:

Identificar actores específicos en los procesos.
Proporcionar interfaces para usuarios, implementadores y administradores.
Llame a servicios externos, envíe y escuche eventos, etc. En general, ser capaz de "caer" en el código
Proporcionar modelado y almacenamiento de datos.
Siga las reglas comerciales
Prueba todo lo creado

Usamos IBM BPM BPMS en Tinkoff, lo que nos ayudó a desarrollarnos debido a su complejidad y cobertura aceptable de estas características. Pero decidimos rechazarlo.

Razones para abandonar IBM BPM

Nos dimos cuenta de que, gracias a la gran funcionalidad del sistema BPMS, solo usamos:

Interpretación de archivos bpmn
Caer en el código

Otras cosas fueron transferidas a otros sistemas, por ejemplo:

, — , , . , BPMS. , — CRM Siebel.
Siebel CRM-. Siebel , — - UI.
El almacenamiento de datos en algún lugar se trasladó a Siebel, en situaciones donde muchos consumidores necesitan operaciones CRUD en datos, y en algún lugar, en aplicaciones separadas. IBM BPM le permite simular datos en un estilo relacional, él crea las placas para el modelo. Pero lo almacena todo en una base de datos para todos los procesos, lo que crea conectividad adicional y carga en la base de datos.
Para las reglas comerciales, tradicionalmente usamos IBM ODM, y ahora estamos comenzando a usar nuestro marco Kotlin.
Normalmente, en el estilo de desarrollo, no aprendimos cómo probar aplicaciones en IBM BPM.

Hubo preguntas generales que no nos gustaron:

Nos cambiamos a Kotlin y Spring, lo cual es difícil en IBM BPM.
Muy pocos especialistas o aquellos que deseen trabajar con este producto.
Dificultades del desarrollo conjunto de esquemas \ código, esencialmente un modo de desarrollo monopolista.
4 3 ( ~40 ), .

Por separado, vale la pena mencionar el problema de los vecinos ruidosos: las restricciones de licencia nos obligaron a colocar muchos productos en un solo clúster. Intentamos reutilizar el código común dentro de diferentes procesos comerciales, lo que creó dificultades con su modificación.

Por ejemplo, había un código de envío de SMS que fue utilizado por 2 productos: servicios de liquidación de efectivo y contabilidad subcontratada. Anteriormente, el texto estaba codificado a nivel de componente, pero ahora el proceso de "contabilidad de outsourcing" quería transferir el texto del SMS del proceso. Pero el proceso CSC no quería esto, pero los cambios deben hacerse en todas partes.

O los errores banales podrían poner toda la base para que muchos productos no funcionen, aunque no tienen la culpa.

¿Por qué eligieron Camunda ?, escribió mi colega Nikolai en una publicación anterior.

¿Qué es un gran proceso?

Decidimos transferir el proceso grande de IBM (al principio, sin embargo, nos capacitamos en uno pequeño):

Más de 100k instancias por mes.
Más de 70 cuadrados
Más de 30 integraciones con otros sistemas.
Backlog de rápido crecimiento

Este es el proceso de abrir una cuenta corriente en Tinkoff Business. No fue posible transferir dicho proceso en un enfoque, se requeriría una pausa de 3-4 meses en el desarrollo, lo que no es muy adecuado para el ritmo del desarrollo del negocio.
Decidimos movernos en pedazos y refactorizar todo lo que viene a la mano. Y para resolver el problema de los vecinos ruidosos, hicimos una solicitud por separado, que solo era responsable de las solicitudes de servicios de liquidación de efectivo.

En el nivel superior, el proceso se ve así:
imagen

Reglas de Transición

No. 1: dejó de cavar

Decidimos dejar de crear nuevas funciones en la aplicación anterior. Cuando la tarea apareció en la cartera de pedidos, intentamos identificar el cuadro \ componente \ servicio con el que se relaciona y reescribimos esto desde cero en Camunda. A veces a un costo era de 1.2x (x - si lo estaban haciendo en IBM), a veces - 3x o 5x.

# 2: Camunda no sabe nada sobre IBM

Después de refactorizar, solo queríamos desactivar la aplicación anterior, por lo que decidimos hacer nuevas funciones en Camunda para que no supiera nada sobre IBM. Dos cosas nos ayudaron:

Datos comerciales almacenados en Siebel
API listas para usar de Camuda que lo ayudan a comprender completamente cómo y cómo terminó el proceso.

Como resultado, realizamos un proceso en IBM que comienza y recibe el resultado de Camunda:
imagen

No. 3: "tareas manuales" largas y procesos de pegado

Primero, trasladamos llamadas síncronas simples de un solo paso a Camunda y todo funcionó bien. Después de eso, comenzamos a pegar estas cosas en los "procesos comerciales" normales, donde las expectativas de los usuarios comenzaron a aparecer.
Los usuarios pueden realizar sus tareas durante años, por lo que comenzamos a tener un montón de tareas para arreglar manualmente los procesos desde la papelera. Ganamos de esta manera: comenzamos a tener en cuenta el tipo de tarea específica en Camunda y no a tener en cuenta la basura en las tareas donde es posible una larga espera.

No. 4: alternar funciones en la horquilla

Algunas partes del código estaban tan confundidas que era más fácil escribir desde cero y ver si funcionaba bien. Para hacer esto, se introdujo en la función de IBM alternar con puertas de enlace. Enviamos un pequeño flujo de aplicaciones a Camuda y miramos los bolígrafos, todo está bien.
imagen

Migración de instancias de IBM a Camunda

Finalmente, el proceso en IBM consistió solo en llamadas a Camunda, y se recolectaron 3 niveles de procesos en Camunda. Los procesos comerciales en sí mismos no han cambiado mucho, por lo que logramos transferir las instancias anteriores de IBM a Camunda a los mismos puntos de espera. Y apague IBM.
imagen

Qué hacer si tienes una situación similar

Si desea mudarse a Camunda con el legado BPMS, entonces:

Mueva el contexto a una base de datos separada.
Mueva las interfaces de usuario a una aplicación separada.
Deje de codificar nuevas funciones en la aplicación anterior.
Utilice las llamadas unidireccionales para que Camunda no conozca el sistema anterior.
Comience con cajas pequeñas, pero no se olvide de las largas tareas personalizadas.

Este enfoque nos ayudó a reducir el número de incidentes en 14 veces, el tiempo de regresión en 4 veces, hizo posible la liberación diaria y redujo el costo de las pruebas manuales en 4 veces. Ahora 5 personas están trabajando en el proyecto y están haciendo la misma cantidad de trabajo que 9 personas con IBM. Espero que sus resultados no sean peores.

Invitación a mitap No. 4 por Camunda

27 de febrero de 2020 (jueves) a las 19:30 en Moscú, Golovinskoye Shosse 5A, Vodny Business Center, celebraremos otra reunión en Camunda. Puede registrarse y leer sobre los oradores en el enlace . ¡Ven!

Cómo migrar un gran proceso de IBM BPM a Camunda y no detener el desarrollo de funciones