De vuelta del MVP Summit 2016

Como cada año los MVP’s realizamos una visita al Campus de Microsoft en Redmond para asistir al MVP Summit donde tenemos la oportunidad de sentarnos con los equipos de producto para ver las novedades que vendrán en el 2017 y dar feedback.

Por desgracia no puedo compartir con vosotros demasiada información ya que es todo NDA, pero si me gustaría compartir las sensaciones de todo lo que está apareciendo público en estos últimos meses.

Este año sin duda el equipo de producto ha compartido con nosotros gran cantidad de novedades dirigidas a seguir mejorando la experiencia de usuario y ofrecer mecanismos de personalización e integración más potentes y controlados.

Para los que venimos del mundo de SharePoint llevamos ya unos años viendo como poco a poco SharePoint se ha ido transformando en un servicio más grande y diferente dentro de Office365. Esta travesía no ha sido fácil de lidiar con los continuos cambios introducidos en Office365 y la constante duda de si SharePoint como producto iría a desaparecer. Aunque, si es cierto que si me hubierais preguntado esto mismo hace un año os hubiera contestado diferente, a día de hoy, mi sensación es que Microsoft seguirá apostando por SharePoint Online, en especial en los escenarios donde se requiera trasladar procesos de negocio y disponer de un sistema de información controlado. Como prueba, podemos ver todas las novedades que se han liberado con los Team Sites, las Modern Pages, la integración con Power Apps, Flow y SPFx.

 

¿Habrá entonces más versiones de SharePoint on premise?

A día de hoy no sabría contestaros, pero si puedo deciros que al menos Microsoft seguirá actualizando la versión onpremise a través de los Feaute Packs. La prueba la tenemos en que recientemente se ha liberado el Feature Pack 1 para SharePoint Server 2016 con el que podremos incorporar ciertas funcionalidades de SharePoint Online.

Si bien con versiones anteriores del producto se tardaba unos tres años en tener un producto maduro, ahora, los equipos están a la carrera para implementar multitud de funcionalidades pequeñas sobre Office365 que en algún momento, solo algunas de ellas, estarán disponibles en un Feature Pack o una futura versión de SharePoint.

Pero si pensamos detenidamente que podría incorporar en una futura versión de SharePoint, llegaremos a la conclusión que se hace imperativo una reimplementación de todo SharePoint sobre tecnologías más modernas, “señores, ¡SharePoint se basa todavía en ASP.NET Web Forms!!!”. En esto podría entrar en juego SPFx? Probablemente, pero nos estaríamos limitando a una simple modernización del frontal quedando el core en ASP.NET.

Mi opinión (sin ningún grado de certeza), es que SharePoint 2016 será la última versión onpremise que se liberará. Que esto no quiere decir que vaya a desaparecer, si no que se transformará en otro producto o servicio más grande, moderno y más integrado con el cloud que lo que conocemos a día de hoy.

 

Cloud, cloud, cloud

Esto no es nuevo y exclusivo de Microsoft, a día de hoy, si queremos ser competitivos y ofrecer servicios diferenciadores debemos seguir trabajando en movernos al cloud. Esto que es fácil de decir, requiere de un profundo reciclado de todos los desarrolladores y administradores de SharePoint.

Los desarrolladores debemos conocer más a fondo MVC y Graph para construir soluciones que utilicen SharePoint como un servicio, TypeScript para personalizar la parte frontal, Flow para definir procesos y Power Apps para ofrecer nuevos mecanismo de interacción.

En el caso de los administradores tendrán que empezar a empaparse de los CmdLet’s de Office 365, WAAD, ADFS y conocer las capacidades híbridas de SharePoint Server 2016.

 

Grupos de Office365 en profundidad

Office365 se centra en la colaboración como uno de los pilares básicos en todos los servicios, pero no solo como un sistema para compartir información y contenidos sino de estar siempre al día de lo que sucede con un equipo de personas que comparten un mismo fin, ya sea un proyecto, un departamento o un grupo de trabajo.

En este artículo haremos un repaso sobre las distintas funcionalidades que nos ofrecen los grupos de Office365, como se integran en cada uno de los servicios para definir los ámbitos de autorización y cómo manejarlos desde el API de Office Graph.

 

