Estoy empezando una seria de artículos sobre las formas como he resuelto algunos problemas típicos de implementación de workflows en Sharepoint Designer y de pronto en VS2005/2008.  Estos post no se basan en la tecnología en si misma sino en la solución de un problema. Por lo tanto pueden haber tantas soluciones como programadores / diseñadores de procesos se enfrenten al él. Si usted conoce una forma más inteligente, rápida o recomendada para solucionarlo no deje de enviarme un comentario. 

(No hay que dejar de tener presente que:

a. estas soluciones se enfocan en poder transferir el conocimiento a usuario no desarrolladores y usando solo las herramientas out-of-box disponibles

b.se asume que el usuario ya usa infopath, Sharepoint Designer, Visual Studio 2005 y sharepoint.)

Problema 1. La primera (o la segunda o la n) tarea de un workflow se asigna dinámicamente  dependiendo de información diligenciada por el usuario.

Este es un escenario típico. La organización tiene 50 managers (gerentes) en el formulario hay un campo que identifica el área a la que esta asignada el gasto, la actividad de aprobación del gasto debe asignarse al gerente de esa área.

Solución.

Preparando la fuente de Datos.

1. Cree una lista en Sharepoint llamada _Areas. (el nombre tiene un caracter "_" para ayudarme a identificar las listas que usare como fuentes de datos).

2. En esta lista cree un campo llamado Nombre (string), eMail (String), Cuenta (Usuario/Grupo)

3. En esta lista cree los 50 gerentes.

Conectando la fuente de datos con el formulario.

(en este caso el formulario esta hecho con InfoPath, otros escenarios pueden requerir conectar la entrada de datos con la lista que se creo antes).

1. En InfoPath cree una fuente de datos, en el menu Tools/Data Connections. 

2. adicione una nueva conexión, seleccione la fuente de datos como una lista de Sharepoint.  Busque la lista de areas que creo. Coloque un nombre a la conexion de datos. Listo, si lo edita deberia ver algo como esto:

3. la fuente de datos esta disponible ahora para todo el formulario, seleccione un campo, en este caso manager que es un desplegable que alcanza a verse en la imagen anterior y configure la fuente de datos de ese campo con la conexión que acabo de crear, debería verse algo como esto.

Bien, ahora cuando el usuario diligencie la forma puede seleccionar el gerente que autoriza esto o el área a la que pertenece el gasto en este caso., esta información quedara almacenada como un campo en la librería de documentos de sharepoint asociada a este formulario.  Con esa información ahora podemos tomar decisiones.

Crear Workflow.

Bueno ahora en SP designer se puede usar la opción de nuevo workflow, se selecciona la lista de documentos que sobre la que se quiere correr el workflow (que debe ser la misma que se alimenta del formulario que creamos antes). y se llega a la ventana de asistente de pasos del workflow.

Crear la acción dentro del Paso (Actividad) del Workflow.

Ok, ahora si la solución,

1. Se crea una acción del tipo Set Workflow Variable.

2. Se hace click en workflow variable, se selecciona crear nueva variable, se le puede poner un nombre como PreApproveUser, de tipo string.

3. Se  hace clic en value y en la opción de función, eso abre la ventana de asignación de valores que es ocasionalmente un poco complicada de usar, así que aquí una foto del resultado final y la explicación de que significa esto

i. Se selecciona la lista de la que quiero sacar la información, en este caso _Departments, luego cual es la variable que quiero, AD Name en este caso, luego le digo como quiero obtener esa información, por ejemplo, que cuando el manager de la lista _Departments sea igual al manager de la lista procurement.

ii. a veces es más fácil pensarlo como un select de SQL, seria así:  select AD User from _Departments Where _Departments:Manager = Procurement Manager.

4. así que ahora tengo el nombre del usuario del AD en una variable del workflow llamada PreApproveUser y esa variable puedo usarla para enviar correos, asignar tareas, etc.

5. creo una nueva acción del tipo Collect User Data. Construyo la información que quiero recopilar y le asigno la tarea a la variable PreApproveUser.

6. Como siempre el resultado de la tarea debo asignárselo a una variable del workflow.

7. sigo el proceso....

De esta forma puede resolverse un problema común de desarrollo de procesos con Sharepoint Designer, asignación dinámica de tareas basada en información ingresada por el usuario. También sirve este ejemplo para ilustrar otras cosas interesantes como por ejemplo el uso de fuentes de datos en formularios de sharepoint.

