Forem: Optimajet Limited

React JSON Schema Form Alternative: FormEngine vs RJSF Bundle Size Comparison

Optimajet Limited — Wed, 11 Feb 2026 19:19:23 +0000

Disclaimer: Hi! We're the team at Optimajet, creators of FormEngine. This is an honest technical comparison of our library with react-jsonschema-form (RJSF). All tests are public, reproducible, and available on GitHub.

TL;DR: We compared two direct competitors in the JSON-based React forms space. RJSF is lighter out of the box (175 KB vs 244 KB). But if you already have Material UI FormEngine becomes 23% lighter (188 KB), while RJSF gets 32% heavier (232 KB). Your choice of UI library determines the winner.

Why RJSF vs FormEngine? 🤔

When we developed FormEngine, we often heard: "How are you different from react-jsonschema-form?"

Fair question. Both libraries:

React-based
Work with JSON:
- RJSF uses JSON Schema to describe forms
- FormEngine uses its own JSON format
Support Material UI
Open to customization

But there's one fundamental architectural difference that radically affects bundle size:

RJSF — adds UI components on top of the base library
FormEngine — completely replaces UI components during integration

Let's see how this works in practice.

Testing Methodology

We tested two realistic forms:

Login Form (Simple Case)

Email + Password fields
Basic validation
Submit button

Booking Form (Complex Case)

Multi-step form
Conditional logic
Different field types (text, dates, selects)
Validation at each step

Test Conditions:

Production build (minified + gzipped)
Vite as bundler
Tree-shaking enabled
Default configurations
Two variants: with default UI (FormEngine Core has no default UI, React Suite v5 was used) and with Material UI

Full methodology: formengine.io/documentation/bundle-size-comparison

Results (gzip sizes)

Login Form - Default UI

🥇 RJSF           175.26 KB  (baseline)
🥈 FormEngine + React Suite (v5)   244.19 KB  (+39% heavier)

RJSF wins in its pure form. Bootstrap CSS is lighter than React Suite.

Login Form - With Material UI

🥇 FormEngine     188.54 KB  (-23% from default!)  
🥈 RJSF           231.62 KB  (+32% from default)

Difference: 43 KB in favor of FormEngine

The picture changes! FormEngine becomes lighter when replacing React Suite with MUI.

Booking Form - Default UI

🥇 RJSF           178.07 KB  (baseline)
🥈 FormEngine + React Suite (v5)    316.69 KB  (+78% heavier)

RJSF is ahead again. But the difference has grown — complex forms require more components.

Booking Form - With Material UI

🥇 FormEngine     199.26 KB  (-37% from default!)  
🥈 RJSF           234.50 KB  (+32% from default)

Difference: 35 KB in favor of FormEngine

FormEngine is lighter again after MUI integration.

Key Insight: How UI Kit Changes Everything

Here's what happens when switching from default UI to Material UI:

Form	FormEngine	RJSF
Login	-55.6 KB (-23%) ⬇️	+56.4 KB (+32%) ⬆️
Booking	-117.4 KB (-37%) ⬇️	+56.4 KB (+32%) ⬆️

Why Does FormEngine Become Lighter?

Comparison of Different UI Library Usage:

FormEngine + React Suite by default:
├── Core engine (~50 KB)
├── React Suite components (~190 KB)
└── React Suite CSS (~52 KB)
= 244 KB total

FormEngine + MUI:
├── Core engine (~50 KB)
├── MUI components (already in project)
└── Minimal CSS (~0.2 KB)
= 188 KB total (-23%)

Why Does RJSF Become Heavier?

Additive Architecture:

RJSF by default:
├── Core engine (~156 KB)
└── Bootstrap CSS (~19 KB)
= 175 KB total

RJSF + MUI:
├── Core engine (~156 KB)
├── MUI adapter layer (~20 KB)
├── MUI components (already in project)
└── Minimal CSS (~0.2 KB)
= 232 KB total (+32%)

MUI is added on top, not replacing the base components.

What Does This Mean for Real Users?

A difference of 35-43 KB might seem small, but let's translate it into seconds:

On Slow 3G (Emerging Markets):

Metric	43 KB Difference	Impact
Load	~1.2 sec	Slower UI appearance
TTI	~1.0 sec	Slower interactivity

On 4G (Typical Conditions):

Metric	43 KB Difference	Impact
Load	~0.13 sec	Almost imperceptible
TTI	~0.15 sec	Barely noticeable

Conclusion: If you have users on slow networks (emerging markets, mobile internet in subways, poor WiFi) — every second is critical.

Conclusions (And What We Learned About Our Own Product)

1. Context Is Everything

You can't say "FormEngine is better than RJSF" or vice versa. The right answer depends on your project:

Choose RJSF if:

Need minimal baseline
JSON Schema is your primary source of truth
Simple forms with basic validation

Choose FormEngine if:

Already using Material UI or another UI kit
Need deep component customization
Complex forms with conditional logic

2. Our Competitive Advantage Is Integration

We initially designed FormEngine for embedding into existing projects with already installed UI libraries. This architectural decision paid off:

Minus 23-37% bundle when integrating with MUI compared to React Suite
Complete UI replacement instead of layering
Zero overhead for components

3. Different Approach to Describing Forms in JSON

This is one of the most important differences that affects not only DX but also bundle size:

RJSF: Separate Schemas (Data Schema + UI Schema)

// data-schema.json - describes data
{
  "type": "object",
  "properties": {
    "email": {
      "type": "string",
      "format": "email"
    },
    "password": {
      "type": "string",
      "minLength": 8
    }
  },
  "required": ["email", "password"]
}

// ui-schema.json - describes UI
{
  "email": {
    "ui:widget": "email",
    "ui:placeholder": "Enter your email"
  },
  "password": {
    "ui:widget": "password",
    "ui:help": "Min 8 characters"
  }
}

Pros of Separation:

✅Standardization — JSON Schema is an open standard
✅ Reusability — one data schema can be used in different UIs
✅ Validation independent of UI — can validate on backend with the same schema
✅ Ecosystem — many tools for JSON Schema (generators, validators, documentation)
✅ Separation of concerns — logic separate from presentation

Cons of Separation:

❌ Synchronization — need to maintain two files in sync
❌ Verbosity — more code for simple forms
❌ Learning curve — need to know both formats

FormEngine: Unified JSON (Data + UI in One JSON)

// form.json - everything in one place
{
  "components": [
    {
      "type": "TextField",
      "key": "email",
      "label": "Email",
      "placeholder": "Enter your email",
      "validation": {
        "required": true,
        "email": true
      }
    },
    {
      "type": "PasswordField",
      "key": "password",
      "label": "Password",
      "help": "Min 8 characters",
      "validation": {
        "required": true,
        "minLength": 8
      }
    }
  ]
}

Pros of Unification:

✅ Simplicity — one file, one source of truth
✅ Less code — no duplication of field names
✅ Conditional logic — easier to describe dependencies between fields
✅ DX — faster to write and understand
✅ Compactness — less boilerplate

Cons of Unification:

❌ No standardization — proprietary FormEngine format
❌ Vendor lock-in — harder to migrate to another library
❌ Validation only on client — can't reuse schema on backend directly
❌ Fewer tools — no JSON Schema ecosystem
❌ UI and data coupling — UI changes can affect logic

Impact on Bundle Size

RJSF (separate schemas):

✅ JSON Schema validator (~15-20 KB)
✅ Standard ajv (might already be in project)
❌ UI Schema parser (~5 KB)
❌ Mapping layer between schemas (~3-5 KB)

Total: ~23-30 KB overhead

FormEngine (unified schema):

✅ Custom validator (~8-12 KB)
✅ Less parsing
❌ No ajv reuse
❌ Proprietary format

Total: ~8-12 KB overhead

Conclusion: FormEngine saves ~10-15 KB on schema parsing, but loses standardization benefits.

Important note: Although FormEngine uses a proprietary format, it is fully open and documented. This means you can study the specification, write your own parsers or form generators, without depending on closed solutions.

Real Example: Complex Conditional Logic

Imagine a form where the "Phone" field is shown only if "Contact by phone" is selected:

RJSF Approach:

// data-schema.json
{
  "type": "object",
  "properties": {
    "contactMethod": {
      "type": "string",
      "enum": ["email", "phone"]
    },
    "phone": {
      "type": "string",
      "pattern": "^[0-9]{10}$"
    }
  },
  "dependencies": {
    "phone": ["contactMethod"]
  },
  "if": {
    "properties": {
      "contactMethod": { "const": "phone" }
    }
  },
  "then": {
    "required": ["phone"]
  }
}

// ui-schema.json
{
  "phone": {
    "ui:widget": "phone",
    "ui:options": {
      "conditional": {
        "show": {
          "field": "contactMethod",
          "is": "phone"
        }
      }
    }
  }
}

Problem: The condition is described in two places! Data schema says "phone required if...", UI schema says "show phone if...". Need to synchronize.

FormEngine Approach:

