Depurar flujos de trabajo de SharePoint

Muestra cómo SharePoint ahora se basa en Administrador de flujos de trabajo 1.0 para todo el procesamiento y administración del flujo de trabajo, y muestra las opciones de depuración.

Proporcionado por:Andrew Connell, Voitanos

Nota:

Los flujos de trabajo de SharePoint 2010 se han retirado desde el 1 de agosto de 2020 para los nuevos espacios empresariales y se han quitado de los espacios empresariales existentes el 1 de noviembre de 2020. Si está usando los flujos de trabajo de SharePoint 2010, le recomendamos que migre a Power Automate u otras soluciones compatibles. Para más información, consulte Retirada del flujo de trabajo de SharePoint 2010.

El equipo de flujo de trabajo ha colaborado con el equipo de Azure para crear un producto llamado Administrador de flujos de trabajo. Administrador de flujos de trabajo hospeda la última versión de tiempo de ejecución de Windows Workflow Foundation y todos los servicios necesarios en una forma disponible y escalable. Aprovecha las ventajas de la Microsoft Azure Bus de servicio de rendimiento y escalabilidad y, cuando se implementa, se ejecuta exactamente el mismo en una implementación local como en la nube, similar a Office 365. SharePoint se conecta y configura para transferir toda la ejecución del flujo de trabajo y las tareas relacionadas a la granja de servidores de Administrador de flujos de trabajo.

Este cambio en la arquitectura requiere algunos cambios en las dos herramientas de creación de flujo de trabajo principal (SharePoint Designer 2013 y Visual Studio 2012 ) de los clientes usan para crear flujos de trabajo personalizados. Sin embargo, aún se aplican las técnicas de depuración utilizadas por los programadores de SharePoint 2007 y SharePoint 2010. La nueva arquitectura permite que una nueva opción de flujos de trabajo creados con SharePoint Designer 2013 o Visual Studio 2012 en ese Fiddler pueda utilizarse para supervisar el tráfico entre SharePoint y Administrador de flujos de trabajo.

Información general de depuración de flujo de trabajo de SharePoint

La depuración de flujos de trabajo personalizados creados para SharePoint es similar a las versiones anteriores, incluidas SharePoint 2010 y SharePoint 2007. Algunas opciones de depuración disponibles dependen de la herramienta que se usa para crear el flujo de trabajo (SharePoint Designer 2013 o Visual Studio 2012 ) y el tipo de implementación de SharePoint, como local o Office 365 (hospedado). Hay cuatro técnicas de depuración de flujo de trabajo que se pueden aprovechar los autores de flujo de trabajo:

• Registro de la lista de historial de flujo de trabajo
• Establecer puntos de interrupción
• Envío de mensajes de depuración a la consola
• Supervisar el tráfico entre SharePoint y Administrador de flujos de trabajo con Fiddler

Cada opción tiene ventajas y desventajas. Resulta útil para tener una idea clara de lo que es posible al usar las dos herramientas de creación de flujo de trabajo (SharePoint Designer 2013 o Visual Studio 2012 ), así como el tipo de implementación del flujo de trabajo (local o Office 365 ). En la siguiente tabla contiene una matriz de creación de herramientas, los objetivos de implementación y las opciones disponibles en cada escenario.

Producto	SharePoint local	Office 365 SharePoint Online
SharePoint Designer 2013, SharePoint Online	Registrar en la lista de historial de Fiddler	Registrar en lista de historial
Visual Studio 2012	Registrar en la lista de historial los puntos de interrupción de la consola de mensajes de depuración de Fiddler	Registrar en la lista de historial los puntos de interrupción

Depurar con la lista de historial de flujo de trabajo

La única opción de depuración que está disponible en cada tipo de implementación de SharePoint es escribir mensajes de registro en la lista de historial de flujo de trabajo. Mediante este método, puede usar la acción registrar en lista de historial en SharePoint Designer 2013 o la actividad WriteToHistory en Visual Studio 2012 para escribir un mensaje de cadena como un nuevo elemento a la lista, especificada en la asociación de flujo de trabajo, que es el contenedor para todos los mensajes de registro de historial. Estos pueden ser cadenas simples o se construyen concatenando el contenido de las variables dentro del flujo de trabajo.

