This project is read-only.

slam.config Validation, Extensibility and GUI

Apr 3, 2009 at 9:31 AM
Hallo everybody,
As we are going to use SLAM! in the context of a more advanced, automated reporting service I have some questions concerning the validation, stability and extensibility of the slam.config file.

1. XSD 
Do you or does somebody else have an *.xsd file that could be used for formal validation of the slam.config file ?
When not, is the slam.config in its current and future releases VALID XML in a sense, that it can be interpreted and modified with any other XML compliant tool as well ?

2. EXTENSIBILITY 
Is it possible to extend the current slam.config with own nodes and attributes ? (I need them for some post-processing to be applied by our own tools on slammed lists/sql tables)  
When yes, are there some commun rules we should/must follow when extending slam.config to prevent SLAM! from crashing ?

3. GUI
Are there plans or does already somebody have a tool where the slam.config can be configured in a GUI ?

Thanks a lot for your feedback
kind regards
René
Developer
Apr 3, 2009 at 5:22 PM
1. It should be, but we have not created an xsd for validation.  This may be helpful but to us it is more important to do the "functional" validation, ensuring that what is claimed to exist in SharePoint in the slam.config actually exists, which in a sense does the format validation in doing so, in the SLAM Control Panel.
2. Yes.  Documentation for extensibility is on our to-do list, and the potential for extension is a big part of SLAM's functionality. 

You can customize the slam.config is a couple of different ways.  First, you can add extra attributes to a type (List or ContentType element) and use the DataMapping.GetTypeAttribute method (in AWS.SLAM.Configuration.DataMapping, accessible from the Configuration Manager) to retrieve them.  For illustration, get the source code and look in AWS.SLAM.Events.ContentTypeItemUpdater.  Near the top of the Update method is an example of using GetTypeAttribute, used in that case to get a default attribute available in other ways.  Second, you can also add extra sections to the slam.config.  For illustration, look at how AWS.SLAM.StructureMap is done.  Checking out the ComponentFactory, in its Initialize method it has:

IConfigurationManager configuration = ObjectFactory.GetInstance<IConfigurationManager>();
configuration.RegisterSection("TypeProfiles",
    config =>
    {
        object section = null;
        if (config is XDocument)
        {
            section = new XmlTypeProfileSection((XDocument)config);
        }
        return section;
     });

So as you can see the IConfigurationManager interface provides a RegisterSection method, it takes the name of the section (the element under <Configuration> defining your custom section) and a delegate that gets called whenever that section is retrieved from the Configruation Manager.  In this case when it calls configuration.GetSection<XmlTypeProfileSection>("TypeProfiles") the delegate defined above is called.  The reason for using this construct is that the input available, config, is an XDocument for the slam.config, which here is being passed into the section "controller" for the XmlTypeProfileSection.  The methods for retrieving the "TypeProfiles" section's settings are encapsulated in the XmlTypeProfileSection class but need not be.  The delegate defined on registration does need to return an object.  GetSection returns that object, because it is simply calling the registered delegate, which as you can see can be called as a generic or not.  And finally of course you can open the slam.config independently of any of this and read any information you want that you have added.  We still recommend using the hooks provided by the Configuration Manager.

All of this is applicable primarily in the context of a Type Profile.  Using a type profile you can take care of that post-processing you would like to do.  See the source code for the Hierarchy extension.  Hierarchy uses a Type Profile and does extra processing before or after the core SLAM processing.  The Hiearchy Profile source is a good starting point though it does not use custom attributes or extra config sections.

3. We plan, though not with a definite timeline, to create a GUI for configuration but one is not currently available.

If you would like our help creating a Type Profile and extending SLAM feel free to email slam@awsystems.com . 

Thanks,
-Brian
Apr 5, 2009 at 4:58 PM
I have drafted a first XSD.
Would be good if  SLAM! Developers might check and comment for complete- and correctness on actual and future SLAM! versions.
For most actual versions and future extensions we are using on our projects (GUI based slam.config XML Editor in the pipeline) send an e-mail to realB12[at]web.de

 

 

 

<?xml version="1.0" encoding="UTF-8"?>
<!--W3C Schema generated on April 5th, 2009 from the slam.config version 1.1.7 sample template on
     http://slam.codeplex.com/Wiki/View.aspx?title=config%20file&referringTitle=Getting%20Started