{
  "components": [
    {
      "type": "RadioGroup",
      "key": "contactMethod",
      "label": "Contact method",
      "options": [
        { "value": "email", "label": "Email" },
        { "value": "phone", "label": "Phone" }
      ]
    },
    {
      "type": "PhoneField",
      "key": "phone",
      "label": "Phone number",
      "conditional": {
        "show": "{{contactMethod === 'phone'}}"
      },
      "validation": {
        "required": "{{contactMethod === 'phone'}}",
        "pattern": "^[0-9]{10}$"
      }
    }
  ]
}

Advantage: Condition described once. UI and validation automatically synchronized.

When Is Each Approach Better?

Choose RJSF (separate schemas) if:

You already have JSON Schema for API validation
Need one schema for frontend and backend
Working in a team where backend generates schemas
Using JSON Schema ecosystem tools
Need compatibility with third-party systems
Simple forms without complex conditional logic

Choose FormEngine (unified schema) if:

Forms are complex with many conditions
UI logic is more important than data validation
Want to avoid duplication
DX and development speed are priorities
Not planning to migrate to another library

4. Transparency Builds Trust

We've published all data, including scenarios where RJSF is faster. This is our principle: honesty is more important than marketing.

If you find errors in the tests — open an issue, we'll fix it.

Detailed Data

Comparison Table (All Scenarios)

Scenario	RJSF (gzip)	FormEngine (gzip)	Winner
Login default UI	175.26 KB	244.19 KB	RJSF (-39%)
Login MUI	231.62 KB	188.54 KB	FormEngine (-19%)
Booking default UI	178.07 KB	316.69 KB	RJSF (-78%)
Booking MUI	234.50 KB	199.26 KB	FormEngine (-15%)

Detailed Bundle Breakdown

RJSF Login (default UI):

Code:     480.72 KB raw / 156.37 KB gzip (80%)
CSS:      117.18 KB raw / 19.27 KB gzip (20%)
Total:    597.91 KB raw / 175.64 KB gzip
Chunks:   2

FormEngine Login (default UI):

Code:     626.23 KB raw / 192.65 KB gzip (59%)
CSS:      438.18 KB raw / 52.42 KB gzip (41%)
Total:    1.04 MB raw / 245.07 KB gzip
Chunks:   2

RJSF Login (MUI):

Code:     725.19 KB raw / 232.47 KB gzip (100%)
CSS:      186 B raw / 169 B gzip (0%)
Total:    725.37 KB raw / 232.64 KB gzip
Chunks:   2

FormEngine Login (MUI):

Code:     622.22 KB raw / 189.27 KB gzip (100%)
CSS:      186 B raw / 169 B gzip (0%)
Total:    622.40 KB raw / 189.44 KB gzip
Chunks:   2

Observation: After switching to MUI, CSS practically disappears for both libraries (186 bytes). The entire difference is in the JS code.

Practical Recommendations

If You DON'T Have a UI Library in Your Project:

Recommendation: RJSF

Reason: 
- Lighter out of the box (175 KB vs 244 KB)
- Faster setup
- No need to choose UI kit

If You HAVE Material UI:

Recommendation: FormEngine

Reason:
- Lighter with MUI (188 KB vs 232 KB)
- No duplication of UI code
- Full integration with your Design System

If You Have Another UI Kit (Ant Design, Chakra, etc):

Recommendation: Depends on adapter availability

RJSF: Has adapters for many UI kits
FormEngine: Currently only MUI and React Suite

Check documentation for both libraries

If Planning to Change UI Kit in the Future:

Recommendation: FormEngine

Reason:
- UI replacement architecture
- Easier to migrate between UI kits
- Less technical debt

Reproducibility

All tests are available and reproducible:

GitHub Repository:
👉 github.com/optimajet/formengine/tree/master/community/examples/bundle-size

Full Report:
👉 formengine.io/documentation/bundle-size-comparison

How to Run Yourself:

git clone https://github.com/optimajet/formengine.git
cd formengine/community/examples/bundle-size
npm install
npm run build
npm run analyze

What You'll Get:

Bundle size report
Chunk visualization
Duplicate packages detection
Tree-shaking analysis

What's Next?

Try It Yourself

RJSF:

📚 Documentation
💻 GitHub

FormEngine:

📚 Documentation
💻 GitHub

Give Feedback

If you:

Found errors in tests
Want to add new scenarios
Disagree with conclusions

Write to us:

Let us know what you think in the comments 👇
GitHub Issues
hello@optimajet.com

Final Verdict

There's no universal winner. And that's good!

RJSF — excellent choice for quick start and JSON Schema purists
FormEngine — optimal for integration into existing projects with UI kits

Choose based on your context, not marketing.

What's your experience with RJSF or FormEngine? Or are you using something else? Share in the comments! 👇

P.S. We're Optimajet, also making Workflow Engine for processes and Workflow Server for business automation.

FormEngine Core is Now Open Source

Optimajet Limited — Tue, 12 Aug 2025 14:22:39 +0000

If you've ever spent hours wrestling with complex forms in React, struggling with validation, localization, or custom components, FormEngine is here to transform your workflow. This powerful tool combines an intuitive visual designer with a flexible, code-first library, enabling you to create any form, from simple to dynamic, data-driven ones, with ease. Born from our team's real-world challenges, FormEngine empowers solo developers and enterprise teams alike to save time and scale projects effortlessly. Curious about how it became a game-changer for developers? Read on to dive into the full story!

Your Ultimate Solution for Building Forms in React.

Here’s a little story about how it all became possible. We began developing FormEngine in early 2023 to address our own internal needs, driven by the immaturity of the React form library ecosystem both in terms of backend-driven form generation and visual form designers. Our goal was to replace our outdated FormBuilder.dev, with a more modern and developer-friendly form builder built for React.

After a thorough investigation, we hoped to find an open-source library we could build on something robust enough to support our team and integrate seamlessly into our commercial products: Optimajet Workflow Server and form-related plugins for WorkflowEngine.

We evaluated the most popular MIT-licensed libraries and have great respect for React Hook Form, Formik, React Final Form, and SurveyJS, each of which has made a significant contribution to the React ecosystem.
When tested against the strict internal requirements of the Optimajet development team, none could fully deliver the flexibility, integration depth, and scalability needed for our enterprise-grade use cases.

One of the key requirements especially for large teams in big tech companies or custom software development firms is the ability to easily and quickly integrate custom components. We recognized that this was a common pain point across the industry, and we had the expertise to solve it.

That insight led us to a bold decision: to build the best React-based FormBuilder from scratch-first and foremost, for ourselves. We surveyed our enterprise customers and small teams building business applications for workflow automation. Based on their feedback and requirements, we formed the foundation for what we believe to be an ideal form library one that supports code-first form creation in React, and serves as the engine behind a low or no-code visual form designer.

Here is the list of requirements and brief explanations that guided the Optimajet team when we started developing FormEngine Core.

Lower learning curve: Easily create forms using typed FormEngine Core functions, without writing components or learning complex React concepts. JSON representation of the form is also supported for configuration-driven use.
Built-in form validation: Data validation works out of the box with no extra code. Required fields, error messages, and rules are defined directly in code or JSON. Easily integrates with third-party validation libraries.
Built-in localization: Forms are ready for multi-language support out of the box. Third-party localization libraries can be integrated if needed.
Dynamic CSS and responsive layout support: Forms automatically adapt to different devices and styles no additional layout code needed.
Built-in actions: Forms support actions like submit, reset, and external calls out of the box. Define only what you need in code or JSON and it’ll just work.
Reusable forms across apps: Cross-project compatibility just copy and use forms are easily portable between applications with minimal effort. A single JSON object contains the full structure, logic, styles, validation, and actions.
Programmatic form creation and dynamic generation: Build or modify forms in real time using code or external data sources.
Ready-to-use component library: Includes built-in components and supports easy integration of custom ones. Get started fast without sacrificing flexibility.
Easy custom component integration: Quickly define your own component by specifying its name, type, and props.
Ready to use with popular frameworks: Works seamlessly with Next.js, Remix, and other modern React stacks no special setup needed.
High performance and lightweight: Fast load times, smooth rendering, and minimal impact on app performance.

On October 31, 2023, we released FormEngine 0.0.13 our new standalone commercial product. Release notes →

This marked the beginning of a journey to bring to life everything our development team had envisioned for the platform. And right from day one, the results confirmed we were on the right track.

We delivered a complete, time-saving tool for development teams something that works just as well for solo developers as it does for large projects. Whether you're building a few simple forms or managing hundreds or thousands of dynamically generated ones from a backend FormEngine just works.

The initial sales were strong, and as demand grew, we even experimented with pricing tiers and product options to better understand what triggered the “Aha!” moment for our users.

That moment where everything clicks and the value is obvious.

We’re still searching for a definitive answer to what exactly made the product such a commercial success, especially among enterprise teams. But one thing is clear: we hit a real need, and we’re excited to keep building on it.

Thanks to the commercial licenses issued to our partners custom software companies we’ve been improving the FormEngine libraries day by day, with one clear goal:

To create the best React-based form solution on the market for developers and businesses who want powerful forms without the usual complexity.

We give developers everything they need to build real, working forms without the usual mess of extra tools, boilerplate, and setup.

@react-form-builder/core Community MIT Open Source Form Library for React

@react-form-builder/components-rsuite Form Components Library

@react-form-builder/designer Premium Drag-and-Drop Form Builder, also known as the Visual Form Designer

