Diferencia entre revisiones de «OpenERP»
Sin resumen de edición |
Sin resumen de edición |
||
| Línea 25: | Línea 25: | ||
L’OpenObject facilita diversos components que permeten construir l’aplicació: | L’OpenObject facilita diversos components que permeten construir l’aplicació: | ||
[[Archivo:MVCDiagram.png| | [[Archivo:MVCDiagram.png|thumb|Arquitectura MVC]] | ||
* La capa '''ORM''' (Object Relational Mapping) entre els objectes Python i la base de dades '''PostgreSQL'''. El dissenyador-programador no efectua el disseny de la base de dades; únicament dissenya classes, per les quals la capa ORM d’OpenObject n’efectuarà el mapat sobre el SGBD [[PostgreSQL]]. | * La capa '''ORM''' (Object Relational Mapping) entre els objectes Python i la base de dades '''PostgreSQL'''. El dissenyador-programador no efectua el disseny de la base de dades; únicament dissenya classes, per les quals la capa ORM d’OpenObject n’efectuarà el mapat sobre el SGBD [[PostgreSQL]]. | ||
* Una arquitectura '''MVC''' (model-vista-controlador) en la qual el model resideix en les dades de les classes dissenyades amb Python, la vista resideix en els formularis, llistes, calendaris, gràfics… definits en fitxers XML i el controlador resideix en els mètodes definits en les classes que proporcionen la lògica de negoci. | * Una arquitectura '''MVC''' (model-vista-controlador) en la qual el model resideix en les dades de les classes dissenyades amb Python, la vista resideix en els formularis, llistes, calendaris, gràfics… definits en fitxers XML i el controlador resideix en els mètodes definits en les classes que proporcionen la lògica de negoci. | ||
Revisión del 18:48 5 sep 2013
OpenERP és un producte de codi obert que es distribueix sota dos tipus de desplegament: On-premise, sota els SO Linux i Windows, amb dues versions (Community, gratuïta, i Enterprise, de pagament); i el SaaS.
La llicència de la versió 6 i 7 és és AGPLv3 o AGPL+Private User.
L’OpenERP és desenvolupat sota una arquitectura web client-servidor de tres capes:
- La base de dades en un servidor PostgreSQL
- Un servidor OpenERP que conté tota la lògica de negoci
- Un servidor web, que en la versió 6.x està ubicat conjuntament amb el servidor OpenERP
- La capa client que té diverses possibilitats: web, GTK i possibles clients desenvolupats amb els protocols XML-RPC i Net-RPC
Instal·lació
Podem seguir aquest manual https://doc.openerp.com/7.0/es/install/#installation-link
Explotació i adequació
L’explotació i adequació de l’ERP d’una organització és una tasca imprescindible, ja que garanteix que el programari es mantingui en condicions de ser utilitzat per l’organització per tal de donar sortida a les seves necessitats. Per poder-ho dur a terme, per una banda cal identificar les necessitats (tasca pròpia de consultors) i, per una altra, tenir un coneixement profund de l’ERP, tant en les funcionalitats que facilita (tasca de consultors i implantadors) com en les qüestions tècniques vinculades a l’ERP (tasca d’analistes i programadors).
L’OpenERP és un programari de gestió empresarial desenvolupat sobre el framework OpenObject de tipus RAD (Rapid Application Development).
La facilitat dels entorns RAD rau en el fet que el desenvolupament d’aplicacions és molt simple pel programador, de manera que amb poc esforç es pot obtenir aplicacions d’altes prestacions.
L’OpenObject facilita diversos components que permeten construir l’aplicació:
- La capa ORM (Object Relational Mapping) entre els objectes Python i la base de dades PostgreSQL. El dissenyador-programador no efectua el disseny de la base de dades; únicament dissenya classes, per les quals la capa ORM d’OpenObject n’efectuarà el mapat sobre el SGBD PostgreSQL.
- Una arquitectura MVC (model-vista-controlador) en la qual el model resideix en les dades de les classes dissenyades amb Python, la vista resideix en els formularis, llistes, calendaris, gràfics… definits en fitxers XML i el controlador resideix en els mètodes definits en les classes que proporcionen la lògica de negoci.
- Un sistema de fluxos de treball o workflows.
- Dissenyadors d’informes.
- Facilitats de traducció de l’aplicació a diversos idiomes.
Tal com es pot observar, són molts els components d’OpenObject a conèixer per poder adequar l’OpenERP a les necessitats de l’organització, en cas que les funcionalitats que aporta l’OpenERP, tot i ser moltes, no siguin suficients.
La base de dades d'OpenERP
En l’OpenERP no hi ha un disseny explícit de la base de dades, sinó que la base de dades d’una empresa d’OpenERP és el resultat del mapatge del disseny de classes de l’ERP cap el SGBD PostgreSQL que és el que proporciona la persistència necessària per als objectes.
En conseqüència, l’OpenERP no facilita cap disseny entitat-relació sobre la base de dades d’una empresa ni tampoc cap diagrama del model relacional.
Si sorgeix la necessitat de detectar la taula o les taules on resideix determinada informació, és perquè es coneix l’existència d’aquesta informació gestionada des de l’ERP i, per tant, es coneix algun formulari de l’ERP a través del qual s’introdueix la informació.
L’OpenERP possibilita, mitjançant els clients web i GTK, recuperar el nom de la classe Python que defineix la informació que s’introdueix a través d’un formulari i el nom de la dada membre de la classe corresponent a cada camp del formulari. Aquesta informació permet arribar a la taula i columna afectades, tenint en compte dues qüestions:
- El nom de les classes Python d’OpenERP sempre són en minúscula (s’utilitza el guió baix per fer llegible els mots compostos) i segueix la nomenclatura nom_del_modul.nom1.nom2.nom3… en la qual s’utilitza el punt per indicar un cert nivell de jerarquia. Cada classe Python d’OpenERP és mapada en una taula de PostgreSQL amb moltes possibilitats que el seu nom coincideixi amb el nom de la classe, tot substituint els punts per guions baixos.
- Els noms dels atributs d’una classe Python sempre són en minúscula (s’utilitza el guió baix per fer llegible els mots compostos). Cada dada membre d’una classe Python d’OpenERP que sigui persistent (una classe pot tenir dades membres calculades no persistents) és mapat com un atribut en la corresponent taula de PostgreSQL amb el mateix nom.
La classe Python sale.order d’OpenERP està pensada per descriure la capçalera de les comandes de venda i la corresponent taula a PostgreSQL és sale_order.
D’aquesta manera, coneixent el nom de la classe i el nom de la dada membre, és molt possible conèixer el nom de la taula i de la columna corresponents. Es pot configurar els clients web i GTK per tal que informin del nom de la classe i de la dada membre en situar el ratolí damunt les etiquetes dels camps dels formularis.
Figura 1.1 Activar el debug mode
Si observem la figura 1.2, podem observar com:
Dalt apareix un desplegable que diu depurar#574, és la vista per defecte per a analitzar els elements dels formularis.
El camp Referencia cliente es diu client_order_ref de l'objecte sale.order. Per tant, la columna client_order_ref de la taula sale_order.
Figura 1.2 Dades de depuració
Respecte al desplegable de dalt, la resta d'opcions són:
- View Fields que permet obtenir una llista dels camps de la vista actual, amb els paràmetres corresponents.
- Fields View Get que mostra l’XML generat per la vista actual. Cal tenir en compte que si la vista s’ha generat a partir de diverses vistes XML heretant les unes de les altres, aquí se’n mostra el resultat final.
- Manage Views que mostra un llistat de les vistes relacionades amb la vista actual. Des d’aquest punt es poden crear noves vistes, eliminar-les o editar-les, encara que és recomanable utilitzar aquesta funcionalitat només per consultar. Es recomana realitzar les modificacions creant nous mòduls, per no perdre les modificacions davant actualitzacions de l’ERP.
- Edit TreeView, Edit SearchView, Edit Action i Edit Workflow que serveixen per accedir a l’edició de les vistes relacionades amb la vista actual.
- Si estem editant un registre (mode formulari) o consultant-lo (mode pàgina), apareix una nova opció View Log (perm_read) que mostra informació relativa al registre actual.
Accés de només lectura a les dades
Les empreses acostumen a tenir, entre els seus responsables, usuaris finals que poden efectuar consultes no previstes a la base de dades i que, per aconseguir-ho, poden utilitzar eines gràfiques per elaborar consultes o fins i tot, si són prou espavilats, executar consultes SQL des d’una consola d’accés.
En aquesta situació, cal facilitar als usuaris que correspongui, un usuari per accedir al SGBD PostgreSQL amb els privilegis d’accés, en mode consulta, als objectes de la base de dades que correspongui. S’aconsella seguir els següents passos:
1. Crear els usuaris de SGBD amb les contrasenyes que corresponguin.
Amb pgAdmin és fàcil d'afegir un nou rol de login.
2. Donar els privilegis d’accés adequats als usuaris que corresponguin.
Desenvolupament de mòduls en OpenERP
Començarem amb la presentació de l’eina de diagramació Dia Diagram Editor, que permet efectuar dissenys UML i per a la que existeix un connector (pluggin) que permet generar mòdulsd’OpenERP a partir dels dissenys efectuats amb Dia.
Aprofundirem en el disseny de mòduls, generant-los directament amb la utilització dels llenguatges Python i XML.
Diseny de mòduls amb DIA
Dia és una aplicació gràfica de propòsit general per a la creació de diagrames, desenvolupada com a part del projecte GNOME. Està construïda de forma modular, amb diferents paquets de formes per a diferents necessitats.
A nosaltres ens interessa aquesta eina per a dissenyar els diagrames UML dels mòduls OpenERP que volem desenvolupar i generar-ne posteriorment el mòdul per a OpenERP, motiu pel qual haurem d’instal·lar Dia amb Python amb l’opció de generació de mòduls OpenERP. [1]. El mòdul està en la branca extra-addons [2]
Per a fer-ho anar, seguim aquest manual: [3]
El procés d’instal·lació de Dia amb Python amb l’opció de generació de mòduls OpenERP, incorpora un exemple de diagrama UML desenvolupat amb Dia (arxiu uml_test.dia facilitat per OpenERP) corresponent a un senzill mòdul de gestió escolar per a OpenERP. Utilitzarem aquest diagrama per iniciar-nos en el disseny de mòduls OpenERP mitjançant l’eina de diagramació Dia.
L’eina Dia permet desenvolupar diversos tipus de diagrama i, com que ens interessa els diagrames UML, caldrà tenir seleccionada la fulla UML a la caixa d’eines de la part esquerra de la pantalla de Dia.
L’exemple de la figura anterior correspon a un model per gestionar, en una escola que facilita cursos (en diverses edicions) i disposa de professors, els estudiants assistents als diversos cursos. El disseny d’aquest model, segons veurem, pot no semblar molt “lògic” i l’hem de considerar com un exemple que ens permet introduir diversos conceptes bàsics per la generació de mòduls OpenERP amb Dia.
En una situació com la presentada, a l’hora de desenvolupar un diagrama UML, és molt lògic pensar en un disseny que contingui classes per modelar els conceptes curs, professor, edicions dels cursos i estudiants, de forma similar al diagrama uml_test, el qual contempla:
- Classe school.course, per modelar els cursos que facilita l’escola.
- Classe school.event, per modelar les edicions dels cursos.
- Classe abstracta school.professor, per modelar els professors.
- Plantilla de classe school.student, per modelar els estudiants.
Una primera ullada del diagrama permet introduir els següents conceptes per mòduls OpenERP:
- Tots els elements d’un diagrama cal escriure’ls en anglès (fins i tot les etiquetes i els textos informatius). Si ens interessa tenir-lo en un altre idioma, utilitzarem posteriorment les eines de traducció que facilita OpenERP.
- Totes les classes s’anomenen en minúscules i es recomana incorporar, com a prefix, el nom del mòdul al què pertanyen.
- Els noms de mòduls, classes i membres de les classes han de ser escrits en minúscula amb guions baixos per a fer llegibles els noms compostos.
- La nomenclatura indicada és la que marca OpenERP i, com possiblement sabreu, és diferent de les nomenclatures recomanades en altres entorns de POO, com és el cas del llenguatge Java.
Com que els noms de les classes tenen el prefix school, deduïm que es tracta del diagrama d’un mòdul anomenat school. S’aconsella batejar el diagrama Dia amb el nom del corresponent mòdul, ja que en el procés de generació del mòdul a partir del diagrama, Dia proposa el nom del diagrama com a nom del mòdul, tot i que es pot canviar.
Continuem observant el diagrama. Per a la classe school.event del mòdul school, en tractar-se del model per les edicions dels cursos, potser hagués estat més encertat el nom school.course.event, de forma similar a la nomenclatura utilitzada per OpenERP per les comandes de venda i les seves línies (sale.order i sale.order.line).
En el diagrama UML, school.professor una classe abstracta i school.studentés una plantilla de classe. A l’hora de generar els mòduls per OpenERP, això no té cap efecte i les haguéssim pogut dissenyar com a classes normals.
Fixem-nos que cada classe del diagrama incorpora un estereotip (nom encerclat entre els símbols « i » per sobre del nom de la classe). El procés de generació de mòduls OpenERP a partir de diagrames Dia, interpreta el contingut del camp estereotip com la jerarquia de menús, dins OpenERP, on ubicar els formularis generats a partir del diagrama i s’utilitza el símbol / per separar els diversos nivells. És a dir, segons el diagrama de la figura 6, el formulari corresponent al manteniment dels cursos estarà en una opció de menú anomenada Courses, dins el submenú Configuration del menú principal Courses (doncs l’estereotip de la classe school.course és «Courses/Configuration/Courses»).
( Els addons en ubuntu si fem una instal·lació amb apt-get estan en /usr/lib/pymodules/python2.7/openerp/addons cal copiar el .zip del mòdul i actualitzar la llista)