2014年12月16日,星期二

Office 365应用–在SharePoint应用程序模型和Office 365 API之间进行选择

就像我一样,许多其他SharePoint开发人员在过去的一两年中都在掌​​握SharePoint应用程序模型–这是SharePoint 2013中引入的一种构建自定义方式的方法,该自定义方式无法在SharePoint服务器上运行。以这种方式构建的增强功能可以在远程计算机(例如Azure,IIS等)上运行,因此任何稳定性/性能问题都不会影响核心SharePoint。如果你’当然,重新使用Office 365时,应用程序模型是扩展平台的重要基础,因为Microsoft不允许将自定义SharePoint代码部署到Office 365服务器(至少服务器端代码)。这些是SharePoint开发领域的重大变化,其中有很多要学习的知识,包括身份验证,远程API和解决常见需求的模式。

但是,那里’s a 新 kid in town. Microsoft have introduced a series of 新 APIs for Office 365 which span SharePoint, Exchange and Lync –而不是需要以开发人员的身份来了解每个平台,而是公开了更一般的概念,例如:

  • 邮件
  • 日历活动
  • 联络人
  • 档案

当然,那些了解领土的人会认识到“mail”, “calendars” and “contacts”与交易所有关,“files” are related to SharePoint (N.B. right now this is primarily about 档案 stored in the user’s OneDrive for Business区域)。但是,要点是,并不是现在所有想要使用Office 365数据的人都有这样的背景。最初,这个新方向可能会使经验丰富的开发人员感到困惑– after all, can’t I access SharePoint 档案 using the existing SharePoint CSOM or REST APIs? Also, why is authentication different? I just spent 了解提供商托管的应用程序以及“new” authentication models with 上下文令牌s, access tokens and so on! Why did we need something 新?  If this is a 新 way of building apps for Office 365, is the old model going away? These are all logical questions in my opinion, so I wanted to talk about them here, as well as discuss some things to look out for in your apps which suggest you SHOULD be using the 新 approach. But for sure, if you’即将开始构建应用程序时,您可能会遇到这个决定(用免费的图形说明):

COB-由提供商托管的SP应用程序与Office 365应用程序

毕竟,两者之间有很多相似之处–在这两种情况下,核心实现都可以是ASP.NET MVC,例如在Azure或某些IIS服务器上。让’s start by understanding what an Office 365 外部 app is about.

Office 365应用的外观

以下是这些应用程序的一些主要原则:

  • 该应用程序是“external” or “standalone”某种类型的应用程序,可能是在ASP.NET中实现的(最近很可能是MVC风格)。而且,当我说网站时,请记住,它实际上可能还完全是其他东西,例如在Word或Outlook中显示的Office for App(因为它们使用下面的网页)。同样,它也可以是Windows应用商店/电话应用,也可以是针对其他设备的应用,例如iOS / 安卓应用
  • 我们希望以某种方式将应用程序与Office 365集成(也许就用户体验/导航,数据存储或身份验证而言)
  • 该应用程序已在Azure Active Directory中注册–特别是Office 365租户背后的Azure AD
  • 应用程序可以实现与Office 365相同的身份验证机制。这意味着您的用户可以进行单点登录,并且可以在Office 365和您的应用程序之间通过,而无需重新输入用户名/密码
  • 用户可以通过Office 365应用启动器或浏览到该应用“My apps” page
  • In coding terms, the apps are likely to use the 新 Office 365 APIs to access data there, but can also revert to using lower-level APIs such as the SharePoint CSOM/REST APIs

使用Office 365 API开发

如果我要总结开发模型,我’d说有两种高级方法:

  • 使用Office 365 REST API (更多的操作,但是更复杂,因为您需要自己制作HTTP请求并处理身份验证等。)
  • 使用Office 365客户端库的形式 (使用较简单,但不要’没有100%的覆盖率’可能)。这些风味包括:
    • .NET(用于ASP.NET网站,Windows Store / Windows Phone应用程序,Xamarin应用程序等)
    • 的iOS
    • 安卓
    • Cordova应用程序(多设备混合应用程序)

Key differences between Office 365应用and Apps for SharePoint/Apps for Office

但是,如果您的应用程序专注于SharePoint / Office,因此可以作为Office 365应用程序或SharePoint / Office应用程序实现?让’我考虑了一段时间的决定-这是我所看到的一些差异(N.B.’m还在下表中总结了这些差异):

差异1-如何访问应用程序(最终用户)

Office 365应用:

可以通过几种方式访问​​Office 365应用程序:

  • 从任何链接(例如,您的Intranet主页上)开始,’s a 独立的 website
  • 从Office 365应用启动器(如果应用为“pinned”在那里快速访问)
  • 从Office 365“My apps” page

应用启动器的经验:

COB app 固定 to app launcher

“My apps” page experience:

COB 我的应用程式 page

适用于SharePoint的应用程序:

可以通过以下方式访问SharePoint应用程序:

  • 从安装了该应用程序的SharePoint网站的“网站内容”页面上
  • 通过开发人员提供的SharePoint链接,使用AppRedirect.aspx?instance_id = [此处为应用程序实例GUID]

换句话说,只能从SharePoint / SharePoint Online网站访问这些应用程序–假设应用程序访问了某些SharePoint数据(大多数情况下)。这是因为身份验证模型依赖于 上下文令牌 从SharePoint传递到应用程序–否则,该应用程序将无法以任何方式与SharePoint通信。

网站内容页面体验:

App deployed to target 现场

差异2–应用注册(针对实施者)

Office 365应用:

首先,这些应用程序必须在与Office 365租赁有关的Azure AD中注册:

COB Azure广告 COB Azure广告-应用程序

请注意,当您为单个Office 365租户创建应用程序时,Visual Studio(更具体地说是Office 365开发工具)将为您执行此步骤。 Azure AD管理员还可以注册应用程序,这就是多租户应用程序需要执行的操作。

适用于SharePoint的应用程序:

这些应用程序使用AppRegNew.aspx(或使用Office Seller Dashboard for Store应用程序)在SharePoint / Office 365中注册:

AppRegNew

差异3-身份验证和授权的工作方式,例如用于SharePoint数据(对于实施者)

Office 365应用:

在Azure AD中注册了该应用程序之后,您可以使用Office 365客户端库编写代码以向平台进行身份验证(更简单),或者可以通过较低级别并通过以下方式自行获取令牌 欧文 (对于MVC)或 NET的ADAL (两者都比较复杂,但是当您’直接根据Office 365 REST API重新编码)。关于客户端库方法,这里’s片段,显示auth在.NET Office 365库中的工作方式(摘自 用于ASP.NET MVC的Office 365入门项目 样品):

您 can cache these access tokens as you see 适合 to avoid repeated auth prompts. But if a 新 token needs to be obtained, this code does the work of redirecting the user to sign-in to Office 365 (whether they are in a web browser or on a device):

COB Office 365登录-Web

图片

适用于SharePoint的应用程序:

SharePoint应用程序的身份验证以下列方式工作:

  • SharePoint托管的应用程序: 身份验证隐式发生,因为网页托管在SharePoint上下文中(并且只能使用SharePoint JSOM API)
  • 提供者托管的应用程序: 应用必须在AppRegNew.aspx(或Office Store)中注册,.NET代码可以使用创建时添加到Visual Studio Web项目中的SharePointContext和TokenHelper类进行身份验证:

差异4–应用部署(针对实施者)

Office 365应用:

将应用程序复制到托管位置所需的任何内容,例如发布到Azure(从Visual Studio–如下所示)或FTP或类似文件:

发布网络应用-验证设置  

适用于SharePoint的应用程序:

Similar to above in that app 档案 must be published to the hosting location, but with two extra steps:

  1. 应用程序包(.app)也必须部署到应用程序目录中:

    发布应用程序-上传到应用程序目录
  2. 将应用程序放入“应用程序目录”后,必须将其安装到应使用该应用程序的任何SharePoint网站(或 租户范围内的安装 应该执行):

     App install - in 现场

差异/共性汇总表

由于以上部分很难交叉引用,因此让我尝试在一个表中进行总结:

Office 365应用

适用于SharePoint的应用

如何访问应用程序(针对最终用户)
应用启动器/我的应用页面

其他链接(例如来自您拥有的其他Intranet网站的链接)或书签– it’s a 独立的 website
通常从SharePoint网站的“网站内容”页面
验证到Office 365 / SharePoint (对于实施者) 应用已在Azure AD中注册,然后在通常使用的Office 365客户端库中进行身份验证帮助(例如.NET Office 365 SDK中的AuthenticationContext对象) 应用验证–上下文令牌从网站传递到应用中,并从那里获取访​​问令牌。以SharePointContext和TokenHelper类形式提供的帮助程序代码(自动添加到应用程序项目中)
应用托管 (对于实施者) 任何网络平台–Azure或其他云托管,内部IIS或其他Web服务器 任何网络平台–Azure或其他云托管,内部IIS或其他Web服务器
应用注册 (对于实施者) 在Azure AD中注册 使用AppRegNew.aspx(或使用Office Seller Dashboard for Store应用程序)在SharePoint / Office 365中注册
应用部署(针对实施者) 一次部署到托管平台(例如Azure / IIS) 部署到SharePoint / Office 365应用目录,然后由网站所有者安装到各种SharePoint网站或以租户为单位的安装。

或者,将其提交给Office Store以在那里出售。

其他差异

