OpenEdge 11.2 ESAP – A Quick Tour

It’s been a while since I posted Part Two of the series on support for mobility in OpenEdge and I’m sure many of you have been on the (Open)edge of your seats in anticipation of the next thrilling installment. Well the wait is over!

The recently released OpenEdge 11.2 ESAP contains many of the bits that will ultimately be available in the GA version of OpenEdge 11.2 scheduled for February 2013.

Let’s take a poke around: In Progress Developer Studio for OpenEdge (PSDOE) we now have support for a Project of type ‘Mobile’.

And there’s a brand new visual designer in PDSOE integrated into the IDE:   The OpenEdge Mobile App Builder is a cloud-based service, thus supporting collaboration, and has extensive support for jQuery Mobile components. Although cloud-based, the Mobile App Builder allows developers to copy source files to the local workspace providing support for any source control mechanisms which may be in place. The Mobile App Builder also supports incremental test and development with a range of device emulators (iOS, Android and various form factors) baked into the facility. We’ll take a deeper dive into the App Builder in a future blog post,  exploring how simple it is to hook up events in the UI to back-end, OpenEdge-based services and ship data over the wire.

But what use would a Mobile App be without data from the OpenEdge database?

The OpenEdge Reference Architecture defines a Business Entity (BE) and we’ve integrated this metaphor into PDSOE. The BE leverages the notion of an abstract schema i.e. a ProDataSet or a TempTable as a convenient way to automatically generate reusable ABL classes.

The PDSOE wizard will optionally create “CRUD” operations against the BE. In our generated code, we can typically customize the data which is populated to the ProDataSet. Here is a short example of the data retrieval that is associated to the READ operation in the Business Entity (similar code is generated for other operations):

In addition, existing code can also be annotated to identify internal procedure or methods which may be required as part of the service interface (OERA). When you’re good with your BE’s, you can integrate them with the Mobile Service developed in an earlier step:

Now, we can tie our back-end services to a Mobile UI. In addition to developing the “look-and-feel” of the Mobile UI, we need to handle the communication between the client and the back-end services – enter the JavaScript Data Object (JSDO)!

The JSDO classes on the mobile client provide the developer an easy way to handle the interaction with the backend i.e. removing any requirements regarding the physical transport over the wire (HTTP/REST/JSON). This is a very deliberate “division of labor” in terms of how mobile applications are developed (JavaScript/jQuery Mobile on the client) and we’ll make it a focus of a future blog post. Finally, we can deploy our Mobile App either as a web application that works in any browser (mobile or tablet, but also a desktop), or as an App Store/Android application that you would find on any of the app store marketplaces.

I hope this short post whets your appetite for OpenEdge Mobile. Stay tuned for a closer look at the wonderful world of JSDO’s and “the catalog” in a future post!