-->
<!-- First draft version 0.1, needs to be reviewed and confirmed by SLAM! Developers  -->
<!-- edited by René Baron at Baron Solutions, Technopark, 8005 Zurich, Switzerland -->
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
 <xs:element name="add">
  <xs:complexType>
   <xs:attribute name="Name" use="required">
    <xs:simpleType>
     <xs:restriction base="xs:string">
      <xs:enumeration value="SLAM"/>
     </xs:restriction>
    </xs:simpleType>
   </xs:attribute>
   <xs:attribute name="ConnectionString" type="xs:string" use="required">
    <xs:annotation>
     <xs:documentation>Exmaple for SQL Server: "Database=db;Data Source=server;User Id=user;Password=password"</xs:documentation>
    </xs:annotation>
   </xs:attribute>
  </xs:complexType>
 </xs:element>
 <xs:element name="List">
  <xs:complexType>
   <xs:sequence>
    <xs:element ref="Fields"/>
   </xs:sequence>
   <xs:attribute name="TableName">
    <xs:annotation>
     <xs:documentation>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.</xs:documentation>
    </xs:annotation>
   </xs:attribute>
   <xs:attribute name="ID" use="optional">
    <xs:annotation>
     <xs:documentation>For Lists, ID is the GUID ID of the list. It is irrelevant for Content Types.</xs:documentation>
    </xs:annotation>
    <xs:simpleType>
     <xs:restriction base="xs:string"/>
    </xs:simpleType>
   </xs:attribute>
   <xs:attribute name="Site" use="optional">
    <xs:annotation>
     <xs:documentation>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).</xs:documentation>
    </xs:annotation>
    <xs:simpleType>
     <xs:restriction base="xs:string">
      <xs:enumeration value="subsite"/>
     </xs:restriction>
    </xs:simpleType>
   </xs:attribute>
   <xs:attribute name="Name" use="required">
    <xs:annotation>
     <xs:documentation>For Lists, ID is the GUID ID of the list. It is irrelevant for Content Types.</xs:documentation>
    </xs:annotation>
    <xs:simpleType>
     <xs:restriction base="xs:string">
      <xs:enumeration value="List"/>
     </xs:restriction>
    </xs:simpleType>
   </xs:attribute>
   <xs:attribute name="ActivationOrder" use="optional">
    <xs:annotation>
     <xs:documentation>When SLAM is activated, it loads each type according to the ActivationOrder. If order does not matter, this can be the same value for each type. </xs:documentation>
    </xs:annotation>
    <xs:simpleType>
     <xs:restriction base="xs:byte">
      <xs:enumeration value="1"/>
     </xs:restriction>
    </xs:simpleType>
   </xs:attribute>
  </xs:complexType>
 </xs:element>
 <xs:element name="Fields">
  <xs:complexType>
   <xs:sequence>
    <xs:element ref="Field" maxOccurs="unbounded"/>
   </xs:sequence>
  </xs:complexType>
 </xs:element>
 <xs:element name="Field">
  <xs:complexType>
   <xs:attribute name="SqlType">
    <xs:annotation>
     <xs:documentation> This is the SQL datatype which the field should be stored as. This is used when SLAM is creating database columns</xs:documentation>
    </xs:annotation>
    <xs:simpleType>
     <xs:restriction base="xs:string">
      <xs:enumeration value="varchar(255)"/>
     </xs:restriction>
    </xs:simpleType>
   </xs:attribute>
   <xs:attribute name="SPType" use="required">
    <xs:annotation>
     <xs:documentation>The equivalent of the SPFieldType of the Field in SharePoint</xs:documentation>
    </xs:annotation>
    <xs:simpleType>
     <xs:restriction base="xs:string">
      <xs:enumeration value="Lookup"/>
      <xs:enumeration value="Text"/>
     </xs:restriction>
    </xs:simpleType>
   </xs:attribute>
   <xs:attribute name="Required" type="xs:boolean">
    <xs:annotation>
     <xs:documentation>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</xs:documentation>
    </xs:annotation>
   </xs:attribute>
   <xs:attribute name="Name" use="required">
    <xs:annotation>
     <xs:documentation>display name or inner name of the Field in SharePoint</xs:documentation>
    </xs:annotation>
    <xs:simpleType>
     <xs:restriction base="xs:string">
      <xs:enumeration value="ListLookup"/>
      <xs:enumeration value="OtherListLookup"/>
      <xs:enumeration value="Title"/>
     </xs:restriction>
    </xs:simpleType>
   </xs:attribute>
   <xs:attribute name="AssociationName">
    <xs:annotation>
     <xs:documentation>The presence of this attribute defines a Field as one that establishes an association. This is the name given to that association</xs:documentation>
    </xs:annotation>
    <xs:simpleType>
     <xs:restriction base="xs:string">
      <xs:enumeration value="ContentTypeToList"/>
      <xs:enumeration value="ListToOtherList"/>
     </xs:restriction>
    </xs:simpleType>
   </xs:attribute>
   <xs:attribute name="AssociatedList">
    <xs:annotation>
     <xs:documentation>This is the name of List, treated as a "type name", to which the containing type is being associated by this association field.
