SLAM XML Configuration

By default SLAM uses an XML Configuration file. SLAM looks in the root of the AppDomain, such as a SharePoint virtual directory or an executing location for a console/windows application, in which it is running for a slam.config file. This can be changed by
setting the appSetting "AWS.SLAM.ConfigurationManager.Config" to contain a physical path to a specific, valid, SLAM configuration XML file, for example "C:\myslamconfig.xml". A basic SLAM configuration looks something like this:

The SLAM configuration contains two main sections, ConnectionStrings and DataMapping.
ConnectionStrings defines those SQL Server connection strings SLAM will use by default. The Default attribute defines precisely that by Name as seen here with "SLAM" being the default connection string.
The DataMappings are the focus of the SLAM configuration however. The Lists and Content Types that SLAM should manage are defined in a DataMapping. For each of these a set of Fields is defined, then each Field that should be mapped from SharePoint to the SLAM
database. The example describes the nodes used in the default DataMapping.

With the release of version 1.3 different site collections can synchronize with different databases. Each DataMapping section can specify a ConnectionString to use by name as defined in the ConnectionStrings section. If no ConnectionString attribute
is present in the DataMapping node the default connection string is used.

With the release of version 1.2 SLAM works across multiple site collections. The SLAM configuration can have many DataMapping sections which configure Content Types and Lists to be managed by SLAM. Each DataMapping corresponds to a different site collection.
If the SiteCollection attribute of a DataMapping element is missing or blank then that DataMapping is used to configure types and fields in the root site collection.

Each node has the following attributes:

List and Content Type

Name - This is the name of the List or Content Type in SharePoint.

ID - For Lists, ID is the GUID ID of the list. It is irrelevant for Content Types.

Site - The Name of the subsite (web), if applicable, in which the List or Content Type exists in SharePoint. This name takes the form like "MySubsite/MysubsubSite". If left out or blank SLAM looks in the Root site (web).

TableName - This is an optional attribute for giving SLAM an alternative name to give the table it creates for a type. For example, a configuration may define two lists with the same name in different Sites and different IDs to be managed by SLAM. These
two lists might need "slammed" to separate tables.

ActivationOrder - When SLAM is activated, it loads each type according to the ActivationOrder. This order matters due to the manifestation of association foreign key constraints in the database. Types that do not have associations should be processed first,
followed by relevant types with already-processed associated types, etc.

Field

Name - This is the display name or inner name of the Field in SharePoint.

SqlType - This is the SQL datatype which the field should be stored as. This is used when SLAM is creating database columns.

SPType - The equivalent of the SPFieldType of the Field in SharePoint.

Required - Indicates whether SLAM should create the Field's column as allowing nulls or not. This value should correspond with the Field's Required flag in SharePoint. If the Field is an association, when Required is set and AssociationTableName
is not set, the foreign key column is constrained.

AssociationTableName - If an association is to manifest in the SLAM SQL database as an association table, this attribute specifies the name of that table. If AssociatedTypeName is defined but AssociationTableName is missing, the association is saved a column
with a foreign key relation to the table corresponding to the AssociatedTypeName.

AssociatedTypeName - The presence of this attribute defines a Field as one that establishes an association. This is the name of configured Type to which the containing type is being associated by this association field. To SLAM an association, a lookup
field, the related List must also be slammed, whether configured by single List or ContentType that would include that List.

With the release of version 2.0 for SharePoint 2010, new options for allowing SLAM to process items synchronously and defining item identifiers. Here is an example of a slam.config utilizing these new features:

The significant differences in this configuration relate to these nodes:

TypeIdDefinitions - TypeIdDefinitions is the section where SLAM IDs can be configured.

The first example defines the following: the SLAM ID field will manifest in the database as a primary key column called {TypeName}ID, like OtherListID, with a datatype of varchar(25), it will "replace" the SharePoint IDs such that ListItemID and
ListRelativeID will not be slammed when types using this ID are saved, and the values of the column will be hexadecimal numbers.

The second example is just like the first example except the "SLAM ID" column does not "replace" the SharePoint ID columns. Because it is still set as the Primary Key, the {TypeName}ID column will be a primary key, but ListItemID and
ListRelativeID will be slammed when types using this ID are saved.

DataMapping additions

SynchronousUpdates - When present and set to True, upon activation SLAM will provision a SLAM ID field for all configured types in the DataMapping that do not themselves contain the attribute and value SynchronousUpdates="False", and the SLAM
process will be performed by the SLAM ID field.

TypeIdDefinition - When present and set to the name of a TypeIdDefinition defined in the TypeIdDefinitions section, that mapped TypeIdDefinition will apply to configured types in the DataMapping that do not themselves contain the attribute TypeIdDefinition.

Some of the internal field names in SharePoint will have codes in. For instance, spaces are replaced with "_x0020_" so a field called "My First Toy" is referenced internally as "My_x0020_First_x0020_Toy". Internal field names in SharePoint also have a limit of 32 characters so they can get truncated.

You use the COLUMN attribute to specify an alternative, more friendly, name to be used in the SQL table. In the example above, you could use COLUMN="MyFirstToy" to make the column name in SQL a little more friendly. In this case the line would look like:

In some examples in the Discussion board there is an additional Field Attribute "Column" used as follows:<Fields> <Field Name="Account" Column="UserName" SqlType="varchar(255)" SPType="Text" Required="true"></Field> <Field Name="Title" Column="Name" SqlType="varchar(255)" SPType="Text" Required="false"></Field> <Field Name="E-Mail" Column="E-Mail" SqlType="varchar(255)" SPType="Text" Required="false"></Field> </Fields>Is this some kind of internal stuff or is "Column" missing in the description above ? When yes - what is the meaning of "Column" ?