Aclaraciones de la arquitectura

Servidor de Datos

– Base de datos: SQL Server Express 2008 R2 with Advanced Tools: Se va a trabajar usando stored procedures y vistas, en ninguna parte del sistema se tendrá acceso a una tabla, esto permitirá al DBA dar soporte, configuración y adaptaciones sin afectar a la correcta operación del sistema, se escribirá el código para que los procesos administrativos requeridos luego de una transacción se ejecuten en un pool, por un agente SQL, en ambientes con muchos usuarios, el tiempo de respuesta luego de almacenada la transacción puede ser un problema si el servidor está en los límites de respuesta, por eso, las tareas administrativas serán realizadas posteriormente. Por ejemplo: registro del ingreso de una compra, el recalculo de los costos de inventario se haría por el pool, al completar el ingreso de la compra, se ordenara la ejecución del SP que hace el ajuste de costos, pero la ejecución será encolada para mantener un tiempo de respuesta predecible, en ambientes con poca carga transaccional, serán inmediatos. Trataremos en lo posible de convertir al SQL Server de un servidor de datos en un servidor de aplicaciones.

– Servidor de Entidades: Voy a usar nHydrate, es gratis y se ve bastante robusto, me gustaría utilizar IdeaBlade DevForce, pero la versión gratuita permite el tener solo 10 entidades simultáneamente y es un posible problema. En caso de necesitarse implementar ubicaciones múltiples, el servidor de entidades puede estar en un equipo diferente. Se comunicara usando WCF al servidor de datos.

Servidor de Aplicaciones

– Servidor y Repositorio de reportes, uno de los problemas que existe en implementaciones de ERP es la compartición de reportes, dashboards y PKIs, cuando un usuario cree un nuevo reporte tendrá la posibilidad de publicarlo, para todos los usuarios del ERP, para el grupo al que pertenece o solo para su uso, se escribirá el código para que un agente pueda disparar la generación automática del reporte en un horario planificado y enviar por mail a uno o varios destinatarios. El resultado del reporte será almacenado en el servidor documental y se dará acceso a los destinatarios y por mail ira el link para acceder al reporte. Deberá generar reportes en XBRL http://www.xbrl.org

– Servidor y repositorio documental, el tener acceso al archivo físico de un proyecto o contrato puede ser complejo, es mucho mejor que exista un repositorio documental que permita el disponer de forma inmediata la visualización de los documentos requeridos, en compras la imagen de la factura del proveedor, en proyectos es útil el contrato, en equipos los manuales de instalación, mantenimiento, publicidad del fabricante, copia del comercial que fue enviado a radio, prensa, televisión, etc, etc. Hay que crear un centro de registro documental, el cual recibe los documentos físicos, los indexa y asocia a los objetos del ERP y continúa el proceso definido.

– Project Server: en un sistema ERP se puede descontrolar la ejecución de tareas, y el ir documento por documento modificando las fechas esperadas de terminación o el registro del avance… puede tomar mucho tiempo, es mejor disponer de un servidor de proyectos que permita en forma visual ver la carga de trabajo de cada uno de los recursos de la organización y si se modifica una tarea, esta cambie los registros transaccionales automáticamente.

– Servidor contable: El sistema administrativo financiero, toda operación administraba tendrá su propio servidor, y los componentes serán creados como dad-in, esto dará la posibilidad de adicionar un tipo completamente nuevo de producto o forma de pago o proceso, en la mayoría de los procesos, básicamente será el gestor de llamadas el proceso que estará en el servidor SQL. Debe cumplir con las PCGA, FASB, NIIF y las normas legales de cada país.

– Orquestador de procesos y flujo de trabajo: la diferencia entre la empresa A y B, (en el mismo mercado vertical) suele ser a nivel de flujo de aprobaciones y autorizaciones, por eso, se construirá un BPM simplificado a la operación interna de la empresa, y su asociación con los roles y perfiles de usuarios, durante la ejecución del proceso el orquestador construirá el flujo del documento. El monitor permitirá el ver el estado de cada proceso, las personas que han participado y sus tiempos de respuesta. En caso que haga falta el administrador del proceso podrá reasignar a los participantes en un proceso específico, se necesita un control de versiona miento y de fechas de operación del proceso, para que el especialista en procesos pueda modificar con tiempo un proceso. Inicialmente los documentos que inicien en una versión del proceso, terminarán en esa versión, en la segunda edición del ERP se dará la posibilidad de mover flujos a versiones nuevas de procesos. Por propósito de este ERP, proceso es la definición conceptual de las relaciones entre documentos y las operaciones realizadas por los usuarios. Flujo es la ejecución real de un proceso.

