Una buena opción para hacer las primeras pruebas de nuestros desarrollos sobre Business Central es probar estos en un entorno local (como harías con otro tipo de desarrollos), pero, ¿Cómo hago para tener un Business Central en mi equipo?. Muy sencillo, usando Docker.
En este artículo te explico como configurarlo todo para que puedas hacerlo.
Sigue leyendo Business Central en nuestro equipo local con DockerEs mas que probable que si estas trabajando en expansiones de Business Central o en integraciones donde BC esté involucrado, en algún momento tengas que compartir o insertar datos desde un punto externo. Para ello, tenemos el objeto Page del tipo API, que nos permite exponer una API para consumir o insertar datos. Vamos a ver como consumir esta API.
Sigue leyendo Como consumir una API de Business CentralDynamics 365 CE permite muchas formas distintas para poder extender su funcionalidad y adaptarla a tus necesidades. Una de ellas es poder añadir un recurso web y mostrarlo en un formulario. Esto nos va a permitir crear nuestro propio HTML que se mostrará dentro de Dynamics.
En estos casos nos puede pasar que necesitemos mostrar en nuestro recurso web algún dato que se recupere del propio Dynamics.
Cuando estamos en el lado de cliente, Dynamics nos ofrece el objeto XRM y el FormContext para poder realizar acciones sobre los objetos del propio Dynamics y por lo tanto si tenemos que acceder a cualquier dato del formulario, podemos hacer algo tan sencillo como lo siguiente:
function displayName(executionContext)
{
var formContext = executionContext.getFormContext(); // get formContext
// use formContext instead of Xrm.Page
var firstName = formContext.getAttribute("firstname").getValue();
var lastName = formContext.getAttribute("lastname").getValue();
console.log(firstName + " " + lastName);
}
¿Pero que pasa cuando estamos en el contexto de nuestro recurso web? Pues que no tendremos dicho contexto y que por lo tanto, en este caso, no podemos acceder a estos datos. Pero es muy sencillo solucionar esto, vamos a ver como podemos pasar este contexto a nuestro recurso web para poder accederlo.
Sigue leyendo Pasar el contexto de formulario y XRM de Dynamics 365 a un WebResourceHola, el otro día estaba leyendo el libro de Satya Nadella (Pulsa refrescar, lo recomiendo mucho, esta regalado en Amazon) en el que habla de cómo ha liderado el cambio tanto tecnológico como cultural en Microsoft. Una de las cosas que dice es que a él lo que le funciona es la empatía, el ponerse en el lugar de los otros. Así que he reflexionado un poco sobre el tema y he pensado que tal vez, desde la parte tecnológica, a veces no se explica lo suficiente el porqué de ciertas decisiones que tomamos y, por lo tanto, no se están entendiendo desde áreas no técnicas. A veces es por nuestro ego (hablo por mí, por supuesto), el orgullo, la falta de empatía o el hecho de que tal vez no se nos escucha como se debería desde las áreas no tecnológicas. Tal vez la suma de todo.
He pensado que tal vez, explicando algunos casos de decisiones que he tomado con más detalle, sin hablar en idioma puramente técnico. Por lo tanto, voy a iniciar una serie de entradas en el blog en las que hablare de algunas decisiones que he tomado y el por que de estas. Tal vez tenga suerte y consiga un debate interesante.
Sigue leyendo Aventuras de un arquitecto: Por que decidí crear una capa de API Rest delante de un D365 Field ServiceEn la mayoría de los proyectos en los que he participado y que Dynamics 365 CE (aka CRM) estaba involucrado, en mayor o menor medida, hemos tenido que integrarnos con otros sistemas para cruzar datos entre ambos. Estas son algunas cosas que he ido aprendiendo y que me han ido enseñando (gente que sabe mucho mas de D365CE que yo) a lo largo de estos proyectos. Si estas leyendo esto y tienes algún tip mas, no dudes en ponerlo en los comentarios, !siempre será bienvenido!
Sigue leyendo 7 cosas a tener en cuenta al hacer integraciones con volúmenes altos de datos en Dynamics 365 CE (aka CRM)No soy yo muy fan del low code, pero oye, a veces me ha tocado usarlo. No negaré que puede llegar a tener sus ventajas en ciertos contextos y si sabemos ver cuando usarlo y cuando no, puede llegar a ser un buen acelerador. Una de las herramientas que se nos ofrece dentro de Power Platform (la plataforma low code de Microsoft) es Power Automate (antes llamados Flow), que a partir de la configuración de «cajitas» nos permite realizar ciertas acciones.
Una de las cosas con las que nos encontramos a tener que crear un flujo, es como gestionamos los datos cuando uno de los pasos que estamos configurando fallan. Cuando algo no va bien, el flujo se detiene y entrando en la página de gestión puedes ver el log y el histórico de ejecuciones, pero eso no suele ser suficiente.
Para tener un poco mas de control, podemos configurar dentro de la tarea que estamos creando, un comportamiento respecto a la ejecución anterior.
De este modo, podemos definir que la acción solo suceda cuando un estado concreto de la acción anterior se cumpla:
Así pues, podemos definir acciones para cuando la acción haya ido mal, y cuando haya ido bien, creando distintos caminos de comportamiento.
A partir de aquí, puedes realizar las acciones que necesites, como dejar un log en una Table Storage, un mensaje en Insights, un correo, etc…
¡Nos leemos!
Por temas de trabajo, últimamente tengo que estar tocando mucho temas de Dynamics 365 CRM y tengo que ver temas de integraciones, desarrollo de plug-in, Power Platform, etc., por lo que seguramente escriba unas cuantas entradas al respecto con cosas que tengo que usar en mi día a día o temas que voy aprendiendo. Una de las formas que tengo para asimilar conocimientos es ver si soy capaz de explicarlos en una entrada del blog.
La cosa es que estoy desarrollando un plug-in para CRM 365 y una herramienta poderosa para ver como va todo por detrás son las trazas (si… así es…).
Vamos a ver como activarlas para poder verlas.
Sigue leyendo Como activar las trazas de log de plug-in en Dynamics 365 Customer Engagement (CRM)