lunes, 7 de julio de 2014

El programa de preestreno de Autohosted Apps venció

Noticia muy importante para desarrolladores de Apps para SharePoint en Office 356.  Definitivamente el tema de no tener control sobre los recursos en Azure de la Aplicación auto contenida integrada con SharePoint fue el mayor determinante para que Microsoft no renovará el programa o lo lanzara finalmente.  El 30 de junio del 2014 venció y no se espera que se relance aunque el comunicado de MS así lo estipula… más bien empoderarán a las Apps Tipo Provider Hosted para conectarse ambientes Azure con la libertad y control que los desarrolladores deseamos en las soluciones que construimos.

La buena noticia es que las Apps que están instaladas antes del 30 de Junio seguirán soportadas en Office 365, aunque no indefinidamente en el futuro MS publicará la fecha de caducidad, por el momento hay que prestar atención a como migrarlas a Provider Hosted y a Azure en un ambiente controlado por el usuario (para más información sobre esto ver el siguiente enlace: http://msdn.microsoft.com/EN-US/library/office/dn722449(v=office.15).aspx).  Pero las nuevas aplicaciones o las que estaban en desarrollo ya no se permitirá su uso. 

Microsoft sigue evolucionando en el nuevo modelo de Apps y escuchando a los clientes y desarrolladores para responder a las necesidades del mercado.  Esperamos que podamos ver un modelo maduro ágil y efectivo.

Hice algunas pruebas y esto fue el resultado:

Una aplicación de Prueba Auto Hosted sigue funcionando en SP 2013

image

image

Si le cambio de versión y la actualizó también me lo permite como dice el artículo:

<App xmlns="http://schemas.microsoft.com/sharepoint/2012/app/manifest"
     Name="SharePointAutoHostedApp"
     ProductID="{c990646d-33a7-4aee-9ea3-e4e288ce7e88}"
     Version="1.2.0.0"
     SharePointMinVersion="16.0.0.0"
>

clip_image001

Al parecer todavía es permitido subir Apps Auto Hosted hasta esta fecha aquí los pantallazos que lo prueban

image

 

image

image

image

image

 

Para más información puedes ver el artículo en el siguiente enlace:

http://blogs.office.com/2014/05/16/update-on-autohosted-apps-preview-program/

Apps4Fun!,

Juan Manuel Herrera Ocheita

miércoles, 25 de junio de 2014

Autohosted App

Estas Apps o Aplicaciones están diseñadas hasta el momento únicamente para suscriptores de Office 365 ya que se hospedan de forma automática y sin poder contralar los recursos asignados en Windows Azure, por ello Microsoft no ha hecho disponible que este tipo de Apps puedan ofrecerse en Microsoft Office Store, por lo que quedan fuera hasta el momento, Microsoft no ha descifrado como proveer la asignación de los recursos en Azure y como cobrar los recursos asignados a las aplicaciones de SharePoint hospedadas en Windows Azure.  El problema es más complejo de lo que parece ya que están hospedados en alguna ubicación que prácticamente es tierra de nadie y que dependiendo de la ubicación del Office 365 asumo así asignarán en Azure la ubicación ya que no esta a la vista de los mortales.

Uno de los atractivos de este tipo de Aplicaciones es que podemos escribir código en el lenguaje de .NET de nuestra preferencia  C# o VB.  Aunque siempre debemos de invocar el modelo de objetos cliente CSOM cuando necesitamos acceder algún recurso de lado de SharePoint Online ya que como es un App corremos con las mismas limitaciones.  Ahora bien por otro lado como esto es hospedado en Windows Azure y esta corriendo en este, podemos cambiar el modelo de la Aplicación Web de Web Forms (Como es la forma standard de SharePoint) a ASP.NET MVC para los amantes de este modelo de desarrollo de aplicaciones Web. ya que prácticamente la aplicación en Windows Azure es incrustada dentro de un IFRAME en SharePoint, pero esta realmente corriendo en Windows Azure.

Aquí interviene otro amigo para validar los permisos para ejecutar las llamadas de CSOM al portal de SharePoint llamado OAuth que es el protocolo standard para validar permisos entre diferentes “dominios” (Windows Azure / SharePoint Online).  Esto requiere conocer un conjunto de nuevas instrucciones para invocar y consumir los recursos de SharePoint que no necesitamos en el tipo de Apps SharePoint Hosted que invocamos a través de Java Script ya que este esta hospedado en el mismo domino SharePoint Online.

Bueno empecemos con nuestra primera App Autohosted, para ello invocamos Visual Studio 2013 (con Update 2 recomendado).

Luego seleccionamos la opción New Project… y dependiendo que plantilla de lenguaje escogimos deberemos de buscar la categoría Office/SharePoint, luego Apps y allí Apps for SharePoint.

image 

Escriba un nombre de aplicación a su elección y presione el botón OK.  Luego le preguntará la dirección URL de SharePoint Online donde desea instalar la aplicación. 

image

Recomiendo utilice una colección de sitios de desarrollo para que pueda hacer pruebas de depuración y sea sencillo el deployment del App (Para los que no tiene acceso a la administración de Office 365, es necesario solicitar al administrador que cree en SharePoint una colección de sitios de este tipo abajo la imagen que muestra el formulario de creación de una nueva colección de sitios).

image

De regreso en la ventana para especificar la ubicación de donde va instalarse la App es necesario indicar el tipo y aquí es donde debemos de seleccionar Autohosted.

image

Luego nos pregunta que tipo de Aplicación Web deseamos Web Forms o MVC.  Le sugiero elija la que esta habituado a desarrollar ya que de lo contrario le costará adaptarse al nuevo modelo.  Una vez dominado el nuevo modelo ya puede seleccionar el que desconoce así no tendrá  el stress de entender un nuevo modelo además de la infraestructura de SharePoint necesaria para ejecutar este tipo de aplicaciones.  Para este ejemplo seleccionaremos Web Forms.

image

Luego levantará una ventana de dialogo para autenticarnos a Office 365.  Si necesita una cuenta de Office 365 de prueba o en planes que permitan el desarrollo de Apps en SharePoint, creo que son las E1…E4.

image

La primera ventana en aparecernos es la página Default.aspx de la aplicación.

image

Si vemos hacia la esquina derecha donde aparece el contenido del proyecto creado desde la ventana del Explorador de la Solución veremos dos proyectos.  El proyecto de SharePoint que servirá para enmascarar el proyecto Web que será hospedado en Windows Azure.  De lado de SharePoint tenemos dos elementos básicos la imagen de la aplicación que utilizará para desplegarla una vez instalada y el manifiesto de la aplicación que es una declaración en XML.  De lado de la aplicación Web de forma predeterminada nos incluye las librerías de Jquery, la página Default.aspx, el archivo de configuración de la aplicación web.config, como el del empacado de la aplicación packages.config además dos archivos de código para manejar el contexto de SharePoint y la seguridad.

image

Ahora veamos que podemos encontrar en el manifiesto de la aplicación de SharePoint

image

En la pestaña General encontraremos el Titulo de la aplicación, el nombre interno de la aplicación, la versión que estamos instalando, el icono de la aplicación, la página de inicio, la cadena de consulta que se incluirá en la URL de la aplicación {StandardTokens} (esta incluye la URL del App, del sitio Host entre otros).  Ahora veamos la pestaña de Permisos.

image

En la casilla Scope o Alcance definimos el recurso o servicio de SharePoint que vamos a utilizar dentro de la aplicación y luego el Permiso que requerimos (Lectura, Escritura, Administración o Control Total).

image

Esto deberá de ser consultado en las referencias de MSDN de Microsoft para obtener el permisos correcto para consumir un servicio o la combinación de estos http://msdn.microsoft.com/en-us/library/office/fp142383(v=office.15).aspx.

NOTA: Mucho cuidado con el permisos que le damos a la aplicación este antes de instalarse el usuario será preguntado si permite conceder los permisos que solicita la aplicación para su uso.  Si los permisos son muy elevados el usuario podría denegar los permisos y no instalar la aplicación.  A parte la aplicación vía código deberá manejar los permisos sobre los recursos que se crean para proteger la información dentro de la aplicación. 

image

Otro tema importante es saber que los permisos que requiere la aplicación se refiere a un Sitio Web o a una lista es sobre el Host Web es decir al sitio Web donde se adicionó el App.  En el caso de Autohosted recuerde que el App esta hospedado en Windows Azure y no en SharePoint. 

El terminó App Web para el caso de las Autohosted no aplica ya que esta se refiere a un sitio Web en SharePoint para el App donde se pueden crear listas, bibliotecas y páginas.  Esto no es aplicable para Autohosted ya que es una aplicación Web que esta hospedada en Windows Azure y tiene recursos como una base de datos y una aplicación ASP.NET no de SharePoint.  Por lo que si requerimos crear una biblioteca será en el Host Web y no el App Web como sucede en las Apps de tipo SharePoint Hosted.

Pestaña de Prerequisitos, en esta pestaña definimos los recursos que utilizaremos de lado de Windows Azure y de SharePoint la versión mínima requerida para ejecutar la aplicación.  Deforma predeterminada incluye de lado de Windows Azure Web Site, pero podemos agregar SQL Database si planeamos almacenar alguna información en base de datos de Azure (Por el momento son los dos únicos recursos disponibles en Azure disponibles para aplicaciones Autohosted). De lado de SharePoint repetiremos los servicios que incluimos en la pestaña de permisos pero con la versión mínima requerida si así deseamos definir la aplicación.

image

En la pestaña de idiomas soportados o Supported Locales, definiremos el idioma que soporta la aplicación y el archivo de recursos con el diccionario de términos que la aplicación reemplazará dependiendo de la ubicación donde se instale y este disponible.  Para ello es necesario desarrollar la aplicación para que en vez de escribir el texto , se definan etiquetas que hagan referencia aun terminó maestro con el prefijo “$Resources:” y este sirva para mapear en el archivo de recursos el terminó en el idioma disponible en la aplicación.

image

Para más información sobre crear Apps para SharePoint en diferentes idiomas puede ver el siguiente enlace: http://msdn.microsoft.com/en-us/library/office/fp179919(v=office.15).aspx

Cuando no se define ningún idioma soportado en la pestaña de Supported Locales el predeterminado es inglés.

Pestaña de Remote Endpoints o Extremos remotos son utilizados para especificar el dominio remoto. El proxy web valida que las solicitudes emitidas a dominios remotos se declaran en el manifiesto de la aplicación. Puede crear hasta 20 entradas y solo se considera en la URL la parte de la autoridad emisora por lo que el resto es omitida.  Con ello puede utilizar una sola URL para consumir diferentes recursos dentro de la misma y evitar la validación de seguridad de dominios cruzados o Cross-domain.  Para más información puede consultar el siguiente enlace: http://msdn.microsoft.com/en-us/library/office/fp179895(v=office.15).aspx

image

Si seleccionamos el archivo de manifiesto desde el explorador de la solución y presionamos el botón derecho del ratón y escogemos la opción para Ver Código o View Code, podremos ver la declaración en XML de lo configurado.

 

image

Aquí se nos muestra otra información que nos es ocultada como el ProductID y la versión mínima de SharePoint soportada por la aplicación que en el caso de SharePoint Online es la 16 ya que es una versión que esta más actualizada que la ofrecida en la versión para instalarla localmente.

image

Bueno ya casi terminamos el alcance de este artículo introductorio.  Por lo que vamos a modificar únicamente la página default.aspx para ejecutar la aplicación y revisar como luce. 

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Default.aspx.cs" Inherits="SharePointApp1Web.Default" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
    <title></title>
</head>
<body>
    <form id="form1" runat="server">
    <div>
        Hola Mundo!
    </div>
    </form>
</body>
</html>

Para ello vamos a agregar las Palabras Hola Mundo! y revisar como se muestra con solo presionar la tecla F5.

Me pregunta si deseo otorgar los permisos solicitados por el App.

image


Le indico que si confío o Trust It.  Y la aplicación es desplegada

image

Otra forma de hacer un deploy menos automático y un poco manual es de la siguiente manera:

1) Desde Visual Studio 2013 en el Explorador de la Solución haga clic derecho y seleccione la opción Deploy Solution

