SharePoint Lookup Field Throttling Causes Missing Fields in CSOM Query

A very annoying bug appeared few weeks ago in one of our production environments with SharePoint 2013.

SYMPTOMS

You have a custom list with some lookup columns that refer to other lists. In our case the main list contained news and the lookup columns contained the classification of the news.

You add a new lookup column to the list, due to customer feedback.

Suddenly, you can’t get the list results any more by code. When you do a CSOM query, the lookup fields are lost. Only the non-lookup fields are retrieved.

CAUSE

SharePoint throttling also includes list item maximum lookup references. It is set to eight (8) lookup fields per list, by default.

Resource Throttling

This particular configuration is set on the web application throttling page in Central Administration, under the heading “List View Lookup Threshold”.

SOLUTION

If you don’t need all of the lookups at the same time, you can still make the query by choosing the fields you want to retrieve. However, in our case we needed all of the classification columns.

In this case you have two choices:

  • Increase the list lookup threshold limit to more than 8 (that’s what we did)
  • Establish a large query window, an interval during the day during which you can perform the queries

De buenos propósitos cara al 2017

Tenía la intención de escribir un post resumen del año 2016, pero los posts de los compañeros como Marc Rubiño o Yeray han tenido que ver en el contenido y enfoque del mismo. Más que un mero resumen, es además una carta de propósitos.

Mirando el 2016 en retrospectiva

Para mí, este pasado 2016 ha sido un año muy satisfactorio personal y profesionalmente.

He participado en varios eventos internacionales de SharePoint y Office 365, sobre todo en las comunidades técnicas portuguesa y belga, que conozco muy bien desde hace años y siempre me hace especial ilusión. Participé en el MVP Summit en Redmond, para poder aportar mi granito de arena a que Microsoft saque mejores productos para sus clientes, que son los nuestros también. Dentro de SUG.CAT, el grupo de usuarios de SharePoint de Catalunya, he impulsado el segundo SharePoint Saturday Barcelona (que salió mejor que el primero, así que algo habremos aprendido por el camino) y he colaborado en la organización del SharePoint Saturday Madrid.

New Year

Escribí un curso de Reactive Extensions en Pluralsight, que siempre es una experiencia gratificante.

Junto con otros compañeros en Sogeti, participé en una candidatura “atípica” de representación sindical (siendo no afiliados a ningún sindicato). Ganamos en Barcelona y nos pusimos a mejorar aquellas cosas que veíamos necesarias, democratizando la representación de los trabajadores y buscando ideas que ayuden a que Sogeti sea un buen sitio tanto para la empresa como para la plantilla.

En Sogeti he podido impulsar algunas medidas de cambio, tanto tecnológicas como culturales. No son muchas, ya que hacer cambios en una empresa tan grande es más lento, pero me dan la satisfacción de poder pensar en otras más ambiciosas. He hecho de mentor de otros compañeros con excelentes capacidades técnicas pero poco recorrido en el mundo de la comunidad técnica. Incluso he tenido que hacer algún que otro “chantaje” para poder sacar a la palestra aquellas personas que creo que se merecen explicar sus experiencias y de las que todos podemos aprender.

Inner circles y demás “bestias”

Le robo el título a Yeray Smile espero que no le importe.

Es precisamente en este aspecto de hacer el esfuerzo a sacar nuevos talentos en la comunidad donde empecé a notar cierta resistencia por una parte de la comunidad de los ponentes establecidos. Para que nos entendamos, con “ponentes establecidos” me refiero a la gente de la talla de Yeray, de Marc, de Eduard, de Lluís, por poner un ejemplo.

El hecho es que algunos de los ponentes establecidos no creen que tengamos que hacer nada para que se vaya renovando el cartel de los ponentes en la comunidad. Sostienen que la gente buena ya se abrirá el camino, lo que es yo también creo, y que no hay que hacer nada especial que no estemos haciendo ya. Aquí es donde discrepo. En mi opinión, podemos hacer mucho más y lo iré explicando en otros posts.

Nota para navegantes: el cacareado y malentendido “inner circle” para mí es la comunidad de los ponentes establecidos, dentro de los cuales me incluyo.

