2012年8月1日,星期三

SharePoint 2013 应用程式s –架构,功能和UX注意事项

UPDATE: this article turned into part 1 of a series on SharePoint 应用程式s - here's the table of contents:

  1. SharePoint 2013 应用程式s –架构,功能和UX注意事项 [本文]
  2. 入门– creating lists, content types, fields etc. within a SharePoint 应用程式 (provisioning)
  3. Working with data in the 应用程式网页, and why you should
  4. Access end-user data (in the 主机网站) from a SharePoint 2013 应用程式
  5. Rolling out SharePoint 2013 应用程式s to the 输入prise - tenant scope and PowerShell installs
  6. Azure是新的SharePoint‘_layouts’ directory
  7. “Host web 应用程式s” – provisioning files (e.g. master pages) to the 主机网站
  8. “Host web 应用程式s” –设置字段和内容类型
  9. Deploying SP2013 provider-hosted 应用程式s/Remote Event Receivers to Azure Websites (for Office 365 应用程式s)
  10. Working with web parts within a SharePoint 应用程式
SharePoint 2013带来了“app” framework and the Office/SharePoint 应用程式 store - and whenever a new version of SharePoint brings a new development 应用程式roach, developers often 开启AnApp700克服它是他们必须克服的一些内部挑战(有时以实际客户需求为代价)。其他博客也发表了类似的文章“when to build 应用程式s”这篇文章,但我注意到我’d也许是从另一个角度来的。具体来说,当我建立了第一个“hello world”SharePoint 2013应用双色球推荐一注,我要准备的内部问题是:

我应该开发客户要求作为应用双色球推荐一注的功能吗?客户对此事没有强烈的意见(他们不太了解应用双色球推荐一注框架),并且正在寻求我/我公司的指导。”

最初我想专注于 用户体验 of using a piece of functionality developed as an 应用程式. 大多数具有SharePoint用户直接经验的人都同意这绝对是一个关键考虑因素。因此,本文的后半部分专门介绍UX。  However, it’可以说,还有更多潜在的方面需要考虑–毕竟,它甚至可能不是 可能 to create the desired functionality as an 应用程式. So let’s start with 应用程式 architecture and capability considerations.
最后一件事-要构想此讨论,请考虑微软说“开发一个您可以使用的应用”(尽管他们的动机可能与您/您的客户不同– I’在总结中将回到这一点)。
免责声明2012年7月31日–SharePoint 2013在此阶段处于预览阶段,因此从现在到发布时间,某些细节和用户体验可能会略有变化。

架构注意事项

Guided by MSDN (see reading list 在 the end of this article), when considering 应用程式 development my summarized checklist here would be:
  • 从3个托管选项中,我可以使用哪些选项?
    • SharePoint托管 –[这是给定的,因为您具有SharePoint环境]
    • 外部托管(到SharePoint场)
      • Do we have some non-SharePoint servers which could host this 应用程式, or could some be created?
      • 假设需要弹性,是否有负载平衡/故障转移解决方案?
      • 要使它们具有与SharePoint服务器相同的业务连续性(DR,备份/还原),需要付出多少努力?
      • 是否需要围绕处理能力,内存使用,网络延迟/吞吐量,磁盘性能和数据存储进行容量规划?
      • 如果我们想在.Net中进行开发,它们是否运行IIS?
      • If the 应用程式(s) need to store data, where would this be?
    • 自动托管(SharePoint Online + Azure)
      • 客户是否 ’在SharePoint Online中运行将在其上部署应用双色球推荐一注的Web应用双色球推荐一注(因为Azure自动托管仅适用于部署到SharePoint Online的应用双色球推荐一注)?
      • 客户是否 have an Azure subscription?
      • Has Azure capacity planning been done? Is any more CPU/memory/disk needed for the new 应用程式(s)?
      • 我们能否准确估计每月Azure成本是多少?
      • 我们是否具有在Azure中进行开发的技能,或者开发人员可以在项目中学习?
  • Is a combined 应用程式 hosting 应用程式roach 应用程式ropriate? (例如,一些SharePoint工件,以及一些SharePoint外部的工件)
  • Does the selected 应用程式 hosting model fit with business and I.T. strategy?
考虑到这些要点,我想知道对于某些非Office 365 / SPO客户端,纯粹由SharePoint托管的应用双色球推荐一注是否比外部托管的应用双色球推荐一注更容易实现。一世’我们已经看到一些组织需要花费数月的时间来配置服务器,因此即使在这个虚拟化的世界中,站起一些.Net服务器来支持SharePoint应用双色球推荐一注也不是最容易的事情。但是,SharePoint托管的应用双色球推荐一注与具有外部组件的应用双色球推荐一注不具有相同的功能,因此让’仔细考虑一下。