Hasta ahora cada uno de los servicios de office 365 implementaba su propio sistema para compartir información, en Exchange Online disponíamos de las listas de distribución con las que compartir post de mensajes y seguir un hilo de conversación centrados en el correo, también disponíamos de la capacidad de compartir calendarios con grupos de personas donde disponer de una misma visión de las agendas; desde SharePoint Online y OneDrive disponíamos de distintos mecanismos de colaboración en especial las bibliotecas de documentos con los que compartir documentación y por último con Yammer podíamos construir nuestras propias redes de trabajo con los que tener hilos de comunicación. Todo esto suponía un esfuerzo de mantenimiento de seguridad y configuración elevado además de una heterogeneidad de interfaz de usuario.

 

El objetivo de los grupos de Office365 es ofrecer de forma transversal a todos los servicios un mecanismo con el que compartir elementos de colaboración básicos para un grupo de personas como: compartir documentación, un hilo de comunicación, calendarios, tareas y un bloc de notas de OneNote.

 

Un vistazo

Desde Office365 no encontraremos un acceso específico a la sección de grupos, si no que encontraremos una sección específica para interactuar con los grupos por cada uno de los servicios que los usen (correo, OneDrive o calendario). De este modo, si queremos centrarnos en un hilo de comunicación, accederemos al correo donde se mostrará distintos hilos de conversación.

 

Actualmente existen dos tipos de interfaz (que se irán unificando) que nos ofrecen las mismas acciones como:

  • Acceder a las conversaciones del grupo.
  • Ir al calendario compartido.
  • Visualizar los archivos subidos por los miembros del grupo.
  • Y editar un OneNote compartido.

 

Para crear un grupo seleccionaremos la opción “Crear” o el icono “+” situado al lado de la sección “Grupos”. Se abrirá entonces un panel desde el que indicaremos la información del grupo:

  • Nombre: Será el nombre del grupo visible para todos los usuarios.
  • Id de grupo: identificador del grupo que se compondrá a partir del nombre sin caracteres especiales. Podremos modificarlo seleccionando el icono del lápiz situado al lado.
  • Descripción: visible al buscar un grupo o recibir una notificación.
  • Privacidad: Indicaremos el valor “Público” para indicar si será visible por el resto de usuarios de la compañía al seleccionar la opción de “Explorar“. Marcaremos “Privado” para que el grupo sea visible solo para aquellos que reciban una invitación al grupo. Habrá que tener en cuenta que esta opción no podrá ser modificable posteriormente.
  • Idioma de notificación: Idioma en el que se recibirán los mensajes de notificación del grupo.
  • Suscribir a miembros para que reciban notificaciones: Enviará un mail a la bandeja de entrada a todos los miembros por cada mensaje enviado al hilo del grupo. Si no se activa esta opción los usuarios sin Office 2016 tendrán que acceder al panel del grupo para ver los nuevos mensajes.

 

A continuación se mostrará una pantalla donde indicaremos los miembros del grupo y aplicaremos los cambios.


 

Uno de los principios básicos de los grupos es que los usuarios sean independientes a la hora de trabajar con las distintas herramientas del grupo, de manera que todos los usuarios de Office365 puedan crear grupos y ser administradores de sus propios grupos añadiendo o invitando a las personas que estimen en cualquier momento.

 

Una vez creado el grupo aparecerá la pantalla de hilo de conversaciones del grupo con un mensaje por defecto.

 

En la parte de la derecha de la página del grupo encontraremos distintas opciones para mantener los miembros y configuración del grupo así como subscribirnos o no a las notificaciones.

Al editar un grupo se podrá subir una imagen para el grupo o bien modificar su nombre, descripción, idioma y opciones de suscripción por defecto.

Marcando la opción “Permitir que personas que no pertenezcan a la organización envíen correos electrónicos al grupo” habilitará la entrada de correos a usuarios con una cuenta externa a la organización configurada en Office365.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Desde la opción de miembros se mostrarán todos los miembros y administradores del grupo, además de añadir o eliminar miembros al grupo. Al pasar por encima de uno de los miembros y seleccionar los tres puntos aparecerá una ventana desde la que ampliar la información del contacto o promocionarlo a administrador del grupo. Si estamos trabajando con un grupo privado es aconsejable disponer siembre de varios administradores para asegurar el buen funcionamiento del grupo aun cuando falte uno de ellos.

Solo podrá añadir miembros de la organización, por lo que no podrá añadir contactos con cuentas externas al dominio de Office365 configurado.

    

 

Al crearse el grupo por defecto se creará un buzón del tipo nombredegrupo@tenant.onmicrosoft.com, todos los correos que se envíen a este buzón aparecerán como una conversación del grupo.

