Configurar el comportamiento en cascada de la relación de tablas

Puede configurar los comportamientos en cascada de relaciones de uno a varios para preservar la integridad de los datos y automatizar los procesos de negocio. Tanto la API web como el SDK para .NET admiten la configuración del comportamiento en cascada.

Uso de la API web para configurar el comportamiento en cascada

Al trabajar con la API web, se define una relación de uno a varios mediante el tipo de entidad OneToManyRelationshipMetadata. Esta definición incluye el nombre de la tabla intersect para crear y cómo debe aparecer la relación en la aplicación mediante el tipo complejo AssociatedMenuConfiguration, el tipo complejo Label y el tipo complejo LocalizedLabel.

Para obtener más información, consulte Creación de una relación uno a varios mediante la API web.

Uso del SDK para .NET para configurar el comportamiento en cascada

Al usar las CreateOneToManyRequest clases o UpdateRelationshipRequest , incluya una instancia de la clase OneToManyRelationshipMetadata en el cuerpo de la solicitud. En la propiedad CascadeConfiguration de esa clase, use la clase CascadeConfiguration.

La clase CascadeConfiguration o el tipo complejo CascadeConfiguration contiene las propiedades que representan las acciones que se pueden realizar en la tabla a la que se hace referencia en la relación uno a varios. A cada propiedad se le puede asignar uno de los valores de tipo de enumeración CascadeType.

Value Etiqueta de aplicación Description
Activo Poner activa en cascada Realice la acción en todos los registros de tabla de referencia activos asociados con el registro de tabla al que se hace referencia.
Cascada Poner todas en cascada Realice la acción en todos los registros de tabla de referencia asociados con el registro de tabla al que se hace referencia.
NoCascade No poner ninguna en cascada No hacer nada.
RemoveLink Quitar vínculo Quite el valor de la columna de referencia de todos los registros de tabla de referencia asociados con el registro de tabla al que se hace referencia.
Restringir Restringir Impedir que el registro de tabla al que se hace referencia se elimine cuando existan tablas que lo referencien.
UserOwned Poner en cascada las que pertenecen al usuario Realice la acción en todos los registros de tabla de referencia que pertenecen al mismo usuario que el registro de tabla de referencia.

Registros activos considerados para la acción en cascada

Las acciones en cascada en los registros activos solo incluyen registros que tienen un código de estado activo. Los siguientes códigos de estado para estas tablas se consideran activos para las acciones en cascada. Es posible que se usen etiquetas diferentes (distintas de Activas) para este código de estado en tablas diferentes. Cualquier código de estado o estado personalizado con valores distintos de los de la tabla siguiente no se procesa como un registro activo con fines en cascada.

Nombre de la tabla Código de estado 0 Código de estado 1 Código de estado 2 Código de estado 3
Cuenta x
BulkOperation x
BulkOperation x
CampaignResponse x
Contacto x
Correo electrónico x
Fax x
Incidente x
IncidentResolution x
Factura x
Cliente potencial x
Letra x
Crear oportunidad x
OpportunityClose x
OrderClose x
PhoneCall x
SalesOrder x
Tarea x
Todas las tablas personalizadas y actividades personalizadas x
Ofertas x
Contrato x
Cita x
ServiceAppointment x
RecurringAppointmentMaster x

El SDK para la clase CascadeConfiguration de .NET o el tipo complejo CascadeConfiguration de API web contiene las siguientes propiedades que representan las acciones que puede realizar en la tabla a la que se hace referencia en la relación uno a varios.

Acción Description Opciones válidas
Asignar Cambie el propietario del registro de tabla al que se hace referencia o la unidad de negocio. Activo
Cascada
NoCascade
UserOwned
Delete Elimine el registro de tabla al que se hace referencia. Nota: Las opciones para esta acción son limitadas. Cascada
RemoveLink
Restringir
Fusionar Fusionar el registro con otro registro. Nota: Para las tablas a las que se referencia que se pueden combinar, la única opción válida es Cascade. En otros casos, use NoCascade. Cascada
NoCascade
Cambiar primario Consulte Acerca de la acción de cambiar primario más adelante. Activo
Cascada
NoCascade
UserOwned
Compartir Cuando el registro de tabla al que se hace referencia se comparte con otro usuario. Activo
Cascada
NoCascade
UserOwned
Dejar de compartir Cuando se quita el uso compartido del registro de tabla al que se hace referencia. Activo
Cascada
NoCascade
UserOwned

Nota:

