I have been using the Compiere web services since they first came out. They are based on the Amazon web services and provide a platform independent and secure way to access the Compiere system. I was forced to use them in my project because there were other parties developing against my clients new system and they needed a way to place orders, grab customer information, etc. The multi-channel aspect of this project meant the customer needed the web site, phone call center, and retail stores to access compiere in a unified way and of course each channel was being developed in Microsoft’s .Net platform so building on top of Compiere was not going to happen and the high powers ( at the time before being acquired by Consona ) made it very clear to my client that doing any direct access to Compiere was bad and it had to be done through the web services. That hurt. I was then forced to use these web services, that were soo buggy and feature thin that I just wanted to go away and cry. Of course the documentation was there to help me………..or not. I ended up having to work with the author of the web services to make the damn thing work with .Net ( I had no .Net experience when starting this project, so I was working with soo many new things my head was hating me ). After, what seemed like forever ( it was more like 6 months of back and forth and getting special builds of the web services and even got them to make views accessible through them ), I got it working. They seemed impressed and even asked if I could contribute my code to be available and I did give it up to them. It was a major task, but I have to report that I have designed a developed a whole phone call center in ASP.Net accessing Compiere through the web services and built the APIs to help the web site developers integrate Compiere into MediaChase’s G5 platform.
The main victory for me was being able to get the Compiere views as part of the web services. The importance of this is significant to our products because the web services are very far from ideal when it comes to accessing data. For example, in our phone call center, a customer will call up and identify themselves as an existing customer or not. The phone center rep will have to look up the customer and be able to find them based on various data such as phone number, address, zip code, email, or name, or any combination. As you know, Compiere stores this information in C_BPARTNER, C_BPARTNER_LOCATION, AD_USER, and C_LOCATION. How do you do a query like that if all you have access to is the tables? I told the developers this and said if I was able to create a view that combined all the tables together, I could do a query against 1 view and get results. So when a customer is found, we have to display all the information for a customer such as order history, addresses, phone numbers, etc. We allow multiple addresses and showing the order history is important. Just to get 1 customer address, we have to pull from C_BPARTNER_LOCATION, C_LOCATION, C_REGION, C_COUNTRY and when you have a customer on the phone, all seconds count. We found 15 second retrieval time was average just to get the information we needed for 1 customer. Way too long. I even went as far as caching the regions and countries to help that, but that was not even getting to order history. By creating views and querying them, we got the retrieval time down in half. Still not great, but its a start.
So that was just one area, but what else do these web services need to become remotely usable to an enterprise? Here is my wish list. Keep in mind, I am considering writing my own layer because waiting for Consona to do anything is probably a futile exercise in patience.
Limited Results
My client has over 350,000 customers and the orders associated with each customer makes the data set very large. A customer could have 100+ orders and if I have to pull all orders for a customer, I could overload the network,time out, or just annoy the user. There is also the possibility that the customer care rep will query the system with something like “Last Name = Smith”. That could return several thousand records and take a very long time if Compiere has to query, generate an XML file, pass it over the network, and have the call center parse it. What would be great would be to have a result set size so the server limits the results. Passing a parameter of “limit=20” would be great and on top of that, passing in a page number to specify the page of the result set would give even greater flexibility to our application. In my .Net code I have written in limiting code so that result sets are limited by a parameter ( if passed in ) but I am still at the mercy of the web services to return whatever size result set I have passed it.
Better Conditionals
You can pass in multiple conditional statements such as “value=10 AND name like ‘Ted%'”, but what about some OR love? Why can’t we have an OR operator? Sheesh.
Errors
Compiere has horrible error messages to begin with, but the web services takes that up a notch. It would be reasonable to expect a proper error response for simple things like “oh the table you query against does not exist” or “the column you specified does not exist”. While I am ranting about this, let me just say the whole case sensitive aspect of Compiere really sucks. If you change a table name from C_BPartner to C_bpartner, Compiere will crash ( and of course give no clue as to why ). I cant count the number of times I have had to search through the Application Dictionary to find out who imported a table and forgot to change the case of the table. Please please please stop making things case sensitive. There is no reason for it.
I have a lot more, but I am too fired up now. If you have any or just want to rant, I’d love to hear it. Again, I may just write my own layer and by pass the whole web services fiasco altogether. Good night.
Mel