Seguimiento de dependencias para los componentes de la solución

Este tema se aplica a Dynamics 365 Customer Engagement (on-premises). Para la versión de Power Apps de este tema, consulte: Seguimiento de dependencias de los componentes de la solución.

Las soluciones están hechas de componentes de solución. Usará el área Soluciones de Dynamics 365 Customer Engagement (local) para crear o agregar componentes de solución. Puede realizar estas acciones mediante programación mediante el AddSolutionComponentRequest mensaje o cualquier mensaje que cree o actualice los componentes de la solución que incluyan un SolutionUniqueName parámetro.

Los componentes de la solución suelen depender de otros componentes de la solución. No se puede eliminar ningún componente de solución que tenga dependencias en otro componente de solución. Por ejemplo, una cinta personalizada normalmente requiere recursos web de imagen o script para mostrar iconos y realizar acciones mediante scripts. Siempre que la cinta de opciones personalizada esté en la solución, se requieren los recursos web específicos que usa. Para poder eliminar los recursos web, debe quitar las referencias a ellos en la cinta de opciones personalizada. Estas dependencias de componentes de solución se pueden ver en la aplicación haciendo clic en Mostrar dependencias.

En este tema se describen los tipos de componentes de solución que puede incluir en las soluciones y cómo dependen entre sí.

Todos los componentes de la solución

La lista completa de los tipos de componentes de soluciones disponibles se encuentra en el conjunto de opciones global del sistema componenttype . Puede usar el https://[ORGANIZATION_NAME].api.crm.dynamics.com/api/data/v9.0/GlobalOptionSetDefinitions(Name='componenttype')punto de conexión REST para consultar estos datos y ver toda la componenet mediante código. El intervalo de valores admitido para esta propiedad está disponible incluyendo el archivo SampleCode\CS\HelperCode\OptionSets.cs o SampleCode\VB\HelperCode\OptionSets.vb en el proyecto. Sin embargo, muchos de los tipos de componentes de solución enumerados solo existen para uso interno y la lista no proporciona información sobre las relaciones entre los componentes de la solución.

Dependencias de componentes de solución

Las dependencias de componentes de solución ayudan a asegurarse de que tiene una experiencia confiable trabajando con soluciones. Impiden que las acciones que realice normalmente interrumpan las personalizaciones definidas en una solución de forma involuntaria. Estas dependencias son lo que permite instalar y desinstalar una solución administrada simplemente mediante la importación o eliminación de una solución.

El marco de soluciones realiza un seguimiento automático de las dependencias de los componentes de la solución. Cada operación de un componente de solución calcula automáticamente las dependencias a otros componentes del sistema. La información de dependencia se usa para mantener la integridad del sistema y evitar operaciones que podrían provocar un estado incoherente.

Como resultado del seguimiento de dependencias, se aplican los comportamientos siguientes:

Se impide la eliminación de un componente si otro componente del sistema depende de él.
La exportación de una solución advierte al usuario si faltan componentes que podrían provocar errores al importar esa solución en otro sistema.

Las advertencias durante la exportación se pueden omitir si el desarrollador de soluciones piensa que la solución solo se va a instalar en una organización en la que se espera que existan componentes dependientes. Por ejemplo, cuando se crea una solución diseñada para instalarse en una solución "base" preinstalada.
Se produce un error en la importación de una solución si no se incluyen todos los componentes necesarios en la solución y tampoco existen en el sistema de destino.
- Además, al importar una solución administrada, todos los componentes necesarios deben coincidir con el tipo de paquete de la solución. Un componente de una solución administrada solo puede depender de otro componente administrado.
Hay tres tipos de dependencias de componentes de solución:

Solución interna
Dynamics 365 Customer Engagement (local) administra las dependencias internas. Existen cuando un componente de solución determinado no puede existir sin otro componente de solución.

Publicado
Las dependencias publicadas se crean cuando dos componentes de la solución están relacionados entre sí y, a continuación, se publican. Para quitar este tipo de dependencia, la asociación debe quitarse y las entidades publicadas de nuevo.

Inédito
Las dependencias no publicadas se aplican a la versión no publicada de un componente de solución que se puede publicar que se está actualizando. Una vez publicado el componente de solución, se convierte en una dependencia publicada.

Las dependencias internas de la solución son dependencias en las que las acciones con un componente de solución requieren una acción para otro componente de solución. Por ejemplo, si elimina una entidad, debe esperar que todos los atributos de entidad se eliminen con ella. También se eliminarán las relaciones de entidad con otras entidades.

