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.
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.
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.
Caveats:
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.
- SAP Managed Tags:
3 Comments