La misma opinión sale a relucir en los comentarios respecto a la falta de diversidad en los eventos tecnológicos. Todavía somos una minoría los que pensamos que este es un problema grave. La gran mayoría de la comunidad ya está cómoda con que la audiencia y el cartel de speakers sean hombres blancos mayoritariamente “frikis”. Yo he decidido luchar por cambiar esta situación. ¿Utópico? Puede que sí. Por mi parte prefiero compartir la misma utopía con gente como Jon Skeet y hacer acciones tangibles para no participar en la perpetuación de la falta de diversidad como para participar en la búsqueda de maneras de inclusión de voces minoritarias en el debate técnico general.

Igual que los “development evangelists” que se dedican a convencer a su público sobre la necesidad del cambio (tecnológico), yo me dedico a convencer a mi público en la comunidad sobre las cosas que tenemos que cambiar. No voy a pedir perdón por ello.

MVPs, las empresas y las comunidades

Entrando de lleno al espinoso tema de los MVPs (de los que formo parte) y de la relación de empresas con la comunidad, voy a exponer mi opinión.

El programa MVP de Microsoft tiene su parte positiva y su parte negativa. La positiva la conocemos: ayuda en la marca personal, el prestigio del profesional (y por extensión de la empresa en la que está), la comunidad de otros MVPs y la interacción con el equipo de producto. Ah, ¡y la suscripción MSDN complementaria, por supuesto!

La parte negativa: la opacidad en el proceso de selección es quizás la más importante. Donde falta luz siempre se forman cuentos, leyendas y fábulas sobre quién está “en el bombo”, con qué criterios y con qué “padrinos”. También cada MVP es un mundo y los hay que siguen siendo los mismos tipos alegres y accesibles de siempre y los hay que se endiosan y se piensan que están más allá del bien y del mal. La riqueza humana es lo que tiene.

Las empresas que tienen en su nómina a un MVP o varios, tienen un activo de branding y de marketing muy útil para vender de cara a los clientes y los futuros empleados. No hay nada de malo en ello. Lo malo es poner objetivos de ser MVP, ya que estaríamos pervirtiendo el modelo, tal como bien expone Yeray en su post.

Y si soy una empresa, ¿cómo podría colaborar con la comunidad? Yo creo que hay muchos modelos de colaboración posibles: patrocinio de las comunidades locales donde esté ubicada la empresa, liberar partes de su código como open-source, la cesión de espacios para charlas (que siempre nos faltan en los grupos de usuarios), dejar tiempo a sus empleados a que asistan a los eventos durante las horas de trabajo (que hay pocas empresas que lo hacen). Para mí esto es ayudar a la comunidad como empresa.

Otro mundo aparte son los eventos comerciales donde se cobra entrada y el organizador de turno decide sobre quién habla y quién no. Allí cada empresa es libre de patrocinar lo que le parezca adecuado en términos de beneficio esperado. Y cada ponente es libre de aceptar los términos o no.

Organizando los eventos como los SharePoint Saturday de Madrid y Barcelona sí que me he encontrado con situaciones en las que un patrocinador suponía que su patrocinio incluye un charla. Mi opinión es que hay sitio para charlas de patrocinadores, debidamente separadas de las charlas de la comunidad (como p.ej. poniéndolas en una hora dedicada o durante la hora de comer).

De cara al 2017

Vale, ya he dicho lo que quería decir sobre la comunidad y los temas candentes. Ahora voy a explicar lo que serán mis propósitos de este año 2017.

Igual que Marc Rubiño, continuaré siendo selectivo con los eventos en los que me involucro. Me centraré en aquellos que son realmente para la comunidad y que cuentan con medidas para tener asistentes y ponentes diversos.

Seguiré creando espacios para otras personas: montar eventos, ayudar a comunidades y mentorizando a las personas valiosas que pueden aportar su voz al debate.

Seguiré buscando ideas de mejora personal y profesional, compartiéndolas con todo el mundo que esté interesado en mejorar.

Y, finalmente, dedicaré el máximo tiempo a mi prioridad número 1: mi mujer Vanessa y nuestro/a futuro/a niño/a que está en camino.

