¡Un post cortito para hoy! Me topé con esto mientras configuraba la nueva función de Azure Synapse Link para Dataverse en un entorno.
La mayoría de las veces, cuando configuro recursos en Azure, lo hago como «Owner» de una suscripción o de un grupo de recursos. Esto significa que trabajo en modo dios todo el tiempo y no tengo algunos problemas que sí se encuentran los usuarios con menos derechos de acceso.
Después de mucho, mucho, mucho, mucho, mucho tiempo esperando, por fin está aquí la funcionalidad de desarrollo local de Dynamics 365 F&O… en preview pública. Es un poco diferente desde la primera vez que oímos hablar de esto en el MBAS de 2019… pero abre un nuevo escenario para los desarrolladores.
No voy a entrar en muchos detalles sobre la nueva experiencia unificada para desarrolladores, que así se llama ahora, pero si quieres saber qué necesitas para usarla y cómo configurarla, puedes leer esta entrada del blog de Aurélien Clere: Dynamics 365 FinOps Unified developer experience.
Hoy explicaré qué es Microsoft Dev Box y cómo podemos utilizarlo con las herramientas de desarrollo local de Dynamics 365 F&O. También conoceremos el coste, y en qué escenarios podríamos beneficiarnos de Microsoft Dev Box como nuestro entorno de desarrollo. Ya sabéis, lo mejor de los dos mundos, o lo peor… 🤣.
Pero antes…
Hoy vengo con un post sobre Dynamics 365 F&O, pero con el foco principal en la seguridad, concretamente en Microsoft Sentinel. Hace unos días se anunció que se había publicado una solución de Microsoft Sentinel para F&O que actualmente está en preview. ¡Vamos a aprender un poco sobre ella!
A veces pasamos por alto los aspectos de seguridad de las cosas que no están directamente relacionadas con F&O, especialmente en lo que se refiere a recursos como redes, cuentas de almacenamiento, máquinas de desarrollo, Microsoft Entra ID (¡este es el nuevo nombre de Azure AD!) o el uso de Bastion.
Y lo hacemos no porque no nos preocupe la seguridad, sino porque somos gente de Dynamics 365, y a veces puede que nos falten conocimientos en otras cosas. Si tienes suerte, contarás con un equipo de seguridad interno que se encargará de eso, si no, tendremos que aprender un poco.
Es la primera vez que uso Microsoft Sentinel, y seguro que me estoy perdiendo muchas cosas y funciones. Es hora de aprender.
Si estás integrando Dynamics 365 Finance & Operations con terceros, y tu organización o la del tercero están usando un firewall, puede que te hayas encontrado en el escenario de que te pregunten «¿cuál es la dirección IP del entorno de producción/sandbox?».
Pues bien, no lo sabemos. Sabemos que IP tiene ahora, pero no sabemos si tendrá la misma IP en el futuro, tendrás que hacer un monitoreo de esto si planeas abrir IPs únicas. Esto es algo que Dag Calafell escribió en su blog: Static IP not guaranteed for Dynamics 365 for Finance and Operations.
Así que, ¿qué tengo que hacer si tengo un firewall y necesito permitir el acceso a/desde Dynamics 365 F&O o cualquier otro servicio de Azure? Al equipo de red no le suele gustar la respuesta: si no puedes permitir un FQDN, debes abrir todos los rangos de direcciones para el centro de datos y el servicio al que quieres acceder. Y eso son muchas direcciones que hacen que el equipo de red se ponga triste.
En el post de hoy, os mostraré una forma de monitorear los rangos proporcionados por Microsoft, y espero que nos haga la vida más fácil.
AVISO: a raíz de este comentario en Linkedin quiero aclarar que estos rangos servirían para comunicación entrante a Dynamics 365 o el servicio que fuera. Para la comunicación saliente ver este documento en Learn: For my Microsoft-managed environments, I have external components that have dependencies on an explicit outbound IP safe list. How can I ensure my service is not impacted after the move to self-service deployment?
Llevamos mucho tiempo trabajando con las VM de desarrollo de F&O, sobretodo los partners de Microsoft que necesitan poder cambiar rápida y fácilmente entre diferentes entornos de clientes, y utilizar el VHD es un poco más complicado en ese escenario.
Y por supuesto, usamos RDP para conectarnos a estas VMs. RDP es poco seguro, debido a su débil cifrado, su uso generalizado y la falta de funciones de seguridad integradas en el protocolo. Por lo tanto, los hackers a menudo se centran en RDP para obtener acceso no autorizado a los sistemas. Puedes leer más sobre cómo proteger sus máquinas virtuales en Best practices for defending Azure Virtual Machines.
Hoy, vamos a ver los pasos para configurar Azure Bastion para las VMs de desarrollo de Dynamics 365 Finance and Operations.
¡Estoy de vuelta con información adicional sobre Azure API Management! Más contenido de Azure, y probablemente seguiré escribiendo más posts relacionados con Azure en el futuro.
Creo que hay muchas formas de aprender cosas nuevas, y para mí, dos de ellas son escribir artículos en el blog y utilizar nuevas tecnologías para resolver problemas en el trabajo. Por supuesto, mi objetivo es intentar aplicar los temas de Azure sobre los que escribo a Dynamics 365.
Hoy voy a presentar un enfoque de arquitectura para las integraciones, aprovechando el API Management y otros componentes de Azure, para Dynamics 365 o cualquier otra cosa que tenga un endpoint.
Puedes leer la segunda parte de este post en IaC con Bicep: despliega la arquitectura de Azure API Management.
En el post de hoy, quiero hablar del uso de Azure API Management (APIM) junto con Dynamics 365 Finance and Operations.
Azure API Management es una plataforma de gestión híbrida y multi-nube para APIs en todos los entornos. Esto significa que, después de desplegar una cuenta de APIM, puedes crear una API que puede servir servicios de un sistema o de varios.
Si quieres leer más sobre builds, releases y el ALM de desarrollo de Dynamics 365 puedes leer mi guía sobre MSDyn365 y Azure DevOps ALM.
Mover datos desde producción a un entorno sandbox es algo que tenemos que hacer regularmente para tener datos reales para testear o debugar. Es un proceso lento que requiere de bastante tiempo y que se puede automatizar como expliqué en el post LCS DB API: automatizando la copia de la DB de Prod a Dev.
En este post voy a añadir un paso adicional al refresco de la base de datos: restaurar un data package (DP). ¿Por qué? Porque estoy seguro que todos necesitamos cambiar parámetros o endpoints en los entornos de test después de un refresco desde prod.
Puedes leer más sobre la API REST del DMF, que voy a usar, leyendo este post de Fabio Filardi: Dynamics 365 FinOps: Batch import automation with Azure Functions, Business Events and PowerBI.
Puedes aprender más sobre la API REST de LCS leyendo estos posts que escribí hace un tiempo. Te puede interesar leerlos porque voy a dar por explicadas algunas cosas que voy a referenciar en este post:
Si habitualmente recibes los correos de notificación de LCS de tus proyectos ya sabrás esto: todas las máquinas Tier 1 gestionadas por Microsoft desaparecerán a partir del 1 de diciembre! Esto es lo que dice el correo: As communicated previously, Microsoft is removing the use of Remote Desktop Protocol (RDP) to access environments managed by Microsoft. As RDP access is required for development, going forward customers will be required to develop using a Cloud Hosted Environment…
Este es otro post sobre resolver problemas en Dynamics 365 usando herramientas externas. De todas formas, empiezo a dejar de pensar en todo lo relacionado con Azure como algo no externo. En este caso mostraré distintos escenarios usando Azure functions con Dynamics 365.
Escribí esto hace tres semanas y tenía la intención de que fuera un post de dos partes, pero después de ver este fantástico post sobre Azure functions de Fabio Filardi no sé si podría añadir nada más y probablemente lo deje aquí. ¡Leedlo!
En este post veremos qué son las Azure functions, cómo crear una localmente y publicarla en Azure.
Mi nuevo libro:
«Extending Dynamics Finance and Operations Apps with Power Platform»
¡Ya está a la venta!
