This Blog is the 3rd case I publish in the context of my support blog – a continuance blog in which I publish Portal support
cases which customer may encounter.
This interesting case demonstrates the importance of navigating in the Portal by using the navigation APIs and not the direct URL to the Portal content.
The customer in this story had an issue with a page that was being triggered from an application (UWL application) and was expected to open in a new headerless page. Instead, it opened in a full L-Shape Portal framework page.
In mobile, on the other hand, when running the same application, it’s working as expected – the new page opened in headerless window when opening a new task. Bear in mind that the mobile application uses a different framework page (mobile framework page).
Why does this happen?
Here are a few more details:
The customer has a custom launcher page with a button that launches the mobile UWL application using a URL such as this*:
(*I anonymized the URL. But you get the idea.)
Can you see what is wrong with this URL?
As I cannot use screen shots from the customer’s system – I simulated this type of scenario on a local computer.
Let’s assume that the page shown below is the launcher.
Both the links are targeting the same iView. The first (“Good Navigation”) does it correctly, and the second (“Bad Navigation”) does it incorrectly.
Figure 1: The simulated launchpad
In the customer’s system it would open the UWL navigation. In my simulation it opens a very basic iView which contains a link to another iView in a new window (as if the UWL is opening a task in a new window).
Look at the result from the “Bad Navigation” below.
Do you see what’s wrong here?
Hint 1: Look at the screen shot below which shows the navigation result.
Hint 2: It is running on a desktop framework page.
Figure 2: "Bad Navigation"
So the problem here is that the portal framework has disappeared – note that there is no TLN or DTN – only the application has been triggered.
The link on this page that opened is navigating to another iView in new headerless window.
But surprise! The new iView has opened in a full Portal framework page as shown below:
Figure 3: "Bad Navigation" result - the content is presented in Portal default framework
Now wait! It gets even more complicated: when running that same URL from the mobile framework page – the page opens correctly in a headerless framework page.
So what is going on here?
As I already mentioned above – the problem is related to the navigation URL. The customer has customized his or her launchpad to navigate directly to the content, instead of navigating to it via the navigation APIs.
So the correct way to navigate to the UWL application in that case would be:
http://myportal:50000/irj/portal?NavigationTarget=ROLES:// aportal_content/Folder1/Folder2/MyWorksets/MyRole/UWL_MOBILE& username_field=auser&password_field=apasswork&login_submit=on&login_do_redirect=1&ganame=MY_TASKS
You can see that the navigation is done by using the NavigationTarget parameter followed by the target content.
So when clicking the “Good Navigation” and navigating correctly by navigating in the Portal – the iView (simulation of the UWL application) opens inside the Portal frame – with the TLN and DTN (and all the other iViews of the frame of course):
Figure 4: "Good Navigation"
And then opening a new headerless window (in the UWL it is New Task) the Portal understands “headerless window” and opens the new page as expected in a new headerless window.
Figure 5: "Good Navigation" result - the content is displayed in headerless window as expected
When you navigate directly to the content, not all the JavaScript frameworkpages are loaded and subscribed. So when a new navigation from that content is performed – there is no JavaScript to process it and understand “open me in a headerless page”. The Portal performs this navigation in the default framework page of the Portal – which for desktop is the framework with the L-Shape (TLN and DTN).
Now why does this work correctly in mobile?
In mobile, the default framework is headerless – so the fallback of the Portal when it doesn’t have the JavaScript to “translate” the opening mode – is to open the page in the headerless window. Luckily, in the mobile case it seems to operate correctly, but it is based on an incorrect navigation just like in the desktop framework case.
So to summarize the conclusions from this case: when you want to navigate in the Portal DON’T navigate to the content directly and DO use the NavigationTarget parameter.
- SAP Managed Tags:
