xTuple.com xTupleU Blog & News Customer Support

Using Oracle 12c instead of PostgreSQL

Dear xTuple community,

We are implementing Oracle Enterprise Manager (OEM) with Oracle VM to monitor and virtualize our dedicated DELL PowerEdge server. Just like Oracle VM, OEM is a free product, but it requires Oracle database, at least Standard Edition One (which cost for five users is about 24€/month). Because OEM has a great monitoring capabilities for Oracle database, we'd like to use ERP+CRM that supports Oracle database. (OEM also supports e.g. monitoring of Glassfish domains which is a great thing for us.)

Instead of using Oracle database, it could be possible to extend OEM to support monitoring of PostgreSQL. But, to simplify administration, it would be better to use Oracle instead of PostgreSQL. So, my question is, how much development effort xTuple would need to make it support Oracle database 12c? We are in situation that xTuple would be the best product for us, but we'd like to use Oracle instead of Postgres.

kind regards,
-- Jussi Lehto
https://twitter.com/JussiLehto

We we're thinking to use Orbeon Forms inside Liferay Portal to write data to our xTuple database. But the problem was that Orbeon supports only Oracle, MySQL and eXist databases out of the box, so it needs some development to make it support Postgres.

Then I found Aperte Workflow which had just released new beta. It supports Postgres out of the box, includes BPMN engine, the UI is made with Vaadin (where I actually have paid pro account) and it's tested with Tomcat application server which can be monitored with Oracle Enterprise Manager (OEM).

So we are currently researching between these two, which one to make work with xTuple. Do you think it makes sense?

P.S. It is still possible to write PostgreSQL plugin for OEM. There is white paper (PDF) about writing MySQL plugin for OEM. On this blog post he writes about the new version of the plug-in for OEM. Why not to make same kind of plugin to support Postgres?

Hi Jussi,

This is an interesting conversation. We tend to think as a general rule that it's best to start conversations with the question, "What are the problems you are trying to solve?" rather than starting with a technology and asking "How do I make this do X?"  Based on your last response it sounds like you are focused on putting together a set of enterprise tools that allow you the flexibility to create, modify and extend web based and enterprise caliber applications with graphical tools that involve minimal programming. You probably have not found anybody that has an end-to-end solution that does this, so you are trying to pull together a "best of breed" tool set to accomplish your goals.

We use Drupal as the basis for our portal solution. We are actually moving along at a rapid clip on our next generation web portal that will use our  REST web service interface.  This integration is providing complete access to Drupal of all xTuple business objects that have been exposed to our web platform, which means they are all made available to Drupal's native form builder system.

We also have a web front end for our ERP that is designed to work on all web browsers and devices including both desktop and touch based mobile devices. The architecture for that is described here. Because we understand that every business is unique, this system is designed to be easily extensible at every level. Our developer group, of course, doesn't mind programming so as of right now all extensions to this system involve JavaScript coding and our main focus so far has been on building out functional parity between this client and our long standing C++ based Desktop Application. However, it is noteworthy that the web client is built with Enyo, and that Enyo has a graphical designer project called Ares that allows for drag 'n drop building of user interfaces. There is a video demonstrating what that looks like here. About 5 minutes into that video you start to see the drag 'n drop features. I've had an idea for some time that I'd like to see an Ares based form builder integrated into our web client, we'd just need someone to push us in that direction to make it happen. We actually did more or less the same thing with the Desktop client years ago where we embedded the Qt form designer into that client and it has worked great.

So to summarize, now that you've described what I think is your business problem, I believe we could have meaningful conversations on how to meet your goals. In some cases we provide solutions today that will meet your needs, some aspects may involve us extending out our platform, and some aspects may involve integrating with some tools you are looking at that it may simply be best to integrate with. One point I will add, however, is that the more vendors and moving parts that are involved in your stack, the more challenging it's going to be to get it all working because there will be much finger pointing as to who is responsible for which part. We tend to do everything we can to minimize the number of components in our stack because we believe there is a strong correlation between simplicity and reliability. If you choose to work with us to sort out your solution, you would have the benefit of a single point of contact to work with and hold accountable, but because our stack is built on 100% open source tools and code, you'd avoid the dangers of vendor lock-in.

