Blum Shapiro Consulting Blogs
Skip navigation links
Back to BlumShapiro
Matthew Rankin
Skip Navigation Links
Michael C Pelletier
Brian Berry
Donald Poggio
Matthew Rankin
Blum Shapiro Consulting Blogs
 
 

Welcome to Blum Shapiro Consulting and our blogs.  To read posts from an individual blog select a link from the left.  Otherwise, the Recent Posts list below is an aggregation of posts from all our consulting employees.

 

 Recent Posts

 

I had a request from a client last week which I thought was worth sharing. Essentially, the data stewards would like the technology team to set an attribute for over 2000 customer accounts programmatically, as well as recording an annotation on the master data stating the rationale and authorization for the change.

 

If you have worked with SQL Server Master Data Services, you are aware that Members carry a list of Annotations.  These are typically Notes fields – used by Data Stewards to record anomalies or idiosyncrasies about the data, and record them so that the group can retain that information.  Unlike members, attributes or relationships, they cannot be set in a bulk manner by using the Data Import functionality.  Check out this blog for more details on how the Master Data Services Data Import functionality works: http://sqlblog.com/blogs/mds_team/archive/2010/02/10/Importing-Data-by-Using-the-Staging-Process.aspx

 

My first thought was to use the Master Data Services WCF API to record a standard annotation to all Members in a  list of Members.  What I discovered is that annotations are always written one member at a time.  This code snippet demonstrates what a WCF call would look like in this scenario.  Notice that you can write a list of Annotations, but to only one member per call.

 

// MDS is prefix for Service Proxy

// set the identifiers for the call

MDS.Identifier ModelId = new MDS.Identifier { Name = CORE_MODEL };
MDS.Identifier EntityId = new MDS.Identifier() {  Name = entityName };
MDS.Identifier VersionId = new MDS.Identifier() { Name = CORE_VERSION};
MDS.MemberIdentifier MemberId = new MDS.MemberIdentifier() { Code = code };

// create a list of annotations

List<MDS.Annotation> annotations = new List<MDS.Annotation>();
MDS.Annotation a = new MDS.Annotation();
a.Comment = comment;
annotations.Add(a);

// write the annotations

MDS.OperationResult opResult = Proxy.EntityMemberAnnotationsCreate(International, annotations, EntityId, MemberId, ModelId, VersionId);

 

While possible, this solution was very unattractive because of the expensive nature of a WCF call: over 2000 WCF operations in quick succession seemed a poor solution.

 

Microsoft recommends that customers avoid calling stored procedures or functions directly in the hub, and generally speaking I agree with this approach. But here I am making an exception.  When I took a look under the hood, I saw that there was a stored procedure named mdm.uspAnnotationSave which seemed to fit the bill.

 

In the end, I developed this SQL script to apply annotations on the back end.  The idea is that we can make the desired changes using the out-of-the-box Data Import process.  Once  the batch has been processed, a Batch ID has been generated in mdm.tblStgBatch, and that Batch ID is recorded on each staged record.  Using that, we can get a set of members which were updated as a result of the batch, and using a simple cursor, record a standard annotation to each record.

 

Note that you do need to get the MemberId value in order to call the stored procedure – the code itself will not work.  Why? Because the MemberId is version specific and the code is unique to the version.  The annotation is made a discrete version of the master data.

 

Here is the SQL script:


DECLARE @BatchID int
DECLARE @ErrorCode nvarchar(15)

DECLARE @ModelName nvarchar(50)
DECLARE @EntityName nvarchar(50)
DECLARE @VersionName nvarchar(255)
DECLARE @MemberCode nvarchar(255)
DECLARE @UserName nvarchar(255)

DECLARE @RC int
DECLARE @UserID int
DECLARE @AnnotationID int
DECLARE @VersionID int
DECLARE @EntityID int
DECLARE @MemberID int
DECLARE @MemberTypeID int
DECLARE @TransactionID int
DECLARE @Comment nvarchar(500)

 

/* The Batch to use as a source */
SET @BatchID = 9315

/* User Name */
SET @UserName = 'BLUM\bberry'

/* The Annotation to write */
SET @Comment = 'Annotation with SQL'

 

SELECT @UserID = mdm.tblUser.ID
From mdm.tblUser
Where mdm.tblUser.UserName = @UserName

