WSS 3.0 & MOSS: Creación de un workflow de máquina de estados!

Habitualmente cuando se realizan ejemplos de workflows de Windows Workflow Foundation (WF) se suele recurrir al diseño y creación de workflows de tipo secuencial. Ahora bien, cómo sin duda sabéis, WF habilita la creación de workflows de máquina de estados, mucho más flexibles y capaces de modelar un espectro más amplio de procesos que los workflows de tipo secuencial sobre todo en lo que a la interacción humana se refiere.


Por otro lado, Windows Sharepoint Services 3.0 (WSS 3.0) y Microsoft Office Sharepoint Server 2007 (MOSS) son las plataformas y tecnologías que ofrece Microsoft para la colaboración y gestión de la información en los equipos de trabajo de una organización, y un conjunto de aplicaciones que mejoran la eficacia de las organizaciones permitiendo la colaboración y gestión de la documentación, aplicando flujos de trabajo con Windows Workflows Foundation, integra un potente motor de búsquedas, gestión de portales, publicación web, integración con Business Intelligence, etc. Por definición, tanto WSS 3.0 como MOSS son herramientas en la que los workflows de máquina de estados encajan a la perfección por estas características de flexibilidad y mayor interacción que hemos comentado. En este post vamos a detallar cómo crear un workflow de máquina de estados para ser desplegado y utilizado en WSS 3.0 & MOSS. Empecemos.


Creación del workflow


El workflow que vamos a crear es realmente sencillo y se compone de tres estados. Este workflow tiene la siguiente funcionaliad: al detectar que se crea un documento en una biblioteca de documentos genera una tarea en la lista de tarea , y que si el documento original sufre alguna modificación. el workflow se “despierta” y actualiza las tareas generadas inicialmente.


El primer paso es crear el proyecto de workflow para Sharepoint en el entorno de Visual Studio 2005 (ya vimos que con Visual Studio 2008 todo es mucho más automático, los pasos en este entorno serían los ya comentados). En este caso tenemos que seleccionar dentro de los proyectos de tipo Sharepoint la plantilla State Machine Workflow Library.






image Workflow_State_Machine_1

Una vez creado el proyecto, vemos que en la superficie de diseño ya tenemos un estado inicial (al igual que ocurre con los workflows de tipo secuenciales y la actividad OnWorkflowActivated): WorkflowInitialState. Por lo tanto, tendremos que añadir dos nuevos estados. El primero de estos estados se encargará de la generación de la tarea, así como de la detección de cambios en el elemento que provocó la generación de la misma. El segundo de los estados es el estado de fin del workflow. Para añadir un nuevo estado al workflow, hacemos clik con el botón derecho del ratón y seleccionamos la opción Add State. Repetimos la operación para añadir el segundo estado a la superficie de diseño:






Workflow_State_Machine_3 Workflow_State_Machine_4

Una vez que hemos añadido los estados, el siguiente paso consiste en dotarles de capacidad lógica añadiendo las actividades (propias de WF o de Sharepoint) necesarias. Para añadir estas actividades a un estado del workflow basta con arrastrarlas desde la toolbox del diseñador al estado. En mi caso, el estado 1 se compondrá de 1 actividad de tipo StateInitializationActivity, 2 actividades de tipo EventDrivenActivity, y 1 actividad de tipo StateFinalizationActivity. Cada una de ellas se encargará de responder a los eventos respectivos de creación de una tarea al crearse un ítem en la biblioteca de documentos, modificación de la tarea (para marcarla como completada, especificar un % de completado,…), detectar que se ha producido un cambio en las propiedades del documento que desencadenó el workflow y finalmente detectar que se ha completado el estado y se puede hacer la transición al estado final del workflow.






Workflow_State_Machine_4 Workflow_State_Machine_6

Una vez que ya tenemos los estados del workflow y sus correspondientes niveles hijos (actividades que acabamos de añadir), el siguiente paso consiste en especificar los estados de inicio y fin del worlflow a través de las correspondientes propiedades y establecer las transiciones entre estados:



  • Para especificar que un estado sea el estado final del workflow, lo seleccionamos y en el menú contextual (botón derecho del ratón) hacemos clic sobre la opción Set As Completed State.
  • Para el estado inicial se sigue la misma idea, pero seleccionando la opción Set As Initial State para el estado que queramos que sea el de inicio del workflow.
  • Para definir las transacciones, tenemos dos posibilidades:

    • De manera visual y seleccionando el nivel hijo dentro de un estado que vaya a ser origen o destino de la transición y cuando en el límite de la misma aparezca el símbolo image , arrastramos hasta el siguiente estado con la que queremos definir la transición. En mi caso, siguiendo este procedimiento, he enlazado la actividad onWorkflowActivated del estado inicial (InitialState) con el segundo estado del workflow…¿y esta transición en que se traduce? Pues si hacéis doble clic sobre el estado inicial varéis que el diseñador de workflows ha añadido a continuación de la actividad onWorkflowActivated una actividad de tipo SetStateActivity que es la responsable de que la transición entre estados tenga lugar.
    • De nuevo de manera visual, pero controlando como se realiza la transición en función de definir una cierta condición. Esta técnica la vamos a utilizar para modelar la transición entre el estado intermedio y el definido como final de nuestro workflow:

      • Hacemos doble clic sobre la actividad desde la que produce la transición (en este caso on TaskChanged).
      • A continuación de la actividad anterior añadimos una actividad de tipo IfElseActivity, que configuramos de manera que en la primera rama situamos una actividad de tipo SetStateActivity que es la que nos permitirá definir la transición del estado actual al destino. Para definir esta transición especificamos que el valor de la propiedad TargetStateName sea CompletedState (que es el último estado del workflow de máquina de estados que estamos construyendo).

Tras realizar los pasos anteriores, tendremos definidas las correspondientes transiciones entre los estados que hemos definido en el workflow.







Workflow_State_Machine_7 Workflow_State_Machine_9 Workflow_State_Machine_10

Configurando los niveles hijos


Hasta ahora hemos diseñado e implementado de manera visual el workflow de máquinas de estados a partir de crear una serie de estados y unas transiciones entre los mismos. como hemos visto, cada estado se compone de una serie de actividades (niveles hijos) que tienen que ser configurados de manera adecuada. En particular, para el workflow creado hay que realizar las siguientes configuraciones:



  • Estado InitialState, Actividad onWorkflowActivated, tenemos que configurar la propiedad CorrelationToken. Especificamos para la misma workflowToken (por defecto aparecerá esta).
  • Estado TaskCreatedState, para el que realizamos las siguientes configuraciones:

    • Hacemos doble clic sobre la actividad InitTaskCreatedState y añadimos a continuación de esta una actividad de tipo CreateTask con las siguientes propiedades:

      • CorrelationToken, especificamos como valor taskToken.
      • MethodInvoking, especificamos InitCreateTask.
      • TaskID, que se configura a partir de la definición de una propiedad (taskID) o campo de la clase que representa el workflow. Se podrá definir de manera visual (a través de la ventana de definición, de la que se detalla un ejemplo debajo) o directamente en código.
      • TaskProperties, que configuramos con otra nueva propiedad denominada taskProperties (creada con el mismo mecanismo seguido para taskID).

