Rain

So there was a bit of rain today, almost enough to flood our house but not quite. And our roof leaked. But the shed is intact. Then as quickly as it arrived, it stopped. And a few hours later, all the evidence had gone. Here are some pictures.

How rich are you?

I've got a theory, not a particularly original theory admittedly, that we all think we're poorer than we actually are (something to do with our celebrity obsessed culture). It only takes a few seconds to plug in some numbers to the Channel 4 Rich-o-meter or The Institute for Fiscal Studies' 'Where do you fit in?' page to see how rich, or otherwise, you are. The Channel 4 one is interesting since it allows you to compare yourself to the rest of the world, which shows even a very modest UK salary is pretty damn good when compared globally. The Institute for Fiscal Studies' version is probably more accurate since it is based on household income rather than personal income.

Adding services to the Windows Workflow runtime and a simple activity implementation

There are two groups of Windows Workflow service that you'll come across. The first group are the well-known services that are used by the runtime itself (well-known because they are well-known to the runtime not necessarily to the developer using the runtime...). These are things like the persistence service, tracking service, data exchange service etc. You can use these services out of the box or you can inherit from them and modify them as required. Fortunately a lot of the methods in these services are virtual so you can quite easily hook in new functionality (and quite possibly get yourself in a whole heap of trouble as well).

The second group of services are services that can be used by your own custom activities. At this point it's worth considering when using your own service makes sense. For instance I downloaded an email sender activity that required me to configure the SMTP host address and port as properties on the activity. Since it was a standalone activity, this was probably the sensible option, since it simplified usage. But if I were to use the activity in many different workflows and the SMTP host changed I'd need to update every workflow to work with the new SMTP server. So if I was to write the activity myself it may well make more sense to handle all this kind of configuration in an email sender service. This also has the advantage of being able to pull the plug on emails being sent out if a poorly written workflow was sending out too many emails. So it depends on what you're trying to achieve whether services make sense or not.

To actually add your own service to the runtime is pretty straightforward. Define an interface and mark it with the ExternalDataExchange attribute.

    [ExternalDataExchange]
    public interface ISendEmail
    {
      void Send(string toAddress, string message);
    }

Next write a class that implements the interface.

    public class EmailSenderService : ISendEmail
    {
      public void Send(string toAddress, string message)  
      {
        // send it...
      }
    }

I'm not entirely sure whether you have to use an interface or if you can just use a class straight off but I've only used interfaces myself and there are at least a couple of good reasons why this is the best way to go. First, it decouples your service implementation from the activity that is calling it. For the email sender example, this means you could replace the SMTP sender with a new implementation using Exchange (or whatever) to send the email without needing to change your activity implementation. Second, if you want to use the CallExternalMethod activity to call into the service, this only accepts an interface for the InterfaceType property.

After that, all you need to do is add the service to the runtime.

    // external data exchange service
    ExternalDataExchangeService dataService = new ExternalDataExchangeService();
    runtime.AddService(dataService);
    
    // email sender service
    EmailSenderService emailService = new EmailSenderService();
    dataService.AddService(emailService);

To call the ISendEmail methods, you have two choices, hook up a CallExternalMethod activity or write a custom activity to call the method. Since I've not yet shown an activity that does anything useful, I'm going down the latter route. Create a new activity via the Add/Activity... popup menu item and add some code as follows.

    protected override ActivityExecutionStatus Execute(ActivityExecutionContext executionContext)
    {
      // generate alerts
      ISendEmail sendEmail = (ISendEmail)executionContext.GetService(typeof(ISendEmail));
      if (sendEmail != null)
      {
        sendEmail.Send("doogal@doogal.co.uk", "blah");
      }

      return ActivityExecutionStatus.Closed;
    }

This is the simplest activity that you can implement, it executes some code then returns saying "I'm done". When I work out how to implement some more complex activities, I'll write about it.

Blogging is like the lottery

The lottery people Camelot used to say "You've got to be in it to win it". Of course the chances of a big win are tiny but if you never buy a ticket you'll never win anything at all. So it is with blogging, you're pretty unlikely to ever get a big crowd of people to your blog, but occasionally you might get that £10 win. Every post is another ticket in the blogging lottery and every so often you'll get a few hits from one.

Which is what happened with my little post about SonicWall on Vista, if only because nobody else has bothered to post about it. And if anybody wants to know, the latest beta still has the same problems for me, Vista complains that two computers with the same IP address are connected to the network. But I'm coming to expect these kind of issues with Vista. Bring on SP1...

