How can I add programmability to my application

Question

I'm writing an applicaton that is, at its core, a rules engine. The users want to be able to define custom rules. Some of these will be fairly simple algebraic expressions, many will involve some if-then branching logic, and some will be even more complex. What are my options for doing this?

My users are pretty smart, proficient at T-SQL and Excel commands, and generally familiar with programming constructs but they are not "programmers" per se.

I've thought about using VBA/VSTA; interoperating with Excel somehow; integrating some sort of scripting language (Ruby? Perl? Tcl?); or rolling my own.

In the best of all possible worlds, I will give them an editor with color coding and IntelliSense-like interactive help, an immediate execution mode for testing and experimenting, and a step-thru debugger. They also need to be able to save, retrieve, edit, and execute their rules. Blazing speed is not essential.

My environment is Windows/.Net 3.5/C#

Any ideas?

Answer 1

Any implementation like that is full of risks. I'd start with the smallest possible set of customizations and then incrementally build up your capabilities from there.

Don't try to program all sorts of extensibilities into it at once, unless you already have lots of skill doing that. Pick one simple ability at a time - running standard SQL queries and returningg recordsets or whatever.

Answer 2

I'm not a windows person so my answers won't exactly suit your situation. I'd recommend embedding a full blown scripting language interpreter into your application. Expose some primitives (ie. the parts of your rule engine you want public) and then provide a full blown interpreter. I know that TCL, Python and Guile are designed to be embedded in this fashion. I'd personally recommend Python since Scheme (guile) is a little esoteric and TCL seems to be losing ground generally.

Answer 3

Don't invent your own scripting language! It is bad to learn a new language for a single system. I'd try to use Python which is relatively easy to learn and to understand.

Answer 4

Windows has built in Windows Script Host engine with two interpreters for VBScript and JScript. You can easily use them. Just check out MSDN for appropriate COM interfaces.

Answer 5

Lua could be a good solution. What I'm really wondering is how complex could be to integrate your rules engine with a scripting language that allows users to write their own rules.

A good approach can be to embed everything (the rule engine too) inside the scripting interpreter, otherwise you would end up writing a lot of code to bridge what an user writes into the script with the related rules used in your program.

However designing such programmability requires much attention to what your language should be able to do, starting from a little core of utilities and then extending it; or you can really plan a lot before starting the whole implementation but for my experience (I wrote like 3-4 interpreters so far) the better way is to fit it while developing it, of course with the feedback of the users: it will be necessary, because you can suppose how good they are, but I wouldn't count on it.

Answer 6

For an honest-to-God rules engine, you could look into using Clips. Clips is an OpenSource expert system that you can embed into your own applications.

If you want true scripting, there are tons of tools out there to add in scripting to applications with languages like Lua, TCL, REXX, etc.

No matter what you do, you should check out the licensing closely. Embedding someone else's code into yours often has repercussions on how you can license the resulting program.

Answer 7

It won't be quite all that you're asking for, but I depending on your needs, I would investigate Boo. It's relatively painless to build a DSL in Boo that is relatively readable to the business folks, which has great benefits even if they aren't the ones coding the rules directly.

Oren Eini's Building Domain Specific Languages in Boo is pretty good, and just came out in final form. A rules engine is one of the example implementations of a DSL that he examines. Boo is a fully-built statically typed Python-like language for .Net, with a small but strong community, and makes altering the language to suit specific needs easier than almost every other alternative, thanks to an extensible compiler pipeline and a very nice semantically-smart macro system.

The nice thing about Boo is that most DSLs are just built on a common base class that provides the "language" you need, but isn't much different than the code you'd be writing to hard-coded rules. You can make the language look exactly like you want, but won't have to worry about hand-parsing or writing control flow commands or all the stuff that you'd expect a language to have.

There are some downsides: It's not quite like Python or Ruby, the documentation is mostly in Boo's source code, and the community is, yes, small. But if you can "teach by example" you can get pretty far. The main caveat that applies to your wishlist is in code completion; code completion has limited support with some VS plugins and with SharpDevelop, but what is there pretty much evaporates as you build out the DSL.

Answer 8

Talking from experience, because our main software has a scripting feature.

We use the Actipro SyntaxEditor as our scripting designer. Our original requirement was to "The user shall be able to write a formula for a field. That formula will be used to validate the content of the field."

From that, we used Dynamic Linq. The user was able to write a formula while still being able to add mathematical functions and custom functions. We didn't need more at the time, but are now seeing limitation of using the Dynamic Linq.

If we are to make a new version of our scripting engine, we would now be looking forward to using the new DLR-enabled language: IronPython and IronRuby

Answer 9

Since .NET is your platform, embedding ironpython might work for you. In fact, the author of one of the ironpython books used ironpython in a product that seems to (on the surface) have a lot of similarities with what you're doing. I think it was called Resolver One.

Edit

It is called Resolver One

Here's a link to his book.

Answer 10

We currently use Mozilla's SpiderMonkey to do this exact thing in our web application. It is a javascript engine so you can create your own functions and objects that corresponds to actual business logic in your application. Javascript::SpiderMonkey is a perl module that interfaces but I believe there are more languages that work with it.

Answer 11

If the structure and rules are clearly understood, then I would mimic the Query interface that is contained in Lucene (java and .net). Basically, your rules become query types and you can and/or them together much in the same way that Lucene does it.

Lastly, you can then create an interface that allows your users to do this work. The critical piece will be the query types and the associated metadata that can serve as items upon which to be acted.

For example, say your rules engine was an ecommerce engine and you allow your users to define rules that will reward customers with a discount if they add a particular product to their basket.

They would pick a type of ProductQuery which matches on product number and then a successful completion of the productquery would result in a discountreward that is automatically applied.

Hope this helps.

Answer 12

As others have stated, LUA is a fairly quick and easy way to embed a scripting language inside your application. Our company's product has a macro feature, and I was briefly entertaining the idea of embedding full scripting support as part of it. But ultimately we decided trainign would be a nightmare.

Regardless, this is a pretty good introduction to embedded LUA in c# if you choose that route: http://blog.apterainc.com/software/embedding-lua-and-c/

Answer 13

Instead of an embeded scipting language, think of programing a graphical language or tool, if you can identify all the possible rules and map them to the appropiete code, You could offer to the end-user a simple & easy way to add behaviors & action to their workflow in a visual manner.

Offering a UI-based rule engine is more simple to learn & more convenient for non programmeurs. And you can always add an embeded scripting language, to customize the preexisting actions, latter.

Also, it's the common tool used in ETL for exemple, in order to create Business rules