Moqui Framework - Intro in Spanish. By Jens Hardings of moit.cl

1. 1 / 17
Moqui Ecosystem
Framework para crear Automatización de Procesos
Jens Hardings Perl <jhp@moit.cl>
Twitter: @jenshp
8 de enero de 2019

2. 1 / 17
Parte I
Introducción a Moqui

3. 2 / 17
Contenidos
1 ¿Qué es Moqui Ecosystem

4. 3 / 17
Historia
2001: se crea OFBiz (Open For Business)
2006: OFBiz pasa a ser un proyecto de la Apache Software Foundation
2010: Inicio de desarrollo de Moqui
2011: Versión 1.0.0: versión inicial básica
2013: Versión 1.3.0 a 1.3.2: búsqueda full-text, notificaciones de usuarios,
optimización de performance (cache, transacciones, profiling)
2014: Versión 1.4.0: Bootstrap, gestión de transacciones, comunicaciones, . . .
2015: Versión 1.5.0 a 1.5.3: EntitySync, Impresión, Mensajería
System-System, mejoras de performance, estabilidad y escalabilidad
2016: Versión 1.6.0 a 1.6.2: REST API, performance, seguridad
2016: Versión 2.0.0: Hazelcast, docker, notificaciones vía websocket
2017: Versión 2.1.0: Client-rendering con Vue, gestión de BD y Wiki
Septiembre 2018: Moqui Ecosystem Open Source Conference en SLC, Utah
2018: Versión 2.1.1: Limpieza y consolidaciones

5. 4 / 17
¿Qué es Moqui?
Framework
Agrupación de Herramientas: librerías y productos externos ya pre-configuradas
y probadas
Conceptos consistentes: diseñado para trabajar en conjunto
Código pequeño, flexible y simple
Sin mapeo de objetos: entidades, servicios, JSON/XML, screen/form, etc.
Basado en 15+ años de experiencia con Apache OFBiz y cientos de
implementaciones
Ecosistema
Artefactos de Negocio: Mantle, SimpleScreens
Modelo de Datos: 499 entidades, 301 vistas
Librería de Servicios: 718 servicios
Elementos UI reusables: 226 pantallas, 690 formularios
Plantillas para documentos y reportes
Integraciones: EDI, Transbank, Factura Electrónica
Aplicaciones: HiveMind Service ERP, POP Commerce Retail, Wholesale ERP
Localizaciones (l10n, i18n)

6. 5 / 17
Objetivo: entrega
Construir artefactos de negocio aplicables a producción desde el día 1 de
desarrollo (después del análisis, diseño y capacitación)
Permitir foco en requerimientos del negocio en lugar de matices técnicos
Habilitar escalamiento de servicios en producción
Facilitar proyectos pequeños, iterativos y grandes

7. 6 / 17
Comparación con otros proyectos
Otros framework: Grails, Spring, Play, Zend, Rails, . . .
Generalmente enfocados en web y persistencia, sin capa de lógica
Mucho que interconectar y agregar para tener un conjunto completo de
herramientas
Esfuerzo relevante para iniciar
Desde simple: Autenticación (authc), Autorización (authz)
Hasta complejo: push data feeds, búsqueda, análisis, . . .
Alto volumen de código, muchos objetos, anotaciones y/o configuraciones
externas

8. 7 / 17
El método Moqui Ecosystem
Conjunto integral de herramientas, basadas en mejores prácticas
Convención sobre configuración, configuración sobre código
RAD basado en scripts/plantillas: cosas comunes fáciles, todo es posible
Persistencia transparente y simple, capa web/UI flexible
Capa lógica basada fuertemente en servicios con gatillos ECA; para usar
internamente o como web service; validada, segura, transaccional,
concurrente
Autorización consciente de artefactos de SW (entidades, servicios, pantallas,
API REST, etc.)
Artefactos comerciales preexistentes para centrarse en la diferenciación

9. 8 / 17
Mapeo de Objetos
¿Por qué no usar JPA, Hibernate, etc?
Sin mapeo objeto-relación (ORM), uso de estructuras de dato relacionales
Menos que escribir, depurar, mantener; reduce la persistencia a casi cero
API genérica y configuración para soportar persistencia, consultas, servicios
CrUD, REST y otras interfaces de Web Services, docuemntos JSON, push
data feeds y mucho más
Sin chequeo estático de tipos: igual que en bases de datos, web services,
etc; pruebas automatizadas son mejor práctica
Patrones similares en otros proyectos: sin objeto-servicios (como Restlet,
CXF); sin objeto-pantalla (como JSF, Struts), etc.

