Hi Henrick,
The problem you are running into with delegates is that once you start a new thread, you lose the current BPM Engine context. The Mstm object, ProcessContext object and "YourProcess" object all rely on that current BPM Engine context to figure out what you are allowed to do. Among other things, this context tells the engine who you are and what the current Folder ID is. If you try to use any of these objects in the new thread, you're likely getting null exceptions on the object.
You still however, have access to the compiled MBO types in the new thread, so you can explicitly pass in any business object that you may need in the new thread as an argument and have nice access to Intellisense. I haven't figured out how to keep access to the MSTM object though, so as long as you resist the temptation to use the Mstm object, you can execute your long running scripts asynchronously with read only access to all your ProcessContext and "YourProcess" objects.
The decision to use async processing shouldn’t be taken lightly... you can really hose your engine if you spawn too many threads or don't handle exceptions properly, but when you want to keep your UI responsive or you want to run expensive scripts, it’s a very powerful tool at your disposal. Async processing should not be used where anything on the current UI is reliant on the results on the Async work. In this case, you would want the thread blocked to ensure everything happens in time and in order.
The basic idea for async work is as follows:
using System;
using System.Data;
using System.Collections.Generic;
using Metastorm.Ide.Extensibility;
using Metastorm.Runtime.Core;
using Metastorm.Runtime.Types;
using System.ComponentModel;
using System.Threading;
namespace Metastorm.Runtime.Models.AsyncWorkerProj
{
public class WorkDelegate
{
public void CreateNewThread()
{
// Spawn a new thread to do concurrent/parallel work.
// This will not wait for a response, so the UI will be unblocked.
// You will have no access to the current BPMEngine's thread so you must
// pass in desired business objects to the new thread as arguments
ProcessContext pc = new ProcessContext();
AsyncWorkerProc pd = new AsyncWorkerProc();
Thread t = new Thread(() => DoAsyncWork(pc, pd));
t.Start();
}
private void DoAsyncWork(ProcessContext pc, AsyncWorkerProc pd) {
// You do not have access to the current BPMEngine Session here (No Mstm!!)
try
{
// Do thread work here
Thread.Sleep(30000);
System.IO.File.WriteAllText(@"C:\Log.txt", pd.AsyncWorkerProcData.MyCustomVariable);
}
catch(Exception ex)
{
// Handle thread exceptions - DO NOT THROW
System.IO.File.WriteAllText(@"C:\Log.txt", ex.ToString());
}
finally
{
// Do thread cleanup
}
}
}
public class WorkThread
{
public static void DoWork()
{
WorkDelegate d = new WorkDelegate();
d.CreateNewThread();
}
}
}Now in your solution you can do the async work anytime by calling WorkThread.DoWork().
Async models usually include the concept of a callback method that you can pass in to alert the UI thread that the async work has been completed. Because of the way the engine handles the current BPM context, the UI thread is already gone (the user is not even guaranteed to be logged in by the time the long-running script finishes), but we can alert the PROCESS that the async work is finished via a flag. We can’t raise this flag with Mstm object so instead you can either shell to the eRaiseFlag.exe utility or Process.Start() in the finally{} block to alert the PROCESS that the work is done.
See the attached solution.
