I started out by following the instructions at http://openmrs.org/wiki/BIRT_ODA_Plugin_User_Guide in an attempt to setup and test the ODA with the Logic Web Service module.

In the OpenMRS Administration interface, it indicates to change module.allow_web_admin to true in the runtime properties in order to upload modules. After a rebuild, it still wouldn't let me upload the module. I went to the "Module Properties" page and it indicated that I needed to have module.allow_upload set to true. I set this in the runtime properties and did another rebuild. This still didn't work for me, so I just dropped the module in C:\Application Data\OpenMRS\modules and restarted. The module showed up in the "Manage Module" section so it looks like it worked.

I dropped the ODA jars in my BIRT installation and setup a new OpenMRS data source. As my mentor, Justin, suspected, the plugin did not work with the current version of the Logic Web Service and it threw an "Expected API functions do not respond correctly" Exception .

I checked out the OpenMRS ODA plugin code and saw that the failure was happening in the canAccessAPI() method of the Connection class. I added some Exception handling to log some info if the problem was an IOException, built and deployed the modified OpenMRS ODA, and restarted Eclipse. This new Exception handling showed me that the failure was happening when trying to access http://localhost:8080/openmrs/moduleServlet/logicws/api/getFilters. Accessing this in my browser gave me a NoSuchMethodError for "org.openmrs.api.context.Context.getReportService()Lorg/openmrs/reporting/ReportService". Tracking this down in the LWS code seems to point to the getAllPatientFilters method. I am wondering if I need to install the ReportService with my OpenMRS deployment?

Based on my conversations with Justin, he was expecting problems like this. So, looks like one of the first steps for this project will be to get a mock web service working so that the ODA development can commence. I was pointed to the following resources for information on modifying/creating a new LWS module:

• http://svn.openmrs.org/openmrs-modules/logicws/web/src/org/openmrs/module/logicws/web/
• http://openmrs.org/wiki/Module
• http://openmrs.org/wiki/Creating_Your_First_OpenMRS_Module

We also plan on nailing down more of the requirements for this project this week.

To really get familiar with an Eclipse ODA, I decided to go through the three part "ODA Extensions and BIRT" series by Scott Rosenbaum and Jason Weathersby. It is not publicly linked but can be accessed here by doing some registration. The tutorial is spread across three parts in volume 8, 9, and 14 of the Eclipse magazine.

The end result of the ODA is the ability to use Google Spreadsheets as a data source. This is particularly appropriate for me because I am wrapping up a big networking project where we have been storing the simulation results in a Google Spreadsheet. The project involves the effects of node density on packet delivery ratio for three different wireless routing protocols.

Going through this ODA guide exposed me to Eclipse plugin and ODA concepts and terminology which will be helpful for this project. With respect to ODA, a simple but important point seems to be that of separating design and runtime for the ODA. The first part of the article mainly focuses on the runtime, the second part with the design time (GUI), and the third part with adding logging, optimization, data types, and parameters.

I think the most valuable lesson I learned was with troubleshooting an ODA. Setting up the Logger for the ODA was crucial to solving a snag I ran into. I had the piece of the ODA working that identifies all the user's spreadsheets and then allows you to drill down and select an individual sheet for the query. However, the data preview kept failing with a CannotExecuteStatement error. Well, needless to say, this generic error didn't help identify where the root cause of the problem was. Looking into what the ODA was logging out showed it was throwing a com.google.gdata.util.ServiceException exception. A few alterations to the ODA and I could see the entire stack indicating it was throwing a com.google.gdata.util.InvalidEntryException exception (extends ServiceException) which typically indicates a bad or malformed request. The final step was to log out the actual query that was being made and I could see that the problem was that the filterClause data set parameter was defaulting to 'dummy default value'. Changing this to null allowed the data preview to work. See the image above that shows the node density and delivery ratio data from my project spreadsheet.

The next thing I am going to do is get, build, and become familiar with the OpenMRS ODA. I've also started adding links that are useful to this project to the right navigation area of this blog.

I finally have a little breathing room from my huge school project and wanted to setup OpenMRS on my laptop. I basically followed the steps from http://openmrs.org/wiki/Step-by-Step_Installation_for_Developers and got things up and running. Basic stuff about the versions of the various software I setup:

• Fresh install of Eclipse 3.3.2 and setup Subclipse 1.2.4. Running Java 1.6.0_05-b13 but set compliance level to 1.5.
• Installed MySQL 5.0.51b and configured as a multifunctional db with 20 concurrent connections. Decided to make UTF8 the default character set.
• Installed the MySQL GUI tools so I could easily look at the db model if required.
• ant 1.7.0
• Tomcat 6.0.16

To make sure things were all working correctly, I made my self a patient in the system:

Alright, back to running network simulations for school. Only 10 more days!

I just found out this week that I was accepted into this summer's GSOC and will be working with OpenMRS on extending their BIRT ODA from last year's GSOC. My mentor is Justin Miranda and I'm really looking forward to coding this summer under his guidance. I will be blogging my progress for this project here. The following is the abstract for this project that was accepted:

A high level description for this project is available at
http://openmrs.org/wiki/Projects#Extend_OpenMRS_ODA_Plugin. Basically, the
goal of this project is to further improve upon the ODA that was created during last year's GSOC (http://openmrs.org/wiki/BIRT_ODA_Plugin_User_Guide). The ODA is a BIRT plugin that uses OpenMRS's Logic Web Service as a datasource.

Additional optimizations need to be made with respect to how the tokens are treated. Currently, tokens can be filtered upon by choosing the tag but it would be nice to add a feature where the users could search for a particular token name using a regular expression. The list of tokens and their tag relationships should be cached on the client side so that the web service does not have to be hit every time a tag or search is made. The CD4 Count token is a multi-value token. The interface should "explode" the multiple values to show the date as well as the actual value of the CD4 count. The user should also be able to change the default datatype of a token to another datatype.

The Logic Web Service will also need to be enhanced to support more tokens as required. It should handle all of the methods available within the Logic Web Service's already constructed interface so that the ODA can leverage any of those APIs that could be useful. A more complex query builder is desired on the ODA side that would take advantage of all the LWS's operator/modifier APIs that are appropriate for a given token/datatype. Also, there should be an option within the web service that would allow the user to choose not to have the tokens returned if they did not contain any data.

This project would also include developing a simple mechanism/framework to upload the BIRT report designs to the appropriate directory on the OpenMRS server automatically. This will allow for quick and easy deployment. Another area to improve upon as far as usability would be the ease of integration of the BIRT report itself. The data source can be configured such that the connection details to the OpenMRS server can be set at runtime of the report. This would involve both the ODA as well as report design improvements/changes. Common data sets could also be configured in the BIRT report design via BIRT templates. Using templates would streamline and simplify report design for creating new reports. A report designer could just drag and drop the individual data items within the precreated datasets in the BIRT template.

When these ODA / Logic Web Service changes have been implemented, I would like to develop some useful reports to show off the new functionality. We can create some reports that were too troublesome to design or easily implement runtime parameters in the past due to only having the JDBC option available. We could also recreate the data access part of existing BIRT reports with the new ODA and make them better.