Skip to Content
Author's profile photo Former Member

How to… maintain runtime versions of MBOs

Normally only one version of a service, application or a package exists in a runtime environment. In case of a mobile middleware it becomes important to host multiple versions of a service, package or application with the same name at runtime. Why?

Let us take Sybase Unwired Platform as reference. It allows us to maintain multiple versions of the same MBO project at runtime. Consider that we release our mobile apps in phases (1,2,3,4.. so on). Each phase is incremental in functionality and user interface. Assume that Phase 1 is live and we are in the process of releasing Phase 2. How will you manage this? There are existing users accessing Phase 1 apps. Obviously we will release Phase 2 as an update of the phase 1 app. Any good MDM will send a notification to the device asking the users to update. But the users can choose to ignore it. This means at any point in time after Phase 2 goes live we could still have users accessing Phase 1. This is app fragmentation. Imagine the pie chart after all of your phases have gone live.

One can arrange for automatic updates and force users onto use the new version. But that may not be always a nice option in an enterprise especially when you want comms and training to happen before the users start to use the new version of the app. One possible solution is to use deployment versions in MBO projects in SUP. The mobile apps can access the versions they are built to access. So if a user chooses not to update his/her app (on the previous version), it will continue to work. This not a magic trick, you can achieve it by changing your MBO project name, but when you are developing a serious enterprise application you will love this support from your development environment.

How to…

I have assumed native apps using MBOs to access SAP RFCs here. There are some caveats that are important to consider to make this work though, they are listed at the end of the blog.

1. Build the MBO project as normal and the unwired workspace assigns a default version 1.0 to your package.

2. Deploy and Generate code for Phase 1.

3. Perform the changes required on the MBO project (please use a versioning system to maintain code versions) for the next phase and as a first step, deploy a new version. This is important as the deployment dialog allows you to change version of the MBO project. See picture below.

deploy version.PNG

4. The wizard asks if you wish to change version of the project, confirm with yes. The MBO project is deployed with a new version. It looks like this in the Sybase control center.

server mbo versions.PNG

5. Now generate code for the native app to use. If you peep into the generated code {the <your project name>DB file}, you will find the new version.

6. When you run the app, SUP identifies which MBO project version the app wants to access based on the version in the generated code it is using. This information is sent by the SUP libraries when the app attempts to connect to the unwired server.

7. I maintain the different native app versions in a versioning system alongwith its versioned generated code. So I can run apps of different phases just by installing them on the devices from an internal app store which also maintains build versions of my app.


1. This approach will work only if the structures of the RFCs (in mycase, or any backend source) used in Phase 1 do not change in the subsequent phases.

2. It is important to choose when to have this approach versus when to force an update.

3. If we have different versions of the same app, it becomes a little difficult to monitor who accesses which version. On SCC Applications tab I can see a device connected along with user and app id but not the app version.

4. The data on the cache in the MBOs is culled based on MBO package versions. So your business data will be in different MBO caches based on the app fragmentation in your landscape.

You must tradeoff the flexibility it offers with the complexity it brings in. Remember one size does not fit all, so pick and choose. Would be great to know your thoughts.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Vladislav Volodin
      Vladislav Volodin

      Thank you for the good article. I have a small question: what will happen with the device data when I update the application (e.g. it uses MBO of 1.0 version) with a new version of the application (with MBO 1.1)? Will the new application remove all old local cache and download new objects (even, if old objects had same names and attributes), or it will download the difference only?

      I am asking this, because on the server side in CDB, new MBOs will create new tables.

      Thank you in advance,


      Author's profile photo Former Member
      Former Member

      This is when the deploy mode becomes very important.

      1. If a "replace" is choosen in deploy mode but if you increase the MBO version to say 2.0 from 1.0 then <yourapp>DB is a new package based on the version. So you will have two packages one with 1.0 and the other with 2.0.

      2. If you choose "upgrade" in deploy mode then the meta data of the MBO objects (object with same name) are updated.

      3. In case 1, you will have a fresh package which will be called <yourapp>DB 2.0 so your old data is no more available. Replace may not be a great idea, esp if you have cache policy in weeks e.g. for master data.

      4. In any case, you will have to generate code on the package again and include it in your client application.

      5. Case 1 is good for cache policy which is small. Not a great idea if you are using DCN and master data.

      Author's profile photo Syambabu Allu
      Syambabu Allu

      Hi Narayanan,

      Nice Blog.

      I understand your point about Native apps.

      How it will works for HWC apps?