Ventajas de la Cache de Objetos en SharePoint Server 2010

La cache de objeto cachea metadatos de objetos como SPList o SPWeb de forma tal que no sea necesario recuperar dicha información para cada petición de los usuarios.  Además la cache de objetos cachea los resultados obtenidos por el Content By Query Web Part de forma que tampoco sea necesaria recuperar todos los elementos por cada consulta realizada por cada usuario. Como cada usuario tendrá distintos niveles de permisos para cada ítems de listas podría ocurrir que la cache de objetos contenga una cantidad de limitada de resultados dependiendo de los permisos del usuario que realiza la consulta, por ello la configuración de la cache nos permite indicar un factor multiplicador sobre el número de resultados devueltos que pueden ser mostrados al usuarios de realiza la consulta esto permite que en la cache queden almacenas una cantidad de elementos mayor en caso de que un usuarios con mayor nivel de permisos realice la misma consulta.
Seguir leyendo

Mejora el rendimiento de tus aplicaciones SharePoint Server 2010. La OutPut Cache

El Output cace es una características de las aplicaciones ASP:NET y por lo tanto SharePoint Server 2010 también puede hacer uso de ella para mejorar el rendimiento de nuestras aplicaciones. La Output Cache permite almacenar en el servidor las páginas que el usuario solicita ya renderizadas de forma que el servidor utiliza menos recursos de CPU y evita realizar viajes al servidor de base de datos, esto mejora el rendimiento y la escalabilidad de las aplicaciones web que desarrollamos en SharePoint ya que además nuestra aplicación se ve menos afectada por el aumento de la cantidad de peticiones por parte de los usuarios. Todo esto a cambio del consumo de mayor cantidad de memoria y saber establecer una política de anulación de las paginas cacheadas.
Seguir leyendo

Planea mejor tu arquitectura, conoce como funciona la Cache en SharePoint Server 2010

SharePoint utiliza varias técnicas para realizar el cacheado de objetos y así reducir las idas y vueltas entre los servidores frontales y los servidores de base de datos.  En este primero artículo hablaremos sobre el BLOB Cache que es un sistema utilizado por SharePoint para almacenar en el servidor frontal una copia de datos u objetos que son requeridos por los usuarios y sus peticiones http y por lo tanto evitar los viajes de ida y vuelta hacia el servidor de base de datos evitando la latencia y consumo de recursos de red que esto implica.

El BLOB Cache funciona en cada uno de los servidores frontales de una granja de SharePoint y crea copias de recursos utilizados por las páginas web solicitadas como archivos CSS, JavaScript e imágenes de esta forma si estos archivos no existen en la cache SharePoint va por ellos al servidor de base de datos si los mismos se encuentra almacenados en bibliotecas pero una vez cacheados los objetos en las sucesivas peticiones de los usuarios estos objetos son servidos directamente desde el servidor frontal sin tener que realizar viajes al servidor de SQL Server.  Como dije antes esto ocurre siempre que los archivos (CSS, JavaScript, imágenes, archivos multimedia, etc) estén almacenados en una biblioteca sin embargo si los archivos están por ejemplo en la carpeta _layout estos puedes ser servidos directamente desde el servidor frontal, sin embargo desplegar los archivos en la carpeta _layout impide la actualización del contenido por parte de los usuarios y por otra parte hace necesario la actualización  en cada servidor frontal. Aquí podemos ver que siempre los activos que queramos desplegar no requieran de la actualización o aprobación del usuario deberíamos desplegarlos en por ejemplo el directorio _layout y así evitar leer de la base de datos.

Seguir leyendo

SPS 2010: Puntos en configuración de cuotas y bloqueos


Cuando configuramos las cuotas y bloqueos para las aplicaciones web desde la administración de central de SharePoint esta no solo nos permite limitar la máxima cantidad de almacenamiento que puede consumir la aplicación web, sino que además no permite configurar a través de un sistema de puntos la máxima cantidad de recursos que pueden consumir las soluciones  de espacio aislado. Si vamos a la administración central a la sección de Configurar cuotas y bloqueos veremos que por defecto las soluciones  de espacio  aislado están limitadas al consumo de 300 puntos, la gran duda surge en saber cómo funciona el sistema de puntos para poder indicar mejor la cantidad de puntos que deseamos asociar a la plantilla de cuota para limitar las soluciones de espacio aislado. Para determinar esto pego el texto que podemos encontrar en la msdn donde se nos explica que el sistema de puntos está basado en la monitorización  de 15 recursos  como por ejemplo la cantidad de excepciones no manejadas que se producen, la cantidad de ciclos de CPU, el porcentaje de tiempo del procesador etc.