Para iniciar una nueva conversación pulsaremos “iniciar una nueva conversación de grupo”, desde la caja de diálogo indicaremos el mensaje a enviar, el grupo de personas (por defecto será a los miembros del grupo) o adjuntaremos un fichero o imagen a la conversación.

Por defecto los contactos suscriptos al grupo recibirán un mail de notificación en su bandeja de entrada del tipo:

Podrá iniciar un mensaje añadiendo a contactos que no sean miembros del grupo pero estas solo recibirán un correo y no tendrán acceso al grupo como el resto de miembros. A la hora de indicar los contactos podrá indicar un correo externo a la organización pero éste solo podrá responder a los correos si se activa previamente la opción “Permitir que personas que no pertenezcan a la organización envíen correos electrónicos al grupo”. Si no activar esta opción el usuario externo recibirá el correo, pero al responder al mensaje recibirá un error del tipo “Delivery has failed to these recipients or groups: Your message couldn’t be delivered because the group you’re sending to needs to know who you are before it will accept your message”.

Una vez enviado aparecerá el mensaje con una “marca azul” indicando que el mensaje no se ha leído. También se mostrará el número de mensajes sin leer junto al lado del nombre del grupo.

Cuando entremos a ver el contenido de un mensaje veremos todo el hilo de respuestas, pudiendo responder o reenviar como un correo electrónico.

 

Desde la sección de “Calendario” accederemos al calendario compartido del grupo, desde el que poder crear nuevos eventos como cualquier calendario de Exchange.

 

Al acceder a la sección de “Archivos” visualizaremos el espacio de OneDrive específico del grupo desde el que poder compartir documentación. La primera vez que acceda aparecerá un mensaje indicando que espere mientras se prepara la colección de sitios asociada al grupo. Esta colección de sitios tendrá una dirección del tipo https://tenant.sharepoint.com/sites/nombredegrupo/ con una plantilla específica muy limitada y una biblioteca de documentos donde podrá subir la documentación del grupo.

 

 

Uso de grupos de otras aplicaciones

El uso de las funcionalidades de grupos no se limita exclusivamente a un acceso web, podremos utilizarlo de forma integrada con otras aplicaciones y servicios como el cliente Office 2016, Power BI y las aplicaciones móviles de grupos.

 

Desde Power BI podremos compartir con los miembros de un grupo un dashboard y reports desde un Content Pack.

Más información https://powerbi.microsoft.com/en-us/documentation/powerbi-service-groups/

 

Administración centralizada

Como se ha comentado, los usuarios tienen por defecto la capacidad de crear grupos de Office365 de forma autónoma manteniendo sus miembros y configuraciones. Sin embargo los administradores de Office365 también podrán disponer de una administración centralizada de todos los grupos creados en la compañía. Desde el nuevo panel de administración de Office365 en la sección “Users & groups” > “Groups” se visualizarán todos los grupos creados por los usuarios pudiendo editar sus miembros y comportamientos.

 

Para desactivar la capacidad de crear nuevos grupos por parte de los usuarios de momento solo podremos realizarlo mediante PowerShell modificando la política “Outlook Web Access policy”

Set-OwaMailboxPolicy -Identity test.comOwaMailboxPolicy-Default -GroupCreationEnabled $false

Podréis encontrar en detalle cómo bloquear la creación de grupos de Office365 desde el siguiente enlace https://support.office.com/en-sg/article/Manage-Group-creation-cf0889c0-b287-4f45-bce7-42e30963f1f3?ui=en-US&rs=en-SG&ad=SG

 

 

Uso de grupos desde el API de Office Graph

 

Con el API de Office Graph dispondremos de un mecanismo unificado desde el que podremos consultar y gestionar a través de REST los mails, eventos, contactos OneDrive y grupos de un usuario. Desde el Office Dev Center y APIS de Office 365 encontraréis información sobre cómo empezar a trabajar con Office Graph, ejemplos sobre cómo registrar una aplicación. Podréis encontrar una referencia completa del API desde https://graph.microsoft.io/docs/overview
.

 

Desde el sitio de https://graphexplorer2.azurewebsites.net/ encontraremos una herramienta online desde la que probar nuestras consultas REST sobre OGraph. Al iniciar sesión con nuestra cuenta de Office365 y autorizar la aplicación podremos probar a componer distintas llamadas.

    

 

Activar beneficio Power BI Pro de MSDN Enterprise

Los usuarios de MSDN con suscripción Enterprise están de suerte, recientemente se anunció la disponibilidad de un nuevo beneficio con el que poder disponer de una licencia de Power BI Pro asociado a su suscripción.

