Workflow Activities Migration Guide

Particularities

Due to the fact, the Workflows can be executed on another process (or even another computer) some standard Workflow Activities changed a little the default behavior, which in some cases need to be taken into consideration when moving execution of the Workflow to the Worker.

Workflow Studio

To be able to be executed on the Matrix42 Worker, the Activity has to be compatible with it, which means the Activity either has all the required modules for the execution deployed on the Matrix42 Worker process, or the Activity is able to delegate the execution back to the Application Server via a Web Service method call. To signal the System uses the Workflow Activity property PLSLBinaryComponentClassBase.WorkerCompatible to signal that the Workflow Activity can be executed on the Matrix42 Worker. 

In the Workflow Studio, the Activities that are compatible with Matrix42 Worker are highlighted as follows:

It provides better transparency to the Author and shows why the Workflow cannot be executed by the Matrix42 Worker.

Administration application

Incompatible Workflow Activities in the Administration application are marked as follows:

Using Data Layer operation in Activity

The Workflow Framework provides the approach for working with the Production database fro the Workflow Activities.  Depends on Matrix42 Worker installation case the module transforms the database request directly over the Data Layer (Matrix42 Workers installed in intranet) or triggers REST web service for data operation on the Application Server when the Worker installed on the internet (Cloud or Data Gateway ). Using this practice guarantees the best option is automatically picked depending on the deployment model.

The Workflow Engine infrastructure provides a few components that are dealing with the data and schema operation.  

The instances of these components are initialized on Workflow Engine start and could be received over the Dependency Injection mechanism

protected override void Execute(NativeActivityContext context)
{
    var executor = context.GetExtension<IExtensionExecutor>();
    var schemaReader = executor.Get<ISchemaReaderProvider>();
    var dataProvider = executor.Get<IDataReaderProvider>();
    var objectsData = dataProvider.GetDataList("SPSCommonClassBase", "[Expression-ObjectID] AS ObjectID, TypeID AS TypeID",
        string.Format("[Expression-ObjectID] IN ({0})", ids)
    );
}

Calling Web API methods from the Workflow Activity

If your Workflow Activity uses resources that are present only on the Application Server, then it needs to be reworked to use Web Services instead to guarantee the Activity is correctly executed regardless of Matrix42 Worker location it is running on. 

T Run<T>(Guid operationId, Argument[] arguments = null, object data = null, int? lcid = null);
JToken Run(Guid operationId, Argument[] arguments = null, object data = null, int? lcid = null);
void Call(Guid operationId, Argument[] arguments = null, object data = null);

using Matrix42.Http.Client.Contracts;

protected override void Execute(NativeActivityContext context)
{
    var executor = context.GetExtension<IExtensionExecutor>();
    var proxy = executor.Get<IProxyContainer>();
    IWebApiClient client = proxy.GetWebApiClient();
    client.Run(new Guid("c04a51a2-a720-c94c-e965-08d77a3ca264"), null, new
                    {
                        SequenceId = sequenceId,
                        InputFile = @"C:\Temp\data.xml"
                    });
}

Upload new assembly

Open Administration application → Services & Processes → Workflows → Manage Assemblies → Actions → Upload Assembly. Select the Assembly from the development machine and upload it to the Application Server, click to select the checkbox “Directly Publish Assemblies":

Set Workflow Activity compatible with Matrix42 Workers

Execute the SQL script on the SQL Server using the Technical Name of the Workflow Activity:

You need implicitly set in the Production database a flag ([PLSLBinaryComponentClassBase].[WorkerCompatible]) for each Workflow Activity which indicates the Activity is "compatible" with the Matrix42 Workers Engine. 

update PLSLBinaryComponentClassBase
SET WorkerCompatible = 1
From PLSLBinaryComponentClassBase B
    inner join PLSLComponentClassBase C On C.[Expression-ObjectID] = B.[Expression-ObjectID] AND
    C.Name = '<Name of Custom Activity>'

Now the Workflow Activity will be marked as Worker compatible. To check it, open the Workflow Activity preview page.

Run Workflow with Custom Activity on Matrix42 Worker

To validate the Workflow Activity is working correctly on Matrix42 Worker, you need to "Set Execution Engine" to Worker for one of the Workflows which uses the Activity.

Start Workflow execution and assure it finished successfully and the targeted Activity was executed. 

If Workflow is part of your Custom Package and could be installed on multiple environments then the package needs to be adjusted to include the information that the Workflow could be executed on Matrix42 Worker. For that the flag [PLSLXamlComponentClassBase].UseWorkflowWorker needs to be set.

Key learnings

• Use DataReader component instead of direct access to the database
• Call web services via IWebApiClient instead of using Service Locator and Web API Service Layer
• Move all business logic from Workflow Activities to REST Services
• Remember that Worker may run not only on App Server, so all resources used should be available on all Worker machines (relevant for PowerShell Activities that require some cmdlets, make sure these cmdlets are installed on every machine that has Worker installed OR mark the PowerShell Activity as to be executed on the Application Server only)