Programar para SharePoint hoy (I): el legado

En esta serie de posts intentaré hacer un resumen de las posibles opciones que tiene un desarrollador (o desarrolladora) para programar una aplicación que tenga que comunicarse de algún modo con SharePoint, en cualquiera de sus variantes.

<ModoAbueloCebolleta>
En los tiempos en los que los dinosaurios vagaban por la Tierra, el ser humano vivía en cuevas y SharePoint era novedad todavía, para programar tenías dos opciones. Cada nueva versión de SharePoint traía algún modo nuevo, así que hoy en día tenemos bastante elección y a veces se hace difícil saber que enfoque es el mejor para una situación dada. Por favor…que viejo me siento contando batallas. ¡Que alguien me sacrifiqueeeee!
</ModoAbueloCebolleta>

El legado

Desde que SharePoint corre sobre .NET Framework (es decir desde su versión 2003), hay dos métodos de desarrollo que están todavía presentes sin muchos cambios. Son el “full-trust code” (FTC) y los servicios web SOAP (o ASMX).

Legacy rusty chain and padlock

Full-Trust Code o SSOM (Server-Side Object Model)

Full-Trust Code o SSOM es el modelo de programación de SharePoint donde nuestro código se ejecuta dentro de los procesos de SharePoint (IIS y/o servicios Windows), como una parte adicional al propio código de Microsoft, para lo bueno (la velocidad) y lo malo (hundir el rendimiento de SharePoint mismo).

Este es el modelo “clásico” de los programadores SharePoint “de los de antes”. Si eres uno de ellos, tengo una mala noticia y otra buena.

La mala es que este modelo es cada vez menos relevante en los desarrollos de SharePoint. Así que si tu idea de especialización era focalizarte en código de SharePoint y te memorizabas las listas de los objetos que empiezan por SP*, tendrás que reciclarte, ¡y pronto!

La noticia buena es que FTC no desaparecerá. Siempre habrá alguna funcionalidad que es necesaria para los desarrollos de SharePoint on-premises, y no habrá otra solución tan elegante y eficiente que el código de SharePoint en el mismo servidor de SharePoint. Vaya..que saber SSOM será el equivalente de programadores COBOL en el siglo XXI.

Las limitaciones serias de este modelo son tener que desplegar en los servidores de SharePoint (y dar ataques al corazón a los administradores de sistemas cuando les explicas que necesitas un Visual Studio en el servidor), usar autenticación implícita (tu código se ejecutará con los permisos del usuario actual) y que no es compatible de ninguna manera con SharePoint Online de Office 365.

Los servicios web SOAP

Evidentemente, alguien siempre ha tenido la necesidad de integrar SharePoint con otros sistemas (¿qué otros sistemas hay? diría algún SharePointero “de los de antes”). En los tiempos en los que nació SharePoint, eso significaba usar el lenguaje universal de la web: los servicios web SOAP (o ASMX, por la extensión del fichero ASP.NET en los que se programan).

SharePoint incluye una capa de servicios web SOAP, accesibles a cualquier plataforma que sepa hacer una llamada SOAP (y que pueda autenticar el usuario correctamente, claro está). Las operaciones que expone son bastante de bajo nivel, y con muchos parámetros obligatorios, y para muestra sólo hay que mirar la documentación de los estándares. Hablando en claro, son prehistóricas.

Hoy en día han quedado bastante en desuso ya que el modelo de REST API los hace casi obsoletos. Sin embargo, es posible que todavía haya cosas que se pueden hacer con los servicios web y con la API REST no, así que es posible (pero no probable) que tengas que recurrir a ellos.

En el siguiente post expondré las opciones modernas de desarrollo con SharePoint.

SharePoint Saturday Barcelona 2016

Después de organizar el primer SharePoint Saturday Barcelona el año pasado, y colaborar en la organización del SharePoint Saturday Madrid este año, los miembros de SUG.CAT volvemos a la carga con el segundo SharePoint Saturday en Barcelona. Se ve que esto de masoquismo organización de eventos nos va.

SPSBCN logo

Este año el SPS Barcelona se hará el sábado día 1 de octubre y volvemos a contar con Institut Químic de Sarrià para el espacio del evento.