Sin embargo, una dependencia interna puede provocar una dependencia publicada y seguir necesitando intervención manual. Por ejemplo, si incluye un campo de búsqueda en un formulario de entidad y, a continuación, elimina la entidad principal de la relación, no puede completar esa eliminación hasta que quite el campo de búsqueda del formulario de entidad relacionado y, a continuación, publique el formulario.

Al realizar acciones mediante programación con soluciones, puede usar mensajes relacionados con la Dependency entidad. Consulte Dependency Entity for messages you can use to identify dependencies that may exist before you delete a component or uninstall a solution.

Comprobación de las dependencias de componentes de solución

Al editar soluciones, es posible que no pueda eliminar un componente de solución porque tiene una dependencia publicada con otro componente de solución. O bien, es posible que no pueda desinstalar una solución administrada porque uno de los componentes de la solución administrada se ha usado en una personalización en otra solución no administrada.

En la tabla siguiente se enumeran los mensajes que puede usar para recuperar datos sobre las dependencias de componentes de la solución.

Message	Description
RetrieveDependentComponentsRequest	Devuelve una lista de dependencias para los componentes de la solución que dependen directamente de un componente de solución. Por ejemplo, cuando se usa este mensaje para un componente de solución de conjunto de opciones global, se devuelven los registros de dependencia de los componentes de solución que representan los atributos del conjunto de opciones que hacen referencia al componente de solución del conjunto de opciones global. Cuando use este mensaje para el registro del componente de solución para la entidad de cuenta, se devuelven registros de dependencia para todos los componentes de la solución que representan atributos, vistas y formularios usados para esa entidad.
RetrieveRequiredComponentsRequest	Devuelve una lista de las dependencias de los componentes de la solución de los que depende directamente otro componente de solución. Este mensaje proporciona la inversa del `RetrieveDependentComponentsRequest` mensaje.
RetrieveDependenciesForDeleteRequest	Devuelve una lista de todas las dependencias de los componentes de la solución que podrían impedir la eliminación de un componente de solución.
RetrieveDependenciesForUninstallRequest	Devuelve una lista de todas las dependencias de los componentes de la solución que podrían impedir la desinstalación de una solución administrada.

Componentes comunes de la solución

Estos son los componentes de la solución que se muestran en la aplicación y los componentes con los que trabajará directamente al agregar o quitar componentes de solución mediante la página de la solución. Cada uno de los otros tipos de componentes de solución dependerá de uno o varios de estos componentes de solución que existan.

Cintas de opciones de aplicación (RibbonCustomization)

Personalizaciones de la cinta de opciones de la cinta de opciones de la aplicación y las plantillas de cinta de opciones de entidad. Las cintas de opciones de aplicación no incluyen definiciones de cintas de opciones en el nivel de entidad o formulario.

Las cintas de opciones de aplicación personalizadas suelen tener dependencias publicadas en los recursos web. Los recursos web se usan para definir iconos de botón de cinta de opciones y funciones de JavaScript para controlar cuándo se muestran los elementos de la cinta de opciones o qué acciones se realizan cuando se usa un control de cinta de opciones determinado. Las dependencias solo se crean cuando las definiciones de la cinta de opciones usan la $webresource: directiva para asociar el recurso web a la cinta de opciones. Más información: directiva $webresource

Plantilla de artículo (KBArticleTemplate)

Plantilla que contiene los atributos estándar de un artículo. Siempre hay una dependencia interna entre la plantilla de artículo y la entidad KbArticle.

Rol de conexión (ConnectionRole)

Rol que describe una relación entre dos registros. Cada rol de conexión define qué tipos de registros de entidad se pueden vincular mediante el rol de conexión. Esto crea una dependencia publicada entre el rol de conexión y la entidad.

Plantilla de contrato (ContractTemplate)

Plantilla que contiene los atributos estándar de un contrato. Siempre hay una dependencia interna entre la plantilla de contrato y la entidad de contrato.

Formulario de panel o entidad (SystemForm)

Los registros de entidades del formulario del sistema se usan para definir paneles y formularios de entidad. Cuando se usa un SystemForm como formulario de entidad, hay una dependencia interna de la entidad. Cuando se usa SystemForm como panel, no hay dependencias internas. Los formularios de entidad y los paneles suelen tener dependencias publicadas relacionadas con su contenido. Un formulario de entidad puede tener campos de búsqueda que dependen de una relación de entidad. Tanto los paneles como los formularios de entidad pueden contener gráficos o subgrids que crearán una dependencia publicada en una vista, que después tiene una dependencia interna en una entidad. Se puede crear una dependencia publicada en los recursos web debido al contenido que se muestra dentro del panel o formulario o cuando un formulario contiene bibliotecas de JavaScript. Los formularios de entidad tienen dependencias publicadas en los atributos que se muestran como campos en el formulario.

Plantilla de correo electrónico (EmailTemplate)