if @UserID is null
begin
print 'Unknown User: ' + @UserName
return
end

print 'UserId: ' + convert(nvarchar(255),@UserId)

 

/* GET SUCCESSFULLY PROCESSED MEMBERS IN A BATCH */
SET @ErrorCode = 'ERR210007'

SELECT @VersionID = Version_ID
From mdm.tblStgBatch
Where ID = @BatchID

if @VersionID is null
begin
print 'Unknown Version'
return
end

print 'VersonId: ' + convert(nvarchar(255),@VersionId)

 

DECLARE Member_Cursor Cursor for (
select MemberCode, MemberType_ID, EntityName from mdm.tblStgMember
Where Batch_ID = @BatchID
AND ErrorCode = @ErrorCode
UNION
Select MemberCode, MemberType_ID, EntityName From mdm.tblStgMemberAttribute
Where Batch_ID = @BatchID
AND ErrorCode = @ErrorCode
UNION
Select MemberCode, MemberType_ID, EntityName From mdm.tblStgRelationship
Where Batch_ID = @BatchID
AND ErrorCode = @ErrorCode)

OPEN Member_Cursor

/* Member Code to Annotate */
FETCH NEXT FROM Member_Cursor into @MemberCode, @MemberTypeID, @EntityName
while @@FETCH_STATUS = 0
Begin

    print 'EntityName: ' + convert(nvarchar(255),@EntityName)
   
    /* GET SYSTEM IDs FOR ENTITY, VERSION, USER */
    SELECT @EntityID = mdm.tblEntity.Id
    From mdm.tblEntity
        INNER JOIN mdm.tblModelVersion ON mdm.tblEntity.Model_ID = mdm.tblModelVersion.Model_ID
    Where mdm.tblEntity.Name = @EntityName
        AND mdm.tblModelVersion.ID = @VersionID

    if @EntityId is null
    begin
        print 'Unknown Entity '
        return
    end

    print 'EntityId: ' + convert(nvarchar(255),@EntityId)
    print 'Member Type: ' + convert(nvarchar(255),@MemberTypeID)
    print 'Member Code: ' + convert(nvarchar(255),@MemberCode)
   
    EXECUTE @RC = [mdm].[udpMemberIDGetByCode]
       @VersionID
      ,@EntityID
      ,@MemberCode
      ,@MemberTypeID
      ,@MemberID OUTPUT
      ,@IsActive=0

    if (@MemberID is null) OR (@MemberID =0)
    begin
        print 'Unknown Member Code: ' + @MemberCode
        return
    end

    print 'MemberID: ' + convert(nvarchar(255),@MemberID)

    EXECUTE @RC = [mdm].[udpAnnotationSave]
       @UserID
      ,@AnnotationID
      ,@VersionID
      ,@EntityID
      ,@MemberID
      ,@MemberTypeID
      ,@TransactionID
      ,@Comment
 
  FETCH NEXT FROM Member_Cursor into @MemberCode, @MemberTypeID, @EntityName
 
End

 

An firm understanding of Data Stewardship Best Practices is becoming a significant element to successful MDM.  Enrichment of Master Data can take many forms: metadata management, annotations, etc.  Make sure your technology team remains responsive to the business as they grapple with data quality issues.  Providing automation services on demand, such as this, can be a big help.

 

Good luck!

SQL Server Master Data Services provides a rich security model for authorizing discrete access to the Master Data Hub.  I believe strongly that Master Data should be widely visible to the broadest possible audience.  Unless your organization is subject to regulatory compliance which restricts one business unit from viewing customer information in another business unit, I advise that your hand picked Data Stewards be responsible for as much Master Data governance as is prudent, and certainly access to everything.

 

Having said that, some organizations are “not there yet”.  While they recognize the value of federating their customer master into a single hub, they have appointed some Data Stewards management responsibility for some of the attributes in the customer master, or even some of the customers.  To accomplish this, we need to do more than grant access to the entire data model.

 

If you want to deliver member level access to a master data entity (i.e. row level security), you will need to do so my securing a Derived Hierarchy which includes the entity to be secured.

 

As an example, let’s say that you have a customer entity.  The customer members are all accounts from several business units.  Let’s say that you have one group of users who work for one of the business units and are responsible for managing only those business unit accounts.

 