</xs:documentation>
    </xs:annotation>
    <xs:simpleType>
     <xs:restriction base="xs:string">
      <xs:enumeration value="List"/>
      <xs:enumeration value="OtherList"/>
     </xs:restriction>
    </xs:simpleType>
   </xs:attribute>
  </xs:complexType>
 </xs:element>
 <xs:element name="DataMapping">
  <xs:complexType>
   <xs:sequence>
    <xs:element ref="List"/>
    <xs:element ref="ContentType"/>
   </xs:sequence>
   <xs:attribute name="DataSchema" use="required">
    <xs:simpleType>
     <xs:restriction base="xs:string">
      <xs:enumeration value="SLAM"/>
     </xs:restriction>
    </xs:simpleType>
   </xs:attribute>
  </xs:complexType>
 </xs:element>
 <xs:element name="ContentType">
  <xs:complexType>
   <xs:sequence>
    <xs:element ref="Fields"/>
   </xs:sequence>
   <xs:attribute name="Name" use="required">
    <xs:simpleType>
     <xs:restriction base="xs:string">
      <xs:enumeration value="ContentType"/>
     </xs:restriction>
    </xs:simpleType>
   </xs:attribute>
   <xs:attribute name="ActivationOrder" use="required">
    <xs:simpleType>
     <xs:restriction base="xs:byte">
      <xs:enumeration value="2"/>
     </xs:restriction>
    </xs:simpleType>
   </xs:attribute>
  </xs:complexType>
 </xs:element>
 <xs:element name="ConnectionStrings">
  <xs:complexType>
   <xs:sequence>
    <xs:element ref="add"/>
   </xs:sequence>
   <xs:attribute name="Default" use="required">
    <xs:simpleType>
     <xs:restriction base="xs:string">
      <xs:enumeration value="SLAM"/>
     </xs:restriction>
    </xs:simpleType>
   </xs:attribute>
  </xs:complexType>
 </xs:element>
 <xs:element name="Configuration">
  <xs:annotation>
   <xs:documentation>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.
DataMapping is the focus of the SLAM configuration however. The Lists and Content Types that SLAM should manage are defined in the 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 DataMapping</xs:documentation>
  </xs:annotation>
  <xs:complexType>
   <xs:sequence>
    <xs:element ref="ConnectionStrings"/>
    <xs:element ref="DataMapping"/>
   </xs:sequence>
  </xs:complexType>
 </xs:element>
</xs:schema>

 

Developer
Apr 6, 2009 at 1:53 AM
Thanks for this XSD!  We are actually about to release a new version (1.2) that will allow SLAM to be used across many site collections.  This will slightly affect the XSD here but not by much (basically the config can contain multiple DataMapping sections with the new release at a DataMapping node can contain a SiteCollection attribute).  I will check out the XSD in detail soon and maybe incorporate changes into for 1.2, which will be released early this week. 

Thanks again,
-Brian
Apr 6, 2009 at 6:25 AM
Maybe it will be better that I will generate a new XSD from the version 1.2 release before going into deteails with the current one.
So what I need for this, is a slam.config example that contains ALL possible nodes and attributes and a crisp description about which of these are optional and which are mandatory.
Thanks a lot for your feedback
Rene