2014年9月8日,星期一

SharePoint / Office 365中基于JavaScript的配置

在这篇文章中,我想特别关注基于JavaScript的供应代码的思想–一种可能有用的方法,在每个现代SharePoint开发人员中都有一席之地’的工具包。这是使用SharePoint的想法’的JSOM API(即CSOM的JavaScript版本)来为SharePoint网站执行各种一次性配置步骤-最初,我对该技术(JavaScript?对于资源调配?是否可靠?)持某种怀疑态度,但是看到了一些团队-同事们在项目上成功使用了它(赞!),我认为’值得考虑。

背景

对于使用SharePoint Online / Office 365的SharePoint开发人员, 要么 正在内部部署,但选择不使用完全信任的WSP只是为了确保其解决方案是“cloud-friendly”,自定义SharePoint代码的先前选项不再可用。而且一些常见情况仍然需要代码–尤其是在开发某种形式的自定义网站模板时,或者我们正在努力实现网站的自动配置时。

开发人员可能需要使用代码的预配步骤的一些示例如下:

  • 绑定托管元数据/分类字段
  • 在网站上设置主题/组合外观
  • 设置网站的母版页
  • 修改导航设置
  • 品牌OneDrive(个人)网站
  • [可选]通过代码而不是XML设置字段和内容类型

当无法使用服务器端SharePoint代码时,这将带来挑战。众所周知,Microsoft已弃用沙盒SharePoint代码(我们以前可能使用过它称为功能接收器),并且将来可能会在Office 365中关闭此功能。因此,我们必须改用一种远程API–并且代码可以从其他服务器(例如.NET CSOM)或用户运行’s browser (JSOM).

远程代码选项

大致来说,远程代码的选项包括:

  1. .NET CSOM API的一些用法:
    1. 将代码部署到Azure等云服务,或在某处运行自己的服务器。这可能是“App for SharePoint”,也可以只是不使用应用程序身份验证的远程代码。
    2. A “PowerShell + CSOM” script 你写了
  2. JSOM API的某些用法(即CSOM的JavaScript版本)
  3. REST API的某些用法(来自JavaScript或远程服务器端代码)

正如微软所说,您的自定义代码要么需要向上移动到云中,要么向下移动到用户’s browser.

基于JavaScript(JSOM)的选项

最初,使用JSOM代码进行站点供应步骤的想法很奇怪。如果用户在代码运行时关闭浏览器,会发生什么?该网站是否将正确配置?如果用户在慢速连接上离服务器很远怎么办?像这样的问题最初使我感到怀疑,但是我认为有了一些保护措施和注意事项’s是一个有趣的远程代码选项。一世’一会儿再说说它是如何工作的,但首先在这里’s why I think it’s interesting:

避开“服务器端远程代码” issue

作为现代SharePoint开发人员,我’所有内置的应用程序和远程代码。在某些情况下’在Azure中实现了远程SharePoint代码(例如,请参阅 将SP2013提供程序托管的应用程序/远程事件接收器部署到Azure网站(用于Office 365应用程序) 发布)。是的,我’我很酷的东西!和我’我也和孩子们在一起 微软’的OfficeDev模式和实践示例,其中涵盖了很多情况,例如我上面列出的那些情况– they’有效地写了 wrapper around the .NET CSOM API calls, which make it 真实ly easy to get these tasks done.

但是仍然需要部署这种类型的代码! 本地服务器(例如某些IIS盒)会在高可用性,防火墙外部访问,SSL证书,备份和还原等方面带来复杂性。当然,也存在云选项。如果您(或您的客户端)已经在使用Azure,那就太棒了!它’在此处部署和运行代码确实不是很困难,Microsoft负责运营/ IT。上面列出的有利因素。但是在许多组织中’不幸的是,经过合作,Azure(或类似的云服务)尚未嵌入IT中。部门’的工具包。没有Azure订阅,有人在I.T.已经支付月度发票。并且有各种各样的可操作IT讨论话题并取得共识,然后我们才能升任该职位–谁负责,我们将在其中存储什么样的数据,谁可以访问,它如何与任何现有的SLA / OLA配合,由哪个部门/成本中心支付账单等。

