SLAM Architecture

SLAM was designed to be a modular product, and is split into 9 atomic components. All the parts work through dependency injection (DI). Our default implementation of DI uses Structure Map. However, we designed SLAM such that if you have a favorite implementation of DI, you should be able to swap it out pretty painlessly. The goal in this architecture is that any one of these parts can be swapped out if you so desire, so long as you implement the proper methods. The components are:

Data Services
Data Services is the layer that interacts with the external data source. In the default SLAM implementation, it uses connections to a SQL Database. If, for example, you want SLAM to write to an Oracle database or an XML file, this is the layer that you'd change.

Configuration Manager
The configuration manager provides an interface with the config file. It defines what you can get from the configuration. For example, what content types are defined for SLAM and what fields for those content types. It acts as the point of access for all interaction with SLAM.

Down the road, we plan on using the configuration manager to handle programmatic changes to the SLAM config. For the time being, all changes to the SLAM config have to be done manually.

Updater
The updater, quite literally, provides the interface for all updates. When the item updated event handler in SharePoint runs, the "update" method in the updater is called.

In the current implementation of SLAM, Updater then calls Data Services to update items in the external data source.

Deleter
The Deleter provides the interface for all deletions through SLAM. When the item deleted event fires in SharePoint, the "delete" method in the Deleter is called.

In the default implementation of SLAM, the Deleter calls Data Services to delete the item from the external data source.

Creator
Provides the interface for creating things through SLAM. When the item created event handler fires in SharePoint, it calls the "create" method of the Creator.

In the current implementation of SLAM, the creator then calls Data Services to create the item in the external data source.

Data Synchronizer
Responsible for resynching data between SharePoint and the external data source. Currently, it runs on activation of SLAM and whenever there's a need to do a data load from SharePoint to the external data source.

For example, if you have an existing SharePoint site with data that you want to attached SLAM to, you would use the data loader, which will use the data synchronizer layer to perform an initial SLAM of data to the external data source.

Sync Type Processor
Used on sync (see Data Synchronizer). It's passed the types by the Data Synchronizer and processes each type based on its type.

Activator
Called upon during activation and deactivation of the SLAM feature.

On activation, the default behavior is to look at the config, set up appropriate event handlers and attach to the appropriate lists and content types. After all that is complete, it runs the data synchronizer.

On deactivation, it detaches the event handlers.

Logger
Logs messages, errors and events to a log source. By default, it uses two tables in the SLAM database - one for events and the other for messages and errors.