企业官网建设流程全解析

• 示例工程
• 数据库
• 教程
• 后端

Master Data Services（MDS）是 SQL Server 提供的主数据管理（MDM）解决方案，用于发现、定义和维护非事务型的主数据列表，形成可持续维护、可靠的主数据清单。本指南以当前仓库 samples/features/master-data-services 目录下的 MDS 示例为绝对主体，系统讲解如何通过 MDS Web Service API 自定义用户与 MDS 的交互方式——包括业务规则的增删改查与验证、实体暂存数据的处理、成员（Member）的 CRUD、元数据管理、模型部署、安全信息导入导出以及 SharePoint 工作流扩展。读完本文，你将掌握一套完整的、可直接复用的 MDS 二次开发模式，并能独立搭建基于 C# 控制台的 MDS 客户端程序。

一、MDS 与主数据管理：示例要解决什么问题

Master Data Services 是 SQL Server 中用于主数据管理的解决方案。所谓主数据管理（MDM），核心目标是让组织能够发现并定义非事务型的数据列表（如客户、产品、供应商、科目等），并将其编译为可维护、可靠的主数据清单——即整个企业共享的"唯一事实来源"。

主目录 README 明确指出：本目录下的 MDS 示例全部是 C# 控制台应用程序，它们演示了如何通过编程方式定制你和你的用户与 Master Data Services 交互的方式。也就是说，这些示例不是 Web 界面操作的替代说明，而是展示了在界面之外，如何以代码驱动 MDS 的核心业务能力。

从目录结构看，示例按 API 能力划分为七个独立工程：

samples/features/master-data-services/ ├── business-rules/ # 业务规则 API（创建、编辑、验证、排除、删除） ├── entity-based-staging/ # 实体暂存 API（处理、查询、清理暂存批次） ├── master-data/ # 主数据 API（成员 CRUD、层次关系、变更集） ├── metadata/ # 元数据 API（模型、实体、属性、属性组 CRUD） ├── model-deployment/ # 模型部署 API（ModelDUtil 命令行工具） ├── security/ # 安全 API（安全主体信息导出/导入） └── workflow/ # SharePoint 工作流类型扩展器

每个子工程都遵循相同的结构：Program.cs（入口与全部示例逻辑）、Reference.cs（由 Visual Studio 生成的 MDS Web Service 代理类）、*.csproj工程文件以及各自的 README 说明。下面先讲解所有示例共用的环境准备，再逐个深入每个示例。

二、通用前置准备：连接 MDS Web Service

除模型部署示例外，其余示例都通过 WCF 客户端代理访问 MDS Web Service（端点形如http://ServerName/MdsSiteName/Service/Service.svc）。所有Program.cs中都有同一段关键配置：

// MDS service client proxy object. private static ServiceClient clientProxy; // Set the MDS URL (plus /Service/Service.svc) here. private static string mdsURL = @"http://localhost/MDS/Service/Service.svc";

例如 business-rules/Program.cs、master-data/Program.cs 中的配置完全一致。实际部署时请将主机名与站点名替换为你的 MDS 环境。

2.1 服务代理的创建方式

每个示例的GetClientProxy方法展示了创建 WCF 客户端代理的标准写法，以 business-rules/Program.cs 为例：

