Skip to Content

Is OBN "compatible" with the FLP's Intent-Based Navigation?

Hello folks,

.

System Information

  • Portal running on Netweaver 7.5 SPS8 with FFP containing Remote Catalogues from the FES, using the Fiori 2.0 Guideline with 1.4X Libraries from JAVA side
  • Gateway (FES 3.0) running on Netweaver 7.5 AS ABAP SPS5 and SAPUI 7.52
  • ERP-System (BES) running on Netweaver 7.5 AS ABAP SPS5, respectively EHP8 on SP40
  • no Hana Montana

.

Background

I'm currently implementing a Portal with lots of, as you call them today, "legacy Apps", i.e. WDAs and I recently got spooked by some applications' navigation behaviour. I'll use the POWL-based Application FITV_POWL_TRIPS in this question as a reference.

.

Short Example of the infrastructural traffic that takes place (to better understand my problem). On our BES with got our Business Applications, in this case, lots of stuff for travel management. On Our Frontend Server we have created Trusted HTTPS Connections to consume the said business applications; here we also have our FLP with Catalogues, Groups and so on. Finally, on our Portal, we implement the Catalogues from the FES as remote content in a Portal Role. So, in a nutshell: Portal --> SSO FES --> SSO BES and vice versa.

.

Problem (or my not understanding due to missing knowledge)

I gotta shortly explain the application's navigational behaviour, otherwise it's not understandable: The WDA FITV_POWL_TRIPS ultimately uses a utility class called CL_FITV_NAVIGATION for (you guessed it) navigational means. The class polls the runtime to determine the caller's shell (standalone, nwbc, portal, etc.) and respectively creates navigational events, i.e. OBN-Calls or direct URL-Calls or Portal Events.

.

Now, in our "ye good olde 7.31 Portal" with AFP and WDA Launchpad (HRESS_A_MENU) the said class would determine the shell to be (surprise) nav-mode=2, i.e. a portal shell, it would then poll the local LPD_CUST settings and navigate into the Portal with an OBN-Call. Now, in the new 7.5 based Portal, using FFP, the runtime determines that the shell is nav-mode=4, which is NWBC. I assume this is happening because the FLP ultimately runs in an nwbc-shell and even though the FLP is again rendered in the FFP, the portal shell seems to become overruled by this somehow. At least that's the only explanation that would make sense to me. It might as well just be a bug. In any case that's where I start feeling lost because the "new" navigation in the FFP works with the FLP's Intent-Based Navigation. Neither aforementioned nav-mode works at the moment because I haven't created any BO-Portal-Content and I haven't created OBN Configurations in the respective PFCG-Role, so both navigation calls run into oblivion.

.

At this point you might ask "why don't you configure stuff then, if you know what's missing" --> Yes, you're right, but I usually want to understand how things correspond with each others instead of blindly following dogmas and with my current knowledge I don't see how OBN-Navigation (it comes down to that in both cases) "interacts" with Intent-Based Navigation. Let me elaborate on what I mean with that: I would expect, that when I, e.g. open a Scenario (Tile) which uses an Intent based Navigation and a target mapping with LPD-Cust in the background for a WDA application and it comes down to, let's say "<Portal-FQDN>/#ZTripsOverview-display" to start the scenario "My Trips and Expenses" (that's the aforementioned FITV_POWL_TRIPS), I would then, upon pushing a button that's supposed to call a corresponding scenario, expect the Application to "magically" navigate to the corresponding Remote Catalogue, say

"<Portal-FQDN>/#ZTravelRequest-change". And this is exactly where I'm getting lost, i.e. I can't really grasp how this interaction IBN --> OBN --> IBN is supposed to happen (if it does at all).

.

I hope it's somehow understandable what my issue is, as I don't know how to verbalize it any better for the moment. Maybe I'll add some pictures later..

.

Thanks for reading & any discussion content is highly appreciated (if only for helping me think into the right direction >.<)

.

Cheers, Lukas

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