Regards,

John

What I like most in xTuple is it's functionality and the multi-platform client so I can have access to my business software even when Internet connection is unreliable or not available at all. Also the database centric design is interesting, and the community and staff are very responsive, as seen here. :-)

But personally I would choose Liferay over Drupal, and Vaadin over Enyo, so xTuple would be a perfect product. I think these are more powerful. Currently I don't like so much the idea to use Drupal...

Jussi,

It looks like both Liferay and Vaadin are written in Java.  Vaadin also uses Google Web Toolkit.  If Java is your thing, there's good news.  xTuple's REST API was specifically designed to work with Google's API Client Libraries.  There are libraries for both Java and GWT.  I don't know anything about how Liferay and Vaadin work, but the technology to access our REST API from a Java client does exist.  I'm utilizing Google's PHP library in our Drupal integration and it's working great.

 

Hi Jussi,

It's unlikely in the extreme that we (or anyone) would spend the considerable effort required to port the xTuple backend from Postgres to Oracle (or anything else, frankly).  There is a huge amount of native Postgres functionality that we use, including two embedded procedural languages, object and table inheritance, and much more.  Spend a little time in the xTuple Developer Zone, and you'll get a sense of what I'm talking about.  Many business applications treat the database as a dumb data store, and don't use it for anything beyond that.  Not us.

What we've found over the past fifteen years (literally) is that Postgres is roughly to Oracle what Linux is to Unix - a free, open source, better version of largely comparable functionality - and in some cases, superior to its commercial counterpart.  And there are numerous examples over the years of how we've leveraged Postgres functionality to deliver better performance, and a more maintainable, reliable ERP server.

From the use case that you've described, it seems to me that you'd be much better advised to choose the ERP/CRM package that meets your functional needs first.  Monitoring is monitoring, and there are a wealth of tools available for that.

One guy's opinion, so take it for what it's worth.  But regardless, thanks for your interest in xTuple - and if you'd like to talk directly with anyone here, please feel free to drop a line to sales@xtuple.com.

Cheers,

Ned

It's hard for me/us to evaluate your situation without understanding exactly what these 3rd party applications/tools that connect to Oracle are providing to your business.  I will reiterate that without a massive (and, were I advising the business in question, silly) investment, it is unlikely xTuple would be convinced to port the application to Oracle.  So, it really comes down to understanding #2 a little better. #1 and #3 are not really interesting to xTuple at all, and while there might be people in the community who would be intrigued by the intellectual exercise, my suspicion is that it wouldn't put food on the table for anyone involved.  #4, of course, is always your choice - but good luck with that.

So, that being the case, what is so awesome about these 3rd party applications/tools, that you're subjugating your choice of mission-critical ERP applications to them?  And can you name them by name?

Thank you for your answer, Ned. So it would need a lot of development?

Also one of the reasons to use Oracle instead of Postgres is some 3rd party applications support for Oracle, but not for Postgres. If we will use Postgres as the "base database" for our business, we need to make development for the 3rd party applications we need to have to make those work with xTuple.

I understand PostgreSQL is a great platform that we'd like to use, but the server architecture I mentioned needs an Oracle database anyway, and the 3rd applications we need to use are not supporting Postgres.

Isn't there these days any database migration tools available? Or do you think that xTuple database might be too complex to migrate with automated tools? For example, Oracle SQL Developer (free SQL IDE) has a migration feature to migrate from other databases to Oracle (here's a YouTube video), but unfortunately it does not (yet) support Postgres. On Oracle SQL Developer Exchange, support for Postgres is almost the most preferred new feature.

As summary, there is four options for us:

1. Develop xTuple to support Oracle out of the box.

2. Use xTuple as it is and develop the 3rd applications to make those work with Postgres.

3. Migrate xTuple Postgres database to Oracle.

4. Use alternative ERP+CRM that supports Oracle out of the box.

Every option has it's own pros and coins. In principle, the best option would the option number one, but unfortunately it looks like we need to make some compromise. Any comments?