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>