If your regular data is held in a database I’m not entirely sure why you’d want to have all of that customer specific information in an xml file. Move it into the database.

Next, there are many different kinds of rules engines out there. Considering you’re using asp.net you might want to look at Windows Workflow for at least some of this. You might read the following: http://karlreinsch.com/2010/02/05/microsoft-rule-engines/

A long time ago I used a product called Haley Rules to drive a c# web app. It controlled everything from the screens that were available right down to the fields that appeared and whether they were required or not. It took awhile to get the team on board with how it worked, but once that happened bringing on a new client was extremely simple. Haley was since gobbled up by Oracle, but was probably the absolute best one out there.

Others you might be interested in are NxBRE and even nCalc. NxBRE is an actual rules engine which is a port of one built for java. nCalc on the other hand isn’t a rules engine per se. However, if you can express your logic in simple boolean statements then it is extremely fast. I’m currently using this to drive page flow in one of our applications.

Some commercial ones include: FlexRule, iLog

Your existing rule engine tool supports your web application, which means it meets your needs already. You can use other “Rule Engine” like MS work flow, but IMO it can also end with a hard to maitain situation.

Let’s say there is registration portal. It collects general user infomation and save them into database. Simple. we build one protal for one client with several ASCXs and Rules.Then for another client,we add more rules and more controls to these ASCXs. Working in this way, sooner or later we will reach the final straw client. At that time the code base is hard to maitain and devs lost themselves in lots of rules. It is what happened to me.

So to me, it is not about which Rule engine to use.

Then How?

I have raised a question, and one of the answer makes sense to me( thought not a picked answer). In this answer, the guy mentioned what kind of company you are. In your question it is more like which department you are or do you want to seperate your dev teams.

If you are in a archetect teams, build a framework with a rule engine. Create a basic registraion portal as a sample portal.Make DAO,BO decoupled with UI (Seperate layers).

If you are in a customise teams, create customised user control (dont reuse these user control in basic version). What you will recreate is just UI, you can still use DAO,BO as they are not defined in user control, they are at other layers. In this way you get the freedom to define your client specified rules without worring about contaminating other clients rules or introducing new bugs to other client’s registrations.

Just realise it is not like an answer to your question. Anyway it is my thoughts after limited xp of working on a engine rule based ,multi-clients web application.

When the individual customer needs are so wildly different that shared functionality represents less than 50% of the features for a given customers needs, then there are really only two major ways to handle this:

Writing a custom page for each individual client

This tends to sometimes be an unsavory option for both technical folk as well as business and sales folk. It can also be unsavory if the client realizes that you are performing a lot of custom development to meet their needs.

Technical considerations

As a developer, high maintainability is one of the central goals that we should strive to accomplish, so writing custom pages for individual customers is counter to this goal. Assume that a common feature must be added that should affect all customers, now this change must be manually implemented for all clients and tested for each client that has a seperate implementation for that page. If you have a number of clients then this can simply be untenable over time.

Business considerations

From the business perspective as an ISV, we like to build a product, which is typically more involved than just the software itself. Selling a software product implies that as a vendor, we have a single package that can fulfill all of the customers needs with minimal to no customization to the core of the product itself.

When product customizations need to occur to accomodate a client, then the product may be a poor fit, or may have just been poorly planned. It may be that the solution that is being sold cannot actually be considered a product at all, but is simply being marketed that way. The software business can be tricky like this and is why product owners and sales people make the big bucks because this winning formula for success in selling software can be extraordinarily tricky. If you don’t market it right, or form a product idea correctly then you may not sell or you may sell and be unable to deliver on promises.

Client considerations

All clients like to feel that they are getting a good deal, and when they buy a software product they want to believe that all of their needs are being met out of box. This is why software products sell more readily and easily than just custom software development, even when the client needs are so inherently specific that no such product could ever exist off the shelf.

If the client finds that you are performing a good deal of custom software development for their needs alone then they lose faith that your product ever had the ability to deliver and that they will end up paying dearly for it in the long run to cover those custom development costs.

When is this a good idea

If the software is in a niche market with a small amount of customers and limited opportunity for growth, then custom web page development for specific features is probably the best choice.

XML based layout and rules engine

Basically you would identify core functionality to be built into pages, and anything customer specific should be defined through a custom layout and rules engine that allows client needs to be customized outside of the code base.
The technical design considerations for this are that

Technical considerations

The client needs at this point become a schema change through XML rather than en expensive maintainability nightmare of a code change. Controlling layouts through XML to define your view, XML to tie in your model, and rules to define your controller will allow for a solid architecture that will scale as your business grows and also maintain loose coupling, high cohesion, and high maintainability. These XML documents can be easily maintained through a NoSQL or even traditional RDBMS systems.

Business considerations

Limiting targeted releases to accomodate customers bolsters the strength and scalability of the product as a whole, and leaves the business confident that they have the ability to grow rapidly in a wild and volatile market. Some disadvantages are the increased complexity of the application and product itself, and the considerations towards increased initial development time and the higher costs associated with this.

Client considerations

Clients can feel confident that their needs are being met through the product without significant cutomization and that their requests and changes can be rapidly accomodated.

Having said that over-flexibility is the cause of many over-complications in software, can you imagine a framework so flexible as to allow you to offer infinite flexibility to your customers?

That said, I would suggest writing a DSL, rather than using XML, for a customisation rules engine.

You can use ANTLR to create a DSL from scratch, or you can write a DSL on top of Boo, which means you don’t have to make trivial decisions like code-formatting and operator precedence, you just get to work with what’s unique to your domain problem.

This should simplify your current rules engine dramatically and also be more extensible in the future. As an added advantage, if you get it right, it will be more reader-friendly for the end-user, so that they can view their own customisation rules and confirm their correctness.

7500 lines of code (XML) is alarming – I think you have to ask yourself how much benefit your users get from the customisation and how much it costs you to provide it. Personally I’d start by trying to reduce the customisation as much as possible.

Next I’d move whatever customisation is left into a database as very simple data (something similar to name value pairs but for each customer and perhaps allowing a type field and a sequence number). Provide a nice simple web interface to this and check that all values entered are valid. The aim being to make it so easy to change that eventually your customers will be able to do it. You could also put system defaults into this structure so you can change the default behaviour via the database.

create table CustomerSettings( 
   customerId         int,
   type               varchar(20),
   name               varchar(20),
   value              varchar(20),
   sequence           int null
);

insert CustomerSettings ( 0, "FORMAT", "emp_no", "^[0-9]+$" ); // default

insert CustomerSettings ( 123, "MENU","main_menu","hire people",1

insert CustomerSettings ( 123, "MENU","main_menu","fire people",2

insert CustomerSettings ( 123, "HIDE","salary",null, null );

insert CustomerSettings ( 123, "FORMAT","emp_no","^[A_E][0-9]+$", null );

etc, etc

The web app would first load all the values for a customer or, if no value is present, it would load the default. A new customer would then just run just using the defaults. You could add settings on the fly until the customer is happy.

The data per customer should hopefully be much smaller. Using defaults where possible.

Mike

PS please forgive the formatting, I couldn’t make head nor tail out of the info on how to show code in a post.