Juan Carlos Peláez

Arquitecto de Software.

visite www.juanpelaez.com

keywords: sharepoint designer, infopath, bpm, problemas comunes workflow, juan pelaez, fuentes de datos en infopath, variables de workflow, wss 3.0, moss 2007.

A continuación el listado de las actividades que desarrollé con Microsoft Latam en 2007. Gracias a Sandra Marín, Jorge Oblitas, Ivanov Cepeda, José Álvarez y todos los miembros de la división de DP de Microsoft Latam que confiaron sus eventos, contenidos y mensajes en mi.  Espero haber estado a la altura y que me sigan invitando.

Juan.

Cámara de Comercio de Bogotá.

Molinos Flor Huila

Grupo Aval

En los últimos días he estado trabajando en procesos y formularios que utilizan las herramientas office de Microsoft, esto es InfoPath para las formas y Sharepoint Designer para los procesos (Workflows)

Aunque todo lo que he venido haciendo se puede lograr en VS2005 con las extensiones para sharepoint (incluso de esta forma se obtiene mayor control de los resultados), uno de los requerimientos específicos era utilizar estas herramientas para poder pasar el conocimiento a usuarios no desarrolladores.

Después de un par de días ya pude realizar el formulario y el proceso, lo publique en el servidor de pruebas y pedí a los usuarios retroalimentación, todo parecía ir bien hasta que tuvieron que realizar sus tareas y se les notifico que no tenían acceso. Luego de verificar todos los permisos en la lista de tareas, los formularios, el gestor de perfiles, el AD, etc. pues nada esto es un bug.  Un par de horas de búsqueda en Internet me trajo esta solución que pongo aquí para que alguien se ahorre un par de horas de la vida.

El Problema.

Un formulario de Infopath, un workflow asociado a la librería de formas, un usuario con permisos limitados,

el usuario puede llenar formas (si)

El usuario puede ingresar a la lista de tareas desde un link (si)

El usuario puede ver el link de editar tarea (si)

El usuario puede editar la tarea (No. Acceso denegado). No se supone que funciones de esta forma.!!!

La Solución

Después de un par de horas de mirar en internet encontré este foro donde lo resolvieron. , para los que les gusta en español, la solución aquí.

Abra el sitio con Sharepoint designer. Clic derecho en el folder workflows, seleccione propiedades., en el tab de seguridad haga clic en el enlace "Manage Permissions using the browser".

Se abrirá una nueva ventana del browser, en mi caso se habían perdido los permisos heredados y mi usuario estaba en un nivel de permisos incorrecto, cambie el nivel de configuración para que volviera a heredar del sitio y listo.

Juan Carlos Peláez

Arquitecto de Software

www.juanpelaez.com  

Keywords: Sharepoint Designer, Workflow, Problemas, Usuario, Tareas, Permisos, Juan Carlos Peláez, Procesos, Formularios, InfoPath, MOSS 2007, WSS 3.0

Cuando se crea un Workflow con Sharepoint Designer se utiliza un asistente, es uno de los argumentos de venta, workflows sin necesidad de código.

La primera pregunta del asistente es esta:

Que le permite a uno determinar la forma como debe arrancar el workflow y su relación con los items de la lista, es decir, si el workflow arranca cuando se crea el item, se modifica o si arranca manualmente.

Bien el problema es que esta pantalla no vuelve a verse nunca más después de este paso (yo nunca la encontré), entonces si hay problemas con el modelo de arranque del workflow se queda uno varado. 

La solución para modificar la forma que arranca el workflow es abrir con un editor de texto el archivo (puede usar el mismo del SPD) como se ve aquí:

luego se pueden modificar estas lineas (eliminandolas), lo que modificará la forma como arranca el workflow de acuerdo con la que se elimine.

<Association
       ListID="{A245AE99-E68F-4500-9B36-6DD167FF676F}"
       TaskListID="{EAE51F29-83F8-4C88-8A36-D9417969E07C}"
       StartManually="true"    'Workflow arranca manual
       StartOnCreate="true"   'Workflow arranca cuando se crea el item
       StartOnChange="true"  'Workflow arranca cuando se cambia el item.
   >

