As I mentioned last time, this subject of this post will be wiring up all the Modeling Services “architectural plumbing” to enable the Contoso business rule repository to enjoy all the goodness that Modeling Services has to offer.

In the current Modeling Services CTP the Repository is implemented as a sophisticated SQL Server database. As one would expect, wiring up the Modeling Services architectural plumbing consists of leveraging/altering a number of database objects (e.g., stored procedures, tables, views, etc) within the Repository. As Modeling Services is built on the SQL Server platform, all of this wiring can be accomplished using T-SQL. However, in this post we will leverage a handy add-on to Modeling Services that greatly reduces the learning curve involved with wiring up a custom model in the Repository – the PatternApplication Sample.

 

PatternApplication Setup

The bits for the PatternApplication Sample are available here. MSDN provides great instructions on how to install the PatternApplication Sample, so I won’t waste space repeating them here.

The sample code used in this series will assume that both the PatternApplication.dll and PatternApplication.mx files are located at the Modeling Services default install location of “C:\Program Files\Microsoft Oslo\1.0\bin\”. If the sample code is used as-is, then these files will need to be copied/moved to this location.

For the remainder of this series I we will be assuming that Visual Studio 2010 Beta 2 is development environment for the Contoso business rule repository, although Intellipad could also be used as well.

<Author’s Note>For the sake of brevity, I will assume that the reader is quite familiar using Visual Studio. As such, I will not be providing detailed step-by-step instructions for the VS activities.</Author’s Note>

Here are the basic steps for setting up the VS project:

  1. Create a C# Oslo Library project called “RulesModel”. Here’s a screenshot of the VS UI:

    VSProj1  

  2. Add References to the “Repository.dll” and “PatternApplication.dll” assemblies to the project. Here’s a screenshot of the VS UI:

    VSProj2

  3. Add the ‘M’ files for Contoso’s business rule model to the project. Here’s a screenshot:

VSProj3

 

Pattern Declarations

The PatternApplication Sample provides a declarative method for wiring up Modeling Services architectural plumbing to a model using ‘M’ code. The ‘M’ code provides metadata regarding what exactly needs to be wired for the model and this metadata is subsequently leveraged by a PatternApplication stored procedure to perform the wiring. A new ‘M’ file will be needed in the project to declare this metadata:

  1. Add a new item to the RulesModel project of type “’M’ Model Data”. Name this file “PatternApplication.m” and click the “Add” button.
  2. In the “Entity Data Model Wizard” dialog select the “Default model” option and click “Finish”.
  3. Delete all of the default ‘M’ code from the PatternApplication.m file.

 

As the structures that define the wiring metadata are declared in the PatternApplication module, and this metadata will be declared for the structures in the RuleModel module, the following ‘M’ code is the first to be added to the PatternApplication.m file:

   1: module PatternApplication
   2: {
   3:     import RulesModel;
   4: }

 

Next, metadata is declared regarding the RulesModel module:

   1: module PatternApplication
   2: {
   3:     import RulesModel;
   4:  
   5:     ModulePatternApplications
   6:     {
   7:         RulesModel_Pattern
   8:         {
   9:             Module => about(RulesModel.RulesTable).Declaration.DefinedIn,
  10:             Pattern => { Patterns.AlterSchemaPermissions}
  11:         }
  12:     }
  13: }

The metadata above declares that the SQL Server RulesModel schema, which will be created based on the ‘M’ RulesModel module, should have its SQL Server permissions altered in accordance with Modeling Services patterns. This ensures that the RulesModel schema will adhere to the Modeling Services Security architecture.

 

