Skip to Content

With NetWeaver 7.4 SP7, there is a new Fiori framework page available to enable portal users to launch Fiori applications from a Fiori Launchpad like UI. Since the new framework provides lots of benefits to the users beyond just UI harmonization, great usability, and responsiveness (e.g. support of Fiori apps wave 2 and above), it was clear to me that I wanted to take my Mobile Portal demo scenario to the next level and move it to the new design.

In this blog, I will share some insights and experience on what changes between the classical Mobile Portal and Fiori launchpad on EP.

1. Enabling Fiori Launchpad

As of NW 7.31 SP12 / NW 7.4 SP7, there is a new Fiori Desktop and Fiori Framework Page available. You can find both in Portal Content > Portal Users > Standard Portal Users > Fiori Framework Content. Just assign the desktop to a your own URL alias (defined with URL Alias Manager) in a rule collection to make it available.

2. Content

It is important to understand that users can consume any type of content (like Web Dynpro, SAP UI5, SAP Screen Personas) in the new Fiori Launchpad on Portal and not just Fiori apps. You can run all Portal iViews in Fiori Launchpad. With 7.4 SPS 8, there is a new type of iViews, which was not available before, the SAP  Fiori iView for Fiori wave 2 and above applications.

Like for Mobile Portal, the new Fiori launchpad content is assigned to the Portal user in portal roles. In FLP on Portal, the roles contain all iViews to which the user has access via the tile catalog, but the user can select and personalize which of these iViews he wants to see on his Home Page.

3. Personalized Launcher vs. Tile Catalog

My Mobile Portal uses the Personalized Launcher to give users access to applications and to provide a catalog with additional content for personalizing their Mobile Portal Launcher. Concept wise this is not very far away from what the Fiori Launchpad provides. Here as well, you have a catalog which contains all iViews/tiles that you can display in your Fiori launchpad. This tile catalog, like in the Personalized Launcher, is structured by categories. The iView property Mobile App Categories defines in which categories of the tile catalog an iView shows up – just like in the Personalized Launcher. There is just one difference: The location where the available categories are defined changed. You now configure the categories (ID, order, and title for each of them) in very much the same way as in Mobile Portal, just in a different iView: Fiori Launchpad Categories in Portal Content > Portal Users > Standard Portal Users >  iViews > Fiori Launchpad.

4. Filter ID vs. Object ID of Device Group

Mobile Portal uses filtering based on filter IDs to determine the content for each device type. This is not always easy, so I really like the new, simpler way of doing it: device groups. Already for Mobile Portal, you configured device groups to assign them to different portal desktops with specific appearance and behavior. Now, you can just reuse them and define for each iView on which device groups it should be displayed. This is done in the iView property ObjectID of Device Group.

After that short introductory comparison, here is what I did to set up my Mobile Portal scenario with Fiori launchpad on Portal:

1.  Define the Portal URL alias and assign it to Fiori desktop in Master rule collection

MasterRule.png

2.  Configure the tile categories in the Fiori Launchpad Categories iView

FLPCategories.png

3. Since I wanted to keep my mobile Portal content in place, I just created a copy of the portal role used for Mobile Portal.

4. I removed all the filter IDs, since they are not needed in the FLP scenario, and made sure that all iViews are set to Visible in my role.

Role.png

5. For all iViews, I adapted the following properties:

    a. Object ID of Device Group: I found the Object IDs in the Device Group Manager in System Administration > System Configuration > Portal Display

DeviceGroupManager.png

and entered those on which the iView should be displayed separated by semicolons into the iView property.

ObjectID.png

If the property remains empty, the iView will not be displayed on any devices, so this property is really important. And note that you have to enter the ID of the device group, not its name.

    b. Native: Checked it for native apps, so they only appear on mobile devices.

    c. Permanent in Launcher: I checked all iViews that should show up in the user’s home page when he first logs in. If you do not set any iViews as Permanent in Launcher, the user will first see an empty page, when he logs in. He can then open the tile catalog and assign tiles to his default group My Home or create other groups and assign the tile to it. Users can still remove iViews marked as Permanent in Launcher from My Home.

    d. Image Type for defining the way the selected image will be displayed (as an icon, full tile).

    e. Mobile App Categories: I entered the IDs of the categories I wanted to assign as a semicolon separated list.

MobileAppCat.png

6. To enhance my demo, I added also some Fiori wave 2 apps. The Fiori wave 1 apps run as in Mobile Portal (see my blog about that), but for Fiori wave 2 and above apps, there is a dedicated iView template available. There is a detailed blog by Irena Kull on this topic. Please note that the system that hosts the Fiori wave 2 application needs to be set up to run with web dispatcher.


7. As a second enhancement, I added some Personas apps. Please see this blog for details.

8. I created a new demo user and assigned my new role to him.

9. Then I logged in with the demo user, created some groups (Sales Executive, Employee Services), assigned some tiles from the tile catalog, and moved some of the permanent tiles around. Here you see the result:

FLPFinal2.png

Finally, you can also customize the portal theme used in the Fiori desktop with the UI Theme Designer.

Hope that was helpful,

Sibylle

To report this post you need to login first.

10 Comments

You must be Logged on to comment or reply to a post.

  1. Sandip Agarwalla

    HI Sibylle Brehm        Aviad RivlinSibylle Brehm

             

    My current client is looking to mobilize their BW Portal. The first choice is ofcourse the Fiori Launchpage framework page. However I had couple of questions

    1) Does the FFP supports deep role structure like we have in regular mode ( role containing worksets, then pages, iviews) . How many levels of role structure is supported by FFP

    2) Are the BW Reports ( Bex, Webi, BOBJ) supported in FFP? Will then run inside the FFP or it will be opened as a new window?

    Appreciate if you can help.

    Thanks

    Sandip

    (0) 
    1. Sibylle Brehm Post author

      Hi Sandip,

      the FLP desktop provides a quite different look and feel from the Ajax FWP as we know it. You can still have roles with a structure of folders and pages etc., but that will not be reflected in a hierarchical way in FLP. In the FLP design, all iViews are reflected as tiles which can be grouped for a better overview and which can be assigned to categories to better find suitable ones. So, you can have as many levels in your role as before, but that will not influence the way the user sees the tiles, as for building FLP those levels are not taken into account, but just the iViews that are part of the structure.

      As for your second question, yes, you can integrate BW reports (BEx, WebI, BOBJ, Web Application Designer). Like all other iViews, they will open in a new browser tab, as the tiles are just designed for launching applications, but not for showing anything in place.

      Hope that helps you.

      Best,
      Sibylle

      (0) 
      1. Sandip Agarwalla

        HI Sibylle

        Thank you so much for your reply.

        Is there a way we can force the BW reports/Web Dynpro apps to open inside the Launchpad? It may not be a good user experience if the reports/other iViews open up in new windows.

        Best Regards

        Sandip

        (0) 
  2. Devisha Bhavik

    Hi Sibylle,

    You have mentioned that using the Device groups, we can decide to show the conents for specific device groups only. That holds true when we access Portal with Fiori framework on different devices.

    But does it hold true for AJAX framework as well?

    For example, device groups are defined as smartphone & tablet device group IDs on iViews. Also, for these device groups, we configured the rules to launch Fiori desktop. But for laptop, we configured to launch AJAX framework.

    Now, in the AJAX framework on the laptop, I still see the contents which I had configured for Fiori only by defining Device groups.

    Not sure this is how it works or something wrong in it.

    -Bhavik

    (0) 

Leave a Reply