(c) Copyright Sybase, an SAP Company

In the Hybrid App Designer, we bundle jQueryMobile as the User Interface (UI) framework.  The UI framework in an app provides the application user experience (screen-screen transitions, screen components).  It includes building blocks like a table-view, which can then have a number of configurations to meet the developer’s use case.  For instance, configuration ‘a’ sets each cell in the table to have a bold-face label, and a smaller detail text label.  Config ‘b’ adds an icon to the left of each cell. Config ‘c’ adds a disclosure button to the right of each cell.  And so on.

jQueryMobile is what you would call a ‘JavaScript UI framework’, because it is written in JavaScript, for use in HTML5 applications.  It is a replacement (/supplement) to a native SDK, such as Cocoa Touch on the iOS platform.  (Technically a supplement, since it leverages the WebKit runtime in the native SDK, but that’s details…).  There are a few other JavaScript UI frameworks that are increasingly relevant in the mobile application development space–especially in hybrid apps (web + native / container)–because they optimize the HTML development experience for mobile.  There is a huge advantage to an SUP developer of using these JavaScript UI frameworks, because they tend to be open-source, have plenty of community, and allow really rich customization of SUP Hybrid Apps that run in the Container.

I wanted to show a few screenshots of some jQueryMobile-based hybrid apps we’ve developed in the Hybrid Web Container.  These apps are connecting through SUP to enterprise data, can be managed and secured using the native functionality for SSO & authentication, and can be remotely provisioned on a role basis with the administrative tool.

Here, the jQueryMobile table view is combined with a button to launch an interactive webview to GoogleMaps that plots the current device location and the location of the customer.

Here, a stock check is displayed in a table view, with a numeric indicator of the quantity, and a bar chart indicating quantity vs. target.

All of this customization is basic web development in HTML5 and JavaScript, and requires no knowledge of xCode, Objective-C, Android development, etc.  The same app runs across all supported platforms, and can be re-skinned to match whichever OS it’s running on.

Subhasha described how SUP 2.1 ‘makes a nice handshake’ with Gateway.  “It was designed in such a way that you could say a ‘lemon’ could go in step-by-step and create SAP applications.”  His teammate Varun added:  “It was nice–we didn’t know what to do, and we went to this document [infocenter.sybase.com] and it says ‘do this, do this’, do that’.  So that really really helped.”

Describing the application design process:  “we had this content and the diagram available, and we were able to visualize how this application overall is going to work.  From that perspective we could see that these were the steps that we were going to develop/consume in NetWeaver Gateway, and these were the steps that we were going to put in SUP.  We created a PowerPoint slide with a diagram of the proper flowchart, and visualized how the application was going to work.  It worked in a similar way.”

View the video here: http://tinyurl.com/4y7jah5

Row Size

I realize that quite a lot of you already have a lot of experience using the SUP tooling.  I wanted to talk through some of the best practices of what we think is appropriate for MBO modeling.

The first thing about the MBO is that it is a data model on the client-side, not for the business back-end.  So you should consider whether every attribute that you put into the MBO is something that will be used by the application.  If it is not, than the implication is that you waste space in the CDB, you take up synchronization bandwidth when you sync those to the device, and you also take up space on the device.  If you send enough of those things, you’ll actually slow down the device performance.

The MBO instance is actually corresponding to a database row on the device.  Your MBO instance is nothing but a row in a database, and the columns are your attributes.  So the implication is that the row must fit within the page on the device.  The larger your row, the larger the page size that is required.

This is important because during generation, we look at your MBO model, look at the number of attributes, the data types, and we try to calculate what is the maximum row size.  We then compare that to the developer-entered page size, and if it is not large enough, we will actually start promoting some of your varchar data types corresponding to a string to long varchar, and get it out of the row itself.  Obviously when we do that, there are performance implications, because now there is indirection in order for you to access your data.  So it is important that you don’t just arbitrarily define a very large MBO, and then end up causing the code generation to start promoting a lot of your attributes into the long varchar type.

