none
Identificar el Objecto o Campo que origina el Flujo de Trabajo

    Pregunta

  • Buenas Tardes tengo una consulta, como puedo hacer para identificar el campo que activa el Flujo de Trabajo.

    actualmente desarrolle un flujo de trabajo que se activa cuando alguno de los campos de la entidad Caso cambia.

    Quisiera saber como puedo hacer para identificar cual de estos campo fue el que cambio.

    Saludos y Muchas Gracias por sus respuestas.

    jueves, 23 de febrero de 2012 19:17

Respuestas

  • Mmmm sin desarrollo creo que no será posible.

    creo que lo mejor sería crearte un "plugin" en donde si que recibes los campos modificados (o utilizando post/pre images).

    un saludo,


    Demian Adolfo Raschkovan Blog: http://crmtoall.blogspot.com

    viernes, 24 de febrero de 2012 13:40
  • Hola, buenos días. En principio los flujos de trabajo cuando más impactan en el rendimiento de la aplicación es cuando tienen condiciones de espera, si tu sólo creas el flujo vacio, con el objetivo de que salga en la lista de flujos asociada a cada Caso, no deberías notar ninguna merma.

    La respuesta de Demian también puede ser una solución, en principio se supone que los lugin dan mejor rendimiento, pero requierenn de más esfuerzo de desarrollo, aparte de que habría que registrarlos en la aplicación, cosa que puede no depender de tí en un entorno de producción, y en mi caso hace año y medio aproximadamente, en una prueba con plugins me encontré que si mantenía abierto el formulario después de guardar cambios en campos determinados, si luego volvía a guardar el formulario modificando campos que el plugin no contemplaba , se disparaba igualmente. En caso de usarlo tienes que ser cuidadoso con las comprobaciones que hagas para detectar en qué campo se da la modificación (y también con el rollup instalado, igual está solucionado).

    De todas formas, si te preocupa el rendimiento de tu aplicación por cómo afecten los flujos de trabajo, es conveniente que regularmente revises el estado de la tabla AsyncOperationBase. Puede llegar a tener un tamaño considerable, lo que retrasará las operaciones con flujos. En este enlace explica cómo limpiarla, y así evitar ciertos problemas de rendimiento del servicio asíncrono: http://support.microsoft.com/kb/968520

    Si tienes CRM 2011 no se si aplica. Otra cosa que tienes que tener en cuenta para el rendimiento, es que si llegas a un momento en que tengas 60 o más usuarios deberías plantear tener más frontales para la aplicación web. Aparte de tener la base de datos en una máquina distinta, e incluso el servicio de procesamiento asíncrono.

    jueves, 15 de marzo de 2012 9:30

Todas las respuestas

  • He estado mirando la tabla de AsyncOperationBase, y lo más que he visto es si el flujo se ha iniciado por creación o actualización, y alguna cosa mas. No sé si habrá alguna forma de relacionarlo con AttributeMapBase, puedes mirar.

    Una forma fácil sería crear flujos independientes para cada uno de los campos y eventos que puedan disparar tu flujo, sin nada dentro, sólo para que salgan en el listado de flujos.

    viernes, 24 de febrero de 2012 10:07
  • Mmmm sin desarrollo creo que no será posible.

    creo que lo mejor sería crearte un "plugin" en donde si que recibes los campos modificados (o utilizando post/pre images).

    un saludo,


    Demian Adolfo Raschkovan Blog: http://crmtoall.blogspot.com

    viernes, 24 de febrero de 2012 13:40
  • Buenos Dias ignacio_camacho de antemano agradezco tu respuesta. en la opcion que me comentas de crear un flujo independiente por cada campo ya la habia pensado, pero la descarte ya que siento que impactaria de forma negativa el rendimiento de la aplicación.

    ya que estamos hablando que serian aproximadamente de 30 a 40 personas, que estarian concurrentemente trabajando y por cada cambio se activaria el flujo. por lo cual sentia que el impacto seria demasiado.

    consulta:

    * Cree usted que el rendimiento no seria afectado si creo un flujo de trabajo por cada campo.

    son 11 campos y un promedio de 35 personas trabajando en el sistema.

    Saludos y Muchas Gracias.

    viernes, 24 de febrero de 2012 13:45
  • Hola, buenos días. En principio los flujos de trabajo cuando más impactan en el rendimiento de la aplicación es cuando tienen condiciones de espera, si tu sólo creas el flujo vacio, con el objetivo de que salga en la lista de flujos asociada a cada Caso, no deberías notar ninguna merma.

    La respuesta de Demian también puede ser una solución, en principio se supone que los lugin dan mejor rendimiento, pero requierenn de más esfuerzo de desarrollo, aparte de que habría que registrarlos en la aplicación, cosa que puede no depender de tí en un entorno de producción, y en mi caso hace año y medio aproximadamente, en una prueba con plugins me encontré que si mantenía abierto el formulario después de guardar cambios en campos determinados, si luego volvía a guardar el formulario modificando campos que el plugin no contemplaba , se disparaba igualmente. En caso de usarlo tienes que ser cuidadoso con las comprobaciones que hagas para detectar en qué campo se da la modificación (y también con el rollup instalado, igual está solucionado).

    De todas formas, si te preocupa el rendimiento de tu aplicación por cómo afecten los flujos de trabajo, es conveniente que regularmente revises el estado de la tabla AsyncOperationBase. Puede llegar a tener un tamaño considerable, lo que retrasará las operaciones con flujos. En este enlace explica cómo limpiarla, y así evitar ciertos problemas de rendimiento del servicio asíncrono: http://support.microsoft.com/kb/968520

    Si tienes CRM 2011 no se si aplica. Otra cosa que tienes que tener en cuenta para el rendimiento, es que si llegas a un momento en que tengas 60 o más usuarios deberías plantear tener más frontales para la aplicación web. Aparte de tener la base de datos en una máquina distinta, e incluso el servicio de procesamiento asíncrono.

    jueves, 15 de marzo de 2012 9:30