If you have a domain based attribute on the customer account named “Business Unit” which refers to an entity named “Business Unit”, then you only need to create a Derived Hierarchy named “Customer Accounts By Business Unit” and include the Customer and Business Unit Entities.

 

Once this is done, you can grant access along any path within this hierarchy.  For a given windows group, you may grant read access to the root of the hierarchy, then override  this with an update permission to a particular business unit.

The first question to be asked in any Master Data Management project is: Where is my Master Data? The prevailing assumption seems to be that master data lives in an ERP table called "the Customer Master" or "the Item Master" for example. From here, project stakeholders focus intensely upon making the ERP data complete, aligned and in-sync. These analyses are all valid and important.

 

But consider the analytical side of MDM: analytical databases provide the ability to aggregate and roll-up similar entities, or concepts. Therefore, reporting systems (OLAP or Business Intelligence systems) need and thrive upon data consolidation concepts – roll-ups, hierarchies, collections of master data which can be used to construct dimensional analysis.

 

For example, a customer may be a stand-alone business, but more often a place of business is owned by a legal entity. Credit Analysts want to see the total credit being extended to a business, not simply a customer. In manufacturing, the phrase "chain" is common to describe essentially a collection or consolidation of customers. In order to provide intelligent customer chaining, the master data needs to include these kinds of "sibling" relationships.

 

Some ERP systems do this well, and therefore are able to offer analysts a tightly integrated Business Intelligence experience over the ERP data. But no matter what your ERP system, this approach assumes that the enterprise is under a single ERP; indeed, this is rarely the case. If you are an organization which has grown by mergers and acquisition, you may have dozens of ERP systems in the enterprise, at varying levels of capability. Those that do have BI capabilities often promote a fairly rigid, out-of-the-box solution to hierarchy management, incompatible with other systems.

 

So what happens? These consolidations become mappings tables in Excel and Access applications and analysts continually scramble to keep their version of this institutional data up to date. These common data assets are essentially "living on the streets" – not inside an ERP system and not inside an MDM solution. And the astonishing thing here is: this data is highly valuable master data. Without it, the enterprise continually struggles achieving simple and reasonable Business Intelligence goals.

 

It's this recognition, I believe, which has driven Microsoft in SQL Server 2012 to deliver an Excel 2010 Add-In for Master Data Services. This add-in should help ease the transition for analysts and Information Workers who have taken the homeless data in. Master Data Services provides a full-featured MDM home.

SQL Server 2012 – formerly known as "Denali" – will be available March 7, 2012. My colleagues at Blum Shapiro have been participating in private technical sessions with the SQL Server team over the past 6 weeks to learn of the many improvements. Today, I want to share some details on what you can expect with regards to Master Data Services.

 

Silverlight to the Rescue

We've been working with Master Data Services since the release of SQL Server 2008 R2. No question that it is a flexible Master Data Management platform, but those of you who work extensively with the product are aware that the Master Data Portal, the primary way for Data Stewards to interact with the master data, has a very unfriendly user interface. In 2012, the data entry grids are all Silverlight based. This makes for a much improved experience for both filter and CRUD operations.

 

This is what the Explorer View looks like in the Master Data Portal. Note the improved Record Detail interface to the right.

 

Excel – the Microsoft BI Swiss Army Knife

Microsoft loves to extend the usability of Excel. No surprise then that 2012 includes an Excel Add-In for Master Data Services. Authorized users can insert, edit and delete master data records within Excel. Even better, data administrators can create entities and attributes directly in Excel! This is a huge benefit to MDS model builders who need to quickly get new master data entities created in Master Data Services. Simply select the data you want to import into your model and click Create Entity.

 

 

 

The thing that interests me most about the two improvements is that it seems to be highlighting the focus that Microsoft has on Master Data in the hands of Information Workers. For most of my MDM clients, Master Data can be found mostly in Business Systems, not on a file share. I think the question Microsoft is posing here is: are you sure you know where your master data is created? This is a challenging question for many organizations.

 

These are just two. Next time around we'll talk about the improved Staging infrastructure.

In SQL Server 2008 R2 Master Data Services, one of the first design decisions you will need to explore is: How will we uniquely identify a master data record? In MDS, each member has a Name and a Code. You cannot remove either of these attributes, alter their data type, or alter their length: they are not User Defined Attributes. The Code attribute is always required and always unique for the member. Therefore, the "primary key" column for your master data is always Code.