Servidor de Integración y Seguridad (visible públicamente)

– Servidor de Comunicaciones, integración B2B y correo electrónico: todo ERP necesita estar comunicado, este servidor se dedicara a la recepción de correos, su asociación a un flujo, ruteo al funcionario responsable y en algunos casos la ejecución de comandos en el ERP, el poder exportar e importar documentos de otros sistemas y el enviar ofertas, copias de facturas u otro documento, reporte o imagen requerida. En caso de instalarse en un grupo empresarial, este servidor se encargará de los procesos de replicación e integración con el servidor central. Por ejemplo el servidor de un almacén, se conectará con el servidor central y se replicara para la integración.

– Servidor de identidades: Al ingresar un usuario al sistema se generará una identidad digital que tendrá limitaciones temporales para reducir la posibilidad de intrusión, a futuro se integrara con Directorio Activo y LDAP. Control de perfiles, roles, usuarios, niveles de acceso y en caso de definirse información sensible, la petición de autorización de acceso. Un ejemplo: en un almacén el cajero necesita eliminar o cambiar una venta, el administrador puede autorizar desde la caja o desde su consola, lo ideal: desde su celular o Tablet.

– Servidor de log, trace y monitoreo: permitirá el tener un control externo de todas las operaciones de todos los servicios y servidores que están en el sistema, el nivel de granularidad de monitoreo deberá llegar a niveles que permitan inclusive el visualizar de forma remota la estación de un funcionario en específico y verla en tiempo real o cuando sea necesario, debe integrarse al servidor de identidad.

– Servidor de sesiones y certificados transaccionales: el mayor problema es el controlar que se complicado el que un intruso pueda realizar operaciones no autorizadas, una forma que he utilizado es utilizando identidades digitales generadas al hacer login al sistema, más un certificado generado por cada sesión (por ejemplo: al crearse una nueva orden de compra, se crea el certificado de esa operación) que estará activo mientras esa operación no se complete y un certificado adicional de muy corto tiempo de vida para iniciar el proceso de conexión con el servidor o servidores que deben realizar la operación. Básicamente: con el certificado de identidad se solicita la creación del certificado de sesión y con estos dos se realiza la operación: begin – commit en la base de datos, al completarse el commit o rollback, el certificado de transacción desaparece, de esta forma un intruso debería tener pocos segundos para robar el certificado y hacer algo no autorizado.

– Servidor ECM – Enterprise Content Manager – Portal, blogs, foros: Ahora se necesita el mantener portales de la empresa para el público, portales para los socios de negocio (clientes, proveedores, socios) y para el personal de la empresa, lo ideal sería utilizar SharePoint framework, pero encontré un ECM en open source y estoy analizando si se utiliza ese o SharePoint. Aun no estoy seguro del licenciamiento de SharePoint para acceso web, de esto dependerá si se usa o no.

En la maquina cliente: Servicio de identidad y el Shell de la aplicación: En las estaciones de trabajo, puede volverse tedioso el esperar que se comunique el Shell con los servidores, para facilitar este proceso se escribirá un servicio Windows que se mantendrá conectado con el servidor de identidad, reduciendo este tiempo y debe ser un cliente el orquestador. Además debe realizar las actualizaciones de los componentes en caso que algún dll o configuración sea cambiada.

TODOS los servidores se conectarán entre si usando ESB (Enterprise service bus), básicamente existirá un solo servicio web (por servidor) para todo el ERP, excepto entre el servidor de entidades y el servidor de datos que será un canal WCF.

Desde el inicio se tendrá esta arquitectura, las funcionalidades de cada uno de los servidores será extendido hasta lograr el cumplimiento de los requerimientos. De inicio: servidor de identidad, servidor ESB, servidor contable, servidor entidades y servidor de bases de datos, servicio de identidad y Shell de la aplicación.

Esta arquitectura permite el crear anillos de confianza entre los servidores, lo ideal sería: maquina cliente -> firewall (control de intrusos) -> servidor de integración -> firewall interno (control de accesos no autorizados) -> servidor de aplicaciones (red interna) -> firewall (control de auditoria) -> servidor de entidades -> servidor de datos.

