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.

Para configurar la cache de objetos en nuestra aplicación de SharePoint es necesario ir a Acciones de Sitio>Configuración del sitio >Cache de objetos de la colección de sitios.

Aquí podremos indicar el tamaño máximo de la cache, las opciones de invalidación de la cache la cual puede estar basada en una cantidad de segundo después de la cual se invalidaran todos los objetos cacheados o la opción de comprobar cambios la cual invalida los objetos que sean modificados y por último el factor multiplicador, hay que tener en cuenta al indicar este últimos que mientras mayor sea mayo memoria consumirá en nuestro servidor, el mismo puede tener un valor entre 1 y 10 siendo su valor por defecto 3.

Con este último post hemos terminado esta serie de post sobre el uso de la cache en SharePoint Server 2010, con lo que hemos visto la importancia de hacer un uso correcto de la cache en sus diferentes variantes para optimizar el rendimiento y la velocidad de respuesta de nuestras aplicaciones.

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.

Las paginas cacheadas pueden ser anuladas de dos formas, una opción es el “Time to Live” la cual nos permite especificar un tiempo de vida de la página cacheada, una vez alcanzado este tiempo la página se descarta y cachea de nuevo en su próxima petición. La segunda opción que tenemos es el “Check for Change” que nos permite anular de la cache la página si existe algún cambio en la misma, por su puesto esta opción puede ser contraproducente en páginas que sobre las que se realizan cambios constantemente de aquí la importancia de saber escoger un equilibrio entre rendimiento y mostrar el contenido actualizado.

Configuración de la Output cache en SharePoint

Para configurar la output cache en nuestra aplicación de SharePoint es necesario ir a Acciones de Sitio>Configuración del sitio >Cache de resultados de la colección de sitios.

Aquí podemos habilitar el Output chache (traducido como cache de resultados)

Además podemos indicar que configuración (Perfiles) de la cache de resultados queremos utilizar para el acceso anónimo y para el acceso de usuarios autentificados.

También podremos  indicar si habilitamos la utilización de perfiles diferentes para cada sitio de publicación y algo muy útil si habilitamos la utilización de perfiles diferentes para diferentes layout de páginas (diseños de página) de esta forma para cada layout podríamos tener distintas configuración de utilización de la cache.

Por defecto vienen 4 perfiles incorporados (Deshabilitado, Internet Público, Extranet,Intranet), para ver los perfiles y configurar nuevos tendremos que ir a  Acciones de Sitio>Configuración del sitio > Perfiles de cache de la colección de sitios.

Entre las opciones que podemos configurar veremos la Duración que permite indicar el tiempo del “Time to Live”, el Buscar Cambios que permite habilitar el “Check for Change”  y además las opciones Varia por que nos permite anular de la cache la página cuando cambien un parámetro de encabezado http, los derechos del usuario que hace la petición, o la variación de los parámetros personalizados (Por ejemplo el navegador utilizando la palabra Browser).

Es importante tomar en cuanto que la opción Varia por produce una nueva copia de la página en la cache del servidor pudiendo tener varias versiones de la misma página cacheada, así por ejemplo si especificáramos en la opción Variar por parámetro personalizado “Browser” tendríamos una versión de la página por cada navegador diferente que hiciera una petición de la página, esto puede significar un alto consumo de memoria si tomamos en cuenta todas la cantidad de cruces disponibles entre las opciones Varia por donde por cada combinación se estará creando un versión de la página que durara hasta que se alcance el tiempo definido en el TTL.

Configuración del Output Cache en layouts

Para configurar la output cache en nuestros diseños de página es necesario ir a Acciones de Sitio>Configuración del sitio >Paginas Maestras y diseños de página. Una vez en la galería solo es necesario ubicar nuestro diseño de página y editar sus propiedades donde podremos elegir los perfiles que queremos utilizar tanto para los usuarios anónimos como para los usuarios autentificados.

Finalmente algunas consideraciones acerca del Output cache:

-El contenido con posibilidad de acceso anónimo es cacheado mucho más rápido debido a que no es necesario que el servidor frontal realice peticiones a la base de datos para validar los permisos de la página.

-Funciona solo para las páginas de publicación.

-Puede ser configurada por colección de sitios, sitio y page layout

-Cada versión de página cacheada ocupa 2* (Peso de la página en Kb)+ 32 Kb

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.