Para cada uno de estos 15 recursos existe un umbral que se deberá alcanzar (medido en las unidades según correspondan al tipo de medición) para anotar un punto a la cantidad de recursos consumidos, así y según la tabla de abajo si se alcanzaran 50 excepciones no manejadas se sumaría un punto al total de puntos por día para esa aplicación web. Apoyándonos en esto podemos realizar un mejor análisis del límite que debemos configurar para las cuotas de bloqueos de nuestras aplicaciones web.
Seguir leyendo

Creación de rutas administradas en SPS 2010

Las rutas administradas en SharePoint Server 2010 nos permiten definir las rutas dentro de la URL de un sitio web que administrara SharePoint. Para hacernos mejor una idea una ruta administrada que viene por defecto en sharePoint es la ruta /sitios (/sites) esta aparece cada vez que queremos crear una colección de sitios. Así como esta definida la ruta /sitios podemos definir nuevas, para ello basta con ir en la administración central a Administrar aplicaciones web, seleccionar la aplicación web sobre la queremos crear la ruta administrada y seleccionar en la ribbon la opción Rutas Administradas.

Al agregar una nueva ruta como por ejemplo /rrhh podremos indicar el tipo que podrá ser Inclusión de caracteres comodín o Inclusión explicita, la diferencia entre las dos opciones radica en que con inclusión explicita no se podrán crear nuevas rutas por debajo de la que hemos definido por lo que solo se podrá crear una colección de sitios el la ruta definida, ejemplo miserver/rrhh pero no se permitirá miserver/rrhh/nuevaruta, lo contrario ocurre con el tipo de Inclusión de caracteres comodín. Veamos como luce esto al crear una colección de sitios.

Al crear una colección de sitios en una ruta de tipo Inclusión de caracteres comodín

Al crear una colección de sitios en una ruta de tipo Inclusión explicita

Lo más común es utilizar el  tipo Inclusión de caracteres comodín sobre todo si se ha habilitado la opción de creación de sitios sin intervención del administrador.

Como validar si un usuario de SharePoint pertenece a un grupo del directorio activo que está dentro de un grupo de SharePoint.


En algunos casos tendremos la necesidad de validar si un usuario que accede a una aplicación de SharePoint pertenece o no a un perfil en específico, esta tarea se vuelve más compleja cuando no agregamos a los perfiles de SharePoint usuarios directamente sino grupos del directorio activo lo cual es bastante común, pues con el método que dejo más abajo se puede validar si un usuario tiene un perfil en concreto ya sea que este otorgado directamente al incluirlo en un perfil en la aplicación o que pertenezca a un grupo de directorio activo que está incluido en algún perfil.


public bool UsuarioTienePermisos(string url, string nombregrupo, string NombreUsuario)
{
bool reachedMax = false;
bool TienePermisos= false;
SPSecurity.RunWithElevatedPrivileges(delegate
{
try
{
using (SPSite site = new SPSite(url))
{
using (SPWeb web = site.OpenWeb())
{
SPGroup grupo = site.RootWeb.SiteGroups[NombreUsuario];
foreach (SPUser usuario in grupo.Users)
{
if (!usuario.IsDomainGroup)
{
if (user.LoginName.ToUpper().Equals(NombreUsuario))
{

TienePermisos = true;
return;
}
}
else
{
if (IsUserInADGroup(web, usuario.LoginName,
NombreUsuario, out reachedMax))
{ TienePermisos = true;
return;
}
}
}
}
}
}
catch (Exception ex)
{
}
});
return TienePermisos ;
} private static bool ValidarUsuarioDirectoiroActivo(SPWeb web, string nombregrupo,
string nombreUsuario, out bool reachedMax)
{
SPPrincipalInfo[] principals =
SPUtility.GetPrincipalsInGroup(web, nombregrupo, 500, out reachedMax);

if (principals == null || principals.Length == 0)
{
return false;
}
else
{
foreach (SPPrincipalInfo principal in principals)
{

if (!principal.IsSharePointGroup && principal.PrincipalType
!= SPPrincipalType.SecurityGroup &&
principal.DisplayName.ToUpper() != “SYSTEM ACCOUNT”)
{
if (principal.LoginName.ToUpper() == nombreUsuario.ToUpper())
{
return true;
}
}
else if (principal.PrincipalType == SPPrincipalType.SecurityGroup)
{
if (ValidarUsuarioDirectoiroActivo(web, principal.LoginName, nombreUsuario, out reachedMax))
{
return true;
}
}
}
return false;
}
}
}