能力考量

The key question here is:- can the functionality be built using the 应用程式 hosting options I have available to me? Consider the following:
  • An 应用程式 cannot have any server-side SharePoint code –所有代码都必须使用客户端API,例如CSOM,REST API和Web服务
  • 默认,则在最终用户浏览网站时不会调配任何提供的SharePoint工件(列表,Web部件,内容类型,网站列,母版页,内容页面,其他文件) – 相反,它们是通过特殊的方式创建的“app web”在与原始SharePoint网站隔离的特殊URL上。例如,如果在用户内容和与应用双色球推荐一注相关的内容之间需要某种形式的聚合或链接,则这可能特别相关。
  • Unless the 应用程式要求s special permissions (which must be agreed to 在 install time), an 应用程式 does not have permission to talk to the parent site or site collection – furthermore, there is no permission 可能 which allows the client APIs talk to the parent web 应用程式lication or farm. [See Working with the 应用程式网页, and why you should 有关这些点的更多信息。]
  • Deep changes to the user site are not 可能 with an 应用程式 –网站定义,品牌,主题,大多数类型的功能区自定义或需要CustomAction的链接更改都是示例
  • Timer jobs are not 可能 within an 应用程式 –在SharePoint托管的应用双色球推荐一注中,’很难看到任何“scheduled processing”可以实现。这是与Azure或外部托管的应用双色球推荐一注(或单个应用双色球推荐一注组件)的主要区别,后者可以使用Azure服务总线,甚至可以在非SharePoint服务器上使用客户端API调用SharePoint的非SharePoint服务器上的计划任务
  • Custom field types are not 可能 within an 应用程式

用户体验注意事项

  • How will users obtain the 应用程式?
    • 会自动将其推广到所有/选定的站点吗?
    • 具有完全控制权的网站所有者/用户将负责从应用目录中获取应用吗? (对于本次讨论,我们’会假设该应用不会被推送到公共商店)
  • 对于未自动推出的应用双色球推荐一注,该应用双色球推荐一注可以’s trust/capability requirements alarm some site owners and cause them to cancel 应用安装ation? (see later screenshots). 如果我们没有’向他们介绍了此过程,是否会导致服务台呼叫?
  • Which of the 用户体验 options will the 应用程式 make use of?
    • Navigation to separate SharePoint 应用程式网页?
    • 导航到使用chrome控件的外部站点? (note that this is only 应用程式licable if any 应用程式 UI components are hosted externally to SharePoint)
    • App parts (ClientWebPart) which use an IFrame to bring 应用程式 content into the 主机网站 ?
    • 浏览列表项’s下拉菜单(编辑控制块[ECB])链接,功能区自定义
  • Does the separation of 应用程式 and other site content work?
    • 用户是否会感到困惑,例如在您的其他文档库旁边找不到您的应用双色球推荐一注配置的文档库? (请记住,要找到该应用’的文档库,他们必须“enter”该应用双色球推荐一注,然后转到包含该应用双色球推荐一注的单独的应用双色球推荐一注网站’s data/artifacts.)
考虑到以上几点,让’看一下网站所有者和最终用户的用户体验。

网站所有者的经验– adding a SharePoint 应用程式

Apps can only be added by users with Full Control permission to the site (typically site owners only), so this process only 应用程式lies to them. We’ll show obtaining an 应用程式 from the App Catalog here,但请记住,如果这样配置的话,网站所有者也可以从公共商店购买商品。
  1. 网站所有者可以导航到该应用“area” (‘Your Apps’),其中显示发布到“应用双色球推荐一注目录”的应用双色球推荐一注,并具有指向公共SharePoint Store的链接。网站所有者可以使用“网站操作”菜单上的链接到达那里:

    ContextMenu-AddApp
    ..or the link in the 网站内容 page:

    SiteContents-AddApp
  2. In ‘Your Apps’, the site owner would then find an 应用程式..

    AddAnApp 
  3. ..并可以选择单击‘App Details’链接以查看有关该应用双色球推荐一注的更多信息。如您所料,此页面上有发行商的一些摘要和正在运行的应用双色球推荐一注的屏幕截图:

    AppDetailsPage 
  4. 如果网站所有者对此感到满意,则可以单击‘Add it’ button –此时,系统会向他们显示应用双色球推荐一注具有的一些权限要求。这可能是针对SharePoint内容(例如列表/库),也可能是其他项目(例如,调用服务应用双色球推荐一注)。请记住,应用双色球推荐一注可以使用与实际使用人员不同的权限级别运行(例如,可以允许应用双色球推荐一注删除用户无法直接删除的文档),并且此步骤可确保负责网站的人授予所需的访问权限。这被称为 应用程式 permission request.

    添加应用双色球推荐一注-信任请求

    (As a sidenote, it will be more normal to see an 应用程式要求ing to work with a 具体 列表,而不是网站所有者从下拉列表中选择列表–上图显示了我指定应用双色球推荐一注需要的结果‘Manage list’权限,但未指定适用的特定列表)。
  5. If the permission request is granted, then the 应用程式 is added to the site and is then accessible from the ‘Site Contents’ 区:

    开启AnApp