Una desventaja del BLOB Cache es que la primera vez que un contenido necesita ser buscado en el servidor de base de datos para cachearlo esta ida y vuelta al servidor tardara mucho más (alrededor de 5 veces más) de lo que tardaría sino estuviera habilitado el BLOB Cache, esto se debe a que esta primera vez SharePoint necesita obtener toda la información referida a la seguridad del objeto que va a cachear y así controlar el acceso al mismo.  Por esta razón no es buena idea utilizar BLOB Cache sobre objetos que se actualicen con demasiada frecuencia ya que terminaría siendo bastante contraproducente a nivel de rendimiento.

Veamos algunos detalles en cuanto al BLOB Cache:

• Los archivos se guardan en disco pero SharePoint mantienen en RAM un índice a los archivos cacheados
• El BLOB Cache se puede configurar para tipos de archivos en concreto
• El BLOB Cache se configura para cada aplicación web
• Por defecto el servidor frontal revisa cada 5 minutos si existe algún cambio en los archivos cacheados, si existen cambios descarta los archivos y los cachea en la próxima petición.
• En algunos casos la devolución de archivos más pequeños podría tardar más que la de archivos de mayor tamaño debido a que para archivos grandes SharePoint empieza a devolver el contenido a medida que va leyendo del servidor SQL Server, esto es muy útil en el consumo de videos, sin embargo no hace los mismo para archivos pequeños.
• Se usan 800 bytes de RAM por objeto cacheado, importante a considerar para que nuestra aplicación escale eficientemente.
• Se puede evitar la tardanza de la primero consulta al servidor  SQL Server configurando la biblioteca con la propiedad AllowEveryoneViewItems igual a True. Las carpetas Images y Site Collection Images ya vienen configuradas de esta manera de esta forma el servidor frontal no necesita obtener toda la información referente a la seguridad de los objetos ya que son visibles para todos los usuarios.

Por defecto el BLOB Cache viene deshabilitado pero se puede habilitar a través del web config incluyendo:

<BlobCache location="<location>" path="<files to be cached>" maxSize="10" enabled="true" />

Ejemplo:

<BlobCache location="C:\BlobCache\14" path="\.(gif|jpg|jpeg|jpe|jfif|bmp|dib|tif|tiff|ico|png|wdp|hdp|css|js|asf|avi|flv|m4v|mov|mp3|mp4|mpeg|mpg|rm|rmvb|wma|wmv)$" maxSize="10" enabled="true" />

Para borrar la cache podemos ejecutar el siguiente comando de PowerShell

$webApp = Get-SPWebApplication "<http://your web application url>"

[Microsoft.SharePoint.Publishing.PublishingCache]::FlushBlobCache($webApp)

Por ultimo dejo algunos enlaces a la msdn donde pueden obtener mayor información sobre la configuración y arquitectura de la BLOB Cache.

 Plan for caching and performance (SharePoint Server 2010)

Almacenamiento en memoria caché basada en disco de objetos binarios grandes

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.

En la siguiente tabla se enumeran los 15 recursos del sistema que se supervisan.

• La columna Umbral mínimo especifica la cantidad mínima predeterminada del recurso que se debe alcanzar antes de que se agregue al total acumulado. En esta columna, 0 significa que se agrega cualquier cantidad, por pequeña que sea.
• La columna Límite absoluto especifica la cantidad predeterminada que activará una terminación inmediata del proceso. Tenga en cuenta que hay un 1 en esta columna para algunos recursos. Esto significa que incluso una única instancia del recurso desencadena una terminación inmediata del proceso.
• La columna Recursos por punto especifica, de forma predeterminada, la cantidad del recurso que hará que se sume un punto adicional al total de Por día o por colección de sitios.

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.

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;
}
}
}

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

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.

Con un poco de análisis de nuestras necesidades podemos llevar a cabo un plan de mantenimiento en pocos minutos. Veamos cómo hacerlo en SSMS.

En SQL Server Managment Studio  podremos ver la carpeta Managment y dentro de ella Maintenance Plans, para usar el ayudante seleccionamos Maintenance Plans Wizard

Hacemos clic en Next

Le damos un nombre a nuestro plan de mantenimiento ya que podremos crear tantos como queramos para distintas base de datos o conjunto de ellas.

Escogemos las tareas de mantenimiento que queremos realizar.

Shrink Database: reduce espacio de la base de datos y los archivos de log.

Update Statistic: asegura que el optimizador de consultas tiene la información actualizada acerca de la distribución de los datos en la base de datos, esto permite que el optimizador realice mejores cálculos acerca de cómo realizar alguna consulta.

Reorganized Index: desfragmenta y comprime los índices físicos (Clustered Index) y no físicos.

Rebuild Index: reconstruye las paginas índices permitiendo la reorganización de los datos y búsquedas más rápidas.

Check Database Integrity: confirma la integridad de los datos y índices de la base de datos.