Annoying Vista UI

In Vista, Media Player and Photo Gallery have very similar user interfaces. The toolbar thingy at the bottom of their windows looks almost exactly the same.

	This is Media Player
	This is Photo Gallery

But the big button in the middle works differently. If I'm watching a video in Media Player, the biggest button on the toolbar pauses the video. In Photo Gallery, it switches to slide-show mode, an operation that takes several seconds and I never want to do. If I'm not thinking about what application I'm in, I'll hit that big button to pause the video and see my computer grind to a halt whilst it does something I don't want it to do. Why have very similar UIs if the buttons do different things??? Consistent UIs are only any use if they behave consistently.

The Complicators

I was under the impression that computing was meant to make our life easier, but it seems there's a bunch of people out there who want to make my life more difficult through poorly thought out APIs or badly designed user interfaces. I call them the complicators.

There are three types of complicators.

Dumb Complicators - These are the developers who aren't really too hot at programming. They copy and paste and generally fumble around in the dark until they have a solution that seems to work, then quickly move onto the next problem, not thinking too much about how the UI or API they've just produced will be used in the outside world. This may be down to inexperience, the need to get something out there ASAP or just a lack of interest in producing quality software.

Evil Complicators - The second group of complicators are a cynical bunch who complicate things to make themselves indispensable to their company. Depending on how cynical I'm feeling, I may confuse either of the other two groups as being members of this lot. 

Clever Complicators - The third group are generally incredibly intelligent but have no way of empathising with the poor people who are going to have to use their software. They understand the complexity and can't understand why anybody else wouldn't be able to. I worked with a very clever guy whose API consisted of a programming language using XML to build the function calls, parameters and the graph used to join all these bits together. Yes, he was a big fan of XSLT. Yes, what he produced was incredibly powerful and clever. Actually trying to use his API from another programming language was an absolute nightmare. On the other hand, I worked with another very bright chap whose API was also based on XML. The difference being that his API simply described data and a few parameters. The actual implementation details of how it all worked under the hood was completely hidden from the API, except where necessary. The wonderful thing about that API was that the simplicity of it made me look good, since I was able to write my code on top of it in super quick time.

This third group of complicators interest me. It seems like there are plenty of clever people in the IT industry but a very select few who can actually take complicated problems and abstract them into something simple for the rest of us to understand. And doing that is the only thing that can drive technology forward. As Einstein said "Make everything as simple as possible, but not simpler."

Something for the ladies

Or more specifically any mothers who've stumbled across this site. My other half has set up a website dedicated to providing tips for mothers and parents in general. There are other sites out there providing similar resources (Mumsnet being the obvious example if only due to their legal problems with Gina Ford) but Mums Guide is providing a different angle on things.

She was after a link from the Random Pub Finder (due to it getting many more hits than this site) but I couldn't for the life of me think of any kind of link between pubs and parenting.

Aren't web services meant to solve interoperability problems?

Somebody has written a web service using JBoss. I'm trying to call it from .NET 1.1 or, heaven forbid, the MS SOAP toolkit. And neither of them can call any operations that have parameters, which kind of restricts what we can do with it. I guess one solution might be to have methods called method1(), method2(), method3() etc all the way up to MAXINT. Doesn't seem a great idea. Or perhaps an ASP.NET 2 web service could call the JBoss web service and expose the functionality as another web service? Yeh it's daft, but it might just work.

So could it be the folks telling us web services were the panacea for all our interoperability problems were actually just snake oil salesmen? Surely not...

Adding icons to custom activities

In a few places I've worked, it seems like some people's jobs pretty much entails selecting and adding icons to development projects. Nice work if you can get away with it and that's what I spent some time doing the other day.

It's actually ridiculously easy to add an icon to a custom activity. In fact it's just the same as adding an icon for any component. Add the image to your project, set its 'Build Action' property to 'Embedded Resource', then add the following attribute to your activity class.

[ToolboxBitmap(typeof(UserActivity), "user.png")]

The icon will then appear in the toolbox and will be shown when the activity is rendered in the workflow designer. It's possible to completely change the rendering of the activity and I may investigate that at a later date, but this simple addition seems to provide the biggest bang for buck.

Property Snake

I remember Fucked Company appearing on the web around the time of the dot-com bubble bursting so perhaps the appearance of the Property Snake website (along with House Price Crash) is evidence that the property bubble is finally about to burst. That and the more bearish coverage in the press...

Windows Workflow isn't workflow