有趣的是,在“实施伙伴 ”就像我的团队所做的那样,我们几乎可以选择为客户端向Azure部署一些远程代码,而无需让他们参与此决策。 Azure网站产品具有免费选项,因此可以避免所有帐单问题/设置。但是,在自由模式下您不会获得高可用性–因此,如果正在修补您运行代码的计算机,则您’会有停机时间。所以最后,除非您的代码很简单,否则这可能不是’t an option.

因此,在某些情况下,用JavaScript实现远程代码的想法可能很有吸引力。

基于JavaScript的配置的可靠实现

所以,我们’d需要某种方式使基于JavaScript的方法更可靠。伙计们使用的模式是这样的:

  • SharePoint网站已创建(也许是从自定义WebTemplate进行的,该WebTemplate负责处理XML中的某些设置)–此时,该站点尚未完全配置
  • 每个页面都引用了一个自定义JavaScript文件–这会检查设置步骤是否已经完成。如果不是,则用户’会检查其权限,以查看它们是否为网站所有者,以及我们是否可以继续(使用“网站所有者需要访问此网站才能对其进行配置”如果未显示该消息)。
  • 当用户访问该网站时,我们的代码就会运行。如果我们可以进行设置,则会显示一个对话框-“Please wait – we are 准备好您的网站”
  • 该代码开始执行配置步骤–可能会设置“组合外观”和/或自定义母版页,绑定分类法字段等
    • 每个步骤完成后,系统会将条目写入网络媒体资源包,例如“BrandingApplied = true”
  • 完成所有步骤后,将显示一条成功消息,并且“准备好您的网站”对话框自动关闭。该站点现在可以使用了。

可以猜到’仅当所有确认都写入到属性包时,我们才不再尝试执行这些步骤。这在实践中效果很好–用户/网站所有者很乐意看到此类消息,并且由于网站所有者是网站创建者,因此最初让网站所有者访问该网站通常效果很好。如果发生任何故障,那’也可以,因为未完成的步骤将在下一页加载时重试。

为了说明这一点,这里’是网站所有者在配置过程中可能会看到的内容(显示在测试页上,而不是“real” site home page):

对话框大

当然,您可以在外观和感觉上做得更好。

一些基于JavaScript的配置示例代码

In my other article Three 云友好 ways for developers to 在SharePoint / Office 365中配置托管元数据字段,我展示了一些JavaScript代码,它们执行了上述基本操作–专门用于将分类字段绑定到MM术语集。 这与其他文章中的示例相同 - 一世’为了方便起见,我在下面再次添加了该文章,但我建议您也阅读另一篇文章,因为它还有一些有关如何使用代码的注释(例如您可能希望通过JavaScript Promise进行增强的事实)。请注意 没有 ’t 可以在网络媒体资源包中处理设置确认信息,但是添加此信息非常简单。该代码将与Office 365或本地SharePoint一起使用:

我猜想从此代码中获取的主要东西是方法-在执行JSOM代码的几个步骤的同时显示对话框。在这个简单的示例中,当代码完成时,我们的分类字段将被绑定并可以使用–但是在我们的实际项目中,显然要执行更多的步骤。

概要

尽管使用JavaScript / JSOM代码进行配置的想法似乎很奇怪,但我相信它已经实现了’的位置,有时可能是正确的选择。当然,如果您不需要其他远程代码和/或没有托管位置(例如Azure或本地IIS服务器)可以投入生产,那么JSOM方法确实为您提供了一种运行方式远程SharePoint代码,而没有其他替代方法带来的麻烦。一如既往,考虑一下取舍并考虑一下’s right for you –但希望这里的信息对您有帮助。

6条评论:

未知 说过...

我认为这是一种很棒的初始化方法'ing sites.

我们使用它时有一些变化:A"MySiteTemplate配置"网站模板中默认激活的功能,该功能会部署
<CustomAction ScriptBlock ="MyNamespace.MySiteTemplate.Init()" ... />
javascript代码的最后一步是停用其自身的功能,因此将来不再"这个网站配置好了吗?"执行检查。