Why FormEngine Core is Now Open Source?

Many of our partners, who use FormEngine as part of their business process automation and approval workflow applications, asked us to open up the core Formengine so they could deeply integrate it into their systems and even extend its functionality where needed.

And now, after nearly two years of development and five major releases, the time has come.

On 26 June 2025, we are proud of the quality, stability, and architecture of our code, and we are ready to share it. By open-sourcing the FormEngine Core library, we make this technology freely available to the global developer community, fostering innovation, transparency, and long-term adoption.

Your support means the world to us, and we’d love for you to be part of this exciting new chapter for FormEngine.

If you find value in what we’re building, consider giving us a ⭐️ on GitHub it helps more amazing developers like you discover FormEngine Core.

Open source thrives on collaboration, and we warmly welcome contributors who want to join us on this journey. Whether it’s contributing code, sharing ideas, or spreading the word, your involvement will help FormEngine, and our growing community thrive.

With gratitude and excitement, The Optimajet Developers Team

A True React Hook Form Alternative – FormEngine Core 4.0 Is Now MIT Licensed and Free! 🚀

Optimajet Limited — Tue, 27 May 2025 18:06:46 +0000

React developers, here's big news! On May 15, 2025, Optimajet released FormEngine Core 4.0, making essential libraries available under the permissive MIT license free even for commercial use. FormEngine is now the leading alternative to React Hook Form, especially for teams building complex, interactive forms.

Why switch from React Hook Form to FormEngine?

⚡️ Rapid and Simple Setup

React Hook Form requires extensive manual setup of controllers, hooks, and validation logic. FormEngine simplifies this by leveraging intuitive, schema-based definitions.

🎨 Powerful Drag-and-Drop FormEngine Visual Designer

Unlike React Hook Form’s code-only approach, FormEngine includes an intuitive visual editor, allowing instant form creation and modification, significantly speeding up development. (Note: FormEngine Visual Designer is a paid component for commercial use; however, its full functionality is available for unlimited testing.)

🔌 Easy Custom Components Integration

React Hook Form’s custom component integration can be cumbersome. FormEngine makes this seamless, simplifying component binding and custom logic implementation.

📱 Real-Time Form Previews

Get instant visual feedback as you build forms. React Hook Form needs extra setup or third-party tools for similar functionality.

Built-In Component Library

Unlike React Hook Form, FormEngine comes with a built-in library of ready-to-use components (@react-form-builder/components-rsuite), further accelerating development and reducing the need to create components from scratch.

Completely Free and MIT Licensed

FormEngine’s core libraries are now MIT-licensed and fully free, even for commercial use:

📦 @react-form-builder/core
📦 @react-form-builder/components-rsuite
📦 @react-form-builder/viewer-bundle

💡 Highlights of FormEngine Core 4.0:

UI-Agnostic: Integrate effortlessly with UI libraries like MUI, Ant Design, shadcn/ui, and more.
Framework-Friendly: Built-in support for Next.js, Remix, and framework-agnostic CDN deployment.
Multi-Database Compatibility: Seamlessly use MySQL, PostgreSQL, MongoDB, SQLite, and more.
Robust Validation: Powered by Zod, with extensible support for Yup, AJV, Superstruct, and Joi.
Dynamic & Responsive: Create reactive, adaptive layouts with MobX-powered dynamic properties.
Flexible Storage: Store forms as JSON or generate them programmatically.

🎬 Watch the video to see FormEngine in action—start building your forms faster, smarter, and with greater ease than ever before!

In this step-by-step tutorial, I'll walk you through building a simple React demo app using FormEngine. You'll see how quickly you can design, render, and manage forms — without writing endless custom code.

Install

npm install @react-form-builder/core

Quickstart

import {viewWithCss} from '@react-form-builder/components-rsuite'
import {buildForm, FormViewer} from '@react-form-builder/core'

const simpleForm = buildForm({errorType: 'RsErrorMessage'})
  .component('container', 'RsContainer')
  .style({flexDirection: 'row'})
  .children((builder) =>
    builder
      .component('firstName', 'RsInput')
      .prop('placeholder', 'Enter your first name')
      .prop('label', 'First Name')
      .validation('required')

      .component('lastName', 'RsInput')
      .prop('placeholder', 'Enter your last name')
      .prop('label', 'Last Name')
      .validation('required')
  )

  .component('birthDate', 'RsDatePicker')
  .prop('label', 'Birth Date')
  .prop('oneTap', true)
  .validation('min').args({value: '1900-01-07T12:25:37.000Z'})

  .component('submit', 'RsButton')
  .prop('children', 'Submit')
  .prop('color', 'blue')
  .prop('appearance', 'primary')
  .event('onClick')
  .commonAction('validate').args({failOnError: true})
  .customAction('onSubmit')
  .json()

export const App = () => {
  return <FormViewer
    view={viewWithCss}
    getForm={() => simpleForm}
    actions={{
      onSubmit: (e) => {
        // submit the form to the backend
        alert('Form data: ' + JSON.stringify(e.data))
      },
    }}
  />
}

What you'll learn:

How to install and set up the FormEngine Core Library
Creating and editing forms using JSON
Running your app and previewing form behavior
Using the FormEngine Visual Designer to create forms

🌍 Help us grow the ecosystem, if you like the project:

⭐ Star us on GitHub

💬 Share feedback! Have feature requests or thoughts on the docs? Share them in the comments below!

🔗 Mention @optimajet Formengine X / Twitter

🚀 This is just the beginning — part two is on the way!

We'll provide a detailed comparison between React Hook Form and FormEngine Core.

📘 Docs, Live Demo & Examples: formengine.io/documentation

We’d love to address your specific questions, so please leave your questions in the comments, and we'll include the answers in our upcoming comparison!

Key differences between BPMN diagrams and Optimajet .NET Workflow Engine process schemes

Optimajet Limited — Mon, 04 Nov 2024 16:06:28 +0000

Element specialization

In BPMN, there are a lot of elements that often have narrow specializations and are categorized into Tasks, Gateways, and Events, although other distinct elements exist as well. The Sequence flow is particularly significant and stands out.
In Workflow Engine, there are only two types of elements in the scheme — Activities and Transitions. By combining the configurations of these two elements, you can create Workflow Engine schemes that function similarly to the corresponding BPMN elements.

Activity is not a Task

At first glance, an Activity appears as a rectangle, similar to a Task, and it may seem like these elements are alike. However, they're actually quite different. An Activity can represent a Service Task, a Gateway, or even an Event. The main function of an Activity is to execute your code, but the overall behavior of the scheme (i.e., the direction and manner in which the process flows next) depends on the settings of the outgoing Transitions from the Activity.

For example, if an Activity has Transitions triggered by Commands, it acts similarly to an Event-based Gateway; however, unlike a Gateway, the Activity can execute some code. If the Transitions from an Activity are configured to start parallel processes, then that Activity will behave like a Parallel Gateway. And so on.

Transition is not a Sequence Flow

At first glance, Transition and Sequence Flow may seem like similar elements, as both represent arrows between elements on a diagram. However, they're actually quite different.

In Workflow Engine, a Transition defines how and where the process execution will transition. For example, a process can move to the next state based on a Timer or a Command. What is set by events in BPMN is managed through transitions in Workflow Engine. Additionally, Transitions can be conditional, and access to them can be restricted to specific users or roles. Transitions also determine parallelism, which in BPMN is either set through Gateways or implicitly defined.

In BPMN, however, a Sequence Flow only defines the direction of the transition. This element has almost no settings, except for flows coming out of exclusive gateways.

Parallelism difference

Parallelism in BPMN and Workflow Engine operates on different, yet non-contradictory principles.

In BPMN, parallel execution is defined either explicitly, using a Parallel Gateway, or implicitly, for example, when multiple Sequence Flows emerge from a single Service Task or Event. In this case, it is considered that the process remains singular, but several tokens are introduced. This can lead to a situation where, if you don't introduce a merging element or remove these tokens, multiple tokens will continue during sequential process execution.
In Workflow Engine, you can assume that there is always only one token within a single process, and parallelism is achieved by creating dependent processes (called subprocesses in Workflow Engine). These subprocesses depend on the process that spawned them, and you can retrieve a list of Activities where the parent process and all its child subprocesses are located, as well as manage the parent process and its subprocesses collectively. The creation and merging of processes are handled by transition settings. However, if this approach is unfamiliar, you can use the Parallel Gateway, which replicates the behavior of its BPMN counterpart.

Subprocesses in BPMN and Workflow Engine are completely different

In BPMN, a Subprocess is merely a nested part of the main diagram that can be collapsed. It can't be reused and is primarily for aesthetic purposes. Workflow Engine has a similar feature called Inline Activity. This is a special activity that embeds another scheme into the current one. The embedded scheme can be used in multiple other schemes, allowing for reusability.
In Workflow Engine, a subprocess is a dependent process, as mentioned earlier.

Workflow Engine provides real access control to Commands

In Workflow Engine, Actors are part of the process, and you can set restrictions on command execution (similar to a Message Catch Event) by specific users directly within the scheme. BPMN doesn't offer such functionality explicitly.

Execution ready approach