Workflows_VS_6




    • Para la actividad onTaskChanged (que es de tipo EventDriven) realizamos las siguientes configuraciones:

      • Añadimos una actividad de tipo onTaskChanged encima de la actividad IfElse que gobierna la transición al estado final del workflow. Esta actividad la configuramos del siguiente modo:

        • Especificamos como taskToken como valor para la propiedad CorrelationToken.
        • Especificamos taskID como valor para la propiedad TaskID.
        • Creamos un nuevo campo denominado afterProps (siguiendo el procedimiento visual comentado) para asignarlo a la propiedad AfterProperties.

      • Especificamos la condición para la actividad IfElse. En este caso vamos a definir una condición de tipo declarativo (Declarative Rule Condition) con la siguiente expresión: onTaskChanged1.AfterProperties.PercentCompleted==1, es decir, para poder realizar la transición al estado final es necesario que el usuario complete la tarea al 100 %.


image




    • Para la actividad onWorkflowItemChanged (que responde a cambios en el ítem que desencadeno el workflow), realizamos los siguientes pasos:

      • Añadimos una actividad de tipo onWorkflowItemChanged, para la que especificamos que su correlation token sea workflow token.
      • Añadimos una actividad de tipo Code especificando que el método invocado sea updateDueDates().
      • Añadimos una actividad de tipo UpdateTask (responsable de actualizar las tareas si se ha producido un cambio en los ítems a partir de las cuales se generaron) en la que especificamos:

        • Propiedad CorrelationToken=taskToken.
        • Propiedad TaskID=taskID.
        • Propiedad AfterProperties, creamos un nuevo elemento denominado taskProperties.

  • Estado CompletedState, en este caso añadimos una actividad de tipo CompleteTask, configurando las propiedades:

    • CorrelationToken=taskToken.
    • TaskID=taskID.

Codificando los manejadores


Una vez configurados los niveles hijos de cada estado, tenemos que codificar los manejadores que hayamos especificado en los correspondientes niveles hijos. En nuestro caso:



  • Método InitCreateTask(), inicializamos la propiedad taskID y definimos algunas de las propiedades propias del objeto taskProperties…en concreto el usuario al que asignaremos la tarea y el título de la misma.




        private void InitCreateTask(object sender, EventArgs e)        {            this.taskID = Guid.NewGuid();            this.updateDueDates(null, null);            this.taskProperties.AssignedTo = “litwaredemo\Administrator”;            this.taskProperties.Title = “Documento a revisar”;        }


  • En el método updateDueDates() lo que hacemos es actualizar la fecha de creación de la tarea a partir de añadirle un número aleatorio entre 5 y 15 días (suponemos que este es un requerimiento de negocio).




        private void updateDueDates(object sender, EventArgs e)        {           Random rand = new Random();           this.taskProperties.DueDate=               DateTime.Now.AddDays(rand.Next(5,15));        }

Sin más, firmamos el proyecto para que el ensamblado que se genere sea seguro y se pueda desplegar en WSS 3.0 / MOSS y compilamos para asegurarnos de que no hay ningún error.


Despliegue y prueba del workflow


Aunque ya comentamos en un post previo la técnica de despliegue de workflows (aunque con Visual Studio 2008 esta tarea se simplifica), vamos a recordar los pasos esenciales:



  • El workflow lo desplegaremos como una feature de Sharepoint, por lo que tendremos que crear el correspondiente archivo XML de definición de la misma:




<?xml version=”1.0″ encoding=”utf-8″?><Feature  Id=”BD2F0F08-8295-4543-9005-1C051CA8E7C5″          Title=”Ejemplo de Workflow Máquina de Estados en VS”          Description=”Ejemplo de workflow de máquina de estados.”

          Version=”1.0.0.0″ 

          Scope=”Site” xmlns=”http://schemas.microsoft.com/sharepoint/”>                <ElementManifests>                               <ElementManifest Location=”workflow.xml” />                </ElementManifests>                <Properties>                               <Property Key=”GloballyAvailable” Value=”true” />                </Properties></Feature>


  • Tenemos que definir el correspondiente manifiesto que describe el workflow:




<?xml version=”1.0″ encoding=”utf-8″ ?><Elements xmlns=”http://schemas.microsoft.com/sharepoint/”>                        <Workflow                                                Name=”Ejemplo de Workflow Máquina de Estados en VS”                                                Description=”Ejemplo de workflow de máquina de estados.”                                                Id=”A9824E24-3608-4504-A09B-323A492714BB”                                                CodeBesideClass=”ResetTaskWorkflow.Workflow1″

                                                CodeBesideAssembly=”ResetTaskWorkflow, Version=1.0.0.0,

                                               Culture=neutral, PublicKeyToken=31d35b2bfb1b9654″>                                               <Categories/>

                                               <MetaData>


                                               <StatusPageUrl>

                                                           _layouts/WrkStat.aspx</StatusPageUrl>                                               </MetaData>                        </Workflow></Elements>


  • Crearnos un script .bat en el que especificaremos los correspondientes comandos para copiar el assembly en la gac, copiar los XML, activar e instalar la feature en los correspondientes directorios dentro del directorio 12 del servidor donde tengamos instalado Sharepoint.
  • Nos vamos al site collection dónde vamos a utilizar el workflow y activamos la feature desde la galería de features del site collection.

Workflow_State_Machine_15


Probando el workflow


Para probar el workflow, simplemente desde las settings de una biblioteca de documentos de nuestro site collection especificamos que queremos utilizar el workflow que acabamos de desplegar, indicando para ello el nombre de la instancia, la lista de tareas en la que se van a a generar tareas y el modo de arranque (en este caso automático y cuando se cree un nuevo ítem):







Workflow_State_Machine_16 Workflow_State_Machine_17 Workflow_State_Machine_18

Una vez que hemos asociado el workflow a una biblioteca de documentos, para comprobar que la máquina de estados funciona como se espera:



  • Creamos o subimos un documento en la biblioteca, de manera que el workflow se iniciará y en la vista de listado de documentos de la biblioteca aparecerá una nueva columna con el nombre de la instancia del workflow y con valor In Progress (se ha creado una tarea que está pendiente de ser completada).
  • Si nos vamos a la lista de tareas, veremos que efectivamente se ha creado una tarea y que el estado de la misma es Not Started.
  • Volvemos a la biblioteca de documentos y cambiamos uno de los metadatos del elemento que desencadeno el arranque de la instancia al workflow.






