5 min. de leitura

Automatização de processos empresariais com Camunda: implementação tolerante a falhas de esquemas BPM

BPMN

Empresas

Comunda

Spring Boot

No mundo digital atual, a manutenção de uma vantagem competitiva exige processos empresariais simplificados e eficientes. A automatização destaca-se como uma solução fundamental para alcançar este objetivo. De acordo com o Statista, o mercado de gestão de processos empresariais (BPM) é esperado para atingir uma dimensão de 14,4 mil milhões de dólares americanos até 2025. A popularidade e a procura crescentes de ferramentas BPM como o Camunda, conhecidas pela sua flexibilidade e escalabilidade, testemunham esta tendência. À medida que as empresas procuram ferramentas fiáveis para otimizar as suas operações, Camunda surge como precursora, abrindo caminho para soluções de automatização inovadoras e tolerantes a falhas na indústria.

O que é Camunda?

Em termos simples, o Camunda é uma plataforma de código aberto para automatização de fluxos de trabalho e decisões que reúne utilizadores empresariais e programadores de software. Através do seu conjunto robusto de ferramentas e funcionalidades, o Camunda oferece formas de conceber, implementar e otimizar fluxos de trabalho BPMN (Business Process Model and Notation), tornando as operações comerciais mais suaves e transparentes.

Camunda, Spring Boot & BPMN: compreender os conceitos

Três intervenientes-chave remodelaram o panorama da gestão de processos empresariais: Camunda, Spring Boot e BPMN. Cada um deles criou o seu próprio nicho, oferecendo funcionalidades únicas que abordam facetas distintas da gestão de processos. No entanto, quando combinados, transformam-se numa potência sem paralelo, capaz de revolucionar as operações das empresas digitais.

Camunda: Esta não é apenas mais uma ferramenta na vasta caixa de ferramentas BPM; é um destaque. Sendo uma plataforma robusta de código aberto, o Camunda é especializado em automatização de fluxos de trabalho e decisões. O seu principal objetivo? Fundir na perfeição os mundos dos estrategas empresariais e dos programadores de software. Ao fazê-lo, garante que a concetualização, o design e a implementação de processos empresariais são eficientes, transparentes e coesos.

Spring Boot: Spring Boot toma a força da estrutura da mola e eleva-a. Ao oferecer um método simplificado para construir aplicativos Java independentes, tornou-se o ideal para desenvolvedores que desejam minimizar o código clichê e mergulhar diretamente no coração das funcionalidades específicas do projeto. O seu poder reside na sua flexibilidade e na sua abordagem de Convenção sobre configuração, que defende a ideia de padrões inteligentes. Essa abordagem permite que os desenvolvedores criem aplicativos escaláveis mais rapidamente, garantindo a entrega oportuna e o desempenho consistente.

BPMN: Se tivéssemos que personificar a BPMN, ela seria o linguista eloquente do mundo dos negócios. Como um padrão reconhecido mundialmente, a BPMN fornece um vocabulário visual para a elaboração de processos de negócios, tornando-os facilmente compreensíveis para uma ampla gama de partes interessadas. Esta linguagem universal garante que as nuances técnicas de um processo são decifráveis tanto pelo programador experiente em tecnologia como pelo estratega empresarial, promovendo diálogos colaborativos e tomadas de decisão mais informadas.

A sinergia entre as capacidades de automação do Camunda, a facilidade de desenvolvimento do Spring Boot e a notação padronizada do BPMN apresenta às empresas uma trifecta dinâmica. Juntos, eles garantem que os esquemas de BPM passem de meras construções teóricas no papel para implementações acionáveis no mundo real. O objetivo final? Cultivar processos de negócios que sejam ágeis, resilientes e perfeitamente alinhados com as demandas em evolução do cenário empresarial digital contemporâneo.

Componentes básicos da BPMN

Para aqueles que não estão familiarizados com BPMN, é crucial compreender os seus componentes essenciais. Esses componentes formam a base de qualquer diagrama BPMN.

Eventos

Significam algo que acontece durante um processo. Os eventos podem iniciar, interromper ou terminar um fluxo e são frequentemente representados por círculos.

Portas de entrada

As portas de entrada tratam da tomada de decisões no âmbito do processo. Com base nas condições, controlam o fluxo do processo, normalmente representado por losangos.

Actividades

As actividades representam o trabalho que está a ser realizado. Podem ser tarefas ou subprocessos e são apresentadas como rectângulos arredondados.

Ligação de objectos

