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

FlowWright, in a proactive move to counter typical complexity and performance degradation,  introduced user sessions.  These user sessions, handled at the API and user interface levels, stand as a testament to FlowWright's commitment to addressing potential issues before they become problems.  

Potential problem? 

Some API constructors execute using a database connection string and an external user name, 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 standard constructor, once an API object is created, you can ask for the user session object and use it to make other API objects.  Here's an example of that:

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

FWUserSession oUserSession = oDesign.GetUserSession();

FWProcessRuntime oRuntime = new FWProcessRuntime(oUserSession);

It follows that once the user session is established, all other constructors will use this new user session object to construct.  

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, which is used for constructing FlowWright API objects. In contrast, the user is logged in using the FlowWright user interface.  Once the user logs off, the web server session is abandoned, and the user session is destroyed for application security reasons.

The API approach and other innovative uses of the Microsoft technology stack contribute to FlowWright's being the fastest and most robust BPM/Workflow application available today.