Compiere from the Source

Compiere Deployment on JBoss, Tomcat, OAS and WAS

Compiere is designed to support generic J2EE Application server, but as usual, there are some detail considerations.  Out of the box, Compiere supports JBoss and manages it's configuration and deployment.  In addition to JBoss, you can deploy the full application server to IBM WebSphere (WAS), Oracle Application Server (OAS) and others in addition to deploying the web containers in Tomcat.

In the setup dialog, you have the choice of "jboss", "tomcatOnly" and "ibmWAS" (the "oracleAS" option is disabled at the moment).  In this blog, I will describe how best to implement the different options.

Let's start with stand alone Tomcat. You can deploy war (WebArchive) files to Tomcat, examples are the web store, the web user interface.  You may do that for performance reasons and you always need another application server for the full functionality.  When selecting Tomcat in the Compiere Setup, you need to provide a path to your Tomcat deployment directory.  When starting Tomcat, you need to make sure that you add the Compiere Home variable to the Tomcat start command
(example: -DCOMPIERE_HOME=C:\Compiere2)
and you must configure the port to listen on.  I suggest that you rename the war file as the context provided is the exact name of the war file.

Using Lists in Compiere

Compiere is designed to allow for easy customization and extension.  Often these changes will include adding new field to existing tables.

You can allow users total freedom in the data entry process (text field), provide them with a list that users can modify (table) or control the list (reference).  Which is the best option will depend upon how the field is used.

For example, you may want to add a field that displays the type of Business Partner in the Business Partner window.  Adding the field BPartnerType to the Business Partner window is a simple task that has been described in earlier blog entries.  What we will discuss here is the different options for how the field is populated.

Compiere Translations

Compiere is designed to support the user interface in multiple languages - and to support multiple document languages.  Example: the users of the system with English or Spanish windows/reports - while you are sending invoices (documents) to your customers in English, German and Russian.

Out of the box, Compiere provides the infrastructure for 28 languages including the two Chinese, Japanese, Thai, Spanish (and Mexian), as well as British and Australian. The language infrastructure is based on Unicode and handles all languages and dialects.

The bulk of the translation is exported and imported via XML files to allow the use of translation tools like Trados.  Even though it might seem easier to "just translate" the system, you will realize significant savings for maintaining the translation with a translation tool - and the initial translation also will be less effort and with higher consistency.

Compiere at this very moment has about 106,000 words to translate. You can reduce that volume to about 98,000 if you only translate the parts a user of the system would see (i.e. not system administrator functionality).  If you skip the translation of the Help text (i.e. only labels and bubble help), the word count is reduced to 46,000.

Compiere offers "Language Packs" which are a good base for a translation.  Here I want to outline, what steps are necessary to create and maintain a Language pack efficiently:

Setting Field Level Security

Compiere allows to define security rules based on Table, Column or Field and Record level.  Here, we discuss your options of Field or Column level security.

There may be situations where you do not want specific users to have access to certain data.  For example, for some of your data entry clerks you do not want them to update the price list on Sales Orders.  When entering Sales Orders, the price list will default to the default sales price list defined for the entered Business Partner (if no default it defined then the default price list is used).  The data entry clerks should be able to see the price list, but the field should be read only.  The data entry managers, however, should be allowed to update the price list.

Aspect Oriented Development in Compiere

Aspect Oriented Programming (AOP) is an approch to manage functionality (aspects) of crosscutting concerns. The dedicated development environments allow the user of a developed functionality to add join points in method calls, etc. to add new behavior or even overwrite current behavior.  Aspects are a great way to isolate customisations and extension functionality.

Compiere is developed in a "classic" non-aspect oriented Java environment, but allows the user to "plug-in" their extension quickly without the need to modify or extend the underlying class.  This eases development and certainly migraion of that functionality to new versions or distributing that functionality to multiple sites.

Compiere provided the following join points for quite some time:

• Before Save (new or update) or Delete of any Persistent Object (PO)
• Before the workflow step Prepare or After the workflow step Complete
• After the user and role is identified in the Login process
• Before a Info window is displayed to modify or add information columns

Automatic Value Assignments

Compiere has the ability to dynamically create default field values when a new record is created (SQL, constant, preferences).  In addition to this, Automatic Assignments allow to set values after the user pressed save, just before a record is saved.  This could be used to create a default value without user intervention or if the user fails to define a value.  Another use is to assign a certain value based on other fields. 