Uso de la lista de historial como una herramienta de depuración no es ideal, debido a que los usuarios pueden ver los mensajes. Por lo tanto, cuando finalice la sesión de depuración y el flujo de trabajo se usa en producción, el programador de flujo de trabajo desea quitar estos mensajes, creación de un paso adicional entre la implementación y depuración. Sin embargo, esta es la única opción disponible en cualquier escenario, independientemente de la herramienta que use para crear el flujo de trabajo o el tipo de implementación de SharePoint.

Depuración con puntos de interrupción de Visual Studio 2012

Otra opción de depuración consiste en aprovechar las ventajas de los puntos de interrupción. Los puntos de interrupción sólo están disponibles para los flujos de trabajo creados mediante Visual Studio 2012, ya que SharePoint Designer 2013 no cuenta con capacidad para establecer puntos de interrupción o para asociar a un depurador al proceso en ejecución. Están disponibles tanto en SharePoint local como en implementaciones hospedadas, como Office 365. En este escenario, podría establecer un punto de interrupción en una actividad en el flujo de trabajo y, a continuación, iniciar el flujo de trabajo en modo de depuración.

Figura 1. Iniciar el flujo de trabajo

Visual Studio se implementar el flujo de trabajo en el entorno de SharePoint de destino y se adjunta a un depurador. Cuando el proceso de flujo de trabajo alcance la actividad que es el punto de interrupción establecido en, Visual Studio recupera el foco y le permite examinar los valores de variables de flujo de trabajo y paso a través de cada actividad de Visual Studio 2012, como se muestra en la ilustración siguiente.

Figura 2. Punto de interrupción de flujo de trabajo

Depurar flujos de trabajo con mensajes de depuración y el host de servicio de prueba

La introducción del administrador de flujos de trabajo en el flujo de trabajo de SharePoint introduce dos nuevas oportunidades de depuración disponibles cuando se crean flujos de trabajo personalizados con Visual Studio 2012 y se prueban en una implementación local. Visual Studio 2012 incluye una actividad WriteLine que acepta un único mensaje basado en cadenas como entrada.

Figura 3. Actividad WriteLine

Esta actividad escribirá el mensaje que se asemeja al método System.Diagnostics.Debug.WriteLine() en una aplicación de consola de Windows.NET estándar. La herramienta de desarrollo del administrador de flujos de trabajo 1.0 incluye una utilidad de consola que se denomina host de servicio de prueba que Visual Studio 2012 abrirá cuando se inicie una nueva sesión de depuración y cuando se pruebe con una implementación local de SharePoint. Esta utilidad de consola, Microsoft.Workflow.TestServiceHost.exe encuentra en C:\Archivos de programa (x86)\Administrador de flujos de trabajo Tools\1.0, se asocia a la instancia de Administrador de flujos de trabajo registrada y escucha los mensajes escritos mediante la actividad WriteLine, como se muestra en la ilustración siguiente.

Figura 4. Mensajes para actividad WriteLine

Estos mensajes se parecen a los comentarios de código o depuración los mensajes en una aplicación de consola. A diferencia de escritura en la lista de historial de flujo de trabajo, no es necesario quitar estos antes de implementar el flujo de trabajo a la producción. A menos que la utilidad de Test Service Host está conectada a Administrador de flujos de trabajo, los mensajes son inocuos.

Esta opción de depuración no está disponible para flujos de trabajo creados con SharePoint Designer 2013, porque no hay ninguna acción que se asigna a la actividad WriteLine. Por desgracia, esta opción de depuración solo está disponible en las instalaciones locales de SharePoint, ya que el puerto que usa la utilidad de host de servicio de prueba no suele ser accesible de forma pública fuera de una red local. Esto también es cierto para Office 365. Los puertos que SharePoint usa para conectarse a Administrador de flujos de trabajo son los mismos que utiliza el host del servicio de prueba y, a continuación, esos sólo son accesibles dentro de la red de confianza. Sin embargo, esto no significa que deba cambiar sus flujos de trabajo para quitar cualquier actividades WriteLine antes de la implementación para Office 365. Estas actividades pueden dejarse en el flujo de trabajo como no se ven a menos que el Host de servicio de prueba está conectado a Administrador de flujos de trabajo.