Plantilla que contiene los atributos estándar de un mensaje de correo electrónico. Normalmente, una plantilla de correo electrónico incluye campos que insertan datos de atributos de entidad especificados. Una plantilla de correo electrónico se puede vincular a una entidad específica cuando se crea para que pueda haber una dependencia interna en la entidad. Una plantilla de correo electrónico global no está asociada a una entidad específica, pero puede tener dependencias publicadas en atributos de entidad usados para proporcionar datos. Un proceso (flujo de trabajo) se configura con frecuencia para enviar un correo electrónico mediante una plantilla de correo electrónico que crea una dependencia publicada con el flujo de trabajo.

Entidad (entidad)

Estructura principal que se usa para modelar y administrar datos en Dynamics 365 Customer Engagement (local). Los gráficos, formularios, relaciones de entidad, vistas y atributos asociados a una entidad se eliminan automáticamente cuando la entidad se elimina debido a las dependencias internas entre ellas. Las entidades suelen tener dependencias publicadas con procesos, paneles y plantillas de correo electrónico.

Perfil de seguridad de campo (FieldSecurityProfile)

Perfil que define el nivel de acceso para los atributos protegidos.

Plantilla de combinación de correspondencia (MailMergeTemplate)

Plantilla que contiene los atributos estándar de un documento de combinación de correspondencia. Una plantilla de combinación de correspondencia tiene una dependencia publicada de la entidad a la que está asociada.

Conjunto de opciones (OptionSet)

Un conjunto de opciones define un conjunto de opciones. Un atributo picklist usa un conjunto de opciones para definir las opciones proporcionadas. Varios atributos de lista de selección pueden usar un conjunto de opciones global para que las opciones que proporcionen sean siempre las mismas y se puedan mantener en un solo lugar. Una dependencia publicada se produce cuando un atributo picklist hace referencia a un conjunto de opciones global. No se puede eliminar un conjunto de opciones global que usa un atributo picklist.

Ensamblado de complemento (PluginAssembly)

Ensamblado que contiene uno o varios tipos de complemento. Los complementos se registran en eventos que normalmente están asociados a una entidad. Esto crea una dependencia publicada.

Proceso (flujo de trabajo)

Conjunto de reglas lógicas que definen los pasos necesarios para automatizar un proceso de negocio, una tarea o un conjunto de acciones específicos que se van a realizar. Los procesos proporcionan una amplia gama de acciones que crean dependencias publicadas en cualquier otro componente de solución al que haga referencia el proceso. Cada proceso también tiene una dependencia publicada de la entidad a la que está asociada.

Informe (informe)

Resumen de datos en un diseño fácil de leer. Un informe ha publicado dependencias en cualquier entidad o datos de atributo incluidos en el informe. Cada informe también debe estar asociado a una categoría Informe que crea una dependencia interna en un componente de solución denominado Categoría relacionada con informes (ReportCategory). Los informes se pueden configurar para que sean subinformes que creen una dependencia publicada con el informe primario.

Paso de procesamiento de mensajes del SDK (SDKMessageProcessingStep)

Fase de la canalización de ejecución que se va a ejecutar un complemento.

Rol de seguridad (rol)

Agrupación de privilegios de seguridad. A los usuarios se les asignan roles que autorizan su acceso al sistema dynamics 365 Customer Engagement (local). Los formularios de entidad se pueden asociar a roles de seguridad específicos para controlar quién puede ver el formulario. Esto crea una dependencia publicada entre el rol de seguridad y el formulario.

Nota:

Solo se pueden agregar roles de seguridad de la unidad de negocio de la organización a una solución. Solo un usuario con acceso de lectura a esos roles de seguridad puede agregarlos a una solución.

Punto de conexión de servicio (ServiceEndpoint)

Punto de conexión de servicio al que se puede ponerse en contacto.

Mapa de sitio (SiteMap)

Datos XML usados para controlar el panel de navegación de la aplicación. El mapa de sitio puede estar vinculado para mostrar un recurso web HTML o un icono en el mapa de sitio puede usar un recurso web de imagen. Cuando se usa la $webresource: directiva para establecer estas asociaciones, se crea una dependencia publicada. Más información: directiva $webresource

Recurso web (WebResource)

Datos equivalentes a los archivos usados en el desarrollo web. Los recursos web proporcionan componentes del lado cliente que se usan para proporcionar elementos de interfaz de usuario personalizados. Los recursos web pueden tener dependencias publicadas con formularios de entidad, cintas de opciones y SiteMap. Cuando la $webresource: directiva se usa para establecer asociaciones en una cinta de opciones o siteMap, se crea una dependencia publicada. Para obtener más información, consulte $webresource directiva.