Tres maneras de pensar sobre las opciones de diseño de los complementos de SharePoint
Requisito previo: primero debe familiarizarse con el artículo Complementos de SharePoint.
En este artículo se examinan las opciones de arquitectura de los complementos de SharePoint de tres maneras diferentes. En primer lugar, obtendrá información sobre las categorías más importantes de opciones de diseño; en segundo lugar, verá la arquitectura de complementos en términos de niveles de aplicación; y, en tercer lugar, verá un conjunto de factores que debe tener en cuenta al tomar las decisiones de diseño.
La primera decisión que se debe tomar es si la extensión de SharePoint debe ser un complemento de SharePoint o una solución clásica de granja de servidores de SharePoint o solución de espacio aislado. Algunas partes del modelo de objetos de SharePoint, principalmente las relacionadas con la seguridad y la personalización de administración de SharePoint, no son accesibles desde los clientes. Solo el código personalizado que se ejecuta en el servidor de SharePoint pueda obtener acceso a ellos y no se le permite al código de servidor personalizado en una Complemento de SharePoint (un amplio conjunto de modelos de objetos de cliente y un servicio REST/OData permiten a las Complementos de SharePoint crear casi cualquier extensión de SharePoint orientada al usuario final). (Un amplio conjunto de modelos de objetos de cliente y un servicio REST/OData permiten a los complementos de SharePoint realizar casi cualquier extensión de SharePoint orientada al usuario final).
Para obtener más información sobre cómo decidir entre soluciones clásicas y complementos, vea Complementos de SharePoint en comparación con soluciones de SharePoint. También es útil para tomar esta decisión elegir la API correcta establecida en SharePoint.
Elementos clave en el diseño de complementos de SharePoint
Se deben realizar tres categorías principales de opciones cuando se diseña un complemento de SharePoint. Como siempre, el diseño de aplicaciones implica ventajas y desventajas; las opciones que cree en una categoría pueden limitar sus opciones en otra. Tenga en cuenta que no todas las combinaciones de opciones posibles son factibles.
Hospedaje: los complementos de SharePoint se pueden dividir en dos tipos principales, según cómo se implementan y hospedan.
Los complementos hospedados en proveedor tienen su almacenamiento de datos y su lógica empresarial principal que el desarrollador implementó y hospedó fuera de SharePoint en servidores o en una cuenta de la nube que proporciona el desarrollador. Él es responsable de exigir el aislamiento entre las cuentas de los diversos clientes que compren el complemento. Los complementos también pueden tener componentes de SharePoint. Estos se hospedan en la granja de servidores de SharePoint del cliente. Este tipo de complemento es el que proporciona mayor flexibilidad en las otras categorías de opciones de diseño. También permite usar plataformas que no son de Microsoft para los datos externos, la lógica y la interfaz de usuario (IU) web. (Dentro de la categoría de complementos hospedados por el proveedor, también debe distinguir entre los complementos cuyos componentes remotos están dentro del mismo firewall corporativo que la granja de servidores de SharePoint y aquellos cuyos componentes remotos están fuera de ese firewall. Los sistemas de autorización para estos dos escenarios son diferentes, lo que, a su vez, hace una diferencia en qué lenguaje de programación se usa para acceder a los datos de SharePoint).
SharePoint-hosted add-ins consist entirely of SharePoint components, such as lists, content types, workflows, and web parts. There are no external components. For more information about the kinds of SharePoint components that can be included in SharePoint Add-ins, see Host webs, add-in webs, and SharePoint components in SharePoint.
Para obtener información más detallada sobre las opciones de hospedaje de los complementos de SharePoint, consulte Elegir patrones para desarrollar y hospedar un complemento de SharePoint.
Conectividad: SharePoint admite tres tipos de acceso seguro a los datos para crear, leer, actualizar y eliminar (CRUD).
Las aplicaciones web externas en un complemento usan el protocolo de OAuth para obtener acceso a datos de SharePoint. Para obtener más información, vea Autorización y autenticación de complementos de SharePoint.
JavaScript puede obtener acceso a datos en una web de complemento de SharePoint y en otros sitios web dentro del arrendamiento de la misma con una biblioteca especial de JavaScript que habilita la creación segura de scripts entre dominios. Para obtener más información, vea Obtener acceso a datos de SharePoint desde complementos con la biblioteca entre dominios.
Una Complemento de SharePoint también puede obtener acceso a datos externos con Servicios de conectividad empresarial (BCS) o un proxy de servicio web. Para obtener más información, vea Servicios de conectividad empresarial en SharePoint y Consulta de un servicio remoto mediante el proxy web en SharePoint.
Para obtener más información sobre el acceso y el almacenamiento de datos en Complementos de SharePoint, consulte Almacenamiento de datos en Complementos de SharePoint, Acceso a datos seguro y modelos de objetos de cliente para Complementos de SharePoint y Trabajar con datos externos en SharePoint.
UI: There are three ways to surface a SharePoint Add-in in SharePoint: at a minimum, all add-ins are surfaced in a full webpage. Optionally, an add-in can also be surfaced through an add-in part, and through a menu item or ribbon button. For more information, see UX design for SharePoint Add-ins.
Nota:
Los clientes pueden instalar complementos de SharePoint en varias colecciones de sitios en un inquilino o en un sitio web por sitio web. Los primeros se denominan complementos con ámbito de inquilino. Si quiere que los clientes tengan la opción de ámbito de inquilino, es posible que no incluya un botón de cinta de opciones personalizado o un elemento de complemento. Para más información, vea Tenancies and deployment scopes for SharePoint Add-ins.
Niveles arquitectónicos
Otra forma de pensar en sus opciones de arquitectura del complemento es pensar que el complemento tiene tres niveles lógicos: la interfaz de usuario, la lógica empresarial y el acceso a datos. Cada capa tiene múltiples opciones de implementación; otra vez, las opciones que elija para una capa limitarán las opciones para las demás. Las siguientes tablas describen algunas opciones, y sus usos, de los componentes de un complemento remoto y los componentes de SharePoint.
Componentes remotos en complementos hospedados por el proveedor: Opciones para cada nivel
| Nivel | Opciones | Adecuado para |
|---|---|---|
| Interfaz de usuario | Páginas ASP.NET en una aplicación MVC o un formulario ASP.NET hospedados en un rol web de Azure. | Aprovechar las habilidades del personal de desarrollo de ASP.NET |
| Página HTML 5 con JavaScript | Interfaz de usuario enriquecida | |
| PHP u otro tipo de página web que se puede hospedar en un servicio en la nube que no sea de Microsoft | Integración de aplicaciones que no son de Microsoft en SharePoint | |
| Silverlight en una aplicación de Windows Phone | Acceso móvil a datos de SharePoint e integración con notificaciones de inserción y datos de geolocalización | |
| Lógica empresarial | JavaScript del lado cliente | Lógica de la interfaz de usuario y lógica empresarial ligera; permite obtener acceso a datos de SharePoint mediante el modelo de objetos de cliente de JavaScript |
| Un rol de trabajo de Microsoft Azure | Función con un uso intensivo del procesador; permite obtener acceso a datos de SharePoint mediante el modelo de objetos de cliente de .NET Framework | |
| Un servicio web remoto | Función con un uso intensivo del procesador; permite obtener acceso a datos de SharePoint mediante el modelo de objetos de cliente de .NET Framework | |
| Datos | SQL Azure | Datos relacionales completos |
| Almacenamiento de tablas de Azure | Configuración de la aplicación y otros metadatos | |
| Almacenamiento de blob de Azure | Almacenamiento de archivos grandes | |
| Un servicio en la nube que no es de Microsoft | Aprovechamiento de orígenes de datos existentes que se basan en plataformas que no son de Microsoft | |
| Una base de datos en el propio servidor del desarrollador | Hospedaje por el proveedor y control de desarrollador de aislamiento de espacio empresarial |
Componentes de SharePoint: opciones para cada nivel
| Nivel | Opciones | Adecuado para |
|---|---|---|
| Interfaz de usuario | Vistas personalizadas de bibliotecas y listas de SharePoint en páginas web de complemento | Permite maximizar la integración con la apariencia y el comportamiento de SharePoint |
| Aplicación de Silverlight hospedada en un elemento web (o dentro de <etiquetas de objeto> ) en una página web de complemento | Permite aprovechar la experiencia de desarrollo existente de Silverlight; interfaz de usuario enriquecida | |
| Lógica empresarial | Un flujo de trabajo de SharePoint | Implementación de procesos empresariales |
| JavaScript del lado cliente complementado con la biblioteca entre dominios de SharePoint | Permite obtener acceso a datos de SharePoint en la web de complemento; permite obtener acceso a datos de otros sitios web dentro del espacio empresarial | |
| Un controlador de eventos remoto | Administrar eventos de CRUD en listas y bibliotecas de SharePoint con lógica hospedada externamente | |
| Datos | Bibliotecas y listas de SharePoint que se consultan con Lenguaje de marcado de aplicaciones de colaboración (CAML) o consultas LINQ con uno de los modelos de objetos de cliente de SharePoint | Aprovechamiento de la experiencia de desarrollo de SharePoint y .NET Framework existente |
| Listas y bibliotecas de SharePoint que se consultan con el servicio web REST/OData de SharePoint | Permite obtener acceso a datos de SharePoint desde plataformas que no son de Microsoft; aprovecha la experiencia de consulta de OData existente | |
| Un modelo de BCS | Exposición de datos externos en SharePoint como una lista de SharePoint |
Factores a considerar al tomar decisiones de diseño
El modelo de Complemento de SharePoint permite muchas más posibilidades de diseño que no son posibles con un árbol de decisión simple. Estos son algunos de los factores más importantes que se deben tener en cuenta al construir la arquitectura de una Complemento de SharePoint.
Por supuesto, lo más importante son las funciones que desea que estén disponibles a los clientes, los casos de uso. Por ejemplo, si el complemento incluye funciones intensivas de procesador, como convertir archivos de vídeo a otro formato de vídeo, ese sería un argumento para crear un complemento hospedado por el proveedor en el que el procesamiento se realiza en uno de los servidores o en un rol de trabajo de Azure.
Ya que un tipo de Complemento de SharePoint, los complementos hospedados en proveedor, necesitan que usted (o su cliente) hospeden los componentes que no son de SharePoint y hagan cumplir el aislamiento del inquilino. Para ello es preciso que tenga en cuenta si dispone del hardware y del personal de TI para hacerlo (o si lo harán sus clientes de destino).
Cuáles serán los clientes de destino también es una consideración fundamental. Si usa todos sus complementos internamente (es decir, no tiene clientes externos), o si solo los usa un único cliente, los complementos hospedados en proveedor son significativamente más fáciles de implementar y mantener que cuando tiene clientes externos o múltiples clientes que utilizarán el complemento. Si piensa vender el complemento al público, también debe tener en cuenta si lo comercializará a empresas con cuentas SharePoint Online, a las que tienen sus propias granjas de servidores de SharePoint o a ambas.
También debe tener en cuenta sus habilidades o las habilidades de su personal de desarrollo. Por ejemplo, si es un desarrollador de ASP.NET con experiencia, eso sería un punto a favor de crear una aplicación web remota y exponer datos de listas de SharePoint en una página de ASP.NET. Por otro lado, si es un desarrollador de SharePoint con experiencia, eso sería un punto a favor de usar una página del sitio y una lista de SharePoint personalizadas con JavaScript para realizar el procesamiento.