Estes elementos, incluindo fluxos de sequência, fluxos de mensagens e associações, ilustram a sequência de processos e o fluxo de mensagens.

Pranchas de natação

Estas categorizam os elementos BPMN por função (por exemplo, gestor, contabilista) ou sistema (por exemplo, um sistema ERP).

Artefactos

Estes oferecem informação adicional sobre o processo. Os artefactos comuns incluem objectos de dados, grupos e anotações.

Prós e contras do Camunda

Como qualquer solução tecnológica, o Camunda apresenta uma mistura de vantagens e desafios. Aqui está um olhar abrangente sobre os seus prós e contras.

Prós:

Integração flexível e fácil com aplicações Java através do Spring Boot.
Uma interface de modelação intuitiva para BPMN 2.0.
Fornece análises pormenorizadas sobre as métricas do processo.

Contras:

Poderá ter uma curva de aprendizagem mais acentuada para os utilizadores não técnicos.
É um bom ponto de partida, mas considere-o apenas como a base - embora o Camunda seja um poderoso motor de fluxo de trabalho, continuará a precisar de mais desenvolvimento de software.

Simplificação de diagramas BPMN sobrecarregados

Realidade dura

O Camunda foi concebido para que os programadores e os analistas falem a mesma língua, mas muitas vezes a realidade intervém.

Os microsserviços falham, os utilizadores introduzem dados incorrectos, tudo pode acontecer. Neste caso, o belo diagrama analítico começa a ser embelezado com vários manipuladores de erros, registadores e caminhos alternativos. O analista concebe um esquema bonito, sucinto e compreensível. Tem alguns delegados e fornece caminhos lógicos para o fluxo do processo em várias circunstâncias. É este o aspeto de um esquema provisório quando chega às mãos de um programador:

No entanto, existem desvantagens. Um esquema deste tipo pode conter uma breve descrição da tarefa, como "verificar o cliente", o que implica várias fases, a tomada de decisões com base em cada resultado e a compilação das decisões derivadas num único resultado, possivelmente com a subsequente transferência deste resultado para sistemas externos.

É evidente que, nesta altura, os manipuladores de erros, os registadores e os elementos de serviço técnico aparecem no diagrama ou no código. Desta forma, uma tarefa "analítica" na implementação Java torna-se volumosa e complexa, ou o número de passos no esquema aumenta, sendo cada um deles acompanhado por manipuladores e caminhos alternativos. Como resultado, o esquema torna-se rapidamente complicado, difícil de suportar e modificar e a adição de novas funcionalidades pode implicar a reestruturação de uma vasta área do esquema e do código do delegado. No fundo, contém um grande número de elementos idênticos.

Eis o aspeto que o esquema anterior poderia ter numa implantação real:

É evidente que o esquema se alargou e se tornou mais pesado. Mas há vantagens: todas as tarefas se tornaram atómicas e surgiram ramos de comportamento em caso de erro.

Perceber o problema

Se tentarmos separar e encapsular o esquema e a lógica comercial do código Java, podemos fazer o seguinte:

Evitar a duplicação de elementos semelhantes no esquema.
Utilizar uma implementação universal e reutilizável de delegados no código Java.
Otimizar e acelerar o fluxo do processo.
Simplificar o tratamento de erros técnicos e estabelecer uma lógica de comportamento do processo quando estes surgem - quase sem o envolvimento de código Java. Isto simplificará significativamente a depuração e a análise manual de processos falhados que se encontram num incidente.
Reduzir drasticamente o número de processos que "caem" em incidentes quando surgem excepções técnicas.
Estabelecer uma base sólida para o desenvolvimento futuro.

Para facilitar o trabalho com o produto, é preferível decompor o esquema em tarefas atómicas, reduzir o volume total de elementos do esquema, diminuir o número de manipuladores de serviços, reduzir o volume de código Java de cada delegado e reutilizar delegados universais, realizando refacções instantâneas quando necessário. Tudo isto implicou automaticamente a escrita de testes unitários para todos os delegados e para os principais caminhos do processo.

Decomposição e atomização

Se olharmos atentamente para a aplicação do processo e analisarmos os seus nós, podemos ver muitas funções repetitivas: consultas a sistemas externos, registo, tratamento de erros, envio de chamadas de retorno, etc. Por outras palavras, é necessário avaliar criticamente a aplicação do processo, identificar objectos que possam ser facilmente encapsulados... Mas em quê? No código Java? Não, isso seria ilógico, porque, nesse caso, o esquema estaria intimamente ligado à sua implementação Java. Nesta situação, faz sentido considerar os pools de processos.

