Workflow Applications
Application types
The following application types are covered in this section:
Web procedures
Asynchronous web procedures
The following application types are not covered in this section:
Incoming webhooks
Non-interactive clients
SOAP web services
WCF services
Web applications
How it works
When an action using a workflow application is launched, WorkflowGen sends the parameters in a JSON or XML file (depending on the context format previously chosen during the creation of the application) to the application using the HTTP protocol. The application uses the JSON or XML file to get the parameters and executes its operations.
Once the application is done, a JSON or XML file with the OUT parameters is sent back to WorkflowGen. JSON is supported by Webproc and Webproc Async applications. For web services, the SOAP protocol is used to communicate with the application. Web services that don’t use the SOAP protocol to communicate with WorkflowGen application will be referred as Webproc applications.
Note: The JSON context is supported as of WorkflowGen version 7.0.0.
Requirements for .NET development
.NET Framework version
The WorkflowGen.My assembly requires .NET Framework 4.
WorkflowGen.My assembly
In order to implement a custom workflow application using the .NET Framework, you must have the latest version of WorkflowGen.My 4.x referenced in your project. To directly reference an assembly in your web project, do the following:
Create a
\bin
directory under your project root folder (e.g.\wfgen\wfapps\sdk\MyProject\bin
).Copy the
WorkflowGen.My.dl
l file to this folder.Right-click on your project name and choose Add reference...
Click Browse.
Navigate to the
\bin
directory you created and choose theWorkflowGen.My.dll
file, then click OK. WorkflowGen.My is now referenced in your project.
You can also put this assembly in your GAC (Global Assembly Cache) in order to have only one centralized reference, instead of referring to a copy of the assembly in each project. To install the assembly in your GAC, do the following:
Copy
WorkflowGen.My.dll
toDRIVE:\Windows\system32
.Open a command prompt and browse to
DRIVE:\Program Files (x86)\Microsoft Visual Studio 14.0\SDK\v3.5\Bin
.Enter the command
gacutil /i c:\windows\system32\WorkflowGen.My.dll
, then pressENTER
. WorkflowGen.My is now in your GAC.
If you want to use an assembly from the GAC, you should drop your assemblies into a local folder, and then add a reference to the assembly from this folder. You may want to set the Copy Local
property to False
for that assembly if you don't want the assembly to be copied locally to your project folders. At runtime, the application will automatically use the assembly from the GAC.
Important: WorkflowGen.My.dll
3.4.0 and later requires Newtonsoft.Json.dll
in the same BIN or GAC.
Configuration settings (app.config
or web.config
)
app.config
or web.config
)The WorkflowGen.My assembly does not require any particular configuration settings.
Deploying a custom assembly
There are some considerations when deploying a custom assembly SDK workflow application in WorkflowGen, namely the assembly location, the reference to WorkflowGen.My, and references to other software libraries.
Assembly location
There are two ways of deploying an assembly file in WorkflowGen.
Method 1: Reference by assembly’s full name
The assembly file must be copied to the three bin folders containing the WorkflowGen executable files: \wfgen\bin
, \wfgen\ws\bin
, and DRIVE:\Program Files\Advantys\WorkflowGen\Services\bin
.
Method 2: Reference by assembly’s path (full physical path with file name)
The assembly file can be copied to a custom folder such as DRIVE:\MyWorkflowApps\Assembly.dll
, and then use that specific path in the workflow application’s definition.
Important: If your custom assembly has dependencies, they must be located in the same folder as the assembly.
Reference to WorkflowGen.My
WorkflowGen.My v3.1.0 and earlier
WorkflowGen.My versions 3.1.0 and earlier are strong-named, which means your assembly must be built with and use the same version as your target WorkflowGen. This requires recompiling your assembly whenever you upgrade WorkflowGen to a newer version.
You can use one of the following workarounds to overcome this requirement:
Install the required WorkflowGen.My version in the system's global assembly cache (GAC). For instructions on how to do this, see the How to: Install an assembly into the global assembly cache Microsoft article. OR
Add a delegate to handle the assembly resolve event in order to load the current WorkflowGen.My version. For instructions on how to do this, see the How to add an assembly resolve event delegate to overcome WorkflowGen.My dependency issue when deploying custom assembly SDK workflow application article on the WorkflowGen Forum & Knowledge Base. OR
Add a web configuration setting to redirect the required version to the current version of WorkflowGen.My. For more information, see the <assemblyBinding> Element for <runtime> Microsoft article.
Note: If your assembly is built with WorkflowGen.My v3.1.0 or earlier, it can be used in WorkflowGen version 6.2.0 and later if one of the above workarounds has been implemented.
WorkflowGen.My v3.2.0 and later
As of version 3.2.0, WorkflowGen.My is no longer strong-named in order to allow non-specific version dependency when referenced by your assembly. You can simply deploy your assembly file using one of the two methods in the Assembly location section above in WorkflowGen 6.2.0 and later.
Note: If your assembly is built with WorkflowGen.My v3.2.0 or later, it can be used in WorkflowGen versions prior to 6.2.0 if you have implemented either workaround 2 or 3 above.
References to other software libraries
If your assembly uses third-party libraries, then these must also be deployed into the three WorkflowGen executable \bin
folders. Alternatively, they can be installed into the system’s global assembly cache (GAC) if they are strong-named assemblies.
WorkflowContext
WorkflowContext is a JSON or XML data structure used to exchange parameters with WorkflowGen. The context format is used by both web procedures and asynchronous web procedures.
Note: The WorkflowGen JSON and DataSet contexts exchange DateTime parameters with external applications in the UTC time zone according to the ISO 8601 format (see https://en.wikipedia.org/wiki/ISO_8601 for more information).
For an example of an XML ADO.NET DataSet context, see WorkflowContext in the Web services API section.
As of WorkflowGen 7.0.0, the application can build ContextParameters
instances from JSON strings. The JSON should respect the following structures:
JSON example (web procedure)
JSON example (asynchronous web procedure)
Note: JSON context properties are case sensitive; as of WorkflowGen 7.1.0, they use lowercase camelcase notation, and their null
values have been removed from the JSON context.
WorkflowContext creation with WorkflowGen.My
Loading the WorkflowGen context
In order to manipulate a WorkflowGen context, it is necessary to load it into a ContextParametersobject
instance. Usually, you will receive the context in a string variable. The following sample code loads the context from a workflowGenContext
string:
Get a particular parameter from the context
You can access any data parameter in the WorkflowGen context by using the contextHandler
(ContextParameters
instance) that you created in the previous section. When you access a single parameter, you store it in a ContextParameter
object to manipulate it. The following example accesses a DATE_EXAMPLE
parameter in the previously loaded context:
Get the ContextParameter
value
ContextParameter
valueTo access the value of the context parameter, use the Value
property of the ContextParameter
instance that you retrieved in the previous section:
The dateValue
variable now contains the DATE_EXAMPLE
parameter value.
Filtering the ContextParameters
collection
ContextParameters
collectionSuppose that you would like to iterate over all the IN parameters of the ContextParameters
instance. You could do this by using a filter and then using the collection enumerator. Don't forget to remove the filter afterward, or else you won't be able to access the other parameters.
Modifying a parameter value in the context
After you have stored your data parameter in a ContextParameter
, you can modify its value:
Note: If you try to modify a parameter with the wrong data type, you will only receive an exception when you try to serialize the context back to a JSON or XML string.
Adding a parameter to the context
In order to add a parameter to the context, you need to build a new ContextParameter
instance, define its name and direction, and then add it to the ContextParameters
instance you already have:
Working with file parameters
File parameters need to be put into a ContextFileReference
instance. The following is an example that extracts a file parameter value into a ContextFileReference
, then modifies the file parameter so that it points to another sample file.
As of WorkflowGen 7.1.0, JSON context file parameters use the file URI scheme in the fileValue
URL field (see https://en.wikipedia.org/wiki/File_URI_scheme for more information).
Web procedure development using an ASP.NET XML web service
Overview
The most widely-used type of WorkflowGen integration is the web procedure. Web procedures are used to receive a WorkflowGen context as a parameter, manipulate it, and then return the modified context to WorkflowGen.
Note: As of WorkflowGen 7.0.0, the term "web services" is only used to refer to web services using the SOAP protocol; all others are referred to as web procedures.
Creating the web procedure
Visual Studio Standard or Professional 2013 or later is suggested for development.
Web procedure installation directory
We strongly suggest that you put all of your web services in the \wfgen\wfapps\WebServices\MyWebProc
folder.
Be aware that if you modify your WorkflowGen process and you need to modify the associated MyWebProc
because of those changes, you should duplicate MyWebProc
beforehand and create another IIS application, otherwise the two versions of the process will use the same modified MyWebProc
.
Creating the application in IIS
The web service directory must be declared as an application in IIS in order to be recognized as a .NET web service application. To declare your web service directory as an IIS application, do the following:
For IIS 7 and later
Open Internet Information Services (IIS) Manager.
Navigate to your web form location, which should be under the Default Web Site node, under
\wfgen\wfapps\webservices\MyWebProc
.Right-click on MyWebProc and choose Convert to Application.
Select the application pool used by your site and another specific application pool.
Click OK.
Creating a web procedure workflow application using an ASP.NET XML web service
You can create a web procedure using an ASP.NET web service, but this Visual Studio template is only available for .NET versions 2.0 to 3.5.
Open Visual Studio.
Select File > New Web Site.
Choose ASP.NET Web Service (available for .NET Framework versions 2.0 to 3.5).
Choose File system from the Location drop-down list.
Click Browse and choose the location of your ASP.NET website.
Click OK.
Obtaining detailed error messages
In order to be able to see complete error messages, change the following properties in the web.config
file:
Make sure this line is set to true
:
Make sure this is not commented and that the mode="Off"
:
Authorize GET and POST protocols
In order to use a web service with WorkflowGen, the GET and POST protocols must be enabled in the web service's web.config
file. The following are the necessary nodes to insert in the system.web
node of your web.config
file:
Configuring the IIS rendering framework version in the web.config
file
web.config
fileYou will need to revert to the behavior of having only .aspx
pages trigger request validation by adding the following code to your web.config
file:
Basic implementation
Overview
In order to demonstrate how to implement a web procedure that processes a context from WorkflowGen, we'll build a simple web service that receives and returns TEXT, NUMERIC, FILE, and DATETIME parameters using the JSON and XML ADO.NET DataSet context formats and their respective content types.
Reference
You must add a reference to WorkflowGen.My.dll
in your web project, and then add a using
statement (for the WorkflowGen.My.Data
namespace of the WorkflowGen.My assembly. For example:
Specifying your class signature
If you want to receive a JSON formatted context, you should add the following signature, located in the App_Code\Service.cs
file, to your web procedure's Service
class (note that ScriptService
signatures aren't required for other context formats). Your service class should look like this:
Specifying your web method signature
Only the methods that have the WebMethod
attribute can be remotely executed. The default web method signature created with your web service should look like this:
Here, we'll modify the web method signature. If JSON is the chosen context format with application/json
content type, or if the context format is XML ADO.NET DataSet with application/xml
content type, the web method will not receive any parameter. Otherwise, if you exchange a JSON or ADO.NET DataSet context using the application/x-www-form-urlencoded
content type, your method must receive a string parameter called WFGEN_CONTEXT
.
JSON (application/json
) and XML ADO.NET DataSet (application/xml
) context formats
application/json
) and XML ADO.NET DataSet (application/xml
) context formatsJSON and XML ADO.NET DataSet context formats using application/x-www-form-urlencoded
content type
application/x-www-form-urlencoded
content typeNote: The parameter name should always be WFGEN_CONTEXT
, which is case sensitive.
Loading the WorkflowGen context
The next step is to retrieve the WorkflowGen context. In the case of JSON or XML ADO.NET DataSet contexts (when using application/json
or application/xml
, respectively), the context is retrieved from the HttpContext
request as shown in the following example:
Otherwise, if the web method has received the WFGEN_CONTEXT
in parameters (this is the case for JSON and XML ADO.NET DataSet contexts when using the application/x-www-form-urlencoded
content type), it is available to be used within the method.
Now, we're ready to create a ContextParameters
instance that will be used to manipulate the WorkflowGen context:
Retrieving the parameters from the context
We'll now retrieve the NUMERIC_IN
value into our numericIn
double variable, and at the same time, we'll verify that the value is not null (if it is, we'll send an exception):
Modifying the parameters with new values
We'll now modify some parameters by giving them new values:
Sending the modified context back to WorkflowGen
Now that we've processed the context, we need to send the context back to WorkflowGen. Below is the necessary code, depending on the context format you chose when creating or editing your WorkflowGen application.
JSON context using application/json
content type
application/json
content typeJSON context using application/x-www-form-urlencoded
content type
application/x-www-form-urlencoded
content typeXML ADO.NET DataSet using application/xml
content type
application/xml
content typeXML ADO.NET DataSet using application/x-www-form-urlencoded
content type
application/x-www-form-urlencoded
content typeAsynchronous web procedure development in .NET Framework
Overview
Asynchronous web procedures allow a WorkflowGen system action to be run asynchronously, meaning that the action is initiated at some point in time during the workflow and can be completed at a later instance by an external application.
This type of asynchronous processing can be used in cases where a system action (such a web service) can time out or cause the UI to hang when processing a large volume of information.
This section will explain how to develop an asynchronous web procedure application using WorkflowGen.My v4.0. The example will consist of two different parts: an ASP.NET XML web service that receives and processes the context, and cURL examples of HTTP POST requests (you can choose the appropriate technology to post these) needed to complete the action.
Creating the asynchronous web procedure
To create the ASP.NET XML web service, follow the steps in the previous section, Web procedure development using an ASP.NET XML web service:
Create the web procedure.
Create the application in IIS
Create a web procedure workflow application using an ASP.NET XML web service.
Configure the IIS rendering framework version in the
web.config
file.Specify your class signature steps.
Basic implementation
In order to demonstrate how to implement an asynchronous web procedure application, we have developed an ASP.NET XML web service that receives a context in JSON or XML ADO.NET DataSet formats, processes the context and updates it.
You must add a reference to WorkflowGen.My.dll
in your web project, then add a using
statement for the WorkflowGen.My.Data
namespace of the WorkflowGen.My assembly:
Only methods that have the WebMethod
attribute can be remotely executed. If the chosen context format is JSON with the application/json
content type, or if the context format is XML ADO.NET DataSet with application/xml
content type, the web method will not receive any parameters. Otherwise, if you exchange a JSON or ADO.NET DataSet using the application/x-www-form-urlencoded
content type, your method must receive a string parameter called WFGEN_CONTEXT
.
JSON (application/json
) and XML ADO.NET DataSet (application/xml
) context formats
application/json
) and XML ADO.NET DataSet (application/xml
) context formatsJSON and XML ADO.NET DataSet context formats using application/x-www-form-urlencoded
content type
application/x-www-form-urlencoded
content typeNote: The parameter name should always be WFGEN_CONTEXT
, which is case sensitive.
Loading the WorkflowGen context
Be aware that WorkflowGen will send the context to your external application formatted based on your chosen context format and context type when creating or editing your application in WorkflowGen application form.
For example, if you choose JSON context with the application/json
content type, your incoming payload will have the following structure:
For an example of an XML ADO.NET DataSet context, see WorkflowContext in the Web services API section.
The next thing to do is receive the WorkflowGen context. In the case of the JSON or XML ADO.NET DataSet contexts, when using application/json
and application/xml
respectively, the context is retrieved from the HttpContext
request:
Otherwise, if the web method has received the WFGEN_CONTEXT
in parameters (this is the case with the JSON and XML ADO.NET DataSet contexts when using the application/x-www-form-urlencoded
content type), it is available to be used within the method.
Now, we're ready to create a ContextParameters
instance that will be used to manipulate the WorkflowGen context.
Retrieving the parameters from the context
We'll now receive the NUMERIC_IN
value into our numericIn
double variable, and at the same time, we'll verify that the value is not null
; if it is, we'll send an exception:
Modifying the parameters with new values
Now, we'll modify some parameters by giving them new values:
Saving the context in a file
Since the asynchronous web procedure will complete the action afterwards, the context
and the replyToUrl
values should be stored. In this example, we'll use files for this purpose:
JSON context format
XML ADO.NET DataSet context format
After the ASP.NET XML web service used to launch the asynchronous web procedure has saved the context, we need to complete the action by sending it back to WorkflowGen. The following cURL examples provide all of the information required to post the context back to WorkflowGen using the information previously saved in the text files. There are many technologies and applications available to do this; for example, you can develop a .NET console application, or post your request using the Postman application. Be aware that the special character must be correctly escaped depending on your application of technology requirements.
JSON context using application/json
content type
application/json
content typeJSON context using application/x-www-form-urlencoded
content type
application/x-www-form-urlencoded
content typeXML ADO.NET DataSet context using application/x-www-form-urlencoded
content type
application/x-www-form-urlencoded
content typeXML ADO.NET DataSet context using application/xml; charset=UTF=8
content type
application/xml; charset=UTF=8
content typeLast updated