Complementos de SharePoint en comparación con las soluciones de SharePoint
Obtenga información sobre cuándo desarrollar su extensión de SharePoint como una Complemento de SharePoint y cuándo desarrollarla como una solución de granja de servidores SharePoint o un solución de espacio aislado sin código.
Este artículo compara los casos de uso de Complementos de SharePoint, soluciones de granja de servidores y soluciones de espacio aislado sin código (NCSS).
- Las nuevas Complementos de SharePoint son extensiones independientes que pueden incluir lógica basada en la nube y datos, componentes de SharePoint y scripts de cliente, pero no código administrado personalizado que se ejecute en servidores SharePoint. Se instalan desde Tienda Office o un catálogo de complementos de la organización y se pueden instalar en conjuntos de servidores en el nivel local o en Microsoft SharePoint Online. Para obtener información general sobre los complementos de SharePoint, vea Complementos de SharePoint.
- Las soluciones de granja de servidores de SharePoint son paquetes de componentes de SharePoint cargados a la galería de una granja de servidores desde donde pueden instalarse. No se pueden distribuir a través de la Tienda Office y no pueden instalarse en SharePoint Online. Pueden incluir código administrado personalizado que se ejecuta en las granjas de servidores de SharePoint. Para obtener más información sobre los conceptos básicos de las soluciones de granja de servidores, vea Introducción a las soluciones y Soluciones de granja de servidores en SharePoint 2010.
- NCSS también son paquetes de componentes de SharePoint, pero se cargan en una galería de la colección de sitios desde donde se pueden instalar. Se pueden instalar en granjas de servidores locales o en SharePoint Online, pero no se pueden distribuir a través de la Tienda Office. Pueden incluir casi los mismos tipos de componentes descriptivos que los complementos de SharePoint y, como los complementos, pueden tener JavaScript, pero no contienen código administrado personalizado que se ejecuta en los servidores de SharePoint. Las diferencias en los sistemas de implementación de complementos y NCSS hacen de NCSS una mejor opción de desarrollo para una pequeña lista de escenarios. Para obtener información sobre las soluciones de espacio aislado, vea Soluciones de espacio aislado en SharePoint 2010.
Importante
Mientras el desarrollo de soluciones de espacio aislado que solo contienen marcado declarativo y JavaScript (que llamamos soluciones de espacio aislado sin código [NCSS]) es viable aún, hemos dejado de usar el código administrado personalizado dentro de la solución de espacio aislado. Hemos introducido el nuevo modelo de complementos de SharePoint como reemplazo de aquellos escenarios que requerían el uso de código administrado. El modelo de complementos separa el producto principal de SharePoint del tiempo de ejecución del complemento y esto permite mucha más flexibilidad, además de darle la capacidad de ejecutar el código en el entorno de su elección. Sabemos que nuestros clientes han hecho inversiones en soluciones de espacio aislado codificadas y se eliminarán progresivamente de manera responsable. Las soluciones de espacio aislado seguirán funcionando en las granjas de servidores de SharePoint locales en el futuro. Dada la naturaleza dinámica de los servicios en línea, se determinarán las necesidades de soporte técnico para las soluciones de espacio aislado codificadas en SharePoint Online según la demanda de los clientes. Los NCSS siguen siendo compatibles. Todas las iniciativas futuras se destinarán a enriquecer y potenciar el nuevo modelo de complementos de SharePoint. Por consiguiente, se recomienda usar el nuevo modelo de complementos en todos los nuevos desarrollos siempre que sea posible. En escenarios donde se debe desarrollar una solución de granja o la solución de espacio aislado codificada, se recomienda realizar un diseño que permita la fácil evolución hacia un modelo de desarrollo más flexible.
Desarrolle un complemento siempre que pueda
El consejo más importante que podemos proporcionarle es que desarrolle una Complemento de SharePoint en lugar de una solución de granja de servidores o NCSS siempre que sea posible. Complementos de SharePoint tiene las siguientes ventajas sobre las soluciones clásicas:
- Proporciona a los usuarios el proceso de detección, compra e instalación más sencillo.
- Ofrece a los administradores las extensiones de SharePoint más seguras.
- Proporciona el sistema de venta y marketing más sencillo basado en un almacén de complementos en línea de Microsoft.
- Aumenta la flexibilidad en el desarrollo de actualizaciones futuras.
- Maximiza la capacidad de aprovechar las ventajas de las aptitudes de programación existentes sin SharePoint.
- Integra recursos basados en la nube de forma más flexible y más sencilla.
- Le permite tener permisos distintos de los permisos del usuario que ejecuta el complemento.
- Le permite usar estándares entre plataformas, como HTML, REST, OData, JavaScript y OAuth.
- Le permite aprovechar la biblioteca de JavaScript entre dominios SharePoint para tener acceso a datos de SharePoint. Como alternativa, puede usar un servicio de token seguro proporcionado por Microsoft, compatible con OAuth o usar certificados digitales para obtener autorización para datos de SharePoint.
Diseñar complementos o NCSS para usuarios finales y diseñar soluciones de granja de servidores para administradores
Los complementos y NCSS de SharePoint usan uno de los modelos de objetos de cliente de SharePoint o puntos de conexión REST para acceder al contenido y los componentes de SharePoint. Estas API de cliente habilitan las extensiones de SharePoint diseñadas para los usuarios finales. ("Los usuarios finales" en este contexto son administradores de colecciones de sitios, propietarios de sitios web y miembros del sitio web). El modelo de objetos de servidor tiene API adicionales que permiten extensiones mediante programación de administración, configuración y seguridad de SharePoint. Estas incluyen extensiones de Administración central, comandos de Windows PowerShell personalizados, trabajos de temporizador y copias de seguridad personalizadas. Para obtener más información sobre los tipos de extensiones administrativas que puede desarrollar, consulte Administración de Windows SharePoint Services. Estas extensiones administrativas se implementan en características de SharePoint que tienen ámbito de granja de servidores, aplicación web o colección de sitios. Las soluciones de SharePointfarm también las instalan los administradores de la granja de servidores, aunque los administradores de inquilinos y colecciones de sitios pueden instalar complementos y NCSS.
El modelo de objetos de servidor también tiene una API para crear, leer, actualizar y eliminar (CRUD) operaciones en listas, bibliotecas y sitios web, y para operaciones en otros componentes de SharePoint. Esto significa que el modelo de objetos de servidor se puede usar para extensiones que diseñadas para usuarios finales, pero, por los motivos indicados en la sección anterior, las soluciones de granja de servidores normalmente no son la mejor opción para dichas extensiones. Por lo tanto, no es ninguna sorpresa que soluciones de granja de servidores no se pueda instalar en Microsoft SharePoint Online. Ya que Microsoft controla toda la administración de SharePoint Online, no es necesario para extensiones administrativas. Para obtener más información sobre los diferentes conjuntos de API en SharePoint y dónde se superponen, vea Elegir el conjunto de API adecuado en SharePoint.
Los modelos de objetos de cliente y los extremos REST no duplican las API administrativas del modelo de objetos de servidor. Además, ya que ni una Complemento de SharePoint ni un NCSS puede contener código personalizado que se ejecute en servidores de SharePoint, no pueden llamar a estas API administrativas. Además, todas las funciones de Complementos de SharePoint deben tener ámbito de sitio web y las características en NCSS tienen colecciones de sitios o ámbito de sitio web. Por lo tanto, una extensión de SharePoint administrativa no es realmente posible con una Complemento de SharePoint o NCSS. Por lo tanto, el segundo principio, pero no una regla absoluta, es que los complementos y NCSS son para los usuarios finales y las soluciones de granja de servidores son para administradores.
Diseñar NCSS para extensiones de tipo plantilla y personalización de marcas
Puede encontrar un pequeño número de escenarios de desarrollo de SharePoint para el que el modelo de complementos no es adecuado, pero en el que tampoco se puede implementar una solución de granja de servidores, quizás porque la solución deba ser instalable en SharePoint Online o tiene que poder instalarla un administrador de colecciones de sitios. De estos escenarios, existen dos grandes categorías que se superponen.
Personalización de marca: los usuarios de SharePoint a menudo quieren darles a sus sitios de SharePoint, incluyendo los de SharePoint Online, un aspecto personalizado con sus propios colores, estilos, diseños y logotipos. Esto generalmente es más fácil de hacer con NCSS que con complementos de SharePoint. Un complemento de SharePoint tiene un control declarativo únicamente sobre el aspecto de su propia web de complemento. Para la web de host, solo puede agregar de forma declarativa botones de barra de herramientas y elementos de menú (y partes de complemento). Los cambios en un sitio web de host o su colección de sitios principal, arrendamiento o aplicación web de SharePoint local debe realizarse con código o script que use uno de los modelos de objetos de cliente de SharePoint. Por ejemplo, los nuevos iconos o archivos CSS tendrían que implementarse mediante programación. Este código se puede ejecutar desde el propio complemento tras su instalación o puede ejecutarse desde el controlador de eventos de instalación de complementos. Pero crear este código supondría una gran cantidad de trabajo. Además, el complemento requeriría permisos de ámbito de colección de sitios para cambiar cualquier sitio web ajeno a sus propias web de complemento y de host y necesitaría permisos de ámbito de cliente para modificar más allá de su colección de sitios principal. Pero un NCSS de marca se puede implementar y activar en cualquier colección de sitios y puede constar únicamente de algunos componentes declarativos.
Nota:
Tenga en cuenta que las soluciones de granja de servidores de SharePoint son potencialmente más eficaces que cualquier NCSS o Complementos de SharePoint de personalización de marca, pero no son una opción en SharePoint Online.
Extensiones "como plantilla": supongamos que necesita crear una extensión de administración de SharePoint para el análisis de colaboración y la solución de crisis empresariales. La extensión incluye varios tipos de listas personalizados, flujos de trabajo sin código y otros componentes de SharePoint, todos combinados en una WebTemplate personalizada. Supongamos que empaqueta e implementa la extensión como un NCSS. Después de activar la característica de la solución, los usuarios pueden crear una subweb de administración de crisis de su sitio web de SharePoint siempre que se produzca una crisis. Puede rellenar el sitio web con datos específicos de la crisis. Por otro lado, podría implementar la misma extensión que Complemento de SharePoint con exactamente el mismo conjunto de componentes de SharePoint. Cuando se instala el complemento en el sitio del grupo, se crea inmediatamente la subred (conocida como la "web del complemento"). De nuevo, los usuarios rellenan el sitio web con los datos relevantes.
Ahora, ¿qué sucede cuando se produce una segunda crisis? Si implementa la extensión como un NCSS, los usuarios pueden crear simplemente otro subweb desde su WebTemplate personalizada. Sin embargo, si implementa la extensión como un Complemento de SharePoint, los usuarios tienen un problema. No se puede instalar una segunda instancia del mismo complemento en su sitio web primario. En una web de host solo puede instalarse una instancia de un complemento. Lo mejor que puede hacer es crear un subsitio del sitio web primario que sirva como una ubicación a otra instancia del complemento para instalarse. Cuando se instala el complemento, se crea una nueva web del complemento, que es una subsubred del sitio web primario, para los componentes del complemento. Esta comparación muestra un principio general, pero no absoluto: las extensiones SharePointcon un carácter de "como plantilla", es decir, un conjunto reutilizable de componentes que se deben configurar para cada caso de uso específico, pero que naturalmente tienen varias instancias asociadas al mismo sitio web de SharePoint, que se ajusten mejor al modelo de desarrollo de NCSS que al modelo de complementos. En este ejemplo, el elemento variable es la crisis, pero es fácil imaginar extensiones SharePoint como plantilla en el que las instancias varían por región, fecha o cualquier número de características.
Para obtener información sobre cómo expandir las posibilidades de los complementos de SharePoint, vea Usar controladores de eventos de complemento de forma conservadora y Complementos que crean extensiones.
Hacer cosas como lo haría un complemento
Como se indicó anteriormente, el código personalizado que se ejecuta en los servidores de SharePoint no se permite en complementos de SharePoint. No se trata de una limitación significativa. Simplemente significa que la lógica empresarial personalizada "baja" al dispositivo cliente o "sube" a la nube. En cualquier caso, puede usar el servicio REST/OData de SharePoint para acceder a sitios, listas y otros datos de SharePoint. También puede acceder de forma remota a los datos de SharePoint a través de los modelos de objetos de cliente de JavaScript, Silverlight o .NET Framework de SharePoint. Por último, en Teléfonos Windows, puede acceder a SharePoint a través del modelo de objetos De SharePointWindows Phone. Para obtener más información sobre los distintos conjuntos de API en SharePoint, vea Elegir el conjunto de API adecuado en SharePoint.
Un punto similar es que las características de Complementos de SharePoint no pueden tener colecciones de sitios, aplicación de web o ámbito de granja de servidores. Sin embargo, no tiene que ceder a los elementos de la interfaz de usuario o la funcionalidad. Significa que la implementación del componente se mueve fuera de SharePoint y a una aplicación web remota o cliente o una base de datos remota.
En la siguiente tabla se enumeran los componentes de SharePoint que no se pueden implementar en una Complemento de SharePoint y describe la "forma en que un complemento" obtiene la misma funcionalidad.
| Si quiere la funcionalidad de... | ... pruebe estos enfoques. |
|---|---|
| Elementos web personalizados |
Un complemento de SharePoint puede tener páginas remotas que contienen elementos web personalizados. Otra opción es mostrar una página de una aplicación web remota en un elemento del complemento en una página del sitio de SharePoint. La página remota puede tener básicamente los mismos controles de interfaz de usuario y funcionalidad que un elemento web. Para obtener más información, consulte Crear elementos de complementos para instalar con el complemento de SharePoint. |
| Receptores de eventos y receptores de características | Una Complemento de SharePoint puede contener receptores de eventos remotos funcionalmente equivalentes. Para obtener más información, consulte Manejar los eventos en Complementos de SharePoint. |
| Tipos de campo personalizados (columna) | Un complemento puede implementar un nuevo campo (columna) basado en uno de los tipos de campo existentes. Los tipos de campo calculado y procesado son especialmente flexibles. Otra opción es presentar los datos en una página web remota mediante controles o cuadrículas personalizados. |
| Servicios web personalizados basados en SharePoint Service Application Framework | Puede desarrollar sus servicios web personalizados como servicios remotos. |
| Páginas de aplicación | Un complemento de SharePoint puede incluir páginas web remotas que están disponibles desde todos los sitios web en los que está instalado el complemento. Un complemento también puede usar cualquiera de los elementos web integrados de SharePoint en las páginas del sitio. |
Algunos componentes de SharePoint, que se enumeran a continuación, se usan en escenarios de usuario final, pero no tienen equivalentes en el modelo de complemento de SharePoint y no se pueden implementar en NCSS. En estos casos, debe usar soluciones de granja de servidores.
- Definiciones de sitios personalizadas, pero las WebTemplates personalizadas, que son funcionalmente similares a las definiciones de sitio, están disponibles en NCSS y en Complementos de SharePoint. Para obtener más información, consulte Trabajar con plantillas y definiciones.
- Delegar controles. Para obtener más información, consulte Control delegado (creación de plantillas de control).
- Temas personalizados
- Grupos de acción personalizados y ocultación de acción personalizada
- Controles de usuario (archivos *.ascx) En realidad, no hay ningún escenario que los requiera.
Usar controladores de eventos de complemento con cuidado
Puede solucionar algunas de las limitaciones de Complementos de SharePoint mediante la creación de controladores de eventos de complemento instalado, complemento actualizado y desinstalación del complemento. Estos controladores son servicios web que se hospedan en servidores web fuera de la granja de servidores de SharePoint, posiblemente en la nube. Pueden usar el modelo de objetos de cliente de SharePoint o las API de REST, para realizar operaciones CRUD en componentes de SharePoint, incluidos componentes en la Web del host. En teoría, podría usar tales controladores para solucionar algunas restricciones de implementación en elementos de personalización de marca y extensiones de tipo plantilla, como se explicó anteriormente. Sin embargo, se recomienda usar estos controladores solo como último recurso, cuando no exista ninguna otra manera de proporcionar a los clientes la funcionalidad que requiere el caso de uso. Al decidir si va a crear un controlador, tenga en cuenta lo siguiente:
- La implementación mediante programación en la Web del host requiere que el complemento solicite el permiso Control total a la Web del host. No se pueden vender complementos que requieran este nivel de permisos a través de la Tienda Office.
- La implementación de componentes en el sitio web del host tiende a reducir las ventajas de seguridad de poner componentes de SharePoint en una web del complemento con su propio dominio.
- El código de implementación exhaustivo necesita una gran cantidad de trabajo para crear y depurar en comparación con el marcado de implementación descriptivo que se puede usar para los componentes de la web del complemento y en NCSS.
- Hay algunas prácticas recomendadas que se deben seguir en la creación de controladores de eventos de complemento. El código debe incluir lógica de reversión para deshacer todo que lo hizo si encuentra un error. También debe alertar sobre la infraestructura de SharePoint del error, para que la infraestructura pueda deshacer todo lo que hizo.
- Los controladores de eventos de complemento no son posibles con el tipo de Complemento de SharePoint conocido como hospedado en SharePoint.
Para obtener más información sobre los controladores de eventos de complementos, vea el nodo SDK Controlar eventos en complementos de SharePoint. Para obtener información sobre la lógica de reversión, vea la sección Add rollback logic to the handler (Agregar lógica de reversión al controlador ) del tema Create a handler for the update event in SharePoint Add-ins The latter topic is written in the context of the add-in updated event, but the basic principles apply to all add-in event handlers.
Complementos que crean extensiones
Otra forma de usar el modelo de objetos de cliente de SharePoint, o su API de REST, para resolver los problemas de implementación del componente con Complementos de SharePoint, es introducir el código CRUD en el complemento, en lugar de en un controlador de eventos de complemento. El complemento se convierte en un tipo de fábrica para un tipo de extensión personalizada. Por ejemplo, un complemento hospedado en SharePoint podría usar el modelo de objetos de SharePointJavaScript para realizar la implementación y otras operaciones de CRUD en la Web de host o en otro lugar en el arrendamiento o en la Web de la aplicación. Para ver otro ejemplo, consulte la sección Introducción rápida al aprovisionamiento remoto de Técnicas de aprovisionamiento del sitio y aprovisionamiento remoto en SharePoint, que describe cómo se usa una Complemento de SharePoint hospedada por el proveedor para proporcionar una subweb realiza el aprovisionamiento de subweb predefinido del tipo SharePoint. Sin embargo, hay mucha reinvención de la rueda y, por lo tanto, una gran cantidad de trabajo de creación de una Complemento de SharePoint de fábrica. Además, este tipo de complemento no se puede vender a través de la Tienda Office porque el complemento requiere Control total de la web del host.