Um conjunto de processos é um esquema de um processo separado que terá o seu próprio contexto. É de salientar que é conveniente extrair peças atómicas de funcionalidade do processo principal para esses pools, bem como todos os momentos repetitivos: envio de notificações, pedidos a sistemas externos, etc.

Pode haver muitos conjuntos de processos, e seria lógico agrupá-los tematicamente. Por exemplo, consultas a um determinado microsserviço, alertas, envio de várias notificações. A interação entre esses pools pode ser facilmente configurada utilizando o sistema de mensagens Camunda. Cada vez que um desses agrupamentos é chamado no motor Camunda, é passada uma determinada mensagem que contém um cabeçalho condicional e o número do processo principal para devolver uma resposta, bem como um conjunto de dados necessários para o funcionamento deste pequeno agrupamento específico.

Aqui vemos como o processo principal (em baixo) envia uma mensagem à qual o iniciador de outro pool está inscrito. Quando o evento ocorre, o segundo pool inicia uma nova instância do processo, faz uma solicitação e envia uma resposta de volta ao processo principal, após o que ele é concluído com êxito. Durante este tempo, o processo principal aguarda o evento de resposta do pool externo para o qual enviou um pedido. Quando a mensagem chega, o processo continua. Se não houver resposta dentro do intervalo de tempo especificado, o processo entende que a computação externa não está disponível ou falhou, e termina.

O que isto oferece:

Oportunidade de reutilização de código. Se for necessário chamar o mesmo código várias vezes em diferentes condições ao longo do processo, basta criar mensagens específicas e chamar os pools de processos atómicos correspondentes;
Encapsulamento do esquema de implementação do software a partir da sua representação comercial. Não importa como o esquema principal será redesenhado, ou que caminhos o processo tomará. Todas as interacções já foram transferidas para processos menores separados, o que proporciona uma flexibilidade total: basta fazer um pedido e esperar por uma resposta.
O número e a probabilidade de ocorrência de falhas no processo principal são significativamente reduzidos. Antes desta divisão, o processo encontrava-se numa incerteza de 4 estados:
A resposta chegou.
A resposta não chegou porque o microsserviço externo falhou.
A resposta não chegou porque o processo principal falhou ao enviar o pedido.
A resposta não chegou porque o tempo limite foi ultrapassado.

Com esta divisão, o processo está sempre num estado estritamente único: ou a resposta chegou, ou o processo esperou e terminou. Para o negócio, importa como exatamente o processo terminou: se foi um erro ou não. Mas esta será uma conclusão correcta, não um incidente. Isto é importante porque um processo que não está preso num incidente não "consome" recursos e os erros podem ser facilmente registados, as estatísticas recolhidas, os alertas configurados e analisados.

Já não importa o que acontece com os processos menores. Eles podem fazer o que quiserem: falhar, correr... Só o resultado é importante: a resposta do recurso externo. E mesmo assim, nem sempre, porque o processo principal não deve garantir a funcionalidade dos sistemas externos. Por exemplo, pode não fazer sentido o processo esperar por uma resposta do microsserviço de notificação, uma vez que pode não haver qualquer resposta.
A complexidade do processo principal é muito reduzida. A lógica complexa pode ser distribuída entre pequenos pools separados, que são mais fáceis de depurar. Por exemplo, a verificação do cliente pode ser mais ou menos assim:

Aqui, podemos ver que no pool externo, várias tarefas são chamadas simultaneamente. Vamos aprofundar este ponto.

Paralelização de cálculos de processos

O Camunda permite a execução simultânea de ramos de cálculos de processos. Para o efeito, existe uma porta de entrada especial denominada "Parallel Gateway", através da qual o fluxo pode ser dividido em paralelos ou fundir vários cálculos paralelos num único fluxo. É evidente que, para acelerar o fluxo de um processo, seria vantajoso delegar determinadas tarefas em threads paralelas. Se a lógica for independente, pode ser executada em paralelo, por exemplo, efectuando pedidos simultâneos a sistemas externos e aguardando respostas de todos eles ao mesmo tempo:

De cada vez que se encontra numa porta de entrada deste tipo, haverá custos associados à criação de novas threads para a divisão de tarefas e à fusão dos resultados. É possível encontrar várias excepções de bloqueio e, claro, nem sempre é necessário ou justificado agir sempre desta forma, especialmente sem testes, mas os benefícios são evidentes.

