Oct 8, 2012

Openbravo Mobile: Technical Overview and Roadmap

by Iván Perdomo

Have you seen the power of Openbravo Mobile already? As you may have read in a previous post, we have been looking for the best HTML5 framework for Openbravo Mobile. After several months of researching, prototyping and testing we have decided that Enyo is our best option.

What’s Enyo?

Enyo is an object-oriented JavaScript application framework emphasizing modularity and encapsulation.

Back in January, HP announced the new version of Enyo, the framework powering webOS applications, but this time, a cross-browser solution optimized for mobile devices and released under the Apache license.

Since this initial announcement we have been tracking the evolution of the framework on every release. In February I posted a very simple example on how to consume Openbravo JSON REST WebServices, using Enyo (core).

In July the first non beta version was a released, by then we knew that Enyo was a real option for us.

Our experience with Enyo

We’ve been working with Enyo for several of months now and we are really pleased and enjoying the experience.

After investing time in prototypes and getting to know Enyo, our first real work was the code refactor using Enyo abstractions (Kind, Component, Control, Event) in Openbravo Web POS.

Openbravo Web POS – Powered by Enyo

The experience and result of this process gave us enough knowledge and confidence to decide and go for it:

Enyo is the right framework for Openbravo Mobile, as it provides the building blocks for developing a modular, extensible, thin, and fast mobile applications

In Openbravo Mobile we’ll use the full suit of Enyo, core, onyx and layout. Here you have some examples of the output of this great framework.

Grid View – Purchase Order Lines

Form View – Purchase Order (Processing)

The Data Model

We’ll also use Backbone.js Models and Collections for representing the entities declared in the Application Dictionary and Enyo will provide the UI widgets for manipulating those collections and models.

In the back-end we’ll use the same modular architecture in Openbravo 3.

Openbravo Mobile Architecture

Openbravo Mobile Architecture

The Roadmap

The main goal of Openbravo Mobile is to deliver the framework for developing mobile applications by the end of Q4-2012, with a few milestones in between:

  • Basic infrastructure (Login + Workspace): Be able to login using a mobile device, and open a window
  • Standard Windows: Support for windows declared in the Application Dictionary
  • Processes and Reports: Support for launching reports and processes from a mobile device
  • Support for Manual Windows: Support for View Implementations (aka Manual Windows)
  • Fine-tune Functional Flows: Revisit the flows and usability in a mobile device (Q1-2013)

I hope this gives you an overview on what has being going on in Openbravo Mobile, the Roadmap and milestones of this project. To know more about Enyo visit http://enyojs.com




Jul 16, 2012

Wow! 2 billion order lines per year, really? How much of that data can be stored offline?

by Iván Perdomo

My colleague Antonio explained in his post the performance of the server side component in the Openbravo solution for Retail. Now let’s take a look on the client side part, What happens when you’re selling and your network goes down? How much time can you work in offline mode?

Imagine you have a store in Pamplona’s city center, and during San Fermín festival you sell all the required clothing for the festival: White shirt and pants, the red handkerchief and belts, bota bags, etc.

Now imagine you’re on July 5th, the day before the Chupinazo, your store is crowded by foreigners trying to buy the outfit and equipment for the festival; you have a lot of them in the queue waiting to pay. Everything is going so well, you’re selling a lot, but suddenly your network goes down, your internet connection is lost, you’re in panic!!, you start asking yourself: “Am I able to keep selling without internet connection?”Of course! You’re using Openbravo Web POS.

Remember what Antonio mentioned:

The POS terminals can work in two different modes: online mode, and offline mode. When they are online, and a sales order is created, the terminal sends this order to the Openbravo instance … If the terminal is offline, however, the order cannot be immediately sent. In this case, the order is stored in a database inside the POS terminal. Once the terminal returns to online mode, the POS terminal sends a batch which contains all stored orders to the Openbravo instance.

This is a nice feature but: How many order can I process in offline mode? How much time do I have before my POS terminal gets full?

The answer is: It depends on the processing rate (orders per minute) and the average order size (lines per order) of your store.

Let’s take the best scenario for your Pamplona store on July 5th as example. Let’s imagine that you’re are able to process 4 orders with 10 lines each every 60 seconds. That is, with a single POS terminal, you’re selling to 4 different customers every minute, without stopping a second. (This is almost physically impossible, but during Sanfermines you never know).

