Skip to Content
Technical Articles

Sap S/4 Embedded Analytics and Intent based navigation

When approaching an SAP S/4 HANA embedded anlaytics implementation an important concept to address is SAP Fiori Intent based navigation. In the past when implementing an analytic solution using SAP BW queries an RRI interface was used (Using transaction RSBBS). The solution still works in sap business objects analysis for office and in SAP Lumira Designer , however the navigation using RRI is not supporting when using SAP Fiori launchpad in S/4 HANA.

The navigation in the fiori launchpad is done using Intent based navigation.

 

What is intent based navigation?

The intent-based navigation mechanism in Fiori Launchpad allows users to launch applications in different views or modes depending on the runtime parameters. This is achieved by defining application navigation targets using abstract intents, which at runtime are resolved into actual URLs by the Fiori Launchpad target resolution service.

In short it means that every time a navigation between different application is happening, all the calling application has to do is to announce, the intent of this navigation using a Semantic Object and an Action to be performed on that object.

Let’s assume we have a report that shows a list of Purchase order document numbers. When a drill down to the document data needs to be performed, what the calling application needs to do is to announce the intent of Semantic object: Purchase order and the action: displayFactsheet.

What the fiori framework does it detects, based on the user authorizations, what that intent means. The framework checks the user catalog and deducts from there what this actions means for a specific user. In case of  purchase order and displayFactsheet if the user is authorized it would usually display the purchase order data.

 

Filtering the data

However, now that we understood the concept of intent navigation, we need to understand how to filter the data. It is not enough to request to see a purchase order we also need to specify, which Purchase order we want to see. In order to do so a value needs to be passed using the url in case of a Purchase order, the object is PurchaseOrder.  The following value needs to be added to the url:

?PurchaseOrder=<PO_NUMBER>.

This addition is usually not done manually but by the framework itself. As it determines the filters from the source app and passes them to the target app. Note that the framework assumes that the names given to object are the same between source and target application. If the names are different this needs to be defined in the relevant target mapping.

 

Applying This to Analytics

There are various analytical application types from which intent navigation can be called.

  • When applying this to a KPI or Report Designer it can be done via the evaluation. Here is an example of adding 3 intents to a KPI:

 

  • In Design Studio applications the following parameter need to be added in the target mapping of the report:

 

Note that the Design Studio apps do not have an action option. When enabling intent navigation on a Semantic object, all it’s actions are enabled, subject to the user having the appropriate authorizations.

  • In Analytical List Page and Overview Pages an annotation should be added to every field which navigation to be applied to
    <Record Type="UI.DataFieldForIntentBasedNavigation">
        <PropertyValue Property="SemanticObject" String="PurchaseOrder"/>
        <PropertyValue Property="Action" String="displayFactsheet"/>
    </Record>​

It can also be added on the CDS itself:

      @UI.lineItem: [ { 
    type: #FOR_INTENT_BASED_NAVIGATION,
    semanticObjectAction: 'displayFactSheet'                -- Action
  } ]
    @Consumption.semanticObject: 'PurchaseOrder'
   PurchaseOrder

 

 

Limitations of the Intent based navigation in Analytics

  • As oppose to the legacy RRI interface, the Fiori framework navigation supports passing only one value per field therefore passing 2 purchase order numbers, for example is not possible.
  • Another important thing to know about the Design Studio Data Grid, is that it uses the InA interface and not  ODATA. This causes for the field names in the app to be different then the names defined in the CDS (The usually look like 2c<View NAME>). At this point there is only limited support for translating those names to their respective Semantic Objects and only a CDS query is supported and there is no support for BEX query.  There are workarounds for those issues using target mapping and custom app development, which I will discuss in future blogs.

 

 

 

 

Be the first to leave a comment
You must be Logged on to comment or reply to a post.