Complementos de SharePoint

There are two basic kinds of SharePoint Add-ins: SharePoint-hosted and provider-hosted. To make the best decision about the right kind to develop for your scenario, start by learning what both types of SharePoint Add-ins have in common.

• Un complemento de SharePoint es un elemento independiente de funciones que amplía las funciones de los sitios web de SharePoint para solucionar un problema empresarial bien definido.
• Add-ins don't have custom code that runs on SharePoint servers. Instead, all custom logic moves "up" to the cloud, or "down" to client computers, or "over" to an on-premises server that is outside the SharePoint farm or SharePoint Online subscription. Keeping custom code off SharePoint servers provides reassurance to SharePoint administrators that the add-in can't harm their servers or reduce the performance of their SharePoint Online websites.
• La lógica de negocios en un Complemento de SharePoint puede tener acceso a los datos de SharePoint a través de una de las varias API de cliente incluidas en SharePoint. La API que usará para su complemento depende de ciertas otras decisiones de diseño que realice.
• Casi todos los tipos principales de componentes de SharePoint pueden formar parte de un Complemento de SharePoint, incluidas páginas, listas, flujos de trabajo, tipos de contenido personalizado, plantillas de listas, elementos web y más.
• The SharePoint websites where SharePoint Add-ins are installed, and from which users launch them, are called host webs. The SharePoint components, however, are generally in a special child web of the host web called the add-in web.
• Los complementos de SharePoint se pueden usar en un sitio web de SharePoint de diferentes maneras:
  • : Como una experiencia envolvente de página completa que puede tener la apariencia de una página de SharePoint.
  • : Como parte de una página web, usando un tipo especial de control llamado elemento de complemento para exponer un elemento iframe que contenga el complemento.
  • : Como comandos de la interfaz de usuario que amplían los menús y las cintas de opciones de listas, documentos y mucho más.
• All SharePoint Add-ins that users install get a tile on the Site Contents page of the SharePoint website. Clicking the tile runs the add-in.
• Un Complemento de SharePoint se configura por medio de un manifiesto del complemento, que es un archivo XML que declara las propiedades básicas del complemento, dónde se ejecuta el complemento y qué debe hacer SharePoint cuando se inicia el complemento. Entre otras cosas, el manifiesto puede especificar qué idiomas admite el complemento, los servicios de SharePoint y la funcionalidad de la cual depende, y los permisos para el web host que necesita el complemento. (Los Complementos de SharePoint tienen control total de su propia web de complemento).
• You distribute SharePoint Add-ins in add-in packages that always include at least the add-in manifest. (If there are no SharePoint components, the add-in manifest may be the only thing in the add-in package.) If the add-in has SharePoint components in an add-in web, these are included in the package as a set of XML files. Remote components that are hosted outside of SharePoint, such as a remote web application or database, are not included in the package and are deployed separately from the add-in package. (However, the add-in manifest does specify the URLs of the remote components.)
• Add-in packages can also include Office Add-ins. When the SharePoint Add-in is installed, the Office Add-in is added to an Office Add-ins catalog in SharePoint. Users can install it from the catalog into Office applications such as Word or Excel.

Unas notas para los desarrolladores veteranos de SharePoint

Las soluciones de espacio aislado que contienen código del lado servidor personalizado están en desuso. Aún admitimos las soluciones de espacio aislado “sin código” y las soluciones que solo contienen JavaScript.

SharePoint Add-ins don't use the server-side SharePoint object model. The client-side object models are greatly expanded in SharePoint. Although some APIs in the SharePoint server object model aren't available in the client object models, these are almost entirely administrative and security-related classes. Custom SharePoint logic that addresses these areas is more appropriate for a Windows PowerShell script or classic SharePoint farm solution. To learn how to choose among SharePoint Add-ins, classic SharePoint farm solutions, and sandboxed solutions, see SharePoint Add-ins compared with SharePoint solutions.

Dos formas de distribuir o vender un paquete de complementos

Puede distribuir un paquete de complementos de dos maneras:

• To an organization's add-in catalog, which is a dedicated SharePoint site collection in the SharePoint Online subscription or on-premises farm. This method is used when the add-in is custom-made for a particular organization.
• To the Office Store. The store handles the marketing process for you, from discovery to purchase to updates. Microsoft has a Seller Dashboard to help you sell add-ins through the Office Store.