At this point, the 应用程式 is now usable by regular site users.

最终用户体验– using an 应用程式

实际上,您只是看到了。对于‘full page’应用双色球推荐一注,用户将通过‘Site Contents’如上图所示。在这里,他们还可以找到其他应用双色球推荐一注,列表,文档库等。单击应用双色球推荐一注图标后, the user will be redirected to the start page for the 应用程式 (如‘StartPage’ property in AppManifest.xml). In the SharePoint托管 example I showed in my last post, this could be a page provisioned to the 应用程式网页:
 COBAppDefaultPage
Regardless of where the user goes within the 应用程式, the header maintains a simple breadcrumb link back to the 主机网站 (where the 应用程式 was accessed from).
请注意,除了整页模型外,还可以通过其他方式显示应用–如果一个Web部件实际上就是所有这些’,然后SharePoint 2013提供‘app parts’(aka ClientWebPart),它是一个IFrame包装器,用于将应用双色球推荐一注的UI引入主机网络。对于SharePoint托管的应用双色球推荐一注,这可以是设置到应用双色球推荐一注Web中的页面(如上所示),或者如果该应用双色球推荐一注具有外部组件,则可以是某些外部服务器上托管的页面。

网站所有者的经验–从公共SharePoint Store添加

万一你’奇怪的是,使用公共应用商店的体验与使用内部应用目录并没有很大不同。有些比特还没有被使用(例如金融交易比特),但是实际上’可以从以下分类的大型应用列表中进行选择:

SharePointAppsInStore

网站所有者的经验– where 应用程式 feature/capability requirements are not met

无论应用双色球推荐一注来自何处,除了权限请求(网站所有者在安装过程中信任应用双色球推荐一注时,网站所有者必须确认的许可请求)之外,应用双色球推荐一注还可以指定SharePoint功能方面的先决条件。毕竟,如果某个应用双色球推荐一注依赖于SharePoint 2013社交功能,那么如果该应用双色球推荐一注不存在,它将显然掉入堆中’在安装应用双色球推荐一注的环境中可用。因此,如果不满足这些先决条件,则应用双色球推荐一注框架不允许安装应用双色球推荐一注–网站所有者将看到一条消息,指出无法添加该应用双色球推荐一注:
无法添加应用
在这种情况下,‘app details’ page lists the reasons why the 应用程式 cannot be added:

无法添加应用 --- Storefro
不过,这里重要的是没有万能的-SharePoint不会对应用双色球推荐一注背后的每一行代码进行某种检查,以找出所需的内容。相反,它’在打包应用双色球推荐一注之前,由应用双色球推荐一注开发人员指定所有先决条件(包括权限请求)–此信息进入AppManifest.xml文件,但Visual Studio 2013中有一个方便的设计器:

VS_AppPermissionAndOtherPre

其他用户体验,例如SharePoint管理员

除了网站所有者‘app install’经验和最终用户‘app usage’经验,还有其他利益相关者也要考虑。管理员将想知道以下内容:
  • Which 应用程式s are in use where
  • If any 应用程式s are currently experiencing problems
  • 公用SharePoint Store中哪些应用是请求最多的应用–这适用于以下情况:不允许网站所有者直接从公共SharePoint存储区获取应用双色球推荐一注,但允许其登录‘app request’
管理中心中的一系列屏幕可以满足管理员的这些需求,但是我’将其保存为另一篇文章。

概要

