Management

Lifecycle

The Form Designer creates a web form (ASPX and code-behind) that's based mainly on both ASP.NET Framework and WorkflowGen.My libraries.

This gives you the advantage of many possibilities for customizing and integrating the web form to your specific needs, especially in an advanced and integrated development environment such as Visual Studio.

Example of the process lifecycle

• A first version is created, which is done quickly and easily using the built-in form designer. The end-users will then test the first version as proof of concept.

• Later, the process can be deployed for production if it meets the business's and end-users' expectations.

• If there are custom or advanced functionalities required in a new version that aren't available in the built-in form designer, then the process can be migrated to the web form development.

Migrating a process

In order to migrate a process with a built-in form to a process web form, follow these steps:

1. Create a new version of or duplicate the process.

2. Uncheck the Built-in form designer option in the New process information tab.

3. In Visual Studio, open the web form website with the folder path (\wfgen\wfapps\webforms[process name]\V[version number]) and start your development.

4. You can choose to leave your web form folder ([process name]\V[version number]) as a sub-folder within the web forms web application (\wfgen\wfapps\webforms) or transform this folder into a web application in IIS.

   • The former case will make your web form dependent and uses the web form's web application resources (e.g. \bin, \App_Data, \App_Resource, \App_Themes, etc.) as it did prior to migration.

   • The latter case will make your web form as an independent web application. In this case, you'll need to copy the web form's \bin sub-folder to your web form’s folder and refresh the opened project in Visual Studio, if needed.

Security

All connection strings in \wwwroot\wfgen\web.config are available for use in the Form Designer and Global Lists except for the master database connection string. While the application tries to verify that user-supplied SQL queries used in these contexts are secure and contain only SELECT statements, you should also make sure that exposed connection strings are secured at the database level. This means that if you don’t want a process manager or a Global List manager to be able to update or modify a certain database, the connection string should have read-only access to your database.

Keep in mind that process designers can also use any connection string that they have access to from the Form designer’s code-behind editor. If you want to restrict a Global List manager’s access to a connection string, while still allowing the process designer to use it, you should add the connection string to the web form application’s web.config (\wwwroot\wfgen\WfApps\WebForms\web.config).

Connection strings in web forms'web.config files are not exposed in the WorkflowGen UI, so for process designers to be able to use them, they must know the name of the connection string. This is also a convenient way to give different process managers access to specific connection strings.