API's are the primary way to access most applications. And as applications become increasingly feature-and-function-rich, their API can become more complex and impact performance.  Workflow applications evolved in this exact way:  when they were rudimentary then their APIs were small and there were few issues - but as features and functionality were added, API performance degraded noticeably. 

In order to counter typical complexity and performance degradation,  FlowWright introduced user and server sessions.  User sessions are handled at API and user interface level.  Server sessions are used by engines and worker processes.

Potential problem?  With some API constructors, it takes a database connection string and an external user name to execute, meaning that every constructor would have to look up a workflow user id for the external user.  You can add caching to speed up these processes, but some deadlock scenarios and other issues, such as duplicate users, will often still manifest. 

What's the solution? FlowWright minimizes the number of calls made to the database through the original constructor by  introducing new user and server session objects.  Using the normal constructor, once an API object is created, you can ask for the user session object and use it to create other API objects.  Here's an example of that:

deDesign oDesign = new deDesign("db connection string", "external user name");
deUserSession oUserSession = oDesign.getUserSession();

deRuntime oRuntime = new deRuntime(oUserSession);

It follows that once the user session is established, all other constructors will use this new user session object to construct.  The same principles apply to server processes:  once a server session object is created, it is used within the engines and worker processes.

User interfaces are smart enough to use these user sessions: once a user successfully logs into FlowWright, the web server session stores a FlowWright user session object, and this user session object is used for constructing FlowWright API objects while the user is logged in and using the FlowWright user interface.  Once the user logs off, the web server session is abandoned and the user session is destroyed at that point for application security reasons.

Use of the API approach, along with other innovative uses of the Microsoft technology stack, contribute to FlowWright being the fastest and most robust BPM/Workflow application available today.