克里斯·奥'Brien 说过...

@Fran,

感谢您添加此内容-可能对人们有用的有用信息"production-ize" this approach.

附:总是很高兴认识我的队友正在阅读我的文章:)

塔尔 说过...

克里斯,你好

长期的读者第一次答复者(正在发展SharePoint开发链,所以现在我可以真正为这些讨论做出贡献了!)。

感谢您撰写本文,因为我认为元素的JavaScript配置被视为"dirty" 要么 "hacky",但我同意确实可以完全做到这一点,来自像您这样的可信任来源的文章可以帮助人们信任该过程。

不过,正如您讨论使用模板一样,我想评论一下您的方法。我已经开发了一种站点供应方法,但是由于这是针对发布站点的,因此我无法使用模板。我们还对配置MySites提出了新要求,这更加棘手。我可能会为此写一篇文章...

对于我们的发布站点,我们不想更改创建站点的用户体验,因此我要做的是编写一个在每个页面上运行的功能。如果发现当前URL是"viewlsts.aspx"它将在旁边创建一个新按钮"new subsite"按钮。此按钮将指向相同"newsubweb.aspx"页,但添加查询字符串。在所有页面上运行的另一个函数将检查查询字符串是否存在,如果存在,则会稍微修改用户体验,以使它们具有相同的外观,但无法选择模板或设置权限选项。当用户点击"Create"会弹出一个对话框,告诉他们正在创建其站点,并且所有调配和配置都在客户端完成。解决方案"如果用户离开页面怎么办"首先是一个确认框,向用户发出警告,但是其次,所有活动都记录到根站点中的列表中,该列表跟踪站点创建请求,创建站点的时间并记录发生的任何错误。

我想我可能会写一篇关于此内容的文章,以及有关我配置mysites的经验...如果您有兴趣,很高兴在撰写这些文章时向您发送链接。

塔尔

克里斯·奥'Brien 说过...

@Tal,

听起来不错。好东西,你 应该 博客:)

克里斯。

马克·威尔逊 说过...

因此,即使是本地部署,您也可以在沙盒上推荐它?在我看来,如果您明白我的意思,那么通过JSOM从应用程序Web到主机Web的文件调配似乎有点荒唐。看着杰里米·塔克'的博客沙箱不是'实际上要关闭一段时间。

我也是'd有兴趣了解如何使用JSOM设置处理自动构建。通过侧面加载安装应用程序后,您需要访问应用程序页面以执行JavaScript。对于诸如内容类型之类的基本内容,这很可能需要在自动化部署的早期就发生。作为构建过程的一部分,开始旋转浏览器感觉很脆弱。

克里斯·奥'Brien 说过...

@标记,

I'm not sure I'd使用这种方法来配置文件-我'我考虑了更多真正需要代码的配置步骤。就是说,如果您想要解决方案的云友好性和可升级性达到最佳,则产品组将开始鼓励实施者放弃声明式配置的几乎所有方面。但是,我个人认为,在需要高度控制更新(例如发布Intranet)的情况下,此刻需要进行一些折衷(尤其是在Office 365中)。不过,可能是另一篇文章的更深入的主题。

关于沙盒的使用,我'd绝对避免在沙箱中使用* code *-指导现已明确。如果你'在本地,是的,您确实拥有更多的控制权(即唐't disable it if you'重新使用它!)与Office 365相比,但显然您不是't 真实ly achieving "cloud-friendly"如果您的解决方案无法进行大规模的重新设计就无法被带到云端(即Office 365,不允许使用沙箱代码)。

对于自动化构建,是的,我同意基于JSOM的配置在这里带来了挑战。另一方面,我不'真的看不到在构建过程中加速浏览器的任何不好的结果-如果那样的话'的实现模式'重新使用,然后围绕它进行自动化测试,这正是您想要的。毕竟,如果构建过程与生产供应过程有所不同,那么您're not testing what'需要,并且会有差距。

和往常一样,有很多要考虑的问题:)

干杯,

COB。