El peaje en CSOM

Sí os digo que SharePoint 2013 con su modelo de Apps ha abierto un nuevo horizonte en el desarrollo de aplicaciones a medida sobre la plataforma, pensaréis que esto no es ninguna novedad, pues ya se han escrito miles de artículos y hay decenas de blogs que hablan sobre el modelo de Apps y cómo trabajan. 

Pero hay algo relacionado con este modelo que, en ocasiones, se pasa por alto de manera alarmante. Se trata del peaje a pagar cuando trabajamos con Apps que utilizan código en el lado cliente y acceden de SharePoint a través de client-side object model (CSOM).

El proyecto en el que estoy inmerso actualmente consiste en la construcción de un portal para un cliente que estima una volumetría de visitas diarias que asciende a miles de usuarios y millones de transacciones a realizar.

¿Os imagináis que puede pasar si por cada usuario que accede realizamos 12 llamadas, que toman una media de 0,5 segundos, a 12 listas a través del CSOM a SharePoint de manera síncrona y simultanea? Pues serían alrededor de 6 segundos por usuario.

Seguro que comenzáis a haceros una idea de la magnitud de la tragedia. Por tanto, para hacer viable el proyecto, debíamos optimizar el uso de los recursos del portal. ¿Cómo nos las hemos apañado para conseguirlo? Pues tal y como suelen resolverse la mayoría de problemas complejos en esta vida: con estrategia y siguiendo el principio de divide y vencerás.

A continuación os explico cuál ha sido nuestra estrategia:

• ClientContext Asíncrono!

El primer problema que abordamos fue el más obvio, hacer que las llamadas del SharePoint Client al servidor fuesen asíncronas, de esta manera se pueden abrir múltiples thread en el servidor sin necesidad de esperar a que acabe uno para iniciar otro.

• Una consulta para múltiples listas.

La segunda medida que adoptamos, consistió en la optimización de las llamadas a SharePoint, esto lo hicimos mediante el uso de dos conceptos data transfer object (dto) y item.

La idea consiste en que los dto se componen de múltiples ítem y estos item son los que almacenan la información necesaria para que el SharePoint Client pueda realizar las Query a SharePoint.

item

Dto

Para poder realizar la llamada a múltiples listas mediante una sola consulta, hemos creado un método genérico en el Repository de SharePoint de nuestra aplicación (dentro de la capa de acceso a datos). Este método genérico se invoca con un tipo <T> (donde <T> corresponde con el dto que se quiere recoger) y mediante reflection devuelve un objeto <T> con los elementos de SharePoint almacenados directamente en el List del dto que le corresponda.

• Caché.

La última medida que adoptamos fue la colocación de una caché de datos “inteligente”. Mediante el uso de dto la App principal del portal provisiona los datos, a la caché, que se prevén necesarios. Pasado cierto tiempo, la App refresca los datos de caché por si ha habido algún cambio en BBDD o SharePoint.

 

Como podéis observar, se trata de un método genérico, en el que <T> corresponde con el dto que se quiere recoger.

Espero que este artículo os arroje algo de luz para afrontar los problemas de rendimiento que pueden provocar las SharePoint App.

Descubre cómo desde SOGETI podemos ayudarte en el desarrollo de proyectos IT bajo tecnología Microsoft Sharepoint.

Más información: 

José González es ingeniero titulado por la Universidad Politécnica de Cataluña y arquitecto de soluciones con más de 10 años de experiencia en proyectos IT orientados a negocio, especializado en tecnologías Microsoft (.net, Dynamics Nav y SharePoint) y en la prestación de servicios de gestión en proyectos informáticos de diversa índole tecnológica y en diversos sectores e industrias. Actualmente trabaja como Arquitecto SharePoint en SOGETI.