Workflow_State_Machine_19 Workflow_State_Machine_20 Workflow_State_Machine_22


  • Si volvemos a la lista de tareas, veremos que la columna Due Date presenta un valor distinto al inicial. El workflow ha cumplido con su cometido, a actualizado esta columna al detectar que se había cambiado el ítem origen de la biblioteca de documentos responsable del inicio de la instancia del workflow.
  • Modificamos ahora la tarea y especificamos que el campo % Completed tenga un valor 100…si lo hemos hecho bien, esto significa que el workflow tiene que concluir y por lo tanto la columna de estado del workflow en la biblioteca debería tener el valor Completed…y así es!





Workflow_State_Machine_21 Workflow_State_Machine_23

 


Y hasta aquí llega este post en el que os queríamos contar como construir un workflow de máquina de estados para Sharepoint. Os podéis descargar el proyecto del workflow de este enlace. Esperamos que os haya resultado interesante.

SOA, S+S, ESB,…: SOA CONFERENCE 2007!

El próximo día 4 de diciembre tendrá lugar en Madrid y organizado por Microsoft la SOA Conference 2007. En este evento se verán en varias sesiones paralelas conceptos relacionados con términos de los que ya hemos hablado en este blog y que últimamente se oyen mucho: Service Oriented Architecture (SOA), Software + Services (S+S), Enterprise Service Bus (ESB) y otros muchos…se trata de un evento en el que se presentarán muchas de las novedades e ideas ya expuestas en la SOA Conference celebrada en USA, así como en varias sesiones del Tech-Ed de Barcelona.

El evento está orientado a distintas audiencias: desarrolladores, profesionales TI, arquitectos o directores de negocio y consistirá en una serie de sesiones impartidas por varios MVP’s (Pablo Peláez, Tomás Hernández), expertos de producto de Microsoft (como Eduardo Azanza o Fernando Bocigas) y un servidor (un poco apabullado por el nivel de la audiencia y de los “espeakers”, y también por tener que dar la última presentación…). La agenda del evento la podéis ver en este enlace, desde el que también podéis inscribiros.

Conéctese a la SOA conference 2007

Agenda

Colaboradores

Reserve ya su plaza haciendo clic aquí

Os animo a que os acerquéis al evento, puesto que muchas de lo que se contará y dirá en el mismo os váis a cansar de verlo y oirlo en los próximos años.

Visual Studio 2008 Beta2: Creando workflows para WSS 3.0 & MOSS!

Cómo ya sabéis, a finales de este mes tendremos disponible para descarga (suscriptores de MSDN) la nueva versión del entorno de desarrollo en plataforma Microsoft: Visual Studio 2008. A pesar de las ganas que tienen de descargárselo algunos de los habituales en Geeks.Ms, de momento nos tenemos que conformar con la Beta 2 de Visual Studio 2008. En este post voy a mostraros una de las mejoras (y que tuve la oportunidad de ver la semana pasada en el Tech-Ed de Barcelona de la mano de Ted Pattison, aunque la demo al final les cascó :PPP…eso si, vaya crack incluso de fiesta :))  que introduce Visual Studio 2008 en lo que a desarrollo en plataforma Sharepoint (WSS 3.0 & MOSS) se refiere. En concerto, en este post veremos lo fácil que resulta crear un workflow con Visual Studio 2008 y desplegarlo en un sitio de WSS 3.0 (casi con unos pocos clicks nos vale). Empecemos.

Creación del proyecto de workflow

Aunque este paso es obvio para los habituales a desarrollar en el entorno de Visual Studio, merece la pena pararnos en él porque nos permite ver una de las novedades ya comentadas de la nueva versión del entorno: su carácter multitarget, es decir, podemos decidir sobre que versión de .NET Framework vamos a implementar nuestra solución. Cómo ya habréis leído, la característica de soporte multiframework estará disponible para las versiones 2.0, 3.0 y 3.5 de .NET Framework.

Post_Workflow_VS_2008_1 

En este caso, nos interesa la versión 3.5 de .NET Framework. La seleccionamos, y claro al ser la versión más alta de .NET Framework, también es la que más plantillas tiene disponible. En nuestro caso dentro de los proyectos para lenguaje C # seleccionamos la sección Office y a continuación 2007. Aquí tendremos las distintas plantillas para crear elementos propios de la plataforma Microsoft Office: Add-Ins para la suite de Office y workflows para Sharepoint (de tipo secuencial o de máquina de estados). Seleccionamos al plantilla Sharepoint Sequential Workflow…hasta aquí todo es similar a lo que ya teníamos con Visual Studio 2005 y las plantillas para crear workflows en Sharepoint, pero es aquí dónde empieza lo bueno…

Post_Workflow_VS_2008_2

Las novedades empiezan nada más especificar el nombre de la solución y pulsar OK, pues se inicia un wizard de creación del workflow al estilo de lo que ya tenemos con Sharepoint Designer 2007 (SD 2007)…veamos unos pocos pasos de este wizard:

  • En primer lugar, nos encontraremos con una pantalla en la que se pide que especifiquemos el nombre del workflow (yo he puesto el mismo que a la solución) y el sitio de Sharepoint (de heco es un sitio de WSS 3.0 pues las pruebas están realizadas en una máquina virtual con WSS 3.0, Visual Studio 2005 y luego he instalado Visual Studio 2008 Beta2…y todo va bien, sólo se queja en cuanto a que necesita bastante memoria…) dónde vamos a desplegar el workflow…cool!
  • Al darle a Next, Visual Studio 2008 se conecta con el sitio de WSS 3.0 especificado (si lo hemos indicado bien) y en la siguiente pantalla nos permite especificar la forma de asociación del workflow (manual o automática), la lista o biblioteca del sitio al que vamos a asociar el workflow, la History List dónde ser irá registrando la información de ejecución del workflow y la Task List dónde se almacenarán las tareas en el caso de que nuestro workflow cree tareas.
  • En la siguiente pantalla se especifica la condición/es (no son excluyentes) de inicio del workflow: manual (por el usuairo), automáticamente al crearse un nuevo elemento en la lista/biblioteca, o bien cuando se actualice un elemento de la lista/biblioteca.
Post_Workflow_VS_2008_3 Post_Workflow_VS_2008_4 Post_Workflow_VS_2008_5

Hasta ahora todo muy interesante y es idéntico a los pasos que se siguen a la hora de crear un workflow desde SD 2007…aquí alguno se preguntará si hemos perdido la flexibilidad que nos da la creación de workflows en el entorno de Visual Studio, y la respuesta es que no. Basta con no marcar la opción Automatically associate workflow? y ya estaríamos en las mismas condiciones conocidas.

