<img height="1" width="1" style="display:none;" alt="" src="https://dc.ads.linkedin.com/collect/?pid=287945&amp;fmt=gif">

FlowWright object model

Posted by FlowWright on Nov 10, 2019, 8:15:00 PM

Developers build most applications using a common design pattern.  That pattern can be object-based, object oriented, component-based, modular, etc...: some pattern exists.   FlowWright helps developers through use of 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 that are related in many ways to other objects.  The following diagram illustrates the object hierarchy and how objects are related:

FlowWright object model

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

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

The high level API is broken into parent and child objects,  where the child objects are internal and are retrieved using the parent objects.  A good example of this is the deWorkflowDefinition object which cannot be retrieved directly from the API or created:  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.

Topics: workflow solutions, business logic