Agregar/Actualizar un campo Date mediante client object

Supongamos que tenemos una variable llamada submital que es de tipo Date Time. La parte en amarillo es la parte más importanet. Convertitmos la fecha en un formato ISO8601

using (ClientContext clientContext = new ClientContext(urlSharepointList))
{
    clientContext.AuthenticationMode = ClientAuthenticationMode.Default;
    Microsoft.SharePoint.Client.List list = clientContext.Web.Lists.GetByTitle("CRM");
    DateTime NewSubmittal = new DateTime();
    ListItemCreationInformation itemCreateInfo = new ListItemCreationInformation();
    ListItem newItem = list.AddItem(itemCreateInfo);
    newItem["Title"] = opportunity.Name;
   newItem["Submital"] = string.Format("{0:0000}-{1:00}-{2:00}T{3:00}:{4:00}:{5:00}Z",
                                        NewSubmittal.Year,
                                        NewSubmittal.Month,
                                        NewSubmittal.Day,
                                        NewSubmittal.Hour,
                                        NewSubmittal.Minute,
                                        NewSubmittal.Second);   
   
    newItem.Update();
    clientContext.ExecuteQuery();

}

Más post relacionados a ISO8601: http://todosharepoint.blogspot.com.ar/search/label/ISO%208601

The request uses too many resources–CSOM

Al tratar de insertar un item en una lista de Sharepoint 2013, me lanzaba el error: The request uses too many resources

{Microsoft.SharePoint.Client.ServerException: The request uses too many resources.
   at Microsoft.SharePoint.Client.ClientRequest.ProcessResponseStream(Stream responseStream)
   at Microsoft.SharePoint.Client.ClientRequest.ProcessResponse()
   at Microsoft.SharePoint.Client.ClientRequest.ExecuteQueryToServer(ChunkStringBuilder sb)
   at Microsoft.SharePoint.Client.ClientRequest.ExecuteQuery()
   at Microsoft.SharePoint.Client.ClientRuntimeContext.ExecuteQuery()
   at Microsoft.SharePoint.Client.ClientContext.ExecuteQuery()

hrresult --> –2146233088

Esto se debe a que Sharepoint setea el número máximo de object-paths que pueden ser usados en un request a 256. Un “Object-Path” trackea cómo un objeto cliente es creado en la clase “ClientRuntimeContext”, de esta manera el objeto puede crearse en el server. Cada SP-Object (por ejemplo un site) genera un object-path-object en el request. Es decir, en palabras simples setea un límite de 256 objetos en una llamada ExecuteQueryAsync.

Para solucionarlo, puedo hacer dos cosas: reducir los object-paths en el request, por ejemplo dividiendo la consulta en consultas más pequeñas o cambiando la propiedad maxObjectPaths.

$webApp = Get-SPWebApplication "htt://ur_webapplication"
$webApp.ClientCallableSettings.MaxObjectPaths = 5000
$webApp.Update()

Tip: 5 causas de performance lenta

• Navegación estructural: por ejemplo si tienes varios sub-sitios (deep navigation), y deseas mostrarlos todos en el menú superior. Es este caso puedes utilizar Managed Navigation para mejorar la performance. Más info en el siguiente link

• Content Rollup: en general son queries muy costosas. Ej: recorrer cada sitio, cada listas y renderizar algo de contenido.

 

• Archivos grandes: Ej: tener imágenes grandes o videos, archivos .js gigantes.
• Tener muchos request: .js, .css e imágenes.
• Tener muchos web parts en la página:

Simple tip para verificar la performance de nuestro servidor: response headers de la solicitud de una página

Cuando realizamos una solicitud a Sharepoint de una página, en el header de la solicitud de HTTP podemos ver varios datos útiles relacionados a la performance de la plataforma.

Para verificarlas podemos usar las herramientas de desarrollo de IE, fiddler u otra herramienta similar (HTTPWatch). En el IE presionamos F12, y elegimos la sección de Network, y presionamos Play.

Realizamos un refresh de la página, y en la solicitud principal, hacemos doble click sobre la misma.

En los headers de la respuesta tenemos, algunas claves útiles, tales como:

SPRequestDuration: tiene un valor de 2805 milisegundos, lo cual quiere decir que Sharepoint tardo ese tiempo para procesar la solicitud (página) del lado del servidor.  Este header está en cada página de Sharepoint. Tiempos excesivos indican que se hizo mucho trabajo para renderizar la página o el servidor está unhealthy (en español sería “poco sano”). Para verificar si el servidor está unhealthy, Sharepoint también otra header para verificar, “X-SharepointHealthScore”, este tiene un valor entre 0 y 10. 10 es cuando está unhealthy (algún problema) o está sobrecargado (high load y throttling request para mantener ell throughput). Más info en el siguiente link

Si este header tiene 0 y tienes alta latencia en el SPRequestDuration, claramente Sharepoint está haciendo mucho trabajo para renderizar la página.

SPIisLatency: es el queue time de la solicitud. Cuando un servidor está sobrecargado, empieza a “encolar” las solicitudes.

Variable de configuración del workflow de aprobación: “CancelonRejection”

La variable “CancelonRejection” define si se cancela el workflow en el PRIMER RECHAZO de una tarea de un workflow.

En un workflow Out the Box, esta configuración se puede hacer desde el mismo UI

En cambio cuando se hace un workflow custom con Sharepoint Designer, se tiene que setear la variable mediante la action “Set Variable”

Si se revisa la conducta de una tarea en el workflow, encontrarán que al completar una tarea, hay un pequeño IF

Cancelation es igual a Yes, se finaliza el proceso de tareas.