Al acceder a la sección de beneficios de la cuenta e MSDN encontraremos un nuevo apartado donde activar la cuenta de Power BI.

Con el lanzamiento de Power BI se han redefinido el sistema de licencias y cómo interactúan los usuarios desde el punto de vista desde un administrador, para lo que os aconsejo que echéis antes un vistazo al post Power BI Licensing Revisited!

 

Para poder utilizar el beneficio pulsaremos sobre la opción “Activar Microsoft Power BI Pro” el cual nos llevará a una página donde registrar un nuevo tenant de Office365 para trabajar. Si ya disponemos de una suscripción de Office365 pulsaremos sobre la opción “Inicio de sesión” que encontraremos en la parte superior de la página.

 

Al iniciar sesión con un usuario de Office365 nos redirigirá a un formulario donde realizar la compra de la suscripción de Power BI. No os asustéis porque en el proceso os pidan el número de tarjeta, no nos cobrarán nada.

 

Si al intentar realizar el pago por tarjeta nos salta un mensaje de error del tipo “Sign-in required” que nos obliga a recargar la página deberemos añadir al site portal.office.com como sitio seguro en nuestro navegador y volver a reintentar el proceso.

A continuación insertaremos nuestros datos bancarios y método de pago. Al menos tendremos que indicar una tarjeta de crédito.

Una vez confirmado la “compra” se añadirá una nueva suscripción a nuestras suscripciones de Office365 con el nombre “Power BI Pro Developer (MSDN)”. Esta suscripción vendrá solo con un usuario.

 

Por último, tendremos que asignar la licencia a uno de nuestros usuarios de Office365 con el que queramos trabajar con Power BI. Desde el panel de administración de Office365 en la sección de usuarios seleccionaremos al usuario y editaremos sus propiedades, en la sección de licenciamiento marcaremos la opción “Power BI Pro“.

 

Ya estaríamos listos para trabajar, accederemos a https://powerbi.microsoft.com e iniciaremos sesión con el usuario habilitado.

Power BI Preview

Una de las cualidades de Office365 es la de facilitar a los usuarios el acceso a la información relevante pudiendo ser ésta desde documentos de trabajo, la actividad de sus compañeros o como en el caso de Power BI información analítica.

Con Power BI los usuarios tienen la capacidad de visualizar de un solo vistazo información e indicadores de la compañía la cual se puede analizar mediante distintos filtros que puede realizar el usuario de forma dinámica, pudiéndola visualizar mediante distintos tipos de gráficas interactivas.

Como se habrá podido apreciar Power BI es un nuevo servicio de Office365 con el que podremos publicar informes de forma sencilla y rápida.

A modo de resumen podéis consultar el vídeo de una de nuestras sesiones en las que se describe de forma muy práctica y sencilla las capacidades de Power BI, o bien acceder a la presentación de referencia.

 

A través de los dashboards los usuarios encuentran la información relevante de un solo vistazo, pudiendo acceder al detalle desde el informe que contiene cada una de las secciones.

Los reports están basados en PowerView por lo que además de disponer distintos mecanismos de visualizar la información podremos conectar de forma transparente las distintas vistas.

 

Todos los reports utilizan al menos un DataSet desde el que PowerBI conoce el tipo de origen y el modelo de datos. Los datasets podrán definirse bien desde el portal de Power BI o bien la herramienta Power BI Designer que consiste en una herramienta cliente que nos permite configurar de forma avanzada tanto el modelo del dataSet como el informe PowerView que se utilizará desde el portal de Power BI.

 

Para aquellos usuarios consumidores disponemos de las aplicaciones mobile con las que dispondremos de los dashboards y reports desde una aplicación Windows 8, iOS y Android (coming soon).

 

Para más información puedes acceder a la presentación.

 

 

MadPoint: Ciclo de mesas redondas

Desde MadPoint queremos iniciar de nuevo este año un ciclo de mesas redondas en los que podremos conversar y debatir sobre distintos aspectos de las plataformas SharePoint Server y Office 365.

Como primera mesa redonda de 2015, os proponemos el próximo jueves 7 de Mayo hablar sobre las distintas vías de desarrollo que tenemos disponibles tanto en SharePoint Server como en SharePoint Online.


 

Podéis registraros desde:


 