A valid Workflow Engine scheme is always ready for execution and can be run on the Workflow Engine. In contrast, a valid BPMN diagram might just be an illustration, and no engine will necessarily be able to execute it.

Ability to set the Process to any state

In Workflow Engine, a running process can always be forcibly set to any of its states. BPMN doesn't offer such a capability.

Armed with this knowledge, let's move on to exploring which BPMN elements are supported in Workflow Engine and how they’re implemented.

Configuring and using BPMN plugin

You can read about how to install, configure, and start using the BPMN Diagram Import Plugin in the .NET Workflow Engine in the official documentation.

Introducing BPMN support in .NET Workflow Engine library

Optimajet Limited — Mon, 04 Nov 2024 15:55:44 +0000

Many .NET developers, during the POC process, requested that we add the ability to import BPMN schemas into our WorkflowEngine. In an new update, Optimajet's Workflow Engine now introduces foundational BPMN support, making it easier for .net developers to work with familiar process elements and streamline workflow designs. While Workflow Engine is not a dedicated BPMN engine, this new capability bridges some gaps by enabling users to work with BPMN elements, enhancing compatibility and efficiency for process modeling.

Workflow Engine is not a BPMN engine, so full compliance with the BPMN standard isn't achievable. However, the process execution principles in Workflow Engine align with those of BPMN. Consequently, BPMN support in Workflow Engine is grounded in two key aspects:

BPMN Elements in Workflow Engine Scheme: We have added basic BPMN elements to Workflow Engine so that when a BPMN diagram is imported, familiar elements remain, making it clear where attention should be focused. Some of these elements are useful on their own, such as the Parallel Gateway, which can be beneficial for creating and merging subprocesses in Workflow Engine in a simpler and more understandable way.

BPMN Import: You can import a BPMN diagram, and it will be converted into a Workflow Engine scheme. A detailed log and comments will indicate what is unsupported or only partially supported in the current implementation.
The structure of this section will be as follows. First, we will describe the differences between BPMN diagrams and Workflow Engine process schemes. Then, we will review which BPMN diagram elements are supported in Workflow Engine and how they are implemented. Finally, we will explain how to integrate BPMN import into an application running Workflow Engine and how to customize this import process.

BPMN elements support in Workflow Engine

The BPMN plugin for Workflow Engine currently supports only the most essential BPMN elements, with new functionalities being progressively added. Here’s an overview of the supported and partially supported elements:

Tasks

Generic Task - Converted into a standard Activity.
Service Task - Transformed into a specialized Activity based on the values of attributes like camunda:topic and camunda:delegateExpression.
Receive Task - Supported, with an outgoing transition triggered by a Command.
User Task. Not supported yet; support will be added after the release of the plugin integrating Workflow Engine with forms.
Business Rule Task. Not supported; will be converted into a standard Activity.
Manual Task. Not supported; will be converted into a standard Activity.
Script Task. Not supported; will be converted into a standard Activity.
Send Task. Not supported; will be converted into a standard Activity.

Gateways

Exclusive Gateway and Parallel Gateway - Supported.
Event-Based Gateway - Supported and converted into an Activity with transitions triggered by corresponding events.
Inclusive and Complex Gateways - Not supported and are currently converted into standard Activities.

Events

Start Events - Generic Start Event is supported, with partial support for Message and Timer types.
End Events - Generic and Terminate End Events are supported.
Boundary Events - Partially supported; Message and Timer Boundary Events are converted into transitions with Command and Timer triggers.

Other Elements

Subprocesses and Pools - Converted to Inline Activities or separate workflow schemes.
Call Activities and Lanes - Not supported; Lanes are ignored due to no equivalent grouping method in Workflow Engine.
Parallelism
In BPMN diagrams, implicit parallelism is converted to explicit parallelism in Workflow Engine, using dashed lines to mark the start of subprocesses and dash-dotted lines for their completion.

Feedback
Since BPMN support is an evolving feature, your feedback on the BPMN elements you need is invaluable to us. Please let us know in the comments below which elements are critical to your workflows, so we can prioritize their implementation in future releases. We will gradually add new BPMN elements based on requests from .NET developers who have chosen Workflow Engine as the workflow library for their business applications.

Maximizing Hardware Utilization with Parallelism in Workflow Subprocesses Using Optimajet Workflow Engine

Optimajet Limited — Wed, 11 Sep 2024 10:31:13 +0000

Introduction

In today's fast-paced digital landscape, businesses demand agility, scalability, and high performance from their software solutions. Workflow engines play a pivotal role in orchestrating tasks and automating processes, ensuring that everything runs smoothly. But when these processes become more complex and resource-intensive, how can workflow engines scale efficiently and stay responsive? The answer lies in threads. Examples of schemas using subprocesses in different workflows are described in detail in the official documentation of the Workflow Engine.

However, in this article, we will try to explain complex things in simple terms. We'll explore what threads are in the context of the Optimajet Workflow Engine and how they can dramatically enhance efficiency, enabling smoother execution and more responsive workflows.

What is Parallelism in Workflow Subprocesses?

In modern software systems, the need to optimize for both performance and resource efficiency has become a critical challenge. One of the most powerful techniques for achieving this is leveraging parallelism within subprocesses when building workflow schemas. By running multiple subprocesses concurrently, you can unlock higher performance and make full use of your hardware’s processing power. Optimizing workflows in this way can dramatically improve system efficiency, especially when dealing with complex workflows that involve multiple independent tasks. Parallelism refers to the ability to execute multiple independent or semi-independent subprocesses simultaneously.

In the context of workflow automation with Optimajet Workflow Engine, this means that different stages of a workflow can be run in parallel as Subprocesses, rather than waiting for each one to finish before starting the next. This improves efficiency, reduces execution time, and allows your workflows to handle more tasks concurrently.

What Are Threads in a Workflow Engine?

In simple terms, threads are independent sequences of execution within a larger process. In a multi-threaded environment, multiple tasks or operations can run simultaneously, each in its own thread. This allows for parallel processing, where multiple parts of a workflow can be executed at the same time rather than sequentially.

Within the Optimajet Workflow Engine, threads enable you to break down a workflow into parallel paths of execution. These paths can run independently or concurrently, meaning that tasks that don’t depend on each other can proceed without waiting for others to complete. This parallelism can significantly boost performance and efficiency, especially in complex workflows where multiple independent tasks need to be handled simultaneously.

Threads and Their Role in Parallelism

At the core of parallelism is the concept of threads. A thread is a lightweight unit of execution that can run code independently of other threads. In modern multi-core processors, threads allow you to take full advantage of the hardware by distributing work across different cores.

In the Optimajet Workflow Engine, subprocesses within a workflow can be split into multiple threads. However, unlike some systems that automatically handle thread allocation, Optimajet requires developers to configure thread distribution manually when designing the workflow schema. This gives developers full control over how tasks are distributed across threads, ensuring that workflows are tailored to specific use cases and hardware environments.

By using threads, developers gain several important benefits for efficiency, performance, and flexibility, which make thread-based parallelism an essential tool for optimizing workflows.

Benefits of Using Threads in Workflow Schemes

1. Parallelism and Efficiency

Benefit: Threads allow for the parallel execution of tasks that can be performed simultaneously, meaning that workflows can handle multiple operations at once.
Why Use It: If you have tasks that don’t depend on each other—like sending notifications while processing data—threads can significantly speed up the workflow by reducing idle or waiting time.

2. Better Resource Utilization

Benefit: Threads make better use of system resources, particularly in multi-core processors. Instead of running tasks sequentially on a single CPU core, threads can distribute tasks across multiple cores for more efficient processing.
Why Use It: For workflows handling large datasets, high-volume tasks, or I/O operations (like API calls or database queries), threads maximize throughput by fully utilizing your system’s computing power.

3. Concurrency and Responsiveness

Benefit: Threads allow workflows to continue processing while waiting for external events (e.g., user input, network responses). This keeps the workflow responsive instead of stalling.
Why Use It: In complex workflows involving long-running tasks, threads prevent bottlenecks by keeping the rest of the workflow active.

4. Asynchronous Processing

Benefit: Threads enable asynchronous execution, meaning tasks can be initiated and the workflow can move forward without waiting for them to complete, revisiting them once results are ready.
Why Use It: This is particularly useful when interacting with external services or databases. Instead of halting the workflow, other operations can proceed, making the entire process more efficient.

5. Scalability

Benefit: Threads help workflow engines scale by handling large numbers of simultaneous operations. This ensures that as workflows grow in complexity, they can split the workload across multiple threads and execute them concurrently.
Why Use It: For businesses with growing demands, thread-based parallelism ensures that workflows can handle larger volumes of tasks or users without degrading performance.

6. Load Balancing

Benefit: In distributed systems, threads can help balance the load by distributing tasks across multiple systems or servers, preventing any one system from being overloaded.
Why Use It: When scaling workflows to handle multiple users or requests, thread-based processing distributes tasks evenly, avoiding overloads in certain parts of the system.

7. Improved User Experience

Benefit: By performing background operations on separate threads, workflows can maintain a smoother, more responsive interface for users.
Why Use It: For workflows that involve user interaction (e.g., form submissions, approvals), threads allow background processing to occur without affecting the front-end experience.

8. Concurrency Control