¿Qué es un SharePoint Saturday?

Los SharePoint Saturday (o SPS) son eventos tipo conferencia, gratuitos y celebrados siempre en un sábado. Suelen tener varios “tracks” en paralelo y ponentes de gran nivel, con preferencia para los ponentes locales y personas destacadas en la comunidad que lo organiza.

SPSBCN 2015

¿Os he dicho que es totalmente gratuito? Hay conferencias de SharePoint con una agenda como la de SharePoint Saturday y que cobran entradas de 200-300 €.

¿Por qué debería asistir?

Depende de tu rol.

Si eres un técnico, administrador o desarrollador de SharePoint/Office 365 lo deberías tener claro: para aprender de otros compañeros, compartir historias e ideas y socializar.

Si eres un jefe de proyecto o de unidad de SharePoint, puedes ver lo que se ha hecho en otros sitios y coger ideas.

Si eres un usuario de SharePoint, principiante o avanzado, seguro que habrá sesiones en las que aprenderás que más se puede hacer. También tendrás un sitio donde preguntar tus dudas y aprender.

Si estás buscando gente de SharePoint/Office 365 para tu empresa o tu cliente, estás de suerte: todos los que te interesa van a estar allí.

¡No te lo pienses tanto y apúntate ya! Te esperamos el día 1 de octubre.

¿Qué hemos aprendido del año pasado?

La ventaja de haber pasado por el primer SharePoint Saturday el año pasado es que ya tenemos experiencia y sabemos que esperar. Este año hemos hecho una serie de mejoras:

  • Evitar que coincida con un partido del Barça o con un megapuente de vacaciones
  • Mejorar la logística para los sponsors
  • Reservar un espacio en la agenda para invitar a ponentes que no se suelen ver en eventos, para mejorar la representatividad y diversidad

Eso sí, seguro que este año volveremos a hacer algunas cosas mal (sin intención, claro), para mejorarlas el año que viene.

Más detalles sobre el evento

“Jotasón” y la (mala) pronunciación de términos informáticos

Los que me conocen saben que soy un poco Grammar Nazi. Lo reconozco, me gusta corregir la ortografía o la pronunciación en inglés cuando se trata de gente a la que aprecio, como amigos o compañeros. No hace falta añadir que no lo hago por fastidiar sino siempre con el afán de que mejoren su expresión oral en inglés, lo que abre muchísimas puertas en el mundo profesional y sobre todo en el de la informática.

A lo largo de los años he ido guardando mentalmente las pronunciaciones de palabras técnicas más frecuentes. Aquí os presento la lista, con la pronunciación aproximada mala y la buena.

(Agradecimientos a Robert Bermejo por ser el artífice de alguna palabra de la lista. Os recomiendo su blog por si tenéis algún interés en Azure)

Término Pronunciación incorrecta aproximada
Pronunciación correcta aproximada con enlace al audio
SharePoint chárpoin
charpóin
sarepóin
sárapoint
serpóin
shérpoint
(share + point)
feature fítur
fiture
feature
fícher
premises premáises prémises
event receiver event risáiver ivén risíver
Azure éishur áshur
Source surs sors
Xamarin shámarin
chámarin
sámarin
JSON jotasón
jasón
yéison
(como el protagonista del Viernes 13)
Bootstrap botestrap bútstrap
XAML chámel sáml
Microsoft Microsof Máicrosof
Git “yit” (como George) guit
LINQ línquiu link

Ya puestos, pongo también como se pronuncia mi nombre: Édin (con la “i” un poco más larga de lo normal) y no Edín.

¿Tenéis algunos ejemplos de vuestra propia experiencia?

Creative Uses of IDisposable

We all know IDisposable interface in NET Framework. It is used to signal to any object with dependencies to other objects when should it dispose of them. IDisposable is a very handy feature together with the using statement, when IDisposable is called automatically when we exit a using code block.

I was reading the Introduction to Rx by Lee Campbell, in preparation of my session for DotNetSpain conference in February. There, I’ve found some creative uses of IDisposable.

