Today I ran into the following error while creating demos for my WF session:
Error 1 Activity 'policyActivity1' validation failed: Can not find the rule set "Rule Set1". Check if rule set is defined in the rules file. c:\WF\Demos\09 - Rules\PaulGielens.WF.Rules\Workflow1.cs 1 1
First I made absolutely sure that the "Rule Set1" ruleset was properly defined in the rules file. I then found this hint at the Windows Workflow Foundation forum by Serge Luca, and experimented by first creating the state components to validate the rules against before slapping the policy activity on my canvas. No luck whatsoever. Alex came to the rescue and figured that, instead of storing the custom types together with the rulesworkflow in a single file (for the sake of clarity), I should store custom types in separate files. Alex's suggestion solved the problem. Thanks!
This error message is misleading.
I believe that there are at least two perspectives on the debate about designing and implementing enterprise applications on top of relational data stores.
Business aspect area
The business aspect area adds knowledge about business objectives, activities, and organizational structure. Try to think in terms of activities, channels and actors as the type of information in this aspect area. We often use object-oriented concepts such as abstraction, encapsulation and inheritance to create the business related artifacts that drive the design and implementation of our systems. Modeling approaches are OOA/OOD, UML and the increasingly more popular technique DDD. The implementation units of these concepts are objects and classes.
Information aspect area
The information aspect area adds knowledge about the information the business uses, the information structure and the relationships. Try to think in terms of communication and communication structure as the type of information in this aspect area. We often use conceptual modeling where the data and processing control parts of our systems are modeled in one unit rather than separately. The entity, relationships and attributes are our main concepts in this aspect area. ER, NIAM and ORM are popular modeling approaches. The implementation of an entity can either be a unit of procedural code, module, class, component or table(s).
Every discussion on “starting with the database vs. starting with the object model” and the positioning of object-relational mapping frameworks and tools is all about choosing a specific camp. I used to believe that choosing one or the other was inevitable. I was wrong!
We should not ask ourselves the question “with what should we start?”, but instead “how should we start?”. “With what” is often considered to be an implementation detail. A great example is the starting with the database vs. starting with the object model debate. It is much more interesting to look at “how” we want to describe our enterprise systems? Choosing an initial aspect area can be of great help. The two aspect areas mentioned here are complementary to one another, and so use them accordingly.
The Entity Data Model (EDM) vision implements most, if not all, of the concepts in both the business and information aspect areas. This makes it an ideal candidate for answering the “with what” question. For the sake of our enterprise systems let us focus on the "how" question for now, shall we?
I tried to commit to the simple rule “do not post a post on a post”, but now that Gregor has this excellent post on “Validating Dynamic Systems” on his blog. I’m going to say goodbye to the rule for now. Apparently Gregor and Erik created a talk on Software Visualization and already discussed their thoughts during the Crested Butte workshop in 2005. Guys why didn’t you bring up this subject in Arosa?
Anyway, one of my clients is struggling with the idea of “chain logging” systems for a while now. I shared thoughts with Cyrille Visser who made the initial design and we both ended up agreeing that the meta-model is the single most important thing. The meta-model is hard to agree upon in a large organization of organizations. There are multiple information levels for the visualization component to be effective. The visualization component(s) thus has to have multiple abstractions.
Process control systems in the oil and gas, automotive and feed industries have loads of experience in process visualization. It is going to be interesting to see how experiences in other industries are going to help up to bring order into the service oriented chaos.