Pàgines

sábado, 17 de octubre de 2020

La clase de Coco: Establecer valor predeterminado vs. Establecer valor de campo

"Hola, soy Coco y hoy vamos a aprender la diferencia entre las acciones Establecer valor predeterminado y Establecer valor de campo en las Reglas de negocio de Dynamics 365".


Así empezaría la clase diaria Coco, nuestro amigo inseparable de Barrio Sésamo que llenaba las tardes de nuestra infancia y con el que tanto aprendimos muchos de nosotros.



Y la verdad es que, amigos míos, existe una diferencia entre estas dos opciones aunque sea sutil para muchos a la hora de crear una Regla de negocio que las contenga.

Yo antes pensaba que tanto daba establecer valores de una forma o otra, al final lo que quieres es que el campo tenga un valor que tu le marcas y punto. Pero claro, si las dos opciones hicieran lo mismo, se llamarían igual y no es el caso.

Vamos a ver cada caso.


Establecer valor predeterminado

Cuando aplicamos esta acción en una regla de negocio lo que estamos realizando es mostrar un valor en un campo de forma predeterminada. La idea es que la Regla de negocio debería cargar el valor de un campo en el formulario en el evento onLoad.

Esta opción es la opción por defecto que se usa en los Optionsets (Conjuntos de datos), pero la acción se puede usar con campos Numéricos, Texto, Fecha/Hora y Búsqueda.

Dependiendo del tipo de campo, el valor establecido puede variar, como por ejemplo, en un campo Fecha/Hora podrá definirse una fecha fija, se podrá elegir que copie el valor de otro campo de fecha, establecer una fórmula que sume o reste días a una fecha o a otro campo de fecha de la entidad o se podrá elegir realizar un borrado del valor del campo.

Pero en definitiva, lo que conseguimos aplicando este componente es asignar un valor al campo que se muestre en el formulario cuando se carga.


Establecer valor de campo

Esta acción la llevaremos a cabo en una Regla de negocio cuando queramos aplicar lógica de negocio e incluso no necesitemos tener el campo cargado en el formulario.

La Regla de negocio no hace falta que se ejecute en el onLoad, puede ser un campo de la entidad que requiere ese valor pero que ni siquiera se muestra. 

Esta acción lo que realiza es poner un valor que definamos en un campo de la entidad que definamos y las opciones que disponemos son iguales al anterior caso.


Mostramos un pequeño ejemplo en el que realizamos una comprobación, si un Caso tiene como Origen el valor Correo electrónico.

Si se cumple la condición lo que hace la acción Establecer valor de campo es establecer el valor del título con la cadena "[Mail]". Este campo Título no haría falta ni que se mostrara en el formulario si no quisiéramos.

Si no se cumple la condición, la acción Establecer valor predeterminado establecerá el campo Origen con la opción "Teléfono". Se cargará el formulario para que el usuario pueda tener este valor por defecto en el campo y lo pueda cambiar si lo desea.



Finalmente, para acordarnos de que opción es cual, si nos vamos al original, quizás la traducción en inglés nos quede más claro:

  • Establecer valor predeterminado = Set default value
  • Establecer valor de campo = Set field value

Pero cuando se traduce, el lenguaje se hace más ambiguo.


---

Enlaces con la información:

Set Default Value vs Set Field Value in Business Rule – Dynamics 365 CE https://dynatecon.com/2020/06/13/set-default-value-vs-set-field-value-in-business-rule-dynamics-365-ce/

Setting Field Values vs. Setting Default Values in Business Rules https://powerobjects.com/2015/02/05/setting-field-values-vs-setting-default-values-business-rules/

jueves, 6 de diciembre de 2018

Merged & Child cases

A veces pasamos por encima de las diferentes opciones que nos da Out of the box el sistema sin tener muy clara su funcionalidad y no sabiendo como aplicarla en nuestro caso.

En el trato de casos encontramos unas funcionalidades que casi siempre se obvian. Unas de ellas son los casos fusionados (merged cases) y los casos hijos (child cases).


[IMG] Merged cases

En la primera funcionalidad se trata de escenarios donde se abren múltiples casos sobre el mismo problema y se quieren relacionar los casos entre ellos.

Con los merged cases se puede relacionar dos o más casos a un caso que quede activo para trabajar, dejándo el resto como cancelados.

