Building Modules: Best Practices - Ismael Ciordia

Openbravo World Conference Building Modules: Best practices Barcelona, April 19, 2009 Speaker: Ismael Ciordia, VP of Technology at Openbravo

Agenda Concepts • Openbravo Development Process • Artifacts of a Module • Types of Modules • Module Life Cycle • Dependencies and Maintenance Module examples Q&A OBWC2009-Building Modules: Best Practices-ICI Page 2

Concepts Openbravo Development Process Analysis Technical • Functional design requirement – Documentation • User needs • Technical spec. – Mental Domain – Openbravo Functional Components Coding Openbravo Development Process • Source code – Code to implement • System running the system • Binaries – Code to run the System Deployment Building OBWC2009-Building Modules: Best Practices-ICI Page 3

Concepts From Functional requirement to Source Code Functional Requirement Technical Design Source Code • Feature requests • Functional Components • Application Dictionary – Information – Data Model – Data Model • Structure • Tables & Column – Windows, Tabs and Fields • Consistency Rules • Data Validation – Callouts – Query and edit information – Windows – Process and Reports • User flow • Tab & Field layout, – Alerts • Dynamic behaviour • Callouts, etc. – … – Automated actions – Processes • Software resources • User interaction • UI pattern, Impl. tech. – Middle tier code and files • Business logic – Reports • Java, JAR – Reporting – Alerts • Conf. Files: xml, jrxml – Integration with other apps. – Web Services • Web static content – Security needs – Background processes – DB resources – Commons (multis) – Enterprise model and sec. • DB schema objects –… –… Develop an Openbravo solution consist of transforming Functional Requirements into Functional Components and those into Source Code OBWC2009-Building Modules: Best Practices-ICI Page 4

Concepts From Source Code to System Running App.Dict. App. Dictionary WAD Code & Conf. files DB schema obj Data SOURCE CODE - Data model - Java - Tables - UI (Windows, etc.) • Servlets, filters, pojos, etc. • Columns Conf. - Processes • JAR libraries • Constraints Script - Reports - Configuration files •… - Alerts • xml, jrxml, hbm, xsql, etc. - Proc.&Functions Reference - … - Web Static Content - Views Data - Model – Object • html, css, jpg, js, etc. DBSourceManager Build Generate Compile Deploy BINARIES & Conf. Files Context deploy DB Update Web server - Servlet Container SYSTEM RUNNING Database Servlet1 req web.xml Browser (FF, IE) DAL / SQLC (html, css, jpg, js, res Classes Servlet2 etc.) Structure App.Dict ... Libs data jdbc •Tables ServletN req Conf. •Functions User Filter1 files data res •Views WS Client ... Web http Openbravo Instance OBWC2009-Building Modules: Best Practices-ICI Page 5

Concepts Artifacts of a Module A Module is a piece of additional functionality that can be deployed optionally and independently on top of Openbravo ERP. It is made by the following artifacts: • Metadata that describe Openbravo ERP Application Dictionary Windows, Tabs, Fields, Messages, etc. ➢ Components • Openbravo ERP components not expressed as metadata Software Java classes, jar libraries, XML files, etc. ➢ Resources .obx file • User Data referred by transactions and that tend not to Reference change frequently Data Charts of accounts, tax codes, banks, product categories, etc. ➢ Can be defined at system, client or organization level. ➢ • Changes in Application Dictionary Components to support Configuration a specific set of business processes Script Hide / show tabs or fields, replace standard processes, etc. ➢ Only meaningful changes are allowed. ➢ OBWC2009-Building Modules: Best Practices-ICI Page 7

Concepts Types of Modules Modules Packs • Base content container • Collection of modules •Application Dictionary • Simplify deployment components •Software resources • Encourage fine grained modules •Reference data • Special packs are localization • Able to add new elements to and verticalization packs Openbravo Concepts • Cannot modify elements of other modules or of Core • The combination of a pack and a configuration script • Able to modify the behavior of other modules, including Core Industry Templates OBWC2009-Building Modules: Best Practices-ICI Page 8

Concepts Module Life Cycle Development Install & Update • Create module and register it in CR • Search for modules • Develop module artifacts • Get .obx file and install module • Export&Package module version in .obx file • Scan for updates of installed modules • Publish .obx file in CR • Get .obx file and update/upgrade • Develop fixes/enhancements modules • Publish new version in CR • Uninstall module OBWC2009-Building Modules: Best Practices-ICI Page 10

Concepts Module Dependencies Version Number 2.50 beta 2.60 beta MP1 MP2 MP3 MP1 MP2 X.YY.ZZZZ Core Major Version 0002 0019 0041 0103 0001 0007 0041 0082 Minor Version 1.0 1.01 depends depends MP1 MP1 MP2 Mod1 0001 0010 0003 0007 0021 0.1 0.2 0.3 depends depends depends MP1 MP1 Mod2 0005 0007 0005 0001 0004 Dependencies are declared at Major Version Level >> Modularity enforces that any Minor Version of a Module Major Version is compatible with any Minor Version of a Module Major Version it depends on. In a Minor Version a module can not modify the interface it provides to other modules OBWC2009-Building Modules: Best Practices-ICI Page 11

