by In my previous post, AcqFest II: The Chronicles of Code, I described the work that we were doing with and around Woodchip – a specialization of the opentaps enterprise resource planning and customer relationship management systems. The post also described some of the complexity of opentaps – perhaps best demonstrated by the size of a stable build (330 MB of Java) and its underlying database schema (exactly 1000 tables). Art had invested a lot of time learning how to tame the beast in the past, and he had hoped to be in a position to be able to invest a lot more time in late 2007 and 2008, but things weren’t working out with his schedule for circumstances beyond his control.
Of the remaining Evergreen developers, only Bill had recent experience with Java (writing the Java OpenSRF bindings) and had spent a significant amount of time with opentaps (doing most of the work to get OFBiz / opentaps talking to Evergreen). I had managed to get Woodchip installed and running before AcqFest II, and had traced through the layers to figure out that we could rely on Dojo to dynamically hide a lot of the unnecessary fields and options that wouldn’t apply to acquisitions or serials – but that still left me 329.5 MB of code to get cozy with. I was happy to spend most of my time tackling EDI and the Python OpenSRF bindings.
A few days after AcqFest II, we collectively realized that the opentaps route wasn’t working for us. We had made great progress on many of the aspects surrounding acquisitions and serials over the course of the weekend, but most of the work involving the customization of opentaps remained. That massive body of code, and the lack of Java resources on our team, was serving as an inhibitor to the style of development that had worked so well for Evergreen in the past: rapid iteration, putting together interfaces, getting feedback, and revising accordingly. And in many areas opentaps has a very “Web circa 1999” interface that, especially with the many layers of controllers and views, is not conducive to rapid change. That 330 MB of code also represents a massive surface to expose to the harsh world.
So we decided to take the last week before Christmas to try a more traditional (for Evergreen) approach: we would create a database schema based on the acquisitions requirements that we had in hand, and build a Web interface in a Python Web framework (Pylons) to see how far we could get in a week. The results, in the acq-experiment branch of the Evergreen repository, were encouraging. Through January thus far, we have been continuing to flesh out the acq-experiment branch, and are pleased with the progress. Most recently, Bill has been building the OpenSRF methods for accessing the acquisitions model objects. We’re confident that this is the right path to follow, and we’re excited by the progress that we are making, and we’re looking forward to showing off the fruits of our labours.
It’s likely that the first release of the acquisitions system will have a relatively static, plain HTML interface – but we’re building it in such a way that it will be easy to start incorporating more fluid elements into the interface via integration of the Dojo JavaScript library and general refinements to the views.
We’re also not leaving opentaps entirely behind. It will serve as a useful reference point for how an ERP handles specific task flows, business objects, and arcane tax rules; there’s a wealth of experience that has gone into building that system, and we’re grateful that we can glean knowledge from that effort.
We could use your help, though. We’re going to be talking a lot more about acquisitions development on the open-ils-dev mailing list, and we hope that you’ll join in with observations based on your own experiences about what we’re doing right or wrong or missing entirely. When we start making demo interfaces available, we would love to have you go through the process of ordering a book, or creating a fund, or rolling over funds to a new fiscal year, and telling us what would changes would make your life easier. Of course, we could also use more hands to help out with programming, UI design, testing, and documentation.