En este artículo, no discutiré la parte funcional de IFS Cloud. En lugar de eso, compartiré lo que descubrimos en el aspecto técnico: configuraciones, informes, interfaces, modificaciones, flujos de trabajo, API y ciclo de implementación.
Uno de mis clientes eligió IFS Cloud como parte de un proyecto de migración de ERP. El entorno ahora está en la versión 25R2 y, en este cliente, ocupo el cargo de gerente de la división de aplicaciones.
CRIMComprensión CRIM
Uno de los primeros elementos de vocabulario que se encuentran en un proyecto IFS es el término CRIM:
Configuración
Adaptaciones low-code, páginas, campos, entidades, proyecciones y BPA.
Informes
Quick Reports, Business Reporter, ediciones y reporting operativo.
Interfaces
API REST/OData, middleware, archivos planos e IFS Connect.
Cambios
Developer Studio, Marble, PL/SQL, compilaciones y entregas.
Esta clasificación parece sencilla, pero una misma necesidad puede movilizar varios objetos técnicos. Agregar un campo, por ejemplo, puede requerir un atributo configurado, una edició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 como configuración
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 agregar 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. Le permiten agregar lógica a las operaciones realizadas en IFS Cloud sin personalizar inmediatamente el código estándar.
Hay tres familias principales en particular:
- Validación: controlar una operación e impedir su validación cuando no se respeta una regla;
- Enriquecimiento de proceso: enriquece o modifica los valores transmitidos durante el procesamiento;
- Interacción del usuario: 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 posibilidades están enmarcadas 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 vestíbulos tienen configuraciones 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 la riqueza de una lista real de valores empresariales. 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 como informes
La palabra report cubre varias familias de herramientas en IFS Cloud. Es importante distinguir entre informes rápidos, informes operativos y herramientas de análisis más avanzadas.
Informes rápidos
Los informes rápidos satisfacen la necesidad de informes ad hoc. Para una tabla simple, es posible utilizar una consulta SQL o un Diseñador de consultas 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 informe rápido en una aplicación completa.
Para necesidades de Excel más avanzadas, IFS ahora dirige hacia Business Reporter. El antiguo complemento de Excel utilizado para informes operativos ha quedado obsoleto en varias versiones y no debe confundirse con Business Reporter.
Ediciones 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, instalada en la estación 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 ediciones y determinadas pantallas avanzadas.
Esta observación debe ser anticuada: la oferta nativa ha evolucionado desde el inicio del proyecto, en particular con Report Studio. Una solución de terceros puede evitar la necesidad de bloqueo, pero también introduce un nuevo entorno, un nuevo lenguaje, habilidades específicas y una dependencia adicional.
II como 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 uno de sus verdaderos momentos destacados. La 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 le 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 intermediario 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 monitoreo, manejo de errores y convenciones de nomenclatura.
MM para cambios
La modificación es la parte que menos domino en la práctica. Interviene 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 extender hacia el interior 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 parte del servidor, así como Marble para las pantallas Web IFS Cloud.
El ciclo de Git, Sanity Build y Delivery
El proceso de realizar un cambio está mucho más estructurado que una simple configuración realizada desde el principio. En nuestro proyecto, el avance teórico es el siguiente:
- 1 crea una nueva rama en el repositorio Git de Customer Solution;
- 2 realizar el desarrollo y las primeras pruebas en el entorno de desarrollo de Build Place;
- 3 confirmar y enviar cambios al repositorio;
- 4 cree una solicitud de fusión, verifique el código y luego fusione la rama con la rama principal;
- 5 lanza una Sanity Build en la confirmación en cuestión;
- 6 corregir cualquier error de generación, despliegue de base de datos o compilación hasta obtener un estado
san-OK; - 7 genera una Entrega desde Build Place;
- 8 probar esta entrega en los entornos previstos para este fin;
- 9 solicita su implementación en los entornos de Use Place, en el orden correcto: entorno de prueba, staging o UAT, luego 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 implementación y la compilación de la solución. Cuando tiene éxito, se produce una imagen de cordura y la confirmación se identifica con una 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.
ACPConfiguraciones de transporte con ACP
Las configuraciones realizadas directamente en IFS Cloud deben organizarse y transportarse de un entorno a otro. Para esto, IFS ofrece Paquetes de configuración de aplicaciones 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.
BDRInicie los BDR lo antes posible
Termino con un consejo que concierne más al proyecto que al desarrollo: conseguir que los usuarios trabajen en los BDR lo antes posible.
En el vocabulario IFS, los BDR corresponden a Requisitos de datos básicos, 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 repositorios.
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 el terreno.
Por el contrario, DSJ 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 una mecánica 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 este trabajo compartido. 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 recuerdo 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 movilizar varios ladrillos.
Nuestro equipo aprendió gran parte de estos conceptos directamente en la fase del proyecto. Ciertamente, este artículo todavía contiene simplificaciones. Por lo tanto, los cambios 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 – Descripción general de sastrería
- IFS Cloud – Build Place y Use Place
- IFS Cloud – Proyecciones y modelo de cliente
- IFS Cloud – Explorador de API
- 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 – Construcciones de cordura
- IFS Cloud – Build Place Entregas
- Blog de DSJ – Artículos técnicos dedicados a IFS
Comentarios
0 comentariosTodavía no hay comentarios publicados. Sé el primero en participar.