Basically, it leverages the fact that Dispose method is called after “using” statement code block exits. So, we can use it to do some wrapping around that code block.

Before the code in the block is executed, the IDisposable constructor will be invoked. After the code is executed, the Dispose method will be invoked. In effect, our code will be surrounded by “Pre” and “Post” actions in an elegant way.

In Campbell’s exemple, a console app can leverage IDisposable to print text in different color inside a code block.

The “wrapper” is a short class named ConsoleColor that implements IDisposable. It remembers the previous console foreground color by saving it in the constructor and restoring it in the Dispose method.

The calling code just decorates Console.WriteLine code blocks with custom ConsoleColor instances, and voilà, we have a multi-color console application.

2016-01-30_13-31-52

SharePoint 2016 y las expectativas

Como ya muchos sabéis, SharePoint 2016 IT Preview está disponible para descarga desde ayer, 24 de agosto de 2015. Con ello, han empezado a proliferar posts sobre la instalación, las mejoras y en general lo que se espera de SharePoint 2016.

Mi post no pretende repetir nada de esto, sino a aclarar lo que pretende conseguir Microsoft con esta versión beta IT Preview. Sólo ha pasado un día y ya he oído comentarios como “vaya SharePoint 2016, que pobre de funcionalidades que viene” o “si está clavado al 2013, si lo se no me lo instalo”, que van muy desencaminados.

SharePoint 2016 Preview Tilt

Si Windows 8 y Windows 10 han mostrado algo, es que Microsoft ha cambiado su estrategia de “betas” de software.

Antes, uno tenía que esperar hasta la Beta 1 para ver algo del nuevo software, pero ese software internamente ya estaba bastante maduro y lo que buscaba la beta es detectar las cosas . La Beta 2 y la Release Candidate o Technical Refresh (o cualquier otro nombre comercial bonito) servían para refinar esos errores minoritarios que siempre hay.

Ahora, la idea es que tengamos la beta Preview muy básica y mucho más “verde” pero mucho antes de lo que habitualmente se tenía. El objetivo es tener feedback real lo antes posible para ver como se comporta el nuevo producto en el “mundo real” y fuera de los laboratorios de Redmond. La primera Preview tosca muy pronto (en un par de meses) se sustituye por una Preview más refinada y así hasta la “beta final”: RTM. Con Windows 8 se siguió este patrón: primero la “Developer Preview” y luego la “Consumer Preview”, es decir los cambios más de back-end y la API primero y luego la interfaz de usuario y el pulido final. Con Windows 10 lo mismo: Preview con un ciclo más lento de cara al usuario final y otro más rápido (Fast Track) de cara al desarrollador/administrador.

Entonces, lo que tenemos entre manos es un SharePoint 2016 en el que la API y el back-end han sido cambiados por dentro de manera muy exhaustiva, pero donde la interfaz de usuario y la cara pública de la API es prácticamente la misma que en SharePoint 2013. De allí el nombre de SharePoint 2016 “IT Preview”. Con ello Microsoft pretende, en mi opinión, validar los cambios tan críticos como los MinRoles, búsqueda híbrida y los nuevos límites de escalabilidad.

Entonces, en una “IT Preview” es normal que no se vean grandes mejoras “a simple vista” ya que son más bien refactorings y reingeniería para poder habilitar esas grandes mejoras en los builds siguientes.

Yo esperaría una “Developer Preview” entre octubre y noviembre, y otra “Consumer Preview” en enero/febrero. La Developer Preview traería las mejoras de API de SharePoint cliente CSOM, el modelo de Apps y a saber que cosas más, con el objetivo de tener el feedback real de esos nuevos cambios para poder pulirlos lo antes posible. La Consumer Preview sería ya una fiel imagen del SharePoint 2016 tal como saldría acabado, con todas las mejoras de funcionalidad ya de cara al usuario y al administrador de sitios de SharePoint.

Entonces…paciencia, “pequeños saltamontes”. Esta IT Preview es sólo la punta del iceberg de las mejoras de SharePoint 2016.

Detect Popup Window Closing in Lightswitch

My last adventure with Lightswitch was trying to detect when a popup window inside a screen is closed.

