Skip to Content

Launch Portal Page in Fiori Launchpad via LPD_CUST possible?

Hello folks,

I'm currently trying to "abuse" the "Launch Fiori App via LDP Cust"-Target Mapping option, which works for WebDynpro ABAP and Transactions for Portal Pages (Application Type POP). Unfortunately the javascript console tells me:

Navigation mode is not recognized - sap.ushell.renderers.fiori2.Shell.controller

Is this generally not supported or is there a chance I'm doing something wrong (if it is supported, I would of course go more into detail about what I did).

The reason I hope it works this way is, that our concept for access is supposed to work completly via authorities maintained in R/3-Roles and the WDA Launchpad (LPD_CUST) currently allows for that. We want to avoid having to create standalone iViews to include into our FFP with seperate mappings to organisationally redundant R/3-Roles (it's been this way in <EHP5 Systems with the so called "Homepage Framework" if anybody still remembers that).

Cheers, Lukas

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

3 Answers

  • Best Answer
    Aug 09, 2017 at 01:30 PM

    Cleaning up my old threads.

    Apparently the requirement is technically not possible in the standard; I went full time redundant and now have content in the FLP-designer only, in the FLP-Designer and LPD-Cust and Portal Content all mixed into one Portal Role. The result works like a charm but the redundancy in the back really is a shame and a big step backwards in contrast to the WebDynpro ABAP based Launchpad. :-(


    Add comment
    10|10000 characters needed characters exceeded

  • May 26, 2017 at 02:01 PM

    Bump. Guess my question is either very daft or very good (since it has no comments yet).

    Has nobody ever come across this requirement? Or maybe I'm overlooking something obvious which renders the requirement useless? Might even be, that my design-approach itself is bonkers.

    Let me try to eleborate once more, what I'm trying to achieve and what I'm trying to avoid:

    What I want to achieve: I want the distribution, i.e. this includes the visibility, of the Applications we use in our portal to be centrally controlled via Authorizations on R/3-Roles. I therefore thought of using one single freestyle Portal Role which contains all the content that users might have (but not necessarily do have) for our Remote Content (i.e. the stuff that comes from the FES on our Gateway). The advatage I personally see by doing that is, that we can have one portal role and one mapped R/3-Role (as anchor) as technical connection. Subsequently, when content is added to our environment, it would only be necessary to add the remote catalogues to this one portal role and assign dedicated R/3-Roles containing the authority for these catalogues (i.e. if you don't have the R/3-Authority you can't see the content although it's technically available in the portal role) plus, when assigning the respective R/3-Role, assuming groups are used, the respective user automatically sees the new content (group with catalogues) in his portal.

    What I want to avoid: I am fully aware that remote content and dedicated Portal content via iViews/Pages can be used simultaneously, but with my current knowlegde I see the following problems: If I assign an iView to a Portal role, the end user does not automatically "have" the tile in his FLP, i.e. he has to manually go to the App Explorer and add it to a group. Another strange observation I made is, that this can seemingly be done independent of authorizations in the Backend, meaning I was able to add a Tile from an iView I didn't have authorization for in the Backend. Subsequently this means for me, I can't just dump all the Portal Content in one Role, because users will see stuff they're not supposed to. Yet again subseuqnetly this means, I'd have to build dedicated portal roles and then Map and Merge them to dedicated R/3-Roles, plus, probably, do Portal Role merging etc. (like it was in the crappy Homepage Framework 10 years ago). All this seems overly complicated in contrast to the current WDA Launchpad, where I can centrally control everything no matter the source.

    Any thoughts/comments are highly appreciated. Much good Karma will come to you.

    Add comment
    10|10000 characters needed characters exceeded

  • avatar image
    Former Member
    May 26, 2017 at 02:21 PM

    Authority in FIORI Launchpad can be controlled at FIORI Launchpad Group Level.

    1. Create Launchpad groups by business roles.

    2. Add tiles to respective groups.

    3. Then setup PFCG roles by business roles identified and assign the Launchpad groups to the PFCG roles.

    That way, depending upon user role, the tiles automatically show up. There should not be need for any portal roles setup.

    Add comment
    10|10000 characters needed characters exceeded

    • My problem ultimately isn't about authorizations, maybe I wasn't being clear... it's that I want all my content or rather the navigation of the content maintained in FLP on the FES because then, subsequently, I can control assignment of content a lot more "centrally" than if I got content on the FLP and content in the Portal which is maintained in iViews/Pages and which I then have to mix in a Portal Role with the Remote Content from the FES which subsequently unnessecarily makes authorization more complicated.