Some numbers (the geeky stuff)

An order with 10 lines is 3 KB of data in the POS terminal cache. If you are serving 4 customers each minute with a single POS terminal; you’re generating 720 KB per hour (nice speed). Notice that this is an ideal situation: 4 customers with 10 different products every minute without stopping.

At this frenetic rate, in a 12 hour shift without internet connection, and just before the party starts, you have stored 8.44 MB of data in your POS terminal offline cache.

While you were selling at the rate of 4 orders per minute, your colleague have called the Internet provider and reported the network problem. 12 hours later and just before closing the day, the internet connection has been restored and the terminal has sent all the 2880 orders that you have produced during the offline period.

The best thing is that you have provided all the required equipment to almost three thousand foreigners eager for party.

Don’t worry, the only limit is the physical space in your mobile device

If you are using an Android device like a Samsung Galaxy Tab 10.1 or a fully fledged Windows 7 tablet like the Asus Eee Slate EP121, your database will silently grow, allowing you to keep selling in offline mode.

At the rate of 4 orders per minute, it will take you more than 2 years to fill 10GB on your Samsung Galaxy Tab, or more than 4 years to fill 25GB on your Asus Eee Slate EP121, and remember, selling without stopping a second!!

The iPad limits

Unfortunately the previous statement is not true for the Safari browser on iOS. The Apple guys have set a 50MB limit for offline storage, but this quota is more than enough space for the normal operation of Openbravo Web POS with a very high order processing rate.

Openbravo Web POS supports enormously high processing rate

Under normal operation (online mode) every order is sent to the server immediately just after closing it. Openbravo Web POS allows you to work in offline mode but this is a fall back mode.

There are several benefits of immediately sending the orders to the server:

  1. Updated warehouse stock
  2. Generate a Sales Invoice when you specify it
  3. Any other retail related process you have implemented in your Openbravo instance

Working in offline mode shouldn’t be your normal operation mode, but even in some unusual situations where you have 1-2 days or even a week without network connection, Openbravo Web POS will support your operation without any issue.

What about Master Data?

When you login into an Openbravo Web POS terminal the required master data it is also stored in the offline cache. By master data I mean: Products (with images), Prices, Business Partners, Tax Rates, etc.

Caching master data will take space from your offline cache, but it is required to be able to have a fully working offline mode. In another post I’ll give you more detailed description of how much the master data takes in the database, but to give you a rough estimation: caching 1000 products with images and prices is about 22 MB of data. Remember the only device that enforces the 50MB quota is the iPad, on Android and Windows devices, the database will grow silently.

Conclusions

  • Openbravo Web POS supports high activity rate even without connection to the server
  • The number of orders you can process in offline mode depends on your selling rate (number of orders per minute) and the order size (average number of lines per order)
  • If you have a constant selling rate of 4 orders per minute (very unlikely), in 12 hours of offline mode you have produced 2880 orders and only filled the 17% of the initial database size
  • The only limit is your device storage space on Android and Windows devices. The database will grow silently if you reach the initial 50MB size. It will take you more than 2 years in the Samsung Galaxy Tab and more than 4 in the Windows 7 device
  • On the iPad you have a fixed quota of 50MB but you’ll have to remain selling for 3 days in offline mode (at constant rate of 4 orders per minute) to fill the database
  • If you think you’ll have huge amount of master data (products, business partners, etc) and long offline periods, you must use an Android or Windows device
  • Offline mode is an exceptional fall back mode, it shouldn’t be your normal operation mode. In online mode, every closed order is sent to the server immediately. The server will process that order and update stock and execute any other retail related process

I hope this post can clarify the most common question we often get about offline operation of Openbravo Web POS. As mentioned before, I’ll write another post more technical on master data cache.

.




Mar 2, 2012

Re-introduction to JavaScript and Openbravo 3 Architecture

by Iván Perdomo

Yesterday we had a session with the Development Team on Re-introduction to JavaScript and Openbravo 3 Architecture.

Some of the topics covered in this talk:

  • What happens when I login into Openbravo
  • What’s a Component Provider or a Component
  • What’s a Data Source
  • Which are the JavaScript classes behind a Openbravo window
  • When I need to compile or just restart Tomcat server

