The FlowWright high-level API is the main API for all FlowWright components, user interface, business logic, and engines and gives all access to functionality and objects within FlowWright.  The API is divided into parent/child objects as described below:

• FWProcessDesign - contains functionality for all design time objects, can create/get FWProcessDefinition objects
• FWProcessRuntime - contains functionality for all runtime objects, can get access to FWProcessInstance objects
• FWFormDesign - access to FWFormDefinitons
• FWFormRuntime - access to FWFormInstances
• FWBusinessIntelligence - access to BI functions

The diagram below illustrates the objects involved within the high-level API:

API is pretty large yet very simple to use.  The above diagram defines objects and their hierarchy.  Most objects use 2 standard constructors.  FlowWright constructors require a very minimum amount of information:

• connection string to the FlowWright database
• external user name

With these 2 pieces of information, any object within FlowWright can be created.  For example, to create the FWDesign object, the constructor looks as follows:

FWProcessDesign oDesign = new FWProcessDesign("DB connection string", "external user name");

Once the oDesign object is created, all design methods and functionality are available.  Objects such as deWorkflowDefintion are set to internal ONLY.  What that means is they are not creatable objects by outside applications.  These objects have to be retrieved using the parent objects of the API, so to get a FWProcessDefinition object, you would perform the following calls:

FWProcessDesign oDesign = new FWProcessDesign("db connection string", "external user name");
FWProcessDefintion oDef = oDesign.getDefinition("defintion id");

It's the same for the FWProcessInstance object; the FWProcessRuntime object must be used to retrieve the FWProcessInstance object.

What's the reason for this? Well, when you ask for an object such as the FWProcessDefinition from the FWProcessDesign object, we perform all the error checking and validation. If the workflow definition exists, then it's returned; otherwise, the API returns NULL.

The API is divided into many classes, which are mainly organized by design and runtime. Some are single-level classes that provide specific functionality through the API. The FlowWright knowledgebase contains many API code examples, as well as the Developers guide and the Getting Started with the API guide.