Datos de interés

  • Audiencia: Desarrolladores y arquitectos de software.
  • Experiencia previa: Plataforma Office 365 y/o SharePoint 2013. Conocimiento de conceptos básicos de desarrollo en SharePoint Server y SharePoint Online.
  • Fecha: Jueves 7 de mayo de 2015.
  • Hora: 19:00 – 20:30 (GMT +1).
  • Lugar: Microsoft Ibérica (Paseo del Club Deportivo 1, Pozuelo de Alarcón, Madrid). Sala Santiago Dexeus.

 

 

Os esperamos!

Web Cast Power BI – Self service BI con datos On-Premise

Desde SUGES hoy a las 17:30 nuestro compañero Hans Baumann Gaitan (Microsoft) realizará el primero Webcast de este año enfocado a conocer de primera mano que puede dar de sí Office 365 en cuanto a capacidades de BI y como explotar datos OnPremises.

Una de las nuevas experiencias en el mundo del Business Intelligence es el self service BI, una add-in de Office 365 que da una nueva dimensión a los Excel Services.

Durante la web Cast vamos a explicar en qué consiste “esto del self service BI” y cómo participan Excel, O365 y Power BI, además de alguna demo que permitirá afrontar este nuevo mundo con los conceptos un poco más claros.

 

Inicio: miércoles, 21 de enero de 2015 17:30

Podéis registraros desde el siguiente enlace: https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032612311&Culture=es-ES&community=0

Perspectivas Office365

Con el reciente cambio en la funcionalidad de sitios públicos de Office365 ha surgido una gran variedad de comentarios generando cierta incertidumbre en muchos usuarios sobre todo en lo que respecta al futuro de Office365.

Acerca de la retirada de la funcionalidad de Sitios públicos solo puedo decir que es algo que ya se venía previendo. Esta funcionalidad permitía a las empresas disponer de un sitio público pensado para la publicación de contenido y dirigido sobre a todo a pequeñas empresas. Desde el principio ha sido un servicio incompleto y muy limitado con la idea que solo fuera utilizado por pequeñas empresas, aunque personalmente no lo he recomendado nunca.

A partir de enero los nuevos clientes de Office365 no podrán utilizar este servicio, pero dispondrán de otras alternativas que se irán conociendo.

 

El hacer obsoleto el servicio de sitios públicos tiene cierta lógica en el planteamiento de Microsoft acerca del uso de Office365 y cómo se ofrecerán los servicios a lo largo de estos años. Office365 se concibe como una plataforma de productividad pensada para tareas internas o de colaboración corporativas más que una plataforma para la publicación de contenido. En este caso Windows Azure nos ofrece una gran variedad de funcionalidades para poder crear sites públicos ya que ha sido pensado como una plataforma donde poder desplegar nuestras soluciones y portales.

Para aquellos usuarios que quieran disponer de servicios integrados entre Windows Azure y Office365 podremos consumir los servicios de Office365 a través de las APIs de cada uno de sus servicios o incluso utilizar el API específica de Office365. Todo esto podremos hacerlo gracias a la integración de autenticación que podremos conseguir con Windows Azure Active Directory. Durante el DevCamp que se hico recientemente en Madrid pudimos aprender cómo hacer esta integración.

 

El caso de los sitios públicos no es el único caso en el que Microsoft ha generado cierta incertidumbre en cuanto a su futuro, las soluciones Sandbox por ejemplo, están desaconsejadas aunque de momento siguen estando disponibles. Las soluciones Sandbox nos permitían desplegar ciertas personalizaciones sobre SharePoint Online para adaptar su funcionamiento. Como alternativa se aconseja el uso de las Apps de SharePoint cuyo objetivo es aislar las personalizaciones de SharePoint en procesos externos a SharePoint integrándose a través del Modelo de Objetos Cliente o bien a través de los servicios REST de SharePoint.

 

Todo hace pensar que la tendencia será la de utilizar los servicios de Office365 en modo OOB y extraer todas las personalizaciones fuera de Office365 utilizando éste a través de las distintas APIs. Es decir, que Office365 se convertiría en una gran API con distintas implementaciones (como SharePoint o Exchange) que podríamos utilizar “as is” o bien crear nuestra propia implementación. Por ejemplo: Delve, es una implementación de Office Graph que podemos utilizar tal cual viene o bien crear nuestra propia implementación consumiendo el API de Office Graph, pero de momento no tiene pinta que podamos personalizar radicalmente el aspecto o funcionalidad de Delve.

 

