|
|
|
|
|
|
|
|
|
|
|
Blum Shapiro Consulting Blogs
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.
|
posted @ 04/19/2012 05:40 PM by BRIAN BERRY 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! posted @ 04/02/2012 01:02 PM by BRIAN BERRY 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. posted @ 02/29/2012 02:31 PM by BRIAN BERRY 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. posted @ 02/23/2012 08:28 AM by BRIAN BERRY 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. posted @ 06/11/2011 10:23 PM by BRIAN BERRY 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:
- You cannot change the data type for Code in the System Administration area of the MDS Stewardship Portal
- When creating an Entity Member in the WCF layer, you are required to submit a Member Code or the operation will fail
- 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. posted @ 05/31/2011 10:21 PM by BRIAN BERRY 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 posted @ 04/13/2011 11:35 AM by BRIAN BERRY 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! posted @ 03/25/2011 10:18 AM by BRIAN BERRY 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! posted @ 03/09/2011 08:42 AM by BRIAN BERRY 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:
posted @ 02/09/2011 08:44 PM by BRIAN BERRY 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.
posted @ 02/02/2011 02:01 PM by Michael C Pelletier
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.
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 posted @ 12/17/2010 11:36 AM by BRIAN BERRY 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! posted @ 11/18/2010 08:11 AM by BRIAN BERRY 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. posted @ 11/05/2010 08:24 AM by BRIAN BERRY 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 posted @ 10/15/2010 08:13 AM by BRIAN BERRY |
 |
|
|
|
|
|
|
|
Blum Shapiro Consulting
29 South Main Street, 4th Floor, West Hartford, CT 06127-2000 | 860.561.4000
Copyright© Blum Shapiro Consulting. All Rights Reserved. |
|
|
|