In many cases, you may wish to have this Primary Key attribute be an auto-generated number, just like the familiar IDENTITY concept in SQL Server databases. This design decision avoids having perform in-depth data profiling to figure out of there is a more natural unique identifier (i.e. DUNS number for customer, UPC for Product or SSN for Person) which could be used. However, the correct way to do this is obscure and difficult to glean for 3 reasons:

  1. You cannot change the data type for Code in the System Administration area of the MDS Stewardship Portal
  2. When creating an Entity Member in the WCF layer, you are required to submit a Member Code or the operation will fail
  3. When Bulk Loading Members into the MDS Hub, you are required to provide a Member Code for members in the tblStgMembers table

I list these three items for a simple reason: cumulatively, they had convinced me that you could not auto-generate a Member Code in MDS. Indeed, I have stated repeatedly that this was the case, both to colleagues and innocent user group presentation audiences. Mea Culpa! There is a way.

First, you need to create a business rule which performs the auto-generation process. MDS provides an action in the business rules designer for this purpose.

You will need to drag the Code attribute from the Member Attributes list to the "Select attribute" item shown above to indicate that Code is the attribute to assign a generated default value. This will have an immediate impact on the user interface in the MDS Stewardship Portal. The next member that you create will not display a textbox for Code.

Apparently, the UI has enough metadata information about Code to know that the value should be auto-generated, not entered. Great! But what about the WCF service layer? And the Bulk Load / Staging tables?

The WCF layer will return an error "The Member Code is required" in the OperationResult object returned by EntityMemberCreate method. So what should we pass in? If we pass a real value, MDS should respect that value and refrain from asserting a default value. To prove this theory, I added this business rule to a pre-existing test model (one where the Codes where all set to an alpha-numeric value). When I ran the rule, the assigned values had not changed.

The answer to the question is that MDS is actually assigning a dummy code to the member: a dummy code which MDS understands can and should be overwritten. To watch this occur, exclude the business rule you just created and publish the change. Now return to the Explorer and enter a new member record. Note that the Code textbox remains hidden. Create a name and hit the Save and Back button. When you search for the member you just created, you will see a generated code which is a GUID prefixed with the string "#SYS-"

The prefix tells MDS that this is a generated value. Now return to System Administration, uncheck the Exclusion option, re-publish the rules, and run the Business Rules against your member to generate a code for it.

Therefore, the second thing you need to do is ensure that all calls into the WCF Layer to perform EntityMemberCreate operations provide a dummy code in the specified manner. This easy enough to do, now that we know how.

Note that in the above example, "MDS" is named as an alias for my service proxy in a using statement not shown (I recommend that you do the same).

Finally, you will want to create a similar dummy code when creating members through the staging infrastructure. If writing straight Transact-SQL to insert records into tblStgMember, use newid() to get a guid; SSIS requires a different syntax. You can use this very same code for tblStgMemberAttributes and tblStgRelationships for bulk updating User Defined Attributes and Hierarchy Memberships, respectively. When the business rule runs for that member, MDS will cascade the changed code through the hub, so that nothing is lost in the change.

Thanks to Pam Mathews at Profisee for setting me on the right path.

BlumShapiro is now one of a select few consulting firms working directly with Profisee to deliver rich tools for SQL Server 2008 R2 Master Data Services.

This makes life in our Microsoft BI and Master Data practice much easier because I can freely demo both the Master Data Maestro Client Application and the Master Data Maestro server solution coming in Version 2 of the product.

Version 1 Master Data Maestro offered several benefits to organizations looking to leverage Master Data Services:

  • Workspaces for Data Stewards working with Master Data Day-in Day –out
  • Merging to the "Golden Record" enabling native merge capabilities found in the WCF Services layer which are difficult to leverage out-of-the-box
  • Hierarchy Navigation and Management because nobody wants to manage a Hierarchy in a browser (trust me)

Version 2 adds a Server component to the product which a key Data Quality ask for nearly every one of my clients: Address Standardization with Bing Maps. I can't wait to get the beta installed in the Blum Lab.

Cheers,

Brian

