2017年12月14日,星期四

演讲台– Best bits of 蔚蓝for the Office 365/SharePoint developer

这是第2篇,共2篇,用于发布幻灯片I’最近,特别是在都柏林举行的2017年欧洲SharePoint会议上,我们给出了这些建议。也可以看看:

演讲台–SPFx开发中的陷阱

与我的其他文章一样,幻灯片平台也嵌入在该文章的底部。那里’我无法轻松地演示这些演示,但希望幻灯片本身具有一些很好的参考信息。当您开始考虑甚至在Office 365 / SharePoint的轻量级扩展中的某些不同情况时,它’s clear how useful 蔚蓝is:

什么? 怎么样?
按计划做某事 Put code in 蔚蓝Web Jobs/Functions
构建应用程序(Office 365应用程序/ SP提供程序托管的加载项) Deploy app 文件s to an 蔚蓝app
SharePoint网站配置 Deploy PnP Partner Pack (or 即插即用核心 with 一些 calling code) to 蔚蓝
单击按钮运行代码 Use 蔚蓝Functions + JavaScript
存储不适合SP列表的数据 Use 蔚蓝SQL Database
为我的应用存储文件 Use 蔚蓝BLOB storage (and CDN if appropriate)
实施SharePoint Web挂钩 Use 蔚蓝Queues 和 Functions
在自定义Web应用上实施身份验证 Implement 蔚蓝Active Directory (AAD) auth

突出显示的场景是我演示的场景’d,最后一个实际上是我们构建的一个实际解决方案的演示,该解决方案涉及队列,Web作业,BLOB存储,CDN等。

Otherwise the 主要topics are:

  • 蔚蓝web apps
    • 您可能在这里忽略了许多很酷的功能,包括 部署槽生产测试。换句话说,它’这比您自己托管IIS时可能获得的简单Web托管要好得多。
    • 在此处部署文件的多种方法–从Kudu界面(类似于将文件拖放到SharePoint文档库中),从Visual Studio发布,到WebDeploy以及从源代码控件(VSTS,GitHub等)自动同步
  • 蔚蓝App Insights
    • 另一个unsung hero of Azure? I’ve最近在几篇文章中对此进行了讨论,包括 Use 蔚蓝App Insights to track events in your app/web part/provisioning code。我喜欢这样的想法:找出某个特定Web部件的运行频率,或者在您的应用程序中单击某个特定的选项卡– 和 it’将此类内容适当放置也非常简单。 应用洞察还具有出色的工具,可通过类似SQL的方式查询日志以及配置警报(例如,从客户端加载首页是否需要5秒以上的时间)。看一看!
  • 蔚蓝Functions
    • 如果你’一个Office 365开发人员’t implemented 一些 code in an 蔚蓝Function yet, I think it’s only a matter of time :) I have a slide which compares to 蔚蓝web jobs, but overall Functions can be used in so many more scenarios –包括在Web部件或PowerApp中单击按钮之类的内容,或者可能是从Flow或Site Designs模型中调出用于站点配置(通过队列触发器)
    • I also talk about how 蔚蓝Functions should typically be secured with AAD auth 在里面 real world. I demo’d一个SPFx Web部件,它使用SPO cookie auth替代adal.js或类似版本–这对(adal.js)的当前安排有一些好处,包括以下事实:同一页面上的多个Web部件没有’无需单独登录
    • It’同样值得了解的是,Visual Studio函数工具已经取得了多大的进步。当然,如今,VS Code在许多编码场景中都是很酷的孩子,但是对于C#函数,我觉得VS 2017实际上更强大– 一些 info on this:
      COB options for 蔚蓝Functions - CSharp
  • 蔚蓝SQL Database
    • 这里的主要要点是停止在SharePoint中存储应该以SQL格式存储的内容:) SP开发人员’接触SQL多年不应该’t be scared of 蔚蓝SQL – it’非常容易上手,您可以免费运行最大20GB的数据库
    • Also, be aware that identity 在里面 SQL world has been updated for the cloud. You can now use 蔚蓝Active Directory accounts to authenticate, including 从 tools such as SQL Management Studio 和 Visual Studio Server Explorer
  • ARM模板
    • ARM模板 offer an alternative to lots of button clicking 和 manual configuration 在里面 蔚蓝portal –非常适合将要部署到多个Office 365租户/ Azure订阅中且需要重复性的事物
  • 蔚蓝Queues (and triggers)
    • 队列是支持您可能在代码中完成的工作的重要构建块。每当您需要一些分隔或长时间运行的处理时,使用队列通常是一个不错的模式– one thing puts 一些thing on the queue, 和 一些thing called a QueueTrigger is used to point to 一些 code which does the long-running thing (e.g. create a SharePoint site). As mentioned previously, the 新 Site Designs model for site provisioning will use this, 和 so do SharePoint web hooks.
    • 在什么方面 your code might be, 蔚蓝Functions 和 蔚蓝web jobs are common –都可以像您期望的那样使用QueueTrigger