Las acciones Asignar, Eliminar, Combinar y Reparent no se ejecutarán en las situaciones siguientes:

  • Si el registro primario original y la acción solicitada contienen los mismos valores. Ejemplo: Intentar desencadenar una Asignación y elegir un contacto que ya sea el propietario del registro.
  • Intentar realizar una acción en un registro primario que ya está ejecutando una acción en cascada

Nota:

Al ejecutar una asignación, los flujos de trabajo o las reglas de negocio que están actualmente activos en los registros se desactivarán automáticamente cuando ocurra la reasignación. El nuevo propietario del registro deberá reactivar el flujo de trabajo o la regla de negocio si desea continuar usándolo.

Acerca de la acción de asignación

Al actualizar el registro primario, la acción de asignación hace que las actualizaciones se realicen en cascada al propietario, a la unidad de negocio propietaria, o a ambos, el propietario y la unidad de negocio, para todos los registros secundarios.

La propiedad de registro permitida en varias unidades de negocio no está habilitada

Cuando no está habilitada la función de permitir la propiedad de registros entre unidades de negocio, no se puede actualizar explícitamente la columna de la unidad de negocio propietaria al cambiar el propietario del registro. En la lista siguiente se muestran los comportamientos en cascada al actualizar el propietario del registro principal.

Si actualiza el propietario:

  • Comportamiento predeterminado de asignación en cascada (todo en cascada)
    • Registrar las actualizaciones para el nuevo propietario
    • La unidad de negocio de registro se actualiza a la unidad de negocio del nuevo propietario
    • Actualizaciones del propietario de los registros secundarios al nuevo propietario
    • La unidad de negocio de registro secundario se actualiza a la unidad de negocio del nuevo propietario
  • Asignación en cascada establecida en Ninguno
    • Registrar las actualizaciones para el nuevo propietario
    • La unidad de negocio de registro se actualiza a la unidad de negocio del nuevo propietario
    • El propietario de los registros secundarios no se actualiza (sin cascada)
    • La unidad de negocio de los registros secundarios no se actualiza automáticamente (sin cascada)

La propiedad de registro permitida en varias unidades de negocio está habilitada

Cuando se habilita permitir la tenencia de registros entre unidades de negocio, es posible actualizar explícitamente la columna de unidad de negocio propietaria al cambiar el propietario del registro. En la lista siguiente se muestran los comportamientos en cascada al actualizar el propietario del registro principal y la unidad de negocio.

Establezca AlwaysMoveRecordToOwnerBusinessUnit en environment database settings o mediante la herramienta OrgDBOrgSettings para Microsoft Dynamics CRM.

  1. Si actualiza el propietario:

    AlwaysMoveRecordToOwnerBusinessUnit = true (valor predeterminado)

    • Comportamiento predeterminado de asignación en cascada (todo en cascada)
      • Registrar las actualizaciones para el nuevo propietario
      • La unidad de negocio de registro se actualiza a la unidad de negocio del nuevo propietario
      • Actualizaciones del propietario de los registros secundarios al nuevo propietario
      • La unidad de negocio de registro secundario se actualiza a la unidad de negocio del nuevo propietario
    • Asignación en cascada establecida en Ninguno
      • Registrar las actualizaciones para el nuevo propietario
      • La unidad de negocio de registro se actualiza a la unidad de negocio del nuevo propietario
      • El propietario de los registros secundarios no se actualiza (sin cascada)
      • La unidad de negocio de los registros secundarios no se actualiza automáticamente (sin cascada)
  2. Si actualiza la unidad de negocio:

    AlwaysMoveRecordToOwnerBusinessUnit = true (valor predeterminado)

    • Comportamiento predeterminado de asignación en cascada (todo en cascada)
      • El propietario del registro no se actualiza
      • La unidad de negocio de registro se actualiza a la nueva unidad de negocio
      • El propietario de los registros secundarios no se actualiza
      • La unidad de negocio de registro secundario se actualiza a la nueva unidad de negocio
    • Asignación en cascada establecida en Ninguno
      • El propietario del registro no se actualiza
      • La unidad de negocio de registro se actualiza a la nueva unidad de negocio
      • El propietario de los registros secundarios no se actualiza
      • La unidad de negocio de los registros secundarios no se actualiza
  3. Si actualiza la unidad de negocio y el propietario:

    AlwaysMoveRecordToOwnerBusinessUnit = true (valor predeterminado)

    • Comportamiento predeterminado de asignación en cascada (todo en cascada)
      • Registrar las actualizaciones para el nuevo propietario
      • Actualización de la unidad de negocio de registros a una nueva unidad de negocio
      • Actualizaciones del propietario de los registros secundarios al nuevo propietario
      • Actualizar la unidad de negocio de los registros secundarios a la nueva unidad de negocio
    • Asignación en cascada establecida en Ninguno
      • Registrar las actualizaciones para el nuevo propietario
      • Actualización de la unidad de negocio de registros a una nueva unidad de negocio
      • No actualizar el propietario de los registros secundarios
      • No actualice la unidad de negocio de los registros secundarios.