You can close a Lightswitch popup window by clicking or tapping outside the popup. The jQuery Mobile popup widget that Lightswitch uses then closes the popup. However, I wanted to intercept that event and do some housekeeping such as discarding the changes made by the popup.

jquery mobile popup

The difficult thing was finding out where to put the event hookup code. Then, it was just a question of using jQuery Mobile Widget afterclose event that is triggered when a popup is closed.

The right event to listen for in my case was the rendering of the popup content. In the Lightswitch designer add a postRender event handler and associate the afterclose event of the parent object (the popup itself):

Lightswitch Deep Linking and Navigation in SharePoint Dialog Frame

Another one of my strange adventures with Lightswitch has made me look deep inside the navigation framework that Lightswitch uses. I will explain the strange symptoms, the cause I found out and the solution that worked for me.

SYMPTOMS

I have a Lightswitch app connected to SharePoint data. I have several screens, one for each list that is managed from Lightswitch. I want to be able to navigate straight to the screen I want from SharePoint, or to deep-link the screen.

To do so, I made a custom Promoted Links list. I added to this list my LS app deep URLs, such as https://appurl/HTMLClient/default.htm?SPHostUrlaaa&SPAppUrl=bbb&SPChromeColor=ccc#/ScreenName/[unique_number]. The ScreenName parameter is different for each screen, obviously. I also configured each link to open in a SharePoint dialog window.

Strange things happened. While I could open the desired screen by clicking on the promoted link, it would start displaying “Error Loading Page” message and keep a /spinning circle icon alive as if it were waiting for a long-running operation, after every navigation to and back from another screen or popup in the app.

image

These symptoms would disappear if the links were opened without dialogs (in the same tab or another browser tab). They would also disappear if I switched to another screen inside the app using the Lightswitch navigation menu.

CAUSE

I first suspected any custom JS files I added to the application. However, it was not until I used Fiddler tool to investigate the requests my app was doing that I found the answer.

Lightswitch app are Single-Page Applications (SPA). They leverage jQuery Mobile framework for Lightswitch navigation and maintaining app state in the browser. jQuery Mobile has a custom navigation feature that overrides standard browser navigation stack to be able to use Back button to go to the previous screen. In a SPA, there is only one “physical” page (default.htm) and all the further requests are done using AJAX calls to the LS backend services.

Fiddler showed me that the error messages were caused by a 404 HTTP not found response to a unknown page that was something like this: /ScreenName/IsDlg=1.

By opening any URL inside a SharePoint dialog, SharePoint automatically adds IsDlg=1 to the URL. It is used by SharePoint to hide any extra chrome such as navigation and toolbar from being displayed inside a dialog. So, my original URL was now changed to as https://appurl/HTMLClient/default.htm?SPHostUrlaaa&SPAppUrl=bbb&SPChromeColor=ccc#/ScreenName/[unique_number]&IsDlg=1. I could now reproduce the error even without SharePoint dialog, just by adding an extra query string parameter to the LS deep link URL and pasting it in the browser address bar.

Well, jQuery Mobile powered Lightswitch navigation seems to break when trying to parse a screen ID that follows the # sign and then finds another query string parameter such as &IsDlg=1. I tried to move the IsDlg parameter to the left of the screen ID. It worked, and I saw that I had to fix the URL in order for the navigation to work.

SOLUTION

I first thought of rewriting the LS URL by adding a custom HTTP module or a IIS rewrite rules but it sounded too cumbersome. I had to find a simpler mechanism to achieve the opening of a specific LS screen in a SharePoint dialog frame.

Thanks to my colleague Sergio Gallego, I was able to find a solution. I made a copy of the default.html page in LS and called it screen.htm. I then changed the ready() event handler inside the page to check for a query string parameter called “s” (for screen). It would then pass the parameter value as a parameter to the LS msls._run() method. This method takes an optional string parameter that is then used to start the LS app and open the screen with that same name.

I had to rewrite my URLs to the following schema: as https://appurl/HTMLClient/screen.htm?SPHostUrlaaa&SPAppUrl=bbb&SPChromeColor=ccc&s=ScreenName.

Here is the full code of the ready() method in the screen.htm file.