TL;DR: Since @kie-tools/form-generation-tool@10 new CLI command can generate your Business Process Forms.

As promised in Part One, we will continue with introducing the @kie-tools/form-generation-tool. In this article, we will generate a Business Process Form.


We rarely use Business Processes as standalone models. They usually belong to some bigger projects. We will use Apache Kie projects. Such example projects can be found here, especially those that have a process in the project name, e.g. process-quarkus-example. Or you can use your own project.

Browsing linked examples, you may notice the projects use Maven. So when Maven builds an Apache Kie project, Kie generates JSON schemas to represent the data models for both Processes and User Tasks. Then @kie-tools/form-generation-tool locates those JSON Schemas in the project and taking advantage of the Uniforms APIs, processes them and generates static forms as a resource in the project src/main/resources/forms folder.

Form Generation

Generation prerequisites

    • Make sure your Apache Kie project has been compiled, otherwise the CLI won't be able to find all the form schemas.

As we installed the @kie-tools/form-generation-tool in Part One globally, we can run the command from anywhere.


This will start a wizard to help you generate the forms:

  1. First, set the path to your Apache Kie Project. I will use process-quarkus-example.

    Kogito Form Generation CLI
    This tool will help you generate forms for the Processes and User Tasks in your Kogito Projects.
    The tool will search for the User Tasks JSON schemas generated in your project, so make sure the project is build.
    The generated forms will be stored as resources in your project (in src/main/resources/forms folder).
    ? Type your Kogito Project path:---> /path/to/my/projects/process-quarkus-example <---

  2. Select one of the available Form types (Patternfly or Bootstrap 4). We will use Bootstrap 4. Use arrow keys to change the selection.

    ? Select the Form type:
    ❯ bootstrap
  3. Confirm Selection, type Y, to start the Form Generation process.

    Current selection:
    Project path: /path/to/my/projects/process-quarkus-example
    Form type: bootstrap
    ? Do you want to continue? (Y/n) Y
  4. Once the generation is done, let's browse /path/to/my/projects/process-quarkus-example/src/main/resources/forms folder.

    ls /path/to/my/projects/process-quarkus-example/src/main/resources/forms/

One question that may come to your mind, is why there are so many forms. We have only three Business Processes in process-quarkus-example project. Well spotted. It is because not only Business Processes can have their forms, but also User Tasks, as special nodes that require input from users, can have their own forms.


Congratulations! We generated Business Process Forms and we will take a closer look at the generated results in the next article.

TL;DR: Since @kie-tools/form-generation-tool@10 new CLI command can be installed into your machine.

This new Whole Business Process Form blog series will be using Apache Kie Business Process automation project. In this short article, we will install @kie-tools/form-generation-tool npm package to be able to interact with Business Processes.

Business Process

If you're already familiar with what a Business Process is, you may proceed to the next section. 

A Business Process is exactly what its name implies, a model of a process from your business. There is no restriction on what can be modeled. Examples are:

  • A bank loan approval
  • Goods delivery planning
  • Booking a hotel room
  • and many others

Each Business Process has then its textual and graphical representation, as defined by the BPMN 2.0 standard.

Business Process Form

Once we have a prepared Business Process, we need to provide data for it:

  • Before we approve any loan, we need details about the loan: who and how much money somebody wants to borrow.
  • Before we deliver any goods, we need to know the delivery addresses.
  • Before we book any hotel room, we need to know the room size and the booking date.

All the above are data that we obtain via forms. The kind that you experience in any web application. Fortunately, using the Apache Kie project, we do not need to code forms manually. We generate them automatically using the @kie-tools/form-generation-tool.


Before you begin the installation, please be sure your machine meets the following prerequisites:

Installation prerequisites

Once the prerequisites are met, it is super simple to install @kie-tools/form-generation-tool. Simply issue the npm command:

npm install -g @kie-tools/form-generation-tool

Once installation is done, you can start using @kie-tools/form-generation-tool via node CLI command form-generation-tool.



We installed @kie-tools/form-generation-tool and we will show how to generate forms using it in the next article.

Executive Summary

I was allowed to represent KIE at Apache Community Over Code NA 2023. This opportunity has quickly paid for itself in networking with other developers, the Apache Software Foundation Board, and the Infrastructure team and announcing Apache KIE to those in attendance. This opportunity and others like it must continue for Apache KIE to maintain its place in the market and in people’s minds.

Not only were people introduced to Apache KIE, but I was also able to find answers to questions we have had over the past few months. Solutions were discussed, information was shared, and new relationships with the project were forged. We will better be able to move forward as an Apache project from this interaction. Further interactions will only be more beneficial.

This article details some of those interactions and how the project will benefit from having a member attend these conferences.

Important people from the foundation I met

Aside from amazing people out in the community, I also met several people from the Apache Software Foundation (ASF) who not only provided insight and direction but also are better able to associate the KIE project with a friendly face, ideally faces as we can get more of our team out to these events. Below are some of these people I was able to meet, speak with, and get to know.

Justin Mclean

Justin is the V.P. of the Incubator, a Board Member, and Assistant V.P. of Legal Affairs. Justin has reviewed over 1,000 Incubator releases with the ASF over the past 11 years. Not only does he help projects understand what is needed for releases, and he also guides and mentors those within the Incubator to graduation and becoming Top Level Projects (TLPs). Be it good or bad, we have already attracted his attention with KIE. He’s helped us understand that some of what we have been doing has not been in harmony with The Apache Way, and he will review our releases.