I have had the pleasure of working with Equilibrium on some competitive opportunities, promoting SharePoint 2010 as a collaboration platform for digital asset management – great folks and a great product! Today I learned that they are partnering with NetConnect's Team Portal Platform to deliver a SharePoint online offering of their Media Rich ECM DAM product. This is great news for companies looking to manage digital assets in the familiar SharePoint 2010 world. Low TCO just got even lower!

A free trial of the service is available here: https://equilibrium.teamportal.com/Default.aspx

Enjoy!

In order to clear the Staging tables from Master Data Services, it is easiest to simply call a stored procedure.

exec mdm.udpStagingClear @User_ID,@StagingType_ID,@DeleteType_ID, @ModelName, @Batch_ID

To get your @User_ID, refer to the mdm.tblUser table.

@StagingType_ID is required, but only used when @DeleteType_ID = 0 or 1

The @DeleteType_ID Parameter controls how the staging table is cleared.

 

Value

Description

@DeleteType_ID

0

Delete by Model and User.

@DeleteType_ID

1

Delete by Model and User the staging records that have processed successfully.

@DeleteType_ID

2

Delete by User.

@DeleteType_ID

3

Delete by Batch, including the batch record.

 

When @DeleteType_ID = 0 or 1, @ModelName is required and you should pay attention to the @StagingType_ID.

 

Value

Description

@StagingType_ID

1

Delete Members

@StagingType_ID

2

Delete Attributes

@StagingType_ID

3

Delete Relationships

@StagingType_ID

4

Delete All

 

I prefer to use @DeleteType_Id = 3 so that I clear the tblStgBatch table as well, but @DeleteType_ID=1 is also appealing, as it bulk clears while retaining failed loads. Also, you really should only use this for Initial Data Loads of Master Data. For all other write operations, I recommend the WCF Service.

Enjoy!

Thanks to CTDOTNET and the 40 or so folks who showed up despite a tanker rollover on I-91.  I sometimes find that I have difficulty filling 90 minutes with content when presenting on a topic.  Not Master Data Services!  This is a surprising product to many experienced .NET practitioners (and even SQL DBAs) and the topic of MDM never fails to provoke conversation.
 
We spent the first 45 minutes simply understanding what MDM was and was not.  Then 30 minutes discussing modeling and business rules.  Before I knew it, I had 10 minutes to show some code.  Ah well.
 
The Slide Deck for those who missed it is here:
 
I also published several Source Code samples.  The first is the SharePoint Workflow which was initiated in response to a Master Data Action:
 
The second is the custom workflow extender which leverages External Actions to launch a customized Business Process:
 
Finally, this Windows App works with the Sample Customer Model and demonstrates how you might go about creating a custom UI:

Yeah! I'm so glad that SB asked me because after SharePoint Saturday Hartford (of course you were there) I was thinking to myself – I need to get up and talk to people more about Master Data Services.

Anyway, I enjoy this group. They meet at the Microsoft office in Farmington, CT every 2nd Tuesday of the month. Nice group of people and I have seen several excellent presentations given there. My talk is on March 8, 2011.

I'm not sure when the event starts, but you can find out here: http://ctdotnet.org/default.aspx

I'll talk about what Master Data Management is, why companies care, and the of course SQL Server 2008 R2 Master Data Services. We'll talk architecture, modeling, rules, getting data in, getting data out, and even demo some SharePoint code!

Hope you can make it.

 

 
This past saturday I presented "SharePoint and Azure - Every Cloud has a Silver(light) Lining".  The focus of the presentation was to walk through various integration scenarios between SharePoint On Premise and SharePoint Online as well as WCF services hosted on Premise and delivered via Azure in the cloud.
 
Here are the slides that I presented: SharePoint Saturday Slides
 
I haven't had a chance to pull together my code samples from the 5 different projects and solutions I presented.  Once I do that I'll put another post up here with that, so be on the lookout.
 
Also, for more SharePoint Saturday Hartford content, check out the site:
 
 
Enjoy,
McP

I have been spending my time exploring Data Quality components which can be used as part of the Master Data Generate phase. With a few MDM projects under our belt, Data Quality tools have become a must have.

For the Microsoft platform, there are plenty of options. We love Melissa DATA's Data Quality Components for SSIS – a full suite of Data Quality components for real-time data cleansing, priced for the Mid-Market.

A less expensive option (if all you need is Customer Address Normalization): \n software has a number of Address Verification components which can be used inside of SSIS.

