Durante mucho tiempo, mi solución para el error handling era la que quizá usamos casi todos: enviar una notificación con el JSON de entrada y la excepción correspondiente. Funcional, sí. ¿Amigable? Para nada. Era una solución que, en lugar de cerrar un problema, abría una nueva conversación para "traducir" lo que había pasado.
Decidí ponerle fin a ese ciclo. Me di cuenta de que mi solución técnica no estaba resolviendo el problema humano. El usuario final no tiene por qué ser un experto en JSON para entender qué ha fallado.
Así que me puse manos a la obra. Con la ayuda de mi LLM de IA de confianza (puedes llamarlo Gemini, Copilot, ChatGPT...), me reté a mí mismo a encontrar una solución mejor. Reconstruí la lógica utilizando Groovy para hacer algo que parece magia: transformar ese "horrible" y confuso JSON en un precioso y limpio HTML.
Ahora, en lugar de un amasijo de texto técnico, el usuario recibe un correo con lista de campos y una tabla clara y ordenada. Puede ver de un vistazo los datos que envió y el mensaje de error exacto, sin necesidad de un traductor.
Los beneficios fueron inmediatos:
✅ Claridad total para el usuario final: Identifican el problema al instante (un dato incorrecto, el error que le sale en la app cuando hace el proceso en JDE …).
✅ Menos preguntas de "¿qué significa este error?".
✅ Una imagen mucho más profesional: Demuestra que cuidas la experiencia de usuario hasta en los momentos difíciles.
✅ ¡Es súper fácil de implementar!
Y como lo bueno se comparte, he preparado un paquete con el código Groovy y un Orchestrator de ejemplo para que puedas añadirlo como error handler en tus proyectos desde hoy mismo.
Lo puedes descargar gratis aquí
Y solo tienes que agregar el Orchestrator como error Handling, mapear el Json de Entrada, la Excepción y el nombre de la notificación
For a long time, my go-to solution for error handling was probably the same one most of us use: Send a notification with the input JSON and the corresponding exception. Functional? Yes. User-friendly? Not at all. 😬
Instead of solving the issue, it often sparked a new conversation just to translate what had gone wrong.
I decided to break that cycle. I realized my technical solution wasn’t solving the human problem. The end user shouldn’t need to be a JSON expert to understand what failed.
So I rolled up my sleeves. With the help of my trusted AI LLM (you can call it Gemini, Copilot, ChatGPT…), I challenged myself to find a better way.
I built the logic using Groovy, and what happened next felt like magic: That messy, cryptic JSON was transformed into a clean, beautiful HTML report ✨.
Now, instead of a wall of technical text, the user receives an email with a clear list of fields and a well-organized table. They can instantly see the data they submitted and the exact error message — no translator needed. 🧠📬
The benefits were immediate:
✅ Crystal-clear communication: Users instantly identify the issue (wrong data, app error in JDE, etc.)
✅ Fewer “What does this error mean?” questions
✅ A more professional image: Shows you care about user experience, even in tough moments
✅ Super easy to implement!
And because good things are meant to be shared, I’ve prepared a free package with the Groovy code and a sample Orchestrator so you can plug it into your projects today.
📥 Download it for free here
You only need add the orchestrator to the Error Handling put the input JSON, Exception Message and Notification Subject
Ahora en vez de recibir esto
Tú usuario recibirá esto
Dejar de pensar solo en que la automatización funcione y empezar a pensar en CÓMO la reciben nuestros usuarios es lo que realmente marca la diferencia.
Ahora te pregunto a ti: ¿Cuál ha sido la queja más "creativa" o divertida que has recibido de un usuario por un mensaje de error automático?