Ask anybody who's had any experience of workflow software what it is and they'd likely give you a different answer to the next person you ask. But I'm fairly certain if they took a look at Windows Workflow they'd probably say it's not what they understand workflow to be about.

I'm the same and it's one reason why when I first looked at WF I was a little disappointed. But as time goes on and I play with it more and more I'm realising what a really nice piece of technology it is. In fact I'd say I'm actually very pleased that Microsoft didn't build another workflow system because it very likely wouldn't have met my needs either. There are hundreds of workflow systems out there, all implemented differently from each other and all meeting certain needs and failing to meet other needs.

I guess somebody at Microsoft realised this and rather than producing yet another workflow system (YAWFS for short), they wrote a framework for developing any kind of long-running process you'd like to build on top of it. As far as I'm aware nobody else has tried to come up with anything similar and the outcome is far more impressive than YAWFS. The book 'Essential Windows Workflow' explains it a whole lot better than I can but essentially it's a whole new way of writing software. No longer do you need to worry about what to do when you need to wait for a day before moving onto the next step in your code and it seems like threading issues will be much reduced. I'm almost inclined to think that WF may be the answer to a lot of the multi-threading pain we suffer today and really need to solve PDQ in a world of multi-core processors, although I need to delve deeper to know for sure. If you come from a .NET background, you can reuse those skills in WF, although it has to be said the learning curve can be quite steep. 

And it seems like they've succeeded in their aims. Not only are people using WF for workflow products, they are using it for things that you wouldn't necessarily associate with workflow. In conclusion, I think it rocks.

Compiling a XOML workflow

In my last post I talked about validating a XOML workflow. Another way to validate a workflow is to just try and compile it and see what you get back from the compiler. The disadvantage of this approach is the fact you have to start to write things out to file. So I've been validating using the previous method and then just compiling when necessary*. The downside of this approach is the x:Class attribute which can't be present when trying to execute a XOML workflow and must be present when trying to compile it. The simple workaround for this is to add the x:Class attribute before writing the XOML out to a temporary file. Anyway here's the code -

        // copy to a temporary file and add the x:Class attribute
        string tempFileName = Path.GetTempPath() + "temp.xoml";
        XmlDocument doc = new XmlDocument();
        doc.LoadXml(xoml);
        doc.DocumentElement.SetAttribute("Class", "http://schemas.microsoft.com/winfx/2006/xaml", WorkflowName);
        doc.Save(tempFileName);
        try
        {
          // Compile the workflow
          WorkflowCompiler compiler = new WorkflowCompiler();
          WorkflowCompilerParameters parameters = new WorkflowCompilerParameters();
          parameters.LibraryPaths.Add(Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location));
          parameters.ReferencedAssemblies.Add("MyActivities.dll");
          parameters.OutputAssembly = string.Format("{0}.dll", WorkflowName);
          compilerResults = compiler.Compile(parameters, tempFileName);
        }
        finally
        {
          File.Delete(tempFileName);
        }
        
        StringBuilder errors = new StringBuilder();
        foreach (CompilerError compilerError in compilerResults.Errors)
        {
          errors.Append(compilerError.ToString() + '\n');
        }

        if (errors.Length != 0)
        {
          MessageBox.Show(this, errors.ToString(), this.Text, MessageBoxButtons.OK, MessageBoxIcon.Error);
          compileOK = false;
        }

* Another reason I did it this way was because I implemented the validation piece before I implemented the compilation piece and didn't realise I could just re-use the compiling code...

Validating a XOML workflow

If you're using workflow assemblies, there is no need to validate your workflow since the compilation process has already done this for you. But if you're working with XOML files you'll probably want to validate it at some point before deploying it. Unfortunately there doesn't seem to be anything provided by Windows Workflow just to validate a workflow. The workaround is to start up the runtime and load up your XOML and see what errors you get. You can use something like the following (ripped off and modified from a newsgroup posting) -

      WorkflowRuntime workflowRuntime = new WorkflowRuntime();
      workflowRuntime.StartRuntime();

      StringReader stringReader = new StringReader(xomlString);
      XmlTextReader reader = new XmlTextReader(stringReader);
      try
      {
        instance = workflowRuntime.CreateWorkflow(reader);
      }
      catch (WorkflowValidationFailedException exp)
      {

        StringBuilder errors = new StringBuilder();

        foreach (ValidationError error in exp.Errors)
        {
          errors.AppendLine(error.ToString());
        }

        MessageBox.Show(errors.ToString(), "Validation errors");
        retVal = false;
      }