Para cambiar los comportamientos en cascada, use la configuración OrgDBSettings AlwaysMoveRecordToOwnerBusinessUnit.

Si establece AlwaysMoveRecordToOwnerBusinessUnit en false, la unidad de negocio de los registros que posee el usuario no se mueve a la unidad de negocio del nuevo usuario.

Establezca AlwaysMoveRecordToOwnerBusinessUnit en environment database settings o mediante la herramienta OrgDBOrgSettings para Microsoft Dynamics CRM.

  1. Si actualiza el propietario:

    AlwaysMoveRecordToOwnerBusinessUnit = falso

    • Comportamiento predeterminado de asignación en cascada (todo en cascada)
      • Registrar las actualizaciones para el nuevo propietario
      • No actualizar la unidad de negocio de registros
      • Actualizaciones del propietario de los registros secundarios al nuevo propietario
      • No actualice la unidad de negocio de los registros secundarios.
    • Asignación en cascada establecida en Ninguno
      • Registrar las actualizaciones para el nuevo propietario
      • No actualizar la unidad de negocio de registros
      • No actualizar el propietario de los registros secundarios
      • No actualice la unidad de negocio de los registros secundarios.
  2. Si actualiza la unidad de negocio:

    AlwaysMoveRecordToOwnerBusinessUnit = falso

    • Comportamiento predeterminado de asignación en cascada (todo en cascada)
      • El propietario del registro no se actualiza
      • La unidad de negocio de registro se actualiza a la nueva unidad de negocio
      • El propietario de los registros secundarios no se actualiza
      • La unidad de negocio de registro secundario se actualiza a la nueva unidad de negocio
    • Asignación en cascada establecida en Ninguno
      • El propietario del registro no se actualiza
      • La unidad de negocio de registro se actualiza a la nueva unidad de negocio
      • El propietario de los registros secundarios no se actualiza
      • La unidad de negocio de los registros secundarios no se actualiza
  3. Si actualiza la unidad de negocio y el propietario:

    AlwaysMoveRecordToOwnerBusinessUnit = falso

    • Comportamiento predeterminado de asignación en cascada (todo en cascada)
      • Registrar las actualizaciones para el nuevo propietario
      • Actualización de la unidad de negocio de registros a una nueva unidad de negocio
      • Actualizaciones del propietario de los registros secundarios al nuevo propietario
      • Actualizar la unidad de negocio de los registros secundarios a la nueva unidad de negocio
    • Asignación en cascada establecida en Ninguno
      • Registrar las actualizaciones para el nuevo propietario
      • Actualización de la unidad de negocio de registros a una nueva unidad de negocio
      • No actualizar el propietario de los registros secundarios
      • No actualice la unidad de negocio de los registros secundarios.

Nota:

Cuando AlwaysMoveRecordToOwnerBusinessUnit = false

Requisitos del privilegio:

  • Se valida el privilegio de propietario del registro principal. Al actualizar el propietario o la unidad de negocio, la validación comprueba que el propietario tiene el privilegio de la unidad de negocio antes de permitir las actualizaciones.
  • Sin embargo, el privilegio de propietario del registro para los registros secundarios no se valida. Puede encontrarse con una situación en la que actualiza la unidad de negocio del registro principal y la unidad de negocio se conecta en cascada a los registros secundarios, el propietario de los registros secundarios pierde el acceso a su registro.

Ejemplo 1

Un registro padre pertenece al propietario 1 de la unidad de negocio A y tiene registros hijos que pertenecen al propietario 2 de la unidad de negocio B. El propietario 1 tiene asignado un rol de seguridad de las unidades de negocio A y B, por lo que puede acceder a los registros hijos. Cuando actualiza el registro principal al propietario 3, el propietario de los registros secundarios también se cambia a propietario 3, pero los registros secundarios siguen perteneciendo a la unidad de negocio B. El propietario 3 no tiene acceso a estos registros secundarios a menos que el propietario tenga un rol de seguridad en la unidad de negocio B.

Ejemplo 2

