Creating a Quarkus Workflow project

As a developer, you can use SonataFlow to create an application and in this guide we want to explore different options and provide an overview of available tools that can help.

We will also use Quarkus dev mode for iterative development and testing.

As a common application development, you have different phases like Analysis, Development and Deployment. Let’s explore in detail each phase and what SonataFlow provides in each case:

Prerequisites

For more information about the tooling and the required dependencies, see Getting familiar with SonataFlow tooling.

Analysis phase

Start by analyzing the requirements for your SonataFlow application. This will enable you to make decisions about the persistence, eventing, security, topology, and component interaction needs of your application.

Adding persistence

Service orchestration is a relevant use case regarding the rise of microservices and event-driven architectures. These architectures focus on communication between services and there is always the need to coordinate that communication without the persistence addition requirement.

SonataFlow applications use an in-memory persistence by default. This makes all the workflow instance information volatile upon runtime restarts. In the case of this guide, when the workflow runtime is restarted. As a developer, you must decide if you need to ensure that your workflow instances remain consistent in the context.

If your application requires persistence, you must decide what kind of persistence is needed and configure it properly. Follow the SonataFlow persistence guide for more information.

You can find more information about how to create an application that writes to and reads from a database following Your second Quarkus application guide.

Adding eventing

Quarkus unifies reactive and imperative programming you can find more information about this in the Quarkus Reactive Architecture guide.

In this phase, we must decide how the Event-Driven Architecture needs to be added to our project. As an event-driven architecture, it uses events to trigger and communicate between services. It allows decoupled applications to publish and subscribe to events through an event broker asynchronously. The event-driven architecture is a method of developing systems that allows information to flow in real time between applications, microservices, and connected devices.

This means that applications and devices do not need to know where they are sending information or where the information they are consuming comes from.

If we choose to add eventing, SonataFlow supports different options like:

You must choose how the different project components will communicate and what kind of communication is needed. More details about Quarkus Extensions enabling Reactive

Adding Data Index service

The Data Index service can index the workflow instance information using GraphQL. This is very useful if you want to consume the workflow data in different applications through a GraphQL endpoint. For more information about Data Index service see Data Index Core Concepts for more details.

If you decide to index the data, you must select how to integrate the Data Index service in your topology. Here are some options:

  • You can choose to have the data indexation service integrated directly into our application using the different Data Index Quarkus extensions. This allows you to use the same data source as the application persistence uses, without the need for extra service deployment.

    • Data Index persistence extension. That persists the indexed data directly at the application data source.

    • Data Index extension. That persist directly the indexed data at the application data source and also provide the GraphQL endpoint to interact with the persisted data.

  • Another option is to have the Data Index as a standalone service. In this case, you must properly configure the communication between your SonataFlow application and the Data Index service. More details in Data Index standalone service

Adding Job service

The Job Service facilitates the scheduled execution of tasks in a cloud environment. If any of your SonataFlow workflow needs some kind of temporary schedule, you will need to integrate the Job service.

If you decide to use Job Service, you need to select how to integrate the service into your topology. Here are some options:

  • You can choose to have the Job service integrated directly into your SonataFlow Quarkus application using Job Service Quarkus Extensions guide.

  • Explore how to integrate the Job service and define the interaction with your SonataFlow application workflows. You can find more Job service-related details in Job Service Core concepts.

Development phase

Once you decide which components you must integrate into SonataFlow project, you can jump into the workflow development phase.

The goal is to create a workflow and be able to test and improve it. SonataFlow provides some tooling to facilitate the developer to try the workflows during this development phase and refine them before going to the deployment phase. As an overview, you have the following resources to help in this development phase:

Bootstrapping a project, Creating a workflow, Running your workflow application and Testing your workflow application

To create your workflow service, first you need to bootstrap a project. Follow the SonataFlow Creating a Quarkus Workflow service guide to setup a minimal working project.

How to configure logging

In order to understand what’s happening in the environment. SonataFlow is using Quarkus Log Management. Logs can provide a detailed history of what happened leading up to the issue.

Quarkus uses the JBoss Log Manager logging backend for publishing application and framework logs. Quarkus supports the JBoss Logging API and multiple other logging APIs, seamlessly integrated with JBoss Log Manager In order to be able to see the in detail access to Quarkus Logging Configuration guide

Example adding Logging configuration properties in application.properties file
quarkus.log.console.enable=true (1)
quarkus.log.level=INFO (2)
quarkus.log.category."org.apache.kafka.clients".level=INFO
quarkus.log.category."org.apache.kafka.common.utils".level=INFO (3)
1 If console logging should be enabled, even by default is set to true
2 The log level of the root category, which is used as the default log level for all categories
3 Logging is configured on a per-category basis, with each category being configured independently. Configuration for a category applies recursively to all subcategories unless there is a more specific subcategory configuration

Access to Logging configuration reference to see how logs properties can be configured

Refining your workflow testing with Dev-UI

Quarkus provides a host of features when dev mode is enabled allowing things like:

  • Change configuration values.

  • Running Development services, including Zero-config setup of data sources. When testing or running in dev mode Quarkus can even provide you with a zero config database out of the box, a feature we refer to as Dev Services. More information can be found in Quarkus introduction to Dev services.

  • Access to Swagger-UI that allows exploring the different SonataFlow application endpoints. The quarkus-smallrye-openapi extension will expose the Swagger UI when Quarkus is running in dev mode. Additional information can be found Use Swagger UI for development.

  • Data index Graph UI that allows to perform GraphQL queries or to explore the data schema

  • Allow to explore the workflow instances if the SonataFlow Runtime tools Quarkus Dev UI is included

By default, Swagger UI is only available when Quarkus is started in dev or test mode.

If you want to make it available in production too, you can include the following configuration in your application.properties:

quarkus.swagger-ui.always-include=true

This is a build time property, it cannot be changed at runtime after your application is built.

Deployment phase

At this stage you have a SonataFlow Quarkus application well tested and ready to be deployed.

There are two basic modes that a Quarkus application can be deployed:

If you put either the Java application or the native executable app inside a container, you can deploy the container anywhere that supports running containers.

Quarkus provides extensions for building (and pushing) container images. You can find more details about that container images generation in Quarkus Container Image extensions

Once this container image is built it can be used as part of the decided topology. You have different options like:

Additional resources

Found an issue?

If you find an issue or any misleading information, please feel free to report it here. We really appreciate it!