Concepts Maintenance • Modules are not allowed to modify other modules Simple – Modules only can add new elements, no crossed dependencies Dependency – Only one Industry Template in an Instance, responsible of Tree System consistency • Only changes that can be automatically and Automated unambiguously applied/unapplied are allowed Deployment – Changes in Openbravo model can be managed without human interaction and without risk of inconsistency (vs.changes in code) Ease of Deployment Distributed • Rules for changes in Minor Versions allow an isolated development of a Module within Major Versions Development and Maintenance • Dependencies are enforced when installing, Automated uninstalling and upgrading modules Mgnt. of Dependencies • From 2.50 any customization should be done through Separated packaged modules Code – No more merges of code in Openbravo instances, just in development environments (team working in a module) OBWC2009-Building Modules: Best Practices-ICI Page 12

Examples Simple Modules Functional requirement Source code Notes • Employee information • Employee info. data model • All other HR modules will - Name, Address, position, • Window to edit and query depend on it team, salary category, family employee info. • Depends on core 2.50 HR members, etc. • Window to edit and query • Fully developed through Employee • Edit (add, modify or delete) and teams Openbravo application query Employee information • Window to edit and query dictionary, no code needed Information • Edit (add, modify or delete) and Family members query auxiliar information •… (positions, teams, salary • Menu entries categories, etc.) • Analyze due payments by • Report with standard UI pattern • Depends on core 2.50 Sales Managers - Inputs: Date from ,Date to, • Does not require db_prefix - Filter by date and Product Product category • Developed through openbravo Category - Jrxml file application dictionary and a Payment - Group by Sales manager • Menu entry within Financial jrxml file packaged within the Report - Sort by date and amount menu folder module OBWC2009-Building Modules: Best Practices-ICI Page 14

Examples Reference data modules Functional requirement Functional components Notes • Automatically apply • Reference data • Depends on core2.50 Translation translations to run Openbravo - Translation files • Does not require db_prefix Pack: 2.50 in Spanish • No other content allowed core2.50 to • Just place xml translated files Spanish within module/referenceData folder • Load Spanish Chart of • Reference data • Depends on core2.50 but could Spanish Accounts in Initial - csv file with CoA be compatible with 2.60 and later Chart of client/organization Setup • Does not require db_prefix • Just place csv file within Accounts module/referenceData folder • Load/Update Spanish Taxes in • Reference data • Depends on core2.50 but could Initial client/organization Setup - DataSet describing Taxes be compatible with 2.60 and later Spanish - Xml file where taxes are • Does not require db_prefix Taxes exported through DAL • Just place xml file within module/referenceData folder OBWC2009-Building Modules: Best Practices-ICI Page 15

Examples Advanced modules Functional requirement Source code Notes • Synchronize OB ERP and this • Data model to configure the • Most of its implementation System to work together Synchronization done through code • The Mobile Sales App. • Windows to edit that info Integration Provides a mechanism to • WS Client to use the web with Mobile synchronize data in Mobile service provided by the mobile Devices through Web Services apps to read and write Sales App. • Sales App. has its own data information model, similar to Openbravo • Background processes to run ERP the Synchronization • Assign Google Calendars to • Data model to configure the • Could be used by any other resource in OB ERP integration: linking a resource module that needs to • Show, read and write calendars with a Google Calendar, graphically show and edit Integration in Google calendar from OB mapping users in both and calendars with Google ERP sharing calendars between • Most if its implementation • Solve security and sharing users done through code Calendar issues • Java code to read and write in • Assign resources to different a Google Calendar using entities in OB ERP Google data feeds • Link from OB ERP to Google OBWC2009-Building Modules: Best Practices-ICI Page 16

Examples Packs and Industry Templates Functional requirement Source code Notes • Run Openbravo ERP in a • It is a Pack, no code within • A pack includes modules, but Spanish Company • It includes the following the content within those modules: modules is provided by the Spanish - Translation Pack: core2.50 to modules itself (just a copy for Localization Spanish users installing from file - Spanish Chart of Accounts system) Pack - Spanish Taxes - Accounting reporting for Spanish Government • Run Openbravo ERP in a • It is an Industry Template, with • After installing an Industry Spanish Bakery the followin modules included: Template the System is ready - Spanish Localization Pack for use, only data load is Spanish - Integration with Mobile apps required Bakeries - Other specific needs Industry • It also includes a configuration Template script to adapt Openbravo to particular needs of Bakeries, including the setup to integrate with Mobile apps. OBWC2009-Building Modules: Best Practices-ICI Page 17

Examples Customization Modules Functional requirement Source code Notes • Any customer need that adds • Data model extension, new • Upgrade from 2.40 new elements to the system Windows, Tabs, fields, automatically generates this callouts, reports, process, etc module and helps you to place New elements your customization within it in customized • It is worth to design it so it can be shared later with other System instances through CR • Any customer need that • It is an Industry Template, with • Upgrade from 2.40 modifies a module (including the followin modules included: automatically generates this core) in the system - Any module needed, including module and helps you to place Customer other Industry Template your customization within it Industry - Customization module • It is worth to design it so it can • It also includes a configuration be shared later with other Template script to adapt Openbravo core instances through CR and other modules to particular needs of the customer OBWC2009-Building Modules: Best Practices-ICI Page 18

OBWC2009-Building Modules: Best Practices-ICI Page 20

Building Modules: Best Practices - Ismael Ciordia

0 comments

Notes on slide 1

Favorites, Groups & Events