Depuración con Fiddler para supervisar el tráfico HTTP

La última opción de depuración de flujos de trabajo de SharePoint es una novedad para desarrolladores de flujo de trabajo debido al cambio en cómo se administran los flujos de trabajo en la plataforma actual. Recuerde que, en SharePoint, todo el procesamiento de flujo de trabajo se entrega a un producto externo, el Administrador de flujos de trabajo 1.0. Cuando tiene un flujo de trabajo para comunicarse con SharePoint, como actualizar el estado actual del flujo de trabajo, la recopilación de datos de usuarios o elementos en un sitio de SharePoint, o cuando se trabaja con tareas, las actividades del Administrador de flujo de trabajo utiliza la API de REST de SharePoint para realizar estas operaciones. SharePoint se comunica con Administrador de flujos de trabajo mediante una biblioteca de cliente que actúa como un proxy para servicios REST expuestos por el Administrador de flujos de trabajo. Tanto SharePoint como el administrador de flujos de trabajo se comunican entre sí mediante los protocolos estándar HTTP y HTTPS.

Esta arquitectura da como resultado una nueva opción de depuración para los autores de flujo de trabajo. Mediante el uso de la herramienta de proxy HTTP depuración Fiddler, puede supervisar cada solicitud y respuesta correspondiente entre los dos productos. Además, los servicios personalizados llama los flujos de trabajo personalizados con la actividad HttpSend en Visual Studio 2012 o acción Call HTTP Web Service correspondiente en SharePoint Designer 2013 también se pueden supervisar e inspeccionado por Fiddler. Este modelo de depuración también está disponible, independientemente de la herramienta que se usa para crear flujos de trabajo personalizados (SharePoint Designer 2013 o Visual Studio 2012 ).

La única vez que esta opción no está disponible es cuando se está probando flujos de trabajo con una implementación de Office 365 de SharePoint. Puesto que todo el tráfico entre SharePoint y Administrador de flujos de trabajo se produce del lado servidor, no es posible conectarse a uno de los servidores en Office 365 e iniciar Fiddler desde la consola.

Esta nueva opción le ofrece transparencia y conocimientos sobre el motor de flujo de trabajo que no era posible al desarrollar flujos de trabajo en versiones anteriores de SharePoint antes de SharePoint.

Por ejemplo, puede ver las respuestas sin procesar que regresan desde Administrador de flujos de trabajo o SharePoint en una llamada de servicio web. En ocasiones, es posible que el administrador de flujos de trabajo responda con un mensaje de error específico. SharePoint incluye mensajes de error descriptivos, pero es posible que no sean suficientemente específicos. Usar Fiddler, puede ver el mensaje de error exacto devuelto como ayuda para solucionar el problema.

Otro caso de uso está examinando la respuesta de una llamada al servicio web correcta. Cuando se trabaja con los servicios web en flujos de trabajo, independientemente de la herramienta de edición, que debe conocer el nombre de la propiedad exacta (y la ruta de acceso si es una respuesta compleja) para un valor que se encuentra en una respuesta. Mediante el uso de Fiddler, puede ver los datos de la respuesta completa.

Información sobre SharePoint y el administrador de flujos de trabajo para depurar con Fiddler

Para depurar flujos de trabajo en SharePoint y Administrador de flujos de trabajo 1.0 con Fiddler, algunos pasos para el programa de instalación y configuración debe realizarse en un entorno de desarrollador antes de la depuración. Antes de completar los pasos, resulta útil tener una idea clara de cómo funciona Fiddler y cómo funcionan los flujos de trabajo en SharePoint.

Fiddler solo puede inspeccionar el tráfico desde el servidor local

El único tráfico que Fiddler puede interceptar e inspeccionar son las solicitudes que se originan desde el servidor local donde se inició Fiddler. Esto puede suponer un reto cuando Fiddler se usa como una herramienta de depuración de flujos de trabajo de SharePoint.