Having said that – have you seen what you can do with Out-Of-the-Box SSIS components?! It's true that you will need to become quite familiar with the Script Transformation component (which requires .NET Development skills), but if you don't mind rolling up your sleeves, you can do some very powerful things. SQL Server 2011 is expected to include Data Quality Services to augment these SSIS tools.

Meanwhile, my colleague Michael Pelletier has written a superb article on assessing the viability of Master Data Management in your organization. Michael continues to lead the way in defining how to begin thinking about MDM in your organization.

http://www.bizactions.com/n.cfm/page/e105/key/153466325G2198J3599667P0P10159963T0/

Enjoy!

I have written some articles in the past on topics which begin with the title "Planning Your First…", as in Planning Your First Microsoft BizTalk Solution or Planning Your First Master Data Services project. This time I thought I would take note of a similar article written by Stacia Misner of Hitachi Consulting under the TechNet auspices.

http://technet.microsoft.com/en-us/magazine/gg413261.aspx

In particular, I like the section entitled "What's Wrong with Querying Your Corporate Databases?" At the end of the day, our ability to answer this question for clients is why we have been successful delivering Microsoft BI. Once a prototype is up and running with the client's own data being used, we will often use Excel to slice and dice that data in a business focused manner. Within seconds of demonstrating the new capability, everyone (business people and technical people) understands why our solution is the answer to their most vexing business problems.

Blum Shapiro Technology Consulting is focused on delivering Microsoft BI solutions to the Mid-Market in the New England and New York Metro regions. Our experience with SQL Server Business Intelligence tools dates back to 2000; in the last 10 years, the evolution of the Microsoft stack has been phenomenal. However, in order to deliver BI, you need to understand SharePoint. We are recognized masters of SharePoint Technologies, and have been working specifically with PerformancePoint Services back when it also did Financial Consolidations (that's PPS-Planning).

The latest area of innovation has been in applying Master Data Services as a business tool for managing the OLAP dimensionality. Whereas in the past, IT maintained and controlled Hierarchies of data, MDS can enable the business to manage the consolidation of Customers, Products, Accounts, etc. in a controlled, stewardship managed manner. This brings the enterprise data warehouse closer and closer to the business users and analysts – always a good thing. The other side of this coin, however, is Operational MDM: the Master Data ideally should truly be Master and consumed by operational systems which are heavily process oriented. Without this component, there is little incentive for data stewards to keep the Master Data clean, or comply with Enterprise Data Policies and Procedures.

I have been extremely impressed with PROPHIX. For those who do not know, they are a Microsoft Partner out of Toronto, ON which is the leading contender to fill the gap left by PerformancePoint Planning for the mid-market. Yes, we are a partner, with a number of budgeting and forecasting implementations to our credit in the Greater Hartford area.

The latest version of PROPHIX takes advantage of the Wave 14 stack from Microsoft: SQL Server 2008, SharePoint 2010 and Office 2010.

In a recent conversation I had with PROPHIX partner support, we discussed PROPHIX's capabilities relative to Financial Consolidation. This is an area that they have been doing a good deal of work on, and I was pleased to see a new white paper on the subject released by them yesterday. The White Paper is 38 pages and targeted to a non-technical audience. However, if you are looking for a review of all of the main points that need to be addressed by any Financial Consolidation tool, I feel that this white paper supports the notion that PROPHIX is ready for real-world, complex Financial Consolidation work.

http://www2.prophix.com/e/444/ommon-pdf-prophix-and-fc-pdf/H9DYS/337742676

Happy reading!

Brian

Congratulations to Professor Mortensen for his Nobel Prize in Economics! I regret that while completing my Economics degree, I did not take a single class with this man – surely my loss. However, news of this kind always fills me with pride at my Alma Mater, even though we do not get the kind of recognition we deserve here on the East Coast.

http://www.northwestern.edu/newscenter/stories/2010/10/mortensen-nobel-economics.html?utm_campaign=oct10&utm_medium=email&utm_source=enews

 

 

View RSS feed

Skip navigation links
Back to BlumShapiro
Matthew Rankin

Blum Shapiro Consulting
29 South Main Street, 4th Floor, West Hartford, CT 06127-2000 | 860.561.4000

Copyright© Blum Shapiro Consulting. All Rights Reserved.