Com a execução sequencial, o tempo total de execução é igual à soma dos tempos de execução de cada operação. Em contrapartida, com a execução paralela, é igual ao tempo de execução da operação mais longa. Dadas as condições de respostas não instantâneas de fontes externas, novas tentativas e falhas, esta diferença está longe de ser insignificante. Outra vantagem inegável é a forma de "tentativas livres", ou seja, enquanto o pedido mais longo está a ser executado, as outras tarefas têm hipoteticamente a oportunidade de falhar várias vezes e tentar refazer as suas acções sem afetar o tempo de execução global da tarefa.

Excepções e tentativas de repetição

Falido? Isso acontece. A versão out-of-the-box do Camunda tem a capacidade de tentar novamente uma transação com falha. Por "transação", queremos dizer o mecanismo interno do Camunda para executar o código delegado. O início de uma transação pode ser, por exemplo, o marcador "async before" ou "async after" em uma tarefa no modelador. Quando o mecanismo encontra esse marcador, ele confirma suas informações no banco de dados e inicia um novo thread assíncrono. Isso é importante. Para aprofundar, por "transação", entendemos a secção de execução entre as chamadas ao método .complete() no TaskService, seguida da gravação das informações na base de dados. Estas transacções, tal como outras, são atómicas.

Quando surge uma exceção técnica, ou seja, qualquer erro não comercial, por exemplo, dividir por zero e esquecer uma verificação de nulo, a transação faz um rollback e tenta recomeçar. Por defeito, fá-lo três vezes consecutivas sem qualquer pausa. Uma tentativa de nova tentativa começa quando surge uma exceção regular, que no mundo BPMN é designada por exceção técnica e não por BpmnError. Um BpmnError que surge pára o processo sem qualquer tentativa de repetição. Imagine como isso aumenta a resiliência do processo.

Faz sentido maximizar esta funcionalidade. Assim, em cada delegado que solicita um sistema externo, estes marcadores são definidos, especificando o número de tentativas e a pausa entre elas, e no código do delegado separa a lógica para quando o processo deve ser terminado e quando não deve. O código delegado separa a lógica de quando o processo deve ser terminado e quando não o deve ser. Dá controlo total sobre o tratamento de excepções e os mecanismos de repetição. Como resultado, o processo tenta refazer a tarefa falhada várias vezes, e só depois de uma série de falhas é que produz um erro.

Talvez o maior desafio seja o tratamento de excepções técnicas e erros relacionados com BPMN, bem como a conceção da lógica do seu tratamento para um fluxo contínuo do processo. Já discutimos alguns erros relacionados ao tratamento de respostas de fontes externas quando falamos sobre a divisão em pools de processos. Gostaríamos de lembrar que a própria chamada foi encapsulada num mini-processo separado, e o principal ou recebeu uma resposta e prosseguiu ou, devido a um timeout, seguiu o caminho "Não recebi uma resposta".

Vejamos agora esse processo muito pequeno:

Está a ver a moldura? É um subprocesso. Contém tarefas específicas e captura erros lançados por tarefas internas. Além disso, nessas molduras, o executor de tarefas é capaz de criar uma tarefa para o temporizador, que define o tempo de execução de tudo o que está dentro do subprocesso.

Como é que isso funciona? O fluxo de execução chega ao subprocesso, cria um processamento de temporizador paralelo e aguarda a conclusão do que está no interior ou, se o temporizador se esgotar primeiro, seguirá o percurso do temporizador. Se for lançada uma exceção durante o processo, que a estrutura do subprocesso capta, o processo interrompe a sua execução no ramo atual e segue o ramo de erro.

Também é evidente que existe uma opção para criar despachos de resposta para pedidos críticos. Note-se que a captura de erros funciona apenas para BpmnError com um código específico. Portanto, tecnicamente, é essencial capturar qualquer exceção e lançar um BpmnError com o código necessário, que funciona para o ErrorBoundaryEvent.

O tratamento de erros no processo principal funciona de forma semelhante. A partir de várias tarefas, são seleccionadas unidades lógicas que podem ser colocadas numa moldura de subprocesso, com um ouvinte configurado para um código de erro específico. Mas há duas nuances aqui. A primeira é que a criação de várias ramificações idênticas com tratamento de erros, diferindo apenas no código, é inconveniente. Se a estratégia de tratamento de erros mudar ou, por exemplo, o registo, muitos delegados no esquema teriam de ser redesenhados, o que não é desejável. Por conseguinte, pode considerar-se a hipótese de considerar subprocessos baseados em eventos.

