Skelta Workflow.NET 2004 R2 incorporates several new features that improve performance and enhance usability.
1. New Resource Action - Work Action
The key new feature in the new release is the new Resource Action – the Work Action. The Work action is one of the most powerful actions available in Skelta Workflow.NET. Work action can be used to build different views for an action based on the participants. The UI to configure the Work action properties can be displayed in either a Role Based View or a General View. This reduces much of the need for creating custom actions. In General View the Activity View for the action is common for all the users. In Role Based view each participant will have a unique activity view based on the role filter and configuration.
To enable Role Based UI in the Activity List it is mandatory to set either of these Activity Control properties - LoggedInUserIDInteger or LoggedInUserIDString.
See Using Work Action and Work Action for more details. You can also see under the [Skelta Installation Folder]\Workflow.NET\Doc folder for the Skelta Workflow.NET 2004 Work Action Description.pdf for a detailed description of the action.
2. New Resource Action - Choice Action
The second Resource Action is the Choice Action. The Choice action allows more than one submit button to be configured. For example, you can have three action outputs like "Approve", "Reject" and "Send Back", which will be displayed as submit buttons using this action.
See Choice Action for more details.
3. New Engine Actions
There are two new Engine Actions – CustomTimerSet and CustomTimerController – in the new Release. The CustomTimerSet action allows a controllable schedule to be set in the workflow for other actions. The CustomTimerController can be used to control this schedule. The control outputs for this action are "Pause", "Resume" and "Stop", which will determine the course of the workflow execution.
See CustomTimerSet Action and CustomTimerController Action for more details.
4. GroupActionUI
This new feature renders action specific UI for users to simultaneously act upon multiple activities. A new web server control – "GroupActionUI" – can be used to display the multiple-selection option for the activity list. GroupActionUI can be loaded through the Activity control by enabling the property EnableGroupUI and setting the GroupByActionType properties. The property GroupByActionType is mandatory for the control.
See Using GroupActionUI for more details.
5. Xcopy deployment of dlls
This new feature allows dlls to be replaced directly by ensuring that they are not locked by processes.
See Enabling Xcopy Deployment for more details.
6. Class implementing IDBConnectionString Interface
This interface can be used to secure the connection string configuration in Workflow.NET configfile <datasource type="sql server" class="" assembly="" param= ""><%CustomData%></datasource>. Custom data can be passed to the interface method by setting the inner text for the datasource node.
Using this the connection strings can be moved from the configuration file to dll in order to enhance security.
See Sample Implementation of IDBConnectionString Interface for details of methods used.
7. Interface for maintaining status at application level
The new Release has an Interface that can be used to maintain activity level information within the application. Examples of activity level information could be when an activity is added to a user, when it is updated by the user, when it is forwarded by the user, etc. All these methods are executed in the transaction mode.
The following node has to be set in the WorkflowNET.config file <activitymap class="" assembly="" param= "" />.
Workflow level data can be passed to the class through interface property parameter by configuring the node <activitymapparams>SomeData</activitymapparams> under workflow tag.
This can be used to maintain activity level information within the application. For example, when activity is added to user, updated by user, forwarded by user etc.
See Sample Implementation of Interface for maintaining status at application level for details of methods used.
8. Interface for getting Action/Workflow status change information from Engine
The engine will alert a new interface on changes in the status of Actions or Workflows. There is an optional Application level tag added in the WorkflowNET.config file named "workflowinformation". This tag will be used to map the IWorkflowInformation interface implemented class. The class implementing the Workflow.NET.Interfaces.IWorkflowInformation in Workflow.NET.dll interface is used to get the information from the Engine on change in the status of Action/Workflow. This is just for information purpose. It does not involve any transaction.
The workflowinformation tag is to be configured in the configuration file as <workflowinformation class="" assembly="" param="" />
Note: This Interface cannot be used to get Workflow Execution Pending status.
See Sample Implementation of Interface for getting Action/Workflow status change information for details of methods used.
9. Class implementing IValidateWFRequest Interface
This interface can be used to validate the client request to the engine (The API used is Client.Execute). Skelta ships two default validation controls: Workflow.NET.ValidateHttpClientRequest and Workflow.NET.ValidateEncryptedClientRequest. These controls can be configured to validate the web application request against the application configured in WorkflowNET.config file.
Workflow.NET.ValidateHttpClientRequest:
This control has to configured to validate client request based on HttpRequest.
The <clientrequestvalidator class="Workflow.NET.ValidateHttpClientRequest.ValidateHttpClient" assembly="Bin\Workflow.NET.ValidateHttpClientRequest.dll" param=""/> node has to be configured under the application. Application level security can be set by setting the web application name using the param attribute. Workflow level security can be set by setting the web application name using the <clientrequestparams>ApplicationName</clientrequestparams> node under workflow. Multiple application names can be set using the ',' seperator.
The client.execute will look like this:
int executionId= 0;
Workflow.NET.Engine.Client client = new Workflow.NET.Engine.Client("Default","Default");
client.RegisterForSecureClientRequest(this.Context.Request);
executionId = client.Execute(1,"<data></data>");
client.Close();
Workflow.NET.ValidateEncryptedClientRequest:
This control has to configured to validate client request based on encryption.
Use the tool GetEncryptedString.exe, available in the "bin" folder under the Skelta installation folder, to generate the encrypted string. The <clientrequestvalidator class="Workflow.NET.ValidateHttpClientRequest.ValidateEncryptedClient" assembly="Bin\Workflow.NET.ValidateEncryptedClientRequest.dll" param=""/> node has to be configured under the application. Application level security can be set by creating the encrypted string using the application name and setting the same using the param attribute. Workflow level security can be set by by creating the encrypted string using application name and workflow name and setting the same using the <clientrequestparams>ApplicationName</clientrequestparams> node under workflow.
The client.execute will look like this:
int executionId= 0;
Workflow.NET.Engine.Client client = new Workflow.NET.Engine.Client("Default","Default");
client.RegisterForSecureClientRequest(this.Context.Request);
executionId = client.Execute(1,"<data></data>");
client.Close();
See Sample Implementation of IValidateWFRequest Interface for details of methods used.
10. Redirect custom document view
In the new Release you can automatically post to another page if it is configured in the workflow configuration file. The configuration should be <documentwebviewcontrol class="Workflow.NET.RedirectCustomDocument.CustomDocument" assembly="Bin\Workflow.NET.RedirectCustomDocument.dll" param="" />
The page to which the custom document dlls post can be configured at design time. The property name is "Custom Document View URL". This property is available for all Resource actions. The data posted to the page are application, workflow, executionid, executiondetailsid, activityid. The posted data can be retrieved as Request.Form["activityid"]
11. New escalation level for all Resource actions
A new escalation level – Recurring Time Interval – can be set for all Resource actions using the property “Multiple Time Out Warning”. This can be used to set a different recurring time out after the first timeout happens. For example, if “Time Interval” for the same property is set as 7 days and “Recurring Time Interval” is set as 2 days. The first time out will happen after 7 days and there will be a recurring time out every 2nd day after the 7th day (first) time out.
12. Support for relative paths
This new feature allows relative paths to be specified instead of absolute paths. Relative paths can be specified for configuration files as well as workflow elements. Example:
Previously, paths had to be specified like this - <documentwebviewcontrol class="Workflow.NET.RedirectCustomDocument.CustomDocument" assembly="C:\Program Files\Skelta\Workflow.NET\Bin\Workflow.NET.RedirectCustomDocument.dll" param="" />.
With the new release, paths can be specified like this - <documentwebviewcontrol class="Workflow.NET.RedirectCustomDocument.CustomDocument" assembly="Bin\Workflow.NET.RedirectCustomDocument.dll" param="" />
13. Process Designer properties
The new release also adds the following properties to the Process Designer control:
14. Notification Emails in HTML format
There is an option to send notification emails in Resource actions in HTML format.
15. Action Display Name property for Resource actions
There is an option to set the display name for an action using the action property "Action Display Name". This display name will be shown in the Activity List as Action Required instead of the default behavior which showed the action type. This is a new property set for all resource actions.
16. Configuration at workflow engine level to validate the clients executing workflows
The new Release allows configuration to be done at the workflow engine level to validate the clients' executing workflows.
<validclientiplist>192.168.1.173</validclientiplist> has to be configured under the workflowengine tag in WorkflowNET.Config file. Multiple IPs must be separated by ';'.
17. Controlling Actions:
Two new APIs have been added for controlling actions.
A few scenarios showing how workflow status gets changed using the above APIs are given below:
18. Resuming Workflows executed with errors:
ResumeWorkflowWithErrors API (Workflow.NET.Engine.Client class) to resume workflow with errors. Now, the action which caused the workflow to fail will be re-executed.
19. Process Designer:
The Process Designer in the new release has the following new features:
20. Global variable introduced for Approval action:
Global variables have been introduced for the Approval action.
"^"+ CurrentAction.Name +"ApprovingUsers"
"^"+ CurrentAction.Name +"RejectingUsers"
"^"+ CurrentAction.Name +"ActingUsers"
These variables should be of type array. The userid's of the resources taking part in the action, approving the action, or rejecting the action will get stored in these variables.
This type of variable can be used in the next action as shown in this example – Userid in [Variable."^"+ CurrentAction.Name +"ApprovingUsers"]
21. Global variable introduced for Resource actions:
Global variables have been introduced for Resource actions.
"^"+ CurrentAction.Name +"ActingUsers"
These variables should be of type array. The userid's of the resources taking part in the action will get stored in this variable.
This type of variable can be used in the next action as shown in this example – Userid in [Variable."^"+ CurrentAction.Name +"ActingUsers"].
22. Activity Control:
<%#ActivityResourceIdentifier%>Placeholders used for getting details of the logged in resources for the activity (based on the property "LoggedInUserID" in ActivityControl.):
<%#ActivityResourceName%>
<%#ActivityResourceEmail%>
<%#ActivityLoggedInResourceIdentifier%>
<%#ActivityLoggedInResourceName%>
<%#ActivityLoggedInResourceEmail%>
23. Properties in Actions.xml:
Attributes have been added to 'hide the property' and
to 'set the property as mandatory' for an action.
Example, <property name="Subject" type="workflowmemo" helpstring="Subject of
the Information” mandatory="true" hideproperty="true"></property>
These attributes are supported by commonly used properties like string,
workflowmemo, resource, limit, email, activitycustomfield, etc.
24. Logger:
The following new debug level has been added.
All error messages logged in the logger console will be sent to the user set in the SMTP node – <smtp host="192.168.1.25" exceptionfromemail="admin@domain.com" exceptiontoemail=""/>
25. Workflow.NET.Engine.ActivityContext:
The following new APIs have been added.
26. Workflow.NET.Config class:
An API has been added to get workflow names for an application. (GetWorkFlowNames method)
27. Workflow.NET.Web.Report:
28. Workflow Action:
Child workflow execution id can be accessed in the
parent workflow using the variable "ChildWFExecutionId"+Worflow action name.
The parent workflow details can be accessed in the child workflow using the
variables. These variables will be accessible in the child only if either of
the properties – “Control child workflow?" or “Wait for the child workflow?” –
is set as “True”.
"ParentWorkflowExecutionDetailsId"
"ParentWorkflowExecutionId"
"ParentWorkflowApplication"
29. "Code Samples Using Skelta Workflow.NET 2004 APIs v1.1.PDF" document along with the installation:
This comprehensive document with several code samples covering a wide range of application scenarios is now provided as part of the Skelta Workflow.NET installation.
See under the [Skelta Installation Folder]\Workflow.NET\Doc folder for the Code Samples Using Skelta Workflow.NET 2004 APIs v1.1.pdf.
30. Workflow.NET.Config.xml:
A new attribute "alertsubmittedby" has been added for the node <exceptionemail> to send the exception email to the "submitted by" user if the initial workflow request fails.
31. New property in Report Control for forwarding tasks from the Report UI:
The Report Control has a new property (CanForwardActivity) that allows a users to forward the task to another user from the Report UI.
32. Application Level Code setting in Configuration file:
The Application tag provided in WorkflowNET.config file has a new attribute named "ownerapplicationcode". This attribute can be used to map the Application tag provided in the workflow configuration file to a web application code. This attribute can be accessed using the API Config.OwnerApplicationCode.
Using the owner application code attribute, application level identification can be set, which can be used within Skelta Workflow.NET.