I'm getting more serious about blogging now and want to be more careful about what goes where.  So all of my technical & business related stuff will go over in my main blog.  Articles about motorcycles, racing and whatever else will go here.  Hopefully, by making this split google will start giving me some more love.

This is a really simple example of Grinder. In this case I’m just going to move a file from one directory to another and rename it in the process.

First, start the workflow designer and create a new workflow. Drag the file copy activity on to the workflow. In the properties area set the Source File Path to ${FULLPATH} and set the destination file path to c:\temp\test\output1\${FILENAME}_${CLIENTID}${EXT}. Now save the workflow and then build it.

Once the workflow has been built go to the configuration editor. Open the existing Configuration.xml file (it will be in Grinder’s folder under Program Files). Now right click on Workflows and select add workflow:

Give the workflow a name. Then click the ellipse button next to the strong name text box. This will let you select the workflow assembly you want. Because a single assembly can contain several workflows you will be asked to select the workflow in the assembly:

After you named your workflow and selected the workflow from an assembly click the update button. We are now ready to setup a file type.

Right-click File Types and select Add File Type. Give you file type a name. Specify the file pattern that will be used to pickup the files. For instance if you are going to process work documents with Grinder you would use *.doc as your file pattern. Then from the drop down select the workflow that will be used to process the files. After you have done that click update.

Now go to directories and add a new directory to monitor by right clicking and selecting Add Directory. Give the directory a name, choose the path (C:\temp\test\client1). Then select the types of files to find in the directory, you can choose as many as you like.

We also want to add a CLIENTID property to the directory so Grinder can use that information during processing (remember how we setup the FileCopy?). Click on properties and add a new property. In the properties form – first click add, then click on the new property. The change its name and value and click update. Then click the Update button at the bottom.

After you have added your property and closed the dialog click update to save the changes to the directory. Now save the configuration file.

We have now done everything we need to do in order to run our sample – mostly. First – create the directories you are going to be using (C:\temp\test\output1 and c:\temp\test\client1). If you just installed Grinder it will not be running yet. Either go to the services control panel and start it or use the Grinder Monitor to start it.

After Grinder starts it will eventually scan the directories for files to be processed. When that happens you will see the file *.docx you created disappear from the client1 directory. If you go look in the archive directory you’ll see it. You will also see it in the output1 directory renamed with the CLIENTID you entered.

This is probably the absolute easiest thing to do with Grinder. Hopefully though it give you a small inkling of what it can really do.

Grinder comes with 4 tools along with the service itself. Here is a brief description of each. I’ll go in to great depth soon.

Grinder Configuration Editor

This is the tool where all configuration for Grinder is done. You specify which workflows are available, what types of files are being processed, and which directory the files are to be picked up from.

Grinder Workflow Designer

The workflow designer is a basic workflow editor that will produce Workflows specifically for Grinder. It provides access to Grinder’s workflow activities.

Grinder Service Monitor

This is a simple diagnostic tool that allows you to stop and start the grinder service. It will also register and unregister the Grinder service with the Windows Service Manager.

Grinder Console

The Grinder console is a console version of the Grinder service. This allows you to run Grinder without installing it as a service.

In order to make workflows easier to write and more flexible, Grinder provides a library of macros that are used to substitute values inside workflow actions. When grinder is making the substitutions it will search for values in the following order:

• Symbols
• File Properties
• Directory Properties
• Service Properties
• Environment variables

The format for a macro is ${macro}. For example ${FULLPATH}. Grinder will search for a macro named FULLPATH and substitute the value for ${FULLPATH}.

The following are the built in symbols:

As an example:

When setting up the File Copy action the source file would use ${FULLPATH} in order to get the path to the file being worked on.  To copy the file to a client directory and add a date time stamp you would use the following:  d:\clients\${CLIENTID}\${FILENAME}_${DATE(yyyyMMdd)}.${EXT}.

Using Grinder's configuration editor will allow you to associate macros like CLIENTID to a directory.  This provides the flexibility to move files around based on the file type, the directory is came in or other variables.

Right now Grinder ships as a single MSI file with everything in it. The installation is pretty straight forward but there are two things to consider first: user account and archive directory.

Because Grinder runs as a Windows service it needs a user account. Further, because Grinder will be moving files around and deleting them it will need a user account that has been granted a few privileges. If the directories you are going to be monitoring are on the local machine and Grinder won’t ever have to access a remote directory then a local user account will work fine. However, if Grinder is going to be working in file shares on remote systems you will want to use a domain account instead.

Grinder needs an archive directory because on occasion bad things can happen. Part of Grinder’s defense strategy is to archive all file before processing them. This way if something bad does happen you can at least get the original file from the archive. The bad thing about this strategy is that if you are handling really big files your archive can get out of hand.

I’m going to assume we are installing Grinder on a development workstation. For the user account create an account named ‘sysop’. For the archive directory I use C:\temp\archive.

With those two details out of the way we can run the MSI. Click through the usual stuff (other than the EULA there aren’t any options). As part of the installation process Grinder will pop-up and ask you for the user account and archive directory. The installer will validate the user account before going on.

When the installer finishes the Grinder service will have been setup and be ready to run. It won’t be started yet though. You can do that through the Services panel applet or the Grinder Service Monitor.

I’ve been a bad wanna-be entrepreneur and not done a good job promoting my products and services. Time to fix that oversight. Back in February I talked about my product Grinder. It is a service that processes files using Workflows. It is an ideal replacement for BizTalk’s file adapter. It is also useful for integrating applications with SharePoint libraries. Fundamentally though it is about replacing all those programs that get written that just watch a directory and then ‘do something’ to the files that are found.

Over the next few days I’m going to talk a lot about using Grinder and how it can be used. I’m also going to talk about how to write Workflow actions that can be written to extend the functionality of Grinder for your specific situation.

If you are interested in getting a copy of Grinder please contact me (jakew@guerillaprogrammer.com) and I will send you a copy to try out.