SharePoint 2013应用双色球推荐一注框架在SharePoint开发领域是一个相当根本的出发点,在制定SharePoint策略时’重要的是要了解什么时候适合应用双色球推荐一注,什么时候不合适。现在可以通过三种不同方式将一项功能有效地推广到SharePoint:
  • 农场解决方案
  • 沙盒解决方案
  • SharePoint应用双色球推荐一注(如上所述,可以是纯粹由SharePoint托管的应用双色球推荐一注,可以在非SharePoint硬件上托管的应用双色球推荐一注(可能由供应商提供)或Azure自动配置的应用双色球推荐一注–我的介绍性帖子也有更多详细信息)
微软指南说“尽可能开发应用双色球推荐一注”,但请注意,它们的目标可能与您的项目/环境不同。我个人认为应用双色球推荐一注的主要MS驱动双色球推荐一注是降低SharePoint升级的复杂性,从而维持许可证收入流。如果您已经评估了开发/自定义策略,并且认为升级到SharePoint的下一版本将是完全可管理的,那么我就不会’不一定得出结论,应用双色球推荐一注在任何方面都是强制性的。
在这种情况下,问题可能是“应用双色球推荐一注模型的语义和用户体验是否比其他自定义方法还给我一些东西?”。这样的一些示例可能是App Catalog体验,或者可能与其他自定义项的开发方式保持一致–无论哪种方式,如果您不是’受升级/架构问题的约束。

进一步阅读

20条评论:

匿名 said...

我非常喜欢这篇文章,因为它显示了Apps的隐藏缺点,但是在阅读了这篇文章之后,我有几个问题:

您 say:
最终用户浏览的网站中未设置任何提供的SharePoint工件(列表,Web部件,内容类型,网站列,母版页,内容页面,其他文件)

那么,列表存储在哪里?在不同的内容数据库中?


2nd. If artifacts provisioned are not in the site the end user browse, so I suppose you cant access lists created by other 应用程式s, or OOTB lists in the sharepoint site?


我仍然认为,对于公司发展而言,Webparts / Farm解决方案将是必经之路。


第三名在多次阅读您的功能升级文章后,我必须问,可以以相同的方式升级Apps吗?如果您创建具有3个字段的应用双色球推荐一注的1.0版,以后又需要在2.0版中添加另外2个字段怎么办?

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

@levalencia,

谢谢。这些都是好问题。让我尝试回答:

1. Yes, the artifacts are in a different site collection and content database. See my image with the stacks of dollars - notice the URL is to a different web 应用程式lication.

2.是和否。应用是隔离的,因此它们无法访问其他应用提供的数据。但是,应用双色球推荐一注可能能够访问'host web'-例如用户使用的OOTB列表/库。这是网站所有者将应用双色球推荐一注安装到网站时必须同意的内容(应用双色球推荐一注许可请求)。

3.应用双色球推荐一注具有自己的升级生命周期。我没有 't yet looked 在 this in detail, but I am expecting that upgrades to SharePoint artifacts in the 应用程式网页 would indeed be handled by the Feature Upgrade framework. I'在以后的文章中将对此进行跟进。

谢谢!

克里斯。

安莫尔说过...

Useful information shared..I am very happy to read this article..Thanks for giving us nice info. Fantastic walk-through. I 应用程式reciate this post.

未知说过...

因此,Azure自动托管仅在SharePoint Online中可用-但是可以使用外部托管的Azure应用双色球推荐一注吗?这样做似乎可以解决围绕外部托管的许多问题-当然,除了SharePoint场需要能够访问外部主机之外。

那有可能吗?那有意义吗?

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

@安德鲁,

是的,是的。完全有可能在Azure中托管外部组件,但不利用自动托管进行部署。确实,在某些情况下自动托管可能没有意义。

只要外部网站(在Azure或其他地方)可以通过CSOM / REST等调用SharePoint,它's a workable option for 应用程式 hosting.

干杯,

克里斯。

匿名 said...

Nice post. One clarification: The 应用程式网页 is not in a separate web 应用程式lication from the 主机网站. In fact, it is a subweb of the 主机网站, and thus it is the same site collection and content database. The 应用程式网页 a different base URL from the 主机网站 because it has its own domain name. This is for security reasons. For more information see this SDK topic: http://msdn.microsoft.com/en-us/library/fp179925(office.15).aspx
In fact, if you open Site Settings on the 主机网站 and then click the Site Hierarchy link, you'll see the 应用程式网页s listed as subsites.

尼克·帕特尔说过...

I am trying to confirm from many sources and yours seems only resource mentioned this.. Azure auto-hosting is only available to 应用程式s deployed to SharePoint Online.

