In the previous series of articles, Designing an event-driven business process at scale: A health management example (which you need to read to fully understand this one), you designed and implemented an event-driven scalable business process for the population health management use case. Now, you will run this process through a few scenarios. In this way, you will:
Continue reading Running an event-driven health management business process through a few scenarios: Part 1
In the first article in this series, Designing an event-driven business process at scale: A health management example, Part 1, you found the business use case and data model for a concrete example from the health management industry. You then began implementing the example in jBPM (an open source business automation suite) by creating the Trigger process.
In the second article, you implemented the Task subprocess and, among other things, you also configured the call parameters for the Reminder and Escalation subprocesses within the Task subprocess. Now you will implement these subprocesses.
Continue reading “Designing an event-driven process at scale: Part 3”
The concept of a business process (BP), or workflow (WF), and the discipline and practice of business process management (BPM) have been around since the early 90s. Since then, WF/BPM tools have evolved considerably. More recently, a convergence of different tools has taken place, adding decision management (DM) and case management (CM) to the mix. The ascendance of data science, machine learning, and artificial intelligence in the last few years has further complicated the picture. The mature field of BPM has been subsumed into the hyped pseudo-novelties of digital business automation, digital reinvention, digital everything, etc., with the addition of “low code” and robotic process automation (RPA).
A common requirement of business applications today is to be event-driven; that is, specific events should trigger a workflow or decision in real-time. This requirement leads to a fundamental problem. In realistic situations, there are many different types of events, each one requiring specific handling. An event-driven business application may have hundreds of qualitatively different workflows or processes. As new types of events arise in today’s ever-changing business conditions, new processes have to be designed and deployed as quickly as possible.
Continue reading “Designing an event-driven business process at scale: A health management example, Part 1”
The Quarkus project is becoming quite popular among developers. Quarkus provides a fast-dev environment, and it has already a set of libraries, standards, and frameworks that are made available through extensions like RestEasy, Panache, SmallRye, Keycloak, and Kafka. Additionally, you can start using Kogito today to create intelligent Quarkus applications.
Continue reading “Kogito for Quarkus intelligent applications”
This is not an article about service-oriented architecture (SOA); neither is it a business process management (BPM) article. This article is about how business automation can change the way you create software.
At a first, developers and architects tend to associate the use of BPM suites (or business-oriented architecture) with SOA. This behavior immediately leads to an incorrect bias about the subject.
C-suite executives understand: Transform—or be suppressed by new, disruptive, technology-driven startups. In 2019, business automation is a key transformation that executives will seek in order to improve business performance and lower costs. However, some technology teams are not very open to it. Why?
In the past, BPM suites have been used as big centralized orchestrators for services, external systems, and human tasks. JBoss SOA Platform, released in 2008, is an example of such an integration platform. Unfortunately, this kind of application does not fit new cloud- and microservices-oriented architectures. The good news is that business automation evolved and can help teams to reach the next step in DevOps: BizDevOps.
Continue reading “Good news: Business automation is not about SOA”
KIE-Server is the light-weight, cloud-native, rules and process execution runtime of the Red Hat Decision Manager (RHDM) and Red Hat Process Automation Manager (RHPAM) platforms. Lately, I’ve gotten more and more questions on how to use the KIE-Server Client Java API to interact with the KIE-Server execution runtime of RHDM (formerly called Red Hat JBoss BRMS) and RHPAM (RHPAM). To answers these questions, and to create a future reference, I decided to write a number of code examples, accompanied by this article.
The KIE-Server Client Java API provides an easy way for Java applications to communicate with the KIE-Server execution engine of RHDM and RHPAM. The API abstracts the application from the underlying REST and/or JMS communication protocol and transport, making integrations with the server easier to build, test, and maintain.
Continue reading “Demystifying the Red Hat Decision Manager and Process Automation Manager Remote Client”
With the release of version 7.1 of Red Hat Process Automation Manager (RHPAM), the platform now supports the deployment of the process automation manager runtime as a “capability” within Spring Boot applications. As Maciej Swiderski, the project lead for jBPM.org (the upstream community project for RHPAM) explained earlier this year, the KIE (Knowledge Is Everything) platform on which RHPAM is built provides Spring Boot Starters to quickly build a business application or microservice with process and case execution capabilities using a minimal amount of code.
Continue reading “Spring Boot-enabled business process automation with Red Hat Process Automation Manager”