Prácticas recomendadas para desarrollar con Microsoft Dynamics 365
Publicado: enero de 2017
Se aplica a: Dynamics 365 (online), Dynamics 365 (on-premises), Dynamics CRM 2016, Dynamics CRM Online
En este tema se describen las prácticas recomendadas para personalizar Microsoft Dynamics 365 (en línea y local).
Importante
Revise Extensiones admitidas para Microsoft Dynamics 365 para obtener información sobre las técnicas compatibles e incompatibles para personalización.
En este tema
Prácticas recomendadas de rendimiento
Prácticas recomendadas de personalización
Prácticas recomendadas de seguridad
Prácticas recomendadas de extensibilidad ISV
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 Microsoft Dynamics 365 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 Microsoft Dynamics 365. 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 10 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 es una buena idea recuperar todos los metadatos con el mensaje RetrieveAllEntitiesRequest, especificando el filtro de entidad EntityFilters.All para la propiedad EntityFilters. En su lugar, es posible alcanzar mejor rendimiento si se limita el filtro de la entidad o se usa uno de los siguientes 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.
Limite las operaciones que llegan en cascada a las entidades relacionadas
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 el servidor Microsoft Dynamics 365 está instalado, puede ir al 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 Bypass proxy server for local addresses y proporcionar el nombre de dominio completo del servidor Microsoft Dynamics 365 en la lista de las excepciones. Esto proporciona un mejor rendimiento cuando los registros se crean con SDK de Microsoft Dynamics 365.
Mejorar el rendimiento de la asignación del canal de servicio
Puede establecer una conexión con los servicios web de Microsoft Dynamics 365 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 CreateManagement<TService> realiza la descarga de metadatos mientras el método Authenticate 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 Microsoft Dynamics 365.
Prácticas recomendadas para Microsoft Dynamics 365 (online)
Las notas del producto Patrones y principios de Microsoft Dynamics CRM Online para creadores de soluciones proporcionan instrucciones específicas sobre la creación de soluciones mediante Microsoft Dynamics 365 (online).
Uso de atributos y entidades personalizadas.
Use siempre el nombre de esquema de la entidad para hacer referencia a una entidad personalizada en código y consultas. No use el código del código de tipo de objeto (también llamado tipo de entidad) porque este 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 las muchas funciones integradas en una entidad existente. Por ejemplo, las entidades de oportunidad y caso tienen campos de búsqueda para asociar clientes. Los clientes pueden ser cuentas o contactos. No puede crear una entidad personalizada que tenga el mismo tipo de búsqueda. Puede cambiar el nombre para mostrar de una entidad del sistema para darle más sentido a su negocio.
¿Cuándo usar complementos y cuándo flujos de trabajo?
Como programador que está interesado en ampliar o personalizar Microsoft Dynamics 365, 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 Microsoft Dynamics 365 (online), se admiten los flujos de trabajo y los complementos, pero no las actividades personalizadas de flujo de trabajo.
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 Microsoft Dynamics 365 (SKU) |
Compatible en Microsoft Dynamics 365 (online) cuando está registrado en el espacio asilado. Puede ser compatible en instalaciones hospedadas por un asociado al criterio del asociado. |
Los flujos de trabajo son compatibles con todas las implementaciones de Dynamics 365. Las actividades de flujo de trabajo personalizadas se admiten en el espacio aislado de Microsoft Dynamics 365 (online) 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 para 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, Microsoft Dynamics 365 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 Microsoft Dynamics 365 incluyen lo siguiente:
Definir un plan aprobado de datos de seguridad en la implementación de Microsoft Dynamics 365 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. Para obtener más información, busque "contraseñas seguras" en la Ayuda de Windows.
Más información:TechNet: Consideraciones de seguridad para Microsoft Dynamics CRM
Roles, privilegios y derechos de acceso
Las prácticas recomendadas para garantizar la implementación del modelo de seguridad de Microsoft Dynamics 365 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 Microsoft Dynamics 365 incluyen lo siguiente:
No modifique la base de datos de Microsoft Dynamics 365 de ninguna forma salvo para usar el SDK porque hacerlo omite el modelo de seguridad de Microsoft Dynamics 365.
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 Microsoft Dynamics 365 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 Microsoft Dynamics 365 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 Microsoft Dynamics 365 directamente a través del Administrador corporativo de SQL Server. 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 de Dynamics 365 y Microsoft Dynamics 365 para 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 Microsoft Dynamics 365. 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 Microsoft Dynamics 365. 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:Escriba código para formularios de Microsoft Dynamics 365
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 confirmDialog 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 integrada de Windows, NTLM o la autenticación básica sobre Seguridad de la capa de transporte (TLS) o 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 Microsoft Dynamics 365.
Para obtener más información, consulte los siguientes recursos:
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 Microsoft Dynamics 365
Debe configurar las direcciones URL del servicio web de Microsoft Dynamics 365 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 tres centros de datos de Microsoft Dynamics 365 (online) en todo el mundo.
¿Dónde debe poner complementos y actividades personalizadas del flujo de trabajo?
Para complementos de disco local o actividades personalizadas de flujo de trabajo, ubique los ensamblados en la carpeta <installdir>\Server\bin\assembly.
¿Dónde se deben poner las aplicaciones web o páginas web personalizadas?
Consulte el tema Implemente el inicio de sesión único de una página Web o un IFRAME de ASPX.
¿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 Microsoft Dynamics 365; 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 Microsoft Dynamics 365 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 Microsoft Dynamics 365. Una página hospedada en un IFRAME que se agrega a la aplicación de Microsoft Dynamics 365 que no interactúa con el formulario de Microsoft Dynamics 365 no se incluye en esta categoría.
Ver también
Amplíe Microsoft Dynamics 365 en el servidor
Establecer mensajes de bit
Escriba código para formularios de Microsoft Dynamics 365
Escriba complementos para ampliar los procesos de negocio
Actividades de flujo de trabajo personalizadas (ensamblados de flujo de trabajo)
Microsoft Dynamics 365
© 2017 Microsoft. Todos los derechos reservados. Copyright