EDUCAÇÃO E TECNOLOGIA

Navigation for interfaces in the Message Monitor of SAP Application Interface Framework

You have several interfaces that are related and you want to navigate among them? If you follow this example for a three-tier interface hierarchy, you should find the required guidance.

Preconditions

You already have interfaces that are related in any kind.

You should check that your configuration is working before doing any change.

As it is often missing I recommend to check if your recipient assignment is set and working correctly.

For the sample we will use a three-tier interface hierarchy. The sample will show the setup so navigation will be possible between the first and second tier and between the second and third tier. There will be no navigation from first to third tier.

You need to know the values for semantic object and action of your target application. In this sample it is a navigation from and to the Message Monitoring app and so the semantic object is “AIFMessage” and the semantic action is “startMessageMonitoring”. For the Message Monitoring app the values can be found in SAP Fiori Launchpad Application Manager using catalog ID “SAP_BASIS_TCR_T”. Otherwise you can find the values using the SAP Fiori App Reference Library – you have to lookup the values in the target mapping of the section configuration at the implementation information for you desired app.

New navigation features in ABAP Platform 2108 (AS ABAP 7.85) / SAP S/4 HANA Cloud 2108  are required.

DDIC changes

You need to adjust the following DDIC objects:

  • Interface (target) structure for each interface
  • Index table
  • Data elements for key fields you want to display and use for navigation

The interface target structure has to hold the values that are used for navigation.

These are the namespace, the interface name and the version of the target interface at least.

In case you want to navigate to a certain message, you require the message id (GUID) as well.

For a parent-to-child navigation you can´t navigate to a single message, but you can restrict the displayed messages with other criteria inherited by the parent message (e.g. parent message id). This can be done using a preset filter value, but is then also required in the structure.

All navigation-related fields must be defined as key fields and must be available in the index table as well.

Customizing changes

You need to maintain settings in the following IMG (SPRO) activities:

  • Error Handling >> Define Namespace-Specific Features
  • Error Handling >> Define Interface-Specific Features

For the namespace-specific features you have to maintain the index table for your interface. The index table is required to use key fields and key fields are required for the key field navigation.

For the interface-specific features you have to maintain the key fields. You need to have one key field for every field that shall be used for navigation – the values in the message table will be displayed as hyperlinks. In addition you need a key field for each field that has to be passed (and mapped) to an app parameter. These key fields do not need to be displayed in the app.

For the key fields you have chosen as navigation fields you need to supply the parameters. In fact it is a mapping of the key fields sequence number and the parameters that can be passed to the app. For the Message Monitoring app you can supply namespace (NS), interface name (IFNAME), interface version (IFVER) and message id (MSGGUID).

Another parameter can be used to control whether to navigate directly to the details view: NAVTO_DETAIL. Of course this make only  sense in case a message id is supplied. The parameter value is true (X) by default and has to be supplied empty in case navigation to detail shall be prevented.

For fine controlling the displayed messages in an interface you can supply any parameter to the Message Monitoring app which you defined as key field. The value will be initially set as filter value in order to narrow down the displayed messages to the desired selection.

Example

As mentioned we use a three-tier hierarchy for the example. So we have three structures that are related. The following figure shows only the relevant fields for the navigation:

InterfaceHierarchyNavFields

InterfaceHierarchyNavFields

For navigation NS_NAV, IFNAME_NAV and IFVER_NAV are used to define the target interface. The value of MSGGUID_NAV is passed as PARENT_ID, which will be set as filter when displaying the second tier interface data. This way only messages are displayed which belong to the same message in the first interface. PARENT_ID is a custom key field and it´s dynamically recognized by the Message Monitoring app as a startup parameter (initial filter value).

First%20tier%20structure

First tier structure

For navigation to the parent interface NS_NAV, IFNAME_NAV, IFVER_NAV and PARENT_ID are used.  The values MSGGUID_NAV_C, NS_NAV_C, IFNAME_NAV_C and IFVER_NAV_C are used for navigation to the child interface (third tier). Only the second tier has navigation in two directions.

Second%20tier%20structure

Second tier structure

For navigation to the parent interface NS_NAV, IFNAME_NAV, IFVER_NAV and PARENT_ID are used same like in the second tier structure.

Third%20tier%20structure

Third tier structure

For all the sample interfaces the same index table is used. This way the table must contain all the navigation related fields from all three structures.

Index%20table

Index table

The key field definition must include all fields that are required for navigation. In the sample the second tier has two navigation fields (which can be clicked on to navigate). In addition there are 6 fields for the navigation context (3 for each navigation field) holding the additional values that have to be passed to the target app.

Second%20tier%20key%20field%20definition

Second tier key field definition

For comparison the key field definition of the first tier:

First%20tier%20key%20field%20definition

First tier key field definition

And the key field definition for the third tier:

Third%20tier%20key%20field%20definition

Third tier key field definition

At last the defined key fields have to be assigned to the app parameters. This is required for each navigation field. So for the second tier you have to do it for field PARENT_ID and IFNAME_NAV_C. For the first and third tier there is only one navigation field, so you have to do it only once for each of them.

Navigation%20parameters%20second%20tier%20PARENT_ID

Navigation parameters second tier PARENT_ID

Navigation%20parameters%20second%20tier%20IFNAME_NAV_C

Navigation parameters second tier IFNAME_NAV_C

In the end you should have a result similar to this:

Message%20monitor%20with%20navigation%20fields

Message monitor with navigation fields

Summary

With this blog post you got a specific instruction on how to enable navigation for depended interfaces using SAP Application Interface Framework.

More general information, other blog posts and SAP Help Portal landing page can be found on the SAP Community topic page for SAP Application Interface Framework.

Related topic:

Forward Navigation to the Message Monitoring SAP Fiori App