One thing to be aware of is that you can't add the x:Class attribute when you use this technique (which you must add if you want to compile your XOML later on). This Catch-22 can be quite easily solved and I'll talk about it in a later post.

If you're wondering why you'd use XOML, I think it probably makes sense when you're automatically generating your workflows from some other source.

Invalid FORMATETC structure (Exception from HRESULT: 0x80040064 (DV_E_FORMATETC))

I've been caught out by this twice now. If you create a new web control by creating a new class and then inheriting from Control (or some other derived class) it will appear in your toolbox, but when you try and put it on a web form, either nothing happens or you'll get the error:

Invalid FORMATETC structure (Exception from HRESULT: 0x80040064 (DV_E_FORMATETC))

This somewhat baffling error message is caused by the fact that when you create a new class Visual Studio 2005 makes it private by default. I'm not sure if this is a good or bad thing, it sure as hell beats the "everything is public, every parameter is passed by reference, every variable is a variant" ethos that used to cause so much horrendous VB code to come into existence. Just a shame the error message doesn't give a clue to the real problem.

Implementing your own workflow type in Windows Workflow

Windows Workflow is extensible in almost every way. But one thing I didn't realise until seeing this example is that it is possible to implement your own workflow type as well. This looks really interesting. Although the state machine workflow models what I want to do pretty well, I'm not too happy with the UI of the designer so I might have to look into this further.

Validator for a custom activity in Windows Workflow

Last time I talked about adding a property to a custom activity, this time I'll talk about validating the value of that property.

So we have a custom activity called UserActivity with a property called Form and we want to ensure the workflow designer has specified a value for this property. First thing to do is write our validator class, which looks like this - 

  class UserActivityValidator : ActivityValidator
  {
    public override ValidationErrorCollection Validate(ValidationManager manager, object obj)
    {
      UserActivity activity = (UserActivity)obj;
      ValidationErrorCollection validationErrorCollection = base.Validate(manager, obj);

      // Don't validate when the activity is standalone  
      if (activity.Parent == null)
      {
        return validationErrorCollection;
      }
      
      // check Form property has been set
      if (string.IsNullOrEmpty(activity.Form))
        validationErrorCollection.Add(ValidationError.GetNotSetValidationError("Form"));

      return validationErrorCollection;
    }
  }

All we do is override the Validate method, call the base implementation, then check to see if the activity has a parent. This check ensures we don't validate the activity when we are designing and coding the activity itself. The next line does the actual work, using a helper method provided by the ValidationError class. This can be used in the most common type of validation, checking to ensure the property has a value. If that's not what you're doing, create an instance of the ValidationError class instead, using whichever constructor you need. 

Once we've written the class all that remains is to tell WF what class should be used to validate the activity, which we do by adding an attribute to the activity declaration.

[ActivityValidator(typeof(UserActivityValidator))]
public partial class UserActivity: HandleExternalEventActivity

And that's it. Now compiling a workflow assembly using the custom activity should show a compiler error if the Form property has not been set.

Activity properties in Windows Workflow

I initially thought Windows Workflow was horrendously complicated, needlessly so. I've since realised that it's just exceedingly extensible but one problem is that there aren't a great deal of internet resources to search through to find the answer. No surprise I guess since this is pretty new technology. So I've decided to add some little tidbits. I'll present a few very short posts about a very small subset of the functionality, a kind of Windows Workflow for dummies. Given that I'm a dummy myself, I am perfectly placed to do this I reckon. Of course since I'm still learning all about WF, these posts may be incomplete or plain wrong.

So first up, adding a property to a custom activity. Properties in WF don't work like properties in normal .NET classes, they are based around dependency properties, which are properties that can be attached to any class deriving from DependencyObject. All activities inherit from DependencyObject so they can use dependency properties. I believe dependency properties must be used when you want to let your workflow designers be able to bind their properties together. Normal properties would have no way of knowing how to update other bound properties when their value had changed.

What is probably worth mentioning at this point is that WPF also uses dependency properties and dependency objects. They look very similar to the WF ones, but they are defined in a different place (System.Windows for WPF, System.Workflow.ComponentModel for WF) so I can only assume there are some subtle differences between the two.

Anyway, here's some code for a simple WF property.

    public static DependencyProperty FormProperty = DependencyProperty.Register("Form", typeof(string), typeof(UserActivity));
    
    [DesignerSerializationVisibility(DesignerSerializationVisibility.Visible)]
    [Browsable(true)]
    [Description("The form to be displayed when the user initiates the activity")]
    public string Form
    {
      get
      {
        return ((string)(base.GetValue(UserActivity.FormProperty)));
      }
      set
      {
        base.SetValue(UserActivity.FormProperty, value);
      }
    }