image

Esta operación desinstalara la versión anterior y instalará de nuevo la solución en la URL que indicamos que lo hiciera cuando creamos el proyecto.

Luego volverá a preguntar si confiamos en la solución.

image

A diferencia de la opción anterior el App lo deja instalado y podemos verlo a través de la opción Site Contents de SharePoint.

https://infowareplus.sharepoint.com/sites/mherrera/_layouts/15/start.aspx#/_layouts/15/viewlsts.aspx

image

Si hacemos clic sobre el App nos ejecutará la aplicación y nos llevará a la página Default.aspx

image

Si desglosamos la URL notaremos los siguientes valores:

https://eb0185ff-11b6-443e-bce5-ba6e4632ceca.o365apps.net/Pages/Default.aspx

?SPHostUrl=https%3A%2F%2Finfowareplus%2Esharepoint%2Ecom%2Fsites%2Fmherrera

&SPLanguage=en-US

&SPClientTag=0

&SPProductNumber=16%2E0%2E2930%2E1220

El ID del App y luego los siguientes parámetros: SPHostUrl,  SPLanguage, SPClientTag, SPProductNumber.

El único parametro no explicado hasta ahora es SPClientTag y se refiere a: El número de control de caché de cliente (etiqueta de cliente) para el sitio web actual.