Si pensamos entonces en “¿cuál es el sentido de todas estas limitaciones?”, lo más acertado es pensar que el Cloud está forzando a Microsoft a replantear el ciclo de vida de sus servicios en Cloud para adaptarse al cambio lo más rápidamente. La velocidad en la que las compañías hacen un rollout de sus servicios en el Cloud es muchísimo mayor a lo que estábamos acostumbrados con las típicas instalaciones y despliegues on-premise. Por tanto Microsoft debe estar preparado a sacar nuevas funcionalidades ágilmente. Pero para ello:

  1. Debe hacer rollouts más pequeños en menos tiempo y retirar aquellas funcionalidades que no funcionan para centrarse en las que verdaderamente aportan valor.
  2. Debe disponer de un entorno homogéneo de funcionalidades y personalizaciones para ser capaz de hacer actualizaciones de la plataforma más rápidamente.

De este modo, en lugar de esperar tres años para sacar un nuevo conjunto de funcionalidades que vayan a la par con su versión de producto on-premise, la idea sería ir sacando pequeñas funcionalidades incompletas que en función de su éxito se seguirían mejorando o bien se descontinuarían.

Esto obligaría al equipo de Office365 a realizar actualizaciones de su plataforma de forma regular, teniendo en cuenta la gran variedad de personalizaciones que pueden llegar a hacer sus usuarios, las actualizaciones se podrían complicar provocando pérdidas de servicio o malfuncionamiento. La única forma de asegurar que una actualización no provocará un comportamiento inesperado sería tener un control absoluto de la plataforma, de ahí que la tendencia sea el reducir las personalizaciones sobre los servicios.

 

Todo esto no saldrá gratis, es posible que muchos usuarios pierdan el sentido de utilizar una plataforma donde la mejor forma de personalizarla sea implementando una solución a medida. A esto se sumaría la retirada de funcionalidades y de funcionalidades incompletas que darían la sensación de ser una plataforma poco robusta.

Sin duda se plantea un año de cambios en Office365 donde esperemos que se centren más en mejorar lo que ya hay que en añadir nuevas funcionalidades incompletas. Como desarrolladores, tendremos que centrarnos más en la integración con Office365 donde se abren nuevos escenarios y posibilidades.

 

Feliz 2015!

 

 

DISCLAIMER: El texto es una opinión personal del autor, no refleja ni representa la opinión de Microsoft ni de ninguno de sus trabajadores.

 

 

 

Cómo crear un developer site y catálogo de aplicaciones en SharePoint Online

El Developer site consiste en una plantilla de colección de sitios para el test, publicación y depuración de Apps de SharePoint. Si estamos desarrollando una app de SharePoint solo podremos depurar si utilizamos una colección de sitios de tipo Developer site.

 

El catálogo de aplicaciones permite administrar de forma centralizada las apps de Office y SharePoint disponibles para ser utilizadas desde las distintas colecciones de sitio. Por defecto el catálogo de aplicaciones no está disponible, por lo que habrá que crearlo desde la sección “aplicaciones” de la administración de SharePoint Online.

A continuación seleccionaremos “catálogo de aplicaciones” y “crear un nuevo sitio de catálogo de aplicaciones”.

En la siguiente pantalla indicaremos los datos para crear una nueva colección de sitios de tipo Developer site que se utilizará como catálogo.

 

Error “Unable to open Lookup list” con columnas de taxonomía

Las columnas de taxonomía utilizan por debajo una referencia a la lista “TaxonomyHiddenList”. Durante una migración o una restauración de contenido podemos perder esta referencia provocando un error general al visualizar la columna o intentar utilizarla desde cualquiera de las vistas de una lista o biblioteca, encontrado en el log entradas del tipo:

System.Runtime.InteropServices.COMException: Esta lista no existe.  La página seleccionada contiene una lista que no existe. Es posible que otro usuario la haya eliminado.

Error while executing web part: Microsoft.SharePoint.SPException: Esta lista no existe.  La página seleccionada contiene una lista que no existe. Es posible que otro usuario la haya eliminado.

Si analizamos los logs por encima de estos errores encontraremos una traza con el ID de la lista utilizada:

Unable to open Lookup list ‘{60ef64a9-fc75-47c0-b2cf-f2b59001eea3}’.[Error was 0x81020026]

 

Para solucionar el problema debemos actualizar el esquema de la columna de taxonomía con el ID de la lista TaxonomyHiddenList y el ID del sitio raíz adecuados. El esquema de una columna lo encontraremos en la propiedad “SchemaXml” aunque si trabajamos con columnas localizadas utilizaremos la propiedad “SchemaXmlWithResourceTokens”.

