FlowWright Object Model

Learn about the FlowWright Object Model

Last published at: July 29th, 2024

Developers build most applications using a common design pattern. That pattern can be object-based, object-oriented, component-based, modular, etc. Some patterns exist. FlowWright helps developers by using a layered approach where modules are separated into components, and components break down into objects using a full object-oriented design.

FlowWright's object model consists of several objects related in many ways to other objects.  The following diagram illustrates the object hierarchy and how objects are related:

 

As you can see from the above mind map, FlowWright has a large object model to support broad and intuitive functionality.  It offers a vast amount of functionality, which you can read about on the features page.

 

All FlowWright objects can be accessed using the FlowWright .Net API (and a REST API that leverages the .NET API). The API is divided into high- and low-level APIs. The high-level API gives access to the majority of these objects, and the low-level API is pertinent specifically to the engine and workflow model.

 

The high-level API is structured around parent and child objects  . Child objects, which are internal, can be retrieved using the parent objects.  For instance, the deWorkflowDefinition object cannot be directly retrieved from the API or created.  Instead, the parent object deDesign must be created first, and then deWorkflowDefinition can be retrieved using the deDesign parent object.

 

In contrast, the low-level API deals with the workflow engine and model.  FlowWright's engine can be run in 2 different modes: (1) background mode by default and (2) using the real-time mode, where a workflow can be executed in real-time in memory using the engine (similar to a workflow instance being executed in the background by the engine service.)

 

The low-level API also holds the workflow modeling API: using this low-level API, every part of a workflow definition/instance can be accessed. Even though workflow definitions and instances are described and stored as XML documents, the low-level object model gives you a nice object-oriented way to access the objects of the model.