Na sua essência, trata-se de um subprocesso separado do pool de processos, que é iniciado apenas quando ocorre um determinado evento no qual está inscrito. Por exemplo, se subscrever esse subprocesso ao evento BpmnError com um código, digamos, MyCustomBusinessError, quando esse evento ocorrer, o manipulador será acionado e, após a sua conclusão, o processo terminará corretamente. Sim, não terminou com sucesso, mas terminou corretamente. Nestes subprocessos, também é possível implementar uma lógica de tratamento diferente para o mesmo evento, dependendo das condições externas, por exemplo, notificando opcionalmente sobre um erro de aplicação quando o processo passa um ponto condicional.

A segunda nuance é muito mais complicada. Na vida real, o ciclo de vida de cada processo está provavelmente dividido em duas fases de negócio: antes da geração de contactos e depois. Se ocorresse um erro antes de os dados serem formatados num lead, o processo poderia provavelmente ser encerrado, notificando as dificuldades encontradas. Uma vez gerado o contacto, isso já não é possível.

Também não recomendamos o encerramento de processos se surgirem obrigações legais durante o processo, por exemplo, se for assinado um contrato. Como é que lidamos com esses erros? Alguns erros técnicos, como os associados à indisponibilidade de serviços externos, são tratados através de novas tentativas automáticas dentro de um tempo limite pré-acordado. Mas e se o processo falhar, as tentativas tiverem passado, mas o hipotético microsserviço externo ainda estiver em baixo?

Otimização manual

Chegamos ao conceito de resolução manual ou, também conhecido como, compensações.

Como é que funciona? Todos os erros são detectados, os delegados têm a oportunidade de tentar novamente, se necessário, e se a sorte não os favorecer, o processo entra num estado de erro, mas com o código apropriado, por exemplo, COMPENSATION_ERROR. Este código é capturado por outro subprocesso baseado em eventos, que processa, regista, notifica e, mais importante, não pode falhar inesperadamente. Apenas onde foi concebido para o fazer, lança uma exceção técnica não capturável e cai num incidente.

Porquê fazer desta forma? Para monitorizar, pode utilizar o EXCAMAD - um painel de administração externo para o Camunda, um análogo do Cockpit, com funcionalidades poderosas. Destaca a vermelho os processos em incidente. Estes processos podem ser modificados ou reiniciados a partir do ponto desejado. Por exemplo, pode colocar o valor da variável necessária no contexto e reiniciar o processo a partir do ponto imediatamente a seguir ao problemático. Isto é conveniente, direto e permite a resolução manual de problemas com um esforço mínimo.

Automatização de processos empresariais com Camunda: exemplos reais

Reconhecida pela sua plataforma de código aberto e pela sua interface de fácil utilização, Camunda tem permitido a inúmeras empresas otimizar os seus fluxos de trabalho. Vamos explorar alguns exemplos da vida real.

Banca e finanças

Münchener Hypothekenbank eG, Camunda, um banco imobiliário independente, passou a utilizar o motor de fluxo de trabalho Camunda para melhorar e automatizar os processos internos, especificamente o tratamento de correio e a coordenação de pedidos de empréstimo entre departamentos. Anteriormente, o seu sistema era rígido, não tinha flexibilidade e conduzia a complexidades que aumentavam as taxas de erro.

Na sua mudança para uma arquitetura de microsserviços baseada em Java, seleccionaram Camunda com base em recomendações internas e trabalharam em estreita colaboração com o WDW Consulting Group. Alguns benefícios que obtiveram imediatamente do Camunda eram funções prontas para uso, enquanto outros precisavam de mais desenvolvimento. Essa transição resultou em uma lista de tarefas centralizada usada por toda a equipe e forneceu flexibilidade para manter processos individuais sem afetar outros.

O resultado mais notável foi uma melhoria significativa na velocidade de processamento dos pedidos de empréstimo. Isto beneficia tanto o pessoal como os clientes finais. Como prova do seu sucesso, outros departamentos estão agora a tentar adotar o Camunda, e o banco até contratou mais programadores para apoiar a sua implementação.

Seguros

SV Informatik, a SV SparkassenVersicherung, uma subsidiária da SV SparkassenVersicherung, é especializada em soluções de TI personalizadas para empresas de seguros. Eles incorporaram o Camunda para automatizar vários processos em todos os departamentos, levando a uma notável economia de tempo e melhores tempos de resposta ao cliente. A empresa adotou o Camunda em 2018 como uma solução para sua busca por uma ferramenta eficaz de modelagem de processos de negócios, com foco na melhoria de processos e no aumento da colaboração entre TI e outros departamentos.