private static ServiceClient GetClientProxy(string targetURL) { // Create an endpoint address using the URL. EndpointAddress endptAddress = new EndpointAddress(targetURL); // Create and configure the WS Http binding. WSHttpBinding wsBinding = new WSHttpBinding(); // Create and return the client proxy. return new ServiceClient(wsBinding, endptAddress); }

其核心是：以 MDS 服务 URL 构造EndpointAddress，配合默认的WSHttpBinding（MDS 服务契约基于 WS-* 标准），实例化ServiceClient代理。所有后续 API 调用都通过该代理完成。

2.2 统一错误处理：OperationResult 遍历

各示例还共享一套错误处理模式——HandleOperationErrors方法遍历OperationResult.Errors，逐个输出错误码与描述（见 business-rules/Program.cs）：

private static void HandleOperationErrors(OperationResult result) { string errorMessage = string.Empty; if (result.Errors.Count > 0) { foreach (Error anError in result.Errors) { errorMessage += "Operation Error: " + anError.Code + ":" + anError.Description + "\n"; } // Show the error messages. Console.WriteLine(errorMessage); } }

MDS 的每个 Web 方法返回中都包含OperationResult，这是判断调用成败的统一入口，实际开发中应像示例一样在每个调用后立即检查。

2.3 生成 Reference.cs：暴露 WSDL 与 Visual Studio 添加服务引用

Program.cs使用的Reference.cs是通过 Visual Studio 生成的服务引用类文件，用来访问 MDS Web Service API。各示例 README 一致提醒：当 MDS Web Service API 发生变化时，可能需要重新生成Reference.cs。

生成代理类时只需临时暴露 WSDL，代理生成之后便不再需要暴露 WSDL，客户端程序可直接调用 API。具体步骤如下：

第一步：启用对 WSDL 的 HTTP/HTTPS GET

1. 用文本编辑器打开 MDS 的web.config文件，路径为<Program Files>\Microsoft SQL Server\Master Data Services\WebApplication\web.config；
2. 搜索serviceMetadata标签，将httpGetEnabled设为true（如果使用 SSL 则设httpsGetEnabled）。

第二步（可选）：启用服务异常详情以便调试

搜索serviceDebug标签，将includeExceptionDetailInFaults设为true。注意：此选项仅用于额外调试，标准（已捕获的）错误并不需要它。

第三步：在 Visual Studio 中添加服务引用

1. 打开工程后点击"Add Service Reference"（添加服务引用）；
2. 在 Address（地址）中输入 MDS 服务 URL：http://ServerName/MdsSiteName/service/service.svc；
3. 在 Namespace（命名空间）框中将服务的命名空间指定为"MDSTestService"；
4. 点击 Advanced（高级）按钮配置高级设置；
5. 勾选Always generate message contracts（始终生成消息约定）；
6. 将 Collection type（集合类型）下拉框设为System.Collections.ObjectModel.Collection；
7. 点击 OK 返回"添加服务引用"对话框；
8. 再次点击 OK 完成生成。

生成的Reference.cs位于BusinessRules\Service References\MDSTestService等对应文件夹中，可将其替换掉示例工程根目录下的Reference.cs（各工程目录结构见 business-rules、entity-based-staging、master-data、metadata、security 各自的 README）。命名空间统一为 "MDSTestService" 是让示例代码可直接编译的关键约定。

三、业务规则 API 示例：规则的完整生命周期

business-rules 示例演示了如何使用 MDS API创建、编辑、验证、排除和删除业务规则，其完整场景链如下：

1. 系统创建一条业务规则（当Code等于ABC时，Name必须等于Test）；
2. 编辑该业务规则（将条件改为Code以Test开头）；
3. 创建一个会触发业务规则校验失败的成员（添加Code = "Test12"、Name = "AA"的成员）；
4. 执行校验（Validation）并获取校验问题（Validation Issue）信息；
5. 最后排除并删除该业务规则。

一个贯穿始终的核心约束是：每次改变业务规则状态的操作（创建、编辑、排除、删除），都必须调用发布（Publish）操作来最终生效。从 Program.cs 的主流程可以清楚看到这一点：

// Create a new business rule and publish it. CreateAndPublishBR("TestModel", "TestEntity", "Test Rule"); // Edits the business rule and publishes it. EditAndPublishBR("TestModel", "TestEntity", "Test Rule"); // Creates a member that causes a validation issue... GetBRValidationIssue("TestModel", "TestEntity", "Test Rule", "VERSION_1"); // Excludes the business rule and publishes it. ExcludeAndPublishBR("TestModel", "TestEntity", "Test Rule"); // Deletes the business rule and publishes it. DeleteAndPublishBR("TestModel", "TestEntity", "Test Rule");

注意：调用前需要预先在 MDS 中创建好TestModel、TestEntity，并指定存在的版本（如默认的VERSION_1）。

3.1 创建规则：条件树 + 动作的参数化构建

CreateAndPublishBR 方法完整展示了规则的对象模型。规则由标识符（MemberTypeContextIdentifier，需指定ModelId、EntityId、MemberType）、优先级（Priority）、条件树（BRConditionTree）和动作集合（BRActions）组成。创建"Code 等于 ABC"条件的关键代码：

newRule.Identifier = new MemberTypeContextIdentifier { Name = ruleName, ModelId = modelId, EntityId = entityId, MemberType = MemberType.Leaf }; newRule.Priority = 10; newRule.BRConditionTree = new BRConditionTreeNode(); newRule.BRConditionTree.LogicalOperator = LogicalOperator.And; newRule.BRConditionTree.Sequence = 1; // Create the rule condition "Code equals ABC". BRCondition ruleCondition = new BRCondition(); // 前缀参数：定位属性 "Code"（BRPropertyName.Anchor 表示锚定属性） conditionPrefix.PropertyName = BRPropertyName.Anchor; conditionPrefix.AttributeId = new Identifier { Name = "Code" }; ruleCondition.Operator = BRItemType.IsEqual; // 后缀参数：值 "ABC"（BRPropertyName.Value） conditionPostfix.PropertyName = BRPropertyName.Value; conditionPostfix.Value = "ABC";

可以看到 MDS 业务规则 API 的设计：条件（BRCondition）由"前缀参数（属性锚点） + 运算符（BRItemType）+ 后缀参数（自由值）"三元组构成；动作（BRAction）采用同样结构，例如"Name 必须等于 Test"使用BRItemType.MustBeEqual。这种参数化结构意味着你可以用代码构造任意复杂度的规则表达式。

创建完成后必须发布：

rulePublishRequest.BRPublishCriteria = new BRPublishCriteria(); rulePublishRequest.BRPublishCriteria.EntityId = entityId; rulePublishRequest.BRPublishCriteria.ModelId = modelId; rulePublishRequest.BRPublishCriteria.MemberType = BREntityMemberType.Leaf; clientProxy.BusinessRulesPublish(rulePublishRequest);

BRPublishCriteria指定了规则所属的模型、实体与成员类型，是发布动作的作用域。

3.2 编辑规则：先查后改再发布

EditAndPublishBR 方法展示了"查询-修改-更新-发布"四步模式：先用BusinessRulesGet按名称取回规则详情（ResultType.Details），再直接修改条件对象的运算符与参数——将BRItemType.IsEqual改为BRItemType.StartsWith、后缀值改为"Test"，然后通过BusinessRulesUpdate提交，最后再次发布。

3.3 验证规则：构造违规成员并获取校验问题

GetBRValidationIssue 方法是整条场景链的高潮：先创建Code = "Test12"、Name = "AA"的叶子成员（该成员必然违反"Code 以 Test 开头时 Name 必须等于 Test"的规则），再调用ValidationProcess执行校验，最后读取返回的ValidationIssueList：

validationProcessRequest.ValidationProcessOptions.ReturnValidationResults = true; ValidationProcessResponse validationProcessResponse = clientProxy.ValidationProcess(validationProcessRequest); if (validationProcessResponse.ValidationIssueList.Count > 0) { ValidationIssue validationIssue = validationProcessResponse.ValidationIssueList[0]; Console.WriteLine("Validation issue: " + validationIssue.Description); }

注意ValidationProcessOptions.ReturnValidationResults = true是获取校验结果列表的关键开关。

3.4 排除与删除规则

排除（Exclude）的本质是将规则状态置为待排除：先查出规则，设置selectedBusinessRule.Status = BRStatus.PendingExclusion，再BusinessRulesUpdate提交，最后发布（见 ExcludeAndPublishBR）。而删除（DeleteAndPublishBR）则通过BusinessRulesDelete按规则的GUID 标识（selectedBusinessRule.Identifier.Id）删除，之后同样需要发布。这印证了 README 中"所有改变规则状态的操作都必须发布"的原则。

四、实体暂存 API 示例：暂存数据的处理、查询与清理

entity-based-staging 示例演示如何通过 MDS API处理（Process）、清理（Clear）和获取实体暂存（Entity Based Staging）数据信息。MDS 的暂存机制是批量导入数据的核心通道：外部系统先把数据写入stg.架构下的暂存表，再由 MDS 处理后进入正式实体。

4.1 准备暂存数据：BatchTag 与 ImportType

运行示例前，必须为所用实体的暂存表预置一条暂存记录，且记录的 batch tag 必须为"Test1"。README 给出了可直接执行的 SQL 示例，向stg.TestEntity_Leaf暂存表插入记录：

Insert into stg.TestEntity_Leaf (ImportType, BatchTag, Code, Name) values (0, N'Test1', N'ABC', N'Name2');

其中ImportType = 0表示导入类型为"合并乐观"（merge optimistic）。此处Code = "ABC"、Name = "Name2"是刻意设计的：它会触发业务规则校验错误（若Code为ABC，则Name必须等于Test），从而演示后续的校验问题获取。批处理标志（BatchTag）是暂存批次的核心标识，后续的查询与清理都围绕它展开。

4.2 处理暂存数据：先解析实体 MUID

ProcessStagingData 方法展示了一个关键实现细节：实体和版本不能仅凭名称指定，必须先通过MetadataGet解析出实体与版本的 MUID（唯一标识），再传给暂存处理请求：

// Get entity MUID. MetadataGetRequest getRequest = new MetadataGetRequest(); getRequest.SearchCriteria.Models.Add(modelId); getRequest.SearchCriteria.Entities.Add(entityId); getRequest.SearchCriteria.Versions.Add(versionId); getRequest.SearchCriteria.SearchOption = SearchOption.BothUserDefinedAndSystemObjects; // Set entity MUID since it cannot be specified only by name. entityId.Id = getResponse.Metadata.Entities[0].Identifier.Id; versionId.Id = getResponse.Metadata.Versions[0].Identifier.Id; // Create the request object. EntityStagingProcessRequest processRequest = new EntityStagingProcessRequest(); processRequest.BatchTag = batchTag; processRequest.EntityId = entityId; processRequest.VersionId = versionId; processRequest.MemberType = MemberType.Leaf; // Process staging data. EntityStagingProcessResponse processResponse = clientProxy.EntityStagingProcess(processRequest);

主流程调用ProcessStagingData("TestModel", "TestEntity", "VERSION_1", "Test1", MemberType.Leaf)后，会等待 60 秒（Thread.Sleep(60000)）让批处理完成（见 Program.cs 主流程）。

4.3 获取暂存信息与清理批次

GetStagingInformation 方法通过EntityStagingGet获取批处理信息，遍历批次列表匹配 BatchTag，返回对应的BatchId；代码注释还提示可以从aBatch.ErrorView和aBatch.Status读取错误信息与批次状态。随后 ClearStagingData 方法用返回的BatchId调用EntityStagingClear，将批次状态置为"Cleared"并删除暂存表中该批次的记录。

示例最后还复用业务规则 API 创建规则并执行校验，验证暂存导入的记录——这与上一节形成闭环：暂存导入 → 规则校验 → 问题定位。

五、主数据 API 示例：成员 CRUD 与层次关系

master-data 示例演示如何使用 MDS API创建、读取、更新、删除实体成员（Entity Member），是主数据日常运维的核心能力。README 列出的 8 个场景在 Program.cs 主流程中一一对应：

1. 使用 MDS API 创建叶子成员（Leaf Member）；
2. 按成员 Code 获取叶子成员信息（成员标识符）；
3. 更新叶子成员信息（修改 Name）；
4. 使用 MDS API 创建合并成员（Consolidated Member）；
5. 按成员 Name 获取合并成员信息；
6. 更新实体成员关系（将叶子成员设为合并成员的子节点）；
7. 删除合并成员；
8. 删除叶子成员。

5.1 建模型与成员创建

示例首先通过MetadataCreate动态创建测试模型（TestModel+ GUID 后缀）、实体与显式层次（见 CreateModel），默认版本名为VERSION_1。创建成员的核心在 CreateEntityMember：

EntityMembersCreateRequest createRequest = new EntityMembersCreateRequest(); createRequest.Members.ModelId = new Identifier { Name = modelName }; createRequest.Members.VersionId = new Identifier { Name = versionName }; createRequest.Members.EntityId = new Identifier { Name = entityName }; createRequest.Members.MemberType = memberType; Member aNewMember = new Member(); aNewMember.MemberId = new MemberIdentifier() { Name = aNewMemberName, Code = aNewCode, MemberType = memberType };

值得注意的细节：当成员类型为Consolidated（合并）时，必须设置父节点信息——HierarchyId指定层次名称，父节点 Code 为"ROOT"（表示层次的根节点，见 Program.cs）。这反映了 MDS 中合并成员必须挂在显式层次下的约束。

5.2 查询成员与属性展示

GetEntityMemberByCode 和 GetEntityMemberByName 展示了基于EntityMembersGet的检索方式：通过MemberReturnOption.Data返回属性数据，并用SearchTerm传入形如"Code = 'xxx'"或"Name = 'xxx'"的过滤表达式。返回的成员属性在 ShowMemberInformation 中按类型分派输出——示例覆盖了String、Number、DateTime、Domain（域属性，需取MemberIdentifier.Code作为值）、File五种属性类型，是理解 MDS 属性模型的直观教材。

5.3 更新成员与层次关系

UpdateEntityMember 演示了局部更新：按 Code 定位成员，构造Attribute（Identifier.Name = "Name"、AttributeValueType.String、新值）后调用EntityMembersUpdate。而 UpdateEntityMemberRelationship 则是调整层次结构的关键操作——通过Parent对象建立父子关系：

Parent aParent = new Parent(); aParent.ParentId = new MemberIdentifier() { Code = parentMemberCode, MemberType = MemberType.Consolidated }; aParent.HierarchyId = new Identifier() { Name = hierarchyName }; aParent.RelationshipType = RelationshipType.Parent; aMember.Parents.Add(aParent);

RelationshipType.Parent明确将子成员挂到指定合并成员之下，这正是"把叶子成员变成合并成员的子节点"的实现。

5.4 变更集（Changeset）与审批流程

除了 README 列出的 8 个基础场景，Program.cs 还扩展演示了**变更集（Changeset）**能力：开启RequireApproval（实体级审批开关）后，通过EntityMemberChangesetSave依次将变更集状态从Open（打开）流转到Pending（待审批）再回到Open（撤回），期间成员的创建/更新/删除都携带ChangesetId参数；EntityMembersGet也支持按变更集过滤成员，并用Debug.Assert(members.Count == 3)断言变更集内的成员数量。整个示例在finally块中调用DeleteModel清理测试模型，体现了"用完即清"的良好习惯。

六、元数据 API 示例：模型与实体的程序化建模

metadata 示例演示如何使用 MDS API 对元数据执行 CRUD，场景覆盖四类对象：

1. 使用 MDS API 创建、获取信息、更新、删除模型（Model）；
2. 创建、获取信息、更新、删除实体（Entity）；
3. 创建、获取信息、更新、删除属性（Attribute）；
4. 创建、获取信息、更新、删除属性组（Attribute Group）。

这四类对象构成 MDS 数据模型的完整层级：模型 → 实体 → 属性/属性组。元数据 API 是"以代码代替界面建模"的基础——上一节 master-data 示例中的CreateModel正是调用MetadataCreate完成的。对于需要自动化搭建开发/测试/生产环境的团队，元数据 API 是必不可少的自动化组件。该示例同样依赖mdsURL配置与Reference.cs（生成方式见第二节），无其他特殊前置条件。

七、模型部署 API 示例：ModelDUtil 命令行工具

model-deployment 示例与前面六个示例不同，它不使用Reference.cs代理，而是一个独立的控制台应用程序，演示模型部署 API（Model Deployment API）中几个常用方法。其外部依赖为两个 DLL：

• Microsoft.MasterDataServices.Deployment.dll
• Microsoft.MasterDataServices.Services.contracts.dll

构建 Visual Studio 2013 解决方案时，需要调整项目引用，指向你本机 SQL Server Master Data Services 部署中的上述二进制文件。

7.1 配置连接字符串

更新ModelDUtil.config（工程内对应 ModelDUtil.exe.config）中的ConnectionString，指向已部署的 MDS 数据库。不要修改连接名称，必须保持为"defaultMdsConnection"，并且ModelDUtil.config必须与ModelDUtil.exe放在同一目录下。

7.2 命令行用法详解

该工具支持以下模式（mode），README 给出了完整的帮助输出：

注意：包含空格的名称要用双引号包裹，例如：

ModelDUtil DeployUpdate mypackage.pkg "Version 1"

这套 CLI 让模型在环境间的迁移（打包、克隆、新建、更新）完全脚本化——它与 security 示例配合，可完整复现一个 MDS 环境（详见下一节）。

八、安全 API 示例：安全信息的导出与导入

security 示例演示如何将安全信息导出到指定文件，以及从文件导入安全信息。它解决的真实痛点是把一套 MDS 环境中的用户、组及其权限完整迁移到另一套环境。

8.1 命令行参数

该示例通过命令行参数驱动（见 security/Program.cs），共 5 个参数：

对应完整用法：

SecuritySample mode mds_host_name mds_application_name file_name [ExcludeMetadata]

8.2 导出/导入的实现机制

从 ExportSecurityInformation 可以看到导出流程：先调用SecurityPrincipalsGet获取全部用户（PrincipalType.UserAccount、SecurityResolutionType.Users），再获取全部组（PrincipalType.Group、SecurityResolutionType.UserAndGroup），请求中同时要求模型权限、功能权限、层次成员权限的详情（ResultType.Details）；随后用XmlSerializer将SecurityInformation（含 Users 与 Groups）序列化为二进制 XML 文件（XmlDictionaryWriter.CreateBinaryWriter）。

导入流程（ImportSecurityInformation）则反序列化文件，并分两步调用SecurityPrincipalsClone：先创建组、后创建用户——代码注释解释了原因：部分用户可能属于某个组并引用该组对象，因此必须先建组再建用户。克隆操作会以相同的 GUID 在目标 MDS 应用中重建这些安全主体。

8.3 关键约束与 ExcludeMetadata 的作用

README 明确列出了两条迁移前提：

1. 导入前，目标 MDS 应用中不能存在与源应用相同的用户和用户组（导入会重建它们）；
2. 导入模型/成员层次权限之前，目标 MDS 应用应拥有 GUID 相同的模型与成员层次——模型部署 API（DeployClone/DeployNew）可以部署与源应用 GUID 相同的模型（元数据模型除外）。

关于ExcludeMetadata：当目标 MDS 应用中元数据模型（Metadata Model）的 GUID 与源应用不同时，安全信息的导入会失败。此时可在第 5 个参数指定ExcludeMetadata排除元数据模型权限来规避。从源码可以看到排除的实现：遍历每个用户/组的SecurityPrivilege.ModelPrivileges，剔除ModelId.InternalId == 1（元数据模型）的权限项（见 security/Program.cs）。这一细节直接指导了跨环境权限迁移的排障方向。

九、SharePoint 工作流扩展示例：自定义工作流类型

workflow 示例与前六个 Web Service 示例不同，它提供了一个工作流类型扩展器（Workflow Type Extender）类，用于扩展 SharePoint 工作流。该类位于 SharePointWorkflowExtender.cs，工程文件为 Microsoft.MasterDataServices.SharePointWorkflow.csproj。

部署方式分两步：

1. 放置程序集：将包含该类的程序集放到与工作流侦听器（Microsoft.MasterDataServices.Workflow.exe）相同的文件夹中；
2. 注册扩展器：更新侦听器的配置文件，引用该类：

<code> <setting name="WorkflowTypeExtenders" serializeAs="String"> <value>SPWF=Microsoft.MasterDataServices.SharePointWorkflow.SharePointWorkflowExtender, Microsoft.MasterDataServices.SharePointWorkflow, Version=1.0.0.0</value> </setting> </code>

WorkflowTypeExtenders配置项采用键=程序集限定名的格式：SPWF是自定义工作流类型的键名，等号右侧是扩展器类型的完全限定名与程序集信息。这一机制让 MDS 的业务规则可以在触发时驱动 SharePoint 审批流，是"MDS + 企业审批"集成的扩展点。

十、总结：一套完整的 MDS 二次开发工具箱

回顾整个 samples/features/master-data-services 目录，七个示例覆盖了 MDS 二次开发的全部关键维度：

• 通用基础：所有 Web Service 示例共用mdsURL配置、GetClientProxy代理创建与HandleOperationErrors错误处理模式，配合"暴露 WSDL → Visual Studio 生成Reference.cs"的固定流程，构成 MDS 客户端开发的脚手架；
• 业务规则（business-rules）：规则的生命周期管理 + 发布机制 + 校验问题获取，是数据质量管控的编程入口；
• 实体暂存（entity-based-staging）：批处理导入的处理、状态查询与清理，是 ETL 批量数据进 MDS 的标准通道；
• 主数据（master-data）：叶子/合并成员的 CRUD、层次关系维护与变更集审批，是主数据日常维护的编程实现；
• 元数据（metadata）：模型、实体、属性、属性组的程序化建模，支撑环境自动化；
• 模型部署（model-deployment）：ModelDUtil命令行工具实现模型的打包、克隆、新建与更新；
• 安全（security）：安全主体信息的导出/导入，配合模型部署实现完整的环境复制；
• 工作流（workflow）：工作流类型扩展器机制，打通 MDS 与 SharePoint 审批。

对于需要把 Master Data Services 融入自动化运维体系、构建自定义客户端或实现多环境复制的团队，这份示例集既是 API 用法的权威参考，也是可以直接改造成生产工具的基础代码。

• 示例工程
• 数据库
• 教程
• 后端