En este artículo, no abordaré las funciones de negocio de IFS Cloud. En lugar de eso, compartiré lo que aprendimos en el plano técnico: configuraciones, informes, interfaces, modificaciones, flujos de trabajo, API y ciclo de despliegue.
Uno de mis clientes eligió IFS Cloud como parte de un proyecto de migración de ERP. El entorno utiliza actualmente la versión 25R2 y, en este cliente, dirijo el equipo de aplicaciones.
CRIMEntender CRIM
Uno de los primeros términos técnicos que se encuentran en un proyecto IFS es CRIM:
Configuración
Adaptaciones low-code, páginas, campos, entidades, proyecciones y BPA.
Informes
Quick Reports, Business Reporter, salidas documentales y reporting operativo.
Interfaces
API REST/OData, middleware, archivos planos e IFS Connect.
Modificaciones
Developer Studio, Marble, PL/SQL, compilaciones y entregas.
Esta clasificación parece sencilla, pero una misma necesidad puede implicar varios objetos técnicos. Añadir un campo, por ejemplo, puede requerir un atributo configurado, una configuración de página y posiblemente un flujo de trabajo de validación. Por lo tanto, un CRIM no siempre corresponde a un único objeto técnico.
CC de Configuration
Una configuración es una adaptación realizada sin modificar directamente el código estándar IFS. Una parte importante de este trabajo se puede realizar desde IFS Cloud Web.
Campos, entidades, páginas y proyecciones
Es posible añadir atributos personalizados, crear entidades personalizadas, configurar páginas o ampliar ciertas proyecciones. Sin embargo, debemos evitar un atajo común: una entidad no es simplemente una tabla y una proyección no es simplemente una vista SQL.
Una entidad representa un objeto de modelo de datos y puede depender de múltiples objetos de base de datos. Una proyección expone parte del dominio funcional como un servicio REST. Contiene conjuntos de entidades, pero también acciones, funciones, estructuras, enumeraciones y otros controles.
Cuando se publica una configuración, IFS puede generar los objetos de base de datos necesarios, actualizar los metadatos y hacer que los nuevos elementos sean accesibles en las proyecciones afectadas.
Para un desarrollador acostumbrado a explorar directamente las tablas de un RDBMS, comenzar puede resultar confuso. El modelo está documentado a través de entidades, proyecciones, información del sistema y la API Explorer, pero no siempre aparece como un diagrama relacional clásico.
BPA y flujos de trabajo
Las Automatizaciones de Procesos de Negocio, o BPA, se basan en un diseñador de flujo de trabajo inspirado en BPMN. Permiten añadir lógica a las operaciones realizadas en IFS Cloud sin personalizar inmediatamente el código estándar.
Hay tres tipos principales:
- Validation: controlar una operación e impedir su validación cuando no se respeta una regla;
- Process Enrichment: enriquecer o modificar los valores transmitidos durante el procesamiento;
- User Interaction: solicitar información adicional al usuario durante el proceso.
Los BPA son una verdadera fortaleza de IFS Cloud, pero no reemplazan un lenguaje de programación general. Las capacidades tienen límites claros y en ocasiones es necesario repensar la necesidad de permanecer dentro del alcance de la configuración.
Lobbies
Los lobbies son portales personalizados que brindan una visión general de un proceso, una función o un conjunto de indicadores. A los usuarios generalmente les gustan porque evitan pasar por varias pantallas para encontrar información importante.
Los Lobbies admiten parámetros de página. Estos parámetros pueden almacenarse en el perfil del usuario o transmitirse en una URL de navegación. Por otro lado, los controles propuestos no siempre ofrecen todas las funciones de una lista de valores de negocio. Por lo tanto, es posible que un usuario necesite conocer el código de una empresa, un sitio o un proyecto.
La mejor práctica es limitar la cantidad de parámetros, utilizar valores predeterminados relevantes y, cuando sea posible, crear enlaces que abran directamente el lobby con el contexto correcto.
RR de Reports
El término «report» abarca varias familias de herramientas en IFS Cloud. Es importante distinguir entre Quick Reports, informes operativos y herramientas de análisis más avanzadas.
Quick Reports
Los Quick Reports responden a la necesidad de informes ad hoc. Para una tabla simple, es posible utilizar una consulta SQL o Query Designer y luego exportar el resultado a Excel.
Son eficaces para producir rápidamente una lista, pero los parámetros pueden quedar inutilizables cuando se multiplican los filtros. Los valores predeterminados pueden ayudar, pero debes evitar convertir un Quick Report en una aplicación completa.
Para necesidades de Excel más avanzadas, IFS recomienda ahora Business Reporter. El antiguo complemento de Excel utilizado para informes operativos ha quedado obsoleto en varias versiones y no debe confundirse con Business Reporter.
Documentos e informes operativos
Documentos como facturas, pedidos o albaranes se incluyen en los informes operativos. IFS Cloud ahora ofrece dos herramientas nativas: IFS Report Designer, instalado en el puesto de trabajo, e IFS Report Studio – Designer, accesible desde la Web.
Cuando comenzó nuestro proyecto en 23R2, la experiencia con la herramienta disponible no cumplió con nuestras expectativas de estabilidad y productividad. Por ello hemos elegido una solución complementaria, Ootary, para determinadas salidas documentales y pantallas avanzadas.
Esta observación debe situarse en el tiempo: la oferta nativa ha evolucionado desde el inicio del proyecto, en particular con Report Studio. Una solución de terceros puede resolver una necesidad bloqueante, pero también introduce un nuevo entorno, un nuevo lenguaje, habilidades específicas y una dependencia adicional.
II de Interfaces
En nuestro contexto, los intercambios entre IFS Cloud y otras aplicaciones pasan principalmente a través del middleware Blueway.
La apertura de IFS Cloud es una de sus principales ventajas. API Explorer enumera las proyecciones y servicios de OData disponibles, con sus conjuntos de entidades y documentación. Las llamadas se basan en métodos HTTP clásicos e intercambios JSON.
Encontrar la API adecuada
Un método práctico es abrir la pantalla correspondiente, activar las herramientas de desarrollo IFS y observar las llamadas de la red. Entonces es posible abrir directamente la proyección correspondiente en API Explorer.
Este método permite comprender rápidamente qué hace la interfaz, pero la API utilizada por una página no es necesariamente la mejor API para la integración de sistema a sistema. IFS distingue en particular entre API Premium, API de integración, API estándar y API de Entity Service. La elección debería depender del caso de uso, la estabilidad esperada y el nivel de soporte.
IFS Connect
Cuando la integración se basa en mensajes, archivos o protocolos más tradicionales, IFS Connect actúa como broker de integración. Admite diferentes conectores, incluidos HTTP/HTTPS, FTP/SFTP, Mail y JMS, con mecanismos de transformación.
Por lo tanto, sigue siendo totalmente posible gestionar archivos planos cuando el sistema de destino no ofrece una API. Funciona, aunque este enfoque generalmente requiere más supervisión, gestión de errores y convenciones de nomenclatura.
MM de Modifications
Las modificaciones son el área en la que tengo menos experiencia práctica. Entra en juego cuando las herramientas de configuración ya no son suficientes y es necesario ampliar el funcionamiento interno de IFS Cloud.
En la documentación de IFS, este enfoque se denomina in-the-core extension o personalización. Se realiza con IFS Developer Studio y puede utilizar modelos IFS, Marble para el cliente, PL/SQL para la lógica del servidor y, en determinados casos, Java.
Los desarrollos deben realizarse en la capa de personalización, sin modificar directamente los archivos estándar. El desarrollo se realiza con IFS Developer Studio y puede utilizar PL/SQL para la lógica del servidor, así como Marble para las pantallas Web IFS Cloud.
El ciclo de Git, Sanity Build y Delivery
El proceso de entrega de un cambio está mucho más estructurado que una configuración realizada desde la interfaz. En nuestro proyecto, el proceso habitual es el siguiente:
- 1 crear una nueva rama en el repositorio Git de Customer Solution;
- 2 desarrollar el cambio y realizar las primeras pruebas en el entorno de Build Place;
- 3 hacer commit y enviar los cambios al repositorio;
- 4 crear una merge request, revisar el código y fusionar la rama con la rama principal;
- 5 ejecutar una Sanity Build sobre el commit correspondiente;
- 6 corregir los errores de generación, despliegue de base de datos o compilación hasta obtener el estado
san-OK; - 7 generar una Delivery desde Build Place;
- 8 probar la Delivery en los entornos previstos;
- 9 solicitar su despliegue en los entornos de Use Place, en el orden correcto: pruebas, staging o UAT y, después, producción.
Sanity Build no solo verifica que los archivos estén presentes. En particular, controla la generación del código de la base de datos, su despliegue y la compilación de la solución. Cuando tiene éxito, se genera una imagen de Sanity Build y el commit se identifica con la etiqueta san-OK. Este paso es esencial antes de preparar una entrega confiable.
No pretendo dominar toda esta parte: conozco el proceso y las etapas de entrega, pero las personalizaciones más estructurantes hoy en día las realiza principalmente nuestro integrador.
ACPTransportar configuraciones con ACP
Las configuraciones realizadas directamente en IFS Cloud deben organizarse y transportarse de un entorno a otro. Para ello, IFS ofrece los Application Configuration Packages, o ACP.
Un ACP puede contener varios tipos de objetos de configuración: atributos, páginas, proyecciones configuradas, flujos de trabajo, eventos u otros elementos admitidos.
Un punto importante: un objeto de configuración solo puede pertenecer a un ACP a la vez. Además, eliminar un objeto de un paquete fuente no lo elimina automáticamente del entorno de destino durante una importación posterior.
BDRIniciar los BDR lo antes posible
Termino con un consejo que concierne más al proyecto que al desarrollo: hacer que los usuarios trabajen en los BDR lo antes posible.
En el vocabulario IFS, los BDR corresponden a Basic Data Requirements, es decir, los datos de configuración necesarios para el funcionamiento de los procesos. Esto incluye, por ejemplo, códigos impositivos, condiciones de pago, grupos contables, estados, ubicaciones y muchos otros datos de referencia.
WEBUn recurso comunitario que nos ha ayudado enormemente
Durante el proyecto, el Blog de DSJ nos ayudó enormemente. La documentación oficial de IFS sigue siendo esencial, pero es muy amplia y a veces describe más las posibilidades de la plataforma que la forma concreta de resolver un problema encontrado en un proyecto real.
DSJ, en cambio, publica ejemplos directamente utilizables, con casos prácticos sobre flujos de trabajo, llamadas REST, autenticación, integraciones, resolución de problemas e informes. En varias ocasiones, sus artículos nos permitieron comprender rápidamente un mecanismo que nos costaba reconstruir únicamente a partir de la documentación.
Según nuestra experiencia, este blog nos ha resultado a menudo más útil que el foro IFS. El foro contiene mucha información interesante, pero algunas preguntas técnicas específicas pueden quedar sin respuesta durante mucho tiempo. Un artículo detallado, acompañado de un ejemplo completo y reproducible, proporciona mucho más valor que un hilo de discusión interrumpido después de la pregunta inicial.
Un gran agradecimiento al autor del Blog de DSJ por compartir este conocimiento. En un ecosistema tan vasto como IFS Cloud, este tipo de recurso independiente permite a los equipos de proyecto ahorrar un tiempo considerable.
✓Lo que aprendí de IFS Cloud
IFS Cloud es una plataforma poderosa y particularmente abierta. Su capacidad para crear configuraciones, automatizar procesos y exponer API facilita mucho los proyectos de integración.
Este poder viene con un vocabulario, un modelo de desarrollo y un ciclo de vida que lleva tiempo. Hay que aprender a elegir entre configuración, informe, interfaz y modificación, pero también aceptar que una necesidad aparentemente simple puede implicar varios componentes.
Nuestro equipo aprendió gran parte de estos conceptos directamente en la fase del proyecto. Ciertamente, este artículo todavía contiene simplificaciones, por lo que los comentarios y correcciones son bienvenidos en los comentarios.
Mientras escribo estas líneas, también participo en el Club de Usuarios de IFS Francia, lo que supone una excelente oportunidad para comparar nuestra experiencia con la de otros clientes.
↗Fuentes oficiales
- IFS Cloud – Tailoring Overview
- IFS Cloud – Build Place y Use Place
- IFS Cloud – Proyecciones y modelo de cliente
- IFS Cloud – API Explorer
- IFS Cloud – Automatización de procesos de negocio
- IFS Cloud – Paquetes de configuración de aplicaciones
- IFS Cloud – Desarrollo de soluciones para clientes y repositorios Git
- IFS Cloud – Sanity Builds
- IFS Cloud – Build Place Deliveries
- Blog de DSJ – Artículos técnicos dedicados a IFS
Comentarios
0 comentariosTodavía no hay comentarios publicados. Sé el primero en participar.