Benefit: Workflow engines utilizing threads provide mechanisms to manage concurrent processes, ensuring that shared resources aren’t corrupted due to conflicting operations.
Why Use It: When multiple threads need to access or modify shared data, thread-based concurrency control ensures safe access, avoiding race conditions and data corruption.

How Optimajet Workflow Engine Manages Threads

Unlike some workflow engines that automatically distribute tasks across threads, the Optimajet Workflow Engine requires developers to manually configure thread assignment within the workflow schema for subprocesses.
Here’s how it works:

Manual Thread Assignment

In the Optimajet designer, developers define which subprocesses should run in parallel and manually specify how they will be distributed across threads. This allows for more control over the threading model, making it possible to tailor workflows based on specific system requirements and workloads.

Task Scheduling by Design

The manual assignment of threads ensures that developers have full control over the scheduling of parallel subprocesses. While this requires some upfront design, it allows for more optimized performance as each task can be carefully scheduled based on the system’s capabilities.

Practical Example

Imagine a workflow designed to process a customer order. This workflow may include subprocesses like validating the payment, checking inventory, generating shipping labels, and sending notifications to the customer. In a sequential workflow, each subprocess would run one after the other, increasing the time it takes to complete the order.

By using Optimajet’s parallelism and manually assigning threads:

Payment validation runs on one thread.
Simultaneously, inventory checking runs on another thread.
While these are happening, shipping label generation and notification sending can run on other threads.

The result is a much faster order processing time, as independent tasks are executed in parallel, fully utilizing the CPU cores. In this scenario, the system is able to handle more orders per minute, improving throughput and customer satisfaction.

Conclusion

Parallelism in workflow subprocesses, combined with manual thread assignment in Optimajet Workflow Engine, unlocks the full potential of your hardware. By distributing tasks across multiple threads, you can maximize CPU utilization, reduce latency, and increase throughput. Optimajet’s support for manual threading ensures that developers have the flexibility to optimize workflows for specific use cases and hardware environments.

If your workflows are still running sequentially, it’s time to explore the power of parallelism. With Optimajet, you can build faster, more efficient workflows that scale effortlessly with your system’s needs.

Understanding Workflow Schemes and Instances in Optimajet Workflow Engine

Optimajet Limited — Tue, 03 Sep 2024 11:14:24 +0000

Our team conducts daily demonstrations of the Workflow Engine and Workflow Server. Quite often, through interviews with those who are just beginning to develop their integration architecture, we discover that very simple concepts are not always immediately understood. One such concept is the difference between a workflow scheme and workflow instances. This understanding can be critically important for product licensing, as the Optimajet license allows for the creation of an unlimited number of instances. The limitations of the free community version apply only to the capabilities of the scheme itself.

Free limits:

Activity: 15
Transition: 25
Command: 5
Schema: 1
Thread: 1

This means that you can create and manage an unlimited number of instances for relatively simple schemes, effectively meeting basic needs when choosing a workflow engine.

Let’s dive deeper into this topic.

In the context of the Optimajet Workflow Engine, a workflow scheme and a workflow instance are two key concepts that are important to understand.

Workflow Scheme

A workflow scheme is an abstract description of the sequence of actions, conditions, and transitions between them. Simply put, it is a plan or model of a workflow that defines how work should be carried out. The scheme specifies the steps, possible transitions between them, the conditions that must be met for a transition, as well as various other parameters and settings.

An example of a workflow scheme might include stages such as:

Request creation
Request review
Decision making
Process completion

A workflow scheme is a static structure that describes the process without being tied to specific data or instances of the process.

Workflow Instance

A workflow instance is a specific execution of a workflow scheme. When a process is launched based on a given scheme, an instance of that process is created. The instance includes the current state of the process, the data that has been passed through the stages, and the history of actions performed.

If you imagine the scheme as a building blueprint, the instance is the actual building constructed according to that blueprint. Therefore, there may be multiple instances of the same workflow, each corresponding to the same scheme but containing unique data and having its own current state.

Differences

Workflow Scheme – This is the general model that describes how the process should proceed.

Workflow Instance – This is the specific execution of the process according to this model, with certain data and the current state.
Thus, the workflow scheme is a concept, while the instance is its practical implementation.

Very important

Please write in the comments about the challenges you face when choosing a workflow engine in the .NET stack. What is the most critical deal-breaker when deciding which library to use? We will try to create a guide that benefits the entire community and helps you.

BPMN Diagram Import Feature in the .NET Workflow Engine Library by Optimajet

Optimajet Limited — Tue, 03 Sep 2024 09:52:41 +0000

Introduction

We are excited to announce a new feature that will be available in one of the upcoming releases of Optimajet Workflow Engine — BPMN diagram import. This feature is designed to significantly simplify and accelerate the process of creating and configuring business processes for .NET Developers. What’s even more important, it is a unique offering in the market of on-premise .NET libraries.

We are starting extensive testing of BPMN diagram import among Optimajet Workflow Engine users. If you need this feature and are willing to provide feedback, please contact us, and we will grant you access.

What is BPMN?

BPMN (Business Process Model and Notation) is an international standard for describing and modeling business processes. BPMN provides a visual language that is equally understandable to both business analysts and technical specialists. It is a universal tool for creating clear and comprehensive process documentation.

Key Advantages of the BPMN Diagram Import

Unique Market Offering: Optimajet Workflow Engine now offers a unique capability for on-premise .NET solutions — BPMN diagram import for Dot Net developers, it's rare to find a library that offers this functionality, making our product a trailblazer in the field
Accelerated Process Creation: With BPMN diagram import, users can instantly transfer their existing process models into Optimajet Workflow Engine, significantly reducing the time required to set up new workflows.
Support for International Standards: The new tool supports the BPMN standard, making your processes compatible with other systems and enabling easy exchange of diagrams across various platforms and teams.
Ease of Use: Importing BPMN diagrams is straightforward and involves just a few simple steps. The user uploads the diagram file, and Optimajet Workflow Engine automatically converts it into a workflow that is ready for further configuration and execution.
Handling Complex Processes: The new feature allows for easy import and management of processes of any complexity, including parallel flows, loops, and branches, expanding the scope of your automation capabilities.

In the image below, you can see an example of a pizza order BPMN diagram.

How Does It Work? Just Three Simple Steps

1. BPMN File Upload: The user selects and uploads a BPMN file (.bpmn) through the Optimajet Workflow Engine interface.

2. Automatic Conversion BPMN to Workflow Engine Schema: Workflow Engine analyzes the structure of the uploaded diagram and automatically converts it into a one or several workflow schemas that can be further configured or executed.

For example, the import of the pizza order BPMN diagram was transformed into two separate workflows: the Customer Workflow Schema and the Vendor Workflow Schema.

Customer Workflow Schema

Vendor Workflow Schema

3. Flexible Configuration: After import, users can make any necessary adjustments to the process, adapting it to specific business requirements, and start using it right away.

Practical Application

The BPMN diagram import feature will be especially valuable for companies that are already actively using BPMN in their work and want to migrate their processes to the Optimajet Workflow Engine platform with minimal effort. It is also an excellent tool for quickly launching automation when ready-made solutions need to be implemented promptly.

Conclusion

BPMN diagram import is an important enhancement that will be introduced in the upcoming versions of Optimajet Workflow Engine. We are confident that this feature, unique for on-premise .NET libraries, will help our users achieve better results in business process automation, making it faster, simpler, and more efficient.

If you need this feature and are willing to provide feedback, please contact us Or Stay tuned for updates and be ready for new possibilities in the upcoming release!

Very important

Workflow Engine: Release Notes Updates - BPMN Plugin is Ready to use!

October 24, Workflow Engine: 2024 16.0.0

Breaking Changes

BPMN import functionality has been released! Be sure to switch to the new BPMN plugin. For more details, please refer to the BPMN documentation.

Become a .NET Workflow Engine Pro: Follow This Step-by-Step Learning Roadmap!

Optimajet Limited — Thu, 15 Aug 2024 14:52:19 +0000

The Optimajet team supports developers of their products during the Proof of Concept stage. In most cases, when .NET developers tackle their own tasks or their clients' business challenges, they have to start from scratch in understanding the architecture of various .NET engines. Initially, they study the market and need to grasp the capabilities of all products, along with their pros and cons.

Unfortunately, all products are different, and it is nearly impossible to compare them, because they are structured very differently. However, there are some fundamental principles.

In this article, we have tried to compile a learning roadmap using our documentation as an example, to make it easier for you to understand the principles of the Optimajet Workflow Engine. This engine is very easy to learn and won't require more than two weeks of your time. After this, you'll be able to understand any engine, professionally compare the solutions available on the market, and make the right choice.

To reinforce the materials through practice, we recommend installing and run WorkflowServer in a Docker container and creating working schemes to test how everything works in practice.

Starting from the Functionality stage, a basic understanding of C# and .Net may be required since Optimajet Workflow Engine is a .Net library for developers, and most tasks require extending the engine’s capabilities using C# code.

Basics

Start by reading the articles in the Workflow Scheme section. As a foundation, it's important to understand how the basic building blocks of a scheme work:

You should have a good understanding of how they are interconnected and what they are used for.