上面也没有涵盖一些更广泛的差异。唐’别忘了:

  • For Office 365应用s, I no longer need knowledge of Exchange and SharePoint APIs to pull together an app which (for example) stores some 档案 in an area I can access (i.e. my OneDrive) and sends an e-mail on my behalf. In other words, I don’t need to be a “career developer”在Exchange或SharePoint中利用这些东西
  • Office 365应用可能更易于为设备开发–拥有适用于iOS和Android的SDK意味着在这些平台上一些常见的开发任务非常简单。一世’d说这些应用没有’无需从SharePoint网站访问也可以在这里提供帮助

摘要-考虑Office 365方法的原因

因此,如果您’重新构建可以用作提供商托管的SharePoint应用程序或Office 365应用程序的应用程序。这里’我的指标摘要列表,表明Office 365应用很适合:

  • 您r app doesn’无需使用本地SharePoint / Exchange
  • 您r app doesn’t really “fit” in SharePoint:
    • It’s an 外部 app, not associated with a “site”
    • 它坐在“Office 365 suite” level
  • 您r requirements match 档案/messages/events etc.
  • 您 want to integrate with the Office 365 App Launcher
  • 你不’希望网站所有者需要将您的应用安装到SharePoint网站中(而租户范围的SharePoint应用则不需要’不符合您的要求)
  • 您’重新开发设备,并希望利用特定于设备的SDK
  • It’s the future!

简而言之,总是存在Office 365应用程序或SharePoint应用程序更合适的情况–两种模型都是有效的。关键是要了解最终用户和实施者之间的差异。

如果您认为我愿意发表评论’我错过了任何东西,或对此有任何想法!

8条评论:

匿名 said...

很棒的文章,对我来说,这正在慢慢陷入我将来对O365解决方案的思考。

Do you see that perhaps the crossover point might be an app that has say a requirement for 档案, events, AND a custom list of sorts, or maybe even write an entry to the social stream (probably Yammer)?

您是否看到O365 API进行了扩展,以便可以通过通用O365 API使用所有服务,也许SharePoint特定的API可能变得不那么重要了?

I'm wondering if we end up with scenarios where we might have a requirement for 档案, events, lists, social activities, and we choose to make use of say Azure Table Storage for lists and don'甚至根本不用操心SharePoint网站!

也许关键在于Delve的覆盖范围,如果Delve可以显示所有O365属性的搜索结果,则对SharePoint网站本身的需求可能会减少(至少在自定义应用程序方案中)。

贾伯乔说过...

克里斯好棒!影响此决定的另一个区别是:Office 365 API在运行时通过用户同意使用Azure AD进行身份验证,而SharePoint的For Apps在'deploytime'。截至目前,Azure AD还没有针对Apps的构造'AllUser'同意,仅适用于用户’单独给予同意。

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

@finarne,


是的,我绝对认为Office 365 API将得到显着扩展。我知道工程团队目前正在研究一些有趣的示例。但是,我不'可以预见,API将像"dedicated"毕竟,诸如SharePoint CSOM / REST之类的远程API都已经投入了数年的时间。

我认为目标是"generic"开发人员在Office 365平台上尽可能高效地工作,尤其是围绕常见需求。

因此,如果只需要基本使用SharePoint构造(例如网站/列表),那么它可能会移到后台。但是,如果需要更深入的使用,恕我直言仍然需要SharePoint API知识。

干杯,

COB。

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

@jabberjaw,

是的-非常好,谢谢。它'值得注意的是,某些“共同同意”权限级别需要用户*和*管理员同意(例如AllSites.FullControl)。但是,是的,每个用户都必须同意。

目前还缺少的功能是请求*指定的* SharePoint网站(而不是全部)的权限-尽管很明显。

感谢您的评论。

干杯,

COB。

奈杰尔·杜瓦(Nigel Dewar)说过...

这是一篇了不起的文章,非常感谢!!!

喹托雷尔说过...

克里斯好文章!

加里马说过...

Thanks for this article Chris. Just a question, does this scenario still holds true with all the 新 capabilities in O365. So for instance, I need to create an add-in which users will access from SharePoint Online but nothing else will be stored in it. Backend will be SQL or some other system. Does it still make sense to go with O365 apps? Have you ever encountered any issue while using it in production?

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

@Garima,

是的,除了说:

-Office 365 API已演变为Microsoft Graph-但相同的考虑因素仍然适用
-它'如今,使用Angular,React或类似的JS库可能比ASP.NET MVC在客户端上实现更多应用程序更为流行。两者都运作良好。如果使用JS调用图'现在需要使用adal.js进行身份验证
-如果*使用*基于JavaScript的实现,则可以使用Azure Functions实现所需的任何服务器端代码。看到 从SharePoint框架调用Azure函数 有关更多信息

总体而言,SP提供程序托管的应用程序与Office 365应用程序之间的主要考虑因素仍然适用-最终用户应如何访问该应用程序,以及执行哪种身份验证模型/ API集,这使我自己比其他应用程序更需要构建?如果数据存储在SQL中,则可能主要是"用户应如何访问该应用程序?"要考虑的问题。

HTH!

COB。