Bueno eso es todo por este artículo en los siguientes profundizaremos temas como incluir el branding del SharePoint en ejecución a través del control chrome y como invocar los recursos de SharePoint desde una aplicación Autohosted que se hospeda en Windows Azure.

Apps4Fun!,

Juan Manuel Herrera Ocheita

Lentitud del sitio debido a comprobación de CRL del certificado STS SharePoint 2013 ataca de nuevo

Nuevamente este tema tan delicado vuelve aparecer en SharePoint 2013 que ha afectado a muchos instalaciones desde la versión de SharePoint 2007. 

Al parecer SharePoint tiene una necesidad imperiosa de validar el certificado que emite el Servicio de Token de seguridad para verificar la validez del certificado y si no encuentra acceso a internet que es la norma en servidores de producción en Guatemala, hace que el servidor se ocupe de esto antes de atender las solicitudes de los usuarios y SharePoint se percibe extremadamente lento, sin reportar consumo en la RAM o en el procesador (síntoma engañoso).  Ver detalle en: http://support.microsoft.com/kb/2625048#mtDisclaimer

El error que puede mostrar es el siguiente:

Log Name:      Application
Source:        Microsoft-SharePoint Products-SharePoint Foundation
Date:          19/06/2014 7:05:40 p. m.
Event ID:      8321
Task Category: Topología
Level:         Critical
Keywords:     
User:          dominio.local\SPSSRS
Computer:      servidor.dominio.local
Description:
La operación de validación de certificado ha durado 30005.6076 milisegundos y ha excedido el umbral de tiempo de ejecución. Si esto continua sucediendo, puede que se trate de un problema de configuración. Vea http://go.microsoft.com/fwlink/?LinkId=246987 para más información.
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-SharePoint Products-SharePoint Foundation" Guid="{6FB7E0CD-52E7-47DD-997A-241563931FC2}" />
    <EventID>8321</EventID>
    <Version>15</Version>
    <Level>1</Level>
    <Task>13</Task>
    <Opcode>0</Opcode>
    <Keywords>0x4000000000000000</Keywords>
    <TimeCreated SystemTime="2014-06-20T01:05:40.246510400Z" />
    <EventRecordID>36041</EventRecordID>
    <Correlation />
    <Execution ProcessID="1276" ThreadID="18900" />
    <Channel>Application</Channel>
    <Computer>servidor.dominio.local</Computer>
    <Security UserID="S-1-5-21-1644491937-413027322-839522115-7063" />
  </System>
  <EventData>
    <Data Name="string0">30005.6076</Data>
  </EventData>