Comparto con vosotros un script con el que podréis actualizar las referencias de cualquier columna de taxonomía https://gallery.technet.microsoft.com/Unable-to-open-lookup-list-e0c59b0b

if ((Get-PSSnapin “Microsoft.SharePoint.PowerShell” -ErrorAction SilentlyContinue) -eq $null) {

    Add-PsSnapin Microsoft.SharePoint.PowerShell

}

 

 

function Fix-UnableToOpenLookupList( [Parameter(Mandatory=$true)][string] $siteCollectionURL, [Parameter(Mandatory=$true)][string] $internalFieldName)

{

    $site = get-spsite $siteCollectionURL

    $web = $site.RootWeb

 

    $field = $web.Fields.GetFieldByInternalName($internalFieldName)

    if($field -eq $null)

    {

        Write-Host -ForegroundColor Red “ERROR: Missing $($internalFieldName) column.”

    }

    else

    {

        $txHiddenList = $web.Lists[“TaxonomyHiddenList”]

        if($txHiddenList -eq $null)

        {

            Write-Host -ForegroundColor Red “ERROR: Missing TaxonomyHiddenList.”

        }

        else

        {

            $strXmlSchema = “<r>$($field.SchemaXmlWithResourceTokens)</r>”

            $xmlSchema = [xml]$strXmlSchema

            $xmlfield = $xmlSchema.r.SelectSingleNode(“Field”)

            $xmlfield.List = “{$($txHiddenList.ID)}”

            $xmlfield.WebID = “{$($web.ID)}”

 

            $strXmlSchema = $xmlfield.OuterXml

            $field.SchemaXml = $strXmlSchema

            $field.Update($true)

 

            Write-Host -ForegroundColor Green “Done.”

        }

    }

}

 

 

Un ejemplo de un esquema de columna de tipo Taxonomía sería el siguiente XML.

<Field Type=”TaxonomyFieldType” DisplayName=”$Resources:EPContentManagement,EstimationTypeDisplayName;”

       List=”{60ef64a9-fc75-47c0-b2cf-f2b59001eea3}”

       WebId=”3c8e614a-be52-4210-93ac-8b40d3a85227″

       ShowField=”Term$Resources:core,Language;”

       StaticName=”EstimationType”

       Group=”$Resources:EPContentManagement,EPGroupName”

       ID=”{b04c8f3f-cbbf-4fdc-b646-639377c1395a}”

       SourceID=”{5ec29463-9b4b-403d-b6c1-958d526382b7}”

       Name=”EstimationType” Mult=”FALSE” Version=”6″ Required=”FALSE” EnforceUniqueValues=”FALSE” ShowInEditForm=”FALSE” ColName=”int3″ RowOrdinal=”0″>

  <Default />

  <Customization>

    <ArrayOfProperty>

      <Property>

        <Name>SspId</Name>

        <Value xmlns:q1=”http://www.w3.org/2001/XMLSchema” p4:type=”q1:string” xmlns:p4=”http://www.w3.org/2001/XMLSchema-instance”>7f76724b-947d-4aaf-a042-fcbe5a247852</Value>

      </Property>

      <Property>

        <Name>GroupId</Name>

      </Property>

      <Property>

        <Name>TermSetId</Name>

        <Value xmlns:q2=”http://www.w3.org/2001/XMLSchema” p4:type=”q2:string” xmlns:p4=”http://www.w3.org/2001/XMLSchema-instance”>cf28e84e-ab80-4727-a95e-55a183a63825</Value>

      </Property>

      <Property>

        <Name>AnchorId</Name>

        <Value xmlns:q3=”http://www.w3.org/2001/XMLSchema” p4:type=”q3:string” xmlns:p4=”http://www.w3.org/2001/XMLSchema-instance”>00000000-0000-0000-0000-000000000000</Value>

      </Property>

      <Property>

        <Name>UserCreated</Name>

        <Value xmlns:q4=”http://www.w3.org/2001/XMLSchema” p4:type=”q4:boolean” xmlns:p4=”http://www.w3.org/2001/XMLSchema-instance”>false</Value>

      </Property>

      <Property>

        <Name>Open</Name>

        <Value xmlns:q5=”http://www.w3.org/2001/XMLSchema” p4:type=”q5:boolean” xmlns:p4=”http://www.w3.org/2001/XMLSchema-instance”>false</Value>

      </Property>

      <Property>

        <Name>TextField</Name>

        <Value xmlns:q6=”http://www.w3.org/2001/XMLSchema” p4:type=”q6:string” xmlns:p4=”http://www.w3.org/2001/XMLSchema-instance”>{91e2b0ab-363b-47de-9c95-5d6cdad201eb}</Value>

      </Property>

      <Property>

        <Name>IsPathRendered</Name>

        <Value xmlns:q7=”http://www.w3.org/2001/XMLSchema” p4:type=”q7:boolean” xmlns:p4=”http://www.w3.org/2001/XMLSchema-instance”>false</Value>

      </Property>

      <Property>

        <Name>IsKeyword</Name>

        <Value xmlns:q8=”http://www.w3.org/2001/XMLSchema” p4:type=”q8:boolean” xmlns:p4=”http://www.w3.org/2001/XMLSchema-instance”>false</Value>

      </Property>

      <Property>

        <Name>TargetTemplate</Name>

        <Value xmlns:q9=”http://www.w3.org/2001/XMLSchema” p4:type=”q9:string” xmlns:p4=”http://www.w3.org/2001/XMLSchema-instance” />

      </Property>

      <Property>

        <Name>CreateValuesInEditForm</Name>

        <Value xmlns:q10=”http://www.w3.org/2001/XMLSchema” p4:type=”q10:boolean” xmlns:p4=”http://www.w3.org/2001/XMLSchema-instance”>false</Value>

      </Property>

      <Property>

        <Name>FilterAssemblyStrongName</Name>

        <Value xmlns:q11=”http://www.w3.org/2001/XMLSchema” p4:type=”q11:string” xmlns:p4=”http://www.w3.org/2001/XMLSchema-instance”>Microsoft.SharePoint.Taxonomy, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c</Value>

      </Property>

      <Property>

        <Name>FilterClassName</Name>

        <Value xmlns:q12=”http://www.w3.org/2001/XMLSchema” p4:type=”q12:string” xmlns:p4=”http://www.w3.org/2001/XMLSchema-instance”>Microsoft.SharePoint.Taxonomy.TaxonomyField</Value>

      </Property>

      <Property>

        <Name>FilterMethodName</Name>

        <Value xmlns:q13=”http://www.w3.org/2001/XMLSchema” p4:type=”q13:string” xmlns:p4=”http://www.w3.org/2001/XMLSchema-instance”>GetFilteringHtml</Value>

      </Property>

      <Property>

        <Name>FilterJavascriptProperty</Name>

        <Value xmlns:q14=”http://www.w3.org/2001/XMLSchema” p4:type=”q14:string” xmlns:p4=”http://www.w3.org/2001/XMLSchema-instance”>FilteringJavascript</Value>

      </Property>

    </ArrayOfProperty>

  </Customization>

