Compartir a través de

Prácticas recomendadas para desarrollar con Dynamics 365 Customer Engagement

  • Artículo

En este tema se describen las prácticas recomendadas para personalizar Dynamics 365 for Customer Engagement.

Importante

Revise Extensiones compatibles para Dynamics 365 Customer Engagement (on-premises) para obtener información sobre las técnicas compatibles e incompatibles para personalización.

Prácticas recomendadas de rendimiento

Las siguientes prácticas recomendadas pueden ayudarle a escribir código que funcione mejor.

Usar varios subprocesos

Agregue el soporte de subprocesos a la aplicación para dividir el trabajo entre varias CPU. Esta sugerencia presupone que está ejecutando el código en un sistema de multiprocesador. Más información: Artículo de la Guía de desarrollo avanzado de NET Framework sobre subprocesos administrados.

Permitir que el sistema cree GUID

Permita que el sistema asigne automáticamente el (id) >GUID en lugar de crearlo usted manualmente. Esta sugerencia permite que Dynamics 365 Customer Engagement (on-premises) se aproveche de GUID secuenciales, que ofrecen un mejor rendimiento de SQL. El siguiente código de ejemplo muestra cómo llamar al método Create para obtener un GUID asignado por el sistema.

// Instantiate an account object.
Account account = new Account { Name = "Fourth Coffee" };  
// Create an account record named Fourth Coffee and retrieve the GUID.
accountId = serviceProxy.Create(account);

Usar tipos de enlace de tiempo de compilación

Use la clase Entity cuando el código debe funcionar en las entidades y atributos que no se conocen en el momento en que se escribe el código. Además, si el código personalizado funciona con miles de registros de entidad, el uso de la clase Entity ofrece un mejor rendimiento que los tipos de entidad en tiempo de compilación. Sin embargo, esta flexibilidad tiene una desventaja porque no se puede comprobar la entidad y los nombres de atributo en tiempo de compilación. Si se definen las entidades en tiempo de codificación y una ligera degradación de rendimiento es aceptable, utilice los tipos en tiempo de compilación que puede generar con la herramienta CrmSvcUtil. Más información: Usar las clases de entidad con enlace en tiempo de compilación en código.

Deshabilitar complementos

Si es posible, deshabilite los complementos registrados antes de ejecutar la aplicación.

Escriba complementos que se ejecuten más rápido

Escriba siempre un complemento que tarde menos tiempo para realizar la tarea prevista. Por ejemplo, el método de Execute con frecuencia se procesa en Dynamics 365 Customer Engagement (on-premises). Si se registra un complemento en el mensaje, el complemento puede tener un impacto importante en el rendimiento del sistema porque se ejecuta cada vez que el método Execute se procesa, lo que sucede con frecuencia.

Si trata de registrar los complementos para la ejecución sincrónica, se recomienda diseñarlos para completar la operación en menos de 2 segundos. Es mejor reducir el tiempo de procesamiento en los complementos que mantener la interactividad de las aplicaciones cliente que están conectadas al mismo servicio de la organización que ejecuta el complemento.

Limite los datos que recupera

Cuando se usan los métodos que recuperan datos del servidor, recupere la cantidad mínima de datos que necesite la aplicación. Esto se realiza especificando el conjunto de columnas, que es el conjunto de atributos de una entidad que se van a recuperar.