Ahora, todo tiene un porque, la razón por la que me vi enfrentado a esto fue que cree un Workflow, le puso a que se iniciara de forma automática y nada paso, nunca arranco, así que tuve que cambiarlo a inicio manual y una cosa llevo a la otra..., esta fue la solución.

Ahora hoy he encontrado que la razón por la que no pude arrancar mi workflow de forma automática tiene que ver con el SP1 de WSS 3.0 y MOSS 2007. Como se indica aquí.  ( en español en este buen blog de Sharepoint)

Juan Carlos Peláez

Arquitecto de Software.

visite www.juanpelaez.com  

Keywords:  Sharepoint, MOSS2007, WSS3.0, Workflows, Declarative Workflows, Sharepoint Designer, SP1, Juan Carlos Peláez.

Al usar VS2005, una de las cosas con las que se encuentran los usuarios (que vienen de VS2003) es un nuevo modelo de compilación de los proyectos Web. (Web Site Project).   Hay varias diferencias entre un modelo y otro, desde el sitio donde se seleccionan para crear un nuevo proyecto hasta los resultados de compilación. Para muchas cosas esto es muy importante, así que aunque este no es un tema nuevo vuelvo a él para referencia propia y de otros. En el modelo Web Application:

• Toda la aplicación se compila en un solo assembly (dll) que queda en la carpeta bin.
• Todas las referencias, y archivos se relacionan en el archivo del proyecto.
• Todo el proceso de compilación usa MSBuild así que se puede personalizar lo que pasa antes, durante y después de la compilación.

En el Modelo Web Project:Se generan muchos dlls que viven en el directorio bin, es un poco complicado saber para que es cada uno y cual es cual. Para mi entonces la principal diferencia esta relacionada con la compilación, y aquí es donde esto se vuelve importante hoy. (3 años después de VS2005.)

Ahora estoy desarrollando algunos proyectos para Sharepoint 2007, hay muchas opciones pero una interesante es crear una aplicacion asp.net normal, agregar las referencias a Sharepoint y publicarla en el directorio _layouts.

Para hacer esto y que quede bien es obligatorio que el assembly de la aplicación web sea uno solo, es decir que sea un proyecto Web Application. , hay otros escenarios como usar Enterprise services en los que eso del ensamblado único también es importante.

Asi que para mucha gente, esto resulto tan importante que se creo una adición para VS2005 que permite volver a tener los proyectos Web Applications.

A continuación algunas fotos de mi maquina de desarrollo (gracias clo J) que permiten ver las diferencias al momento de creación, los resultados de compilación y el deployment resultante en sharepoint. Cuando se entra a Visual Studio y se selecciona nuevo web site se ve una pantalla como esta:

si se crea una pagina, un botón, una clase, se compila y se publica (Publish) se obtiene algo como esto:

Como pueden ver hay dos dlls, una llamada application Code y Otra llamada App_web_xxxx.dll. Para tener el soporte para Web Applications se puede ir al sitio de Microsoft y rápidamente instalarlo siguiendo estos pasos:

1. Primero Aplicar este parche y
2. Luego descargar el complemento de aqui.

Luego de instalar esto se siguen teniendo los web projects, pero también esta ahora la opcion de web applications, solo que se encuentran en otro lado como se puede ver aquí:  (new Project, Web…)

Y al agregar la misma página, el mismo botón, la misma clase que en el proyecto anterior, compilar y publicar se obtiene esto:

Como se ve una sola dll con el mismo nombre del proyecto. Pues bien, esta dll es la que se puede colocar en el carpeta BIN del directorio virtual del sitio sobre el que se esta creando la aplicación en sharepoint. asi : (En este caso mi aplicación dentro del Sharepoint se llama ProjectServer)

Y las páginas del compilado si quedan en el directorio layouts:

Personalmente me gustan los proyectos que usan webApplications, y hasta el momento no he encontrado ninguna restricción o algo que no pueda hacer, incluso en otro proyecto que usaba Enterprise Services desde una de las clases del Web Site fue perfecto para registrar con facilidad los componentes en la consola de COM+. espero que sea de ayuda.  

Juan Carlos Peláez

MCTS Distributed Applications 

Keywords: VS2005, Sharepoint, Web Application Projects, Web Projects, Sharepoint Applications, Juan Peláez, MCTS Distributed Applications. Build, deploy, Desarrollo para Sharepoint, Consultor en Sharepoint.