</Field>

 

 

[Evento MadPoint] Novedades presentadas en la SharePoint Conference 2014

El próximo 13 de Junio nos juntaremos en MadPoint para ver todas las novedades presentadas el pasado mes de marzo en la SharePoint Conference 2014 en Las Vegas.

Hablaremos del reciente Service Pack 1, de las novedades para desarrolladores, del fin de InfoPath, de la nueva versión que se lanzará en 2015, de todas las novedades de Office 365 y del nuevo concepto del Office Graph y de Oslo.

Queremos que este evento sea participativo y nos gustaría abrir un poco de debate para comentar qué os parecen todas estas novedades y cómo veis el futuro de la plataforma. ¡Os animamos a participar!

 

Regístrate gratis:

http://www.eventbrite.com/e/madpoint-novedades-presentadas-en-la-sharepoint-conference-2014-tickets-11780416543

   

 

Datos de interés

  • Audiencia: Jefes de proyecto, decisores de negocio, desarrolladores.
  • Experiencia previa: Plataforma Office 365 y/o SharePoint 2013.
  • Fecha: Viernes 13 de Junio de 2014.
  • Hora: 16:00 – 19:00 (GMT +1).
  • Lugar: Colegio Tajamar, C/ Pío Felipe 12, 28038 MADRID . Sala Student Tech Club.
  • Evento gratuito

 

Agenda:

  • Resumen de las novedades del Service Pack 1 y de la SharePoint Conference
  • Novedades para desarrolladores de SharePoint y Office 365
  • Relaciones en la empresa, el nuevo Office Graph y Oslo
  • InfoPath ha muerto, ¿qué nos depara el futuro?

 

Página de registro (gratis):

http://www.eventbrite.com/e/madpoint-novedades-presentadas-en-la-sharepoint-conference-2014-tickets-11780416543

 

Te esperamos!!!