La segunda funcionalidad se puede aplicar cuando existe un caso que debe ser realizado por diversas personas o cuando la incidencia afecta a diferentes clientes.
Para trabajarlo de forma independiente, se crearía un caso hijo que pudiera ser tratado por diferentes agentes o se agruparían, creando una jerarquía de casos que permitiría simplificar las gestiones a realizar. Por ejemplo, se puede definir que cuando se cierre el caso padre se cierren los casos hijos o viceversa.

Adjunto el enlace al post que me ha dado la idea, por si queréis ampliar la información.

https://crmindian.com/2017/04/17/case-merged-vs-child-cases/

martes, 18 de septiembre de 2018

Ejecutar una regla de negocio cuando se crea un registro


Con la aparición de las reglas de negocio se ha conseguido introducir funcionalidades que antes eran complicadas para usuarios no programadores. Ahora, con esta funcionalidad, cualquiera puede crear reglas que permitan ocultar o mostrar campos, indicar la necesidad de un campo o bloquearlo si es necesario según las condiciones que le marcamos.

Son muy útiles para trabajar con formularios y poder establecer como los queremos y en que momento lo queremos.

Un problema que surge es cuando queremos ejecutar una regla de negocio en una entidad, se ejecutará en todos los casos y solo buscamos que se ejecute en un formulario en el momento de su creación, dejando aquellos que ya están creados con las condiciones que tienen.

Este problema surge porque las reglas de negocio se ejecutan en la carga del formulario y en el evento onChange de los campos y se ejecutaría para todas las veces que entrásemos en el formulario.

Un truquito muy interesante para solventar el problema es poder comprobar si el campo Fecha de creación (Created On) está vacío, el cual nos indicará que es un nuevo registro.

Adjunto un artículo donde se puede comprobar el funcionamiento descrito que puede ayudar en este caso y en diferentes casuísticas utilizando las reglas de negocio.

Referencias:

viernes, 8 de diciembre de 2017

Herramienta para formatear FetchXML (FetchXML Formatter Tool)

Siempre nos pasa lo mismo, encontramos una información que en un momento nos parece relevante y al cabo del tiempo la intentamos encontrarla, sin éxito. La hemos perdido entre toda la información que ha ido pasando por nuestras manos.

En este caso, hace aproximadamente un año, encontré una herramienta para ayudar a convertir el formato de FetchXML para utilizarlo como fragmento de código, FetchXML Formatter Tool.

Para ese uso se necesitan cambiar las comillas y otros caracteres que son incompatibles con el código, ya sea JavaScript o C#.

