2013年9月17日,星期二

在Office 365中置备托管元数据字段- Part 1: dealing with multiple environments

托管元数据字段一直对SharePoint开发人员来说有些痛苦,但是如果您在SharePoint 2010中进行了任何类型的网站模板或功能开发,则很可能您需要进行一些研究,阅读一些博客文章并了解该解决方案。我在这’d想谈谈Office 365的应用,并展示一些我为帮助我们当前使用的流程而构建的自定义设置。这篇文章很长,因此我将其分为两篇文章:

  1. 在Office 365中置备托管元数据字段–处理多种环境[本文]
  2. 在Office 365中置备托管元数据字段–为特定环境/租赁构建WSP软件包

因此,回到SharePoint 2010的情况-要做的是一些托管元数据详细信息 更改 SharePoint环境之间–因此,与其他字段不同,不能在dev / test / UAT / production中使用相同的配置XML。具体来说,术语存储库,组和术语集的ID在环境之间都不同。提醒一下,广泛的解决方案是:

  • 使用XML定义“static”领域的细节
  • 使用服务器端代码“finish the job” –即使用API​​询问SharePoint(当前环境中的ID)是什么,然后使用该值更新字段配置

如果没有第二步,则将创建该字段,但该字段将被破坏–它将显示为灰色,并且用户无法使用它(此处显示了SP2010示例):

sp2010管理的元数据字段已禁用

帖子作者 阿里·巴克(Ari Bakker) (其图像我’我在上面使用,谢谢阿里(Ari), 威克多·威伦安德鲁·康奈尔 在讨论解决此问题的步骤时很受欢迎。

It’SharePoint 2013 / Office 365中的相同处理 –但是事实证明我们需要不同的技术。

为什么这种方法没有’适用于Office 365 / SharePoint Online

首先, 在沙盒解决方案中已弃用。全站。 [相关-您听到了吗? Microsoft开始澄清没有代码的沙盒解决方案’毕竟真的过时了 (希望MSDN会很快反映出这一点),但是不建议使用沙盒解决方案中的CODE,并且可以在以后的版本中逐步淘汰它。显然,这是一个非常重要的区别。]

但是,即使我们很乐意使用沙盒代码-在Office 365 / SharePoint Online中,我们也无法使用 Microsoft.SharePoint.Taxonomy 无论如何,服务器端代码中的名称空间–最终结果是我们无法“finish the job”以这种方式确保字段正确绑定到术语库。这是个问题!更糟糕的是,尽管CSOM API中可以绑定字段, 在供应过程中执行此操作 (例如,通过模板创建网站)具有挑战性,也许是不可能的。也许您可以提出一些富有想象力的技巧,但是’s probably what it would be. And what happens if this 远程码 (e.g. a Remote Event Receiver) fails?

可能的解决方案

我的一个同事 路易斯·马埃兹,做了一些很棒的研究– I’我会在这里给您一个简短的摘要,但我强烈建议您阅读他的文章- 在SharePoint 2013 Online(Office 365)中以声明方式部署托管元数据字段. 这里’s a summary:

实际上,如果您愿意接受重大的折衷,则可以不用任何代码来配置托管元数据字段– 您可以 声明性地 在XML字段定义中指定键详细信息(例如术语库ID(也称为SspId),组ID,术语集ID等). 威克托在他的帖子中提到了这种可能性。 但是请记住,这些细节在环境之间会发生变化!

换句话说,权衡是 需要针对每种环境重建您的WSP.

这对我们来说很棘手,因为在此项目中,我们选择运行多个Office 365租约,以进行开发/测试/生产(’我会在以后的帖子中谈论)–就像传统的成熟过程一样。所以起初我们说“No way! 那’违反我们的所有ALM原则! 完全相同的软件包必须在环境之间移动!”。但随后我们理性地研究了可以看到的替代方案:

  • 选项1 - 一些精心制作“remote 码”解决方案,可能涉及在提供站点之后单独运行的代码。在执行此代码之前,无法将文档上载到站点内具有MM字段的库中(并且类似地,如果此远程调用实际上由于任何原因而失败, 在管理员干预之前,这些库将无法正常运行)。
  • 选项2- 客户端需要手动修复任何托管元数据字段–在我们期望的所有5000个站点中。在每个列表和库中。知道某些列表/库最多具有5个此类字段。是啊….

由于这两种方法都不具有吸引力,因此我们继续研究100%声明式定义托管元数据字段的想法。然后我们意识到了这一点。

..如果你以某种方式做事 , 您可以 get to the point where ONLY THE TERM STORE ID (SspId) CHANGES BETWEEN ENVIRONMENTS. 那’有点有趣。这意味着只需一个查找/替换操作即可’s needed – assuming 您’很高兴接受整体的权衡。当然,必须替换SspId仍然不是最佳选择,容易出错,而且效果不佳。但是也许我们也可以– 和 that’这些帖子的真正含义是- 为了显示Visual Studio自定义,我们进行了简化,以简化此过程,并减少了人为错误的发生。 如果您想跳过此步骤,请参阅 在Office 365中置备托管元数据字段–第2部分:为特定环境/租赁构建WSP软件包. 

但首先,让’s talk about that “如果你以某种方式做事 ”事物(这意味着在环境之间唯一的SspId会发生变化)。

的full recipe for Managed Metadata fields

如果您在,请退后一秒“development mode”(例如,为SharePoint网站创建模板),那么成功进行配置实际上不仅仅涉及以某种方式配置字段本身。有效 您应该寻求提供术语集和字段。不允许管理员在管理界面中创建新的术语集。 这是因为:

  • 这条路, 可以控制您所有术语集的ID–而不是让SharePoint生成该GUID
  • 因为这是静态的“known”ID,我们可以在其他地方引用

这里’需要发生什么:

  • 术语集通过以下方式设置到术语库中“known” IDs
  • 的“known IDs”然后在字段的XML定义中使用
    • 下面的代码示例是100%声明方式提供的Managed Metadata字段的示例。请注意,在‘Customization’部分(使用组合式声明式+代码方法的字段不具备):
      ** N.B.我较新的代码示例未在RSS阅读器中显示- 点击这里查看全文 **

如果这样做,您的Managed Metadata字段将可以正常工作:

托管元数据字段-工作

大。它’知道Office 365可以做到这一点当然非常有价值。 所以现在我们有了东西 仅SspId值需要在环境之间进行更改。但是那’仍然是讨厌的查找/替换操作–我们怎么做这个 情况更好?

我将在下一篇文章中描述我们使用的机制- 在Office 365中置备托管元数据字段–第2部分:为特定环境/租赁构建WSP软件包.

没意见: