Tecnología

 

 

Componentes Tecnológicos

  • ADempiere es una solución 100% Java pura.
  • Basada en una tecnología de base de datos Oracle.
  • Soporte de la base de datos. - Postgresql -
  • El cliente está completamente escrito en Java.
  • Un cliente HTML para poder utilizar la aplicación donde la instalación de la misma no sea apropiada (Por Ej. Funcionalidad de auto servicio para proveedores, clientes o empleados).( Servlets Java y Páginas de Java Server).
  • El componente de Server Aplicativo JMX está implementado en Java basado en tecnología J2EE usando (server Jboss).
  • Parte de la funcionalidad aplicativa está implementada como PL/SQL.

 

   
   

Diccionario Aplicaciones

  • El diccionario de datos contiene las definiciones del tipo de entidad (tipo, validación, etc.).
  • Como debe ser mostrado (etiqueta en pantallas y reportes, ayuda, secuencia y posición relativa a otros campos), y las reglas de despliegue.
  • Las reglas de seguridad y acceso.
  • El Diccionario de datos es extensible por el usuario y puede contener reglas e información incluida por el mismo.
   
   

Interface de Usuario Inteligente

  • Interface de Usuario consistente: los usuarios puedan navegar rápidamente en áreas de aplicación poco familiares. 
  • La Interface Gráfica de Usuario utiliza la potencia de las PCs actuales y es preferible en situaciones donde una reacción y navegación rápida es importante. 
  • La Interface de Usuario HTML permite utilizar la aplicación en cualquier lugar donde pueda correr un browser (navegador) de Internet.
  • Es posible habilitar funciones del tipo Zoom desde cualquier lista desplegable. 
  • Se puede consultar registros. La consulta reduce el número de registros en una ventana al permitir introducir criterios en un estilo mejorado de "consulta por ejemplo" (query by example).
  • Los propios usuarios pueden adecuar el esquema de la ventana y pueden definir pantallas especiales para una situación o cliente específico cuando asi lo requieran.

 

   
   

Reportes Inteligentes

  • Listados reportes Visor OLAP Los reportes de ERP están basados en el diccionario de datos, dado que el visor de reportes tiene acceso a las definiciones, esto permite Profundizar (drill-down) en una entidad referenciada y Navegar (drill-across) entidades en donde la entidad reportada es utilizada. Los enlaces son generados automáticamente, al tiempo que se asegura la adherencia a las definiciones de seguridad y acceso.
  • Todas las salidas de los reportes pueden ser pre visualizadas en pantalla antes de ser impresas o de generar archivos en variados formatos (Ej.: Excel, HTML, XML, Word y PDF).
  • Profundizar (Drill-down) un nuevo reporte es generado, basado en la entidad seleccionada, los reportes en donde el número es una suma de números, o acceder desde un monto acumulado mensual a las transacciones originales.
  • Navegar Referencias (Drill-across)  le permite al usuario crear un nuevo reporte en donde una entidad específica esté siendo utilizada.
  • Los listados están basados en la información de las Ventanas. Ud. puede generar un reporte para cada pantalla del sistema.
  • Los reportes están usualmente basados en información agregada (sumarizada) y están basados en Vistas de Reportes.
  • El Visor OLAP permite visualizar diferentes dimensiones en una tabla o como un gráfico.
   
   

Arquitectura Sustentable

Las aplicaciones de negocio cambian a lo largo del tiempo. Necesitan utilizar nuevas tecnologías y proveer funcionalidad adicional y más inteligente. Las aplicaciones enlatadas deben incluso dar soporte a funcionalidad adicional, aunque usualmente no resulta apropiada para su integración con el núcleo funcional (Por ej.: adecuaciones y ciertas extensiones).

Adempiere usa los siguientes principios de diseño para crear una arquitectura sustentable:

Arquitectura Smalltalk MVC (derivación del Model-View-Controller -Modelo-Vista-Controlador-). Derivación asincrónica de procesos vía mensajes. Motor de Reglas Explícitas para lógica compleja. Transacciones y recuperación A prueba de fallas (Safe-fail).

ERP tiene una Arquitectura de Objetos (comparada con Orientada a Objetos, Como-si-Objetos o Arquitecturas Tradicionales). Cada Objeto es tan independiente como es posible de otros Objetos, incluyendo su derivación transaccional.

 

   
   

A Prueba de Fallos (Safe-fail)

Usualmente las aplicaciones están diseñadas para ser libres de fallas (fail-safe): Se asume que todo funciona y que todos los datos son ingresados correctamente y son consistentes. En caso de falla, los expertos deben buscar la causa y revisar si hubo daños. El usuario usualmente nota el problema. La realidad es que las aplicaciones a veces fallan.


En contraste ADempiere está diseñado para ser a prueba de fallas (safe-fail). Cada transacción puede ser repetida y regenerada. La mayoría de las fallas son identificadas por el sistema y el usuario puede intentar solucionar el problema. Si la recuperación no es posible, el error es aislado y el resto del sistema continúa trabajando.  El diseño de transacciones desacopladas es la base de esta habilitada.

El sistema verifica regularmente si una transacción está completa. Si una transacción no está completa y consistente debido a una falla del sistema, el administrador y el usuario son informados.


Mientras las aplicaciones devienen más complejas con combinaciones siempre crecientes, los errores potenciales crecen exponencialmente. ERP provee un marco de referencia de validación extensiva y en caso de que falle, aísla el problema asegurando una alta disponibilidad de las funciones centrales (núcleo aplicativo).

   
   

Seguridad

ADempiere soporta seguridad de datos y de funciones. La seguridad de funciones está basada en Roles de Usuario y controles de acceso a Ventanas, Reportes y Procesos.

La seguridad de los datos para la información del Cliente y la Organización es mantenida a nivel de la base de datos a través del contexto de seguridad. Este es un nivel adicional de seguridad más allá de la identificación (login) de usuario normal de la base de datos. Esto permite el uso de herramientas de terceras partes basadas en SQL para acceder a la base de datos. Antes de acceder a cualquier dato el usuario debe identificarse a través de una stored procedure (procedimiento almacenado) con nombre de usuario, contraseña, rol y opcionalmente idioma. Esto provee las mismas reglas de acceso para herramientas de terceros que puedan existir en la aplicación.

La mayor parte de las aplicaciones no tienen una capa de seguridad más allá de la identificación de usuario de la base de datos y tienen dificultad para restringir el acceso a través de herramientas SQL de terceros.

Las Contraseñas en los Clientes son guardadas de forma cifrada.