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.
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.
You need to adjust the following DDIC objects:
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.
You need to maintain settings in the following IMG (SPRO) activities:
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.
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:
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).
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.
For navigation to the parent interface NS_NAV, IFNAME_NAV, IFVER_NAV and PARENT_ID are used same like in the second 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.
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.
For comparison the key field definition of the first tier:
And the key field definition for the third tier:
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.
In the end you should have a result similar to this:
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.
Forward Navigation to the Message Monitoring SAP Fiori App
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
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 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 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 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 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 tier key field definition
For comparison the key field definition of the first tier:
First tier key field definition
And the key field definition for the third tier:
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 parameters second tier PARENT_ID
Navigation parameters second tier IFNAME_NAV_C
In the end you should have a result similar to this:
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
- SAP Managed Tags:
1 Comment