Typically, what we find is that when you start having 50 attributes, we have to really start wondering whether you have the right object?  Are you putting in the right information, and should you have 2 MBOs instead of 1 MBO?  Because the larger the row size, the fewer rows that we can put into a page, and then the more i/o’s that we have to do.

An easy thing we see is when people use a STRING as a data type.  Instead of using STRING, use STRING(n).  When you use a STRING and don’t define what the size is we default it to 300.  In one of the customer cases we saw, he had everything as a STRING, and he was blowing up the size of the row.  We started promoting just about everything into LONG VARCHAR, and that caused serious performance implications.

Another thing that you can do in MBOs with attributes with long maximum length that are typically much smaller is set the database on the device to run with a smaller page size than the one calculated at code generation. We see that with strings a lot where the developer defined a Notes column for 1000 or 2000 characters. When you add all those up, the row size can actually end up being quite large.  We end up bumping up the size of the page.  Usually, even though the back-end says the attribute is 2000 characters, in most cases, normally, you know there isn’t going to be that many characters.  You can use a larger page size–say, 16K–during code generation, and run with a smaller one–8K–on device if the normal size is much lower than the maximum.  But be warned–this may lead to a synchronization error if a record comes through at full size and cannot fit.  It’s something you’ll need to test.

Indexes

The other key issue is the Index.  You already know what they are and how to use them to speed up your query, but indexes actually impact the performance on operations, because if you do anything you have to maintain the index.  Even more-so, it actually impacts the synchronization, because if you sync data to the device, during the ‘apply download’ phase–when we try to apply the download onto the client-side data–we have to maintain those indexes as well.  So synchronization is actually impacted by the number of indexes you have for some of the MBOs.  We’ve seen cases where the customer has a lot of indexes defined, and we’ve seen that the data processing and synchronization takes much longer

So what we say is:  we know indexes are necessary for your query to perform well.  But you should understand the size of the data.  For example, if your table is very small, you didn’t really need that index.  There are some things we do automatically in the tooling to be aware of.  We generate ‘findByPrimaryKey’.  findByPrimaryKey is actually the business key.  Sometimes you don’t actually need to find the primary key.  A good example is if you have child MBOs, maybe you’re doing navigation to access the child MBOs.  findByPrimaryKey is not something you normally use for the child MBOs.  In that case, the best thing to do is un-check the option for auto-generating so that we will not generate findByPrimaryKey, and then create indexes for the key.

The other thing we generate–which doesn’t impact the indexes–is the findAll.  Even though it doesn’t require indexes, it is a very expensive operation to perform, because it returns the entire collection of objects as a list, so if you have a lot of collections of MBOs, that can actually impact the performance as well as the memory consumption.  So findAll is something that it’s best not to use unless you know that it will be returning a relatively small collection.

In the tooling, we allow you to create custom Object Queries.  When you create object queries, you also have the ability to create indexes for them.  That’s one more opportunity to manage the indexes.  So it’s always a tradeoff on a mobile device–you can’t take the i/o and memory for granted–so you should use these options to optimize for your model.

Synchronization Group

As far as Synchronization Groups go, what are the best practices?  The main thing is to allow you to control what is being synchronized, so you don’t always have to end up syncrhonizing everything across to the device.  The concept allows you to customize, or prioritize the MBOs that you want to get across.

You might want to get your call ticket or service ticket across first, but you don’t want all the details associated with it.  Later you want the details if they’re necessary.  Or we see customers only sync bulky materials when they have a wifi connection.  The sync group gives you that flexibility to control what you synch, and limits the amount of data traffic, which is important when you have limited connectivity.

Now, in the synch group, just like the MBO, when you start putting a lot of MBOs in the sync group, you should again question:  is this the right thing to do?  The idea of the sync group is to control what you sync.  When you start putting everything in there, it kind of defeats the purpose.

Typically what we recommend you do is:  any MBO that’s in a relationship should be put in the same synchronization group, for the obvious reason that you don’t want to sync half of the object graph across. Then again, if you have a really huge object graph that consists of many MBOs, again you kind of defeat the purpose, so that’s something you should consider when you craft your graph and synchronization groups.

