Java, ERP and other annoyances
May 18th, 2007Recently I have been searching for an Open source ERP application to support some custom invoice printing and workflow apps. In this, what became a trek, I have looked at the following applications: Adempiere, Compiere, TinyERP, SQL Ledger and Alfesco (not ERP but it has workflows). TBH this has been like walking through thick sludge, there are significant barriers (not just hurdles mind you) to implementation before you get anywhere near actually testing the application. The biggest one is JAVA. Java sucks. I’m sure it’s great for developers and programmers but for the average Open Source Joe it’s the butt end of nowhere. To bet your business on the mess of technology that is Java is surely suicide.
Let me explain. To install the technology backbone for some of these apps you need the Java JDK and an application server like Tomcat or JBoss. To install the Sun JDK on Fedora you can’t just download and install it from the Sun site (that would just be too easy, no one made any money off making things easy). In fact if you just did this step you would be assured that your java application will absolutely not work. You actually have to go to www.jpackage.org get the Jpackage RPM, get the Sun JDK (go for the Java 5 version which everyone seems to be compatible with), rebuild the RPM’s and install them. Great that’s 50% of the allocated eval time gone. OK on to Tomcat. On Fedora it is just a case of using Yumex or Smart searching for Tomcat and installing a bunch of RPM’s. Cool that was easier than the last step. OK on to the applications. Get Compiere, Adempiere etc. Figure out the best install method of the many available (at least 1 to two days!!!). Go ahead and install. OMG they all install thier own tomcat/Jboss server. If you have a couple of these applications on your machine you will have separate installs of tomcat/Jboss for each application and your existing OS installed tomcat is sitting there doing nothing (actually it is doing something, it’s getting in the way of the other tomcat installs). There has got to be a way to just pop these into the OS supplied tomcat server. Sure there is. Just run through the config files and use the WAR’s (A java application distribution method). OMG no way, the config files are all XML or some other non-human readable file format. (as an aside I also have a gripe about Java error messages. Crumbs, what meaningless drivel Java throws out. To tell you you don’t have the Mysql driver for JDBC installed is an error message two pages long. I kid you not. It doesn’t even say it cannot find the driver you have to sort of guess that and spend some time googling.)
Anyway enough griping. Adempiere have made a great effort of simplifying the install of Compiere so if you want to go down this route use Adempiere. If you are thinking of spending any money implementing this kind of application then it is better spent in the more open environment of Adempiere. However I wonder what would happen if you installed one of these apps and your servers went tits up (so to speak). If implemented your business will very quickly become dependant on them. How long would it take to re-build the servers? A very, very long time I think using some expensive consultancy time no doubt.
On a side note The Liferay website was the only one that explained (in human readable terms) the choice between tomcat and Jboss. See Here. In summary, Jboss supports EJB’s which in turn support distributed transactions (and importantly rollback of failed distributed/complex transactions). So tomcat is useful for 95% of what you want to do in the real world and Jboss is for special circumstances (at least in my mind). Nice to know in the complicated world of Java.
On to Alfresco. Alfresco was selected to implement a document management system to track documents that need to be held for regulatory reasons. In this case Electrical Safety Certificates, Gas Safety Certificates, Insurance documents and such like for a property management and leasing business. Clients of the business and local government officials might request to see these at any time and they needed to be made easilly available to staff and also monitored for expiration/renewal and such like. Once you had jumped through the hoops to get the JDK and tomcat (OS native version) installed Alfresco installation was a breeze. Follow the instructions on the website and you get a WAR deployed to your OS installed tomcat webapps directory. Setup your database and fire it up. Start actual real work (document workflows etc) Good stuff, all Java apps should work like this (well, apart from the very confusing database setup which in a production environment will require you to delve into the complicated and confusing world of Java configuration files.)
TinyERP is a different beast. It exists in the Fedora Extras repository and it is a Python application. Select your RPM’s, install, setup your Postgres Database and you are off. I must say that if any application deserves to bring Enterprise ERP to the Small and Medium business sector then TinyERP should be it. Simple to install and evaluate, good documentation on the website and python seems to be easy to learn if you are of the mind to extend and develop the application perhaps with Plone (python based and also included in Fedora Extras) as your web frontend. It’s biggest positive attribute from my perspective is that it is NOT Java based although it has many other positive attributes. I would advise people to look at TinyERP before the other big metal ERP applications purely on the basis of it’s relative simplicity (ERP is not simple). Should your servers go down it would be much easier to recover (stick in a Fedora DVD to replacement hardware, install everything from the DVD + repositories, restore your database and add any TinyERP add-ons). Recovery in perhaps 2 to 4 hours once you have replacement hardware and most importantly you don’t need to be a rocket scientist to do it.
SQL Ledger is another financial application that might be a useful alternative to consider. It is mature, has great user reviews and once setup just seems to get on with the job. It is not ERP but can get the meat of the financial work done. Being a ’normal’ web app it is relatively simple to implement on a LAMP platform. They will also customise it for you for a fixed price not an open ended consultancy type of arrangement. The keep it simple principle always seems the best way to go.
An interesting comparison of Java and PHP apps in the CMS world (See HERE) throws light on similar issues in the Open source ERP world. Unless you have skilled staff on board you are dependant on the provider. For complex ERP applications it is meaningless that the source code is available. It is just too complex to maintain yourself if the provider does not meet your needs. After my experience with it I could probably say that Java is a form of code obfuscation better than or equal to the engines which mangle your code unless you have a great deal of time on your hands. Needless to say that after my rant I am not happy to bet my business (or anyone elses for that matter) to a Java based application unless there is a pile of cash and lots of not very busy, very smart people around to fix things when they go wrong (aside from needing them just to get things up and running). Now who has that?
R
PS. I have also looked at OfBiz which is a very promising Apache Software Foundation project. Just out of incubation I will be watching it with interest as I think it could ultimately beat the rest of the pack. Can’t comment further as I did not get a chance to play around with it much (getting Java and tomcat/Jboss working took much time). It seems to have the ‘out-of-the-box’ functionality that you don’t get with some of the other apps in this arena. Worth a look.
PPS if you have got this far in the post then I would absolutely love to hear your opinions on this. Unfortunately due to some dubious spamming of the blogs I have had to turn off the commenting system. Please post in the forum or send me a PM and I’ll get them up on the site for all to see.