Skip to Content
Technical Articles

How to handle custom Fiori Application version?

Intro

This title may sound a bit odd, but I want to tell you about a situation that happens to me quite frequently with my clients.

Imagine being asked to create a freestyle application or an extension of a standard. You do it and you deploy it all the way to production. The users are happy and ask you for an evolution, which you do and deploy on the quality system. Another evolution request arrives while the first one is being tested.

At this stage you have 3 versions of your application! Problem…. How to manage the correction of the bug that has just been reported on the production system?

To answer this question I will write two blogs. The first one (this one) which will explain the notion of versioning for a home-made Fiori application. And the second one which will explain how to manage these versions with Git Flow.

What is a Version?

I based my rebuild on the Semantic Versionning 2.0.0 reference. It explains that the version hierarchy must be built this way :

Mengenal Semantic Versioning OnlineStore ID – OnlineStore ID

It is very important to have a clear and simple versioning system. At least, when you apply an HotFix the Patch number increase, if a new Feature is deployed then the Minor numbre is modified, and when the new version is no more compatible to the old one, the Major number is modified.

Where is that version number?

The answer is simple… in your manifest.json file at the applicationVersion attribute:

{	
"_version": "1.12.0",
  "sap.app": {
    "id": "ch.saphirnet.demo.odata.Demo_OData",
    "type": "application",
    "i18n": "i18n/i18n.properties",
    "applicationVersion": {
        "version": "1.0.0"
    },
    "title": "{{appTitle}}",
    "description": "{{appDescription}}",
    ...
}

In that example, the version is 1.0.0 and you can modify it easily.

Where to find it?

Now that we know how to have fun with version numbers, how can my users see it in order to communicate with me?

Thanks to the Launchpad, in the Me Area, you have the About option that gives you the information.

Conclusion

At this stage, you may not see the point of this notion of versioning, but I can assure you that the day you are going to implement this versioning system, the business will thank you, because you will be faster and more efficient in resolving bugs.

There’s one point I didn’t mention, but the fact of deploying applications with different versions, I noticed that the cache system was correctly managed.

The blog that is in preparation will exploit this version notion and integrate it in a Git Flow.

References

Image: https://onlinestore.id/2018/07/03/semantic-versioning-onlinestore-id/

 

4 Comments
You must be Logged on to comment or reply to a post.
  • We had the same challenges with our customers and custom apps. The way we have tackled it was (who would have thought? 😉) with another SAP Fiori development. We build the app to automate the issue-reporting: “Reporter for SAP Fiori launchpad”, integrated with issue tracking system (in most cases Jira or ServiceNow).

    With SAP Fiori launchpad plugin using semantic object and action, the Reporter picks the currently started app id and gets all other app attributes. One of the characteristics is the app version.
    Together with the version you get automatically in the body of the issue request in Jira:

    • app ID and official name
    • automatically taken, uploaded and attached screenshot
    • automatically generated, uploaded and attached su53 report – missing authorizations – it turned out to be the main reason for most of the problems reported
    • frontend and backend system id, mandant, logon language
    • user details with the timestamp
    • link to start the app

    More detailed video here: https://youtu.be/jXtkzR0d-4Y

    System auto assigns the Jira issue to responsible leads based on the app’s Area designation.

    We also linked it with change request records so you can track what changes the project requested for that particular custom app. Change requests trigger invalidation of sign-offs, so responsible team members see that developers made changes, and there is the need to retest and sign off the app again. The tool helped us avoid a bunch of lengthy discussions and save hundreds of hours.

    The Reporter for SAP Fiori launchpad is free, and you can read more and download it here: https://help.fioritracker.org/, https://github.com/fioritracker/installation

    /
  • Grzegorz Malewski thanks a lot for your comment. Your tool is a greate one for administrate Fiori applications.

    What I wanted to explain is this Version notion should be a main subject for all developpers when maintenance should be done. In the next blog (I’m still working on it) I will explain how to deal with it in a Git flow but for developper point of view.

     

  • Hi Joseph ,

    We are in same situation of a solution wen live recently  and same has to be rolled out to other regions in a template based approach . Maintenance + development happens in parallel . Please share the second blog if it is ready. Also, insights into how to handle both at the same time with automate of retrofit of bug fix into Project track .

     

    Thanks

    Ratnakar

    • Hello,

      I’m still writing it, it take some time to do it correctly and clearly 🙂 But hope soon I will provide the second Blog (maybe at the end of the next week).

      Keep tune 🙂

      Regards,

      Joseph