Esta es una sencilla herramienta independiente que copiando el texto del FetchXML te devuelve el texto formateado para el uso que se quiera dar (JavaScript o C#).


La herramienta se puede encontrar en la web de su autor.

FetchXML Formatter Tool en Arun Potti's MS CRM Blog

Quizás en XRMToolBox existe alguna herramienta parecida (aunque no exacta), pero al ser un pequeño ejecutable independiente puede ser más útil que tener que abrir toda la navaja suiza de soluciones.

Además, hoy he podido ver que han creado una versión en formato web, donde nos proporciona el código para C# y JavaScript en la misma página. La versión colgada en GitHub también ofrece la versión de JavaScript optimizada para JSLint.

FetchXML Formatter Tool online en Codepen
FetchXML Formatter Tool online en GitHub

jueves, 7 de diciembre de 2017

Scriptlets (USD)

Que ganas tenía de escribir sobre Unified Service Desk (USD) y hoy por fin puedo comentaros un tema que he estado buscando y que no acaba de estar correcto en diversos sitios (entre ellos Microsoft) o no se entendía bien en diferentes webs.

Desde que conocí USD me tiene enamorado. Se trata de un escritorio unificado sobre el que realizar aplicaciones conjuntas con CRM y otras aplicaciones externas. Además es muy flexible y permite crear nuevos componentes o eventos.

El problema que he encontrado es a la hora de realizar la llamada a un Scriptlet.
Un Scriptlet es un fragmento de código (habitualmente JavaScript) que se puede invocar y te devuelve un resultado que puedes utilizar mediante la sustitución de parámetros en una llamada a la acción en USD, por ejemplo.

En primer lugar, debemos ir dentro de CRM a Configuración -> Unified Service Desk y aquí buscar el elemento Scriptlets.


Aquí podremos crear un nuevo Scriptlet.


Rellenamos el campo Nombre que tendrá el Scriptlet (muy importante después recordarlo) y en el campo Texto del script colocaremos nuestro script de JavaScript.

Comenzaremos el script como si de una función de JavaScript se tratara y finalizaremos la función con la cláusula return. Dentro podemos utilizar los parámetros de sustitución de USD, lo que nos da una gran ventaja para tener los datos del contexto y poder tratarlos.
Después cerraremos el bloque de la función y realizaremos una llamada a la función escrita.

Os lo presento con un ejemplo:


En este caso quiero utilizar tres parámetros que me llegan por CTI en un solo parámetro para utilizarlo en una búsqueda.

En mi caso el parámetro que quiero devolver será la variable paramtosearch y en la última línea de la función realizo el return de la variable.
Posteriormente realizo una llamada a la función con la línea SCM_CTIParamMultisearch();.
Esto ejecutará la función y el Scriptlet me guardará el resultado como parámetro de sustitución de USD.

Para poder utilizar ese parámetro de sustitución en una llamada a la acción, en una comparación o en cualquier lugar donde pueda usar variables de sustitución de USD, debo utilizar el nombre que le dimos al Scriptlet (no el de la función).
En mi ejemplo será el siguiente:

[[$Scriptlet.SCM CTI CallType parameter for multisearch]]

Y si voy al debugger, puedo ver que se ha creado un nuevo parámetro llamado $Scriptlet que como clave el nombre del Scriptlet (SCM CTI CallType parameter for multisearch) y como valor el resultado de la función ejecutada.

¡Así de fácil y así de difícil!

Solo un apunte más. En el nombre del Scriptlet se pueden incluir espacios. USD lo reconoce sin problemas.




domingo, 4 de junio de 2017

CRM Saturday - Madrid

Ayer se celebró en Madrid el CRM Saturday (http://www.crmsaturday.com). Se trata de un evento organizado por Microsoft Dynamics Community MVP's para profesionales, consultores y desarrolladores de CRM y tiene como objetivo enseñar y compartir técnicas y habilidades, así como dar a conocer el Manifiesto de CRM para ayudar en los retos de las implementaciones de forma que estas sean exitosas.

La agenda llegaba cargada de buenos temas y grandes presentadores. En mi caso, tenía ganas de conocer a Neil Parkhurst, exponente para todos aquellos técnicos que traten Unified Service Desk, aunque ha tocado con maestría otros temas que también son muy interesantes de seguir.



Fue un gran día y debo confesar que mis expectativas se cumplieron con creces, pues no solamente pude ver las novedades en las que estaba interesado en acción y conocer el "making of" de todas ellas, sino que también me dieron a conocer nuevos elementos que estoy seguro que entrarán en breve en mi portfolio.

Por supuesto que fue para mí un gran lujo poder saludar a Neil y agradecerle todo su trabajo del cual me he nutrido en este tiempo, pero no quedó ahí la cosa, sino que conocí a Marco Amoedo y Mario Trueba en sus presentaciones, las cuales fueron un verdadero lujo, y pude conocer y charlar con Jordi Montaña o Demian Rasko, entre otros, además de charlas con los asistentes.

Me encanta la idea de la organización de los CRM Saturday de forma itinerante para facilitar la oportunidad de asistir a personas de los diferentes países. Espero que llegue la siguiente oportunidad para poder pasar un día completo sumergido en CRM, y quien sabe, quizás algún día esté arriba en el estrado presentando alguna novedad.


miércoles, 21 de diciembre de 2016

Entra en escena Microsoft Dynamics 365


El pasado 1 de noviembre Microsoft puso en escena a Microsoft Dynamics 365.

En Microsoft Dynamics 365 (Dynamics 365 para los amigos) la empresa de Redmon ha juntado CRM con nuevos y esperados módulos, ERP (AX7), conexión con Azure, Power BI, Microsoft Apps para crear aplicaciones, Microsoft Flows que ayudan a que los sistemas se entrelacen y otras más.

La verdad es que todos estamos abrumados y no dejamos de sorprendernos de la gran cantidad de herramientas nuevas que se han incorporado. Ahora se abre un nuevo universo para explorarlas y explotarlas a fondo para sacar el mayor jugo.

Todo corresponde con la nueva visión de Microsoft, entregar una nube empresarial inteligente, donde provee de un ecosistema la nueva plataforma y la engrandece con todas las opciones posibles.

Trabajamos duro para introducir los cambios y estoy seguro que más de uno ya los está esperando.

Seguimiento de actividades mediante publicaciones automáticas

Muchas veces encontramos en las escalas de tiempo (o timeline) de los diferentes registros un montón de publicaciones automáticas que o no n...