Sometimes, we purposely break this rule when we want to separate the higher priority object from the lower priority data coming across.  But it can expose you to an incomplete graph, and as a result you may have a case where you can’t access all the data on the device.

Even though you specify the sync group, that doesn’t mean you lose flexibility for cases like when you have wifi connection and want to pull everything across in one synchronization.  During runtime, you can specify a synchronization that syncs all the sync groups together in one session.  So you have the flexibility of setting sync duration to “1″, or “5″, and it doesn’t really matter at runtime because you can over-ride from the device.

Cache Group

I mentioned that the Cache Group is somewhat similar to the sync group, but the impact of the cache group is really on the CDB, and how you load the data.  By having a cache group, it allows you to break up your data between the back ends.  Normally, if you have everything in one cache group, the result is:  anytime you do anything, the whole cache group might be refreshed, depending on the caching policy.  That might not be the right policy, because everytime a user changes something, the whole cache group might be refreshed, and other devices might have to wait.  So the idea of the cache group is to separate out similar MBOs that have similar cache characteristics, so you can then apply a policy to only load that data when they are needed.

In a similar vein, when you do put object graphs across multiple cache groups, you can end up with incomplete graphs–it’s no different, because the CDB itself is also a relational database.  So you can get warnings spilling out telling you that we are not able to link up with the relationship. You can do that, but in some cases it can impact your performance, and I would definitely recommend that you put related objects in the same cache group.

One of the things that is the most common-sense thing to do is:  map the synchronization group to the cache group.  The reason is:  when the cache group is being synchronized, it’s going to trigger the data to be potentially refreshed or retrieved from the back end.  If the granularity between sync group and cache group doesn’t match, you could potentially have one sync group that triggers a very large cache group to be refreshed, and the end result is you waiting for the entire cache group to refresh before the synch continues.  The mismatch can slow you down.  So the most common sense is to map it so when you sync something, you only cause that group to refresh from the back end.

The other thing to do is avoid circular dependencies between cache groups, because when one refreshs, then the other group will be wanting to refresh, and that’s not going to work very well.  Similarly, avoid driving the load of an MBO in one cache group based on attributes of an MBO in another cache group.

In summary:  the Cache Group controls how the data is being retrieved from the back end, and the Sync Group controls what is synched.

The quick and dirty New Features:

• OData SDK:  Support for NW Gateway, RESTful native application development
• Hybrid Web Container:  Camera API, enhanced Offline Storage API
• Application Lifecycle Management tools:  Afaria SDK integration, automatic user on-boarding

The key message:  SUP 2.1 is the platform for 20+ SAP-delivered applications in Q4 2011, including Mobile Sales 2.0, EAM, Retail Execution, Field Service, and the Employee Productivity Suite of person-centric native apps.  The new functionality improves our ability to manage and administer these apps and users, and points to the platform value of providing deepening integration between the management tools and the SDK tools themselves.

To answer the question:  the OData SDK is additive to SUP.  We now provide APIs for 3 core scenarios:  offline/synchronized, online+ (business process push in the Container), and online/RESTful.  As we evolve into a world with nearly ubiquitous connectivity, wifi, and LTE, the RESTful OData programming model is a simple, standards-driven way to develop apps with rich UI’s and exciting user-experience, make ad hoc requests, and consume analytics.  SAP and Partners will continue to develop for both offline and online apps on SUP, driven by the use case and customer requirements.

We had a great Knowledge Transfer workshop this past week on the 2.1 release with R&D and our field consultants, support, CSA, and pre-sales teams.  I’ll have full posts with excerpts of the presentations OData, MBO Best Practices, and Hybrid Web App development over the next week.

Weinre isn’t  a step-by-step JavaScript debugger.  But it does allow you to use the console to write in JavaScript calls, and drill-down into the returns.  What does this mean?  You can see the live state of the MessageValueCollection when you make a query, or call a submit.  You can see exactly what the structure of the results is, check the key values, and see the functions available.  In short:  it’s pretty awesome.

Check out these tutorials for using Weinre in Hybrid Apps on iOS, Android, and BlackBerry.  They mostly show the same functionality–there’s some additional things in the iOS and Android screencasts that didn’t make it into the BB6 video, but still work across all the platforms.