</Event>

La solución

Aunque no es muy bien vista por Microsoft, yo he tomado la opción de deshabilitar la validación del certificado para evitar que vuelva a suceder, con la variante que lo hago para cada uno de los usuarios registrados en el registro de Windows y si reinicio el servidor para asegurarme que si se corrigió el problema.  Y créanme el cambio es dramático.

Los pasos a continuación:

Ejecute el editor de Registro de Windows (Regedit.exe)

Vaya a HKEY_CURRENT_USER \ Software \ Microsoft \ Windows \ CurrentVersion \ Proveedores WinTrust \ Trust \ Publishing Software

En el panel de apariencia lado izquierdo de la clave del Estado y haga doble clic para abrirlo

Cambie los datos del valor Hexadecimal 0x00023e00 .  Que es el valor para apagar la validación.

Y si reinicie el sistema.

Una de las posibles razones por las que no puede resolver todos los problemas relacionados con la CRL es que a veces la entrada HKEY_CURRENT_USER puede no ser adecuado. Puede deberse también a que deben aplicarse a otras llaves como por ejemplo:

HKEY_USERS \ S-1-5-18 \ Software \ Microsoft \ Windows \ CurrentVersion \ Proveedores WinTrust \ Trust \ Publishing Software
HKEY_USERS \. DEFAULT \ Software \ Microsoft \ Windows \ CurrentVersion \ Proveedores WinTrust \ Trust \ Publishing Software

