Autor: pmarchena

Si después de publicar los content types de un content type hub estos no se muestran en nuestro portal subscrito esto se debe a que existen 2 timer jobs que se deben ejecutar y están programados para hacerlo, sin embargo su ejecución no es inmediata.

Para comprobar que la publicación funcione correctamente podemos iniciar los timer jobs mediante el Central Admin o vía PowerShell:

Ejecutar el siguiente script the PowerShell para poder ver nuestros content types publicados (Lo obtuve del siguiente link http://get-spscripts.com/2010/08/use-powershell-to-push-changes-from.html) :

#Run the Content Type Hub timer job
$ctHubTJ = Get-SPTimerJob «MetadataHubTimerJob«
$ctHubTJ.RunNow()

#Run the Content Type Subscriber timer job for a specific Web Application
$ctSubTJ = Get-SPTimerJob «MetadataSubscriberTimerJob» -WebApplication http://portal
$ctSubTJ.RunNow()

El http://portal representa la aplicación web que sea subscrito a nuestro content type hub, tendremos que ejecutar esa parte del script para cada aplicación web subscrita.

Si queremos realizar este procedimiento de manera manual tendremos que ingresar a la Aministración Central y en la sección de Monitoring seleccionar Review job definitions.

A continuación deberemos buscar el timer job Content Type Hub  y darle clic.

 

Después deberemos ejecutarlo de inmediato para lo cual deberemos dar clic en Run Now.

 Adicionalmente buscar el timer job Content Type Subscriber, existirá uno por cada aplicación web que este subscrita al Content type hub, por lo cual deberemos ejecutar el timer job de la aplicación web donde queramos ver replicados los content types de inmediato.

En el siguiente post veremos como obtener los resultados de búsqueda en formato XML esto nos será útil pues mediante este XML tendremos el control total para personalizar a nuestro gusto los resultados de búsqueda haciendo uso de XSLT.

A continuación los pasos:

1. Editar el Search Result WebPart

2. En el Editor XSLT copiar el siguiente XSLT:

<xsl:stylesheet version=»1.0″
  xmlns:xsl=»http://www.w3.org/1999/XSL/Transform«>
<xsl:output method=»xml» version=»1.0″ encoding=»UTF-8″ indent=»yes»/>
<xsl:template match=»/»>
  <xmp><xsl:copy-of select=»*»/></xmp>
</xsl:template>
</xsl:stylesheet>

3. Guardar los cambios. El resultado debería ser el siguiente:

En un cliente se presentó la necesidad de programar la actualización de todos los elementos de una lista una vez al año.

Esta necesidad se dio debido a que se disponía de una lista de cumpleaños donde mediante una columna calculada se mostraba la fecha actual del cumpleaños. Como sabemos las columnas calculadas no se actualizan a menos que el elemento de la lista haya sido actualizado, por lo tanto era muy complicado lograr obtener vistas de cumpleaños por el día actual.

Entre las alternativas existentes para lograr este objetivo preferí el uso de PowerShell por lo sencillo que es trabajar el uso de scripts que puedan ser programados y debido a que su despliegue era mas sencillo y tenía menos dependencias de servicios que desarrollar un job.

A continuación les comparto el script:

$site = Get-SPWeb -identity «http://miportal«

$list = $site.Lists[«Tareas»]

$spitems = $list.items

foreach($item in $spitems){

[Microsoft.SharePoint.SPListItem]$spListItem = $item

$Titleactual = $spListItem[«Title»];

$spListItem[«Title»] = $Titleactual;

$spListItem.Update();

}

Espero les sea de utilidad!

En este post explicaré como podemos personalizar nuestro Quick Launch para que tenga un efecto Collapsible haciendo uso de jquery.

He tomado como referencia el código de esta página: http://www.sharepoint2010guru.com/sharepoint2010architecture/knoxblog/SitePages/navdemo2.aspx es uno de los mejores que he encontrado para SharePoint 2010.

En el código al presionar el botón Make Navigation Collapsible el Quick launch cambia, sin embargo debido que yo quiere tener este efecto al cargar la página hice unas pequeñas modificaciones y copie el código en mi archivo actions.js que explique como utilizar en mi post anterior.

El código a copiar en actions.js debe ser el siguiente:

//Con la sección $(document).ready especifico que se ejecute la función Collapsible cuando la página este lista.

$(document).ready(function(){

makeLNCollapsible() ;

});

function makeLNCollapsible()
{
  $(«div.menu-vertical>ul.root>li.static>a span.menu-item-text»).append(
    «&nbsp;<img src=’_layouts/images/plus.gif’ border=’0′ class=’collapser’/>»);

  $(«img.collapser»).toggle(
    function () {
      $(«>ul», $(this).parent().parent().parent().parent()).show(«fast»);
      $(this).attr(‘src’,’_layouts/images/minus.gif’);
    },
    function () {
      $(«>ul», $(this).parent().parent().parent().parent()).hide(«fast»);
      $(this).attr(‘src’,’_layouts/images/plus.gif’);
    }
  );

  $(«div.menu-vertical>ul.root>li.static>ul.static»).css(«display»,»none»);
}

El resultado final debería ser el siguiente:

Cuando comenzamos a configurar nuestras granjas de SharePoint comenzamos instalando nuestro primer servidor y progresivamente agregando nuevos servidores a la granja. Sin embargo, durante la instalación no existe ninguna opción que permita especificar que nuestro servidor tendrá el rol de Application Server o de Web Server.

Para nosotros poder definir que servidor será application server y cual será un WFE tenemos que hacerlo mediante la configuración de los servicios que son ejecutados.

Los servicios que deberían ejecutarse desde un WFE son los siguientes (Principalmente lo que están marcados en negrita):

Microsoft SharePoint Foundation Incoming E-Mail
Microsoft Foundation Subscription Settings Service
Microsoft SharePoint Foundation Web Application
Microsoft SharePoint Foundation Workflow Timer Service

Esta información la pude obtener de un link bastante interesante: http://www.wahidsaleemi.com/2010/04/which-services-are-required-for-sharepoint-2010-web-server-role/

 

 

Cuando en SharePoint configuramos nuestras aplicaciones web para utilizar nombres alternativas mediante Alternate Access Mapping (AAM) probablemente al intentar acceder desde nuestros Web Front End nos pedirá autenticarnos varias veces hasta mostrarnos un mensaje de error 404.1.

Si por otro lado intentamos acceder desde cualquier equipo cliente no tendremos este inconveniente. Si deseamos acceder desde los WFE será necesario deshabilitar el loopback security check de windows, para esto abrir PowerShell e ingresar el siguiente comando:

New-ItemProperty HKLM:SystemCurrentControlSetControlLsa -Name «DisableLoopbackCheck» -Value «1» -PropertyType dword

Reiniciar el servidor y volver a ingresar.

Para mas detalle: http://support.microsoft.com/kb/896861

Metiendome un poco a revisar los temas de jquery y javascript para aplicarlos a mis portales con SharePoint encontré varios links interesantes.

Pero uno de los mejores para aquellos que recien empiezan es http://thenewboston.org/ tiene muchos tutoriales paso a paso muy buenos y se los recomiendo.

 

Comparto con ustedes un script para crear múltiples site collections con su base de datos independiente:

Script de PowerShell:

Add-PsSnapin Microsoft.SharePoint.PowerShell

#Cargando las variables
Write-Host «Cargando las variables»
$server = «SP2010AliasSQL»

$csvfile = ‘\DBSrv01ScriptsSP2010DeploymentCreatingSiteCollectionsSiteCollectionsToCreate.txt’
$csvdata = Import-Csv $csvfile
foreach ($line in $csvdata)
{
$url = $line.Url
$owner1 = $line.Owner1
$owner2 = $line.Owner2
$name = $line.Name
$description = $line.Description
$language = $line.Language
$template = $line.Template
$dbname = $line.DBName
$webapp = $line.WebApp

#Creando BD de Contenido
Write-Host «Creando Base de datos de contenido»
New-SPContentDatabase -Name $dbname -DatabaseServer $server -WebApplication $webapp | out-null
Write-Host «Base de datos » $dbname » Creada»

#Creando Colección de sitios
Write-Host «Creando Coleccion de Sitios»
New-SPSite -URL $url -OwnerAlias $owner1 -SecondaryOwnerAlias $owner2 -Name $name -Description $description -Language $language -Template $template -ContentDatabase $dbname | out-null
Write-Host «La coleccion de sitios » $url » fue creada»

}

Archivo .txt con la lista de site collections: (Se muestra la estructura que debe tener)

Url,Owner1,Owner2,Name,Description,Language,Template,DBName,WebApp
http://webspsrv01/proyectos/proy01,contososp_install,contosopiero.marchena,PROYECTO 01,PROYECTO 01,1033,STS#0,WSS_Content_PROY01,http://webspsrv01

 

 

A continuación les comparto un script para republicar content types desde un Content Type Hub. Esto resulta útil en pases a producción donde se lleva un backup completo del content type hub y del site collection de la solución a restaurar.

El script lo obtuve de esta página: http://get-spscripts.com/2010/11/republish-all-hub-content-types-in.html se las recomiendo pues tiene muchos ejemplos interesantes del uso de PowerShell para SharePoint.

function Republish-HubContentTypes ($CTHubURL)
{
    #Get Content Type site and web objects
    $ctHubSite = Get-SPSite $CTHubURL
    $ctHubWeb = $ctHubSite.RootWeb

    #Check the site is a content type hub
    if ([Microsoft.SharePoint.Taxonomy.ContentTypeSync.ContentTypePublisher]::IsContentTypeSharingEnabled($ctHubSite))
    {
        #Set up ContentTypePublisher object to allow publishing through the Content Type Hub site
        $spCTPublish = New-Object Microsoft.SharePoint.Taxonomy.ContentTypeSync.ContentTypePublisher ($ctHubSite)
       
        #Step through each content type in the content type hub
        $ctHubWeb.ContentTypes | Sort-Object Name | ForEach-Object {
           
            #Has the content type been published?
            if ($spCTPublish.IsPublished($_))
            {
                #Republish content type
                $spCTPublish.Publish($_)
                write-host «Content type» $_.Name «has been republished» -foregroundcolor Green
            }
            else
            {
                write-host «Content type» $_.Name «is not a published content type»
            }
        }
    }
    else
    {
        write-host $CTHubURL «is not a content type hub site»
    }
    #Dispose of site and web objects
    $ctHubWeb.Dispose()
    $ctHubSite.Dispose()
}

#Republicar Content Types del content type hub
Republish-HubContentTypes -CTHubURL http://miportal/soluciones/contenttypehub

Muchas veces personalizamos nuestras propias páginas para referenciar a elementos de lista mediante filtros por el ID del elemento, esto utilizando full XSLT.

Con esta personalizaciones, poder ver noticias o anuncios con una interfaz que no es la propia del formulario de vista de elemento resulta muy atractivo. Sin embargo, cuando rastreamos nuestro contenido y obtenemos como resultado los elementos de una lista como la de anuncios al darle clic nos direcciona a la página de la vista del elemento.

Si nosotros queremos redireccionar esto para que nos envíe a la página que personalizamos, lo podemos hacer editar el XSLT del Search Result.

Para esto deberemos abrir desde SharePoint Designer el XSLT e incorporar lo siguiente debajo de la etiqueta <xsl:template match=»Result»>:

en <xsl:when test> se valida que la Url contenga la palabra Anuncios pues ese es el título de la lista de Anuncios y tambien se verifica que tenga la palabra DispForm pues es la url que nos lleva hacia la vista de formulario de un elemento de lista.

después se construye una cadena para la url de la página personalizada y se le añade el ID del elemento actual.

Espero les haya sido de utilidad!