Desde a sua implementação, o Camunda automatizou tarefas como cancelamentos de apólices de seguro automóvel e pedidos de documentos de apólices. Uma realização notável foi o processamento automático 80% de relatórios de danos causados por tempestades em linha. Isto revelou-se especialmente valioso durante as inundações e tempestades de 2021 na Alemanha. Ferramentas como o Camunda Optimize e o Camunda Cockpit facilitam a monitorização e otimização dos processos.

Hospitalidade

Em 2020, o Grupo SV, Camunda uma empresa de hotéis de luxo que opera na Alemanha, Suíça e Áustria, lançou uma plataforma digital disruptiva chamada "likeMagic" com a assistência da Camunda. Esta plataforma proporcionou uma experiência perfeita aos hóspedes, desde a reserva até ao check-out, com resultados que incluem uma taxa de auto-check-in/out de 95% e uma pontuação de 9 em 10 de felicidade dos hóspedes. A inovação reduziu as necessidades de pessoal e integrou plataformas como a Airbnb sem problemas. Reconhecendo o seu potencial, o SV Group ofereceu o "likeMagic" a outros fornecedores de serviços de hotelaria. Até 2023, eles expandiram de 2 para mais de 30 clientes na região DACH, com planos para um alcance europeu mais amplo e visando 15.000 quartos até o final do ano.

Concluir

O potencial transformador do Camunda não reside apenas nas suas funcionalidades principais, mas na sua capacidade de redefinir as operações comerciais a um nível fundamental. Combinado com o Boot Spring, ele abre uma porta para integrações perfeitas e escalabilidade aprimorada. Entender os detalhes do BPMN é fundamental para aproveitar todo o potencial do Camunda. À medida que as empresas evoluem nesta era digital, ferramentas como o Camunda se destacam, oferecendo soluções dinâmicas que podem girar e se adaptar às necessidades em constante mudança. Não se trata apenas de automatizar processos, mas de inovar fluxos de trabalho, aumentar a eficiência e gerar resultados tangíveis que fazem a diferença. Abrace o poder da Camunda e deixe a sua empresa voar para novos horizontes.

Dmitry Nazarevich CTO

Data: 17 de janeiro de 2024

Índice

Avaliar este artigo:

★★★★★ 4/5

4.8/5 (45 comentários)

Conteúdo relacionado

Blogue

Looker vs Power BI - Revolucionando a indústria de coberturas pequenas

Comparação entre Looker e Power BI: revelando a ferramenta de BI

Blogue

Porquê contratar programadores de software juniores para os seus projectos

Blogue

Escolher o parceiro certo de nearshoring de TI: dicas para consultores de TI na Europa

Blogue

Por que razão é provável que o seu projecto falhe sem BA

Porque é que é provável que o seu projecto falhe sem um especialista em BA

Blogue

Porque é que os projectos de TI falham

Contactar-nos

Nome

Empresa

Correio electrónico

Telefone

Mensagem Inclua os detalhes do projeto, a duração, o conjunto de tecnologias, os profissionais de TI necessários e outras informações relevantes

Gravar uma mensagem de voz sobre o seu
projeto para nos ajudar a compreendê-lo melhor

Anexar documentos adicionais, se necessário

Enviar ficheiro

Pode anexar até 1 ficheiro de 2MB no total. Ficheiros válidos: pdf, jpg, jpeg, png

Informamos que, ao clicar no botão Enviar, o Innowise's processará os seus dados pessoais de acordo com a nossa Política de Privacidade com o objectivo de lhe fornecer informações adequadas.

O que é que acontece a seguir?

Após termos recebido e processado o seu pedido, entraremos em contacto consigo para detalhar as necessidades do seu projecto e assinar um NDA para garantir a confidencialidade das informações.

Após a análise dos requisitos, os nossos analistas e programadores elaboram uma proposta de projecto com o âmbito dos trabalhos, tamanho da equipa, tempo e custos e custos.

Marcamos uma reunião consigo para discutir a oferta e chegar a um acordo.

Assinamos um contrato e começamos a trabalhar no seu projecto o mais rapidamente possível.

Automatização de processos empresariais com Camunda: implementação tolerante a falhas de esquemas BPM

O que é Camunda?

Camunda, Spring Boot & BPMN: compreender os conceitos