Revise todas y donde encuentre la llave cambie el valor.

Abajo las alternativas y soluciones relacionadas a este tema:

http://blogs.msdn.com/b/chaun/archive/2014/05/01/best-practices-for-crl-checking-on-sharepoint-servers.aspx

SharePoint4Fun,

Juan Manuel Herrera Ocheita

viernes, 6 de junio de 2014

Entrada temporal usada para la detección del tema (9ca6b807-844e-47ca-83cd-da173bb8bdfd - 3bfe001a-32de-4114-a6b4-4005b770f6d7)

Se trata de una entrada temporal que no se eliminó. Elimínala manualmente. (e25cccb2-b74c-4448-83f6-a03ee5d6c329 - 3bfe001a-32de-4114-a6b4-4005b770f6d7)

Error SQL Setup Fail al intentar instalar SSRS 2012 en un servidor de SharePoint 2013 con Windows Server 2008 R2

Este error me paso cuando estaba tratando de instalar Reporting Services de SQL Server 2012 Business Intelligence Edition sobre un Windows Server 2008 R2.

image

Y luego de varios intentos probando con la media original de SQL Server 2012 y de la versión con SP1.  Y no encontrar en la red ninguna referencia directa de este problema, se me ocurrió revisar las actualizaciones de Windows y efectivamente hacían falta varias actualizaciones del Sistema Operativo Windows 2008 R2 Standard Edition. 

image

Luego utilice la media que incluía el SP1 de SQL Server 2012 y con ello ya pude instalar Reporting Services en el servidor de SharePoint 2013.   En otras instalaciones que lo he instalado con Windows Server 2012 no he tenido este tipo de problemas, asumo que es porque es un sistema operativo que salió mucho antes que la versión 2012 de SQL Server.

En síntesis revise lo siguiente:

1. Que las actualizaciones de Windows 2008 R2 estén todas instaladas.

2. Que la media de SQL Server 2012 incluya el SP1 esto para subscriptores de MSDN no tienen ningún problema para el resto de mortales tendrán que agenciárselas para crear un SLIPSTream o esperar que este disponible en Microsoft Downloads.