Después de implementar el complemento de alguna de estas maneras, queda disponible para instalación en la página Agregar un complemento de los sitios web de SharePoint. Si el complemento necesita permisos para su suscripción primaria o para el web host, SharePoint solicita al usuario que instale el complemento para conceder los permisos.

Cuando tenga que actualizar un complemento para corregir un error o agregar funcionalidad, realice los cambios y aumente el número de versión del complemento en el manifiesto. A continuación, vuelva a implementar el paquete del complemento en el catálogo de complementos o la tienda. Dentro de las 24 horas, los usuarios obtienen un aviso en la interfaz de usuario de SharePoint que hay una actualización disponible. Pueden instalar la actualización con un solo clic.

Dos tipos de Complementos de SharePoint: hospedado en SharePoint y hospedado en proveedor

Complementos de SharePoint hospedados en SharePoint

Los complementos hospedados en SharePoint son casi todos componentes de SharePoint en una web de complemento. A veces, se dice que tienen su centro en SharePoint.

Like all SharePoint Add-ins, a user can run a SharePoint-hosted add-in from a tile on the Site Contents page of the SharePoint website to which it's installed. Optionally, it can also have two other kinds of UI components in the host web: add-in parts and custom actions (that is, custom ribbon buttons or menu items). Everything else in a SharePoint-hosted add-in is deployed to the add-in web. These components are defined declaratively using XML files, and they can include, among others:

• Páginas personalizadas
• Flujos de trabajo
• Módulos (conjuntos de archivos)
• Plantillas de lista
• Instancias de lista y biblioteca
• Vistas y formularios de lista personalizados
• Tipos de contenido personalizados
• Plantillas web
• Columnas integradas (no columnas personalizadas)
• Elementos web integrados (no elementos web personalizados)
• Archivos JavaScript
• Botones personalizados y elementos de menú para la web de complemento

All business logic in a SharePoint-hosted add-in uses JavaScript, either directly on a custom page or in a JavaScript file that is referenced from a custom page. A JavaScript version of the SharePoint object model (JSOM) is available to make it simple for the add-in to perform CRUD (create, read, update, and delete) operations on SharePoint data.

Custom pages in a SharePoint-hosted add-in are generally ASP.NET pages (ASPX), and they can declaratively reference ASP.NET and in-the-box SharePoint controls, but there can be no code behind. However, you can customize the SharePoint controls by using a client-side rendering option and custom JavaScript.

The JavaScript in SharePoint-hosted add-ins can access data and resources that are outside of the add-in web by using either of two techniques for safely working around the browser's same origin policy: a special JavaScript cross-domain library or a specific JavaScript WebProxy class. Using these techniques, a SharePoint-hosted add-in can work with data on the host web, its parent subscription, or anywhere on the Internet.

Complementos de SharePoint hospedados por el proveedor

Any SharePoint component that can be in a SharePoint-hosted add-in can also be in a provider-hosted add-in. But provider-hosted add-ins are distinguished from SharePoint-hosted add-ins because they include at least one remote component, such as a web application, service, or database, that is hosted externally from the SharePoint farm or SharePoint Online subscription. This could be a server in the same corporate network as a SharePoint farm or a cloud service. The external components can be hosted on any web hosting stack, including the Linux, Apache, MySQL, and PHP (LAMP) stack.

You have complete flexibility for the hosting framework that you use for the remote components. You don't have to use a Microsoft stack. Any web hosting framework can be used, including LAMP (Linux, Apache server, MySQL, PHP), MEAN (MongoDB, ExpressJS, AngularJS, Nodejs), Java, Python, and others, and you are welcome to use non-Microsoft development tools. In addition, the remote components can be hosted in non-Microsoft cloud services.

Puede darles a las páginas remotas del complemento la apariencia de las páginas de SharePoint con un control de cromo especial.