Drawing the attention of a V.P. while in the Incubator may not be helpful for us, but getting to know him and having him understand what we are doing in KIE has helped us understand KIE and one another better. Justin is certainly willing to help us and answer questions as they arise.

Infra Team

Meeting with the ASF infrastructure team in person helped clear up some questions immediately. For example, the pain that we have been experiencing with migrating our GitHub Actions (GHA) to Jenkins no longer needs to continue. The information we discovered about GHA at the Apache organization in GitHub is outdated. They have 900 runners that have been donated from GitHub. They’re only using about a third of them. There is plenty of space for us to continue using GHA. Learning about the monthly round table meetings will be helpful in the future. There’s also a build mailing list with other projects on it whom we could ask for ideas and suggestions about our builds. The Infrastructure Team was also very excited to meet someone from KIE, learn about what we’re doing, and understand where and how they can help.

Craig Russell

Craig is the Assistant Secretary for the ASF. He helps review and receive the Software Grant Agreements (SGA) and Individual Contributor License Agreements (ICLA). Craig initially had some questions and concerns about KIE and our PPMC. I reassured him I knew them and would address them on the mailing list. For reference, we need to have all our committers as PPMC members. We’ll have to go through a vote for all of them that are currently not part of the PPMC. This will preclude us from graduating from the Incubator.

Ruth Suehle

Ruth Suehle acts as the Executive V.P. for the ASF. Ruth helped steer us initially toward the ASF for KIE instead of other foundations. Unfortunately, she left Red Hat shortly after that. Knowing Ruth will be helpful in the future, and further learning how we can progress within the ASF and build new relationships within the community.

Brian Proffitt

Many of us already know Brian or have at least met him virtually. I had not met him in person, so I was very grateful for the opportunity to get to know him. Brian is our mentor while within the Incubator. Brian is also the V.P. of Marketing and Publicity for the ASF. Brian will be able to continue to guide us through the Incubator, provide valuable insight into conference attendance, and help us get the word out about KIE.

Christofer Dutz

Christofer introduced himself early on during our transition into the Incubator. He is a Board Member and also the V.P. of Apache PLC4X. Christofer has stated he’d be happy to help us during incubation. He is also very interested in contributing to Drools and learning how it can be used in an IoT setting.

Shane Curcuru

Shane has been with the ASF for over 20 years. He’s held various positions within the ASF during that time and understands how it functions. While Shane did not offer any aid or help for the project, he is still a great person to know within the foundation.

Jesse Gorzinski

Jesse is a Senior Business Architect within IBM. He has done much with Apache Camel (not sure if he has contributed) and is interested in the Business Modeling space. We spoke over a couple of days. I let him know about KIE and what is happening there. I believe there to be interest there and for his customers.

Additional Direction and Guidance

While at Apache Community Over Code, I got some direction about KIE, where we need to make some changes, and things to do as we progress through the Incubator. A couple of the highlights:

  1. We haven’t done anything overly egregious. We’re not in danger of being kicked out of the Incubator or having the Board intervene with the project. I never thought this was a concern, but I felt that some thought this might be a problem. Justin and Brian told me we’re doing just fine. The Incubator is the place for projects to figure things out, and they understand it will be rocky for a little while.

  2. We need to address the difference between the number of PPMC members and committers. This will affect us if we don’t get it sorted out. The ASF will expect to see all the committers as PPMC members. When KIE graduates from the Incubator, we can ask everyone if they want to continue being part of the PMC for the project.

  3. Infrastructure is happy to help and willing to do so. However, they are a small team and do not have a dedicated build person. Thankfully, our information about GHA at the Apache GitHub organization is outdated. They have 900 runners that have been donated from GitHub. Currently, they are only using about a third of those runners. There should be plenty of capacity for our projects to continue to use GHA. We can look at Apache Airflow for ideas on how they have things set up. There is also a mailing list and a slack channel we can leverage for additional help. In addition, Infra holds a monthly roundtable huddle on Slack we can attend.

Community Outreach

Community events are a fantastic way to spread the word about what we are doing and see what users of our projects are doing and what they need. Collaboration is also a considerable benefit from these events. As I have done with many ASF Board Members and other leaders, we can meet with people and forge new relationships. This interaction cannot be overstated. Putting a face with an email address or Slack handle makes interactions more memorable. Seeking help from a broad audience of people at these sorts of events is also much more targeted than anything we could do via Twitter/X, LinkedIn, Facebook, etc.

As an example of this collaboration, I learned the Infra team has been experiencing some difficulties with Keycloak lately. I facilitated an introduction of some members of the Keycloak team and the ASF Infra team. In-person meetings and conferences catalyze these sorts of collaborations, and they go a long way toward us becoming good community members.

Slides and Ideas I had while attending

Several people discussed mailing lists, The Apache Way, and reasons for doing things a certain way. Below are some images of slides from various talks I found helpful.

Written communication can be difficult, and it is easy to misinterpret what people say. The above slide talks about things to remember with mailing lists. Below are reasons to favor mailing lists for significant discussions and decisions over Slack or Zulip.

Written communication can be difficult, and it is easy to misinterpret what people say. The above slide talks about things to remember with mailing lists. Below are reasons to favor mailing lists for significant discussions and decisions over Slack or Zulip.

Keeping development and decisions transparent and archived is a wonderful reason to use archived mailing lists. This presenter spoke about needing help understanding why a particular architecture was being used in a project he started contributing to. Because the discussion was on the mailing list a few months back, he could go back and read the entire discussion and understand why the architecture was put in place.

When a vote is called when utilizing The Apache Way, it makes the decision official and allows consensus to be moved forward quickly.