Workflow Custom Activity - Designer re-hosting

Thursday, November 02, 2006 4:02 PM

In developing some workflow stuff, ran across the need to create custom activities that "aggregate" other atomic activities into a larger activity. The idea is that

  1. Programmer codes some atomic activities, exposes appropriate Dependency Properties
  2. Non programmer
    1. Uses these atomics and creates processes using the atomic compiled activities
    2. Saves these composite activities as a new custom activity
    3. Can expose specific parameters for inner activities, but otherwise the activity is "locked" for the end user.
  3. End user
    1. Uses the composite activities to define a workflow and run it.
    2. Can bind runtime parameters to the composite activities.
  4. Runtime picks up an end user's activity and runs it.

 

Gotcha's:

  1. Designer re-hosting is a bit more complex than I would like it to be..
  2. Had to fool around with designer emitted dependency properties "Promote Bindable Properties" and ensure it would do the trick. This is the best way I found so far to expose inner properties of the atomic activities to the "surface" of the composite activities and allow the end user to assign values to them.
  3. Had to add to the compilation a ToolboxItem attribute (the re-hosting examples don't do that, and since the non programmer does NOT have access to the code beside file, you have to add it within the designer compilation of the designer activity. The exact magic incantations are:
  4. ////////////////////// add these lines to the workflow loader:
    CodeAttributeDeclaration attrdecl = new CodeAttributeDeclaration(
    "System.ComponentModel.ToolboxItem",
    new CodeAttributeArgument(new CodePrimitiveExpression(true))
    );
    ctd.CustomAttributes.Add(attrdecl);
    CodeCommentStatement nurisComment = new CodeCommentStatement(
    new CodeComment("ToolboxItem decoration should do the trick..")); ctd.Comments.Add(nurisComment); ////////////////////// end added lines


  • Share This Post:
  • Share on Twitter
  • Share on Facebook
  • Share on Technorati

Feedback

# re: Workflow Custom Activity - Designer re-hosting

Great posting - just the information I was looking for. Can you elaborate on the 'fooling around' you did with the designer emitted dependency properties "Promote Bindable Properties".

7/3/2007 12:53 PM | Simon

# re: Workflow Custom Activity - Designer re-hosting

The composite activity "packaged" by the re-hosted designer gets saved as an activity - let's call it "Package". "Package" is now an activity that can be run. But if we want anyone to use "Package" and set any properties on it, these properties must be part of "Package" itself - the properties of sub-activities from which "Package" is composed would not accessible.

The action on the designer "Promote Bindable Properties" takes a sub-activity's property(ies) and creates a property on "Package" itself which maps (eg: populates and or reads) the inner property on the sub activity.

So as you design a package, you want to "float up" some or all of the inner properties so that you can run the "Package" with the proper access to inner activity properties.
7/9/2007 4:28 PM | Nuri

Post a comment