Esta arquitectura permite cumplir con las normas Sarbanes-Oaxley. http://es.wikipedia.org/wiki/Ley_Sarbanes-Oxley, y las normas internacionales se Auditoría Informática y Auditoría forense.

Todas las reglas de negocio estarán en archivos XML (criptografiados) para su facil distribución y uso. 

 

8 thoughts on “Aclaraciones de la arquitectura

  1. Una pregunta Ivan, que llevo varios post leidos pero no me aclaro. Tú pretendes hacer esto?
    en ese caso, tú solo o con más gente? (especificar cuanta en este caso)
    Por ultimo, cúal es la fecha de finalización prevista?

  2. Soy el único dedicado a la parte de arquitectura, 3 personas estan colaborando en función de su tiempo libre, no se cuando se termine todo, pero como objetivo es tener lo básico de un ERP: SDK, BPM, orquestador, Contabilidad General, Clientes (ventas), Proveedores (Compras), Inventarios, Rol de Pagos para septiembre de 2011.

    Estoy publicando en este blog con la esperanza de obtener apoyo de otras personas para implementar los servidores.

    Para septiembre de 2012 se deberia tener el release 1.0 con todos los servidores funcionales.

  3. Ivan, en mi opinión personal, espero que no te lo tomes a mal, estas cometiendo varios errores, a primera vista esto parece un batiburrillo de tecnologías mezcladas que no conducen a nada, no defines tu modelo de arquitectura básico, creas dependencias con herramientas de terceros sin valorar su coste, creo que debes replantearte completamente el proyecto, así difícilmente podréis llevarlo a cabo, intentas dar solución a todas las capacidades de un ERP, esto algo imposible, créeme he construido varios, no trato de desanimarte, pero sinceramente me parece completamente erróneo tu planteamiento, dices además que esto lo desarrollaran 3 personas en sus ratos libres, no hablas del coste del proyecto, de metodologías de trabajo, de escalabilidad, de desacoplamiento, de pruebas unitarias y de otros muchos aspectos fundamentales en la definición de la arquitectura, solo hablas de tecnologías y herramientas de terceros que te permitirán abordar un desarrollo como el que expones, siento decirte que tal y como planteas el proyecto es imposible que puedas llevarlo a cabo, espero que este post te anime a reflexionar, y no te tomes a mal esta crítica.

    Un saludo.

  4. Gracias por el comentario, no lo tomo a mal, este blog es para poner en un foro externo lo que se quiere hacer, en esta etapa estoy exclusivamente visualizando los componentes a nivel de servidores y servicios y de la estructura de capas a nivel de cada uno de éstos.
    En los últimos años he escrito varios sistemas administrativos, MRP y MRP II y un ERP (tomo 4 años y un equipo de 10 en desarrollo y 12 personas en QA y documentación). No estoy tratando de hacer algo parecido a Axapta o SAP, sino un ERP funcional totalmente en C# usando componentes ya disponibles en codeplex, codeproject, sourceforge y otros repositorios.
    Si tienes tiempo e interés, me gustaría invitarte a colaborar, es refrescante el tener con quien compartir y debatir ideas.

  5. Gracias, a fines de este (31/03/2011) hare público el proyecto en codeplex con el código inicial. A esa fecha debo tener el servidor ESB, la base de datos con las definiciones de «Party», Empresa, Ubicación, Usuario-Rol-Perfil, Repositorio documental y un Shell que permita hacer login y administrar las entidades indicadas.

  6. Le animo a segui con esta tarea, a pesar de las críticas, que puedo entender, pero lo importante es tener algo funcional y aprovechar los distintos recursos existentes de terceros de codeplex,codeproject… lo veo muy instructivo (de lo mejor en geeks.ms que he vistoen mucho tiempo, ojalá continue).

    Y cierto que esas críticas pueden ser entendibles, pero comprendo que no se q uiera llegar a un nivel profesional de ERP, que haya que definir bien la arquitectura…pero lo que se expone en los posts hasta ahora da una idea general de lo que se quiere hacer, y se hace la boca agua pensando que con todos esos componentes de terceros se pueda llegar a hacer algo potente.

    salu2&grz

  7. Unos diagramas de la arquitectura ayudarían mucho a verlo globalmente, con tantos servidores me pierdo un poco. Salu2grz

Leave a Reply

Your email address will not be published. Required fields are marked *