At this stage, there's no need to look for real-world applications for the schemes; just practice creating them for different scenarios without focusing on implementation. It’s also important to understand how to create scheme instances—processes—and the lifecycle of these instances. You don’t need to delve too deeply at the start, simply creating a few processes and experimenting with their states will suffice.

Functionality

At this stage, you'll need to figure out how to turn empty schemes into the workhorses of business, and here, unfortunately, C# .Net knowledge is essential. The Optimajet Workflow Engine is designed for developers. The engine’s functionality is implemented through three main components: Actions, Conditions, and Rules, which developers see as IWorkflowActionProvider and IWorkflowRuleProvider.

Practice implementing these interfaces and create a scheme that performs some useful work—saving data to a database, sending notification emails, or requesting user approval.

You should also learn how to programmatically trigger transitions using SetState, SetActivity, and Resume.

Complex Schemes

The ability to create “simple” schemes consisting of branches with conditions and action implementations is sufficient for 80% of scenarios. However, for the remaining cases, you’ll need some advanced techniques: subprocesses and parallel task execution, embedding one scheme into another, and creating loops in the scheme (this feature is implemented via plugins).

These features allow you to create very advanced schemes. At this stage, it’s important to understand how scheme migrations occur when they are changed. Also, explore the important mechanism of Pre-execution, which allows you to predict the movement of the scheme without changing its state. By the end of this stage, you should be confident in developing complex business processes using WFE.

Customization

Quite often, users of Optimajet Workflow Engine want to customize the product and extend its functionality. There are two components here: visual and logical. Both can be combined into a plugin and installed as a single package.

Visual customization

Visual customization is based on the fact that any element of the designer is a template written in Vue.js, which the client can change without access to the source code. There are also some specific features like autocomplete or providing forms for parameters.

The logical part allows you to create your own custom activities that perform some specific work. They work thanks to metadata (annotations) that can be attached to any activity, and a form for editing these annotations is automatically generated, using the parameter form mechanism from the visual part.

As part of this learning stage, you should study how localization works, which can also be configured in the designer itself. Here, you can learn how to add languages for localization.

Plugins

This stage is not as difficult as the previous one but is quite extensive and requires an understanding of how customization and plugins work. A lot of work has been done, and most of the standard scenarios of logical customization have already been written by Optimajet and included in the package.

These are various plugins: A Basic plugin one with a set of different tools, an Approval plugin that implements an inbox system for tracking and notifying actors moving the process state, and an Assignment plugin for task assignment. There are also other minor plugins, which you can find on the documentation website and review on your own; they are mostly integrations with various services and technologies.

Advanced Features

This stage of learning covers very large and complex concepts, specific tasks may arise, and it’s important to know how they work. The difference between a single-server and multi-server setup, understanding the concept of Runtime, Runtime configuration options, and recovery after a failure. The specifics of data storage by the Optimajet provider and the configuration of multi-tenancy mode should also be reviewed. Additionally, familiarize yourself with scheme generation and the process of building a scheme.

Various Useful Features

It’s difficult to categorize these features, but they are worth mentioning as they are not the most complex features and additions, but also guides. They will also be useful for understanding the Optimajet Workflow Engine at an advanced level.

We will continue to supplement and update this article based on your questions and feedback, so that the Learning Roadmap becomes the best version of itself. Please be active in the comments and feel free to ask your questions.

Formengine Release notes 1.3.0

Optimajet Limited — Fri, 14 Jun 2024 09:24:29 +0000

Added the RsSignature component for drawing signatures.
The text of the form data and errors in the left panel on the designer preview is now scrollable.
Fixed minor style breakdowns in the designer scrollbars.

Formengine Release notes

Comprehensive Guide: Integrating a Drag-and-Drop Form Builder for Camunda.

Optimajet Limited — Mon, 10 Jun 2024 09:16:49 +0000

Introduction:

Camunda is a Open Source powerful business process management (BPM) solution that provides a flexible and scalable platform for process automation. It supports BPMN for process modeling, CMMN for case management, and DMN for decision modeling.

