2008-08-29 7 views
5

MS CRM Dynamics 4.0 incorpora el motor MS WF. El diseñador integrado permite la creación de flujos de trabajo secuenciales cuyas actividades tienen acceso nativo a entidades de CRM.MS WF flujos de trabajo de máquina de estado y MS CRM Dynamics 4.0

¿Es posible:

  • crear un estado de flujo de trabajo de la máquina exterior de CRM (es decir, en el estudio visual) y la importación en CRM?
  • ¿Este flujo de trabajo tiene acceso a las entidades CRM ?

Respuesta

5
  • NO es posible crear un flujo de trabajo de máquina de estado para su uso en MSCRM.
  • Tampoco es compatible para crear ningún flujo de trabajo fuera de MSCRM e importarlo.
  • Como solución, puede escribir toda la lógica que necesita en una actividad de flujo de trabajo personalizada e importarla a MSCRM y hacer que se llame desde un flujo de trabajo normal.
  • La otra opción es crear una aplicación separada que ejecute un flujo de trabajo de máquina de estado e interactúe con MSCRM a través de los servicios web. Podría (¿necesitaría?) Combinar esto con una actividad de flujo de trabajo personalizada para iniciar procesos.
+1

Aunque no sea compatible, es posible crear un Flujo de trabajo e importarlo en CRM ... – BeardinaSuit

+1

@Mercure Supported es importante por dos motivos. Uno, si algo sale mal, usted sabe que Microsoft podrá ayudar y dos, de modo que las actualizaciones sean fluidas, y con CRM 5 a la vuelta de la esquina es muy importante ahora. –

+0

Estoy de acuerdo. El único punto que quería destacar es que es posible, incluso si no es compatible. – BeardinaSuit

-2

No conozco la respuesta a tu pregunta específica, pero espero que esta información te indique la dirección correcta.

El formato "nativo" para los flujos de trabajo WF es archivos ".xoml". Estos son básicamente idénticos a los archivos XAML, y ambos no son más que formatos genéricos de persistencia para un árbol de objetos .NET. Si puede acceder a los datos guardados que genera el diseñador de Dynamics, debe tener el mismo formato. Si es así, debería poder abrirlo desde el diseñador de Visual Studio.

La clave aquí es que CRM sin dudas define su propio conjunto de actividades personalizadas a las que deberá poder hacer referencia desde dentro del diseñador alternativo. Con un poco de suerte, estos estarán en asambleas con nombres obvios y/o en el GAC.

+0

-1: usos MSCRM WF, pero proporciona cero acceso al XOML que construye, por lo que aunque en teoría podría hacerlo, en realidad no puede hacerlo. Las actividades personalizadas de MSCRM no están en el GAC y están "ocultas" internamente (las versiones anteriores del SDK tenían una forma de encontrarlas, que se ha eliminado para evitar esto). –

Cuestiones relacionadas