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. La API web y SDK para .NET son compatibles con la configuración del comportamiento en cascada.
Uso de la API web para configurar el comportamiento en cascada
Si trabaja con la API web, puede definir una a varias relaciones de uno a varios usando el tipo de entidad OneToManyRelationshipMetadata. Esta definición incluye el nombre de la tabla de intersección que se creará, así como la forma en que la relación debería mostrarse en la aplicación utilizando el tipo complejo AssociatedMenuConfiguration, tipo complejo Label y tipo complejo LocalizedLabel.
Más información: Crear una relación de uno a varios mediante la API web.
Uso de SDK para .NET para configurar el comportamiento en cascada
Cuando se usan las clases CreateOneToManyRequest o UpdateRelationshipRequest, se incluye una instancia de una clase OneToManyRelationshipMetadata en el cuerpo de la solicitud. En la propiedad CascadeConfiguration de esa clase, se usa 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 de uno a varios. A cada propiedad se le puede asignar uno de los valores de tipo de enumeración CascadeType.
| valor | Etiqueta de aplicación | Descripción |
|---|---|---|
| Activas | Poner los elementos activos 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 | Desvincular artículo | 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 | Impida que el registro de tabla de referencia se elimine cuando existen tablas de referencia. |
| 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 acción en cascada
Las acciones en cascada en registros activos solo incluirán registros que tengan un código de estado de "Activo". Los siguientes códigos de estado para estas tablas se consideran activos para las acciones en cascada. Se pueden usar diferentes etiquetas (distintas de Activo) para este código de estado en diferentes tablas. Cualquier estado personalizado o código de estado con valores distintos a los de la tabla siguiente no se procesarán como un registro activo para asignación en cascada.
| Nombre de 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 | |||
| Responsabilidad de Campaña | x | |||
| CONTACTO | x | |||
| Correo electrónico | x | |||
| Fax | x | |||
| Incidente | x | |||
| Resolución de incidentes | x | |||
| Factura | x | |||
| Cliente potencial | x | |||
| Carta | x | |||
| Oportunidad | x | |||
| Oportunidad de cerrar | x | |||
| Pedido cerrado | x | |||
| Teléfono | x | |||
| Pedido de venta | x | |||
| Tarea | x | |||
| Todas las tablas personalizadas y actividades personalizadas | x | |||
| Ofertas | x | |||
| Contrato | x | |||
| Cita | x | |||
| Cita de servicio | x | |||
| Maestro recurrente de la cita | x |
El SDK para .NET clase CascadeConfiguration o API web tipo complejo CascadeConfiguration contiene las siguientes propiedades que representan las acciones que se pueden realizar en la tabla a la que se hace referencia en la relación de uno a varios.
| Acción | Descripción | Opciones válidas |
|---|---|---|
| Asignar | Se cambia el propietario del registro de la tabla de referencia o la unidad de negocio. | Activas Cascada NoCascade UserOwned |
| Delete | Se elimina el registro de tabla al que se hace referencia. Nota: Las opciones para esta acción son limitadas. | Cascada RemoveLink Restringir |
| Combinar | El registro se combina 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. | Activas Cascada NoCascade UserOwned |
| Uso compartido | Cuando el registro de tabla al que se hace referencia se comparte con otro usuario. | Activas Cascada NoCascade UserOwned |
| Dejar de compartir | Cuando se quita el uso compartido del registro de tabla al que se hace referencia. | Activas Cascada NoCascade UserOwned |
Nota
Las acciones Asignar, Eliminar, Combinar y Cambiar primario no se ejecutarán en las siguientes situaciones:
- 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
La acción de asignación permite que las actualizaciones del propietario, de la unidad de negocio propietaria o tanto del propietario como de la unidad de negocio se distribuyan en cascada a todos los registros secundarios cuando se actualiza el registro principal.
La propiedad de registro permitida en varias unidades de negocio no está habilitada
Cuando la opción permitir la propiedad de registros en todas las unidades de negocio no está habilitada, la columna Unidad de negocio propietaria no se puede actualizar explícitamente al cambiar el propietario del registro. A continuación, se enumeran los comportamientos en cascada cuando se actualiza el propietario del registro principal.
Si actualiza el propietario:
- Comportamiento predeterminado de asignación en cascada (todo en cascada)
- El propietario del registro se actualiza al nuevo propietario
- La unidad de negocio de registro se actualiza a la unidad de negocio del nuevo propietario
- El propietario del registro secundario se actualiza 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
- El propietario del registro se actualiza al 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 está actualizado (sin cascada)
- La unidad de negocio de los registros secundarios no está actualizado (sin cascada)
La propiedad de registro permitida en varias unidades de negocio está habilitada
Cuando la opción permitir la propiedad de registros en todas las unidades de negocio está habilitada, la columna Unidad de negocio propietaria no se puede actualizar explícitamente al cambiar el propietario del registro. A continuación, se enumeran los comportamientos en cascada cuando se actualiza el propietario y la unidad de negocio del registro principal.
AlwaysMoveRecordToOwnerBusinessUnit se puede instalar en la configuración de la base de datos del entorno y también se puede configurar con la herramienta OrgDBOrgSettings para Microsoft Dynamics CRM.
Si actualiza el propietario:
AlwaysMoveRecordToOwnerBusinessUnit = true (predeterminado)
- Comportamiento predeterminado de asignación en cascada (todo en cascada)
- El propietario del registro se actualiza al nuevo propietario
- La unidad de negocio de registro se actualiza a la unidad de negocio del nuevo propietario
- El propietario del registro secundario se actualiza 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
- El propietario del registro se actualiza al 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 está actualizado (sin cascada)
- La unidad de negocio de los registros secundarios no está actualizado (sin cascada)
- Comportamiento predeterminado de asignación en cascada (todo en cascada)
Si actualiza la unidad de negocio:
AlwaysMoveRecordToOwnerBusinessUnit = true (predeterminado)
- Comportamiento predeterminado de asignación en cascada (todo en cascada)
- El propietario del registro no está actualizado
- La unidad de negocio de registro se actualiza a la nueva unidad de negocio
- El propietario de los registros secundarios no está actualizado
- 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 está actualizado
- La unidad de negocio de registro se actualiza a la nueva unidad de negocio
- El propietario de los registros secundarios no está actualizado
- La unidad de negocio de los registros secundarios no está actualizado
- Comportamiento predeterminado de asignación en cascada (todo en cascada)
Si actualiza la unidad de negocio y el propietario:
AlwaysMoveRecordToOwnerBusinessUnit = true (predeterminado)
- Comportamiento predeterminado de asignación en cascada (todo en cascada)
- El propietario del registro se actualiza al nuevo propietario
- La unidad de negocio de registro se actualiza a la nueva unidad de negocio
- El propietario del registro secundario se actualiza al nuevo propietario
- 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 se actualiza al nuevo propietario
- La unidad de negocio de registro se actualiza a la nueva unidad de negocio
- El propietario de los registros secundarios no está actualizado
- La unidad de negocio de los registros secundarios no está actualizado
- Comportamiento predeterminado de asignación en cascada (todo en cascada)
Cambie los comportamientos en cascada con OrgDBSettings AlwaysMoveRecordToOwnerBusinessUnit
Puede configurar AlwaysMoveRecordToOwnerBusinessUnit a false. La unidad de negocio de los registros del usuario propietario no se mueve a la unidad de negocio del nuevo usuario.
AlwaysMoveRecordToOwnerBusinessUnit se puede instalar en la configuración de la base de datos del entorno y también se puede configurar con la herramienta OrgDBOrgSettings para Microsoft Dynamics CRM.
Si actualiza el propietario:
AlwaysMoveRecordToOwnerBusinessUnit = false
- Comportamiento predeterminado de asignación en cascada (todo en cascada)
- El propietario del registro se actualiza al nuevo propietario
- La unidad de negocio del registro no está actualizada
- El propietario del registro secundario se actualiza al nuevo propietario
- La unidad de negocio de los registros secundarios no está actualizado
- Asignación en cascada establecida en Ninguno
- El propietario del registro se actualiza al nuevo propietario
- La unidad de negocio del registro no está actualizada
- El propietario de los registros secundarios no está actualizado
- La unidad de negocio de los registros secundarios no está actualizado
- Comportamiento predeterminado de asignación en cascada (todo en cascada)
Si actualiza la unidad de negocio:
AlwaysMoveRecordToOwnerBusinessUnit = false
- Comportamiento predeterminado de asignación en cascada (todo en cascada)
- El propietario del registro no está actualizado
- La unidad de negocio de registro se actualiza a la nueva unidad de negocio
- El propietario de los registros secundarios no está actualizado
- 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 está actualizado
- La unidad de negocio de registro se actualiza a la nueva unidad de negocio
- El propietario de los registros secundarios no está actualizado
- La unidad de negocio de los registros secundarios no está actualizado
- Comportamiento predeterminado de asignación en cascada (todo en cascada)
Si actualiza la unidad de negocio y el propietario:
AlwaysMoveRecordToOwnerBusinessUnit = false
- Comportamiento predeterminado de asignación en cascada (todo en cascada)
- El propietario del registro se actualiza al nuevo propietario
- La unidad de negocio de registro se actualiza a la nueva unidad de negocio
- El propietario del registro secundario se actualiza al nuevo propietario
- 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 se actualiza al nuevo propietario
- La unidad de negocio de registro se actualiza a la nueva unidad de negocio
- El propietario de los registros secundarios no está actualizado
- La unidad de negocio de los registros secundarios no está actualizado
- Comportamiento predeterminado de asignación en cascada (todo en cascada)
Nota
Cuando AlwaysMoveRecordToOwnerBusinessUnit = false
Requisitos del privilegio:
- Se valida el privilegio de propietario del registro principal. Cuando actualiza el propietario o la unidad de negocio, validamos que el propietario tenga 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 está validado. Puede encontrarse con una situación en la que actualizó 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 podría perder el acceso a su registro.
Ejemplo 1
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 y B y, por lo tanto, puede acceder a los registros secundarios. Cuando el registro principal se actualiza 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 tendrá 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 y, por lo tanto, puede acceder a los registros secundarios. Cuando la unidad de negocio propietaria se cambia a la unidad de negocio C, la unidad de negocio de los registros secundarios se 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 de cambiar primario, es posible que cambie el ámbito deseado de los derechos de acceso de heredados para las tablas pueda cambiar para ReadAccess, WriteAccess, DeleteAccess, AssignAccess, ShareAccess, AppendAccess y AppendToAccess. No cambiará para CreateAccess. Las acciones en cascada relacionadas con la acción de cambiar primario hacen referencia a los cambios para los derechos de acceso indicados más arriba para el registro de tabla y cualquier registro de tabla relacionado con él.
Acerca de la acción de fusionar
La acción de fusión a veces puede tener problemas para completarse si se elimina un registro que forma parte del conjunto de la operación mientras se está ejecutando el trabajo del sistema de fusión. A menudo, esto dará como resultado un error que indica que el registro tendrá "uno primario diferente" o que el registro secundario "podría perder su primario". Si esto ocurre, y prefiere que la fusión continúe hacia adelante incluso si falta el registro, puede optar por deshabilitar la comprobación de primario cuando seleccione las columnas a fusionar.
Nota
Al realizar una fusión entre dos tablas personalizadas, los valores de DateTime no se fusionarán. El valor DateTime del registro de destino permanecerá sin cambios.
Notificación en cascada
Puede utilizar dos mensajes auxiliares de notificación asíncrona en cascada para proporcionar una notificación a un usuario o un registro cuando un trabajo asincrónico en cascada falla o tiene éxito. Esto se logra escribiendo y registrando un complemento personalizado que se ejecuta cuando se procesan esos mensajes y proporciona una notificación de éxito o falla.
Los dos mensajes de notificación son:
| Name | Description |
|---|---|
cascadeAsync_FailureAPI |
Este mensaje se procesa (ejecuta) cuando un trabajo en cascada asincrónico se detiene debido a múltiples fallos. Esto se puede usar para informar a los usuarios 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. |
El complemento personalizado debe registrarse durante la etapa posterior a la operación y debe configurarse en modo asíncrono. La siguiente figura muestra un ejemplo de registro de complemento utilizando la herramienta Registro de complemento.
Algunos ejemplos del tipo de notificaciones que puede proporcionar su complemento personalizado son los siguientes:
- Si tiene éxito, agregue una entrada a un registro en tiempo de ejecución
- En caso de error, agregue una entrada a un registro de tiempo de ejecución y luego envíe un correo electrónico (u otra comunicación) al Administrador indicando la fecha / hora y la naturaleza de la falla
- Mostrar un mensaje interactivo al usuario
Reparar acceso heredado
Después de cambiar el comportamiento en cascada de una relación de tabla para las acciones Reparent o Share a Sin cascada, el sistema intentará ajustar los derechos de acceso heredados del usuario para que coincidan con el comportamiento en cascada de la relación de tabla actual. Más información sobre limpieza de derechos de acceso heredados
Sin embargo, si este enfoque no tiene éxito, es posible que los usuarios conserven el acceso a registros relacionados que deben eliminarse. Para conocer los pasos para solucionar el problema, consulte Limpiar el acceso heredado.
Consulte también
Definiciones de relaciones de tablas
Nota
¿Puede indicarnos sus preferencias de idioma de documentación? Realice una breve encuesta. (tenga en cuenta que esta encuesta está en inglés)
La encuesta durará unos siete minutos. No se recopilan datos personales (declaración de privacidad).
Comentarios
Próximamente: A lo largo de 2024 iremos eliminando gradualmente las Cuestiones de GitHub como mecanismo de retroalimentación para el contenido y lo sustituiremos por un nuevo sistema de retroalimentación. Para más información, consulta: https://aka.ms/ContentUserFeedback.
Enviar y ver comentarios de