Elegir los modelos para desarrollar y hospedar su complemento de SharePoint
El modelo de complemento de SharePoint presenta una amplia gama de patrones de hospedaje y desarrollo. Algunos de estos patrones se pueden usar en combinación con otros. Por ejemplo, los complementos pueden combinar componentes hospedados en SharePoint con otros hospedados de forma remota. La manera más útil de determinar qué patrones deseará usar es comenzar con sus propios requisitos, tecnologías y objetivos, y hacer coincidirlos con las opciones y posibilidades habilitadas por los complementos de SharePoint.
Consideraciones al elegir un modelo de desarrollo
Complementos de SharePoint amplía el número de posibles pilas de tecnologías y lenguajes de programación que se pueden usar al trabajar con recursos y servicios de SharePoint. El número preciso de opciones depende tanto del tipo de complemento como del patrón de hospedaje que se elija. También es posible combinar patrones.
Complementos hospedados en SharePoint
Comience con la opción más sencilla: complementos hospedados por SharePoint o complementos cuyos elementos están hospedados en su totalidad en una granja de servidores local u Office 365. Los complementos hospedados por SharePoint se instalan en un sitio de SharePoint que recibe el nombre de web de host. Tienen sus recursos hospedados en un subsitio de una web de host llamado web de complemento. Es importante saber la diferencia entre webs de host y webs de complemento.
La imagen 1 muestra la arquitectura básica de un complemento hospedado por SharePoint.
Figura 1. Arquitectura de complementos hospedados en SharePoint
Se puede combinar un complemento hospedado en SharePoint con complementos que tienen componentes hospedados de forma remota, pero todos los complementos o partes de un complemento que se ejecutan en una web de complemento tienen el siguiente conjunto de requisitos para tres componentes clave: dónde está hospedado el complemento, cómo obtiene autorización el complemento y qué lenguaje puede usar.
| Componente | Requisito del complemento hospedado en SharePoint |
|---|---|
| Ubicación donde se hospedan los componentes de los complementos | En el dominio de complemento aislado de la granja de servicios de SharePoint |
| Cómo obtiene autorización el complemento | Los privilegios del usuario que ha iniciado sesión |
| Qué lenguaje puede usar el complemento | JavaScript (con la biblioteca de SharePoint JSOM) + HTML |
| Obtenga estas ventajas | Pero tenga en cuenta lo siguiente |
|---|---|
| Se pueden reutilizar elementos de SharePoint comunes, como listas y elementos web. | En el complemento solo se puede usar JavaScript y no se puede usar ningún código del lado servidor. |
| Relativamente fácil de crear e implementar, así que son una buena opción para complementos de productividad de pequeños equipos y automatización de procesos de negocios, con reglas de negocio de poca complejidad. | El complemento solo tiene los privilegios de autorización del usuario que inició la sesión. |
Introducción a la creación de complementos de SharePoint hospedados en SharePoint
Complementos hospedados por el proveedor
Los complementos de SharePoint hospedados por el proveedor incluyen componentes que se implementan y hospedan fuera de la granja de servidores de SharePoint. Se instalan en la web del host, pero los componentes remotos están alojados en otro servidor que no debe ser un servidor de la granja de SharePoint.
La ilustración 2 muestra la arquitectura básica de un complemento hospedado por un proveedor.
Figura 2. Arquitectura de complementos hospedados por el proveedor
La siguiente tabla muestra cómo los requisitos para la ubicación de hospedaje, la autorización de los complementos y los lenguajes son mucho menos rígidos para los complementos hospedados por el proveedor que para los complementos hospedados en SharePoint.
| Componente | Requisito de los complementos hospedados por el proveedor |
|---|---|
| Ubicación donde se hospedan los componentes de los complementos | En cualquier servidor web o servicio de hospedaje |
| Cómo obtiene autorización el complemento | OAuth o la biblioteca entre dominios JavaScript |
| Qué lenguaje puede usar el complemento | Cualquier lenguaje compatible con el servidor web o servicio de hospedaje |
Un complemento hospedado por el proveedor interactúa con un sitio de SharePoint, pero también usa recursos y servicios ubicados en el sitio remoto. Tenga en cuenta la siguiente información antes de decidir crear un complemento hospedado por el proveedor.
| Obtenga estas ventajas | Pero tenga en cuenta lo siguiente |
|---|---|
| Hospede el complemento en Microsoft Azure o en cualquier plataforma web remota, incluidas plataformas distintas de Microsoft. | Es el responsable de crear la lógica de instalación, actualización y desinstalación de los componentes remotos. |
| Use uno de los modelos de objetos de cliente de SharePoint, la biblioteca entre dominios de JavaScript o el servicio web basado en REST/OData de SharePoint para interactuar con SharePoint. | Cada forma de interactuar con SharePoint tiene opciones correspondientes para enfoques de acceso a datos. |
| Obtenga autorización a los datos de SharePoint mediante uno de los tres sistemas de autorización. | Necesita decidir entre OAuth y la biblioteca entre dominios para autorizar el acceso del complemento a SharePoint. |
Coincidir el modelo de hospedaje con los objetivos de desarrollo
Además de considerar las ventajas y restricciones técnicas de cada opción, también debe pensar en los objetivos de desarrollo a la hora de decidirse por un patrón de hospedaje. Puede usar la siguiente tabla para determinar cuál es el patrón de hospedaje que mejor satisface sus necesidades.
| Sus requisitos | Modelo de hospedaje recomendado | Ejemplo |
|---|---|---|
| Trabajar y aprovisionar exclusivamente nuevas entidades de SharePoint | Hospedado en SharePoint | Un complemento que incluye un control de selector de personas y que almacena información sobre usuarios de SharePoint en una lista de SharePoint |
| Usar entidades de SharePoint existentes e interactuar con servicios web externos (no de SharePoint) | Hospedado por el proveedor | Un complemento que obtiene direcciones de los clientes de una lista de SharePoint existente en el web de host y usa un servicio de asignación en una aplicación web para mostrar sus ubicaciones |
| Aprovisionar nuevas entidades de SharePoint e interactuar con servicios web externos | Combinación de hospedadas en SharePoint y hospedadas por el proveedor | Un complemento de asignación que aprovisiona una lista de SharePoint en la web de aplicación de forma que pueda almacenar las coordenadas de latitud y longitud para direcciones suministradas por el usuario o extraídas de una lista de SharePoint existente |
Consideraciones al elegir un modelo de hospedaje para complementos hospedados por el proveedor
Los complementos hospedados en SharePoint tienen un patrón de hospedaje fijo, debido a que están hospedados en la web de complemento. Los complementos hospedados por el proveedor ofrecen más flexibilidad a la hora de hospedar los diferentes componentes del complemento, así que si decide crear uno, deberá hacer coincidir sus objetivos y requisitos con el patrón de hospedaje adecuado.
OAuth o la biblioteca entre dominios
Una de las cuestiones más importantes que deberá preguntarse al considerar los complementos hospedados por el proveedor y en cómo construirlos es cómo obtendrá autorización el complemento para interactuar con SharePoint. Los complementos hospedados por el proveedor ofrecen dos opciones: la biblioteca entre dominios JavaScript y OAuth.
La biblioteca entre dominios le permite interactuar con más de un dominio desde los componentes remotos de su complemento mediante un proxy. Si el código del lado cliente y los permisos de un usuario que ha iniciado sesión en SharePoint son suficientes, la biblioteca entre dominios es una buena opción. La biblioteca entre dominios también es conveniente cuando desea realizar llamadas remotas a través de un firewall.
OAuth es un protocolo abierto para la autorización que permite autorización segura en las aplicaciones de cliente (aplicaciones de escritorio, web y móviles) de una forma fácil de administrar. Si tiene previsto compilar un complemento de SharePoint que se ejecute en una aplicación web remota y se comunique de vuelta con SharePoint, a menudo tendrá que usar OAuth. OAuth es necesario cuando se llama a SharePoint desde una aplicación web de forma remota hospedada que no puede usar el código de cliente (HTML + JavaScript) exclusivamente. Obtenga más información sobre el funcionamiento de OAuth en complementos de SharePoint.
En Acceso a datos seguro y modelos de objetos de cliente para complementos de SharePoint y Tres sistemas de autorización para complementos de SharePoint se explica con mayor detalle la elección entre OAuth y la biblioteca entre dominios.
OAuth con granjas de servidores de SharePoint locales
Si usa una implementación local de SharePoint, puede usar OAuth, pero tendrá que elegir entre crear complementos de alta confianza y usar un espacio empresarial de Office 365. Office 365 usa el servicio de Control de acceso (ACS) de Microsoft Azure como agente de confianza y, si no tiene acceso a un arrendamiento de Office 365, tendrá que usar Crear complementos de SharePoint de alta confianza, que utiliza certificados para establecer confianza entre el complemento y SharePoint. Puede agregar complementos de alto nivel de confianza en el catálogo de complemento de la granja de servidores de SharePoint, pero no puede venderlos en la Office Store. Si tiene acceso a un arrendamiento de Office 365, puede vincularlo a su instalación local de SharePoint y usar ACS como el agente de confianza para complementos que se instalan en SharePoint local.
La siguiente tabla enumera todos los posibles patrones para hospedar tanto los componentes de SharePoint como los componentes remotos del complemento, junto con los agentes de confianza disponibles si usa OAuth. Recuerde que deberá tener acceso a un arrendamiento de Office 365 para poder usar el ACS para establecer la confianza entre SharePoint y una Complemento de SharePoint instalada en una instalación local de SharePoint.
| Ubicación de componentes de SharePoint | Ubicación de componentes remotos | Agente de confianza |
|---|---|---|
| Local | En la nube | ACS, certificado |
| Local | Local | ACS, certificado |
| Sitio de SharePoint para Office 365 | En la nube | ACS |
| Sitio de SharePoint para Office 365 | Local | ACS |
Combinar hospedaje de proveedor y hospedaje de SharePoint
También puede compilas complementos que incluyan componentes tanto hospedados por SharePoint. Por ejemplo, puede crear un complemento de nube que incluya un tipo de contenido y una lista de SharePoint personalizados. Si decide usar esta arquitectura, el diseño y el enfoque deben tener en cuenta las limitaciones de seguridad que están integradas en el modelo. Puede usar solo JavaScript en los componentes del código que se hospedan en SharePoint y los componentes de forma remota hospedados deben usar OAuth o la biblioteca de dominios para interactuar con el sitio web de SharePoint. Al considerar este enfoque, asegúrese de que comprende cómo funciona la autorización de complementos en SharePoint.
La ilustración 3 muestra el funcionamiento de esta arquitectura si usa Azure para hospedar los componentes remotos de complemento y usa OAuth.
Figura 3. Comunicación entre servidores de complementos de SharePoint cuando se usa OAuth y Windows Azure
Estos son algunos puntos que necesita tener en cuenta si tiene previsto combinar hospedaje de proveedor y hospedaje de SharePoint.
| Obtenga estas ventajas | Pero tenga en cuenta lo siguiente |
|---|---|
| Todas las ventajas de los dos métodos. | Una arquitectura más compleja requiere una planificación más cuidadosa en torno a la comunicación de servidor a servidor y las restricciones de scripts entre sitios. |
Complementos hospedados por el proveedor en roles web de Azure
Puede hospedar un complemento de SharePoint hospedado por el proveedor en un rol de web de Azure en vez de una aplicación web (tanto si la aplicación web es local o un sitio web de Azure). Básicamente, un rol de web de Azure es un sitio web alojado en Azure y basado en Internet Information Services (IIS). Puede aprovecharse de los servicios de hosting y la escalabilidad de los roles web de Azure. También puede mejorar el rendimiento y el uso de su complemento de SharePoint, sobre todo si el complemento se utiliza mucho o la demanda cambia con el tiempo. Si el complemento de SharePoint requiere alguna vez más servidores de recursos, Azure puede distribuirlos en el complemento.
Vea estos vínculos para obtener más información sobre los roles web de Azure.
- ¿Qué es un servicio en la nube?
- Presentación de Microsoft Azure
- Escalado automático y Microsoft Azure
Como requisito previo, necesitará el SDK de Microsoft Azure para .NET (Visual Studio 2012) 1.8.1, que puede instalar si usa el Instalador de plataforma web.
El método con el que cree el proyecto en vsnv depende de si comienza con un proyecto de un complemento de SharePoint y después agrega el proyecto de rol web de Azure, o bien si comienza con el proyecto de Azure y después agrega el proyecto de SharePoint.
Agregar un servicio en la nube a un complemento existente
Si ya tiene un complemento de SharePoint hospedado por el proveedor que desea hospedar en Azure, seleccione el proyecto aplicación web en la solución para el complemento de SharePoint. En la barra de menús, seleccione Proyecto>Agregar proyecto de servicio de Microsoft Azure Cloud. Un proyecto de Azure denominado NameOfTheWebAppProject.Azure se agrega a la solución para el complemento de SharePoint. También se agregará una nueva función al proyecto para el servicio en la nube de Azure. Las Office Developer Tools para Visual Studio 2012 establecen las propiedades de proyecto necesarias para que la función web pueda trabajar con SharePoint Add-in.
Agregar un complemento a un rol web existente
Si ya tiene una función web en una nube de servicio de Azure que quiere usar como host para un complemento de SharePoint hospedado por el proveedor, abra el proyecto de la nube de Azure en Visual Studio y, a continuación, en el Explorador de soluciones, seleccione el proyecto rol de web. En la barra de menús, seleccione Proyecto>Agregar complemento para proyecto de SharePoint. Se crea un nuevo proyecto para un complemento de SharePoint hospedado llamado NameOfTheWebAppProject.Azure y se añade a la solución. Visual Studio hace referencia a la función de Azure web como host de proyecto web para el complemento de SharePoint.
Consulte también
- Aspectos importantes del panorama de desarrollo y arquitectura de los complementos para SharePoint
- Complementos de SharePoint
- Hospedar webs, webs de complemento y componentes de SharePoint en SharePoint
- Autorización y autenticación de complementos de SharePoint
- Flujo de OAuth de token de contexto para complementos de SharePoint
- Usar un sitio de Office 365 SharePoint para autorizar complementos hospedados por el proveedor en un sitio de SharePoint local
- Complementos de SharePoint comparados con soluciones de SharePoint
- Empezar a crear complementos hospedados en proveedor para SharePoint
- Introducción a la creación de complementos de SharePoint hospedados en SharePoint
- Crear un complemento hospedado por el proveedor donde se incluya un tipo de contenido y una lista de SharePoint personalizados