Configuration

From SharemailWiki

Almost all the java that is invoked when the DRRE runs consists of java beans configured using a traditional-style spring configuration file. Since the DRRE is desinged as a mutli-purpose application, annotations are not used for configurations. There are some helper beans that are loaded directly within code as new objects. The most important of these is a helper bean that provides additional functionality to drools rulesets, but even this has has access to the Spring application context via a static object.

Contents 1 Boilerplate beans 2 Mule transformer beans 3 Client adaptor beans 4 Core beans 5 Server adaptor beans 6 Drools beans 7 Helper beans 8 Helper classes 9 Sample configurations 10 Grouper integration sample configurations

Boilerplate beans

These include a few beans to wire Mule to a Spring application context. For example, raising Mule events through the Spring event system is managed by a boilerplate bean.

Mule transformer beans

These are needed when a Mule interface is used and are coded as extensions and implementations of Mule classes and interfaces. For example there is a transformer to convert a delimited text file into a List of String arrays. A more complicated transformer is that which accepts an incoming DSML request over a Mule HTTP interfaces, processes it through the DRRE and returns a result code to the client. Some Mule interfaces also require Mule-specific configuration (e.g. writing to a text file)

Client adaptor beans

At least one these is required in a DRRE configuration in order to input sata into it. A client can either be a listener process (such as an HTTP listener), normally using a Mule interface; or a polling process. Clients are responsible for loading incomgin data into dynamically created data-bearing java beans. The configuration of a client interface bean therefore includes the definition of the data-bearing bean.

Core beans

These route the data-bearing beans sent from client adaptors, sending them to one or more server adaptors in turn.

Server adaptor beans

These are responsible for sending data to its destination and returning any result codes to the core bean, which returns them to client adaptor bean. Server adaptors can be Mule provided, or custom. LDAP, DSML, JDBC and Grouper adaptors are examples of custom server adaptor beans.

Drools beans

These load Drools rulesets from decision tables into memory, making them available to any client or server adaptor bean to use them to process data-bearing beans

Helper beans

These include beans that help other beans fulfil their functions. For example, helper beans exist that build LDAP commands, manage LDAP connections pools, and manage database connection pool

Helper classes

These are not configured as Spring beans, such as the DroolsDecisionTableHelper class which is intended to be instantiated within functions embedded in a Drools ruleset, thus providing additional functionality to them.

Sample configurations

Here are some sample configurations, in order of complexity. The best approach to building a configuration is to use one with a similar purpose as an example and go from there.

• File to File
• LDAP to file (unboundID LDAP)
• File to LDAP (JLDAP)
• File to LDAP (unboundID LDAP)
• File to Database
• Database to file
• Database to LDAP
• Database to Database
• File to matching database only
• File to database with matching

Grouper integration sample configurations

I've contributed some code to the Internet2 Grouper project to enable events to be pushed to an ESB-type service (such as the DRRE). These example configurations illustrate how to populate groups in a LDAP directory in near-real time on an event-driven basis.

• Grouper to OpenLDAP
• Grouper to Novell eDirectory
• Grouper to Novell eDirectory with Stems