En muchas ocasiones me he preguntado si existe alguna forma de saber si una página esta en modo de edición o no, para personalizar el contenido que se muestra en cada uno de los modos. Navegando por internet, he encontrado como se hace, y la verdad es que es bastante simple, cuando se conoce.
Se puede utilizar desde una página o control de usuario en aspx, de modo que todo lo que esté dentro de la etiqueta sólo se mostrará si esta en el modo que se especifica en la propiedad.
<PublishingWebControls:EditModePanel runat=server id="idEditPanel" PageDisplayMode="Display">
<!- - Controles definidos en esta zona se muestran en modo visualización - ->
</PublishingWebControls:EditModePanel>
<PublishingWebControls:EditModePanel runat=server id="idEditPanel1" PageDisplayMode="Edit">
<!- - Controles definidos en esta zona se muestran en modo edición- ->
</PublishingWebControls:EditModePanel>
Si se necesita realizar la comprobación mediante código fuente:
if( SPContext.Current.FormContext.FormMode == SPControlMode.Edit)
Cabe destacar que en el caso de los webparts, será necesarios utilizar la propiedad de WebPartManager.DisplayMode
Dejo unos enlaces para ampliar la información.
WebPartManager.DisplayMode Property
SPControlMode Enumeration
Comparto con vosotros esta información acerca de las bases de datos que se crean y llenan de datos con nuestros fantásticos sitios de SharePoint, pero que nunca se por donde cogerlas…
Me apunto estos enlaces en el blog, para encontrarlos luego fácilmente…
Os dejo unos enlaces que pueden ser de utilidad:
Tablas de la Base de Datos de Contenido
Tablas de la Base de Datos de Configuración
Tablas de la Base de Datos
Procedimientos almacenados
Durante estos días he probado cuantos web parts se pueden añadir a una página de elementos web en SharePoint 2007, para ver si conseguía aclarar cuál es la diferencia entre cerrar (“X” en la esquina superior derecha del webpart) y eliminar un webpart de la página, dado que a efectos visuales para el usuario es el mismo…
Las pruebas las he realizado con web parts del tipo “Content Editor Web Part” añadiendo contenido a los mismos, en algunos casos, más contenido que en otros, pero todos ellos con contenido. Las recomendaciones del TechNet, indican que el número máximo recomendado de web parts por página no debe exceder 50 para no tener bajadas de rendimiento. Este número es una recomendación, ¿pero es real? Y, ¿qué indica? Tras realizar las pruebas pertinentes, comprobé que no se pueden añadir más de 50 webparts en una página mediante la interfaz gráfica, desde código podrían añadirse más pero provoca un error a la hora de visualización de la página.
De modo si no se pueden tener insertar más de 50, ¿por qué recomiendan no tener más de 50? La respuesta es sencilla, como todo en SharePoint tiene truco. No se pueden tener abiertos más de 50 webparts, pero no se cuentan los que están cerrados en la página que no se renderizan. Por tanto el principal problema que ocasionan estos Webparts cerrados es que se el contenido se sigue descargando de la base de datos, de modo que se realizan más peticiones de las necesarias, y el tiempo de carga aumenta notablemente, independientemente del número de Webparts que estén abiertos en la página. Si eliminamos los Webparts que ya no se utilizan en una página en lugar de dar al aspa “X” evitaremos que los Webparts que no se utilizan se carguen innecesariamente en nuestra página, mejorando el rendimiento de la misma.
Para comprobar los elementos web que tenemos añadidos a una página sólo tenemos que añadir “?contents=1″ en el querystring después del nombre de nuestra página (http://servidor/default.aspx?contents=1), de esta forma se puede acceder de forma rápida a la página de mantenimiento de elementos web, mediante la cual podremos eliminar los Webparts cerrados, entre otras opciones.
Debido al modelo de seguridad de MOSS/WSS y a las personalizaciones que se realizan mediante el desarrollo de nuevos webparts, interfaces,.. podemos necesitar realizar operaciones que el usuario final no tiene permisos para realizar, por ejemplo, acceder al perfil de un usuario, agregar elementos a listas con un usuario lector, que cualquier usuario pueda activar features desde un webpart… (aunque en la mayoría de los casos, suele tratarse de operaciones más complejas).
Esta tarea, era más compleja en SharePoint 2003, pero ahora gracias al nuevo modelo de objetos y los métodos que ofrecen, podemos realizar una impersonación mediante la cual podremos ejecutar código que realice acciones para las cuales el usuario actual no tiene permisos. El modelo de objetos proporciona dos formas de realizar esta tarea:
· Utilizando la cuenta del sistema: ejecutaremos el código con los permisos que tiene la cuenta del sistema en el sitio (FullMask), de modo que podremos realizar todas las acciones.
· Utilizando los datos de otro usuario: ejecutaremos el código con los permisos que tiene la cuenta del usuario utilizado en el sitio.
A continuación veremos que se realiza esta tarea y algunos aspectos a tener en cuenta.
En el primer caso, impersonar utilizando la cuenta del sistema, vamos a crear un nuevo elemento de una lista con un usuario lector. Para realizar la impersonación utilizamos el método RunWithElevatedPrivileges de la clase estática SPSecurity.
SPSecurity.RunWithElevatedPrivileges(delegate()
{
using (SPSite miSitio = new SPSite(&quot;http://urlServidor&quot;))
{
miSitio.AllowUnsafeUpdates = true;
using (SPWeb miWeb = miSitio.OpenWeb())
{
miWeb.AllowUnsafeUpdates = true;
SPList miLista = miWeb.Lists[&quot;Pruebas&quot;];
SPListItem elemento = miLista.Items.Add();
elemento[&quot;Title&quot;] = &quot;PRUEBA CON USUARIO LECTOR&quot;;
elemento.Update();
miweb.AllowUnsafeUpdates = false;
}
miSitio.AllowUnsafeUpdates = false;
}
});
En el caso de querer utilizar otro usuario, se puede realizar la impersonación de forma similar:
SPUser miUsuario = SPContext.Current.Web.AllUsers[&quot;miDominio\\ccanov&quot;];
SPSite sitioImpersonado = new SPSite(&quot;http://urlServidor&quot;, miUsuario.UserToken);
SPWeb webImpersonada = sitioImpersonado.OpenWeb();
En ambos casos, si se obtiene el usuario llamando al método CurrentUser del objeto SPWeb impersonado, se obtendrá el usuario con el que se ha impersonado, siendo en el primer “SHAREPOINT\\SYSTEM” y en el segundo “miDominio\\ccanov”, mientras que si se realiza la llamada al objeto del contexto SPContext.Current.Web.CurrentUser, el usuario será el que está accediendo realmente a la página.
Hay que realizar siempre el Dispose de los objetos que se han utilizado para la impersonación, ya sea mediante el uso de using (primer ejemplo) o mediante el uso del método Dispose (segundo ejemplo).
En el caso de tener que realizar modificaciones, ya sea de listas, elementos de listas, páginas,… hay que poner la propiedad AllowUnsafeUpdates a true, antes de realizar la acción, y ponerla a false después, para esto, es recomendable hacer uso de finally e introducir todo el código dentro de un try-catch, para evitar que esta propiedad se quede con el valor a true.
Cuando se trabaja con definiciones de sitio en WSS/MOSS se tiende a pensar que únicamente nos proporcionan la base para la creación de sitios con una determinada estructura de listas/bibliotecas y elementos básicos de configuración.
En una próxima entrada comentare como crear una definición de sitio, y muchas de las features no documentadas por Microsoft, que permiten realizar la mayoría de las opciones que se muestran en la página de “Configuración de Sitio”. En esta entrada, veremos que utilizar las definiciones que proporciona microsoft, para crear una colección de sitios con subsitios en varios niveles, empleando únicamente los ficheros xml de configuración.
La estructura que crearemos será la siguiente:
Una vez tenemos clara la estructura que vamos a crear, únicamente necesitamos crear 2 ficheros xml:
webtempMySiteProvider.xml: (ubicado en 12/TEMPLATE/3082/XML) en este fichero, definiremos la definición de sitio que se va a emplear. No hay que crear una definición de sitio como tal, lo que pretendemos es que aparezca en la página de creación de sitios. A continuación se muestra el contenido del fichero:
<Templates xmlns:ows="Microsoft SharePoint">
<Template Name="MySiteProvider" ID="10900">
<Configuration ID="0" Title="Estrucutura desde xml" Hidden="FALSE" ImageUrl="/_layouts/images/stsprev.png" Description="Definicion que creaa toda la estructura de la coleccion de sitios" ProvisionAssembly="Microsoft.SharePoint.Publishing, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" ProvisionClass="Microsoft.SharePoint.Publishing.PortalProvisioningProvider" ProvisionData="xml\\estructura.xml" RootWebOnly="TRUE" DisplayCategory="MiTopologia" />
</Template>
</Templates>
Como se puede ver, aparentemente se trata de una definición de sitio básica, salvo por las propiedades:
- ProvissionAssembly: especifica que librería se utilizará para el aprovisionamiento del sitio.
- ProvissionClass: especifica que clase se utilizará para el aprovisionamiento del sitio.
- ProvisionData: especifica el fichero que proporciona los datos para el aprovisionamiento. En nuestro caso estructura.xml
estructura.xml: (ubicado en 12/TEMPLATE/3082/XML) en este fichero se especifica la estructura que hay que crear, utilizando el esquema PortalSchema.xsd. Mediante el uso de y especificaremos los sitios y subsitios que se van a crear. El fichero estructura.xml, con la estructura especificada en la imagen, quedaría de la siguiente forma:
<?xml version="1.0" encoding="utf-8" ?>
<portal xmlns="PortalTemplate.xsd">
<web name="Inicio" siteDefinition="CMSPUBLISHING#0" displayName="Inicio" description="Inicio" >
<webs>
<web name="sitio1" siteDefinition="STS#0" displayName="Sitio 1" description="Sitio 1"/>
<web name="sitio2" siteDefinition="MPS#0" displayName="Sitio 2" description="Sitio 2"/>
<web name="sitio3" siteDefinition="STS#1" displayName="Sitio 3" description="Sitio 3"/>
<webs>
<web name="blog" siteDefinition="BLOG#0" displayName="Blog" description="Blog"/>
<web name="wiki" siteDefinition="WIKI#0" displayName="Wiki" description="wiki"/>
</webs>
</web>
<web name="sitio4" siteDefinition="SRCHCEN#0" displayName="Sitio 4" description="Sitio 4"/>
<web name="sitio5" siteDefinition="SPSREPORTCENTER#0" displayName="Sitio 5" description="Sitio 5"/>
</webs>
</web>
</portal>
En el caso del ejemplo, se utilizan las definiciones de sitio que proporciona Microsoft, pero del mismo modo se puede utilizar con las definiciones que creemos, y de ésta forma, podremos crear la estructura que necesitemos empleando nuestras definiciones de sitio.
En algunas ocasiones, necesitamos generar un fichero (por ejemplo, zip con adjuntos de elementos de las listas, un pdf…) cuando se pulsa un botón. En mi caso, se trataba de obtener un fichero comprimido con los adjuntos de los elementos que se muestran como resultado de la búsqueda, para una única página. Realice múltiples pruebas y siempre funcionaba todo correctamente hasta que añadí el webpart a SharePoint. En ese momento, comenzó a suceder una cosas muy rara: únicamente podía pulsar una vez el botón. Cuando me devolvía el fichero, el resto de la página no respondía a los eventos. Realice pruebas de nuevo con el mismo webpart fuera de SharePoint y todo funcionaba correctamente.
Este problema se debe a que cuando se envía el formulario, se llama a la función WebForm_OnSubmit y desde ahí a la función _spFormOnSubmitWrapper (en el init.js). Precisamente en ésta función se verifica si la variable _spFormOnSubmit se ha puesto a true, y en ese caso, se cancelan las peticiones de envió. Imagino que este mecanismo evita que se produzcan múltiples envíos del formulario ante un doble click del usuario.
La solución consta de dos pasos:
· Asignar en el evento del botón (en el lado del cliente) a:
exportRequested=true;
· Añadir las siguientes líneas en el evento de carga (page_load) del control de usuario/pagina/webpart
string beforeSubmitJS = "var exportRequested = false; ";
beforeSubmitJS += "var beforeFormSubmitFunction = theForm.onsubmit;";
beforeSubmitJS += "theForm.onsubmit = function(){ ";
beforeSubmitJS += "var returnVal = beforeFormSubmitFunction();";
beforeSubmitJS += "if(exportRequested == returnVal){_spFormOnSubmitCalled=false; exportRequested=false;}";
//beforeSubmitJS += "alert(returnVal + '\\n' +_spFormOnSubmitCalled);";
beforeSubmitJS += "return returnVal;";
beforeSubmitJS += "};";
//beforeSubmitJS += "alert(theForm.onsubmit);";
this.Page.ClientScript.RegisterStartupScript(this.GetType(),"alterFormSubmitEvent", beforeSubmitJS, true);
Espero que os ayude.
Muchos somos los que desarrollamos soluciones para MOSS o WSS y en ocasiones, damos muchas vueltas para obtener información o realizar acciones que ya existen por defecto pero no lo sabemos. En esta entrada, vamos a ver algunas de las utilidades que proporciona la clase SPUtility, hay muchas más y en función de las necesidades de cada uno, tendrán o no sentido, pero en estas son algunas de las que he utilizado hasta la fecha.
Para hacer uso de esta clase, es necesario incluir la siguiente línea:
using Microsoft.SharePoint.Utilities;
Antes de comentar algunos de los métodos que proporciona, destacar que una de las ventajas de esta clase, es que al tratarse de una clase estática, no necesitamos instanciarla, lo cual facilita el acceso desde cualquier parte de nuestro código. A continuación describo la utilidad y como utilizar algunos de los métodos de ésta clase:
· EnsureSiteAdminAccess: éste método permite validar si el usuario actual es administrador del sitio al que accede. Existen otros métodos para validar esto, pero lo interesante es que en este caso, si no se trata del un usuario administrador, aparecerá la ventana de login tres veces, dando la opción al usuario a acceder con otra cuenta. En caso de que el usuario no tenga acceso, se le enviará a la página de acceso denegado. En el código del ejemplo, se utiliza un control de usuario que estará cargado en un webpart.
protected void Page_Load(object sender, EventArgs e)
{
SPUtility.EnsureSiteAdminAccess(SPContext.Current.Web);
//Resto del código
}
· GetGenericSetupPath: ¿quién no ha necesitado alguna vez la famosa ruta hasta el directorio 12? Este método nos devuelve la ubicación del directorio de instalación, en la mayoría de los casos es c:\Program Files…\….\12 pero no queda demasiado bien dejar el código con estas ruta y si cambia necesitaremos realizar modificaciones. En el caso del ejemplo, obtenemos la ruta hasta la carpeta features.
string directorioFeature= SPUtility.GetGenericSetupPath(&quot;template\\features&quot;);
SendEmail: permite enviar correos electrónicos haciendo uso de las configuraciones de la granja.
string subject = &quot;Correo electronico de notificación de &quot; + SPContext.Current.Web.Title;
string body = &quot;El cuerpo del correo electronico a enviar&quot;;
SPUtility.SendEmail(SPContext.Current.Web, false, false, &quot;miemail@miemail.com&quot;, subject, body);
· TransferToErrorPage y TransferToSuccessPage:permiten redirigir a las páginas por defecto de error o bien de operacón realizada con éxito.
Evidentemente no son todos los métodos ya que la idea principal es ver como se pueden utilizar éstos métodos.
Finalmente, recomiendo que visitéis en el SDK los métodos y propiedades que proporciona ésta clase, aunque aviso que no todos están documentados.
SDK Clase SPUtility
Durante estos días he tenido que modificar diseños de páginas y crear formularios personalizados para rellenar todos los campos de una biblioteca de páginas. Antiguamente, creaba un formulario personalizado donde añadía etiquetas y cuadros de texto, DropDownList y demás elementos para permitir rellenar el formulario.
Esta forma de programación está muy extendida y es completamente funcional, pero no es la más óptima, dado que cualquier cambio en el tipo de columna de una lista, puede generar numerosos cambios en el formulario (por ejemplo, en un campo de búsqueda, deberíamos obtener los elementos, rellenar el combo, añadir eventos….). Gracias a los controles web de SharePoint, sería suficiente con cambiar el control, y automáticamente realizaría los cambios necesarios.
Para utilizar estos controles, es necesario registrar la librería en la página, webpart o control de usuario dónde creemos el formulario.
| <%@ Register Tagprefix="SharePointWebControls" Namespace="Microsoft.SharePoint.WebControls" Assembly="Microsoft.SharePoint, Version=11.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %> |
Una vez tenemos registrada la librería, se puede hacer uso de estos controles del mismo modo que cualquier otro control asp, html… Por ejemplo, para añadir un control que permita escoger el valor de una columna de búsqueda de nuestra lista, denominado “Departamento”
<SharePointWebControls:LookupField runat="server" id="idDepartmentoField" FieldName="Departamento"/>
Este es sólo un ejemplo de uno de los controles existentes en esta librería, cabe destacar los controles que permiten subir ficheros, o botón guardar, editar,… o bien visualizar información de los elementos de la lista.
A continuación muestro una tabla donde aparecen los controles más utilizados en función del tipo de columna.
Para información detallada de éstos controles, pueden consultar:
Microsoft.SharePoint.WebControls Namespace
Para eliminar un page layout es necesario eliminar previamente todas las páginas que lo utilizan. Puede que debido a las dimensiones del portal, o bien por no recordar dónde utilizamos ese layout para hacer una prueba, no sepamos que páginas lo utilizan y al eliminarlo se produzca el siguiente error: "This item cannot be deleted because it is still referenced by other pages".
SharePoint ofrece la funcionalidad de listar todos los elementos que utilizan un page layout, y después de dar mil vueltas por el portal, la he encontrado. Como se puede ver puede ver en las imágenes, esta funcionalidad muestra que elementos usan un page layout como estructura de la página, pero además muestra que elementos componen dicho page layout.
Para acceder a esta funcionalidad, hay que seguir los siguientes pasos:
1.- Menú Acciones de Sitio -> Administrar Contenido y Estructura
2.- Pulsar sobre la carpeta "Galería de Páginas Maestras"
3.- Seleccionar el layout del cual queremos obtener la información y pulsar sobre "Mostrar recursos relacionados".
A continuación se cargará la siguiente página:
En la parte inferior, se puede observar que elemento utiliza el layout seleccionado, y que páginas utilizan este layout.
Recientemente publiqué una entrada que explicaba como se puede utilizar la herramienta SPDisposeCheck desde la consola, pero resulta que he encontrado una forma para poder ejecutarlo desde el Visual Studio (ya no hay excusas para no pasar esta herramienta por nuestro código). Para hacer uso desde visual studio, y teniendo instalada la herramienta, tenemos que ir al menu Tools (o herramientas) y pulsar sobre External Tools (herramientas externas). Una vez hay, tenemos que crear una nueva y configurarlo de la forma que se indica en la imagen.
Una vez este configurado, pulsamos en Apply y luego en Ok.
A partir de ahora, en el menú Tools (Herramientas) encontramos una opción SPDispose Check, la cual lanzara el SPDisposeCheck sobre la dll que se genera en nuestro proyecto y la salida de la herramienta, la tenemos en la ventana de salida de nuestro visual studio.
A continuación se muestran dos ejemplos con el código de la entrada anterior donde se pueden ver los resultados.
En fin, ya no hay excusas.
Hace un par de días, un compañero de trabajo me comento la existencia de una herramienta de Microsoft, que es bastante interesante para aquellos que estén desarrollando para SharePoint y WSS. La herramienta se llama SPDisposeCheck, y nos proporciona una forma rápida de comprobar que en el código que desarrollemos estamos realizando la liberación de los objetos de forma correcta, además de avisarnos en algunas otras circunstancias, como puede ser el uso de métodos que devuelven objetos y no almacenamos el valor de retorno.
Una vez la hemos descargado e instalado (el directorio por defecto es: “C:\Program Files\Microsoft\SharePoint Dispose Check” la forma de uso es la siguiente:
SPDisposeCheck [-debug] [–xml ]
-La opción “debug” es opcional y genera una salida con más información
-La opción “xml ” es opcional y genera un fichero xml con la salida, donde indica el nombre del fichero que utilizaremos para la salida.
A continuación se muestran dos ejemplos de uso:
Como se puede observar en el código de la imagen,se utilizan los objetos SPSite y SPWeb pero no se liberan al finalizar las operaciones
Si se utiliza la herramienta SPDisposeCheck sobre la dll que genera este código, se puede comprobar que nos indica la línea donde se declara un objeto que posteriormente no es liberado.Un ejemplo de la salida:
Como se puede observar en el código de la imagen,se utilizan los objetos SPSite y SPWeb y se liberan al finalizar las operaciones.
Si se utiliza la herramienta SPDisposeCheck sobre la dll que genera este código, se puede comprobar que nos indica que en este caso, se están liberando todos los objetos de forma correcta.Un ejemplo de la salida:
A continuación os dejo unos enlaces que puedes ser de utilidad:
Roger Lamb's SharePoint Developer Blog
Best Practices: Using Disposable Windows SharePoint Services Objects
SharePoint Dispose Checker Tool
Simplemente informar, para todo aquel que lo desconozca, que el tamaño máximo del nombre de un ámbito de búsqueda en SharePoint 2007 es de 60 caracteres
Una vez hemos configurado el servicio de búsqueda con acceso a todo el portal, (parte I y parte II) debemos crear y configurar el/los orígenes de contenido para especificar que contenido queremos rastrear y de dónde obtendremos los datos. Un origen de contenido, especifica las direcciones de inicio del rastreador. Por defecto, cuando se instala el producto, existe un origen de contenido creado denominado “Todos los sitios” mediante el cuál se rastrean todas las aplicaciones web existentes en la granja. Cada vez que se crea una nueva aplicación web, ésta se añade al origen de contenido por defecto, de modo que en los resultados de la búsqueda, pueden salir elementos de otra aplicación web (si el usuario tiene permiso en varias aplicaciones web). En muchas ocasiones, se recomienda crear un origen de contenido por aplicación web, o incluso varios orígenes de contenido para una misma aplicación web, dependiendo del funcionamiento deseado. A continuación veremos como se crea y configura un origen de contenido, y como se puede añadir eliminar contenido de éste.
Para crear un origen de contenido, hay que acceder a la administración central de la granja y posteriormente, seleccionaremos el proveedor de servicios compartidos, en mi caso, “SharedServicess1”.
A continuación, seleccionamos la opción “Configuración de Búsquedas” dentro de la sección “Búsqueda”.
En la ésta página se muestra tras pulsar el enlace, aparece información del servicio de búsqueda, dónde se puede comprobar a simple vista, si el servicio está rastreando elementos, el número de orígenes de contenido que existen, los elementos que se han rastreado, número de errores,…
En nuestro caso, seleccionamos “Orígenes de contenido y programaciones de rastreo” y pulsamos sobre “Nuevo”.
En ésta página, nos solicitan los datos para la creación del origen de contenido, así como programar el rastreo para conseguir que se añade el contenido automáticamente al índice. Será necesario rellenar todos los campos.
-
Nombre: indica el nombre que le daremos al origen de contenido.
-
Tipo de origen de contenido: indicamos de dónde obtendremos el contenido, carpetas de red, sitios web, carpetas de Exchange, sitios de SharePoint…
-
Direcciones de inicio: Especificamos la dirección del sitio de SharePoint, carpeta de red,… en función del valor seleccionado en el caso anterior.
De ésta forma tendremos los orígenes de contenido disponibles para realizar búsquedas desde el portal, sobre elementos de SharePoint, o bien carpetas de red, otras páginas web, correo,…
Como punto importante a tener en cuenta, son las programaciones de rastreo dado que hasta que no se lance un nuevo rastreo (incremental) no se tendrá acceso en la búsqueda al contenido del portal. Esto puede inducir a reducir la frecuencia de los rastreos incrementales, y hay que tener en cuenta que es un proceso que accede al portal o por tanto reduce el rendimiento. Hay que buscar un equilibrio en función de las necesidades de cada uno.
Para ampliar la información acerca de los elementos que se pueden rastrear y como añadir o eliminar elementos del índice, os dejo los siguientes enlaces que pueden ser de ayuda.
TechNet - Configuración de búsqueda e indización
TechNet - Creación de orígenes de contenido
TechNet - Contenido a rastrear
TechNet - Administración de Orígenes de Contenido
En la primera parte, vimos como configurar los servicios de búsqueda y la cuenta de acceso al contenido (leer entrada), de ésta forma, nos aseguramos que los servicios de rastreo tengan acceso al contenido de nuestras aplicaciones web, pero existen más opciones de configuración para evitar que se rastree determinada información, o bien agregar nueva información. Para ésto, utilizaremos las reglas de rastreo.
Las reglas de rastreo nos permiten añadir o excluir contenido del índice de elementos rastreados. Antes de ver como se crean las reglas de rastreo, es necesario resaltar la diferencia entre las reglas de rastreo y las reglas de los ámbitos. En el caso de las reglas de rastreo de exclusión, el contenido que cumple con el criterio especificado en la regla, se elimina del índice, de modo que nunca estará disponible para nadie/nada, mientras que si se añade una regla de un ámbito de exclusión, el contenido no se elimina del índice pero si del contenido de ese ámbito, de modo que el contenido estará disponible para el resto de los ámbitos.
Para crear las reglas de rastreo, hay que acceder a la administración central de la granja y posteriormente, seleccionaremos el proveedor de servicios compartidos, en mi caso, “SharedServicess1”.
A continuación, seleccionamos la opción “Configuración de Búsquedas” dentro de la sección “Búsqueda”.
En la ésta página se muestra tras pulsar el enlace, aparece información del servicio de búsqueda, dónde se puede comprobar a simple vista, si el servicio está rastreando elementos, el número de orígenes de contenido que existen, los elementos que se han rastreado, número de errores,… A continuación, pulsaremos en “Reglas de Rastreo”.
Existen dos tipos de reglas:
-
Reglas de exclusión: reglas que eliminan del índice todos los elementos rastreados que cumplan el criterio especificado en la ruta de acceso. Por ejemplo, en la imagen siguiente, se muestra una regla de rastreo que no permite añadir al índice ningún elemento del sitio subsite1 que se encuentre en el sitio mySiteName.
Reglas de inclusión: reglas que añaden al índice elementos rastreados que cumplan el criterio especificado en la ruta. En este caso, la ruta puede ser otro servidor de SharePoint, o una sitio web. La peculiaridad de estas reglas de rastreo de inclusión, es la posibilidad de modificar la cuenta de acceso que será necesaria para rastrear el sitio especificado, o bien un certificado.
Más información:
TechNet - Reglas de Rastreo
Durante estos primeros posts, voy a escribir sobre la configuración del motor de búsqueda de SharePoint, y poco a poco me iré metiendo en otras opciones de configuración, en ocasiones desconocidas, que pueden repercutir en el rendimiento de la búsqueda, rastreo o resultados obtenidos. Pero antes de nada, será necesario tener configurados los servicios, orígenes de contenido, ámbitos, propiedades…
En la mayoría de las aplicaciones web que se crean con MOSS, ya sea intranet o internet, es necesario incluir la funcionalidad de búsquedas para facilitar la localización del contenido dentro del portal. En esta entrada, veremos cómo activar el servicio de búsqueda para que indexe todo el contenido del portal.
Antes de empezar:
A continuación se detalla como configurar el servicio de búsqueda, así como configurar las cuentas de acceso al contenido.
En primer lugar será necesario revisar el usuario que esta corriendo los servicios citados con anterioridad. Para ello, Inicio –> Ejecutar –> services.msc
En caso de disponer de una cuenta para el rastreo, será necesario cambiar el nombre de usuario que ejecuta el proceso. Para ello, pulsamos con el botón derecho sobre el nombre del servicio, e introducimos el nombre de usuario y contraseña correspondiente. Será necesario reiniciar los servicios después del cambio de usuario.
Una vez realizado el cambio (si era necesario), abrimos la Administración central y accedemos a la administración de servicios compartidos. Una vez allí, pulsamos sobre configuración de búsquedas.
Finalmente pulsamos sobre la opción: Cuenta predeterminada de acceso al contenido.
Aparecerá un ventana en la cual se introduce el nombre de usuario y contraseña que será la cuenta de acceso al contenido. Debe tener permisos de lectura en todas las aplicaciones/colecciones sitios/sitios/… para poder rastrear todo el contenido.
Una vez realizados estos pasos, ya tendremos el motor de búsqueda correctamente configurado para que pueda acceder a todo el contenido del portal.
En futuras entradas, veremos la forma de configurar el resto de opciones que proporciona la búsqueda de SharePoint como por ejemplo, los orígenes de contenido, ámbitos de búsqueda, reglas de rastreo, propiedades rastreadas,…
Actualización: Configurando el motor de búsqueda de SharePoint (Parte II) - Reglas de Rastreo
Actualización: Configurando el motor de búsqueda de SharePoint (Parte III) Orígenes de contenido
Hola a todos,
En primer lugar quiero agradecer la oportunidad que tengo de participar de forma activa en esta comunidad y espero no defraudar a nadie. Imagino que a estas alturas será difícil hacerse un hueco debido a la multitud de blogs que se pueden encontrar sobre la temática que comentaré, pero que por esfuerzo no sea…
La mayoría de las entradas del blog estarán relacionadas con el desarrollo en .Net (concretamente C#) sobre Microsoft Office SharePoint Server (MOSS/WSS), donde veremos ejemplos de código para realizar algunas operaciones de configuración, nuevas funcionalidades, características, definiciones,... y artículos dónde comento alguna problemática que me ha surgido, y he tardado más de lo deseado en encontrar una solución..
Hasta la fecha he mantenido un blog en wordpress (Carlos Cano weblog) dónde se puede ver la línea que seguirán mis artículos.
Un saludo a todos, y hasta la próxima.
Carlos Cano.