History Cleanup: elimina información histórica sobre copias de respaldos y restauraciones.

Maintenance Cleanup: elimina archivos dejados por la ejecución de los planes de mantenimiento.

Escogemos el orden en que se ejecutan las tareas.

Para cada tarea se nos pedira que escojamos la base de datos, podemos escoger una, varias o todas.

Para cada tarea sera necesario escoger las opciones que correspondan.

Después de configurar todas las tareas se creara el plan de ejecucion.

Podremos ver en el diseñador el plan de mantenimiento que hemos creado.

En la parte superior del diseñador en el icono con forma de calendario podemos configurar la programación de un nuestro plan de mantenimiento.

Finalmente lo mismo que hemos realizado con el SSMS lo podemos realizar con SQL Server Integration Services y el SQL Server Business Intelligence  Development Studio.

Cuando creemos un proyecto podremos ver que en las herramientas tenemos una sección dedicada a tareas del plan de mantenimiento. Solo es necesario arrastrar las tareas que queremos ejecutar.

Si hace clic derecho> Editar sobre cualquier tarea la podemos configura exactamente igual como lo hacíamos con SSMS.

Con esto generaremos un paquete de SSIS que podremos ejecutar cada vez que queramos.

Como hemos visto crear un plan de mantenimiento es relativamente sencillo, obviamente cada escenario necesitara de realizar una análisis de cuáles son nuestras necesidades y como puede impactar el plan de mantenimiento a nuestra aplicación sobre todo si estamos hablamos de producto out of the box.

Más información en la MSDN

En este blog ya hemos tratado como mejorar el rendimiento de SQL Server en los siguientes post:

Cuellos de botella en SqlServer

Mantener las estadísticas actualizadas en Sql Server.

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.

Ahora bien más allá de la incompetencia de algunos jefes de finanzas y tecnológicos de muchas empresas, cualquier inversión grande en proyectos de software debe estar respaldada por el desarrollo de un modelo del retorno de la inversión que justifique el proyecto. Para esto lo primero que hay que hacer es determinar el beneficio que recibiremos por llevar a cabo nuestro proyecto.
En el caso de los proyectos de software los beneficios pueden están enmarcados en las siguientes categorías:

Reducir costos laborales: sencillamente si podemos hacer lo mismo con menos personas podemos reducir costos de manera directa o reubicar a dichas personas en otras áreas donde puedan generar valor.
Reducir errores: los errores generalmente tienen un coste económico, reduciendo los errores minimizamos este coste y además reducimos gastos en realizar test de calidad o revisar que el trabajo realizado cumpla con ciertas características.
Incrementar las ganancias: un proyecto por ejemplo nos podría ayudar a vender más, posicionar mejor nuestra marca o tener mayor visibilidad. Un claro ejemplo es la implementación de un CRM con Microsoft Dynamic o una extranet para crear vínculos con nuestros clientes.
Mejorar el acceso a la información: es bien sabido que la información es la base para la toma de decisiones, contar con la información necesaria y el momento preciso puede ayudar a los directivos de una empresa a tomar decisiones que ayuden generar mayores ingresos o a reducir cotos. En un mundo donde la información se genera cada segundo y se va transformando en corto tiempo es necesario estar informado de cómo va tu negocio, aquí entran en juego muchas aplicaciones de inteligencia de negocios (SQL Analysis services, SharePoint performance point service, Power Pivot, etc)
Incrementar la productividad: si podemos realizar lo mismo con menos esfuerzo estamos siendo más productivos, esto casi siempre va atado a ahorro de dinero. Por ejemplo cuando tardan los empleados de una empresa al día buscando información necesaria para llevar a cabo su trabajo, ¿En cuanto podríamos reducir este tiempo implementando un portal de búsquedas corporativas con SharePoint y cuantos ahorraríamos al año?

Ahora bien hasta ahora solo hemos hablado de los beneficios pero cualquier proyecto trae consigo costos asociados al mismo, a parte del costo inicial del proyecto en sí, entre ellos tenemos:
Costo de licencias: es importante que sepamos gestionar el costo de las licencias basándonos en un arquitectura de software y hardware bien definida y las posibilidades de crecimiento de la aplicación.
Costos de mantenimiento: cualquier proyecto de software necesitara personas que sean capaces de mantener la aplicación tanto a nivel de software como a nivel de infraestructura, personas que administren los distintos servidores , resuelvan incidencias, etc. Es necesario tener en cuanto nos va a costar mantener nuestros aplicativos según la tecnología que escojamos también encontraremos distintos precios para personal de soporte, es bien sabido que es mucho más rentable contratar a un experto en Windows Server 2008 que a un experto en Red Hat.
Hardware: muchas veces se lleva gran parte de los costos, pero recordemos que siempre podemos reducir la cantidad de equipos físicos implantando tecnologías de virtualización, en los costos de hardware están involucrados la compra de servidores, equipos de red, etc.