Once metadata is declared for the RulesModel module, declarations are added for the Operator extent:

   1: module PatternApplication
   2: {
   3:     import RulesModel;
   4:  
   5:     ModulePatternApplications
   6:     {
   7:         RulesModel_Pattern
   8:         {
   9:             Module => about(RulesModel.RulesTable).Declaration.DefinedIn,
  10:             Pattern => {Patterns.AlterSchemaPermissions}
  11:         }
  12:     }
  13:  
  14:     EntityPatternApplications
  15:     {
  16:         Operator_Pattern
  17:         {
  18:             Module => about(RulesModel.OperatorsTable).Declaration.DefinedIn,
  19:             Extent => about(RulesModel.OperatorsTable).Declaration,
  20:             Pattern =>
  21:             {
  22:                 Patterns.AddViewsInsteadOfTriggers,
  23:                 Patterns.AddFolderForeignKey,
  24:                 Patterns.AddAuditing,
  25:                 Patterns.AddChangeTracking
  26:             }
  27:         }
  28:     }
  29: }

The metadata above specifies that the OperatorsTable extent of the RulesModel module will be wired to support the following four Modeling Services patterns:

  1. AddViewsInsteadOfTriggers – As discussed last time, the Modeling Services Security architecture leverages SQL Server Views. In particular, I noted that Modeling Services relies on convention over configuration when it comes to the naming of extents (Tables) and computed values (Views) as part of the Modeling Services design patterns. This metadata declaration ensures that Modeling Services “InsteadOf” triggers will be added to a SQL Server view named “Operators” in accordance with the Modeling Services Security design patterns.
  2. AddFolderForeignKey – This metadata declaration ensures that a SQL Server foreign key constraint is applied to the “OperatorsTable” table, constraining the table’s “Folders” column with respect to the foreign “FoldersTable” table. Specifically, this patterns assumes the convention of an attribute named “Folders” of type “FoldersTable” exists within the extent. This pattern is required to leverage Modeling Services support for using Folders to provide Security and Segmentation for Contoso’s business rule repository.
  3. AddAuditing – This pattern ensures that the extent will have Auditing services enabled within the Repository.
  4. AddChangeTracking – This pattern ensures that the extent will have Change Tracking services enabled within the Repository.

 

The use of the PatternApplication Sample is another example of Modeling Service’s productive “plug and chug” development paradigm. The following code snippet illustrates this by adding pattern metadata declarations for the Proposition extent:

   1: module PatternApplication
   2: {
   3:     import RulesModel;
   4:  
   5:     ModulePatternApplications
   6:     {
   7:         RulesModel_Pattern
   8:         {
   9:             Module => about(RulesModel.RulesTable).Declaration.DefinedIn,
  10:             Pattern => {Patterns.AlterSchemaPermissions}
  11:         }
  12:     }
  13:  
  14:     EntityPatternApplications
  15:     {
  16:         Operator_Pattern
  17:         {
  18:             Module => about(RulesModel.OperatorsTable).Declaration.DefinedIn,
  19:             Extent => about(RulesModel.OperatorsTable).Declaration,
  20:             Pattern =>
  21:             {
  22:                 Patterns.AddViewsInsteadOfTriggers,
  23:                 Patterns.AddFolderForeignKey,
  24:                 Patterns.AddAuditing,
  25:                 Patterns.AddChangeTracking
  26:             }
  27:         },
  28:  
  29:         Proposition_Pattern
  30:         {
  31:             Module => about(RulesModel.PropositionsTable).Declaration.DefinedIn,
  32:             Extent => about(RulesModel.PropositionsTable).Declaration,
  33:             Pattern =>
  34:             {
  35:                 Patterns.AddViewsInsteadOfTriggers,
  36:                 Patterns.AddFolderForeignKey,
  37:                 Patterns.AddAuditing,
  38:                 Patterns.AddChangeTracking
  39:             }
  40:         }
  41:     }
  42: }

Given this “plug an chug” paradigm, I won’t take the time here to illustrate the metadata declarations for the remaining RulesModel extents. For those interested readers a link to the Visual Studio solution is provided at the bottom of this post.

 

Next Time

At this stage of development Contoso’s model for business rules is ready for deployment into the Modeling Services Repository. The subject of the next post will be adding the required steps necessary to deploy and wire Contoso’s business rule repository in SQL Server.

 

SkyDrive Files