SharePoint4Fun!,

Juan Manuel Herrera Ocheita

lunes, 19 de mayo de 2014

Apps for SharePoint cómo saber cual tipo usar…SharePoint, Auto o Provider Hosted?

 

Bueno Apps es el nuevo modelo de programación para adicionar funcionalidad instantánea a un portal de SharePoint OnPremises (Instalado en la red interna de la organización) o SharePoint Online en Office 365.  La gracia de este nuevo modelo es que el código se ejecuta aisladamente de la infraestructura de SharePoint.  De alguna forma algo similar a las soluciones SandBox introducidas en la versión SharePoint 2010, pero evolucionada, mejorada y ampliada.   Esto no implica que se ejecute en un entorno visual distinto ya que son incrustadas dentro de la Web UI de SharePoint a través del uso de IFRAMEs tecnología antigua que ha tomado relevancia en esta versión SharePoint 2013 para dar el efecto al usuario que esta en la misma interfaz Web aunque pueda estar corriendo inclusive en Azure o en un proveedor de terceros.

Lo mencionado anteriormente define el tipo de App que se puede desarrollar bajo el nuevo modelo disponible en Visual Studio 2012 de forma de plug-in y en 2013 ya incluidas las plantillas de Proyecto que son solamente tres plantillas: App for Office, App for SharePoint y Cloud Business App.

image

Según donde se hospeda el código así se define su nombre y los recursos a su disposición.  A continuación los nombres de los tipos de Apps:

1) SharePoint Hosted: Se hospeda en SharePoint de forma aislada en una “Web” (lo que equivale a un sitio Web de SharePoint) denominada App Web, que es creada cuando se instala el App en una Web de SharePoint denominada Host Web.  Esto quiere decir que si deseo que la funcionalidad este disponible en otro sitio de SharePoint tendré que instalar la App en el nuevo sitio web que denominamos en el ambiente de Apps Host Web. Lo interesante de esta opción es lo accesible que se tiene acceso a los recursos de SharePoint en cuanto a contenido y lo fácil que es instalar y remover como lo es un App en un teléfono.  Eso quiere decir que si la removemos deforma predeterminada toda la información almacenada en el App Web desaparecerá que por temas de seguridad este es el comportamiento esperado.  Este tipo de App esta disponible tanto para On Premises como Online y puede venderse en Office Store de Microsoft.  En esta aplicación podemos hacer invocaciones de Servicios Web a través de Ajax, pero debemos de cuidar de adicionar en IE por ejemplo las direcciones de los recursos como sitios seguros o Local Intranet para evitar errores de llamadas cruzadas de dominio o Cross Domain Calls.

imageThe components of a SharePoint-hosted app are hosted on the appweb of a SharePoint farm.

http://msdn.microsoft.com/EN-US/library/office/fp179887(v=office.15).aspx

2) Auto Hosted: Esta aplicación se hospeda en Azure y es controlada por Microsoft.  Es decir no se instala en una instancia alquilada por el ISV o proveedor del App sino en un espacio administrado por Microsoft dentro de Azure el cual le asigna los recursos de forma automática y sin control del creador del App para conocer sobre que recursos, por ello esta no esta todavía disponible en el Office Store de Microsoft, sino solamente para subscriptores de Office 365 y no esta disponible para SharePoint On Premises.  Tenemos disponible los recursos de SharePoint a través del Host Web pero el código esta corriendo en algún espacio en Azure.  También podemos ejecutar código de servidor pero solo para los recursos disponibles de lado de Azure (Web Sites & SQL Azure). 

image image

