The goal of this series of posts is to help mobile developers transition to AppBuilder, the new mobile UI development tool from SAP, by comparing it to a tool that many developers may already be familiar with – SAP and Sybase’s PowerBuilder. A fair amount of the technology in AppBuilder actually comes from PowerBuilder, so the comparisons work well to illustrate development practices. The previous two installments of the series, here and here, have focused on the SuperList control. In this article, the SuperList is still a focus, but we'll be discussing aspects of backend integration, specifically, designing the data source for SuperList controls using OData. But before we get there, let’s take a quick refresher on PB’s datawindow.
PowerBuilder’s datawindow control has two primary roles in an application – managing the UI presentation layer, and retrieving and updating data in the backend data source. It is essentially a combined control that implements both the Model and View layers of an app. In most cases, that backend datasource is a relational database, and the resultset for the datawindow is created from either a Structured Query Language (SQL) statement or a stored procedure call. (Support for invoking web services is also available, but not discussed here.) Therefore, a critical skillset for PB developers is to be able to navigate the relational schema and design efficient queries. In my experience, 99.9% of performance problems with a PowerBuilder app can often be tracked down to a poorly-constructed SQL query.
SQL statements for PB datawindows are designed with a very powerful graphical editor. It’s possible to design very complex queries with this editor, with advanced options such as UNIONs, correlated subqueries, outer joins, aggregations, and so on. Figure 1 below shows a typical query in the datawindow SQL editor. An even more powerful aspect of the datawindow engine is its ability to translate the graphical query model into the specific syntax of the DBMS backend being accessed. This abstracts out any subtle differences in the SQL syntax across platforms, and allows a single datawindow to operate across different backends.
Tip #3: AppBuilder's SuperLists are based on OData, not SQL
The result set in AppBuilder does not come from an SQL statement, it’s derived from the payload of an OData web service method. OData has been described as “ODBC for the web”, but it’s got a long way to go before it can replicate the power and flexibility of SQL. There are some OData options for doing SELECT, WHERE, ORDER BY, and rudimentary joins. There’s even a “TOP <N> and SKIP <N> for data paging, but the default behavior of an OData query is basically “Select * from table”.
There are three prerequisites for starting to work with OData in AppBuilder. These are:
- have an OData endpoint defined with a valid service URL;
- create an Application ID in the SMP management console, whose “backend” endpoint references the service URL;
- register (aka “onboard”) the AppBuilder IDE to the SMP server, and point to the Application ID;
The AppBuilder SMP onboarding dialog looks like this:
Once those are completed, you should see a list of OData services that match those in the Onboarding dialog appear in the left-hand panel:
In my sample OData service, I have four entities defined - three tables and a view object. These represent the “base queries” that can be executed through the OData endpoint, but they basically correspond to “Select * from <entityName>”. Select one and click the Preview button to see the JSON resultset that’s generated.
Any decent developer knows the downside of the “Select *” approach. To add functionality like selecting a subset of the available fields, adding a sort order or where clause, or restricting the number of rows retrieved, you have to create a new OData query and add those OData options to the URL string. That brings us to another major difference from PowerBuilder: there's no graphical query editor for you to customize the result set. It's all done through the OData URL syntax. In PB, the graphical query editor is already “inside” the datawindow painter, and altering the query is a single button click away. In AppBuilder, the query definition dialog is accessed from the SMP Services panel (shown above), and that's outside the SuperList designer. You define a new OData query by selecting the SMPOData root node, then clicking the 3rd icon from the left – New SMP Query. That opens the following dialog:
This dialog has three fields – the query Name, the OData URL string, and a dropdown list to select an existing OData query upon which to “base” the new query. In my opinion, these appear out of order, because selecting the base OData query (field #3) will populate the URL field (#2) for you! Any edits made in the URL field are discarded as soon as you select a different “base” OData query, so remember to choose that one first…
In my use case, I want to define a new query based on the “recipes” entity. This is going to retrieve all the ingredients for a single recipe, based on the recipe’s primary key. I’ll call it “IngredientbyRecipe”, and I’ll select “recipe” from the list of existing queries. I’ll then need to add two OData query options to the URL:
- ({0}) will parameterize the query, and retrieve a single Recipe row that matches the primary key;
- $expand=ingredient will join to the Ingredient entity and retrieve all the child ingredients for the recipe. These will appear as collections underneath the recipe node in the result.
The final OData URL looks like this:
http://10.0.0.8:8080/com.sap.recipes/recipe({0})?$expand=ingredient
The addition of the parameter in brackets immediately changes the appearance of the dialog window, and adds fields to enter the parameters. If you need more than one parameter field, just number them consecutively, starting with {0}.
I now have a named OData query that can be used as the datasource for a SuperList control.