Modelo de ROI

Una vez hayamos identificado los beneficios económicos que traería la implementación de un nuevo software y el costo de llevarlo a cabo y sus costos asociados debemos desarrollar nuestro modelo de ROI para cual debemos de tener en cuenta lo siguiente:
La vida útil del software: una aplicación es evidente que no nos puede durar para siempre, aunque muchos jefes de finanzas quisiera que fuera así, pasada una cierta cantidad de años puede ser que la tecnología tienda a volverse obsoleta o que las necesidades de la compañía hayan cambiado, de todas formas la vida útil de un software suele estar entre los 5 y los 8 años. Es esencial que sepamos cual será la vida útil del aplicativo que queremos desarrollar porque para cada año de vida tendremos que calcular los beneficios (Cash in)y los gastos que nos generara (Cash out).
Depreciación: al igual que casi cualquier cosa el software suele ir perdiendo valor a medida que pasa el tiempo.
Risk-free interest rate: es la tasa que se podría obtener anualmente del dinero que se pretende invertir si se pusiera en un banco o en otras inversiones con cero riesgo, si el % de retorno de nuestra inversión no está por encima de esta tasa obviamente no vale la pena llevar a cabo el proyecto.
Cualificación de riesgo: se refiere a las probabilidades de conseguir los beneficios que se han planteado en el modelo.

Ejemplo de un modelo ROI

Esto significa que hemos convertido 100 mil en 120 mil lo cual sería el valor presente de nuestra inversión (PV) y el valor presente neto seria 20 mil (NPV).
Esto monto no es del todo real ya que en necesario aplicar el discount rate el cual estará basado en Risk-free rate y el porcentaje de riego del proyecto. Generalmente el discount rate es fijado por los departamentos financieros de las empresas.

Para aplicar el discount rate a nuestro NPV antes calculado y obtener un valor más realista hay que aplicar la siguiente formula.

Seguramente el cálculo del ROI podemos hacerlo tan complejo como queramos pero lo que no deberíamos es dejarlo a un lado tanto si queremos plantearnos llevar a cabo un proyecto de software como si estamos interesados en presentar una propuesta tecnología a algún cliente. Además si tenemos claros las ganancias que supondrán el terminar a cabo el proyecto todas las partes interesadas estarán más involucradas en el éxito del mismo.

Si quieren ampliar sus conocimientos en esta área una buena forma de empezar es a través del Microsoft REJ Framework un marco de trabajo permite evaluar a las organizaciones el valor de las inversiones que pretenden realizar en el área de IT.

Fuentes:

Microsoft

cleverworkarounds

REJ

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.

Luego tenemos que hacer algunos ligeros cambios en el xsl que formatea los resultados de las búsquedas, ya hablamos de cómo hacer esto en un antiguo post.

 Para este caso en el xsl vamos hasta donde dice:

<div class=”srch-Title2″>>

  <div class=”srch-Title3″>

A partir de aquí se empieza a dar formato al título del resultado de búsqueda.

Ahora debemos sutituir:

<xsl:choose>

                                  <xsl:when test=”hithighlightedproperties/HHTitle[. != '']“>

                                        <xsl:call-template name=”HitHighlighting”>

                                               <xsl:with-param name=”hh” select=”hithighlightedproperties/HHTitle” />

                                        </xsl:call-template>

                                  </xsl:when>

                                  <xsl:otherwise>

                                        <xsl:value-of select=”title”/>

                                  </xsl:otherwise>

                           </xsl:choose>

Por:

<xsl:if test=”isdocument = ‘True’”>

                           <xsl:value-of select=”filename”/>

                    </xsl:if>

                    <xsl:if test=”isdocument = ‘False’”>

                           <xsl:choose>

                                  <xsl:when test=”hithighlightedproperties/HHTitle[. != '']“>

                                        <xsl:call-template name=”HitHighlighting”>

                                               <xsl:with-param name=”hh” select=”hithighlightedproperties/HHTitle” />

                                        </xsl:call-template>

                                  </xsl:when>

                                  <xsl:otherwise>

                                        <xsl:value-of select=”title”/>

                                  </xsl:otherwise>

                           </xsl:choose>

                    </xsl:if>

En resumen comprobamos si el resultado es un documento, si es así hacemos que muestre el nombre (FileName) de lo contrario se comporta como hasta ahora lo ha venido haciendo mostrando la propiedad administrada title.