5 Answers

  • Nov 09, 2017 at 03:07 AM

    G'day Lukas,

    I'm on a similar path in our sandpit systems (WDA Launchpad -> FFP) but a bit further behind you, so not really able to add any factual insight to your navigation questions at this point in time. Having said that, I'm not all that surprised that the OBN navigation logic in the BES hasn't been fully updated to play happily with the FES/FLP/FFP.

    I am curious though how many services you are migrating to the FFP and if there are a lot (we have 80+), how you are structuring the layout of your FFP? We are also heavy users of the HRESS_MENU BAdI to restrict the availability of certain services, and I'm not sure how/if we are going to be able to implement something similar with FFP.

    So in short - I feel your pain :)

    Regards,

    John

    Add comment
    10|10000 characters needed characters exceeded

  • Nov 09, 2017 at 09:05 AM

    Hey John,

    you have no idea how happy I am that somebody finally answers one of my threads and is in a similar situation like me.

    We currently have around 40+ Services (also see this thread for more of my "pain") and in our current "old" 7.31-based world, we also use HRESS_MENU heavily --> concerning this, I haven't found any similar coding-based "injection-point" for dynamic manipulation of the navigation output for the FLP/FFP, which is a bummer, because the consequence of that is, that I am currently going "one step back" from elegant coding based dynamic navigation building, to mapping Portal Roles to R/3-Roles in the Portal's Identity Management. Kind of "ye good olde Homepage Framework(if you remember that)". This is, thank god, working consistenly for us because I have forced (organizationally in our company) the visibility of content to be "expressed" by the assignment of R/3-Roles. If you are, on the other hand, using the "full power" of HRESS_MENU and manipulate the navigation due to, let's say, certain Infotypes a user has, then you are most likely screwed.

    Cheers, Lukas

    P.S. Invoking the newfound power of mentioning people on the 1DX-platform, maybe Simon Kemp has an idea, seeing that he has been confronted with the problem in the past.

    Add comment
    10|10000 characters needed characters exceeded

    • Hi Simon,

      thanks a lot for your answer!

      On the contrary, your feedback is extremely invaluable, because it shows that I'm not "too stupid" to get things working and the problem really is a problem and not an understanding issue on my side.

      No, I haven't raised a Customer Incident yet; this thread on SCN is my second step of information retrieval after failing to find a concrete source of documentation (except for your thread in 2016). I'll subsequently ask around on the DSAG-Network and my business contacts. If that fails as well, I'll ask our key accountant for a feedback from the SAP developers and if that fails as well, I'll raise an incident as a last resort.

      Cheers, Lukas

  • Nov 10, 2017 at 01:37 AM

    G'day Lukas,

    Yes, I do remember the old Homepage Framework. And EP5.0 before that. And Workplace 2.11 with 4.6c before that. And the 4.6b ITS..... :)

    We had built a nice little Z config table to drive the dynamic stuff in the WDA launchpad, so the application alias could be pointed to a role for the simple stuff or a function module at worst. So sadly we are most likely as you say "screwed" on that front.

    I've been meaning to set up a couple of test roles on the portal side and seeing how well/if they merge at runtime in the FFP. I've got a suite of reporting roles currently that extensively use the role merge functionality in the AFP, so if the FFP works the same way there may be a glimmer of home. Creating a role for each transaction to be dynamically assigned is going to be a complete PITA though....

    Just out of curiosity - are you using a web dispatcher to get around the clickjacking protection issue? I have tried setting up the whitelist stuff in the portal and FES but that didn't work for whatever reason, so we are back to using the WD. We use it for load balancing across the portal app servers anyway, so it's no big deal.

    Your other thread on the limit on the number of tiles is a worry, although we are just in the process of installing SPS9 so I'm (optimistically) hoping that may have been solved.

    Cheers,

    John

    Add comment
    10|10000 characters needed characters exceeded

  • Nov 10, 2017 at 02:36 PM

    Hi John,

    as far as I've tested for now, Portal Roles are automatically merged in the FFP; I didn't even need a merge ID or anything.

    We're using a reverse proxy to bypass the same-origin-policy-problem but not the dogmatic Web-Dispatcher from SAP (technically there's no difference, though). I haven't set up any whitelist stuff, neither on portal nor on Gateway(FES)-side. However, I had to maintain a whitelist entry in table HTTP_WHITELIST for the FLP on our Backend-System which, as a side effect, caused dozens of side problems and I ended up with about 50 necessary whitelist entries which is a PITA but oh well. As far as I understand it, though, this has nothing to do with the necessity of a reverse proxy (I assume you always need one if there's cross-site scripting, but then I could be wrong, I'm no basis admin :-)).

    At the moment, we're still on SP8. Yeah, let's hope the 30-Tile-Thing is only a bug and already fixed. I will find out very soon.

    Cheers, Lukas

    Add comment
    10|10000 characters needed characters exceeded

  • Nov 12, 2017 at 11:41 PM

    Hi Lukas,

    I figured role merge would work with the FFP, but I like to have a bit more control over how things merge, especially with lots of content.

    Regarding the Web Dispatcher, we will continue to use that for load balancing and as a reverse proxy, but I was hoping to simplify the configuration by removing the cross site scripting protection stuff. According to note 2410897 it should be possible to do that by whitelist configuration, but we haven't been able to make it work. Maybe I misunderstood the intention behind that note, or maybe it just didn't work on the release we were on at the time. I'll give it another go when we get to 7.50 SPS9 on the portal side.

    On a slightly different topic I see Fiori FES 4.0 has been released, just as we have upgraded all our systems to 3.0. I'm yet to see if there is any advantage to us implementing it, given that it seems to mainly refer to S/4HANA and we are still on Business Suite. It also takes the FES UI library up to 1.48 and there's no sign of an equivalent version for the portal UI library, so that's probably just asking for trouble....

    Hope you have a productive week :)

    Cheers,

    John

    Add comment
    10|10000 characters needed characters exceeded