So we have a custom activity called UserActivity with a property called Form. It looks like a normal property except the getters and setters use the GetValue and SetValue methods defined in the DependencyObject class. Beyond that all we need to do is register the dependency property. Once that is done, the property should appear just like any other in your workflow.

Metastorm BPM 7.5 review

It's been around a while so it's about time I wrote down my thoughts. If you want to see the official line take a look at the Metastorm Press Release, I'm just going to talk about things that interest me, which in general means the core product and any .NET integration pieces.

One of the main reasons I wasn't particularly keen on version 7.0 was the requirement to disable DEP before installing. Although this was rectified in the first service release, installing still required disabling DEP, installing 7.0, re-enabling DEP then installing the service release. Thankfully this has all been fixed in 7.5 and I presume 7.5 can be installed straight over 6.6, although I haven't tried this yet.

I've been running with 7.5 web client against some 6.6 engines to get a feel for it. Although this isn't supported and it does seem to have a few issues, it's pretty useful for testing out the various client-side hacks we've employed in the past. There's not been any major innovation in the web client but it has had a few minor tweaks and I'm very much of the opinion that small things matter. The things I like are

• the ability to kick off an action without opening the folder, this is a quite a productivity boost.
• fixed headers on a grid. I'm sure it took an afternoon to implement but it will please many many people.
• the error message when a required field has not been populated tells you the name of the field. Again, a minor change but shows someone is paying attention to the details

You can also add links from the web client to other sites. It's seem a bit of a random feature but I'm sure some people will love it.

The Designer on the other hand seems somewhat unloved, which is understandable given Metastorm have started on a complete rewrite of it. There aren't really any new features to speak of (except the .NET event delegation which I'll talk about shortly). There are some serious performance issues when using it, it seems to flicker constantly when moving around and adding fields to a form takes forever. I've had it crash a few times but I'm not sure it's any less stable than previous versions. The pointless dialog count is about the same, although I did find a new one when it couldn't locate the ELB file in the database so it asked if it should look for an XEL instead. Yes of course you should, do you really need to ask???

So onto the .NET integration. Initially I thought this was pretty poor but upon closer examination it is actually reasonably good. Tell the Designer you want to delegate your map events to a .NET assembly then go into Visual Studio and create an assembly for the map via a wizard. I thought this was the end of it, which left me wondering what would happen when I updated the procedure. It turns out there is some integration with Visual Studio but the installer didn't activate the add-in. Once I had that running, I was able to synchronise the procedure and assembly and deploy it.

There's a few problems with this integration though

• not all events are covered. When button pressed and when the user selects a row in a grid are the obvious ones, but calculated fields and basically all places where e-Work formulae are used need to be available.
• deploying the assembly requires stopping and starting the engine. Oddly, Metastorm have worked around this by stopping and starting the engine for you from Visual Studio rather than going down the more obvious route of using shadow copies. This is fine for a development machine but deployment to a production machine would be much easier without this requirement. ASP.NET has been doing it for years...
• I think the Process Orchestrator requires a separate license purchase. Really this should be part of the main product and until it is, I don't think we'll be interested in using it.

.NET 3, worst... name... ever...

People have got their fingers burned in the past. Installing .NET 2 did cause some applications to break (OK, I can only think of Metastorm e-Work off the top of my head but most people I deal with are using that bit of software) so every time I tell them to install .NET 3 to use the wonders of Windows Workflow I have to include a disclaimer that .NET 3 isn't really a new version of .NET, it runs on top of .NET 2 so shouldn't break anything blah blah blah. Worst... name... ever...

Browsers getting interesting again

Well interesting is perhaps stretching it, but certainly confusing. IE7 has been out for a long time now and it seems to have stalled at about 30% usage. Then today Apple released a version of Safari for Windows. So now I have yet another browser to worry about, because I'm guessing quite a few people will start using it, because it's not Microsoft. Yeh, it's based on Mozilla but it's bound to be different to FireFox and it's bound to be different to Safari on the Mac.

And IE7 doesn't make life any easier. I can't forget about IE6, because most people are still using it, but enough people are using IE7 that I can't ignore that either. I will however continue to ignore Opera, Konqueror, Lynx, Netscape and any older versions of IE. Complain if you like, but I have better things to do with my time than worry about browsers with miniscule market share.