Key takeaways:

• Add the Weinre target-script-min.js src location to customBeforeWorkflowLoad().
• Use the Weinre console to call getCurrentMessageValueCollection() to view the current contents of the Message Value Collection.

(The Weinre homepage is hosted here:  http://phonegap.github.com/weinre/).

Check out the other videos here:  http://www.youtube.com/playlist?list=PL0B1BEA2F5930BE70.

Apologies:   there weren’t any cue cards, so the intro is a bit off the cuff.  But we get going into regular conversation shortly @ the 3:15 mark.

link:  video

Second:  now that I can set TechEd prep aside, there are a bunch of SUP development posts that have been stacking up that I want to get out.  To start off, I’ll deal with a most basic question recently posted to the Why Are We So Excited About 2.0.. post:  “When I am deploying application in SUP workspace, an error is generating while connecting to ‘My Unwired Server’.  The error is: ‘ Could not connect to My Unwired Server’. Ping also failed.”

If you cannot connect to the SUP Server, this typically means one of two things:  the server isn’t started, or you have a domain configuration which is incorrect.

Check the SUP Server is running

1. In the Services directory, look for: SybaseUnwiredPlatform<hostname>Server1
2. If it is not started, click the ‘Start Sybase Unwired Platform Services’ batch file icon installed on the desktop.  The batch will run, and attempt to start the set of SUP services.  This includes the internal databases, the OpenDS service, etc.  When it comes to the SUPServer1 service, it will check some properties against the license/admin service.  This happens regardless of whether you are using a licensed or evaluation environment.
3. Refresh the Services directory.  If the SUPServer1 failed to start, that means one of two things:  the license settings are inaccurate, and/or the admin services are improperly configured.
4. If the SUP Server is running, skip to:  Check the Connection Profile Settings

Check that the License settings are correct

1. Make sure your license is for the version you selected @ install.  This process is documented here:  Sybase Unwired Platform Licenses
2. Key Points:  make sure that you have the correct version of the license (Locating Information in a License File)
3. Troubleshooting guide is here:  Troubleshooting SySAM

Check the Admin Tool Domain settings

1. Sometimes if you installed SUP while on a corporate domain, that domain setting will be hard-coded to the Admin service-config file.  To check this, go to: <Install dir>/SCC-3_0/Services/RMI/, and open service-config in Notepad.
2. In the <properties> tag, make sure that the “address” value is set to “localhost” or an appropriate IP for when the administration service is running locally.
3. Example:

<?xml version="1.0" encoding="ISO-8859-1"?>
<service-config id="RMIService" version="3.0.0" name="RMI Service" class="com.sybase.ua.services.rmi.RMIService" provider-name="Sybase, Inc." register-on-startup="true" mbean-type="Model MBean" mbean-descriptor="mbean-descriptor.xml" arl-config="arl.xml">
  <dependencies />
  <properties>
    <set-property property="address" value="localhost" />
    <set-property property="addressType" value="dynamic" />
    <set-property property="port" value="9999" />
    <set-property property="timeout" value="43200" />
  </properties>
</service-config>

Save.  If you changed this setting, you should re-boot your machine so that the SCC service can capture the new value and take effect.  Once you’ve confirmed in the Services window that the Sybase Unified Agent 3.0 is ‘Started’ (not just ‘Starting), run the ‘Start Sybase Unwired Platform Services’ bat file on the desktop.  The server should get running.

Check the Connection Profile Settings

Now, the server is running, but you can’t connect from the Eclipse tool.  This has to do with the same domain issue as in the RMI service, and is a much easier fix because you can do it right in Eclipse.

1. Right-click on the ‘My Unwired Server’ connection profile in the Enterprise Explorer window, and select ‘Properties’.
2. Switch from ‘Common’ view to ‘Unwired Server Connection Properties’.
3. If you are running SUP on a local machine, delete the value in the ‘IP domain’ field.  Leave it empty.
4. Click ‘Test Connection’ to get a ping.  You should be able to ping successfully.

Special Case:  TechEd 2011 images: If you are using a TechEd 2011 image, you must also change the ‘Port’ value to 20000 from the default 2000.  This was modified during the image creation to eliminate a conflict, and was not propagated to the WorkSpace configurations.

Coding started at about 4:30pm.  No one in the room had any experience with SUP at the start, and the team members were a combination of developers, architects, and business analysts.  They broke into teams of 2-5 around business scenarios that they’d brought with them or shared.  At least one team had prepared service wsdls.  Everyone targeted the Hybrid Web Container, using primarily the Eclipse-based designer, and a few of the 8 teams wrote directly to the HTML and JavaScript.

I caught up with the AMD/Satyam partnership at about 10pm, right after they’d succeeded in hooking up the 3rd-party charting library they dropped in the Container to the data coming out of the SAP ECC system, and deployed to the iPad.

The teams broke at 3:30am (though one of the HP Technical Leads went straight through the night), then re-convened early morning to work through to the 4:30pm cut-off. By brunch the business scenarios were showing definite shape, and included: (team-member organizations)

• Expense submission and approval (Nvidia)
• Customer service request for a support contact center (HP)
• Journal Entries (FI) Approvals (eBay)
• Maintenance Notification Creation / Service Notification Management (Genentech, Intel, IGT)
• Executive Dashboard Reporting (AMD, Satyam)
• SAP System Health Checker (BAPS Software Consulting Services, HP)
• Sales Order Approval / Invoice Approval (KLA, Maxim Integrated Products)
• Workflow Management (Applied Materials)

A few great takeaway stories:  Prithvi, the young man feverishly coding with headphones-in on what would become my personal favorite app (a remote-monitoring app to check SAP system status) turned out to be a Duke EE/BioTech undergrad attending with his father Bala.  His task was to read comma-delimited values out of the Message Value Collection in Custom.js containing the system load data and render in a table view.  Another screen presented color-coded the state of multiple systems.  Bala took the iPad in the raffle, so I’m guessing it was good flight home for father/son.

The Genentech/Intel/IGT (‘Team Awesome’) partnership that would go on to win the competition had an agressive plan to use location services from the device in the Hybrid Web Container as input to a server-side SQL query to determine ‘Functional Location’ of a maintenance request.  Every object in the company is assigned a ‘functional location’ mask that is associated with a cost center.  The codes for functional locations are virtually meaningless to most end-users, so using the device location to automate the entry will streamline the process for users, and reduce help requests and errors.

Rob Robertson (Intel) Ashish Singh (Genentech) George Rally (Genentech) Raj Chintam (IGT) Brian O’Neill (IGT)

Starting in the morning they were the dark horse–they’d had trouble with the BAPI-MBO interface for the notification creation BAPI, and there was some debate as to whether to use the easier SQL data source in order to meet the competition deadline.  But then the BAPI ‘clicked’, and from there, “we started just pumping out screens”, said Brian O’Neill from IGT.  “Then it was like, you work on this, you work on this, and you work on this, and then we all came together and mashed it together.  Most of the app got written in the last 4 hours.”  The final product was ‘A Day In the Life of A Service Technician’, an app to enable a complete suite of tasks for a serviceman– an impressive leveraging of location-based services to retrieve Functional Location as an input for a new maintenance notification, also calling Google location services to provide a site image for the record.

At 4:30pm coding stopped, and the judging began.  Raj Nathan of Sybase, Sanjay Poonan and Dan Mahowald of SAP, and Tiago Dias of Slalom Consulting (who sponsored the event) viewed 6-minute presentations from each team, asked questions of the participants, then returned after deliberation to award TechEd 2011 Vegas tickets to two winning teams:  the Team Awesome partnership, and Rakesh Palle of Applied Materials, who was the only individual participant.

I want to thank everyone who participated, and the InnoJam team for hosting.  The event was a great opportunity to get to know our developers while they’re hands-on with our SDK, understand their business scenarios, collaborate, and show-off a bit.

There is another Mobility InnoJam in Australia early next week, looking forward to seeing the video.  For more, see photos, follow @SAPInnoJam on Twitter, and show up at DemoJam at TechEd!

As I was finishing penning the response, I started thinking about Steve Jobs’ comments in the WWDC 1997 closing keynote about developer productivity (41:24 mark in clip):

“The way you get programmer productivity is by eliminating lines of code that you have to write. The line of code that’s the fastest to write, that doesn’t break, that doesn’t need maintenance, is the line of code that you never have to write, right? So the goal here is to eliminate 80% of the code that you have to write for your app. That’s the goal.”

That’s exactly it. SUP’s libraries and code for native apps (the Object API) is a ‘managed object’ approach to developing with on-device persistence, similar to the iOS-specific Core Data framework. Managed object approaches provide significant benefits to developers by eliminating the amount of code they have to write, and eliminating points of failure. SUP’s Object API provides the client-side data management functionality, and also provides a huge set of functionality that Core Data does not:

1. The ability to connect to an external data source and authenticate
2. The ability to handle (queue) operations on the database when offline
3. The ability reconcile with the external data source when the device reconnects. This means processing the format of the result set and writing to the database/exposing to an object ‘under the hood’. Similarly, it means updating the client database without wiping out pending operations.

These features: connectivity/authentication, update handling, and queuing are all API features provided by SUP for which a developer could write code, but it would be long, complex, and difficult to maintain.

To understand just how important a managed object API is, I’ve compared the development processes for a purely client-side app that uses raw SQLite, Core Data, and the SUP Object API. See how the two managed object approaches are quicker to develop and much less likely to be buggy or to break:

Your development process is as follows:

For raw SQLite:

• Write the SQL to create the data structure
• Create NSObject classes for each of your objects. These map to the tables you’ve created in the SQLite db.
• Write the query methods for each of your queries that will be needed by the application. if you’re pretty good, these could be generic (taking the object class types and set of clauses. as parameters), or specific:  -(Customer *)getAllCustomersInRegion:(Region *)region ofGender:(NSString *)gender age:(NSNumber *)age …
• You need to then write the handles for the database results to pass them to the NSObject. This means if you have 20 attributes (columns) in your table, you’ll be writing a 20-line block of code to accept each item in the result array, assign it a type, and map it to an attribute in the NSObject. This is a freaking pain, because each attribute is name-specific, and possibly type-specific. So you can be clever and create a static array of the attribute names for each NSObject, and then iterate through them for this. But that array is another ordered thing to maintain. The difficulty of maintaining these queries is directly proportional to size and specificity.

For Core Data:

• Use the Core Data modeling tool in xCode to create the data structure
• Generate the NSManagedObject classes for each of your objects. These map to the model.
• Use the Core Data framework (including the FetchedResultsController) as your structure for processing SQL statements. You can use Key Value Coding, which is another thing to learn, but is pretty useful once mastered. You will still need to construct the SQL statements to input to the FRC. Fortunately, you can map result sets directly to the managed objects, so that eliminates all the garbage of maintenance described above.

For SUP Object API:

• Use the Eclipse modeling tool to create the data structure
• Generate the MBO classes for each of your objects. These map to the model. The database is generated at initial runtime ‘under the hood’.
• Use the generated methods for returning results from the database. Results are automatically mapped to managed objects.

So, as you can see: SUP Object API and Core Data are both ‘managed object’ approaches to persisting and working with data on the device (for iOS). They both require learning to use the API for accessing results, but the benefit in terms of unbreakable code and reducing maintenance is huge.

Where the SUP Object API extends that benefit is by also managing the code for connecting to an external data source, authenticating, and updating the databases on both the back-end and on the device.

Really quick, think about the mess of attributes and mapping I described in the ‘raw SQLite’ approach above.

Now, think about the code that you’ll have to write in order to make a connection to your data source, authenticate, submit any create/update/delete operations you’ve stored since the last time you connected to the network (you should also create a flag in your tables to create keep track of that…), then retrieve the current values from the data source.

How will you deal with the results? Will you write a block of code to check whether each result is an update or not? Will you just over-write the existing data? What if the user was working while that happened? What if the results for every user are 5MB, and most don’t have WiFi?

It’s doable. It’s an absolute nightmare to maintain, and SUP provides a huge benefit by handling it all for you.