10. 9 / 17
Escalando: despliegue en hardware
Desde microservicios e instancias pequeñas hasta grandes volúmenes de
datos y usuarios.
Servicio basado en silo único (ejecución local) o en partición lógica
(ejecución remota)
El stack completo puede ejecutarse embebido (JVM única), stand-alone o en
cluster
Base de datos relacional (H2, Derby, MySQL/MariaDB/Percona, Postgres,
Oracle, SQL Server, DB2, etc.)
Base de datos NoSQL (OrientDB, otras)
ElasticSearch para búsqueda facetada (razonada) y análisis

11. 10 / 17
Escalando: tamaño del proyecto
Proyectos pequeños o iterativos y pequeños equipos
Construir, revisar, refactorizar, iterar en tiempo y esfuerzo mínimos
Expertos pueden construir a la velocidad de los requerimientos y diseños
Proyectos y equipos grandes
Herramientas de alto nivel y mejores prácticas mantiene consistencia de
artefactos
Modelo de datos y otros artefacots completos y flexibles ayudan a buena
integración de gran volumen de artefactos de nivel superior

12. 11 / 17
Parte II
Desarrollo con Moqui

13. 12 / 17
Parte III
Anexos

14. 13 / 17
Glosario I
Activo Orig: Asset. Es una instancia específica de un objeto o servicio
descrito como Producto. 1
Autenticación (authc) Aspectos de seguridad relacionados con la identificación de
un sujeto o sistema, generalmente en base a sus credenciales
(logging in). 1
Autorización (authz) Aspectos de seguridad relacionados con la autorización que
tiene un sujeto o sistema (control de acceso). 1
Clase de Producto Orig: Product Class. Una partición de los productos (un
producto puede pertenecer solamente a una clase). Es específica al
dominio, por lo que no existe una definición a priori en Moqui
Framework. 1
Distribuidor Orig: Supplier. Es un Sujeto hace de intermediario entre el proveedor
y el minorista. Típicamente se refiere a productos y no servicios. 1

15. 14 / 17
Glosario II
Fachada Orig: Facade. Una fachada corresponde a un punto de entrada que
se tiene a ciertas funcionalidades del sistema. El nombre proviene
del Patrón de Diseño Facade, y su objetivo es reducir la dependencia
y complejidad al interactuar con diferentes subsistemas. 1
Patrón de Diseño Los patrones de diseño son técnicas usadas para resolver tipos
de problemas que ocurren con frecuencia en el desarrollo y
arquitectura de software. 1, 10
Product Class ver . 1
Product Type ver Tipo de Producto (Product Type). 1
Producto Un producto en Moqui es la descripción de una clase de objetos o
servicios que pueden ser vendidos, comprados, almacenados,
usados y/o fabricados. Cualquier instancia real. 1, 10

16. 15 / 17
Glosario III
Proveedor (Provider) Orig: Provider. Es el rol que tiene un Sujeto que provee
servicios. 1
Proveedor (Vendor) Orig: Vendor. Es una persona u organización que vende
productos (activos) a un cliente. El proveedor es el “dueño” del
producto, es decir quien define el nombre, código de barra, inicio y fin
de comercialización, etc.. 1
Provider ver Proveedor (Provider). 1
Sujeto Orig: Party. Es un ente (persona u organización) que participa a
través de algún rol en los procesos relevantes al sistema. 1, 11
Supplier ver Proveedor (Distribuidor). 1

17. 16 / 17
Glosario IV
Tipo de Producto Orig: Product Type. Una partición de los productos que afecta la
forma en que Moqui los trata en los procesos standard. Ejemplos:
Activo, Uso de Activo, Bien Configurable, Digital (descarga), Activo
Digital, Uso de Instalación, Ensamblaje, Servicio, Virtual (con
variantes). 1
Usuario Un usuario es una persona (no una organización) que interactúa con
el sistema, y por tanto tiene credenciales (ej: nombre de usuario y
contraseña) con los cuales ingresar, y una definición de roles que le
permite acceder a ciertas funcionalidades del sistema. 1
Vendor ver Proveedor (Vendor). 1

18. 16 / 17
Moqui Ecosystem
Framework para crear Automatización de Procesos
Jens Hardings Perl <jhp@moit.cl>
Twitter: @jenshp
8 de enero de 2019