Los datos remotos pueden ser blobs, memorias caché, colas de mensajes, redes de entrega de contenido (CDN), y bases de datos, entre otras cosas. Además, las bases de datos pueden ser cualquier de tipo, incluidas las relacionales y las orientadas a objetos. Se puede tener acceso a datos remotos de diversas maneras. Por ejemplo, puede usar Servicios de conectividad empresarial (BCS) para explicitar los datos en una lista de SharePoint. Otra opción es exponer los datos en una cuadrícula en una página de una aplicación web remota.

Los Complementos de SharePoint usan las API de SharePoint para conectarse e integrarse con las características de SharePoint: búsqueda, flujo de trabajo, redes sociales, taxonomía, perfiles de usuario, BCS y mucho más. Esto les permite leer documentos, hacer búsquedas, conectar personas y realizar operaciones CRUD. Existe más de un conjunto de API:

• Cuando se implementan los componentes remotos con .NET, queda disponible la biblioteca del modelo de objetos del lado cliente (CSOM) de SharePoint del código administrado.
• For remote components that are not based on .NET, a set of REST/OData APIs can be used to access SharePoint data. These can also be used from a .NET client if you prefer working with an OData interface.
• La biblioteca JSOM, mencionada anteriormente, no se puede usar en una página remota, pero los complementos hospedados por el proveedor pueden tener páginas de SharePoint personalizadas en una web de complemento. En estas páginas, JavaScript puede usar la biblioteca JSOM.

Los complementos hospedados por el proveedor que tienen acceso a SharePoint son entidades de seguridad tal como los usuarios y grupos. La entidad de complemento se debe autenticar y autorizar, tal como lo hace el usuario. El complemento necesita permisos para realizar operaciones en datos de SharePoint en el web de host. En la mayoría de los escenarios, los permisos efectivos de un usuario que trabaja con SharePoint mediante un Complemento de SharePoint son la intersección de los permisos del usuario y del complemento, aunque existen algunos escenarios en los cuales un usuario puede hacer cosas con un complemento para las que no tendría permiso de otra manera.

Los complementos hospedados por el proveedor pueden conectarse a cualquier servicio web público o interno y, a diferencia de los componentes hospedados por SharePoint, pueden controlar los eventos de elemento de lista y lista de SharePoint, como agregar un elemento a una biblioteca de documentos.

Seleccionar la ruta de desarrollo de SharePoint

¿Está listo para empezar?

• Si es un desarrollador experimentado de SharePoint, le recomendamos que empiece con complementos hospedados en SharePoint. Son lo más parecido a los tipos de extensiones de SharePoint que haya realizado en el pasado.

  Introducción a la creación de complementos de SharePoint hospedados en SharePoint

• Si es un desarrollador experimentado de aplicaciones web de ASP.NET, le recomendamos empezar con complementos hospedados por el proveedor. Se crean a partir de aplicaciones web.

  Empezar a crear complementos hospedados en proveedor para SharePoint

• Si quiere desarrollar un complemento hospedado por el proveedor en una pila que no es de Microsoft, siga este procedimiento para empezar:

  • Instale las herramientas adecuadas para su pila, si aún no están instaladas.
  • Get a developer account on Office 365 for testing and debugging purposes. For details, go to Set up a development environment for SharePoint Add-ins on Office 365, or if you already have an Office 365 subscription, you just need to create a Developer Site on it.
  • El complemento usará las API de REST/OData de SharePoint para realizar operaciones CRUD en datos de SharePoint:
    • Vea documentación explicativa en el artículo Get to know the SharePoint REST service (Introducción al servicio REST de SharePoint) y en otros artículos vinculados.
    • Vea la documentación de referencia en Referencia a API de REST para SharePoint 2013.
  • If you are not using Visual Studio, you have to create the add-in manifest file and the add-in package. For information, see Explore the app manifest structure and the package of a SharePoint Add-in. There are a lot of time-saving advantages to using Visual Studio and Microsoft Office Developer Tools for Visual Studio to make your manifest and package. We recommend that you consider them, even if you use another tool to create the remote web application itself. The Community edition of Visual Studio is free.
  • Encontrará complementos hospedados por el proveedor de ejemplo para algunos lenguajes y plataformas distintos de Microsoft en la sección OfficeDev de GitHub (por ejemplo, PHP-App-for-SharePoint).

Vea también

• Glosario de SharePoint