Automatic Assignments are basically declerative before-insert/update/delete trigger and the main use is to complete records based on user entered values, set status, routing.  It is an easy alternative to extending the business class and modifying the beforeSave method.

Examples include: In a Lead assign the sales rep based on the country/region of the lead;

The Automatic Assignment allows you to add business logic without programming nor impact on migration to new versions and with that an ideal Customization tool. It acts like a Trigger and it's execution is logged.

You define the auto assignment for a certain table and select the situation the assignment should take place:  e.g., when a record is Created and/or Updated. You can add the restriction that the record cannot modified if processed (for documents are assumed to be read/only after processing).

Migration Tips & Tricks

Compiere provides three types of Migration

• Version Migration - Moving your system from one version/release to another
• Component Migration - Installing and upgrading your Component/Customization
• Data Migration - Moving/updating selections of data from one system to another

In contrast to other ERP/CRM systems, Compiere was designed to be extended/customized and with the principle that there is only one maintained version - the latest. In the beginning people were a bit uncomfortable with the idea that there is no support for historical versions. When they experienced the benefits of the Version Migration (available and stable since 2001), this concern was no longer an issue.  To be able to migrate to the current version new concepts were introduced to enable this.  The main element is the clear distinction who owns what via the Entity Type - and that in the migration does not touch customizations nor customer data.

The Version Migration is basically a "diff" program which compares the current state of the target system with the to be achieved state of the source system.  The migration is now in it's third generation and also maintains database index, constraints and views.  The runtime is more dependent on the number of differences between the versions rather than the size of the database.

The main advantage of the migration is that it uncovers potential issues (it does NOT create them).  The most useful output is the error log.  In most cases, you can start/continue production, even if you have a significant number of issues.  Let's look into causes and options:

Compiere Scaleability & Performance

These are the architectural components governing Compiere's architecture Performance & Scalability:
 
Volume:

Compiere handles transaction through its persistence layer which maps, secures and authenticates transaction consistency from dictionary meta data to database
The Compiere persistency engine is optimized for high volume OLTP environments.  For example, Compiere uses anonymous keys with the default settings of NUMBER(10) in the database and Java int. This restricts the system to 999 million records per table. If this is not sufficient, you can without code changes switch to Java Big Decimal and increase the scale of the ID column in the database to the maximum supported by the database.  Along with performance scalability, Compiere provides rigorous security and roles based access options. For example, the system can restrict users from creating queries with a defined number of records.  Long running processes can be executed in background or stared via scheduler thereby optimizing CPU performance.

Database:

Compiere uses a central database and is in production with Oracle Database Grids and database clusters.  Compiere manages transactions via a central service, eliminating the need for application developers to manage their transaction.  This increases uniformity and stability.  Compiere is available on Oracle and EnterpriseDB (PostgreSQL) with prototypes on DB/2 and Microsoft SQL Server.

Application Server:

Compiere can utilize any number of individual application servers, application server clusters and also Oracle Application Server Grids.  Each individual application server can be specialized for certain tasks or run in parallel to other application servers (e.g. multiple accounting servers). This allows for the IT infrastructure to scale up with the needs of the business application.  In addition to JBoss, Compiere was implemented with the Oracle Application Server and IBM WAS - and the web container also runs on stand alone Tomcat.

Payment Processors in Compiere

When you want to process credit card or electronic payments, you get a Merchant Account from your bank or other providers like Paypal. The Merchant account provider then may give you a choice of Payment Gateways, the companies who route the credit card requests to the issuers like Visa, Mastercard, American Express and manage the payments processing to your Merchant Account.

Compiere has provides an abstract class org.compiere.model.PaymentProcessor, which you can extend to interface to your specific payment gateway.  Compiere provides implementations for some of the the main gateways in the US - PayFlowPro (PP_PayFlowPro), Optimal Payments (PP_Optimal). I did also some research for interfacing to PayPal and Authorize.net.

You define the data required for the payment processor in the Window Bank - Tab Payment processor.  Here you define your payment processor class (e.g. org.compiere.model.PP_PayFlowPro) with your account/user names and passwords.

 

Blog Re-Org

Our blog was popular target of hackers, so we switched to a better environment with also provides Tags and a better way to find/search categories.  We plan to publish on a weekly schedule.

What would help is to get more topic suggestions.  Please feel free to add your suggestions and comments. Just sign-in - the link is on the right side.

In addition to adding the blog to your feeds, you can sign up to get blog updates via email.