Un registro principal pertenece al propietario 1 en la unidad de negocio A y tiene registros secundarios que pertenecen al propietario 2 en la unidad de negocio B. Al propietario 1 se le asigna un rol de seguridad de las unidades de negocio A, B y C, por lo tanto, puede acceder a los registros secundarios. Cuando cambia la unidad de negocio propietaria a la unidad de negocio C, la unidad de negocio de los registros secundarios cambia a la unidad de negocio C. El propietario 2 de estos registros secundarios no tendrá acceso a sus registros a menos que al propietario se le asigne un rol de seguridad de la unidad de negocio C.

Acerca de la acción de cambiar primario

La acción de cambiar primario es similar a la acción de compartir, pero se ocupa de los derechos de acceso heredados en lugar de los derechos de acceso explícitos. La acción de cambiar primario es cuando se cambia el valor de la columna de referencia en una relación jerárquica. Cuando se produce una acción reparente, el ámbito deseado de los derechos de acceso heredados podría cambiar para ReadAccess, , WriteAccessDeleteAccess, AssignAccess, ShareAccess, AppendAccessy AppendToAccess para las tablas relacionadas. No cambiará para CreateAccess. Las acciones en cascada relacionadas con la acción reparental hacen referencia a los cambios en los derechos de acceso indicados anteriormente para el registro de tabla y los registros de tabla relacionados con ella.

Acerca de la acción de fusionar

Una acción de combinación puede encontrar problemas al completarse si se elimina un registro que forma parte del conjunto de operaciones mientras se ejecuta el trabajo del sistema de mezcla. A menudo, este problema da lugar a un error que indica que el registro tiene "una relación parental diferente" o que el registro secundario "podría perder su relación parental". Si se produce este problema y prefiere que la combinación continúe incluso si falta el registro, puede optar por deshabilitar la comprobación primaria al seleccionar las columnas que se van a combinar.

Nota:

Al realizar una combinación entre dos tablas personalizadas, los valores dateTime no se combinan. La fecha y hora del registro de destino permanece sin cambios.

Notificación en cascada

Utilice dos mensajes auxiliares de notificación asincrónica en cascada para notificar a un usuario o registrar cuando un trabajo asincrónico en cascada falla o tiene éxito. Para implementar esta solución, escriba y registre un complemento personalizado que se ejecute cuando se procesen esos mensajes y proporcione una notificación correcta o de error.

Los dos mensajes de notificación son:

Name Description
cascadeAsync_FailureAPI Este mensaje se procesa (se ejecuta) cuando un trabajo en cascada asincrónico se detiene debido a varios errores. Use este mensaje para informar a los usuarios de que necesitan revisar su conjunto de datos en busca de problemas con complementos existentes, problemas de datos o problemas de flujo de trabajo.
InputParameters
casadeAsyncExceptionDetails: detalles de la excepción que causa el error del trabajo asincrónico en cascada.
casadeAsyncJobName: Nombre del trabajo asincrónico en cascada.
cascadeAsync_SuccessAPI Este mensaje se procesa (ejecuta) cuando el trabajo en cascada asincrónico se completa con éxito.
InputParameters
casadeAsync_JobName: nombre del trabajo asincrónico en cascada.

Registre el complemento personalizado durante la fase posterior a la operación y establézcalo en modo asincrónico. En la ilustración siguiente se muestra un ejemplo de registro de complemento mediante la herramienta Registro de complementos.

Registrar un complemento para notificación en cascada

Estos son algunos ejemplos del tipo de notificaciones que puede proporcionar el complemento personalizado:

  • Si se ejecuta correctamente, agregue una entrada a un registro en tiempo de ejecución.
  • En caso de error, agregue una entrada a un registro en tiempo de ejecución y envíe un correo electrónico (u otra comunicación) al administrador que indique la fecha y hora y la naturaleza del error.
  • Mostrar un mensaje al usuario interactivo.

Reparar acceso heredado

Después de cambiar el comportamiento en cascada de una relación de tabla para las acciones Reparent o Share a No Cascade, el sistema intenta ajustar los derechos de acceso heredados del usuario para que coincidan con el comportamiento en cascada de la relación de tabla actual. Obtenga más información sobre la limpieza de derechos de acceso heredados.

Sin embargo, si este enfoque no se realiza correctamente, los usuarios pueden conservar el acceso a los registros relacionados que se deben quitar. Para conocer los pasos para solucionar este problema, consulte Limpieza del acceso heredado.

Consulte también

Definiciones de relación de tabla