Setting up a directory, processor and deploying a workflow

The default Flower package includes two directory implementations: in-memory and SQL Server. This section covers only the installation and setup of the in-memory implementation. To learn more about SQL Server directory, see "Setting up the SQL Server directory".

Components configuration

The common way to configure any component of Flower is to edit its configuration files in the Config directory of the installation package and then install the component.

A component may have the following configuration files:
  • <Component name>.exe.config - the standard application configuration file. Usually, you need to edit this file if you wish to change WCF configuration of the component.
  • <Component name>.config - the primary Spring.NET application container XML configuration. This configuration needs to be changed when you choose an alternative or custom implementation of some of the Flower services (for example, if you switch from in-memory to SQL Server directory implementation).
  • <Component name>.logging.config - the logging Spring.NET application container XML configuration. This configuration contains log manager configuration and it is pretty much the same for all components. You will need to change it if you wish to use a logging framework other than NLog (the default in Flower).
  • <Component name>.exe.nlog - NLog configuration. This configuration should be changed if you need to add logging targets or change the default one. For example, by default, Flower components log into files in ..\Log folder relative to the installation destination. If you need to change it, edit the NLog configuration (make sure NETWORK SERVICE has permission to write into the logging target).

"Component name" here is the name of the assembly of the component.

See also:

Installing the directory

To install the service host, run the following in the installation package:

msbuild /t:ServicesHost /p:InstallDir=c:\Your\Flower\Installation\Path

By default, the directory is configured for local (net.pipe) access. To enable remote access, you need to change the endpoint configuration in Flower.Services.Host.exe.config.

When you install the service host for the first time, you need to register it as a Windows service by using installutil. When you reinstalling the service, don't forget to stop it before installation.

Checking that the directory is working

The simplest way to ping the directory is to do that via the management API. First, in the installation package edit Config\flower.exe.config to make sure the WCF endpoint named 'Directory' matches the endpoint of your directory.

To install the management tool, run the following in the installation package:

msbuild /t:ManagementTool /p:InstallDir=c:\Your\Flower\Installation\Path

To be able to run the tool from anywhere, add your Flower installation location to the PATH environment variable.

Run flower in the command line and you will see the prompt '/>'. Then, type $dir.get('/') and press enter. If you see something like the text below, the directory has responded successfully.

C: 01.01.2013 00:00:00 U: 01.01.2013 00:00:00
R:  W:  CC:

Directory administration basics

The default Flower management API allows to administrate the directory in JavaScript compatible with ECMAScript 5.0 specification. The flower command line tool can work in interactive and batch mode. If the tool is run without arguments, it starts interactive prompt and interprets JavaScript line by line. If any arguments are specified, each of them is treated as a path to a JavaScript file to interpret.

The management API provides two main global objects and a set of useful global functions.

The $dir object provides access to the directory. However, in most scenarios you will use high-level utility functions.

The $fs object represents the file system. It provides functions similar to the powershell commands to browse the file system and read/write files (usually, XML files).

In the interactive mode, the prompt shows the current path in the directory that is the root by default (so, you see '/>' prompt). To change the current folder, call cd().

//Prompt is '/>'.

dir(); //Will output the contents of the root folder.

cd('/Processors'); // The prompt will change to '/Processors>'.

dir(); //Will output the contents of the '/Processors' folder.

Shortcut directory access functions accept paths relative to the current path.

var set = get('MySet'); //Returns '/Sets/Shared/MySet' - equivalent to $dir.get('/Sets/Shared/MySet').

rm('MySet'); //Removes '/Sets/Shared/MySet' - equivalent to $dir.remove('/Sets/Shared/MySet').

mkdir('MyFolder'); //Creates a folder 'MyFolder' at '/Sets/Shared'.

rename('MyFolder', 'MyFolderNewName'); // Renames '/Sets/Shared/MyFolder' to 'MyFolderNewName'.

The set of createOrUpdate* functions allows to create directory entries and maintain their internal structure if needed (there is one function for each directory entry type except folders; folders are created using mkdir()). As the name implies, each of these functions create new or updates existing entry with the data in the JavaScript object passed as an argument. This section covers only creation of a processor. To learn more, see "Scripting API reference".

Installing and registering a processor

By default, the processor is configured to use the directory at 'net.tcp://localhost:10000/Flower/Directory' and expose the endpoint 'net.tcp://localhost:10001/Flower/Processor'. If you wish to change that, edit Flower.Processor.exe.config in the installation package.

To install the processor service, from the installation package run:

msbuild /t:Processor /p:InstallDir=c:\Your\Flower\Installation\Path

When you install the processor for the first time, you need to register it as a Windows service by using installutil. When you reinstalling the processor, don't forget to stop it before installation.

To learn more about the processor administration see "Managing processors".

In simple cases a processor can be registered by the following call:

createOrUpdateProcessor({ name: 'MyProcessorName' });

However, you may wish to allow the directory to notify the processor on the changes in its folders. This helps the processor to react on the process status changes quickly without polling the directory too frequently. To enable this notification, you need to specify endpoint configuration of the processor.

First, create an XML Spring.NET IoC container configuration with an object with id 'processor' and class Flower.Directory.Host.Default.ProcessorClient. This class is a WCF proxy for the endpoint that the processor service exposes, so its endpoint must be configured to match the service endpoint of the processor.

The configuration file may look like this:

<?xml version="1.0" encoding="utf-8" ?>
<objects xmlns="">
    <object id="processor" type="Flower.Directory.Host.Default.ProcessorClient, Flower.Directory.Host.Default">
        <constructor-arg name="binding">
            <object type="System.ServiceModel.NetTcpBinding">
                <!-- Binding properties. -->
        <constructor-arg name="remoteAddress">
            <object type="System.ServiceModel.EndpointAddress">
                <constructor-arg value="net.tcp://hostname:10001/Flower/Processor" />

Having the configuration file ready, you need to register a processor specifying the file as the configuration source:

createOrUpdateProcessor({ name: 'MyProcessorName', from: 'Path\\To\\MyConfiguration.xml' });

Deploying a workflow

Workflows are created and updated automatically when you import assemblies into the directory. The management API takes information from the metadata of the workflow classes and creates directory entries accordingly. So, all you need to do to deploy a workflow is to import the assembly containing it.

In the management tool call:


The function importAssemblies accepts an array of assembly file paths and uploads the specified assemblies.

Check that your workflow is imported by calling:


To learn more about assemblies importing, see: "Assemblies importing".

Service crashes during the start and there is nothing in the logs

In such a case, you can debug the error by starting the service in debug mode from the console. Simply run the .exe file of the service with /debug argument and check the Default.log file in the current directory.


With a workflow written, tested and deployed you are ready to start it from an application. The next tutorial covers the basics of using the Flower client API: "Starting a workflow".

Last edited Oct 28, 2013 at 7:20 PM by dbratus, version 8


No comments yet.