Optimajet team receives a large number of questions regarding the integration of the form builder for Camunda. We have written a detailed guide so that all developers can connect [Optimajet Formengine to Camunda.

Formengine is a Drag & Drop Form Builder Library for React. OptimaJet FormBuilder is a lightweight front-end tool that offers an easy and flexible approach to adding drag-and-drop form functionality to your React applications.

In this guide, we will use an example from the Camunda
repository, Using React Forms with Tasklist, and modify it so that the forms are displayed using Optimajet FormEngine.

Requirements

To follow along, you will need the following:

Ensure that both Camunda 7 Community Edition and Camunda Modeler are installed on your system if they are not already.

Starting with the React Example

The Camunda repository on GitHub provides a simple and
clear instruction for using React
in Tasklist. Let's walk through it together.

Add loadReact.js to Camunda Tasklist:

Download loadReact.js
and place it in the app/tasklist/scripts/react directory of the Camunda Tasklist webapp. For example, if you are using Tomcat, the path
will be /webapps/camunda/app/tasklist/scripts/react.

This script will load React and ReactDOM from a CDN and add them to the global scope. If you prefer to use different versions of React,
adjust the import paths in the script accordingly.

Add the loader as a custom script:

Modify the app/tasklist/scripts/config.js file of the Camunda Tasklist webapp to include the loader script. For Tomcat, this file is
located at /webapps/camunda/app/tasklist/scripts/config.js. Update the file as shown in
the example.

config.js



   customScripts: [
     'scripts/react/loadReact.js'
   ]

Launch Camunda if it is not already running. Next, we need to upload the process definition and forms from GitHub, then upload them to
Camunda using Camunda Modeler and start the process. Let's do it step by step:

Download the following files:

Open Camunda Modeler and load the react-example.bpmn file:

Update the form keys:

Click the "Invoice Received" element and change the Form key from embedded:app:start-form.html
to embedded:deployment:start-form.html:
Click the "Approve Invoice" element and change the Form key from embedded:app:task-form.html to embedded:deployment:task-form.html:

Deploy the process:

Click the Rocket button at the bottom of the screen, then click the plus button next to "Include additional files" and add the previously downloaded start-form.html and task-form.html files:

Click the "Deploy" button. You should see a message indicating that the Process Definition has been successfully deployed:

To ensure everything works correctly, follow these steps to test the setup in the Camunda web interface. If Camunda is running locally, the
address will be something like http://localhost:8080/camunda-welcome/index.html:

Open the Camunda web interface:

Access the Tasklist:

Click on the Tasklist image.
Log in using the credentials demo/demo:

Start the process:

Click on the "Start Process" button on the top panel:
Select "React example" in the "Start process" window:

Fill in the start form:

The form for starting the process, uploaded from start-form.html, should now be displayed.
Fill in the form with the necessary data and click the "Start" button:

View the task list:

The process has started. Now click on "All Tasks" on the left panel.
You should see your task in the task list:

Claim the task:

Click on the task:

Claim the task by clicking on the "Claim" link, which will change to "Demo Demo":

Complete the task:

The form you see is uploaded from the task-form.html file.
Fill out the form by clicking on the "I approve this Invoice" checkbox, then click the "Complete" button:

Verify completion:

The task will be completed:

Creating forms

To connect FormEngine to Camunda, we will use a package that includes a set of components based on React Suite. These components are
utilized in our demo.

First, we need two forms to replace the React forms from the Camunda example. We will omit the process of creating these forms, as it is
straightforward to accomplish. For instance, you can use our demo. Simply drag and drop the necessary
components onto the form and configure their properties as required. Below are the JSON files containing the forms themselves.

start-form.json

Click to view start-form.json



{
  "version": "1",
  "actions": {
    "onChange": {
      "body": "    const setInvoiceDocument = document => e.store.formData.state['invoiceDocument'] = document;\n\n    const blobFile = e.args[0]?.[0]?.blobFile;\n    if (blobFile) {\n        const reader = new FileReader();\n        reader.readAsDataURL(blobFile);\n        reader.onload = () => {\n            setInvoiceDocument(reader.result.replace(/^data:(.*;base64,)?/, ''));\n        };\n        reader.onerror = () => {\n            setInvoiceDocument(undefined);\n        }\n    } else {\n        setInvoiceDocument(undefined);\n    }",
      "params": {}
    }
  },
  "form": {
    "key": "Screen",
    "type": "Screen",
    "props": {},
    "children": [
      {
        "key": "RsContainer 1",
        "type": "RsContainer",
        "props": {},
        "children": [
          {
            "key": "RsLabel 1",
            "type": "RsLabel",
            "props": {
              "text": {
                "value": "Invoice Document:"
              }
            }
          },
          {
            "key": "invoiceDocument",
            "type": "RsUploader",
            "props": {
              "autoUpload": {
                "value": false
              }
            },
            "events": {
              "onChange": [
                {
                  "name": "onChange",
                  "type": "code"
                }
              ]
            }
          }
        ]
      },
      {
        "key": "creditor",
        "type": "RsInput",
        "props": {
          "label": {
            "value": "Creditor:"
          },
          "placeholder": {
            "value": "e.g. \"Super Awesome Pizza\""
          },
          "size": {
            "value": "md"
          }
        }
      },
      {
        "key": "amount",
        "type": "RsNumberFormat",
        "props": {
          "label": {
            "value": "Amount:"
          },
          "placeholder": {
            "value": "e.g. \"30.00\""
          },
          "allowNegative": {
            "value": false
          }
        }
      },
      {
        "key": "invoiceCategory",
        "type": "RsDropdown",
        "props": {
          "label": {
            "value": "Invoice Category:"
          },
          "data": {
            "value": [
              {
                "value": "Travel Expenses",
                "label": "Travel Expenses"
              },
              {
                "value": "Business Meals",
                "label": "Business Meals"
              },
              {
                "value": "Other",
                "label": "Other"
              }
            ]
          },
          "value": {
            "value": ""
          }
        }
      },
      {
        "key": "invoiceNumber",
        "type": "RsInput",
        "props": {
          "placeholder": {
            "value": "e.g. \"I-12345\""
          },
          "label": {
            "value": "Invoice Number:"
          }
        }
      }
    ]
  },
  "localization": {},
  "languages": [
    {
      "code": "en",
      "dialect": "US",
      "name": "English",
      "description": "American English",
      "bidi": "ltr"
    }
  ],
  "defaultLanguage": "en-US"
}

You can see the "start-form" in the screenshot below:

The second form is similar to the first.

task-form.json

Click to view task-form



{
  "version": "1",
  "actions": {
    "onChange": {
      "body": "    const setInvoiceDocument = document => e.store.formData.state['invoiceDocument'] = document;\n\n    const blobFile = e.args[0]?.[0]?.blobFile;\n    if (blobFile) {\n        const reader = new FileReader();\n        reader.readAsDataURL(blobFile);\n        reader.onload = () => {\n            setInvoiceDocument(reader.result.replace(/^data:(.*;base64,)?/, ''));\n        };\n        reader.onerror = () => {\n            setInvoiceDocument(undefined);\n        }\n    } else {\n        setInvoiceDocument(undefined);\n    }",
      "params": {}
    }
  },
  "form": {
    "key": "Screen",
    "type": "Screen",
    "props": {},
    "children": [
      {
        "key": "RsContainer 1",
        "type": "RsContainer",
        "props": {},
        "children": [
          {
            "key": "RsLabel 1",
            "type": "RsLabel",
            "props": {
              "text": {
                "value": "Invoice Document:"
              }
            }
          },
          {
            "key": "invoiceDocument",
            "type": "RsUploader",
            "props": {
              "autoUpload": {
                "value": false
              }
            },
            "events": {
              "onChange": [
                {
                  "name": "onChange",
                  "type": "code"
                }
              ]
            }
          }
        ]
      },
      {
        "key": "creditor",
        "type": "RsInput",
        "props": {
          "label": {
            "value": "Creditor:"
          },
          "placeholder": {
            "value": "e.g. \"Super Awesome Pizza\""
          },
          "size": {
            "value": "md"
          }
        }
      },
      {
        "key": "amount",
        "type": "RsNumberFormat",
        "props": {
          "label": {
            "value": "Amount:"
          },
          "placeholder": {
            "value": "e.g. \"30.00\""
          },
          "allowNegative": {
            "value": false
          }
        }
      },
      {
        "key": "invoiceCategory",
        "type": "RsDropdown",
        "props": {
          "label": {
            "value": "Invoice Category:"
          },
          "data": {
            "value": [
              {
                "value": "Travel Expenses",
                "label": "Travel Expenses"
              },
              {
                "value": "Business Meals",
                "label": "Business Meals"
              },
              {
                "value": "Other",
                "label": "Other"
              }
            ]
          },
          "value": {
            "value": ""
          }
        }
      },
      {
        "key": "invoiceNumber",
        "type": "RsInput",
        "props": {
          "placeholder": {
            "value": "e.g. \"I-12345\""
          },
          "label": {
            "value": "Invoice Number:"
          }
        }
      }
    ]
  },
  "localization": {},
  "languages": [
    {
      "code": "en",
      "dialect": "US",
      "name": "English",
      "description": "American English",
      "bidi": "ltr"
    }
  ],
  "defaultLanguage": "en-US"
}

This is what the second form looks like:

Connecting FormEngine to Camunda

When connecting FormEngine to Camunda, we decided to use a bundle designed for use on any web page. This method does
not require a separate React connection.

During the connection process, we discovered that Camunda uses a strict Content Security Policy, which prohibits some inline CSS used in the
bundle. Therefore, we will connect the component styles separately.

Add loadFormEngine.js:

Place loadFormEngine.js in app/tasklist/scripts/formEngine of the Camunda Tasklist webapp (e.g., for Tomcat, it will
be /webapps/camunda/app/tasklist/scripts/formEngine).

loadFormEngine.js



   const formEngine = document.createElement('script');
   formEngine.crossOrigin = true;
   formEngine.src = 'https://unpkg.com/@react-form-builder/viewer-bundle@1.2.0/dist/index.umd.js';
   document.body.append(formEngine);

Add the loader to config.js:

Modify app/tasklist/scripts/config.js of the Camunda Tasklist webapp to include the loader script. For Tomcat, the path will
be /webapps/camunda/app/tasklist/scripts/config.js.

config.js



   customScripts: [
     'scripts/react/loadReact.js',
      // highlight-next-line
     'scripts/formEngine/loadFormEngine.js'
   ]

Download and add the CSS files:

Download the rsuite-no-reset.min.css file and
the formengine-rsuite.css file. Place them in
the app/tasklist/styles folder. To avoid configuring the CSP policy, download the styles locally.

Modify user-styles.css:

Add the following highlighted lines to app/tasklist/styles/user-styles.css:

user-styles.css



   /*
   .navbar-brand {
     text-indent: -999em;
     background-image: url(./path/to/the/logo.png);
     width: 80px;
   }

   [cam-widget-header] {
     border-bottom-color: blue;
   }
   */

   @import url('./rsuite-no-reset.min.css');
   @import url('./formengine-rsuite.css');

   .rs-picker-select-menu.rs-picker-popup {
     z-index: 2000;
   }

Modifying Forms

In the code of both forms, we will use a simple renderFormEngineForm function that will render the form into an HTML element.

The function accepts the following parameters:

form is the JSON of the form.
container is the HTML element where the form will be rendered.
additionalProps are the additional properties of the FormViewer component.



function renderFormEngineForm(form, container, additionalProps) {
  const viewerRef = {current: null};
  const viewerBundle = window.FormEngineViewerBundle;
  const components = viewerBundle.rSuiteComponents;
  const view = components.view.withViewerWrapper(components.RsLocalizationWrapper);
  const props = {
    getForm: () => form,
    view,
    viewerRef,
    ...additionalProps
  };
  viewerBundle.renderFormViewerTo(container, props);
  return viewerRef;
}

Each form's code will have its own renderCamundaForm function that will link the FormEngine form and the Camunda form, which is stored in
the camForm object. In general, the form code is similar to the forms from the React example. See the form code below for reference.

start-form.html
Click to view start-form



<script>
  function renderFormEngineForm(form, container, additionalProps) {
    const viewerRef = {current: null}
    const viewerBundle = window.FormEngineViewerBundle;
    const components = viewerBundle.rSuiteComponents;
    const view = components.view
      .withViewerWrapper(components.RsLocalizationWrapper);
    const props = {
      getForm: () => form,
      view,
      viewerRef,
      ...additionalProps
    }
    viewerBundle.renderFormViewerTo(container, props);
    return viewerRef;
  }

  function onSubmit(camForm, formRef) {
    const formData = formRef.current.formData.data;
    // the file data was saved via a user action to a user state
    const userState = formRef.current.formData.state;

    camForm.variableManager.createVariable({
        'name': 'invoiceDocument',
        'type': 'File',
        'value': userState.invoiceDocument,
        'valueInfo': {filename: 'invoice.pdf'},
        isDirty: true
      }
    );
    camForm.variableManager.createVariable({
        'name': 'creditor',
        'type': 'String',
        'value': formData.creditor,
        isDirty: true
      }
    );
    camForm.variableManager.createVariable({
        'name': 'amount',
        'type': 'Double',
        'value': formData.amount,
        isDirty: true
      }
    );
    camForm.variableManager.createVariable({
        'name': 'category',
        'type': 'String',
        'value': formData.invoiceCategory,
        isDirty: true
      }
    );
    camForm.variableManager.createVariable({
        'name': 'invoiceID',
        'type': 'String',
        'value': formData.invoiceNumber,
        isDirty: true
      }
    );
  }

  function renderCamundaForm(elementId, camForm) {
    const form = `
{
  "version": "1",
  "actions": {
    "onChange": {
      "body": "    const setInvoiceDocument = document => e.store.formData.state['invoiceDocument'] = document;\\n\\n    const blobFile = e.args[0]?.[0]?.blobFile;\\n    if (blobFile) {\\n        const reader = new FileReader();\\n        reader.readAsDataURL(blobFile);\\n        reader.onload = () => {\\n            setInvoiceDocument(reader.result.replace(/^data:(.*;base64,)?/, ''));\\n        };\\n        reader.onerror = () => {\\n            setInvoiceDocument(undefined);\\n        }\\n    } else {\\n        setInvoiceDocument(undefined);\\n    }",
      "params": {}
    }
  },
  "form": {
    "key": "Screen",
    "type": "Screen",
    "props": {},
    "children": [
      {
        "key": "RsContainer 1",
        "type": "RsContainer",
        "props": {},
        "children": [
          {
            "key": "RsLabel 1",
            "type": "RsLabel",
            "props": {
              "text": {
                "value": "Invoice Document:"
              }
            }
          },
          {
            "key": "invoiceDocument",
            "type": "RsUploader",
            "props": {
              "autoUpload": {
                "value": false
              }
            },
            "events": {
              "onChange": [
                {
                  "name": "onChange",
                  "type": "code"
                }
              ]
            }
          }
        ]
      },
      {
        "key": "creditor",
        "type": "RsInput",
        "props": {
          "label": {
            "value": "Creditor:"
          },
          "placeholder": {
            "value": "e.g. \\"Super Awesome Pizza\\""
          },
          "size": {
            "value": "md"
          }
        }
      },
      {
        "key": "amount",
        "type": "RsNumberFormat",
        "props": {
          "label": {
            "value": "Amount:"
          },
          "placeholder": {
            "value": "e.g. \\"30.00\\""
          },
          "allowNegative": {
            "value": false
          }
        }
      },
      {
        "key": "invoiceCategory",
        "type": "RsDropdown",
        "props": {
          "label": {
            "value": "Invoice Category:"
          },
          "data": {
            "value": [
              {
                "value": "Travel Expenses",
                "label": "Travel Expenses"
              },
              {
                "value": "Business Meals",
                "label": "Business Meals"
              },
              {
                "value": "Other",
                "label": "Other"
              }
            ]
          },
          "value": {
            "value": ""
          }
        }
      },
      {
        "key": "invoiceNumber",
        "type": "RsInput",
        "props": {
          "placeholder": {
            "value": "e.g. \\"I-12345\\""
          },
          "label": {
            "value": "Invoice Number:"
          }
        }
      }
    ]
  },
  "localization": {},
  "languages": [
    {
      "code": "en",
      "dialect": "US",
      "name": "English",
      "description": "American English",
      "bidi": "ltr"
    }
  ],
  "defaultLanguage": "en-US"
}`

    const viewerContainer = document.getElementById(elementId);
    const formRef = renderFormEngineForm(form, viewerContainer);

    camForm.on('submit', () => {
      onSubmit(camForm, formRef)
    });
  }
</script>

<form class='form-horizontal'>
  <div id="formViewerContainer"></div>

  <script cam-script type='text/form-script'>
    renderCamundaForm('formViewerContainer', camForm);
  </script>
</form>

task-form.html

Click to view task-form

title="task-form.html" {2,18,20,51,150-168,173,194}



<script>
  function renderFormEngineForm(form, container, additionalProps) {
    const viewerRef = {current: null}
    const viewerBundle = window.FormEngineViewerBundle;
    const components = viewerBundle.rSuiteComponents;
    const view = components.view
      .withViewerWrapper(components.RsLocalizationWrapper);
    const props = {
      getForm: () => form,
      view,
      viewerRef,
      ...additionalProps
    }
    viewerBundle.renderFormViewerTo(container, props);
    return viewerRef;
  }

  function renderCamundaForm(elementId, camForm, scope) {
    const camVars = camForm.variableManager.variables;
    const invoiceUrl = camVars.invoiceDocument.contentUrl;

    const form = `{
  "version": "1",
  "form": {
    "key": "Screen",
    "type": "Screen",
    "props": {},
    "children": [
      {
        "key": "RsContainer 1",
        "type": "RsContainer",
        "props": {},
        "children": [
          {
            "key": "RsLabel 1",
            "type": "RsLabel",
            "props": {
              "text": {
                "value": "Download Invoice:"
              }
            }
          },
          {
            "key": "invoiceDocument",
            "type": "RsLink",
            "props": {
              "text": {
                "value": "invoice.pdf"
              },
              "href": {
                "value": "${invoiceUrl}"
              }
            }
          }
        ]
      },
      {
        "key": "amount",
        "type": "RsNumberFormat",
        "props": {
          "label": {
            "value": "Amount:"
          },
          "placeholder": {
            "value": ""
          },
          "allowNegative": {
            "value": false
          },
          "readOnly": {
            "value": false
          },
          "disabled": {
            "value": true
          }
        }
      },
      {
        "key": "creditor",
        "type": "RsInput",
        "props": {
          "label": {
            "value": "Creditor:"
          },
          "placeholder": {
            "value": ""
          },
          "size": {
            "value": "md"
          },
          "disabled": {
            "value": true
          }
        }
      },
      {
        "key": "category",
        "type": "RsInput",
        "props": {
          "label": {
            "value": "Invoice Category:"
          },
          "disabled": {
            "value": true
          }
        }
      },
      {
        "key": "invoiceID",
        "type": "RsInput",
        "props": {
          "placeholder": {
            "value": ""
          },
          "label": {
            "value": "Invoice Number:"
          },
          "disabled": {
            "value": true
          }
        }
      },
      {
        "key": "approve",
        "type": "RsCheckbox",
        "props": {
          "children": {
            "value": "I approve this Invoice"
          },
          "checked": {
            "value": false
          }
        }
      }
    ]
  },
  "localization": {},
  "languages": [
    {
      "code": "en",
      "dialect": "US",
      "name": "English",
      "description": "American English",
      "bidi": "ltr"
    }
  ],
  "defaultLanguage": "en-US"
}`

    const additionalProps = {
      initialData: {
        amount: camVars.amount.value,
        creditor: camVars.creditor.value,
        invoiceID: camVars.invoiceID.value,
        approved: camVars.approved.value,
        category: camVars.category.value
      },
      onFormDataChange: ({data, errors}) => {
        camForm.variableManager.variableValue('approved', data.approve);
        if (data.approve !== camVars.approved.value) {
          // Activate 'save' button
          scope.$$camForm.$dirty = true;
        }
      }
    }

    const viewerContainer = document.getElementById(elementId);
    renderFormEngineForm(form, viewerContainer, additionalProps);
  }
</script>

<form class='form-horizontal'>
  <div id='formViewerContainer'/>

  <script cam-script type='text/form-script'>

    // Fetch Variables and create new ones
    camForm.on('form-loaded', function () {
      camForm.variableManager.createVariable({
        'name': 'approved',
        'type': 'Boolean',
        'value': false,
        isDirty: true
      });

      camForm.variableManager.fetchVariable('amount');
      camForm.variableManager.fetchVariable('creditor');
      camForm.variableManager.fetchVariable('invoiceID');
      camForm.variableManager.fetchVariable('invoiceDocument');
      camForm.variableManager.fetchVariable('category');
    });

    camForm.on('variables-applied', function () {
      renderCamundaForm('formViewerContainer', camForm, $scope);
    });
  </script>
</form>

The JSON for the form and the basic code for rendering the form are included in HTML files for this example. In practice, it's likely
better to use a separate JavaScript module.

Running FormEngine Forms in Camunda

Deploy the FormEngine Forms:

Open Camunda Modeler and click the rocket icon button.
Delete the selected forms start-form.html and task-form.html.
Add the forms created for FormEngine.
Click the Deploy button.

Open the Camunda Tasklist Web Interface:

Navigate to http://localhost:8080/camunda/app/tasklist/ and refresh the page.

Start the Process:

Click on the “Start Process” button on the top panel.
Select "React example" in the "Start process" window. You should see the form made with FormEngine.

Fill Out the Form and Start the Process:

Fill out the form and click the Start button.
The process has started. Now click on "All Tasks" on the left panel.

Select and Claim the Task:

Select the created task from the top.

Claim the task by clicking on the "Claim" link. The link text will change to "Demo Demo".

Verify Task Variables and Fill Out the Form:

You should see that the variables have been populated. Click on the link next to the highlighted text "React Example".

The form should be correctly filled out.
Fill out the form and click Complete.

That's it! Your FormEngine forms are now running in Camunda.

Conclusion

In this article, we have successfully connected FormEngine as a form rendering engine for Camunda. This allows you to use your custom
components to render forms by passing a set of your components through properties.

Your feedback is very important to us
It helps us understand whether this guide was useful to you, how clearly it was written, and what else you would like to learn about. Please ask your questions in the comments or start discussions on GitHub.

Optimajet Data Engine 1.0.0: Open Source Workflow Engine Component alpha release

Optimajet Limited — Tue, 28 May 2024 15:48:11 +0000

Optimajet Data Engine 1.0.0: Open Source Workflow Engine Component is a .NET ORM framework developed for implementing providers in the Workflow Engine. This project is currently in the alpha release stage.

The primary goal of DataEngine is to generate queries to various databases through a unified interface and automatically map this data to entities.

Contains Breaking Changes

Reworked the process of passing settings to providers' implementations.
Added the method IProvider.UseOptions to create a local context with settings.
Added the ability to specify the database schema. Note that this is not supported by all databases.
Introduced splitting large queries in InsertAll and SelectByKeys into subqueries to avoid parameter overflow errors.
Reworked the addition of TypeHandlers in SQL providers. This mechanism is now more reliable and understandable, and it also supports detecting vanilla Dapper in the project.
Updated SqlKata to version 1.0.0.

GitHub Open Source code