和以前一样,希望这里有一些有用的块对您有用!

    滑轨:

    张贴者 Chris O'Brien 06:45 0 comments 链接到这篇文章  

    2017年12月5日,星期二

    演讲台–SPFx开发中的陷阱

    这是第2个帖子中的第1个,用于发布幻灯片I’最近,特别是在都柏林举行的2017年欧洲SharePoint会议上,我们给出了这些建议。也可以看看:

    演讲台– Best bits of 蔚蓝for the Office 365 Developer

    不幸的是,我从不认为幻灯片会传达会议会议的所有信息,因为’演示通常是最有价值的部分。尽管如此,我还是尝试组装具有有用参考信息的幻灯片,因此希望对某些人有用。完整的幻灯片平台从SlideShare嵌入在本文的底部。我在这里讨论的主要主题是:

    • 版本和依赖性问题
      • 需要确保您使用 - 保存 要么 -精确保存 当添加库 npm安装 (以便将它们记录在您的package.json文件中,并且团队中的其他开发人员可以从源代码控制成功构建)
      • 语义版本控制,包括版本号中的插入符号和代字号
      • 需要跑步 npm收缩包装 每个版本的代码
      • [注意–npm 5中的某些更改会自动执行 - 保存 在进行安装时,还会自动生成一个 package-lock.json 文件(类似于 npm-shrinkwrap.json。但是目前,SharePoint Framework(SPFx)尚未正式支持npm 5,因此,这些要点仍然很重要)
    • 重用现有的JavaScript代码
      • 如果尚未将此类代码包装在模块中,则可以选择–这在TypeScript / JavaScript中提供了更正式的共享代码(例如库代码)的方法
      • 一旦您 have a module, you can look 在 options such as npm安装 [文件路径], npm连结 要么 使用由提供的私有托管npm存储库 npm私人套餐 要么 Visual Studio Team Services程序包管理
    • Office UI结构
      • 使用Fabric Core和Fabric React组件–从SPFx 1.3.4版开始,使用Core样式要简单得多, sp-office-ui-fabric-core 包被引用,并且SCSS样式使用mixins来引用自定义样式中的样式
      • 使用Fabric React组件时,通常应确保使用 静态的 链接您的导入语句,例如 import { Button, ButtonType } 从 'office-ui-fabric-react/lib/Button';
      • 看到 在SharePoint Framework中使用Office UI Fabric Core和Fabric React 有关此的更多信息
    • Calling the Microsoft Graph 和/or custom APIs (e.g. an 蔚蓝Function)
      • 所有这些资源都有可能通过AAD获得保护
      • GraphHttpClient 目前用途有限。
      • ..所以您很可能需要 adal.js 如果是从客户端致电,或者 ADAL.NET 如果从服务器端调用
      • 自定义Web API / Azure函数的adal.js的替代方法是一种利用SharePoint Online身份验证cookie将凭据传递到您的API的方法(使用 “credentials”: “include” 头er to pass across domains) –我认为这是一种有用的方法,我的一个演示对此进行了介绍(视频位于 //www.youtube.com/watch?v=Nz9Q8TDgYtk&t=5s)
      • 我使用这张幻灯片概述了这两种方法:

        图片
      • 另请注意,很快,可以通过指定其他AAD应用程序注册来调用您的自定义API,这些注册可以从SPFx调用而无需额外的同意。这将大大简化操作,这意味着您的SPFx Web部件/扩展不再需要登录按钮/过程即可调用下游资源。
    • 部署方式
      • 请记住,默认的SPFx行为适用于您添加的任何第3方库 捆绑到您的Web部件中 –这会增加捆绑包的大小,当您有多个Web部件/扩展都使用同一个库时,这可能是一个特殊的问题(而Office UI Fabric可能是其中的罪魁祸首!)
      • 另一个“by default”要记住的是,您构建的每个Web部件/扩展都可以获取它’s own bundle – the config.json 文件是什么控制
      • 在可能的情况下,应将第三方库外部化为CDN。
      • ..如果不是’t possible, consider SPFx组件包 作为一种避免在所有Web部件之间复制库的方法。如果页面上有5个Web部件都使用相同的库,则’第一次页面加载会降低外部性或使用组件包的性能

    希望在那里’这里有一些有用的信息,而我’在以后的文章中,最有可能在这些方面进行扩展。这里’s the slide deck:

    滑轨:

    张贴者 Chris O'Brien 11:10 0 comments 链接到这篇文章  

    2017年10月31日,星期二

    在2017年欧洲SharePoint会议上的演讲

    ESCP17徽标-500

    今年11月13日至16日’在都柏林举行的欧洲SharePoint会议’我期待在那儿讲话。这次活动看起来很棒,有令人赞叹的发言人名单和Microsoft的出色代表。 Jeff Teper将作主题演讲,其他Microsoft发言人包括Dan Holme,Mark Kashman,Chris McNulty,Vesa Juvonen,Mike Ammerlaan等。实际上,这是今年欧洲最大的SharePoint项目。

    I’我做了两个演讲,我都’之前已给出过,但已更新了最新动态中的内容。作为演讲者,’谈论一个持续相关的话题真是太好了,但是,哇,您当然必须检查所有信息块仍然有效,并且您’重新介绍最新动态。这些天的演讲厅里到处都是骂微软的人;)无论如何,我的演讲的细节是:

    蔚蓝- the best bits for Office 365/SharePoint developers

    11月14日,星期二-15:15-16:15

    蔚蓝– 那里’考虑了很多’s just a small word! As a skillset, 蔚蓝is practically mandatory for most Office 365 developers. Between 蔚蓝functions, web apps, 蔚蓝AD, BLOB storage, SQL Database, queues 和 web jobs, 那里 are a lot of useful building blocks –OfficeDev PnP等解决方案大量使用它们。可能是你’重新开始并想托管远程SharePoint代码(例如Office 365应用或提供商托管的SharePoint加载项),或者您可能’re familiar with many 蔚蓝bits but also have a list of “untouched” areas. In this session, 蔚蓝for Office 365 和 SharePoint developers, we’ll dig into the most relevant 蔚蓝capabilities, using real scenarios to show winning combinations such as SharePoint web hooks 和 蔚蓝functions.

    I’ve还添加了以下内容:

    • Graph bindings for 蔚蓝Functions
    • 应用洞察

    使用SharePoint框架(SPFx)避免常见的陷阱

    11月16日,星期四-15:15-16:15

    本届会议超出了“intro”级别的SPFx内容,以讨论在开始使用SharePoint Framework Real时的常见问题。我们’它将涵盖与TypeScript,npm和依赖项,SPFx安全性有关的陷阱,并重点关注与团队开发有关的挑战– including 新 causes of “它可以在我的机器上运行!”。也许您已有现有的JavaScript代码’d想与SPFx一起使用,所以我们’我会说比复制/粘贴更好的方法。我们’我还会看一下当您遇到陷阱时’准备发布SPFx Web部件的版本–从意外捆绑JS库到不“shrink-wrapping”您的依赖关系以实现可复制的构建。

    I’ve还添加了以下内容:

    • 正确使用Office UI Fabric,因为这是一项常见任务,比目前应做的要难
    • SPFx中的组件包–在Web部件和SPFx定制程序之间共享通用代码的能力

    更多信息

    如果你’还没走,我’d认真考虑研究它,并向老板询问可能性。以前的活动非常好,我认为内容始终是高质量的。门票仍然可用,您可以使用以下代码获得10%的折扣:

    ESPC17SPEAK

    您需要的链接是: //www.sharepointeurope.com/pricing/

    干杯!

    COB。

    张贴者 Chris O'Brien 15:40 0 comments 链接到这篇文章  

    2017年10月6日,星期五

    我的点燃愿望清单–交付了什么,没有交付了什么’t?

    在最近的Ignite会议之前的一两周,我发布了一份希望清单,希望微软能宣布。和我一样,这主要*主要*集中在Office 365以及SharePoint的构建和扩展上。我喜欢偶尔发布这些列表-它可以帮助我塑造自己的想法,并与时俱进“top of mind”Office 365中的最新发展,这将有助于我与之合作的组织。既然事件已经发生,在Ignite上会有许多公告–显然,现在整个Office 365都在进行大量的投资和开发,’是与Microsoft技术合作的绝佳时机。如果您想知道您是否为自己的职业生涯选择了合适的马(或为您的组织做出了正确的选择),我认为’这些天很难让人怀疑。但这就是说,我注意到我的愿望清单中的几个项目没有得到处理,因此我认为最好对这些项目进行反思。

    在开始讨论这些项目之前,我对Ignite有两个高级想法:

    • Hey, I see what you did 那里!
      • 尽管有*大量公告,但请注意每个公告的时间表。一世’我试图在下表中收集与我最相关的内容–但是我注意到,实际上许多人到2018年都还很遥远。这没什么错,但是我觉得也许微软采取了一种策略来提供一个“big wave”的公告,以提高整体效果,即使许多公告离发布都还很遥远(甚至“可能发生的事情”)。我想今天适合’s “disclosure strategy”一年中使用这2或3个大型事件进行公告的过程–坦率地说,与路线图的整体可见性相比,我更喜欢这样做。您只需要注意日期和注意事项即可。
    • Office 365和云收入推动了投资!
      • 还记得几年前人们在问SharePoint是否已失效吗?现在感觉就像一个不同的世界。我认为其中一个重要因素是,微软正在进一步提高Office 365的采用率,相应的收入和前景意味着可以设定雄心勃勃的目标。我可以想象各种产品组更大一些,拥有更多资源。另一个问题是,现在显然已经解决了许多基础架构/规模/基础挑战–更加注重为用户提供出色的工具和现代化的开发平台。

    我最初的愿望清单

    无论如何,回到我的清单– here’我说过微软应该提供的。我没有’将此博客发布,但奇怪地将其放在LinkedIn上-也许这是与 增强了LinkedIn和Office 365之间的集成 ;)

      图片

      什么 got delivered/announced, 和 what didn’t?

      我最初只是对每个项目进行了一些检查/划线,但是后来我添加了一些注释,然后添加了时间表,最后我得到了下表。这可能仅对我个人有用,但是,嘿,如果有的话’对您也很有用,那就太好了。它可能具有更全面的注释/链接,但是’这可能是我目前无法完成的任务!所以:


      项目

      宣布了吗?

      时间线

      笔记

      现代页面的标签/元数据

      并不是的

      2018年上半年

      “Categorization” mentioned for 2018

      将现有的SP网站与
      小组/团队



      2018年初

      PowerShell也将成为可能。看到“BRK2434 –没有团队现场”

      供应/模板
      通讯站点(理想情况下为PnP)



      2017年第四季度

      网站设计(以前称为“Recipes”).*请参见下面有关网站设计的特别说明

      通讯的页面布局
      网站



      2018年第一季度



      个人资料页面的可扩展性

      没有

      ?

      ?

      Web挂钩创建组
      (现场)

      没有

      ?

      没有 thing 即将来临, but a *custom*
      网站设计可以调出流程

      为团队配置/模板
      (标签,连接器,漫游器)

      没有

      ?

      ?

      更现代的Web部件(例如
      搜索)



      2017年第四季度
      • 计划者/表单Web部件
      • 对“突出显示的内容” Web部件的增强(提供查询)
      • 增强的Web部件选择器

      SPFx增强




      • 网站脚本/网站设计 (2017年第四季度)
      • 简化了由AAD保护的调用Graph /自定义Web API
      • 网站集应用目录等 (2017年第四季度)

      一些‘under the radar’ things!




      • 多地域 (现在是OneDrive / EXO,2018年是SPO)
      • 集线器站点 (2018年初)
      • OneDrive文件按需 (2017年第四季度)
      • 每个站点的条件访问 (2018年初)
      • 更简单的共享,例如外部用户的验证码链接 (2017年第四季度)
      • 列表增强功能格式化,关注视图,索引编制和流程改进等。 (2017年第四季度)
      • 更好的网站/内容分析 (2018年初)
      • LinkedIn与Office 365人卡集成 (2017年第四季度)

      以前宣布的,
      但尚未交付




      • 新管理中心 (2018财年早期的首次发布租户)
      • 应用启动器更新
      • PowerAppsfor SharePoint lists (FR租户于2017年10月)
      • PowerApps增强功能,例如上传附件,更简单的条件视图等。 (2017年底之前)

      注意:– I’d很乐意听到任何发现错误或我错过了这些细节的人(例如时间轴)。如果您不这样做,请发表评论’t mind 和 I’ll update!

      我的想法–特别是缺少的物品

      所以微软没有’不能提供我所希望的一切。但是,他们确实提供了很多以前没有的东西’在我的清单上!我在其中列出了大多数“under the radar” 和 和 “先前宣布,但尚未交付”类别。我们MVP非常幸运,他们中的大多数人都有自己的内幕(感谢Microsoft,顺便说一句,您在这里的工作受到了极大的赞赏),所以在活动开始之前,我对他们非常熟悉。它’那些类别有很多项目真是太好了,并且无疑可以添加更多的项目。但:

      •  现代页面的标签/元数据
        • 令我失望的是,我没有听到更多有关此消息的信息。在围绕现代页面构建解决方案时,尤其是在汇总和显示不同类型的内容(例如标有X的页面)时,感觉仍然存在很大差距。是, 那里’s a 新 PnP re-usable control, 但是你’d必须做一些工作来整合它,就像微软一样’s job to be honest.
      • 个人资料页面的可扩展性
        • 依然没有。什么’同意吗?这已经讨论了很长时间了,但是我们仍然可以’添加自定义窗口小部件或定制Office 365 / Delve配置文件页面。我没有’说实话,甚至没有听到任何提及,但是我与之合作的许多组织都希望在那里做点什么。
      • 组创建上的Web钩子(站点)
        • Again, nothing 这里either. 维萨 已经提到了有关提供此功能的一些工程方面的考虑,但是我希望能有所作为,以便将自定义PnP模板应用于自助创建的Office 365组网站将变得更加容易。当然,可以将Flow与即将推出的“网站设计”功能配合使用,但是对于那些没有 ’不要使用任何类型的网站设计,例如开箱即用的Group网站。该信息仅在昨天发布,因此我可能会丢失一些内容– hope so..
      • 团队的配置/模板(选项卡,连接器,机器人)
        • Microsoft Teams取得了很多进步,但仍然没有合适的模板故事。我真的很惊讶,没有听到这样的消息-我确实有一些客户想要大规模使用Teams,但是使用相同的自定义标签集等。手动配置只是’t an option, so let’希望很快就会有希望(再次,除非我错过了)。

      当然,让我知道我是否遗漏了任何东西,或者您不同意我对事物的解释。

      *网站设计注意事项

      因此,我们确实有一种将模板应用于通信站点的方法(而且不仅如此)–网站设计还可以应用于通过开箱即用的UI创建的团队网站,因此这很重要。但是,现在我确实对这里的模型有所保留。显然在那里’现在定义网站模板的另一种方法(Site Designs使用的JSON格式,’看起来太难于实际使用–似乎有很多属性/动作需要理解),并且考虑到PnP设置构件已经发展了很多,这感觉不是很理想。我们可以*集成即插即用配置(woohoo),但是架构是站点设计> Flow > 蔚蓝queue item >QueueTrigger / Azure函数>我的PnP设置代码。很好,可以打很多框,但是:

      • 坦白说,我宁愿使用某种形式的Microsoft托管我的PnP设置模板并负责执行。 The fact that we still need 蔚蓝can be a blocker for 一些 要么ganizations, 和 means 那里 is still a level of complexity, 和 a chunk of work for us to do. It was pointed out to me that Microsoft may have chosen this approach because they don’我不想自己托管/支持即插即用配置(作为社区的工作,而不是纯粹的Microsoft),我想我实际上可以理解。但是还是
      • 模板Office 365组网站似乎仍然存在差距。 是的,我可以调出我的流程来查找*具有*自定义网站设计的网站–但是随着用户创建组/团队/计划者计划/ Power BI工作区等而涌现的组站点又如何呢?那里’可以在租户级别指定默认网站设计的方法,但这是否适用于组网站?一世’目前尚不清楚。但我当然希望能够将自定义模板应用于与组连接的站点 及时地.
        • 更新 –发布后仅几分钟,我就从下面链接的视频中了解了细节,可以将现成的网站设计定位为开箱即用的网站。这是通过将您的网站设计与WebTemplate =相关联来完成的”64”组网站或WebTemplate =”68”交流网站等。快乐的日子。

      我还是觉得’拥有另一种模板语言/方法实在令人遗憾。模板的哪些位将在“站点设计”中完成,哪些在PnP模板中完成?我可以想象有很多不同的方法用于此。但是,当然,主要的优点是这种模板形式与开箱即用的UI集成在一起以创建SharePoint网站,这带来了很多可能性。我只是想知道最后 ’ll be implementing “shell”网站设计调用PnP模板,该模板可以完成在网站中创建内容类型/列表/页面/ Web部件等的实际工作。让’s see..

      有关网站设计的更多信息,请参见 //techcommunity.microsoft.com/t5/SharePoint-Developer/SharePoint-Patterns-amp-Practices-PnP-Core-and-PnP-PowerShell/m-p/114082#M3496

        结论

        尽管未选中我列表中的所有项目(当然这只是一个人的观点)–其他每个人也都有自己的优先事项),我认为微软实际上超出了我的期望。是的,总会有差距,正如您可以想象的那样,有很多东西我’我不在这里覆盖。无论’s general developments such as 新 Office 365 Plans 要么 Bing for Business, the raft of enhancements to Microsoft Teams (e.g. taking the place of Skype for Business for online), 要么 developer-focused things such as Graph enhancements (e.g. 延期s in 蔚蓝Functions, SP list data 在里面 Graph 等等), 那里’还有很多其他事情要跟上。进一步阅读的一些好起点是:

        张贴者 Chris O'Brien 15:19 8 comments 链接到这篇文章  

        2017年9月20日,星期三

        Use 蔚蓝App Insights to track events in your app/web part/provisioning code

        在我最近的帖子中 Add 蔚蓝App Insights 要么 Google 分析工具 to your SharePoint pages with an SPFx应用程序定制程序 我们专注于 页面跟踪/分析 应用洞察的功能。但是我真正认为很棒的是能够跟踪代码正在发生的事情– whether it’仅表示您的Web部件已执行或您的应用已启动(因此您可以获得计数),或者您向用户显示了错误消息(带有详细信息),或者可能是为了了解用户在您的应用中导航的位置,或者他们选择了哪些选项。例如,我们在一个特定的应用程序中有一个选项卡式界面,’d非常希望知道实际上有多少用户导航到第二和第三选项卡(我敢打赌)。好吧,App Insights事件跟踪非常适合这些情况以及更多情况。我用此列表完成了最后一篇文章:

        • 服务器端应用程序(Office 365 / SharePoint加载项)
          • 有多少次应用启动?由谁/在哪里?
          • 应用内发生了什么(例如,正在单击哪些按钮/正在使用哪些功能)?
        • SPFx /图
          • 我们的Web部件每天获得多少次执行?
          • 我的Web部件在客户端执行需要多长时间?
          • 我的异步调用需要多长时间(例如,到图表)?它们对世界各地的用户有何不同?
        • 供应代码
          • 我们每天/每周/每月创建几个站点?
          • 我们在配置期间遇到了多少次问题?
          • 置备需要多长时间?
        • 一般
          • 我们向用户显示错误消息多少次?

        你明白了。

        快速入门概述(适用于JavaScript / SPFx)

        Remember that to use 应用洞察 you need an 蔚蓝subscription 和 an 应用洞察 Resource to be created – this will give you the instrumentation key which you obtain 从 the 蔚蓝portal (see 我最后的帖子 for more details). 如果你’正在使用JavaScript / TypeScript / SPFx’可以安装的npm软件包:

        npm i applicationinsights-js  - 保存

        从那里,您将需要几行帮助您入门。模块顶部的import语句:

        import {AppInsights} 从 "applicationinsights-js";

        ..然后是引用您的App Insights密钥的初始引导程序代码:

        let appInsightsKey: string = "[YOUR KEY FROM THE AZURE PORTAL HERE]";
        
        AppInsights.downloadAndSetup({ instrumentationKey: appInsightsKey });

        现在,您可以将代码中发生的各种情况记录到App Insights中。本质上,当我们想记录发生了什么事情时,我们在一行中插入一行-让我们看一些示例。

        例子1–记录对Microsoft Graph的调用(使用SPFx代码)

        下面的代码以SPFx代码获取当前用户的日历事件,该代码取自 SPFx React样本之一。这是Microsoft Graph的相当典型的用法,此处使用的日志记录方法可用于许多类似的情况。它在React组件中的事实并不重要,但是要重点关注的是对App Insights的调用-请注意,’我还在做的是记录通话所花费的时间,以及发现我的Web部件被使用了很多次之后,我还开始了解到Graph通话对世界各地的用户花费了多长时间。为此,我只需在调用之前创建一个时间戳,然后再创建一个 在承诺中,一旦获取数据即执行和subtract the difference:

        然后,在App Insights中,我可以看到Web部件每次执行的事件以及调用图形所花费的时间:

        SNAGHTML1f5d5c2c

        SNAGHTML203e67e

        正如我在上一则App Insights帖子中所显示的那样,当您积累数据时,可以使用‘Analytics’App Insights中的“部分”以根据需要进行过滤和排序(例如,在“ timeTaken’ value):

        SNAGHTML1f6b05fa

        例子2–在站点设置/模板代码中记录呼叫

        以便 ’s是登录SPFx的示例。作为不同的口味,让’说您正在基于模板创建一些SharePoint网站–也许作为自助式网站创建工具的一部分。您可能对以下内容感兴趣:

        • 正在创建多少个站点?有什么细节?  
        • Office 365需要多长时间创建基本网站集?
        • 您的模板要花多长时间?

        在这种情况下,您’我可能会在C#代码中使用PnP Core库– so you’将需要来自以下位置的App Insights nuget包: //www.nuget.org/packages/Microsoft.ApplicationInsights/

        要开始使用C#代码,您需要’需要一些引导代码:

        // 在 top of 类..
        using Microsoft.ApplicationInsights;
        
        // to initialize..
        TelemetryClient telemetry = 新 TelemetryClient(); 
        telemetry.InstrumentationKey = APP_INSIGHTS_KEY;

        作为第一种情况,让’s say you want to log the fact that a site collection was created 和 how long that step took. 如果你’重新使用PnP设置代码,它可能类似于以下内容– the key things are:

        • 简单使用.NET秒表时钟进行计时
        • 的制作‘metrics’ 和 ‘properties’字典将详细信息传递给App Insights
        • 使用TrackEvent()方法实际记录数据

        如果使用PnP设置代码,则可能会得到以下结果: 

        This would then show up in 应用洞察 with details of the SharePoint URL, 和 the time taken for site collection creation (shown 这里in the 分析工具 tool):

        SNAGHTML16524535

        We can 延伸 this to PnP templating too. In a similar way, I would add logging statements around PnP 'ApplyProvisioningTemplate' call, 和 perhaps log any errors too.

        代码示例:

        如预期的那样,然后您可以获取所应用模板的详细信息以及所记录的任何详细信息(本例中为站点URL,模板ID和处理时间):

        SNAGHTML1f82d233

        概要

        应用洞察非常适合将其集成到各种Office 365和SharePoint开发人员中。通过简单地在代码中添加几条语句,您可以稍后对其进行报告,并获得比所可能具有的更好的可见性。无论’Web部件的执行情况,发生的错误或用户沿着应用程序中的特定路径浏览的频率,’这是轻松构建此登录的好方法。就实用性而言,您当然需要Azure订阅,并且如果您每月(在撰写本文时)传递的数据量超过1GB,则App Insights是收费的。但是,你不’不需要构建任何类型的前端或查询工具,您就可以获取图表/图表,每周摘要电子邮件,并且重要的是, 警报 如果不满足您定义的任何条件。此外,还有很多方法可以与数据集成(包括BLOB下载以使数据保留更长时间)。综合考虑,这些功能都很棒。

        我认为Office 365和SharePoint开发人员肯定没有充分利用App Insights,但是有很多可能性。一世’我期待将其纳入我们的更多解决方案中!

        张贴者 Chris O'Brien 11:50 2 comments 链接到这篇文章  

        2017年9月11日,星期一

        管理跨SharePoint网站的租户范围的SPFx扩展

        正如我在 Use an SPFx应用程序定制程序 to add JavaScript (e.g. 头er) to every page in a site,’s now possible to *globally* deploy SPFx 扩展名 (e.g. page 头ers, footers 要么 other random pieces of JavaScript) 要么 do a controlled roll-out across *many* SharePoint sites - without the app needing to be installed to each individual site. This is great 新s, 和 it was a gap for modern pages until now. SPFx 网页部分 在SPFx中,部署在租户范围的部署将出现在选择器中的所有位置 扩展名那里 is still 一些thing you need to do locally, 和 that’s “associate”您的扩展程序包含网站/网站/列表/字段。对于应用程序定制程序,它’此步骤可让您精确控制使用扩展程序的站点。为此,您需要在网站或网站上添加CustomAction,并在ClientSideComponentId属性(SPFx的新增功能)中指定扩展的GUID。虽然我’在本文中,我们将重点放在网站级别的自定义(应用自定义程序)上,’类似的故事 SPFx字段定制器 也(在字段上指定了ClientSideComponentId)并且 SPFx命令集定制器 (在列表上指定了带有ClientSideComponentId的CustomAction)。所有这些可以通过以下两种方式完成:

        • 使用CSOM或REST–也许用PowerShell或C#代码
        • 作为PnP XML的一部分,如果您要将自定义模板应用于网站–XML模式和PnP Core设置库现在支持此功能(自2017年9月版起)

        在这篇文章中,我’将提供一些PowerShell和C#代码,以帮助您在站点中应用应用程序定制程序–您可以为其他类型的定制器进行修改而不会带来太多麻烦。但是,在所有情况下都有一些先决条件-在某些方面,关联步骤是您要做的最后一件事。因此,让我们快速介绍一下:

        租户范围的SPFx扩展-概述/先决条件

        从SPFx v1.2起可以使用SPFx扩展和Webpart。大致来说,使用本文中的脚本/代码所需的先决条件是:-

        • 您指定了 "skipFeatureDeployment": 真正 在里面 package-solution.json 文件
        • 打包该应用程序,然后将其安装到应用程序目录中,管理员选中了“使该解决方案可用于组织中的所有站点”框(如下图所示)
        • SPFx应用程序的JavaScript软件包已部署到CDN或其他Web托管位置

        这是管理员在安装到App Catalog时将看到的内容,以及在安装时出现的复选框(他们需要检查) "skipFeatureDeployment": 真正:

        SNAGHTMLf7281c2

        PnP XML选项

        在本文中,我将重点介绍C#/ PowerShell选项,但是’s a PnP XML option which is very useful too. This allows you to 包括 the association as part of a custom site template, 和 那里fore is great for any sites being 新ly-created 从 such a template. In fact, you could also use it to apply a ‘partial’模板添加到现有站点,但是我认为大多数人可能会选择PowerShell或C#代码。我想在这里传达的主要信息是可以从 版本2.18.1709 从...开始 即插即用核心 (2017年9月版)。 2017-05模式有地方指定 ClientSideComponentId 属性在CustomAction和字段上,因为’关联由什么组成。在Web级别提供应用程序定制程序的XML摘录为:

        在下一节中,我’首先介绍PowerShell,然后介绍C#。

        使用PowerShell代码和PnP PowerShell

        以下是一些PowerShell函数,可通过在根网站级别添加自定义操作来在整个站点中添加,删除和列出SPFx全局扩展–调整是否需要其他东西。我在这里使用一个简单的站点URL数组,但是您可以随意填充该数组。其他说明:

        • 我正在使用 PnP PowerShell cmdlet这里 - you'll need to install those if you don't have them already, 和 then get connected to your tenant with 连接即插即用 等等
        • 在撰写本文时,我对它们提供的PnP cmdlet有所疑问(Add-PnPCustomAction),所以我在'add'方法中使用了直接CSOM。 我提出了GitHub问题 关于此问题(也在下面脚本的注释中指出),我敢肯定他们会尽快修复(或告诉我我做错了;),但直接CSOM方法也可以工作)
        输出:

        在以下位置注册全球部署的扩展 addSpfxExtensionCustomAction(ctx) 会给:

        SNAGHTMLf6529dd

        在网站上列出扩展程序:

        Get-PnPCustomAction -Web $ ctx.Web |哪里对象{$ _。Location -eq"ClientSideExtension.ApplicationCustomizer" }

        会给:

        SNAGHTMLf67a240

        删除扩展

        Remove-CustomActionForSPFxExt $ spfxExtName $ site $ ctx

        会给:

        SNAGHTMLf69e124

        使用C#代码和PnP内核

        但是,也许您想使用C#代码而不是PowerShell。一些注意事项:-

        • 我在这里使用PnP Core库-您需要将NuGet软件包安装到解决方案/ Azure Function /如果没有的话,无论如何。从这里得到 //www.nuget.org/packages/SharePointPnPCoreOnline
        • In contrast to the PowerShell above I'm only processing a single site here, but it would be trivial to 延伸 the code to run across whatever sites you need

        样例代码:

        输出:

        当你’d期望,在以下位置注册全球部署的扩展程序 addSpfxExtensionCustomAction(ctx) 会给:

        SNAGHTMLf59848b

        在网站上列出扩展 getCustomActions(ctx) 会给:

        SNAGHTMLf55b850

        删除扩展 removeSpfxExtensionCustomAction() 会给:

        SNAGHTMLf5790d9

        另一个option – CLI scripts

        另一种选择是,请注意我尊敬的同事 瓦尔达曼·德什潘德 它还具有超酷的CLI工具,可帮助您管理SPFx扩展。他’如此时髦;)他的脚本也提供了管理SPFx命令集定制器的功能。看到 //github.com/vman/spfx-extensions-cli 更多细节。

        概要

        对于租户范围的SPFx应用程序自定义程序,您需要确保使用它的网站或网站具有带有扩展程序的ClientSideComponentId的CustomAction(除了处理其他先决步骤,即获取应用程序包和相应的JavaScript捆绑包) 。尽管此代码未解决,但它’对于SPFx字段自定义程序和命令集自定义程序也采用类似的方法。希望本文介绍的选项(以及潜在的PnP令人敬畏)是有用的。

        张贴者 Chris O'Brien 13:38 0 comments 链接到这篇文章  

        2017年8月17日,星期四

        Add 蔚蓝App Insights 要么 Google 分析工具 to your SharePoint pages with an SPFx应用程序定制程序

        蔚蓝App Insights is fantastic to help understand how your site 要么 app is being used, 和 I’在以后的文章中,将花更多时间在此上。现在,让’s从一个简单的案例开始–您想知道有多少用户访问您的SharePoint网站,哪些页面最受欢迎,用户所基于的国家等。我们可以使用以下方法将页面跟踪添加到现代SharePoint网站(无法自定义母版页来添加脚本)中的所有页面: SPFx应用程序定制程序 – previously, script 在现代页面上was a problem but it is is easily possible now. Of course, the same approach can be used to add Google 分析工具 要么 other similar tracking scripts. However, whatever script you’重新添加您应该考虑:

        • 如果你r site has 经典 也有SharePoint页面,SPFx App Customizer不会涵盖这些页面– you’为此,将需要一种单独的方法,例如使用“自定义操作”在其中添加脚本。 (注:这主要是仅针对发布网站或较早的团队网站–Office 365组网站,现代化的团队网站和交流网站只有现代化的页面。)
        • 随SPFx App Customizer添加的任何脚本也将出现在系统页面上,例如列表/库页面或“网站内容”页面。这可能很有用,因此您可以查看访问量最大的库,但是您可能会决定只使用真正的页面,然后添加几行代码来过滤掉这些页面– up to you.

        Regardless of which page tracking system you use, to get this added to modern SharePoint pages the starting point is always to create an SPFx应用程序定制程序. 如果你 need a getting started guide, I wrote about these in Use an SPFx应用程序定制程序 to add JavaScript (e.g. 头er) to every page in a site – in this post I’ll focus on the specific code snippets to add Google 分析工具 要么 蔚蓝App Insights page tracking, 和 then talk a bit more about 应用洞察.

        Integrating Google 分析工具

        好,让’我们先把它弄清楚。对于GA,您只需要将脚本引用添加到页面–而且由于Google为您提供了一些JavaScript代码,因此动态添加某些脚本的经典方法就可以很好地工作(与使用可与外部脚本一起使用的SPFx模块加载器相反)。

        可以在自定义程序的onInit()方法中执行此操作,因为Google的代码指定应异步加载脚本-因此浏览器不会仅出于分析目的而延迟加载页面。并不是说选择SPFX App Customizer的Render()方法反而会带来巨大的变化,但是在任何情况下,onInit()都可以很好地解决这一问题。

        整合App见解

        应用洞察随附具有各种对象和方法的SDK(可以使用客户端SDK和服务器端SDK)-可以说,这比Google 分析工具(分析)更容易添加。对于客户端Web应用程序(例如SPFx),存在’s an npm package (applicationinsights-js),因此一旦创建了SPFx应用程序自定义程序,您就可以开始使用:

        npm i applicationinsights-js  - 保存

        在代码的顶部,您’然后,需要导入App Insights模块以使用它:

        import {AppInsights} 从 "applicationinsights-js";

        Just like with Google 分析工具, one of the other first steps is to ensure you have the service set-up. 在这种情况下,您 need an 蔚蓝subscription 和 an 应用洞察 resource - this will provide a tracking ID to use in your code:

        SNAGHTML1e867b14

        An 应用洞察 resource will be automatically created for any 蔚蓝web apps you have in your subscription (e.g. you might have 一些 Office 365 apps 要么 provider-hosted SharePoint add-ins 那里), but if none of those are appropriate you should create a 新 instance. 一旦您 have the instrumentation key, the code you need is this:

        上面显示的代码赢了’将App Insights JS包含在您的捆绑软件中– the AppInsights.downloadAndSetup()method just references Microsoft’CDN上的JS。跟踪页面浏览量的核心方法很简单:

        AppInsights.trackPageView();

        现在,您可以使用Application Customizer选择是通过在现代页面的URL中添加参数,还是在调试模式下对其进行测试,或者将其打包以作为应用程序包进行实际部署,然后添加到您的身边(我以前的文章 详细介绍了这两种方法)。一旦代码执行完毕,’ll see results over 在里面 蔚蓝portal for any users hitting pages which run that line of code, 和 you can now track page load performance 和 other things. Just like other analytics software, various details about the user (location, browser, device 等等) will be recorded:

        SNAGHTML19ce5502

        SNAGHTML19d0667d

        但是,当我们通过更改代码以在跟踪请求时传递更好的数据来提供帮助时,事情会变得更加有趣。可以使用的另一个重载是:

        因此,您可以选择记录有关页面请求的一些有用信息:

        • 用户登录
        • 用户显示名称
        • 如果用户是外部用户

        特别是我们可以使用‘dimensions’参数以传递此类数据。在SPFx中,该代码如下所示:

        警告!

        当然,请小心存储用户的个人身份信息(PII)!我仅将其用作完成操作的示例-但在现实生活中,您可能需要存储某种实际上不允许识别个人身份的用户令牌。

        但是其他形式的用户信息呢?通过还从用户的Office 365 / SharePoint用户配置文件中获取一些数据,您可以回答以下问题:

        • 我的大多数用户来自哪个部门?
        • 我的大多数用户来自哪个地区?
        • 有多少导演/经理正在访问该网站/应用程序?

        毫无疑问,还有许多其他可能性。不幸的是,除非您进行一些自定义的工作来将其放回原处,否则您会丢失页面持续时间的计时,并带有更详细的过载信息。–具体来说,编写一些代码来记录浏览器事件的计时,然后在上面的重载中使用final参数。如果这样做,请务必使用浏览器事件(例如load事件)而不是简单的秒表,因为在SPFx App Customizer中执行的代码当然只是整个页面加载的“一部分”。

        But now I have my page views tracked, 和 I can do 一些 nice analysis 在里面 蔚蓝portal. I can create 一些 charts in Metrics Explorer (and 一些 charts 和 tables *are* generated automatically), but the 分析工具 tool is even more powerful. This definitely isn’作为最终用户/站点所有者工具,但是,作为技术人员,我可以使用带有Intellisense样式自动完成功能的简单语法进行一些查询:

        SNAGHTML19e93f15

        (注:这些结果包括页面加载持续时间,因为它们使用了简单的重载)。

        当您将自定义信息作为呼叫的一部分 trackPageView(), 默认 this comes out in a “customDimensions” column as JSON:

        SNAGHTML1aa6f52f

        ..但是’如果您想对其进行排序/过滤,效果不是很好。您可以使用“extend”App Insights查询中的关键字来解决此问题–因此,要展开我们之前记录的3个自定义数据位,我们可以使用:

        pageViews |
        where url !contains "workbench" | 
        extend userLogin = tostring(customDimensions.userLogin), userDisplayName = tostring(customDimensions.userDisplayName), isExternal = tostring(customDimensions.isExternalGuest) 

        ..现在我们在单独的列中获取该数据:

        SNAGHTML1ab5c82b

        现在,您可以随心所欲地使用这些数据。

        因此,总的来说,添加页面跟踪相对简单,您可以在移动时找到分析数据的最佳方法。重要的是首先使用默认的调用将其捕获 trackPageView() 或更高级的带有自定义数据的数据。

        应用洞察数据保留

          在这一点上’可能值得记住的是,App Insights只能保留90天的数据,因此’您可以在单个查询中分析的最长时间。但是,如果您需要更长的时间,可以进行设置 连续出口 to copy your data out (to 蔚蓝BLOB storage) 和 store it forever. Working with it becomes slightly different, but 那里 are details on that page.

          超越页面跟踪

          我在这里提到页面跟踪是因为’这是一个相对简单的案例,可与SPFx应用程序自定义程序很好地结合在一起。但是,我认为App Insights的其他用例也许更有趣。我*真正*认为有价值的是丢弃的想法 AppInsights.TrackEvent() 您的代码中的语句,无论是否’SPFx Web部件,自定义Web API,Office 365应用或提供程序托管的SharePoint加载项(例如MVC网站)。一世’我会在以后的文章中讨论这一点,但是我喜欢以下场景的想法:

          • 服务器端应用程序(Office 365 / SharePoint加载项)
            • 有多少次应用启动?由谁/在哪里?
            • 应用内发生了什么(例如,正在单击哪些按钮/正在使用哪些功能)?
          • SPFx /图
            • 我们的Web部件每天获得多少次执行?
            • 我的Web部件在客户端执行需要多长时间?
            • 我的异步调用需要多长时间(例如,到图表)?它们对世界各地的用户有何不同?
          • 供应代码
            • 我们每天/每周/每月创建几个站点?
            • 我们在配置期间遇到了多少次问题?
            • 置备需要多长时间?
          • 一般
            • 我们向用户显示错误消息多少次?

          当然,一旦您开始考虑,就有上百万种可能很容易追踪的东西。一世’在下一篇文章中将详细讨论跟踪事件。

          张贴者 Chris O'Brien 06:43 1条评论 链接到这篇文章  

          2017年6月29日,星期四

          Office 365开发人员愿望清单(SPFx和现代站点),2017年夏季

          显然我们’re in a 过渡时期 in Office 365 在 the time of writing (June 2017), where modern SharePoint experiences are available - modern sites 和 pages for example - but not everything is fully joined-up yet. That said, it’瞬息万变的景观,是顾问的一部分’其作用是跟上提供解决方案的最佳方法。一次,我希望这是一篇博客文章,可以很快–当然,我必须添加一些信息’我一直在写它,而我’随着事情的宣布/发布,我将再次回来并更新下表。

          回到那个‘transitional period’-对于具有协作工作负载的组织,情况尤其如此’需要为团队网站创建某种网站模板。即使对于我们的客户来说,这仍然很常见’只需提供不同的首页体验或向站点添加一些列表/库/内容类型/全局管理员即可。毕竟,我认为无论Microsoft提供什么作为默认体验,许多组织都可以从对此的一些轻量级更改中受益–因此,网站模板在SharePoint中仍然很重要。我希望微软不要’不要忽视这一点。当然,当我考虑我的愿望清单时,有很多项目与 “大规模地进行团队协作” in SharePoint – so perhaps let’首先考虑一下。

          当前站点模板挑战

          当前站点模板具有挑战性,因为:

          • 要使用网上论坛网站吗? 好吧’目前很难模板化这些模板,因为:
            • 能够’当前指定自定义模板
            • 能够’t currently be notified that a 新 site has been created, because 那里 are no web hooks
              • [顺便说一句,我同意  ways around this (e.g. web job/function which polls for 新 sites), but none are pretty because users may start using the site in one state, only for it to change as they are working in it..]
          • 是否要使用非Group SharePoint网站? 目前很难为这些模板提供模板并获得现代体验,因为:
            • 甚至模式和实践(PnP)站点模板都没有’当前允许配置现代页面– 在 least, not without 一些 dev effort to 延伸 it

          对于不这样做的客户’如果不想使用网上论坛,第二种方法对我们来说已经很普遍了。但是,如果更多地投入/减少工作量,那就太好了。它’我知道即将到来(请参阅下表中的信息),但是’在沿途抚弄人没有害处;)

          我目前的愿望清单

          这里’是PowerPoint幻灯片的摘录,我最近讨论了我当前的清单“asks” to Microsoft:

          SPFx和现代页面的愿望清单-2017年6月

          让我详细介绍一下:

          事情

          状态(2017年6月)

          笔记

          SPFx Web部件的全球部署

          • 不需要将SPFx应用安装到每个站点
          • Ideally 在 different 范围 e.g:
            • 某种类型的所有网站,例如所有小组站点,所有常规团队站点等。
            • 行李袋中带有X的网站
            • 除[列表]外的所有网站集
            • 等等

          部分解决方案“imminent” (weeks not months)

          2017年9月5日 – now delivered, see //dev.office.com/sharepoint/docs/spfx/tenant-scoped-deployment

          请参阅本文结尾处的幻灯片。最初的解决方案将允许Web部件可跨站点使用,但无需过多控制(例如,“scopes” examples).

          扩展PnP模式以包括配置现代页面和Web部件

          • 需要允许提供团队站点*以现代页面作为主页*–没有代码/即插即用可扩展性提供程序)

          预计在下一版的PnP Core(2017年8月版)中发布。它’已在XML模式中...

          更多网钩

          没有 新s

          I’d想查看用于以下方面的网络挂钩:

          • 网站创建,例如集团网站
          • 子网站创建
          • 清单建立
          • 权限变更
          • 其他变化

          取消限制“no script”网站(尤其是物业包)

          • 需要为Group网站(或其他具有“no script” enabled
          • 在许多自定义方案中,写属性包很常见

          做完了!

          It’现在可以禁用“no script”在现代团队网站(包括小组网站)上。的 自定义现代团队网站 页面已更新以反映此内容(2017年6月26日)

          缺少控件和标记支持

          • 分类控制
          • 人/组控制
          • 日历控件(适用于非组网站)
          • 完整内容搜索Web部件(或类似内容)

          没有 specific 新s

          团队网站中的现代页面非常适合编辑和显示,但是目前在某些类型的内容和标记方面还不够好。缺少控件包括我’已列出(很难有一个“Page contact” 要么 “Site owner”(例如),但由于“网站页面”内容类型上的(缺少)字段,因此也缺乏标记/元数据支持。在当前的安排中,使用过滤器汇总这些页面非常棘手。

          页数

          • 多列支持
          • 固定横幅/标题高度

          未来“soon”

          2017年9月5日 –现在已交付,请参见“Section layouts”此帖子的“传播网站”部分(但请注意,相同的页面模型也适用于团队网站中的现代页面)- //techcommunity.microsoft.com/t5/SharePoint-Blog/Reach-your-audience-via-SharePoint-communication-sites-in-Office/ba-p/70079

          这些页面的灵活性存在更多已知问题–特别是单列方面。但是,这对于Microsoft来说是一笔微不足道的成果,我认为这些问题很快就会解决。

          扩展SPFx扩展模型(奖励项目)

          没有 specific 新s

          定位的其他领域,而不仅仅是“PageHeader” 和 “PageFooter”。该产品小组表示,将在团队站点(可能也是通信站点)中为现代页面提供更多区域。

            关于第一个项目,SPFx Web部件的全球部署,Vesa最近使用这张幻灯片来讨论’s coming:

              SNAGHTML46ce695

              这听起来像是一个合理的计划,因为至少长期解决方案可以使我们完全掌控。短期解决方案显然意味着所有SPFx Web部件到处都是可用的(例如,在我的团队站点,我的Intranet和我的通讯站点中),因此可能没有长期的安排’t too far away.

              通讯网站

              通讯站点开始启动,Microsoft’s “Ask Me Anything”会议是昨天(2017年6月28日)。令我感到失望的是,我没有听到有关通信站点模板的任何详细信息,因此这肯定是另一个愿望清单。我知道有“new”为即将到来的人提供模板选项,但我仍然希望能够使用PnP网站设置和XML–毕竟,我们仍然需要控制和能力来指定PnP提供的网站模板的所有方面,所以为什么要使用另一种方法?而且,我之间不匹配’在其他任何地方以及对于通讯站点而言,网站也将不是最佳选择。希望在那里也可以进行PnP配置– I really hope so!

              什么 else?

              我当然可以想到其他一些项目。但是我想念什么’目前在您的清单上?

              更新2017年7月26日–等等,我怎么想念缺少Microsoft Teams的API?同样,我知道’s coming, but I’很期待来创建用于相应的选项卡和连接器,以及(旁边的办公室365组/ SharePoint站点也许)编程创建团队的能力的团队模板的能力。希望不要等待太久!

                张贴者 Chris O'Brien 07:53 2 comments 链接到这篇文章  

                2017年6月11日,星期日

                Use an SPFx应用程序定制程序 to add JavaScript (e.g. 头er) to every page in a site

                [2017年9月更新了SPFx 1.2 RC0]

                用于自定义Office 365中现代SharePoint网站和页面的新工具已经到来(在撰写本文时进行预览,2017年6月)。  These are known as “SharePoint Framework(SPFx)扩展”,并替换一些SharePoint开发人员长期用于提供关键方案的工具,例如:

                • 将JavaScript添加到站点/网站中的每个页面
                • 在每个页面中注入一些内容(例如,巨型菜单/全局导航或消息栏)
                • 集成弹出对话框
                • 将项目添加到SharePoint中的某些工具栏/菜单
                • 更改列表中特定字段的呈现/行为

                换句话说,SPFx扩展提供了与CustomActions和JSLink等效的功能–以前的开发方法没有’不一定要翻译成现代网页。

                在本文中,我想重点介绍上面列出的前两种情况(粗体)–在每个页面上引用一些JS,并运行一些代码以将某些内容放置在页面的页眉区域中。 Microsoft提供的文档在第二种情况下做得很好,但有时’有一点点视觉效果很好,所以我’将提供更多屏幕截图。一世’我还会谈谈你不这样做的情况’不一定要在页面上添加*内容*,但是您确实想添加*其他形式的脚本*以在每个页面上运行(例如,分析/其他)。

                在向页面中注入内容方面,我们现在在现代页面中具有以下区域(注:这些是从SPFx 1.2起的名称):

                • 最佳
                • 底部
                • 对话框容器

                N.B.我们可以期望将来有更多区域!这里’顶部(页眉)和底部(页脚)区域的外观如下:

                SNAGHTML4eec1a

                关键信息

                微软目前表示,SPFx扩展将在2017年秋季/秋季达到“一般可用性”(即在所有租户中全面发布并适合生产使用)。在此之前,它们均处于预览状态。

                Also be aware that what makes the 新 扩展名 possible is Microsoft's updates to tenants (only in developer tenants 在 the time of writing, not even in First Release), 和 updates to the Yeoman Generator that developers use to get started - this has a 新 set of component types which get you started with the right default code.

                SPFX 1.2的更改

                • 占位符名称的更改– “Top” 和 “Bottom” insteaad of “PageHeader” 和 “PageFooter”
                • 不推荐使用onRender()方法/在SPFx扩展中不再使用该方法

                现代页面的先前限制

                现代页面之所以令人沮丧,是因为:

                • 无法运行自定义脚本
                  • 以前的方法(CustomAction + JSLink)添加的全局JS不在此处运行– only on “classic” pages
                • 相应缺乏页面扩展性
                  • 无法将内容注入页面

                什么’此处的更改是Microsoft提供了一个运行您的代码的钩子,并且还提供了 命名占位符 在现代页面上–您可以向其中添加内容的页面区域。只要您坚持这些区域并且不要’t arbitrarily “hack”通过更改其他DOM元素(例如使用jQuery或类似的元素)来显示该页面,则Microsoft有效地保证对Office 365的更新不会影响您的自定义设置。

                您提供的脚本必须安装到应用程序目录并以这种方式部署,这意味着实际上存在批准步骤。这意味着,简单地编辑页面以添加脚本编辑器Web部件不再是简单的选择–脚本必须正常’d由管理员提供。当然对此有很多争论,但最终还是’Microsoft需要采取的措施,以促进更多的治理并保护Office 365作为一个稳定的平台。

                Targeting placeholders such as the 最佳 和 底部 zones

                在早期版本的SPFx中,某些页面仅具有“顶部”区域,但没有“底部”区域。那’现在已修复,并且如果页面类型(例如,现代页面,网站内容页面,文档库或列表页面等)上存在“顶部”区域,则“底部”区域也会出现:

                SNAGHTML53485bb

                我在上方显示了一个相对较窄的条形,但是’如果要使用CSS(此图像被缩小),则没有什么可以阻止您将顶部区域变大:

                SNAGHTML2418631

                但是,当然,这仅适用于现代页面–传统页面通常没有这些区域或不支持SPFx扩展:

                SNAGHTML48946

                I’稍后将讨论端到端的过程,但是直接看代码-对文档中建议的代码进行一些小的调整/简化,我的代码看起来像这样:

                通过在扩展名中添加SCSS文件来实现CSS’s directory –我的名为AppCustomizer.module.scss,具有以下内容:

                请记住,这已导入到您的定制程序的类中,例如:

                import styles 从 './AppCustomizer.module.scss';

                So, the key elements 这里are:

                • ApplicationBaseCustomizer
                • 使用 this.context.placeholderProvider.tryCreateContent() 引用合适的占位符的方法及其’的内容-它使您可以操作DOM元素的事实(例如,设置innerHTML)

                部署选项–全球或逐站点

                  在什么方面 关联s您 r customizer to the site, 那里 are two ways of doing this in production:

                  • 逐站点 –通过这种方法,您可以在应用程序包装中添加一些声明性XML,然后确保将应用程序从“应用程序目录”安装到扩展应在其中运行的每个站点。具体来说,您的定制程序有一个包含清单文件的清单文件’s ID ([MyCustomizer].manifest.json), 和 on top of this you actually add an elements.xml 文件 with a CustomAction element (just like the old days!). This has a 新 "’ClientSideComponentId”属性,并且必须指向您的定制工具的ID。
                  • 全局/脚本 –在这种方法中,您将 skipFeatureDeployment 归因于“true” in youre package-solution.json 文件,然后使用CSOM或REST根据需要以编程方式将CustomAction添加到每个网站(例如,通过迭代或包含在某些配置代码中)。看到 //dev.office.com/sharepoint/docs/spfx/tenant-scoped-deployment 更多细节。使用这种方法时,管理员可以选择在安装到应用程序目录中时使SPFx Web部件/扩展名全局可用:

                    SNAGHTMLf7281c2

                    SPFx Web部件将显示在每个站点中,但是正如我所说,对于SPFx扩展,您还需要使用CustomAction / ClientSideComponentId来照顾到您所需的每个站点/网站的程序化关联/注册。 看我的帖子 管理跨SharePoint网站的租户范围的SPFx扩展 一些PowerShell / C#代码可以做到这一点。

                  但是在包装生产之前’是一种模式,您可以在担心打包之前开发/测试定制程序。通过运行一个“gulp serve”在本地并向现代页面添加一些querystring参数,以便从本地主机加载清单– it’s a bit like the “local SPFx workbench”等效,但适用于SPFx扩展程序/定制程序。

                  但是我不’t need placeholders –我只想在每个页面上引用一些JavaScript!

                  In this case, the code is 一些what simpler. 如果你 have an external JS 文件 you want to reference in a quick 和 dirty way, you could do this by dynamically adding a script tag to the <head>页面的元素。我的测试表明,在onInit方法中执行此操作似乎很安全,但是onRender方法也可以– in any case, it’只是这样的老式方法:

                  但是考虑一下!

                  • 如果JS托管在另一个域上,则可能需要在该域上启用CORS(取决于您的JS在做什么)
                  • 如果你're referencing a module script, you could do this in a cleaner way by referencing it as an external module 在里面 "externals"config.json文件的部分(请参阅 将外部库添加到SharePoint客户端Web部件 了解更多)。我已经测试过,这种方法确实可以与Application Customizer一起使用
                  • 您也可以选择捆绑脚本(如果有必要的话),并确保在定制程序的onRender方法中引用了该脚本。那也应该工作。

                  处理

                  无论您要定位页面占位符还是仅在每个页面上引用脚本,此过程实际上都是相同的:

                  如果需要,更新SPFx Yeoman Generator

                  您可能需要做的第一步是更新SPFx Yeoman Generator–假设您已经安装了所有位,则可以通过键入“yo”在命令行上,然后执行更新过程:

                  SNAGHTML38f4e932

                  选择“更新您的发电机” option 和 select “@ microsoft / sharepoint”:

                  SNAGHTML38f64e11

                  SNAGHTML38f7128a

                  创建应用程序定制程序扩展

                  [注:一世’m本质上是复制/遍历 主要“建立您的第一个扩展” documentation这里 –您也应该参考。]

                  一旦您’准备好实际创建您的应用定制程序,可以通过运行该生成器来完成:

                  SNAGHTML3902e5e2

                  为您的解决方案命名,并确保选择“Extension” option:

                  SNAGHTML1dbcd6b

                  在这种情况下,我们’重新使用应用程序定制程序(而不是ListView命令集定制程序[CustomAction /工具栏替换]或字段定制器[JSLink /字段替换]):

                  SNAGHTML1d772eb

                  为您的定制器提供一个名称,然后提供一个描述:

                  SNAGHTML212d82d

                  然后,生成器将忙于使用适当的文件创建您的应用程序,然后您’ll see:

                  SNAGHTML2114dd4

                  现在,您的应用程序已创建,您 ’将获得样板代码(在更高版本的SPFx中看起来可能与此稍有不同):

                  SNAGHTML2152c30

                  It’s a good idea to test running this in debug mode before making any code changes, so do this by running a 喝一口 with the “nobrowser” switch:

                  SNAGHTML216506c

                  下一步是浏览到新页面,但在URL中添加了一些querystring参数,以便加载定制程序的* local *清单。首先,打开浏览器到现代页面–文档库是一个不错的选择:

                  SNAGHTML21b7c46

                  然后在记事本或类似工具中,构建所需的querystring参数。这种基本格式是:

                  ?loadSPFX=true&
                  debugManifestsFile=//localhost:4321/temp/manifests.js&
                  customActions={"badba93c-7f98-4a68-b5ed-c87ea51a3145":{"location":"ClientSideExtension.ApplicationCustomizer","properties":{"testMessage":"Hello as property!"}}}
                    

                  但是你’我需要用您的定制工具中的ID替换ID’s manifest 文件:

                  SNAGHTML224e8a1

                  SNAGHTML226aa94

                  如果你 paste that onto the end of the URL to the document library in your browser window 和 hit enter, you should see a warning message related to debug mode:

                  SNAGHTML228610e

                  点击“Load debug scripts”按钮,然后您的代码应执行,您应该看到结果–在样板代码的情况下,’s an alert box:

                  SNAGHTML22a488b

                  成功!您’现在,可以在调试模式下运行Application Customizer。

                  生产包装(逐站点/声明性方法)

                  为此,我建议您按照文档中的步骤操作(从 将扩展部署到SharePoint) –但以下是主要步骤的摘要。最终,它围绕:

                  1. 生成您的应用程序,并将捆绑的JS文件部署到CDN之类的地方(就像SPFx Web部件一样)
                  2. 将一些打包文件添加到您的应用程序,以便在将应用程序添加到网站时调用自定义程序(有点像功能激活)–实际上,它是功能激活;))
                  3. 将应用程序包部署到应用程序目录,然后将其添加到站点

                  在过程方面,关键步骤为:

                  • 创建SharePoint / Assets文件夹并添加一个elements.xml文件:

                    SNAGHTML3954c9a1
                  • 将内容添加到elements.xml– set the “ClientSideComponentId”到您的定制工具的标识符,即在[MyCustomizer] .manifest.json文件中找到的标识符 (请记住,如果您打算使用skipFeatureDeployment = 真正并通过脚本进行全局部署,则可以跳过此步骤):

                    <?xml version="1.0" encoding="utf-8"?>
                    <Elements xmlns="http://schemas.microsoft.com/sharepoint/">
                        <CustomAction
                            Title="COB Global JS"
                            Location="ClientSideExtension.ApplicationCustomizer"
                            ClientSideComponentId="5dba1a34-6bbe-42ef-be72-94e01b527ce2">
                        </CustomAction>
                    </Elements>
                          

                  • 编辑config \ package-solution.json文件– add a “Features”节点以引用您的elements.xml文件。它需要类似于以下内容:

                      "features": [{
                          "title": "COB AppCustomizer - global JS",
                          "description": "Adds 一些 JavaScript to every page 在里面 site",
                          "id": "456da147-ced2-3036-b564-8dad5c1c2e34",
                          "version": "1.0.0.0",
                          "assets": {        
                            "elementManifests": [
                              "elements.xml"
                            ]
                          }
                        }]
                  •       
                  • 请注意与JS捆绑包的CDN托管相关的其他一些步骤(例如,更新‘cdnBasePath’ property 在里面 ‘write-manifests.json’文件),然后分别使用“ gulp bundle --ship”和“ gulp package-solution --ship”来捆绑和打包您的应用。
                  • As I say, 头 to 文档 实际执行此操作的全部步骤。

                    然后将应用上传到应用目录:

                    SNAGHTML2dc2e6a

                    请注意,此时,管理员需要信任该应用程序,并将看到远程文件的托管位置-在我的情况下,我使用了Office 365公用CDN:

                    SNAGHTML9a5ac5

                    然后,您应该看到您的定制程序生效,并且如果您继续查看,’会看到一个网络范围的功能(默认情况下),它将您的定制程序绑定到该站点:

                    SNAGHTML2cbe9ae

                  其他事项 

                  • 财产袋– as shown 在里面 “建立您的第一个扩展” page, 那里’可以与定制程序一起使用的各种属性包。在生产模式下,属性是在elements.xml文件的CustomAction元素中指定的。在我的示例中,我选择使用直接在代码中指定的值,但是此属性包提供了 一些 分离级别(但仍会烧入您的包装中)

                  定制愉快!

                  张贴者 Chris O'Brien 23:07 3 comments 链接到这篇文章