Si SharePoint y Administrador de flujos de trabajo 1.0 están instalados en servidores diferentes y Fiddler se inicia desde SharePoint Server, el único tráfico que mostrará Fiddler es el tráfico donde se originó la solicitud de SharePoint. Ninguna parte del tráfico procedente de Administrador de flujos de trabajo 1.0, incluso si está destinada a SharePoint Server, se interceptará.

Por lo tanto, al desarrollar flujos de trabajo, es más fácil depurarlos si SharePoint y Administrador de flujos de trabajo 1.0 están instalados en el mismo servidor. Tenga en cuenta que esto no es un requisito; puede iniciar Fiddler en los servidores de la SharePoint Server y el Administrador de flujos de trabajo, aunque es más complejo para supervisar dos instancias en dos servidores para el mismo proceso de flujo de trabajo.

Fiddler solo puede inspeccionar el tráfico del usuario que ha iniciado sesión

Fiddler sólo puede interceptar e inspeccionar el tráfico desde el usuario ha iniciado la sesión actual. Para ver el tráfico que se originó en SharePoint, debe iniciar sesión para SharePoint Server con la cuenta de Windows que está configurada como la identidad del grupo de aplicaciones que hospeda la aplicación web para el sitio de SharePoint que se inicia el flujo de trabajo.

Lo mismo pasa con Administrador de flujos de trabajo. Para interceptar e inspeccionar el tráfico que se origina en Administrador de flujos de trabajo, debe iniciar sesión en el servidor con la identidad de Windows que se configuran durante el aprovisionamiento de la granja de servidores de Administrador de flujos de trabajo como la cuenta de servicio para Administrador de flujos de trabajo.

Al utilizar Fiddler para depurar flujos de trabajo, es más fácil de depurarlos si no solo Administrador de flujos de trabajo y SharePoint están instalados y configurados en el mismo servidor, pero también usan la misma identidad de Windows como cuenta de servicio. Fiddler puede interceptar e inspeccionar todo el tráfico del Administrador de flujos de trabajo y de SharePoint.

SharePoint debe confiar en el certificado de Fiddler

Antes de usar Fiddler para depurar flujos de trabajo de SharePoint, debe comprender cómo se controla el tráfico cifrado. Tráfico cifrado sobre HTTP, conocido como HTTPS, se implementa mediante el uso de la clave privada de un certificado para cifrar algunos datos y, a continuación, enviarlo a otro destinatario. El destinatario tiene la clave del certificado público que se corresponde con la clave privada. Cuando se recibe una solicitud para el destinatario, el destinatario puede validar que la solicitud procede del remitente como firma del contenido cifrado coincide con la clave pública, que sólo puede ser true si se cifró con la clave privada del certificado.

Fiddler puede interceptar tráfico HTTPS y configurarse para poder descifrarlo por lo que resulta en un formato legible para la inspección en la herramienta. Después de mostrar la solicitud, Fiddler, a continuación, utiliza su propio certificado para volver a cifrar el tráfico y enviarlo al destinatario previsto. Sin embargo, esto puede causar un problema, ya que ahora el destinatario ha recibido la respuesta original, pero no está protegido mediante el certificado del remitente original. Esto puede ser un problema al depurar flujos de trabajo de SharePoint debido a que SharePoint no confía en los certificados de Fiddler. Por lo tanto, para usar Fiddler para interceptar e inspeccionar el tráfico HTTPS entre SharePoint y el administrador de flujos de trabajo, el certificado de Fiddler debe ser de confianza para SharePoint.

Configurar SharePoint y administrador de flujo de trabajo 1.0 para la depuración de flujo de trabajo con Fiddler

En las secciones siguientes, se explica cómo configurar Fiddler y SharePoint para la depuración de flujo de trabajo.

Configurar las opciones de proxy predeterminadas de .NET Framework

El primer paso es definir, en primer lugar, la configuración de proxy predeterminada para .NET Framework. Estos cambios permitirán a Fiddler interceptar el tráfico procedente de SharePoint y el Administrador de flujos de trabajo. Abra el archivo machine.config en ambas de las siguientes ubicaciones:

• %systemdrive%\\Windows\\Microsoft.NET\\Framework\\v4.0.30319\\Config\\machine.config
• %systemdrive%\\Windows\\Microsoft.NET\\Framework64\\v4.0.30319\\Config\\machine.config

A continuación, agregue el marcado siguiente a la parte inferior de cada archivo, justo antes del elemento de configuración> de cierre<:

<system.net>
  <defaultProxy enabled="true">
    <proxy bypassonlocal="false" usesystemdefault="true" />
  </defaultProxy>
</system.net>

Guarde los cambios y cierre los archivos.

Configurar Fiddler para interceptar e inspeccionar el tráfico HTTPS

El siguiente paso es configurar Fiddler para interceptar tráfico cifrado y descifrarlo para la configuración.

1. Inicie Fiddler.
2. Si usa el archivo HOSTS local, asegúrese de que las entradas se incluyen en Fiddler seleccionando la opción de menú Herramientas -> HOSTS .
3. Active Habilitar reasignación de solicitudes de un host a otro host o IP, invalidación de DNS,
4. Haga clic en el Archivo de Hosts de Windows de importación y, a continuación, haga clic en el botón Guardar.

Figura 5. Reasignación de host

A continuación, configure las opciones de conexión de Fiddler.

1. Seleccione la opción de menú Herramientas -> Opciones de Fiddler .

2. Haga clic en la ficha conexiones.

3. Desactive la selección de cadena para el proxy de puerta de enlace ascendente.

4. Seleccione las opciones de actuar como proxy del sistema en el inicio y supervisar todas las conexiones, tal como se muestra en la ilustración siguiente.

   

5. Seleccione la ficha HTTPS en el cuadro de diálogo Opciones de Fiddler.

6. Compruebe la captura CONNECTs HTTPS.

7. Seleccione descifrar tráfico HTTPS.

8. Seleccione ??? de todos los procesos.

9. Comprobación de errores de certificado de servidor de omitir.

10. Haga clic en el botón Exportar certificado raíz al escritorio.

11. Cuando se le solicite una advertencia, haga clic en Sí para Confiar en el certificado raíz de Fiddler.

Este proceso va a configurar Windows para que confíe en el certificado, aunque SharePoint no confía en él todavía.

Figura 7. Pestaña HTTPS

Nota:

Si una alerta de seguridad aparece con un mensaje que le indica que no confíe en el certificado de Fiddler, haga clic en Sí para continuar instalando el certificado.

Configurar SharePoint para confiar en el certificado

El último paso es configurar SharePoint para confiar en el certificado de Fiddler que se exportó en el paso anterior.

1. Inicie sesión como un administrador de la granja de servidores de SharePoint.

2. Inicie el Shell de administración de SharePoint.

3. Cargar el complemento de SharePoint.

   Add-PSSnapIn Microsoft.SharePoint.PowerShell
   

4. Use la utilidad de certificado para instalar el certificado de Fiddler.

   $fidderCertificatePath = [full path to exported FiddlerRoot.cer certificate file]
   certutil.exe -addstore -enterprise -f -v root $fidderCertificatePath
   $fiddlerCertificate = Get-PfxCertificate -FilePath $fidderCertificatePath
   New-SPTrustedRootAuthority -Name "Fiddler" -Certificate $fiddlerCertificate
   

5. Ejecute IISRESET para asegurarse de que SharePoint recoge el cambio de confianza de certificado.

Tutorial: Depurar un flujo de trabajo de SharePoint con Fiddler

Este sencillo tutorial muestra cómo usar Fiddler para depurar un flujo de trabajo de SharePoint creado con Visual Studio 2012. Cuando se inicia el flujo de trabajo, recupera un ID de cliente de un campo en una lista personalizada. Este identificador de cliente se usa para consultar un servicio públicamente accesible y recuperar detalles adicionales acerca del cliente. Luego, utiliza estos valores para actualizar el elemento de la lista original. El flujo de trabajo se puede encontrar en el siguiente ejemplo de código de MSDN: Flujo de trabajo de SharePoint: llamar a un servicio web externo.

Este tutorial tiene los siguientes requisitos previos:

• SharePoint y Administrador de flujos de trabajo 1.0 instalados en el mismo servidor.

• La identidad de Windows CONTOSO\SP_Content está configurada para la identidad del grupo de aplicaciones que hospeda la aplicación web que sirve al sitio de SharePoint que inicia el flujo de trabajo.

• El sitio de SharePoint que se usa para iniciar el flujo de trabajo es http://intranet.contoso.com

• El extremo de la granja de servidores de Administrador de flujos de trabajo 1.0 es w15sp.contoso.com.

• SharePoint y Administrador de flujos de trabajo 1.0 están configurados para permitir OAuth sobre HTTP.

  Precaución

  Nunca debe realizarse en el servidor de producción, pero sólo para pruebas y depuración.

1. Inicie sesión en el servidor que tenga instalado el Administrador de flujo de trabajo y SharePoint con la identidad de Windows configurada como la cuenta de granja de servidores de Administrador de flujos de trabajo 1.0 y la identidad del grupo de la aplicación de SharePoint.

2. Inicie Fiddler. Mientras Fiddler ahora interceptar tráfico del usuario actual, si hay conexiones existentes o procesos que se ejecutan, Fiddler podría pasar por alto los que no se ejecuten cuando inicialmente se han establecido las conexiones. Para forzar que el Administrador de flujo de trabajo y servidor de SharePoint para reciclaje y el tráfico entre sí se intercepten por Fiddler, reciclaje SharePoint ejecutando IISRESET y reciclaje Workflow Manager al detener e iniciar el servicio de Windows Workflow Manager back-end. Esto puede realizarse con los dos comandos siguientes en un símbolo del sistema administrativo.

   IISRESET
   net stop WorkflowServiceBackend
   net start WorkflowServiceBackend
   

3. Iniciar el flujo de trabajo

En la figura siguiente, tenga en cuenta que las sesiones #18-36 se originaron en SharePoint y las sesiones #37-43 se originaron en Administrador de flujos de trabajo.

Figura 8. Iniciando la instancia de flujo de trabajo

Observe que en la sesión #36, SharePoint solicita que Administrador de flujos de trabajo inicie un flujo de trabajo (que se indica como [A] en la figura) y Administrador de flujos de trabajo responde (que se indica como [B] en la figura) con un mensaje de "Correcto":

Figura 9. Respuesta de mensaje "Correcto"

Sesión #40 es donde Administrador de flujos de trabajo consiste en recuperar el identificador de elemento de lista y el GUID de SharePoint.

Figura 10. Recuperación del identificador del elemento y el GUID

Sesión #43 es donde Administrador de flujos de trabajo es actualizar el elemento de lista de SharePoint con un nuevo valor para el campo del cuerpo del elemento de anuncio al pasar un objeto de Notación de objetos de JavaScript (JSON) (indicado como [A] en la ilustración) a lo largo de como la carga. SharePoint responde con un estado HTTP de 204, que indica que ha procesado correctamente la solicitud, pero no hay ningún mensaje en la respuesta.

Figura 11. Actualizando el elemento de la lista

Conclusión

La historia del flujo de trabajo en la versión de SharePoint Server 1.0 introdujo una nueva capa de abstracción, Administrador de flujos de trabajo 1.0. Esta nueva arquitectura cambia cómo se procesan los flujos de trabajo. SharePoint ahora se basa en Administrador de flujos de trabajo 1.0 para todo el procesamiento de flujo de trabajo y administración.

Una tarea que tiene que realizar cuando crea aplicaciones personalizadas y procesos empresariales en flujos de trabajo es depurar el trabajo. La nueva arquitectura de flujo de trabajo de SharePoint ofrece las mismas opciones de depuración existentes en versiones anteriores de SharePoint. Sin embargo, la nueva arquitectura ofrece dos opciones nuevas cuando se crean flujos de trabajo personalizados con la nueva arquitectura. En este artículo se explican las opciones de depuración heredadas, así como las nuevas opciones de uso de la actividad de WriteLine y el uso de Fiddler para interceptar e inspeccionar el tráfico entre SharePoint y Administrador de flujos de trabajo 1.0.

Consulte también

• Fiddler