So in v7.x .NET is available to your Metastorm BPM processes via server side scripting. You can use basic scripting on the server side, but not for use with the .NET framework. By using JScript.NET as your server side scripting language you have the .NET framework class library and your own custom types available to you, but let’s not forget the all important ework script object. This object allows you to access your process data from the server side.
When you create a server side script via designer, it is like creating a new class file in visual studio. The script can have full access to the .NET Framework Class Library and you may notice at the top of your script, like with your class files that the basic import System declaration has been made. Before I talk about the second imported namespace eWork.Engine.ScriptObject, I need to touch on references first.
In visual studio, if you are using assemblies that have been created by you or someone else or if you are using non core .NET framework assemblies, you have to create a reference in your project. This reference is essentially a link to the assembly so that you can access the types in that assembly. You would right-click the references folder in your project and then go find your assembly or COM component (VS will wrap it in a .NET callable wrapper for you). Once you select the assembly, it is copied locally to your project (if ‘Copy local’ set to true) so that when your project compiles it can use it after application deployment.
The same rule applies to using Metastorm BPM server side scripts. Instead of adding a reference to an assembly, you place the assembly that you need to reference in the Engine/dotnetbin folder of the Metastorm BPM program folder. Anything placed in here, the engine can see and so all you need to do is make sure you import the namespace required. This is where the eWork.Engine.ScriptObject comes in. If you go take a look in the dotnetbin just after installation of Metastorm BPM, you’ll see a collection of assemblies and eWork.Engine.ScriptObject.dll is one of them.
The namespace eWork.Engine.ScriptObject contains 13 types which you can use in your server side scripting. You may notice that when you first create a server side script, 2 methods are created for you, SyncSample and AsyncSample. The first parameter of each of these is an object called ework which is of type SyncProcessData or AsyncProcessData. Each of these are types found in the eWork.Engine.ScriptObject.dll.
So, we have an object in our methods available to us called ‘ework’. Now the first question is, what methods or properties does this handy ework object contain? – The server side script editor in v7 does not employ intellisense so typing ‘ework.’ is not going to help you much. One idea is to use visual studio’s object browser. If you create a new VS project, right click your references folder and then make your way over to Program Files/Metastorm BPM/Engine/dotnetbin and select the eWork.Engine.ScriptObject.dll file it will be added to your project references list. Right click this new reference and select ‘View in Object Browser’. You’ll now see the namespace and the 13 types I mentioned earlier in the object browser. Type members will be shown. Take a moment to instantiate the SyncProcessData type to have a look at its members that will available to you via the ‘ework’ object in the Designers script editor.
There’s a lot more to the ework object than you thought right? Most of the functions available via the Integration Wizard are there and because this is a .NET object, all of the standard object members are inherited (ToString() etc).
ps – When validating your server side scripts, Designer might throw up some errors to the effect that it can’t find a reference to your own .NET assemblies if being used. This is purely because the designer looks to its own Dotnetbin folder for references when validating your code and so any assemblies you wish the engine to work with should be placed in your local Designers Dotnetbin folder also (note, its a capital ‘D’ for the designer folder and a small ‘d’ for the engine folder).