3) Provider Hosted o Remote Hosted:  Esta App se hospeda en recursos proveídos por terceros a Microsoft es decir por el ISV o Proveedor del App, que bien puede ser en una instancia de Azure administrada y pagada por nosotros mismos.   Pero aquí aunque hay mucho más control sobre donde se hospeda la App también hay mucho más esfuerzo de lado del ISV por proveer multitenancy o Multiinquilinos, manejo de las versiones del App y el soporte que debe de manejar cada versión del App que se pone a disposición en el Office Store de Microsoft.  Este tipo de App también tiene disponible los recursos de SharePoint del Host Web pero son invocados desde los recursos de terceros donde esta la funcionalidad hospedada de la aplicación.  Aquí tenemos libertada de escoger modelos de programación Web como lo son MVC o Web Forms y correr código de servidor.

imageThe components of a provider-hosted app are hosted on any web server or hosting service.

Para los tres tipos de Apps la única forma de acceder los recursos de SharePoint es a través de CSOM o el modelo de Objetos de SharePoint Cliente o vía REST API.  Y para  SharePoint Hosted tiene que ser por fuerza CSOM para JavaScript ya que no se puede hospedar código en este tipo de aplicaciones que no sea JavaScript y sus derivados, como lo son: Ajax, Jquery y Json.  Para las Apps Autohosted y Remote Hosted esta disponible en los lenguajes de código de .NET como lo son C# y VB la versión de CSOM para los desarrolladores se sientan más cómodos en su ambiente o con REST API.

image

En la imagen de arriba nos permite ver claramente para los 3 tipos de Apps donde es se hospeda el código.  Interesante que la aplicaciones Provider Hosted pueden almacenar código del lado de SharePoint además de contar con la infraestructura provista por el ISV, a diferencia de SharePoint Hosted que todo el código es almacenado en SharePoint, con posibilidades de llamar recursos como servicios Web a través de Ajax u otros sistemas de la nube por medio del servicio de Business Connectivity Services.  Estos dos tipos de Apps mencionados están disponibles para el Office Store.  Por otra parte Auto hosted aún no ya que hay temas de subscripción con Azure no resueltos aún.  Esto no quiere decir que no sea posible crear estas aplicaciones para usuarios de Office 365 pero no pueden ser ofrecidas todavía en el Office Store.

En conclusión podemos decir que las aplicaciones de más rápido desarrollo son las SharePoint Hosted con limitaciones como solo pueden ser escritas para Javascript y derivados (Ajax, jquery & json) y mayormente enfocada en los servicios y recursos disponibles en SharePoint.  Estas tiene la bondad que funcionan tanto para SharePoint Online como On Premises y puede ser ofrecidas en el Office Store de Microsoft.  Por otro lado las aplicaciones Provider o Remote hosted debemos de proveer toda la infraestructura para almacenar el código que estamos escribiendo como multitenancy, Infraestructura Web, Base de datos, control de versiones, Soporte.  Pero con al ventaja de tener toda la libertad de crear las aplicaciones con el lenguaje e infraestructura de nuestro dominio.  Por último las Apps Autohosted, nos proveer de forma predeterminada toda la infraestructura de Azure a nivel de sitios Web y Base de datos sin que tengamos que preocuparnos, pero solo esta disponible para usuarios de Office 365 y no tenemos ningún control sobre los recursos asignados en Azure. 

Dicho esto hay mucho que profundizar en cada una de ellas y conocer sus verdaderas restricciones, ventajas y esfuerzo requerido en el desarrollo por lo que en los siguientes artículos profundizaré en cada uno de ellos.

Hasta la próxima, Apps4Fun!,

Juan Manuel Herrera Ocheita

miércoles, 30 de abril de 2014

Cómo habilitar 5 niveles de menú de navegación en SharePoint Server 2013 sin una línea de código

Para poder realizar esto necesitamos lo siguiente:

1) SharePoint Designer 2013 para modificar mínimamente la master page

2) Contar una granja de SharePoint Server 2013 Standard o Enterprise

3) Tener aplicado por lo menos la actualización de Marzo 2013 de SharePoint 2013 o bien el SP1

4) Tener configurado el servicio de Metadatos

5) Poseer permisos como Administrador de la colección de sitios donde se desea el menú de 5 niveles