¿Cuál es tu modelo de negocios de SharePoint?

Una interesante presentación que nos guía hacia como generar un modelo de negocios basado en SharePoint, pero que en realidad se puede aplicar a la generación de cualquier modelo de negocios que se pretenda implementar a través de una solución tecnológica.

La herramienta que utilizan para crear el modelo de negocios la pueden descargar de aqui.

Visto originalmente en nothingbutsharepoint

Como crear un plan de mantenimiento para tus bases de datos usando SSIS o SSMS.

SQL Server nos permite crear un plan de mantenimiento de nuestras bases de datos de forma muy sencilla sin embargo es poco común que existan en la mayoría de los entornos sencillamente por desconocimiento técnicos de los administradores de sistemas o por no saber cómo nuestras bases de datos se ven afectadas a medida que se realizan operaciones sobre ella lo cual reduce el rendimiento y a su vez los tiempo de respuesta en operaciones CRUD y especialmente en las consultas. Una vez más, más allá de que el usuario tenga que esperar un segundo más en una consulta se trata de como la disminución del rendimiento de nuestras aplicaciones afecta de forma global el desempeño de nuestra aplicación, cuanto tiempo (horas o minutos laborables) nos hace perder y los costos económicos asociados a ello, cuanto espacio estamos ocupando de manera innecesaria en nuestros servidores y cuál sería el costo económico de perder parte de nuestros datos en caso de un fallo grave en nuestros discos.

Sea que tengas una aplicación SharePoint, Dynamic CRM, Dynamic NAV, un aplicación hecha a medida, etc. vas a necesitar de un plan de mantenimiento ya que todas estas aplicaciones se ven afectadas de la misma manera. De una manera muy resumida el problema está cuando empezamos a agregar y eliminar información a nuestra base de datos, esto produce que aumente el porcentaje de fragmentación de la base de datos y de los índices por lo que la ruta que consideraba el SQL server era la mejora para realizar determinada consulta ya no lo es, para ello SQL server se basa en plan de ejecución que en base a ciertas estadísticas le permiten saber cuál es la mejor forma de atacar un consulta, pero estas estadísticas si no se actualizan en base al estado actual de la base de datos van quedando obsoletas y mientras mas desfragmentación exista mas cuesta realizar operaciones de escritura.

Seguir leyendo

Retorno de la inversión en los proyectos software

Aunque parece obvio que antes de realizar cualquier inversión es necesario realizar un análisis de que tan fructífera pueda ser dicha inversión o si efectivamente nos traerá beneficio y no pérdidas cada vez es más común que las empresas (inclusive grandes empresas) compren software o inviertan en proyectos de software sin hacer un verdadero análisis de cuánto dinero les hará ganar dicha inversión o de cuanto les hará ahorrar, también resulta curioso que muchas empresas consultoras (casi todas) venden proyectos de software realizando propuesta que tampoco dejan claro cuál será el beneficio económico real de la empresa en caso de llevar el proyecto acabo.

Seguir leyendo

Mostrar el nombre del documento en lugar del título en las búsquedas de SharePoint

Por alguna razón, supongo que justificada, los ingenieros de Microsoft decidieron que al realizar una búsqueda en SharePoint el título del resultado para el caso de los documentos sea el Titulo del mismo el cual obtiene de la primera página del documento, obviamente en esto están involucrados varios condicionales a la hora de mostrar el título u otra propiedad de rastreo, pero al menos en los documentos de office es muy común que ocurra.

Un problema algo común es que se carguen documentos a una librería de SharePoint  con diferentes nombres  pero que por tener el mismo título en la portada SharePoint al realizar una búsqueda asuma que son duplicados y no aparezcan en los resultados de búsquedas al menos que seleccionamos la opción de ver duplicados. Por esta razón y otras más podría ser conveniente que SharePoint en los resultados de búsqueda nos devuelva como título el nombre del documento y no el título que ha interpretado de la información de la primera página.

Como hacemos esto:

Lo primero es ubicar la propiedad administrada isDocument y asegurarnos que está configurada para ser utilizada en ámbitos.

Seguir leyendo