Creación del workflow

Una vez que finaliza el asistente para facilitar la creación del proyecto de workflow para WSS 3.0 & MOSS, aparece la superficie de diseño de workflows de Visual Studio 2008 y en el explorador de soluciones veremos que se han creado todos los elementos necesarios para diseñar el workflow (archivo workflow.cs) y para desplegarlo en WSS 3.0 & MOSS mediante una feature (archivos feature.xml  y workflow.xml). Estos archivos ya aparecían con las plantillas del SDK de WSS 3.0 & MOSS, pero aparte de definir el workflow  en sí, también teníamos que configurar adecuadamente los archivos feature.xml y workflow.xml siguiendo un proceso ciertamente laboriosos. Además, para desplegar el workflow en un sitio de sharepoint se creaba un archivo Install.bat en el que teníamos que especificar los comandos necesarios para desplegar físicamente la feature en el servidor, copiar los ensamblados en la GAC, desplegar la feature en sharepoint y activarla (mediante las correspondientes opciones del comando stsadm)…vamos, era una labor sencilla, pero que conllevaba seguir una serie de pasos de una manera ordenada. Sin embargo, con Visual Studio 2008 todo es mucho más sencillo ya que el asistente nos ha creado y configurado de manera adecuada:

  • El archivo feature.xml:

<?xml version=”1.0″ encoding=”utf-8″ ?>

 

<Feature  Id=”ab357e6f-0201-40d3-9187-29b620749ed2″

      Title=”WF_Secuencial_Visual_Studio2008 feature”

      Description=”My SharePoint Workflow Feature”

      Version=”12.0.0.0″

      Scope=”Site”

      ReceiverAssembly=”Microsoft.Office.Workflow.Feature, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c”

      ReceiverClass=”Microsoft.Office.Workflow.Feature.WorkflowFeatureReceiver”

      xmlns=”http://schemas.microsoft.com/sharepoint/”>

  <ElementManifests>

    <ElementManifest Location=”workflow.xml” />

  </ElementManifests>

  <Properties>

    <Property Key=”GloballyAvailable” Value=”true” />

 

    <!– Value for RegisterForms key indicates the path to the forms relative to feature file location –>

    <!– if you don’t have forms, use *.xsn –>

    <Property Key=”RegisterForms” Value=”*.xsn” />

  </Properties>

</Feature>

  • El archivo workflow.xml:

<?xml version=”1.0″ encoding=”utf-8″ ?>

 

<!– Customize the text in square brackets.

Remove brackets when filling in, e.g.

Name=”[NAME]” ==> Name=”MyWorkflow” –>

 