Para empezar debemos de crear en el Almacén de términos un grupo de términos donde definamos el menú de 5 niveles para ello a nivel del sitio en configuración del sitio encontramos el enlace como se muestra en la imagen de abajo

image

Ahora crearemos un grupo de términos que le llamaremos navegación.   Para ello haga clic en la esquina derecha de la opción “Aplicación de Servicio de Metadatos” o su correspondiente nombre según el idioma en que tiene el SharePoint

image

Luego creamos un Conjunto de Términos llamado MenuPrincipal de igual forma en la esquina derecha de la opción “Navegación”.

image

Ahora seleccione la pestaña Finalidad y seleccione la opción “Usar este conjunto de términos para la navegación del sitio” y abajo presionar el botón Guardar.  Esta opción permitirá especificar en cada termino opciones de navegación como lo es la dirección URL del destino del término u opción del menú.

image

Ahora debemos de crear los niveles de la misma forma que hicimos con los anteriores

image

Para cada término tenemos la opción de seleccionar la pestaña Navegación la opción de Vínculo simple o encabezado para escribir o seleccionar la URL Destino.  Hay otras opciones que no revisaremos en este artículo, pero podemos habilitar la opción de utilizar nombre amigables en la URL para esconder la dirección real y el nombre de la página que se esta accediendo.

image

Abajo como se definió en este ejemplo las opciones.

image

Ahora necesitamos asociar los términos que acabamos de crear, para ello debemos de volver al sitio primario e ir a la Configuración del Sitio, Aspecto, Navegación.  Sino le muestra la opción de Navegación habilite las características de publicación a nivel de colección de sitios y de sitio donde esta ubicado.

image

Luego seleccionamos la segunda opción Navegación administrada.

image

Esto nos habilitará la opción para seleccionar el conjunto de términos deseado, que para este caso es MenuPrinicipal. 

image

Para finalizar presionamos el botón Guardar.

Ahora viene el truco vamos a modificar la página Maestra para que acepte más de dos niveles en el menú horizontal de navegación o Top Link Bar.  Para ello es necesario habilitar las características de publicación a nivel de colección de sitios y de sitio, como se muestra en la imagen de abajo.

image

Para acceder a las características puede hacerlo utilizando la siguiente url o bien a través de la configuración del sitio http://hostname/_layouts/15/ManageFeatures.aspx?Scope=Site

image

Para acceder a las características puede hacerlo utilizando la siguiente url o bien a través de la configuración del sitio http://hostname/_layouts/15/ManageFeatures.aspx

Para modificar la página maestra necesitaremos utilizar el SharePoint Designer 2013 (Es libre y gratuito para descargar) o bien descargar la pagina html utilizada que en este caso es seattle.html editarla con notepad inclusive y luego volverla a subir.  Para este caso vamos a editarla en SharePoint Designer 2013 para ello es necesario abrir un sitio.  Y luego ir a la opción de Master Pages o Páginas Principales dependiendo de la versión que descargo de SharePoint Designer 2013. Seleccionamos editar la página maestra y luego buscamos la siguiente palabra compuesta MaximumDynamicDisplayLevels.

image

Esto nos llevará el siguiente segmento de código.

 

image

En el cual debemos de reemplazar el valor 2 por 4 y listo, eso es todo debemos de guardar los cambios en la página html y SharePoint se encargará de convertir a .master dicha página. No se preocupe porque esta comentada luego SharePoint la des-comenta en la versión .master.  Si quiere saber más del nuevo modelo y como funciona el tema del branding leea el siguiente artículo: http://msdn.microsoft.com/en-us/library/jj191506(v=office.15)

image

Vista de la sección en la que estamos en SharePoint Designer 2013.

image

Ahora veamos el menú en acción.

image

Bueno amigos, eso fue todo, espero que puedan realizarlo tan fácil como lo es sin necesidad de escribir una línea de código sino utilizando las opciones que están disponibles en SharePoint Server 2013.

Hasta la próxima,

Juan Manuel Herrera Ocheita