Technical Highlights of opentaps 1.4
opentaps Open Source ERP + CRM version 1.4 is an important transitional step in the development of opentaps. This version continues to support the traditional ofbiz-based tools, including the entity engine, service engine, the ofbiz controller, screen, and form widgets and applications on top of the ofbiz framework. At the same time, it has new tools to support Java developers who wish to write a more object-oriented code using Java IDE's such as Eclipse. Finally, we are using Pentaho and JasperReports more extensively to provide better reporting capabilities.
opentaps Version 1.4 has been upgraded to use ofbiz 09.04 (April 2009 release). The most important change in this new release is the support for OWASP web-based security. In addition, there are new community developed ofbiz applications including the human resources, project management, and webPOS.
OWASP has been incorporated into opentaps 1.4 to provide protection against cross site scripting (XSS) and other web-based security attacks. As part of the change, the controller will no longer allow GET requests to call services with parameters. This means that your code must be changed so that all calls are made with POST requests. This can be done using some of the new opentaps form macros. See URL parameter security.
Google Web Toolkit
opentaps Version 1.4 has integrated the Google Web Toolkit (GWT) to support richer user interfaces using AJAX. The advantages of GWT are:
- Cross browser compatibility
- Ability to code and debug user interfaces in Java, which makes for more maintainable code, than scripted frameworks such as ZK, dojo, prototype
In opentaps 1.4, we have both client and server-side libraries for creating everything from forms, lists of results, and widgets. See:
- Introduction to Google Web Toolkit (GWT)
- Opentaps Google Web Toolkit
- Creating a Widget with Google Web Toolkit and opentaps
Domain Driven Architecture
A key change for opentaps 1.4 is the introduction of a domain driven architecture. The domain driven architecture allows you to build large-scale enterprise software as a series of domains, such as product, customer, and order, which separate the critical business logic of the domain from the underlying database implementation. This approach has several advantages. First, by abstracting your application from your database implementation, your code becomes more maintainable and portable. You can isolate changes to the database schema more easily if the rest of your code does not depend directly on your database tables. You can also switch from one set of database tables to another, essentially porting your application from one ERP system to another.
Second, the domain driven architecture allows you to realize a true object-oriented approach to implementing complex systems, whereas a database driven approach is inherently relational. This means that you can realize the benefits of object-oriented programming, including encapsulation, polymorphism, and inheritance and make your code easier to work with and easier to extend. An example is the contact mechanism implementation. At the database level, many tables with foreign keys are required to implement the contact information for a party, such as PartyContactMech, PartyContactMechPurpose, ContactMech, TelecomNumber, PostalAddress. This could all be hidden with a domain class, which can implement simple methods such as getPostalAddress or getTelecomNumber for a particular party and hide the complexity of the underlying tables. If you need new types of contact information, you can extend the base classes to support them, rather than relying on new foreign key types.
Finally, domains allow you to write code which is more similar to the natural languages for domains, rather than the database tables. This can be simple differences such as a method called isActive instead of ACTIVE='Y', or it can be more elaborate abstraction, such as creating a domain for Aircraft and Engine instead of relying on the Product and other entities through joins.
For more information, see Domain Driven Architecture
Java Entities, Constants, Services, and Screen Actions
These are several enhancements in opentaps 1.4 to help developers write more object-oriented and maintainable code using Java and IDE's such as Eclipse:
- Java base entities, which are Java classes for data model entities. These are automatically generated Java classes based on the entity engine XML, and they allow you to use Java get and set methods with strong type checking rather than the Map-like access using the ofbiz GenericDelegator. These classes allow your IDE to prompt you for the names and fields of the entities, and they also allow compile time type and field name checking.
- Java constants are similar to the Java base entities and are automatically generated Java classes which hold the string constants from the seed data XML files. For example, there are Java classes for status and enumeration codes. These again are designed to give you better IDE support during development and compile time error checking.
- Java services wrap the services defined in ofbiz service engine XML files in Java classes, so you can set parameters and call the services with Java methods. This makes the services easier to develop with IDE's, easier to manage with compile time error checking, and easier to maintain and extend.
- Java screen actions are an alternative to the ofbiz screen widget data preparation's use of scripted languages such as minilang, beanshell, and groovy. Again, the advantages are easier development with IDE's, compile time error checking, and better maintainability.
Integration with hibernate has been one of the most requested features from developers. In opentaps 1.4, we introduced the ability to use hibernate as well as the ofbiz delegator for persistence. Hibernate can be used with our Java base entities to persist and retrieve data in an object oriented manner. For more details, see Opentaps Hibernate Integration.
opentaps 1.4 has significantly improved reporting capabilities by incorporating JasperReports and Pentaho for business intelligence and reporting. Reports can be designed with iReport and then loaded into opentaps using the ReportRegistry. Data can also be transformed using the Pentaho Data Integration tool (also known as Kettle) into data warehouse tables, which can then be used to generate reports. For more information, see