<Elements xmlns=”http://schemas.microsoft.com/sharepoint/”>

  <Workflow

     Name=”WF_Secuencial_Visual_Studio2008″

     Description=”My SharePoint Workflow”

     Id=”7a9325e2-2a2e-477f-b70a-324ac497c4a7″

     CodeBesideClass=”WF_Secuencial_Visual_Studio2008.Workflow1″

     CodeBesideAssembly=”WF_Secuencial_Visual_Studio2008, Version=1.0.0.0, Culture=neutral, PublicKeyToken=ac5a949a105159bc”

     AssociationUrl=”_layouts/CstWrkflIP.aspx”>

 

    <Categories/>

    <MetaData>

      <!– Tags to specify InfoPath forms for the workflow; delete tags for forms that you do not have –>

      <!–<Association_FormURN>[URN FOR ASSOCIATION FORM]</Association_FormURN>

       <Instantiation_FormURN>[URN FOR INSTANTIATION FORM]</Instantiation_FormURN>

      <Task0_FormURN>[URN FOR TASK (type 0) FORM]</Task0_FormURN>

      <Task1_FormURN>[URN FOR TASK (type 1) FORM]</Task1_FormURN>–>

      <!– Modification forms: create a unique guid for each modification form –>

      <!–<Modification_[UNIQUE GUID]_FormURN>[URN FOR MODIFICATION FORM]</Modification_[UNIQUE GUID]_FormURN>

      <Modification_[UNIQUE GUID]_Name>[NAME OF MODIFICATION TO BE DISPLAYED AS A LINK ON WORKFLOW STATUS PAGE</Modification_[UNIQUE GUID]_Name>

      –>

      <StatusPageUrl>_layouts/WrkStat.aspx</StatusPageUrl>

    </MetaData>

  </Workflow>

</Elements>

  • No menos importante es el hecho de que se haya generado el correspondiente archivo de firma, de manera que también nos vamos a ahorar el paso de firmar el ensamblado.

Además, no aparece por ningún sitio un archivo Install.bat, sino que para desplegar el workflow en el sitio de Sharepoint que hemos especificado al principio del asistente basta con utilizar la opción Deploy Solution que como más adelante veremos aparece disponible en el menún Build del entorno de Visual Studio 2008. Siguiendo con la creación del workflow, las novedades no acaban aquí, sino que el diseño en sí (visualmente) del workflow para Sharepoint también incluye mejoras referidas a que la ToolBox por fin cuenta con el juego completo de actividades necesarias para diseñar e implementar el workflow:

Post_Workflow_VS_2008_6

Como se ve en la figura, tenemos las actividades agrupadas en tres categorías:

  • Actividades de WF versión 3.0, es decir, las ya conocidas para la versión que actualmente tenemos de WF dentro de .NET Framework 3.0.
  • Actividades para workflows de Sharepoint (alguno dirá por fin), y que hasta ahora no aparecían por defecto en la toolbox de creación de workflows para Sharepoint, lo que nos llevaba a ir a buscarlas en el directorio del servidor de Sharepoint ..12ISAPI (ensamblado microsoft.sharepoint.WorkflowActions.dll) y añadirla mediante la opción Choose Items de la ToolBox del workflow designer de Visual Studio.
  • Actividades de WF versión 3.5, que generalizan la comunicación de un workflow con aplicaciones externas para enviar / recibir datos de las mismas.

Una vez que hemos visto las principales novedades que tenemos para crear un workflow para Sharepoint, vamos a ponernos manos a la obra y crear un sencillo workflow. En este caso, el workflow creado simplemente va a crear una tarea cuando se cree un elmento en la lista que especificamos en el asistente (la tarea se creará en la lista de tareas que especificamos también en el asistente). Luego añadimos una actividad CreateTask a continuación de la actividad OnWorkflowActivated que es la actividad que por defecto añade el diseñador al workflow para Sharepoint y que marca el inicio de este (es obligatoria en workflows para Sharepoint ya que es una actividad  de tipo event driven que está configura para responder a los eventos que genera Sharepoint cuando se crea una nueva instancia del workflow en respuesta a que se haya creado o modificado un elemento de una lista o biblioteca de Sharepoint). Una vez que hemos añadido esta actividad, la configuramos de manera adecuada a través de la ventana de propiedades:

  • Especificamos el correlation token de la misma a través de la propiedad CorrelationToken, es decir, el canal por el que vamos a hacer que flujan los datos relativos a la tarea. Por ejemplo, especificamos taskToke (al especificar este valor, os pedirá que indiquéis el activity owner que en este caso es el propio workflow que estamos modelando: en el desplegable os saldrá workflow).
  • Especificamos la propiedad TaskID, para lo que nos serviremos de la ayuda que nos da Visual Studio para definir visualmente el binding de esta propiedad con una propiedad existente en el workflow o con una nueva que definamos. En nuestro caso definimos una field property (que luego el diseñador generará en el fichero code behind asociado al workflow) con nombre taskID.
  • Especificamos la propiead TaskProperties siguiendo el mismo esquema que para TaskID, creando en este caso una field property denominada taskProps que como luego veremos nos va a permitir acceder a propiedades de un ítem propio de la lista de tareas.
  • Finalmente, en la sección Handlers especificamos el método que se va invocar cuando se cree la tarea. Lo denominamos CrearTarea()
image Post_Workflow_VS2008_8

Finalmente, una vez que hemos diseñado de manera visual el workflow, sólo nos resta codificar el método CrearTarea(), compilar para comprobar que no hay errores y hacer el deploy de la solución:

        private void CrearTarea(object sender, EventArgs e)

        {

            this.taskID = Guid.NewGuid();

            this.taskProps.AssignedTo = “wssv3\Administrator”;

            this.taskProps.Title = “Tarea creada desde VS 2008”;

        }

Post_Workflow_VS2008_9

Probando el workflow

Bueno, hasta ahora todo ha ido como la seda. Lo siguiente que vamos a hacer es comprobar que el workflow se ha desplegado correctamente (está asociado a la lista, lo que implica que la feature correspondiente se ha instalado y activado en el servidor), y a continuación que funciona como se espera. Comprobar que el workflow está asociado a la lista especificada en el asistente (Announcements) es sencillo, para ellonos vamos a las settings de la lista y bajo la columna Permissions and Management (el sitio Sharepoint de purebas está en inglés) pulsamos sobre Workflow Settings…en la página que se abre veremos los workflows que están asociados a la lista…y ahí está el workflow creado desde Visual Studio 2008 Beta2. De momento todo pinta bien.

Post_Workflow_VS2008_10 Post_Workflow_VS2008_11

Bueno, pues sin más vamos a comprobar que el workflow funciona. Volvemos a la interfaz de la lista Announcements y creamos un nuevo elemento desde el menú New Item, al salvar el elemento seremos redirigidos al listado de anuncios y veremos que a la vista de la lista se le ha añadido una nueva columna con el nombre de la instancia del woorkflow. El valor de esta columna como sabemos indica el estado de ejecución del la instancia del workfow que en este caso tiene un valor In Progress pues en nuestro workflowhemos definido que se cree una tarea en la lista Tasks y hasta que esta tarea no se complete, el workflow no habrá acabado su labor. De hecho, si vamos a la lista Tasks comprobaremos que efectivamente se ha creado la tarea comentada. Si editamos dicha tarea y la completamos, al volver a la lista Announcements veremos que el estado de ejecución de la instancia del workflow ha cambiado a COmpleted como era de esperar.

Post_Workflow_VS2008_12 Post_Workflow_VS2008_13 image

Bueno, pues todo ha funcionado perfectamente. Cómo véis, empezar a crear workflows para Sharepoint con Visual STudio 2008 es bastante más sencillo que lo que conocíamos de Visual Studio 2005 y las plantillas de creación de workflows para Sharepoint. También se facilita el despliegue de la solución y ya no tenemos que preocuparnos por configurar los archivos feature.xml, workflow.xml o Install.bat. Espero que el post os haya resultado interesante.

Microsoft Office System Developer Conference 2008!

La semana pasada en el Tech-Ed de Barcelona me pasé varias veces por la sección Ask the experts para preguntar alguna cosilla, ver cosas interesantes (sobre todo de WSS 3.0 & MOSS y de LINQ) y de paso conseguir alguna cosilla chula de merchandaising (me quedo con el balón de Office y el gorro de Software + Services). El caso es que en uno de estos paseso por la zona ask the experts (por allí estaban algunos Geeks como Iván González o Miguel Jimenez) me paré un rato a hablar con los expertos de desarrollo en plataforma Office porque tenían unas demos muy chulas de Microsoft Excel 2007, el correspondiente portal MOSS que mostraba la información de las hojas excel con Excel Services, y también cosillas de integración de Sharepoint con Reporting Services. Estuve hablando con Khawar Ahmed, y claro, igual que yo obtuve el beneficio de aprender cosas interesantes, él me estuvo comentando si sabía que el año (del 10 al 13 de febrero) que viene va a tener lugar la Microsoft Office System Developer Conference en la ciudad de San José en California.


image


Lógicamente yo le comenté a Khawar que no lo sabía, y el me animó a ir…je je, no estaría mal, pero le dije que en mi caso no iba a poder ser. Bueno, el caso es que me preguntó cómo podría difundir la noticia del evento y le comenté que yo podría echarle una mano y publicar la noticia en un foro tan relevante de tecnologías Microsoft como es Geeks.Ms. Como lo prometido es deuda, aquí dejo la noticia…a ver si alguien puede ir y nos cuenta que se dice en la conferencia porque tiene muy buena pinta.

WSS 3.0 & MOSS: Recopilación de enlaces interesantes (X)!

De nuevo os presentamos la tradicional entrega de enlaces interesantes que sobre WSS 3.0 & MOSS han aparecido recientemente (en los diversos blogs especializados y dedicados a esta plataforma) y que sin duda nos resolverán más de una situación de aprieto. En esta nueva edición del recopiltarorio destacamos los siguientes elementos de interés:

Artículos, Recursos & Documentación

Tips & Tricks

Utilidades, Novedades y Otros

  • En esta entrada podeís encontrar la LT Data Viewer Web Part especialmente pensada para visualizar datos de BD’s relacionales como SQL Server u Oracle. Lo malo es que es de pago (200 $).

Post_Recopilatorio_iDevFactory

 

    image image
  • Codeplex se está convirtiendo en la fuente por excelencia de utilidades y proyectos en torno a WSS 3.0 & MOSS. La última herramienta útil que me he encontrado es esta: Sharepoint Logging Spy.

  • Interesante iniciativa lanzadades Microsoft para proporcionar servicios de planning de Sharepoin: Sharepoint Deployement Planning Services.
  • Han aparecido en MSDN dos nuevos artículos sobre migración desde portal server 2003 con personalizaciones a MOSS:

Y hasta aquí llega la nueva entrega de este recopilatorio. Espero que el nuevo set de funcionalidades os haya resultado interesante. 

Software + Services, su relación con SOA y otras cosas…

Volviendo con los conceptos e ideas que subyacen bajo los términos de Software as a Service (SaaS), así como el de Service Oriented Architecture (SOA), en la última sesión del pasado miércoles en el Tech-Ed de Barcelona tuve la oportunidad de asistir a una conferencia impartida por David Chappel. La verdad es que merece la pena oir como David explica y pone ejemplos reales de este tipo de conceptos (algunos dirán que desde una perspectiva de muy alto nivel, pero es justo por aquí por dónde todo empieza…ya luego llegaremos a cuestiones más tecnológicas). La idea de este post es partir de la presentación de David Chappel para ver la perspectiva SaaS desde el punto de vista de Microsoft y su relación con SOA (de lo Miguel Llopis ya nos ha adelantado alguna cosilla en este post). Empecemos.


La perspectiva SaaS de Microsoft: Software + Services


Si recordáis el post prevíso sobre SaaS, lo que se trata es de un nuevo modelo distribución del software que proporciona a los clientes el acceso al mismo a través de la red (generalmente Internet), de manera que les libra del mantenimiento de las aplicaciones, de operaciones técnicas y de soporte. Desde el punto de vista de Microsoft, en lugar de hablar de SaaS hay que hablar de Software + Services (S+S), o lo que es lo mismo: Software On-premise (software que es usado dentro de la organización, es decir, la tendencia actual en el uso de aplicaciones) + Software Services (sofware que puede ser utilizado en cualquier lugar, sin necesidad de instalación, mantenimiento o soporte,…,pero cuidado, no estamos hablando de servicios web!). Básicamente, en este nuevo modelo las empresas no pagan por disponer, instalar y utilizar el software (modelo tradicional on-premise basado en licencias de software), sino que es un proveedor de software el que ofrece el servicio que necesita la organización, siendo por tanto quien garantiza su mantenimiento, escalabilidad, etc…en este escenario el cliente paga según el uso que hace del servicio.  Esquemáticamente, todo lo comentado se traduce en:



Siguiendo con el tema de Software + Services, y si pensamos un poco, hoy en día ya tenemos ejemplos de este tipo de aplicaciones software. De hecho, los dos ejemplos más claros los tenemos en plataforma Microsoft:



  • Microsoft Exchange Server,  la plataforma de mensajería confiable de Microsoft que puede ser utilizada en tres modalidades:

    • On-Premise, es decir, se realiza una instalación de la plataforma en la organización y se utiliza en la misma.
    • Siguiendo el concepto de S+S, por lo que habilita el que exista un proveedor de servicio que permite que los servicios de mensajería se puedan consumir en la red.
    • Siguiendo el concepto de S + S, pero siendo el propio Microsoft quién actue como proveedor del servicio.


  • Microsoft Dynamics CRM, que sigue la misma filosofía comentada para Exchange, ofrenciendo las tres modalidades comentadas:

    • On-Premise, es decir, la organización tiene instalado Microsoft Dynamics CRM
    • Un partner de Microsoft hostea Microsoft Dynamics CRM y lo ofrece en modalidad S+S.
    • La propia Microsoft es quien hostea Microsoft CRM y lo ofrece en modalidad S+S, en este caso estamos hablando de Microsoft Dynamis CRM Live.


En el caso de Microsoft Dynamics, es interesante el hecho de que aunque estamos hablando de tres modalidades o escenarios de utilización de la plataforma, no estamos hablando de tres plataformas diferentes, sino de una única que puede ser utilizada de estas tres formas.


S+S y SOA


Un cuestión interesante es si existe algún tipo de relación entre SOA y S+S, y la respuesta es que depende…de hecho, según David Chappel depende de lo que se entienda por SOA,…je je, ya estamos con filosofías y cuestiones retóricas…nada más lejos de la realidad. Esta claro que el concepto de servicio está muy  asociado al concepto de SOA, de hecho definimos SOA como: es un patrón de diseño arquitectónico, un estilo de arquitectura que se basa en la definición de relaciones con un grado de acoplamiento débil entre una serie de elementos consumidores y productores. SOA agrupa nuevas funcionalidades, y las ya existentes, en servicios atómicos que se comunican entre sí a través de pasar datos entre servicios o coordinando una actividad entre uno o más servicios. De acuerdo a esta definición de SOA:




  • Si SOA se refiere sólo a servicios proporcionados dentro de la organización, estariamos hablando del software on-premise en S+S.


  • Si estamos hablando de servicios proporcionados tanto dentro de la organización como a otros actores que intervengan en los procesos de negocio (socios comerciales, proveedores, etc), estaráimoas hablando de software on-premise y algunos aspectos SaaS en S+S.


  • Finalmente, si con SOA nos referimos a todos los servicios independientemente de su destino, entoces SOA y S+S están plenamente alineados y van de la mano.

Del concepto e idea de S+S a la realidad

Como hemos comentado, en la actualidad el software On-Premise es la alternativa dominante. Sin embargo, ya hay ejemplos de aplicaciones S+S que están teniendo éxito en cuanto a que proporcionan a sus clientes el máximo beneficio. Aunque ya vimos algunos ejemplos en el post sobre SaaS (y también en la primera parte de este post), veremos algunos más tanto en plataforma Microsoft como fuera de ella (en la sección de plataforma SaaS). Pero antes de verlos, una pregunta que nos podemos hacer es: entiendo S+S, incluso entiendo sus beneficios pontenciales…pero, ¿por dónde empiezo?, es decir, que tipo de aplicaciones encajan en esta filosofía de S+S…la respuesta inicial es que no todas las aplicaciones encajan en el concepto de S+S por lo menos a priori. Imaginaros el típico sistema de misión crítica, ¿tiene sentido llevarlo a S+S? Probablemente no, puesto que S+S se asienta en la capacidad de Internet que habilita utilizar este tipo de aplicaciones en cualquier lugar y en cualquier instante,..¿y si la red se cae? Pues, Houston tenemos un problema. Por lo tanto, hay que empezar con aplicaciones que no sean críticas para una organización y que tengan un cierto grado de flexibilidad: Microsoft Dynamis CRM es un ejemplo claro de esta idea (también Microsoft Exchange). Aunque ya hablamos de beneficios e inconvenientes, no está de más repasarlos:




































Beneficios Inconvenientes, Dudas, Problemas potenciales
Bajo coste: el cliente paga por uso, no por licencia. Confianza: ¿Hasta qué punto se puede confiar en el proveedor de servicio?
El despliegue es mucho más rápido que el despliegue in-house de cualquier aplicación paquetizada. Datos: ¿Qué niveles de seguridad se pueden asegurar?
Hay un menor riesgo financiero. Cumplimiento de la regulación existente: ¿Puede el proveedor de servicio garantizar el cumplimiento de las regulaciones existentes en cuanto a confidencialidad de los datos?
Las actualizaciones son más sencillas. Integración: ¿Cómo se puede conectar una aplicación SaaS con el resto de aplicaciones empresariales?
Alta confiabilidad Personalización: ¿Hasta qué nivel podemos llegar?
Alta Escalabilidad  
El cliente se centra en el negocio Identidad: ¿Soporta acceso federado?
La seguridad se aumenta Gestión: ¿Cómo se puede monitorizar una aplicación SaaS?
Respuesta ante los cambios muy rápida Soporte a Usuario: ¿Quién es ejecuta el Help Desk?

Tanto en S+S como en SOA hablamos de servicios, pero hasta ahora no hemos hablado en ningún momento de que tipos de servicios nos podemos encontrar. Desde una perspectiva S+S, podemos dividirlos en de acuerdo a distintos aspectos:



  • Por el tipo de servicio:

    • Consumer Services, más orientados al cliente / usuario final y que no tienen unas características de confiabilidad óptimas. Microsoft ofrece al cliente final los servicios de Live: el correo electrónico de Live, los espacios personales, etc.
    • Business Services, más orientados al cliente empresarial, que paga por el servicio y suele estar protegido por un service-level agreement (SLA). En este caso Microsoft ofrece los Online Services, siendo el ejemplo más claro el de CRM Live.


Fuera de Microsoft, el ejemplo más claro de esta clasificiacion de servicios es el de Google Apps, pues ofrece servicios sin coste (versión estándar, que incluye e-mail, creación de documentos, etc) y servicios premier que asegura una disponibilidad del 99,99 % para el servicio de correo electrónico, integración con el help desk empresarial, … (a un coste de 50 $ por usuario y año).



  • Por la forma en que son proporcionados:

    • Servicios Single-Tenant, es decir, tenemos una única instancia de aplicación por cada organización que la va a utilizar. De este forma se garantiza aislamiento, pero el proveedor de servicio pierde flexibilidad en cuanto a la posibilidad de compartir elementos entre múltiples organizaciones.
    • Servicios multi-Tenat, es decir, tenemos una única instancia que es compartida por distintas organizaciones. En este caso estamos hablando de una opción más económica para los clientes, pero con menos nivel de aislamiento que en el caso anterior.

Antes de empezar con la plataforma de aplicaciones S+S, os adelanto ya un ejemplo de aplicación que estaá funcionando en modalidad SaaS con éxito. Se trata de Salesforce.com, que ofrece servicios de CRM en modalidad SaaS y que es la prueba viviente de que el concepto e idea SaaS y por ende S+S funcionan.


 


Plataforma de aplicaciones en un mundo S+S


Básicamente una platataforma de aplicaciones SaaS, y una S+S, se caracteriza porque ejecuta aplicaciones personalizadas en servicores que corren en la red, es decir, no estamos hablando de crear una fachada de servicios web en las aplicaciones empresariales. Por lo tanto, dicha plataforma debería ofrecer las siguientes capacidades:



  •  Computing, es decir, estariamos hablando de características de (todas ellas disponibles en la red):

    • Sistema operativo, siendo Amazon’s Elastic Compute Cloud  (EC2) el ejemplo más aproximado ( a grandes rasgos, se trata de un conjunto de instancias personalizadas de Linux que se están ejecutando sobre máquinas virtuales y que se asientan sobre el sistema de almacenamiento S3) que tenemos hoy en día a un sistema operativo en la red (en las aplicaciones On-Premise estaríamos hablando de toda la familia de S.O Windows, o de las distintas versiones de Linux)..
    • Servicios de Aplicaciones, es decir, lo que le damos al cliente. En este caso los ejemplos claros son los que ya hemos comentado: Salesforce.com’s Force.Com y la plataforma de aplicaciones de Microsoft Dynamics CRM (en el caso On-Premise estaríamos hablando de .NET Framework o de Java EE app. Server).

  • Almacenamiento, es decir, ser capaces de almacenar objetos de información en la red:

    • A nivel de sistema de archivos, en este caso el ejemplo real más aproximado es de nuevo el sistema que utiliza Amazon: Amazon’s Simple Storage Service (S3). En el caso On-Premise estaríamos hablando de Windows NTFS o de el sistema de archivos de Linux.
    • A nivel de motor de base de datos: ahora mismo no existe ninún gestor de base de datos preparado para ser consumido en la red (en el caso On-Premise tenemos SQL Server 2005 / 2008, Oracle, MySQL, etc).

  • Integración, es decir, conectividad de aplicaciones, capacidad de orquestación y / o workflow, etc. El único ejemplos que tenemos hoy en día, todavía en versión CTP (aunque para el año que viene se prevé la versión RTM) es el de Microsoft BizTalk Services (en el caso On-Premise tenemos BizTalk Server, WebSphere Process Server,…). Microsoft BizTalk Services permitirá pasar de escenarios ESB a escenarios ISB cómo vimos en este post proporcionando servicios de conectividad, identidad y workflow.

En resumen….y el futuro


Para acabar el post, voy a recoger una tabla muy interesante que David Chappel nos mostró en la sesión y que resume que es lo que tenemos ahora mismo en cuanto a aplicaciones On-Premise y SaaS en tornos a dos aspectos: plataforma de aplicaciones, y aplicaciones en sí:


 


¿y que nos deparará el futuro? Pues el futuro desde el punto de vista de Microsoft (y se podría decir que el único) tanto para S+S como para SOA es OSLO. Las ideas que hay bajo  OSLO ya nos las comentó Miguel Llopis: proporcinar los elementos necesarios para simplificar SOA y enlazar con la estrategia S+S.


Sin más, esto era lo que os quería contar de S+S, SOA y otras cosas. Espero que el post os haya resultado interesante, creo que los temas tratados realmente lo son y que se va a hablar mucho de esto en los próximos meses y años (lo cuál significa que habrá muchos proyectos y trabajos en torno a todo ello).

IFilters

En los últimos post que he publicado he hablado sobre como instalar y configurar los IFilter en SharePoint para poder indexar y buscar contenido de ficheros PDF y OneNote, por eso ahora os detallo una serie de links donde podéis descargaros más tipos de IFilters para indexar más tipos de contenido (Para ver una lista completa de ficheros que se pueden indexar pulsa este link):

IFilters:

Utilidades:

  • IFilter Explorer: Utilidad para ver cuantos IFilters estan instalados el el servidor 

Referencias:

Microsoft Search Server 2008: Release Candidate!

Por fin, y después de 6 sesiones en el Tech-Ed en las que apenas he visto novedades (y si muchas demos que no funcionaban, aunque las sesiones de arquitectura a las que he asistido no han estado nada mal), en la última sesión del martes Ryan Duguid (del que no apunte su blog, y claro ahora no lo encuentro…) nos ha introducido lo que para mi es una gran novedad y una gran noticia (no había leído nada al respecto): Microsoft Search Server 2008…¿y eso qué es? Pues esto mismo me pregunté yo al poco de que empezara Ryan con la sesión, y la respuesta es que esta nueva joya de la corona es la versión actualizada y rehecha de Microsoft Office Sharepoint Server 2007 for Search. Es decir, el motor de búsqueda que conocemos hoy para MOSS deja de ser parte del mismo y se convierte en un elemento independiente que podemos instalar o no en nuestras soluciones de WSS 3.0 / MOSS…ala, otra licencia más. Bueno, esto es parcialmente cierto porque aquí no acaban las sorpresas…dos más:



  • Cómo es un elemento independiente, y que se supone construido sobre WSS 3.0 (la filosofía no cambia) podemos tener el potente motor de búsqueda en una instalación WSS 3.0 y no MOSS, con lo que tendríamos que pagar la licencia de Microsoft Search Server…pero eso está por ver :PP
  • Habrá dos versiones de search server:

    • Microsoft Search Server 2008, pensado para topologías distribuidas y que se licenciará por servidor.
    • …y Microsoft Search Server 2008 Express…ta chán, que es gratuito. Esto si que es un notición, podemos montar el motor de búsqueda en nuestras instalaciones WSS 3.0 (monoservidor, claro) sin coste alguno. Lógicamente, esta versión está más limitada en cuanto a escalabilidad y posibilidades de indexción, pues “sólo” permitirá indexar un total 400.000 documentos (el límite lo impone SQL Server Express)…si no nos llega esta capacidad de indexación, pues nos pasamos a la versión no express que puede indexar hasta 50 millones de documentos.

Además de este anuncio, también se ha comentado que ya hay una primera CTP de Microsoft Search Server 2008 Express que os podéis descargar desde este enlace. Yo ya tengo una copia (la estoy instalando ahora mismo, y creo que tardará algo más de los 20 minutos que nos comentaba Ryan) que nos dieron en la sesión (Ryan tenía una maleta llena de DVD’s de Microsoft Search Server 2008 Express). En cuanto a la fecha oficial de lanzamiento de la versión RTM, será en la Microsoft Office Sharepoint Conference 2008 que tendrá lugar del 3 al 6 de marzo de 2008.


¿Cómo afecta la instalación a lo que ya tengo en MOSS?


Esta es una pregunta que os haréis los que ya tenéis soluciones MOSS funcionando…la idea es que tan pronto como Microsoft Search Server 2008 esté listo, habrá una actualización para todos los clientes de MOSS. Dicha actualización que incluirá esta nueva forma de concebir las búsquedas para WSS 3.0 / MOSS, se realizará de dos formas:



  • Cómo un parche del SP1 para WSS 3.0 & MOSS a lo largo del primer cuarto de 2008 (lo que no nos han dicho es cuando será oficialmente liberado el SP1 para WSS 3.0 & MOSS).
  • Ya estará incluido en el futuro SP2 (otro anuncio más…).

En cuanto a la instalación en sí de Microsoft Search Server 2008, podemos también recurrir a lo que ahora mismo estoy haciendo: nos lo bajamos del enlace comentado y lo instalamos enla máquina en la que ya tenemos WSS 3.0 & MOSS. Tendremos dos opciones de instalación:



  • Básica, que se encargaría de hacer todas las configuraciones de manera automática: creación del Search Center, creación del Shared Service Provider,…
  • Avanzada, en la que nosotros vamos configurando todo a medida (esta es la opción que he seguido en mi caso y que os enseñaré en el siguiente post sobre esta novedad). Por cierto (justo ahora he acabo la instalación), el resultado a nivel de adminsitración central es que tenemos una parte específica para administrar las configuraciones de búsqueda (con muchas más opciones que en el caso del shared service provider de MOSS):


Y qué novedades trae Microsoft Search Server 2008?


Pues sobre todo los conceptos que giran en torno a Federation y que tiene que ver con la capacidad de Microsoft Search Server 2008 para mostrar resultados procedentes de diversos motores de búsqueda o aplicaciones. Para ello se definen varios elementos clave:



  • Las Federated Search Locations que describen el origen de datos dónde se van a ir a buscar estos. Como os podéis imaginar, se trata de un XML en el que especificas si los datos están en una BD, en otro motor de búsqueda, en Flickr, etc.
  • Los Federated Search Connectors que son los que nos permiten realizar la búsqueda efectiva de los datos en las federated locations. Tanto unos como otros suponen puntos de extensibilidad, es decir, conforme vayamos añadiendo federated locations posiblemente tengamos que crear los conectores correspondientes para las mismas. Como siempre, ya tenemos mucho trabajo hecho y aquí tenéis una galería de conectores disponibles.
  • Location Types soportados, y que son dos:

    • OpenSearch 1.0 / 1.1 (este es un estándar de búsqueda creado por Amazon para sindicación de contenidos), en el que se envía la consulta como un parámentro de url y los resultados tienen que ser devueltos en XML.
    • Local Search index.

  • Federated Web Parts, que permiten separar los resultados por motor de búsqueda, mostrar los top federated results, etc.

¿y qué se puede hacer a nivel de desarrollo ?


Pues de to’ como díria alguno, y como muestra:



  • Personalización: de la UI, de la búsqueda avanzada, el formato de los resultados con XSLT.
  • Consumir la búsqueda: vía el modelo de objetos o los correspondientes servicios web.
  • Escribir IFilters o manejadores de protocolo.
  • Los Federated Search Locations, por ejemplo:

    • Buscar datos en una BD SQL Server.
    • Buscar en sitios que sólo devuelven resultados en HTML (por lo que necesitaremos un conector que permita devolver los resultados en formato XML).


¿y qué más cosas trae Microsoft Search Server 2008?


Pues otros muchos aspectos (qué habrá que ir probando y evaluando) relativos a:



  • Rendimiento y ecalabilidad.
  • Autenticación de acceso.
  • Límites en los índices (400 k para la versión express, 50 M para la versión no gratuita).

El aspecto que tendría el Search Center es el siguiente:



Y hasta aquí lo más novedoso que hasta ahora he visto en el Tech-Ed. La verdad que me ha impresionado el producto y sus capacidades. En el próximo post os realizaré un paso a paso de la instalación (que ha ido como la seda). Espero que el post os haya resultado intersante.