真的吗?自动托管的应用双色球推荐一注仅在SharePoint Online中可用吗?仅提供者/开发者托管和SharePoint托管应用可用于本地吗?

尼克

尼克·帕特尔说过...

好像您已经在评论中确认过早-Azure自动托管仅在SharePoint Online中可用。

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

@匿名,

那's a great clarification, thank you! I had missed the fact that actually the 应用程式网页 is on a different domain for HTTP request processing, but in storage terms it'实际上位于同一网站集中。就容量规划等而言,这更有意义。

I'不久将更新文章的正文。再次感谢。

克里斯。

未知说过...

校正:
An 应用程式 is effectively scoped to a web only – the client APIs do not provide the ability to talk to the parent site collection, web 应用程式lication or farm

您 can talk to 主机网站 (spweb) or event site collection (SPSite) via APPS in case you have asked permission to access it.

But for web 应用程式lication and farm, yes, it's correct. 您 can'即使使用读取也无法访问它

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

@Natalia,

您'完全正确-我在下一篇文章中实际上谈论了很多 Working with the 应用程式网页, and why you should.

The idea of 应用程式s which have, say, a Manage Web permission request for the 主机网站 (or even Full Control to the host site collection) and use stuff there came to light (for me) between writing this article and that one, but I hadn'还没有纠正这个问题。

Thanks for the comment, 应用程式reciate it!

克里斯。

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

@Natalia,

主要文章文本现已更新,再次感谢您的提示:)

克里斯。

库鲁什说过...

您好,感谢您提供的有用信息。我遇到了问题,希望您能帮助med解决。我已经基于VS 2012中的模板创建了SharePoint托管应用。我没有添加任何内容。当我按下F5时,它可以工作,但是当我发布它(将.app文件添加到app-catalog网站集中)并将其添加到网站集中并浏览到它时,它说"This page can'请确保网址http_mysite是正确的。等等等等。十分感谢。

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

@Kourosh,

听起来你像避风港't configured your 应用程式 domain properly. Check out Configure an environment for 应用程式s for SharePoint (SharePoint 2013) 在TechNet上。

HTH,

克里斯。

基思·托米(Keith Tuomi)说过...

克里斯,你好

你知道吗's 可能 to customize the small icon that 应用程式ears in Edit Page > Insert > App Part?

于尔根·威斯玛(Jurgen Wiersema)说过...

你好,

您如何看待以下想法:

创建一个完美编程的普通Web部件。它所要做的就是允许您在Webpart属性的App Web中选择一个App。
Then it shows the 应用程式-page that is in the 应用程式网页 in an iFrame on any regular publishing page.

优点是:
1)您只需要部署该App-wrapper Webpart的代码。
2)它将允许网站所有者和贡献者通过添加新应用安全地添加新功能,然后将这些新应用包装在Webpart中。 3)应用' data can all be stored in the 应用程式网页 and it doesn't need to have permissions outside of the 应用程式网页.
4)对于最终用户,共享点站点的工作方式与以前相同(即状态+动态内容)。

缺点是你'd be immediately violating the 应用程式 principle and you'd需要少量服务器场部署的代码的单独服务器。

强尼说过...

克里斯(Chris)-系列文章很棒,您是否知道何时有可能向市场提交自动托管的应用双色球推荐一注?目前还不是't available.

朱希说过...

你好

Is there any gallery where we can access all the 应用程式零件 similar to web parts in web part gallery?

We have a requirement where we need to list all the 应用程式零件 (with their properties). This has to be done using CSOM. But we cudnt find any gallery or location from where we can read them programmatically. The only place we see them is when we edit a page to insert an 应用程式 part.

未知说过...

很棒的文章。我希望您能帮助我澄清一些我无法弄清的东西,因为我正在研究我们公司是否允许访问App Store。它'有关允许哪些最终用户角色安装应用的信息。

我们不希望Site Collection Admin以下的任何用户能够访问应用商店并安装应用。是否可以在管理中心中配置?如果没有,我们如何得到这个结果?

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

@南希

不幸的是我没有'我们相信这是可能的-网站管理员除了拥有网站集管理员外,还拥有从商店安装应用双色球推荐一注/加载项的权限。这是非常模型,我不知道'相信可以更改(例如,通过调整“完全控制”权限级别的权限)。

你考虑过"app requests"选项?这意味着即使网站所有者也只能“请求”应用双色球推荐一注,因此您可以对环境中使用的应用双色球推荐一注进行一些管理。

干杯,

克里斯。