Moqui Ecosystem. Framework Open Source para desarrollo de ERP y similares.

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

1 / 45
Contenidos
1 ¿Qué es Moqui Ecosystem?
2 Modelo
Introducción
Personas y Organizaciones
Orden de compra-venta
Pagos
Productos y Activos
3 Funcionamiento
4 Anexos

2 / 45
Historia I
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,
notiﬁcaciones de usuarios, optimización de performance
(cache, transacciones, proﬁling)
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

3 / 45
Historia II
2016: Versión 1.6.0 a 1.6.2: REST API, performance,
seguridad
2016: Versión 2.0.0: Hazelcast, docker, notiﬁcaciones 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

4 / 45
¿Qué es Moqui? I
Framework
Agrupación de Herramientas pre-conﬁguradas y probadas
Conceptos consistentes: diseñado para trabajo conjunto
Código pequeño, ﬂexible y simple
Sin mapeo de objetos: entidades, servicios, JSON/XML,
screen/form, etc.
Basado en 15+ años de experiencia (Apache OFBiz),
cientos de implementaciones

5 / 45
¿Qué es Moqui? II
Ecosistema
Artefactos de Negocio: Mantle, SimpleScreens
Modelo de Datos basado en “The Data Model Resource
Book: A Library of Universal Data Models for All
Enterprises”, Len Silverston (2008)
bibl. de servicios, elementos UI reusables, plantillas de
documentos / reportes
Integraciones: EDI, Transbank, Factura Electrónica, . . .
Aplicaciones: HiveMind Service ERP, POP Commerce
Retail, ERP, POS
Localizaciones (l10n, i18n)
Licencia: CC0 + Patent Waiver

6 / 45
Características Moqui
Localización (l10n): múltiples idiomas, monedas, zonas
geográficas
Uso intensivo de cache para maximizar eficiencia
Sistema de permisos granular
Protección de exceso de accesos (tarpit) configurable con
múltiples criterios
Estadísticas de uso granulares
Servicios exportables directamente a través de API REST
Manejo de múltiples empresas relacionadas en el mismo
sistema
Acciones periódicas y frente a eventos
Envío y recepción de e-mails y otros canales de
comunicación

7 / 45
Proyectos Incorporados (1/2)
Apache Shiro (https://shiro.apache.org/): permite manejo de
autenticación conﬁgurable para usar OAuth u
otros esquemas
Apache Camel (http://camel.apache.org/): ruteo de mensajes
entre sistemas
Drools (https://www.drools.org/): procesamiento de reglas
de negocio, soporta integración con jBPM
Hazelcast (https://hazelcast.org/): clustering. Ejecución
distribuida de servicios asíncronos, invalidación
distribuida de caché de entidades, replicación de
sesiones web y cache distribuido (javax.cache)
JackRabbit repositorio de contenidos
(http://jackrabbit.apache.org/)
Atomikos / Bitronix gestión de transacciones
(https://www.atomikos.com/) /
(https://github.com/bitronix)

8 / 45
Proyectos Incorporados (2/2)
ElasticSearch indexación automática y búsqueda full-text
(https://www.elastic.co/products/elasticsearch)
Apache FOP generación de documentos como PDF
(https://xmlgraphics.apache.org/fop/)
Vue.js (https://vuejs.org/)
Bootstrap (https://getbootstrap.com/)
FreeMarker (https://freemarker.apache.org/)
JQuery (https://jquery.com/) para el front-end
QZ Tray uso de periféricos (impresoras, pesas, etc.)
locales al browser (https://qz.io/)
YotPo (user-generated content marketing, referrals, and
loyalty programs) (https://yotpo.com)

9 / 45
Objetivo
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
Manejar el modelo de datos (y su evolución) sobre una
variedad de soportes
H2, Derby; MySQL/MariaDB/Percona, Postgres, Oracle,
SQL Server, DB2, etc.

10 / 45
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
conﬁguraciones externas

11 / 45
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

12 / 45
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 conﬁguració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.

13 / 45
¿Cómo es desarrollar con Moqui?
XML para deﬁniciones generales
pantallas, formularios
entidades, relaciones, vistas
servicios, transiciones
Groovy para scripts cuando XML no basta
acceso a clases Java
En casos donde se necesita modiﬁcar comportamiento
default front-end:
Bootstrap / HTML / CSS
Javascript
Vuet
Freemarker (macros)
IDE de desarrollo (Intellij Idea, otros)
CI/CD (Gitlab)
Docker en producción, opción de standalone para
desarrollo

14 / 45
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

15 / 45
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 ﬂexibles
ayudan a buena integración de gran volumen de artefactos
de nivel superior

16 / 45
Ventajas de Open Source
Punto de vista del proveedor
Se comparte costos de desarrollo
Desarrollo conjunto con clientes
Visibilidad del proyecto
Desarrollo de capacidades locales
Reduce deuda técnica (mayor autoexigencia)
Uso de estándares abiertos, fácil integración
Punto de vista del cliente
Auditabilidad del código
Evita dependencia del proveedor
Flexibilidad en implementación
Se evita la “ingeniería en licencias”
Try before you buy
Sin obsolescencia programada

17 / 45
Contenidos
2 Modelo
Introducción
Pagos
Productos y Activos
3 Funcionamiento
4 Anexos

18 / 45
Contenidos
2 Modelo
Introducción
Pagos
Productos y Activos
3 Funcionamiento
4 Anexos

19 / 45
Modelo Flexible y General
Implica mayor complejidad, permite extensión y
adaptación a (¿casi?) cualquier caso
Pantallas generales (PopC-ERP, Hivemind) reﬂejan la
complejidad
Según el caso, complejidad se puede esconder si
solamente se tratan ciertos casos

20 / 45
Visión General y Externa
No se asume el punto de vista de LA organización
administrada por el sistema
Existen múltiples sujetos (Personas y Organizaciones)
Se registran relaciones y acciones entre sujetos
(compraventas, pagos, despachos, mensajes, préstamos,
contratos, participación en propiedad, . . . )
Las organizaciones (plural) internas son las administradas
con el sistema
Ej: Orden de Compra
Un sujeto proveedor, un sujeto cliente
Dependiendo de cuál es o no org interna, se mira como:
cliente es org interna: compra
proveedor es org interna: venta
ambas son org internas: compra o venta según punto de
vista
ninguna es org interna: transacción entre terceros

21 / 45
Múltiples Organizaciones Internas
Datos base son comunes (unidades de medida, tipos de
roles, definiciones de productos, listas de precio,
definiciones de usuarios, definición de cuentas contables)
de acuerdo al alcance de visibilidad que corresponde a
cada sujeto
Directorio de Sujetos es común (proveedores, clientes, etc)
Transacciones entre Org Internas: la compra por parte del
cliente aparece inmediatamente como la venta por parte
del proveedor
Administrador de BD tiene acceso a todos los datos
Permite selección de Organización Activa para utilizar
punto de vista de una Organización Interna específica

22 / 45
Contenidos
2 Modelo
Introducción
Pagos
Productos y Activos
3 Funcionamiento
4 Anexos

23 / 45
Sujetos: Personas y Organizaciones
Nombres usados en otros sistemas: principal, auxiliar, . . .
Sujeto: ente que participa de las acciones capturadas en
el sistema
puede ser de distinto tipo: Persona u Organización
tiene asociadas diversas dimensiones, ej:
métodos de contacto: direcciones postales, teléfono,
e-mail, mensajería instantánea, . . .
roles: Organización Interna, cliente, proveedor, afiliado,
cajero, . . .
información financiera-contable: formas de pago, cuentas
financieras, calificación de riesgo
información comercial-legal: contratos, acuerdos,
clasificación comercial
relación con otros sujetos: empleado, representante,
vínculo familiar, . . .
identificación
puede tener asociado un Usuario con el cual acceder al
sistema

24 / 45
Contenidos
2 Modelo
Introducción
Pagos
Productos y Activos
3 Funcionamiento
4 Anexos

25 / 45
Compraventa
Un sujeto no puede comprar algo si no hay alguien
vendiendo
Toda Orden es simultáneamente una compra y una venta
Usualmente un sistema muestra solamente un punto de
vista
Dependiendo del punto de vista puede considerarse:
Orden de Compra
Orden de Venta
Intercambio entre terceros

26 / 45
Orden
Tienda (física, virtual, . . . )
Moneda
Tipo (carro de compras, cotización, orden de
compra/venta)
Estado
Partes de Orden
Sujetos (cliente y proveedor)
Información de despacho (destino, instalación de origen)
Ítemes

27 / 45
Orden: Estados
En Modificación
Abierta (Tentativa) Estado inicial normal. Una orden que está
en estado borrador, no ha sido colocada por el
cliente.
Colocada El cliente ha colocado la Orden y espera la
confirmación del vendedor.
En Espera En espera de ser procesada por el vendedor.
En Proceso En proceso por parte del vendedor.
Aprobada La orden ha sido aprobada por el vendedor (ya
sea que está pagada o el vendedor acepta el
riesgo de un pago posterior al despacho).
Despachada La orden ha sido despachada, normalmente en
ese momento se emite la nota de cobro y factura
fiscal correspondiente.
Completa La orden ha sido recibida por el cliente.
Cotización Solicitada El cliente solicita el envío de cotización
formal.

28 / 45
Contenidos
2 Modelo
Introducción
Pagos
Productos y Activos
3 Funcionamiento
4 Anexos

29 / 45
Pagos I
Se hace seguimiento a los pagos antes de hacerse
efectivos
Estados
Propuesto El estado inicial del registro de un pago.
Información es tentativa generalmente está
siendo modiﬁcada antes de una promesa o
autorización.
Prometido El pago se ha informado, asociado a algún
propósito, tal como destinado a pagar una
orden. Ej: pagos con tarjeta de crédito
mientras autorización está en proceso.

30 / 45
Pagos II
Autorizado Caso pagos salientes: pago ha sido
autorizado para ser enviado al Sujeto
receptor.
Caso pagos entrantes: usado cuando existe
algún nivel de autorización (ej: procesador de
tarjetas de crédito)
Enviado Pagos salientes: ha sido enviado. Pagos
entrantes: ha sido recibido pero aún no
conﬁrmado.

31 / 45
Pagos III
Confirmado Pagos salientes: la contraparte ha confirmado
recepción conforme. Pagos entrantes: pago
confirmado, ej: después de conciliación
bancaria.
Cancelado Pago cancelado antes de enviar los fondos
Nulo Pago anulado antes de enviar los fondos
Rechazado Pago no pudo realizarse (ej: rechazo del
procesador de tarjetas, cheque protestado,
. . . )
Devuelto Pago fue devuelto del receptor al originador

32 / 45
Contenidos
2 Modelo
Introducción
Pagos
Productos y Activos
3 Funcionamiento
4 Anexos

33 / 45
Productos y Activos
Producto: descripción de una clase de objetos o servicios
que pueden ser vendidos, comprados, almacenados,
usados y/o fabricados
Características, dimensiones, contenidos (ej: manuales)
Tipos de producto: Activo, Uso de Activo, Bienes
Conﬁgurables, Digital (descarga), Activo Digital, Uso de
Instalación, Ensamblaje, Servicio, Virtual (con variantes)
Clase de producto: especíﬁca al dominio de aplicación del
sistema
Relación entre productos (sustituto, complemento,
incompatible, nueva versión, embalaje para, variante,
compuesto por, . . .
Activo
Con número de serie: cada objeto se mantiene trazable por
sí mismo
Cantidad: un grupo de objetos se mantiene como grupo
(lote)

34 / 45
Precios
Tipo Lista, Actual, Promedio, Promocional, Mayorista
Propósito Compra, Cargo Recurrente, Cargo por Uso
Proveedor Precio específico para proveedor determinado
Cliente Precio especfico para cliente determinado
Tienda Precio específico para tienda determinada
Cantidad Mínima Precio válido para al menos esa cantidad de
productos
Fechas Desde - Hasta

35 / 45
Contenidos
2 Modelo
Introducción
Pagos
Productos y Activos
3 Funcionamiento
4 Anexos

37 / 45
Contenidos
2 Modelo
Introducción
Pagos
Productos y Activos
3 Funcionamiento
4 Anexos

38 / 45
Glosario I
Activo Orig: Asset. Es una instancia específica de un
objeto o servicio descrito como Producto. , 42
Autenticación (authc) Aspectos de seguridad relacionados con
la identificación de un sujeto o sistema,
generalmente en base a sus credenciales (logging
in). 11
Autorización (authz) Aspectos de seguridad relacionados con
la autorización que tiene un sujeto o sistema
(control de acceso). 11
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. , 41

39 / 45
Glosario II
Distribuidor Orig: Supplier. Es un Sujeto hace de intermediario
entre el proveedor y el minorista. Típicamente se
reﬁere a productos y no servicios. , 43
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.
Orden representación de una compraventa, donde un
Sujeto que toma el rol de cliente compra un bien
que otro Sujeto, tomando el rol de proveedor,
vende.. 26

40 / 45
Glosario III
Organización Activa Organización Interna seleccionada
cuando un Usuario puede representar a más de
una, de forma que los contenidos son ﬁltrados
cuando es pertinente, para mostrar solamente los
relevantes para esa organización.. 22
Organización Interna Es un Sujeto cuyas actividades se
registran en el sistema, normalmente es la
organización que motiva la existencia del sistema,
o una parte relacionada.. 22, 24, 41
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. , 40
Product Class ver Clase de Producto.
Product Type ver Tipo de Producto.

41 / 45
Glosario IV
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 se modela
como un Activo. , 39
Proveedor (Provider) Orig: Provider. Es el rol que tiene un
Sujeto que provee servicios. , 42
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 deﬁne el nombre, código de barra,
inicio y ﬁn de comercialización, etc.. , 44
Provider ver Proveedor (Provider).

42 / 45
Glosario V
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. 24, 30, 40–42
Supplier ver Distribuidor.
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 Conﬁgurable, Digital
(descarga), Activo Digital, Uso de Instalación,
Ensamblaje, Servicio, Virtual (con variantes). , 41

43 / 45
Glosario VI
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 deﬁnición de roles
que le permite acceder a ciertas funcionalidades
del sistema. 24, 41
Vendor ver Proveedor (Vendor).

44 / 45
Contenidos
2 Modelo
Introducción
Pagos
Productos y Activos
3 Funcionamiento
4 Anexos

45 / 45
Moqui Ecosystem
Framework para crear Automatización de Procesos
Jens Hardings Perl <jhp@moit.cl>
Twitter: @jenshp
15 de mayo de 2019

Moqui Ecosystem. Framework Open Source para desarrollo de ERP y similares.

Más contenido relacionado

Similar a Moqui Ecosystem. Framework Open Source para desarrollo de ERP y similares. (20)

Más de Miguel Barrera_Maureira (7)

Último (9)

Moqui Ecosystem. Framework Open Source para desarrollo de ERP y similares.