Por ejemplo, habitualmente no es una buena idea recuperar todos los metadatos con el mensaje RetrieveAllEntities usando la clase RetrieveAllEntitiesRequest, especificando el filtro de entidad All` para la propiedad EntityFilters. En su lugar, es posible alcanzar mejor rendimiento si se limita el filtro de la entidad o se usa una de las siguientes clases de solicitud de mensajes: RetrieveEntityRequest, RetrieveOptionSetRequest, RetrieveAttributeRequest, RetrieveRelationshipRequest o RetrieveMetadataChangesRequest. El mensaje RetrieveMetadataChanges permite crear una consulta para devolver solamente los metadatos que necesita o metadatos que han cambiado. Más información: Recuperar y detectar cambios en metadatos.

Limitar el número de entidades que se habilitan para uso sin conexión

Considere detenidamente si una entidad debe estar disponible para las personas sin conexión. Cada entidad que habilite para la funcionalidad sin conexión afecta directamente al tiempo necesario para que los usuarios sincronicen los datos cuando se vuelvan a conectar. Esto es especialmente real para los usuarios con equipos menos potentes.

Al usar el método Update o el mensaje UpdateRequest, no puede establecer el atributo OwnerId en un registro a menos que el propietario haya cambiado realmente. Cuando establece este atributo, los cambios a menudo llegan en cascada a las entidades relacionadas, que incrementar el tiempo necesario para la operación de actualización. Más información: Comportamiento en cascada

Ajuste los valores de proxy en el cliente (solo local)

 

Un servidor proxy se encuentra entre una aplicación cliente, como un explorador web, y el servidor de destino real. Cuando un equipo está en una LAN, puede usar un servidor proxy para conectarse a Internet. En este caso, el servidor proxy se combina con, o es parte de, la puerta de enlace y el servidor de firewall. El proxy puede almacenar en caché solicitudes web y servir varias solicitudes de cliente mediante los datos almacenados en caché. Si los datos solicitados no se encuentra en la memoria caché del servidor proxy, transmite la solicitud al servidor mediante su propia dirección IP. Aquí, el servidor proxy actúa en nombre del equipo cliente.

Aunque un servidor proxy pueda actuar como servidor de caché y puede ayudar a cargar una página web más rápidamente, puede disminuir a veces el rendimiento si se usa de manera incorrecta.

Con frecuencia, las personas evitarán la configuración manual del proxy y usarán la configuración de proxy automática. Este acceso directo ayuda en el equilibrio de carga de un servidor de proxy, pero en función de la complejidad del script de configuración, un retraso considerable se puede experimentar cuando se usa la configuración de proxy automática.

Cuando Dynamics 365 Server está instalado, puede anular el servidor proxy para lograr un mejor rendimiento.

El servidor proporciona una dirección web local que no requiere ningún proxy para ser alcanzada. Puede seleccionar Anular el servidor proxy para direcciones locales y proporcionar el nombre de dominio completo de Dynamics 365 Server en la lista de las excepciones. Esto proporciona un mejor rendimiento cuando los registros se crean con ensamblados de SDK.

Mejorar el rendimiento de la asignación del canal de servicio

Puede establecer una conexión con los servicios web de Dynamics 365 Customer Engagement (on-premises) y autenticar a los usuarios mediante las clases del proxy de servicio OrganizationServiceProxy y DiscoveryServiceProxy. Sin embargo, el uso incorrecto de estos tipos del proxy de servicio podría disminuir a veces el rendimiento de la aplicación. Por tanto, si comprende cuándo y cómo usar las clases de cliente que están disponibles en el SDK, es posible obtener a menudo un mejor rendimiento de la aplicación.

Cuando establece un canal de servicio de Windows Communication Foundation (WCF) mediante un extremo de servicio, por ejemplo, mediante el servicio web de la organización, la aplicación debe realizar dos operaciones largas: descargar metadatos del extremo y la autenticación de usuarios. Puede mejorar el rendimiento si la aplicación realiza las operaciones la cantidad mínima de veces en cada sesión de la aplicación.

El constructor OrganizationServiceProxy que se muestra aquí realiza ambas operaciones cada vez que se crea un objeto del proxy de servicio.

OrganizationServiceProxy (Uri uri, Uri homeRealmUri, ClientCredentials clientCredentials, 
    ClientCredentials deviceCredentials)

Normalmente se obtiene mejor rendimiento si la aplicación usa este constructor para crear una instancia del proxy de servicio con este constructor una vez durante la sesión de la aplicación y almacenar en caché la referencia devuelta para usar en varias rutas de acceso del código en la aplicación. Observe que la referencia devuelta del servicio no es segura para subprocesos, de modo que otras aplicaciones de múltiples subprocesos necesitarán asignar una instancia por subproceso. Las aplicaciones también deben llamar a Dispose en el objeto del proxy de servicio antes de que finalicen para liberar los recursos asignados del canal de servicio.

La clase del proxy de servicio realiza la descarga de metadatos y la autenticación de usuarios a través de los siguientes métodos de clase.

IServiceManagement<IOrganizationService> orgServiceManagement = 
    ServiceConfigurationFactory.CreateManagement<IOrganizationService>(
    new Uri(organizationUrl));

AuthenticationCredentials authCredentials = orgServiceManagement.Authenticate(credentials);

El método ServiceConfigurationFactory.CreateManagement método realiza la descarga de metadatos mientras el método Authenticate(AuthenticationCredentials) autentica al usuario. Los objetos devueltos de estos métodos son seguros para subprocesos y los puede almacenar en caché estáticamente la aplicación. Puede usar posteriormente estos objetos para crear un objeto del proxy de servicio que use uno de los demás constructores disponibles.

OrganizationServiceProxy (orgServiceManagement, authCredentials.ClientCredentials)
OrganizationServiceProxy (orgServiceManagement, authCredentials.SecurityTokenResponse)

Al almacenar en caché los objetos de la administración del servicio y de credenciales autenticados, la aplicación, puede crear de forma más eficiente objetos de proxy de servicio más de una vez en cada sesión de la aplicación. Si habilita los tipos en tiempo de compilación en OrganizationServiceProxy con uno de los métodos EnableProxyTypes(), debe hacer lo mismo en todos los proxys de servicio creados a partir de objetos almacenados en caché en el objeto IServiceManagement<TService>. Si la aplicación usa metadatos, se recomienda que almacene en caché metadatos que recupera y periódicamente llame al mensaje RetrieveTimestampRequest para determinar si debe actualizar la memoria caché.

Además, supervise el token de seguridad WCF (Token) y actualícelo antes de que caduque, de modo que no pierda ningún símbolo y no tenga que empezar de nuevo con la autenticación. Para comprobar el token, cree una clase personalizada que herede de la clase OrganizationServiceProxy o DiscoveryServiceProxy y que implemente la lógica empresarial para comprobar el símbolo. O ajuste las clases de servidor en un nuevo tipo. Otra técnica es comprobar explícitamente el símbolo antes de llamar al servicio web. El código de ejemplo que muestra estas técnicas se puede encontrar en las clases ManagedTokenDiscoveryServiceProxy, ManagedTokenOrganizationServiceProxy y AutoRefreshSecurityToken en el tema Código auxiliar: clase ServerConnection.

Prácticas recomendadas de personalización

Las recomendaciones siguientes pueden ayudarle a personalizar y ampliar Dynamics 365 Customer Engagement (on-premises).

Prácticas recomendadas para Dynamics 365 Customer Engagement (on-premises)

Las notas del producto Patrones y principios de aplicaciones de Microsoft Dynamics 365 Customer Engagement (on-premises) para creadores de soluciones proporcionan instrucciones específicas sobre la creación de soluciones mediante Dynamics 365 for Customer Engagement.

Uso de atributos y entidades personalizadas.

Use siempre el nombre de entidad para hacer referencia a entidades en el código y las consultas. No use el código del código de tipo de objeto (también llamado tipo de entidad) porque el valor de entero varía para entidades personalizadas en varias organizaciones.

Ahorre espacio en el servidor mediante estas técnicas:

  • Cree atributos personalizados para las entidades existentes en lugar de crear una nueva entidad.
  • Cambie el nombre de las entidades existentes para crear entidades más significativas.

¿Cuándo debe personalizar una entidad?

Personalice una entidad del sistema, como la entidad de oportunidad, en lugar de reemplazarla por una nueva entidad personalizada, para poder usar cualquiera de las funciones integradas en una entidad existente.

¿Cuándo usar complementos y cuándo flujos de trabajo?

Como programador que está interesado en ampliar o personalizar Dynamics 365 Customer Engagement (on-premises), puede elegir entre varios métodos para realizar las tareas. Además de agregar código de cliente de JavaScript a un formulario o de agregar las páginas personalizadas ASP.NET, puede escribir un complemento o crear un flujo de trabajo personalizado mediante la interfaz web que llama a una actividad personalizada de flujo de trabajo. ¿Cómo decide cuándo usar un complemento y cuándo usar un flujo de trabajo? La tecnología que use dependerá de la tarea que tiene que realizar y de quién haga la personalización.

Por ejemplo, debería usar un flujo de trabajo en tiempo real de complementos sincrónicos si desea ejecutar código personalizado que se ejecute inmediatamente antes o después de la operación de la plataforma base y antes de que el resultado de la operación se devuelva desde la plataforma. No puede usar un complemento ni un flujo de trabajo asincrónico en esta situación porque están en cola para ejecutarse cuando la operación base ha terminado de ejecutarse. Por lo tanto, no puede predecir cuándo se ejecutarán. Si desea agregar funcionalidad personalizada a Dynamics 365 for Customer Engagement, se admiten los flujos de trabajo, actividades de flujo de trabajo personalizado y complementos, pero no los flujos de trabajo XAML.

Evalúe estas tecnologías y elija la que mejor se adapta a sus objetivos de negocio tras considerar la implementación, el rendimiento y las preocupaciones de mantenimiento del complemento o solución de flujo de trabajo.

La siguiente tabla resume las características de los complementos y los flujos de trabajo.

Criterios Complemento Flujo de trabajo
Ejecución antes o después de la operación de la plataforma base (Crear, Actualizar, Eliminar, etc.) Se ejecuta inmediatamente antes o después de la operación base (sincrónico).

También puede estar en la cola para ejecutarse después de la operación base (asincrónico).		 Los flujos de trabajo asincrónicos están en la cola para ejecutarse después de la operación base.

Los flujos de trabajo en tiempo real tienen características similares a los complementos.
Impacto en el rendimiento del servidor Los complementos sincrónicos pueden aumentar el tiempo de respuesta de la plataforma porque forman parte del procesamiento principal de la plataforma.

Los complementos asincrónicos tienen menos impacto en el tiempo de respuesta del servidor porque el código se ejecuta en otro proceso.		 Los flujos de trabajo asincrónicos tienen menos impacto en el tiempo de respuesta del servidor porque el código se ejecuta en otro proceso.

Los flujos de trabajo en tiempo real tienen características de rendimiento similares a los complementos en espacio aislado.
Restricciones de seguridad Para publicar un complemento con la plataforma se necesita un rol de seguridad de Administrador del sistema o personalizador del sistema en el grupo administrador de implementaciones. Los usuarios pueden crear de forma interactiva flujos de trabajo en la aplicación web.

Sin embargo, para registrar una actividad personalizada de flujo de trabajo, el usuario debe tener los mismos roles de seguridad que los necesarios para registrar complementos.
Compatibilidad con la versión Dynamics 365 Customer Engagement (on-premises) (SKU) Compatible con Dynamics 365 for Customer Engagement cuando se registra en el espacio aislado. Puede ser compatible en instalaciones hospedadas por un asociado al criterio del asociado. Los flujos de trabajo son compatibles con todas las implementaciones de Customer Engagement. Las actividades de flujo de trabajo personalizadas se admiten en el espacio aislado de Dynamics 365 for Customer Engagement y dentro o fuera del espacio aislado para implementaciones locales/IFD.
Duración del tiempo de procesamiento Un complemento registrado para la ejecución sincrónica o asincrónica está limitado para completar su ejecución en un límite de tiempo de dos minutos. Funciona bien con procesos largos o cortos. Sin embargo, cada actividad de un flujo de trabajo no puede tardar más de dos minutos en finalizar.
Funciona cuando el cliente de Dynamics 365 for Outlook está sin conexión Se admite con conexión y sin conexión. Los flujos de trabajo no se ejecutan sin conexión.
Persistencia de los procesos y los datos Los complementos se ejecutan hasta que se completan. Los complementos se deben escribir para no tener estado donde no persisten los datos en memoria. Los flujos de trabajo asincrónicos se pueden pausar, posponer, cancelar y reanudar con las llamadas de SDK o por el usuario mediante la aplicación web. El estado del flujo de trabajo se guarda automáticamente antes de que se detenga o se posponga.

Los flujos de trabajo en tiempo real no tienen ningún estado de espera. Deben ejecutarse hasta completarse, igual que los complementos.
Suplantación Los complementos pueden realizar operaciones de datos en nombre de otro usuario del sistema. Los flujos de trabajo asincrónicos no pueden usar la suplantación, mientras que los flujos de trabajo en tiempo real sí pueden. Los flujos de trabajo en tiempo real pueden ejecutarse como el propietario del flujo de trabajo o como el usuario que hace la llamada.
Creación Los ingenieros de software o los programadores pueden crear complementos. Cualquier persona, un usuario final, analista de negocios o administrador, puede crear flujos de trabajo si tiene los permisos apropiados.

No hay impacto importante en el rendimiento en el servidor entre un flujo de trabajo y un complemento asincrónico.

¿Qué tipo de flujo de trabajo es mejor?

Desde una perspectiva de rendimiento, ¿es mejor crear un solo flujo de trabajo largo o es mejor tener varios flujos de trabajo secundarios y llamarlos desde un flujo de trabajo principal? El método de flujo de trabajo secundario alcanza un rendimiento menor, pero es más administrable si suele cambiar la definición del flujo de trabajo. La sobrecarga de compilación no es una preocupación importante porque el flujo de trabajo se compila únicamente durante la publicación. Sin embargo, Dynamics 365 Customer Engagement (on-premises) incurre en sobrecarga al iniciar cada instancia de flujo de trabajo. La sobrecarga se produce cuando se recuperan todas las entidades que se usan en el flujo de trabajo y el flujo de trabajo secundario se inicia en un proceso de dos fases que incluye una "tarea de expansión de flujo de trabajo" y la instancia de flujo de trabajo actual. Por lo tanto, para obtener el máximo rendimiento, use un solo flujo de trabajo largo.

¿Cómo se debe marcar la actividad personalizada de flujo de trabajo como completada?

El valor devuelto del método Execute es usado por el tiempo de ejecución del flujo de trabajo para marcar la actividad como "completada". Debe usar return base.Execute(executionContext) a menos que la actividad omita funcionalidad de clase base. Evite devolver ActivityExecutionStatus.Closed. Más información: ActivityExecutionStatus Enumeration

¿Cómo se debe informar de excepciones en actividades personalizadas de flujo de trabajo?

Debe lanzar una InvalidPluginExecutionException en el código. Este error se muestra en el formulario de la instancia de flujo de trabajo.

¿Puede definir las entidades personalizadas que son específicas de unidades de negocio?

Las entidades tienen privilegios para cada rol de seguridad, pero no para cada unidad de negocio. Para definir las entidades personalizadas que están visibles solo para unidades de negocio especificadas, debe crear varios roles de seguridad para cada unidad de negocio y conceder los privilegios a la entidad personalizada en el rol adecuado.

Prácticas recomendadas de seguridad

Siga estas directrices para ayudar a proteger los datos de negocio.

General

Las prácticas recomendadas para garantizar la implementación de Dynamics 365 Customer Engagement (on-premises) incluyen lo siguiente:

  • Definir un plan aprobado de datos de seguridad en la implementación de Dynamics 365 Customer Engagement (on-premises) de la organización.
  • Asignar la menor cantidad de privilegios necesarios al configurar el grupo de aplicaciones.
  • Requerir que todos los usuarios usen contraseñas seguras para sus cuentas.

Más información: Conceptos de seguridad para Dynamics 365 Customer Engagement (on-premises)

Roles, privilegios y derechos de acceso

Las prácticas recomendadas para garantizar la implementación del modelo de seguridad de Dynamics 365 Customer Engagement (on-premises) incluyen lo siguiente:

  • Limite totalmente el número de personas asignadas al rol de administrador del sistema. Nunca quite este rol.
  • Cree los roles según la recomendación de seguridad de menos privilegios, dar acceso a la cantidad mínima de datos empresariales necesarios para la tarea. Asigne a los usuarios el rol adecuado para su trabajo.
  • Cree un nuevo rol con esos privilegios específicos y agregue el usuario al nuevo rol si necesita niveles o derechos de acceso adicionales. Los derechos de un usuario son la unión de todos los roles a los que está asignado. No conceda los privilegios del rol original que son necesarios solo para uno o varios integrantes.
  • Use el uso compartido, si procede, que permite dar a usuarios específicos derechos específicos en objetos individuales, en lugar de privilegios más amplios en todos los objetos de un tipo determinado.
  • Use los equipos para crear grupos funcionales en niveles para que se puedan compartir objetos específicos con el equipo.
  • Dé formación a los usuarios que tengan derechos de acceso compartidos a compartir el mínimo de información necesaria.

Evite la elevación de privilegios

La elevación de ataques de privilegios se produce cuando un usuario puede asumir los privilegios de una cuenta de confianza, como un propietario o un administrador. Ejecute siempre las cuentas de usuario con menos privilegios y asigne solo los permisos necesarios. Evite el uso de cuentas administrativas o de propietario para ejecutar código. Esto limita la cantidad de daño que se puede producirse si se produce un ataque. Al realizar tareas que requieran permisos adicionales, use la firma de procedimientos o la suplantación solo para la duración de la tarea.

Desarrollo de servidor

Las prácticas recomendadas para desarrollar código de servidor para Dynamics 365 Customer Engagement (on-premises) incluyen lo siguiente:

  • No modifique la base de datos de Dynamics 365 Customer Engagement (on-premises) de ninguna forma salvo para usar el SDK porque hacerlo omite el modelo de seguridad de Dynamics 365 Customer Engagement (on-premises).
  • Los complementos se ejecutan en el contexto del administrador: debería saber que este código puede obtener acceso a información a la que el usuario conectado no tiene acceso.
  • Para los ensamblados de flujo de trabajo, así como para los complementos, evite escribir código que requiera mucho tiempo para ejecutarse. Es importante que el código del complemento que se registra para ejecutarse de forma sincrónica vuelva lo más rápidamente posible.
  • Si está replicando los datos de Dynamics 365 Customer Engagement (on-premises) en su propio almacén de datos, será responsable de la seguridad de los datos. Si usa un complemento para transferir los datos, asegúrese de que registra el complemento para que se ejecute después de la operación de la plataforma base. La comprobación del privilegio de seguridad del usuario conectado sucede durante la operación de la plataforma base.
  • Los datos que salen de Dynamics 365 Customer Engagement (on-premises) tal vez no sean seguros para representación. Los datos se han podido contaminar con etiquetas HTML que no son seguras.
  • Respete el requisito de no tener acceso a las bases de datos de aplicaciones Dynamics 365 Customer Engagement (on-premises) directamente a través del Administrador SQL Server Enterprise. Al omitir el SDK se puede abrir la puerta a amenazas por inyección de código SQL.
  • Para las implementaciones a través de Internet, recuerde que la solución es tan segura como el vínculo más débil. Después de que la aplicación se exponga a Internet, está abierta a amenazas de seguridad.
  • Use solo los idiomas que muestran código administrado para obtener la mejor seguridad de las saturaciones de búfer, excepciones, etc.

Para obtener más información acerca de la seguridad, vea los temas siguientes:

Desarrollo de cliente

Las recomendaciones para desarrollar personalizaciones para la aplicación web Customer Engagement y Dynamics 365 for Outlook incluyen lo siguiente:

  • Use los recursos web en lugar de las páginas que requieren el procesamiento de servidor siempre que sea posible. Si sus requisitos solo se puede obtener usando el procesamiento de servidor, cumpla el requisito de que las páginas web personalizadas se instalen en un sitio web diferente de Dynamics 365 Customer Engagement (on-premises). Establezca el nivel de confianza del sitio adecuadamente, en función del nivel de confianza en la seguridad de su código. Esto reduce la amenaza de scripting entre sitios y otras amenazas.
  • Para mejorar la seguridad, asegúrese de que el sitio web se ejecuta de forma separada en otra cuenta de Dynamics 365 Customer Engagement (on-premises). Esta cuenta debe tener el mínimo acceso posible, uno que no tenga acceso directo a las bases de datos de Microsoft. Puede usar una contraseña compleja que no expira porque ningún usuario inicia sesión en esta cuenta, solo en la aplicación.
  • Evite el uso de controles ActiveX porque tienen problemas conocidos de seguridad.
  • Tenga en cuenta de las limitaciones de scripting del cliente. Más información: Prácticas recomendadas: ejemplo de script en Customer Engagement
  • Use los complementos para aplicar lógica empresarial independientemente de cómo se hagan cambios en los datos.
  • Use siempre un cuadro de diálogo de confirmación cuando elimine registros o aplique los cambios confidenciales, como agregar un nuevo usuario a un rol de seguridad. Puede usar openConfirmDialog para mostrar un diálogo. Esto ayuda a evitar las técnicas como el secuestro de clic o la redirección de la interfaz de usuario donde un desarrollador con intenciones maliciosas puede incrustar la página en una página aparentemente inofensiva para engañar a un usuario de forma que realice acciones que pueden poner en peligro la seguridad o realizar acciones no deseadas en los datos.

Las prácticas recomendadas de seguridad para un sitio web incluyen lo siguiente:

  • No use el acceso anónimo.

  • Use la autenticación de Windows integrada, NTLM o autenticación básica sobre la seguridad de capa de transporte (TLS) o la capa de sockets seguros (SSL).

  • Use TLS/SSL para evitar que se envíen datos sin cifrar si el sitio web se encuentra en un equipo diferente de Dynamics 365 Customer Engagement (on-premises).

    Para obtener más información, vea lo siguiente:

  • [Información general sobre las amenazas de seguridad de la aplicación web](/previous-versions/f13d73y6(v=vs.140)

  • Seguridad de aplicaciones web de ASP.NET

  • Introducción a la seguridad de aplicaciones web

Prácticas recomendadas de extensibilidad ISV

Uno de los principios clave de la extensibilidad ISV es que no se debe asumir que la solución ISV es la única instalada. A continuación se ofrece una lista de las prácticas recomendadas.

Prácticas recomendadas para usar los servicios web de Dynamics 365 Customer Engagement

Debe configurar las direcciones URL del servicio web de Dynamics 365 Customer Engagement (on-premises) en un archivo de configuración, por ejemplo, en un archivo app.config, para aislar el código de los cambios en la dirección URL. Por ejemplo, hay diferentes direcciones URL para los centros de datos de aplicaciones Dynamics 365 for Customer Engagement en todo el mundo.

¿Dónde se deben poner las aplicaciones web o páginas web personalizadas?

Consulte el tema Implementar el inicio de sesión único desde una página web ASPX o desde IFRAME.

¿Cómo se ejecuta un complemento cuando se actualiza la vista de cuadrícula de la aplicación web?

Registre el complemento en la solicitud de mensaje RetrieveMultipleRequest y no especifique un tipo de entidad durante el registro.

¿Cuándo se debe crear un nuevo sitio web?

Cree un nuevo sitio web para el código cuando algo de lo siguiente sea aplicable:

  • La aplicación se debe vincular a un dominio, un protocolo o un puerto distinto de la aplicación de Dynamics 365 Customer Engagement (on-premises); o debe ejecutarse en otro grupo de aplicaciones.
  • La aplicación puede existir y se tiene acceso a ella por sí misma. Por ejemplo, un portal que interactúa con Dynamics 365 Customer Engagement (on-premises) como servidor (mediante los servicios web) debe ser hospedado como un nuevo sitio web.
  • La aplicación siempre usa Active Directory o la autenticación integrada de Windows (no IFD) y el scripting entre dominios no es un problema. Por ejemplo, la aplicación interactúa con un servidor back end utilizando los servicios web e interactúa con formularios de Dynamics 365 Customer Engagement (on-premises). Una página hospedada en un IFRAME que se agrega a la aplicación de Dynamics 365 Customer Engagement (on-premises) que no interactúa con el formulario de Dynamics 365 Customer Engagement (on-premises) no se incluye en esta categoría.

Consultar también

Escribir código para Dynamics 365 Customer Engagement (Web Services)
Escriba código para formularios de Dynamics 365 Customer Engagement (on-premises)
Complementos para ampliar Dynamics 365 Customer Engagement (on-premises)
Actividades de flujo de trabajo personalizadas (ensamblados de flujo de trabajo)