You can watch them online at:

Enjoy!




Mar 29, 2009

Hidden Architecture Syndrome: Definition & Longterm Effects

by John Fandl
Software architecture as archeological dig (when engineers have no voice)

A common criticism of Open Source software vendors (most often made by our proprietary brethren) is that Open Source vendors are founded by engineers and technologists who do not understand commercial business, and the importance of the sales and marketing functions. I will let that generalization stand for now (of course, commercial success requires a proper balance across the disciplines!), and focus my first series of posts on the "flip side", namely:

  • what generally happens over time in "sales-driven" software companies?
Note: My comments are focused on the mid-market ERP space, with which I am very familiar.


Context
First, some context. As a relative newbie to the world of Open Source ERP, I was immediately struck by how transparent and "out in the open" everything is, at least here at Openbravo--not just the source code, but complete documentation, release status, virtually everything! My iGoogle now has a graphical widget that shows me the number of open bugs in the new Openbravo 2.50 release, by severity. Take a look at Openbravo's public wiki: as a new employee, I can be told "just read the wiki, and you will be pretty much up to speed re: what we are up to". Wow, all there on the web, linked together, searchable, easy to consume (even from an iPhone!) .

And once you start reading, you see topics like "Concepts for Openbravo ERP Redesign". Yowza, "Redesign"?, why do we need a redesign? That makes it sound like what we have now is no good. Did I take the right job? And then you step back and realize that in the proprietary world, you were used to spending a lot of cycles on perception (so time is spent by high-priced marketing staff "sanitizing" such politically incorrect verbiage). Here in opensource land, we are doing real Collaborative User Experience Design (complete with UI mockups) out in the open with partners and clients!

And as I am reading and learning more, it occurs to me that this transparency is not just a "difference", it is a hugely valuable differentiator. The first area I want to talk about related to transparency is Software Architecture, which in my experience is a mission-critical Software Engineering discipline that requires ongoing investment to deliver sustainable, adaptable business systems that will last over the course of decades. Open Source vendors tend to be very strong in this area, simply because the Darwinian nature of the overall open source ecosystem demands it--architectural weaknesses are quickly exposed publicly, and, if not addressed, your open source project will die due to lack of interest on the part of developers. So, the transparency assures that only the best architectures will actually be built upon, and that they will be updated with worthy new technologies that inevitably arise in the future (recent past examples include RESTful Web Services and AJAX).

So what happens over time when a system's architecture is allowed to evolve in a non-transparent, "hidden" manner, as is often the case with sales-driven, proprietary mid-market ERP vendors?


Hidden Architecture Syndrome
Well, the short answer is that "Hidden Architecture Syndrome" (HAS) sets in. And, depending on where the proprietary product is in its lifecycle, the symptoms of this syndrome do not bode well for its users, longterm.

I have identified 5 phases of HAS, based on my experiences working in the mid-market ERP space:

  1. Life is Good: We have a product that fits a niche!
  2. Bulk Up: Our success has attracted competition
  3. Attrition & Contraction: Initial effects of technological obsolescence
  4. Pump up the Marketing: This stuff is still good, just need more focused marketing for new deals
  5. Keep Milking the Base / Get Acquired: (aka, "Decision time for customers")

One final thought at this point: Why is the "common wisdom", as espoused by the analyst firms (Gartner, AMR, etc.), that the shelf life (or customer buying cycle) for an ERP system is 7-10 years? I think that much of the answer is that Hidden Architecture Syndrome is prevalent industry-wide, and a decade is about how long a vendor can profitably "ride" any given architecture (before dramatically reducing the R&D investment on that "legacy" system).

But it doesn't have to be that way, does it? What if your ERP vendor actually invested in a rock solid, modern architecture, and then invested incrementally to refine and improve it at every release? From an economic perspective, nobody actually wants to "rip and replace" every decade (conceptually, that's like planning to get a divorce once per decade). Doesn't it make a lot more sense to find that perfect partner, one who shares your goals and openly commits to making the necessary investments? Think that perfect partner doesn't exist? Think you can't have "ERP for Life"? Perhaps you haven't been looking in the right places! :)