Introduction

In general, the creation of the GUI Transaction target in ABAP FioriLaunchpad is more or less straightforward:

• Create a new Target Mapping (FLPD) or Business App (FLPAM)
  • Add Semantic Object + Action to be able to address the target from a Tile or in CrossApp navigation
  • Add App Type Transaction.
  • Add Title, Transaction TCODE, and System Alias (if you are using FLP Hub deployment)
  • Add required and default parameters, with renaming rules to map from intent parameter names to technical GUI batch input names.
• Add new Tile (Static Launcher), pointing to the Semantic Object – Action of the new TM above
  • You do not need a tile if you design the target for App to App navigation only.
• Add Tile and Target Mapping to a Catalog
• Add Catalog to a Role (TR PFCG)
• Add Role to a User (TRs SU01 or PFCG)

And it will work in most cases. But sometimes, when you need to fine granular customize a transaction call (skip selection screen, pass parameters, etc.) you will need more.

The article below describes advanced flags you can apply to GUI transactions when you have problems :).

Works for ABAP FLP and cFLP.

Documentation

Step-by-Step Guide

1. Define new Target Mapping with Application Type Transaction in Fiori Launchpad Designer or FLP App Manager (TR /ui2/flpam):
   1. Fiori Launchpad Designer (FLPD)
      
   2. FLP App Manager (TR /ui2/flpam)
      
2. Semantic Object and Action defines the inbound intent of your target. E.g how you want to call it.
3. The title does not reflect somewhere in UI (FLPD).
4. In the Transaction field fill name of the transaction, you want to call.
5. If your transaction is located not on Front–End server (hub deployment, or remote destination) you need to fill in System Alias (FLPD only).
   1. In FLPAM you need to configure target in the remote backend catalog and then replicate it to the Front-End server
6. Now you can configure the passing of parameters and/or OKCODE:
   1. You can fill in only parameters on the initial transaction screen.
   2. You pass parameters to transactions using their batch input names. To find a batch input name:
      1. Put the cursor on the field you want to fill.
      2. Press F1
      3. On the Performance Assistant screen press the Technical Information button
         
      4. The batch input name can be found in the Screen Field field.
         
      5. Knowing the batch input field would be already enough to pass the parameter to the transaction. E.g such IBN call #Action-startReport?RS38M-PROGRAMM=ZZ_AA_TEST would already prefill the value. But that would not be user-friendly and human-readable and would have too much Dynpro technical specific, but no semantic and abstraction, and this we normally try to avoid in FLP and IBN. The good style would be, that we expand outside parameter in nice, readable form, and rename it into technical batch input name on calling transaction. For this, we use rename to feature of FLP and define input name in Name field and technical name in Target Name column:
         
      6. Now we can call our target like this #Action-startReport?report=ZZ_AA_TEST and get transaction called and field Program pre-filled.
      7. If you want to ensure, that your target will be always called with the program name (this example), you can set the parameter as Mandatory. In this case, the transaction will be executed after this call #Action-startReport?report=ZZ_AA_TEST but not this #Action-startReport. 
      8. You can also pre-fill some default parameters, that shall be passed always to your transaction (can be still be overwritten, when came as part of the call). For this, you define a parameter and configure for it a Default value:
         
      9. In the example above, it will set the Source Code option to be always selected. And in this case, we do not need to rename it, while we do not plan to expose this parameter or use it in an IBN call.
   3. You can also send SET/GET parameters.
      1. If you want to fill the input field, you can use either its batch name (see above) or its SET/GET parameter ID:
         
      2. Most useful SET/GET parameters for cases when you do not have a corresponding field for it on the initial screen. But if it is not bound to any field on the screen, one needs to know the application logic to find the name. Not so easy. You can scan the program for the SET PARAMETER ID command, but still, you need to know which of them if more than one occurrence is found.
      3. When passing SET/GET parameters to target transaction, you need to prefix them with the “@” symbol:
         
   4. Very often, after the pre-filling of parameters, you would like to execute the transaction, using the pre-filled value, and go directly to the second screen. Here is the way to go depending on the Transaction Type.
      1. Dialog Transaction. If you see more than one button on Application Toolbar, it is a Dialog Transaction, with GUI Status and OK CODE processing, and so, you can control it by passing the needed OK CODE as a parameter.
         1. For this, you need to use the predefined Dynpro parameter DYNP_OKCODE:
            
         2. To find the OKCODE, you can also use Technical Information Screen, and navigate from it to Program Status, by double-clicking on its name:
            
         3. In the Manu Painter, you will find a function code corresponding to the button you want to press.
            
         4. Be aware, that while FLP does not know the type of transaction, it always adds a skip selection screen indicator (“*” symbol in front of transaction name) to transaction call if any parameter passed. For dialog transaction, it would result in an empty OK code coming to PAI after the transaction start, which still can result in skipping of selection screen if application logic has such processing for empty OK codes. Details.
      2. Report (Selection Screen) Transaction. If you see only one button Continue or Execute on the toolbar, it is most probably a Section Screen transaction:
         1. Something like this
            
         2. And here you do not have too much freedom. If you pass ANY parameter, FLP will trigger the skip selection screen command and you get the initial screen executed. It is not possible to pass any specific OKCODE, and it is not possible to just pre-fill parameters and stay on the screen. Some more information about it can be found here.
         3. By default, the processing logic for Report transactions will always skip the initial selection screen as far as you pass any parameter (even if it is defined as the default parameter in TM configuration). To avoid that you can use new controlling flags/parameters:
            • DYNP_SKIP_SEL_SCREEN=0 → disable default logic and stay on the selection screen with pre-filled parameters
            • DYNP_SKIP_SEL_SCREEN=1 → default, skip selection screen as far as any parameter passed.
   5. DYNP_NO1ST. This parameter prevents back navigation to the initial application screen (e.g jump over). Make sense only if the initial application screen was prefilled and skipped by start.
      • Example: *VA03 VBAK-VBELN=60052798;DYNP_NO1ST=1;DYNP_OKCODE=ENT2.
   6. DYNP_NOSETGET (>2105). If you combine skipping of the initial screen feature and automatic loading of SET/GETs (always happening), it leads to the issue, that already typed values from previous ABAP sessions for the current user become invisible mixed-in into input parameters of the skipped screen, influencing processing logic. This effect is not obvious for the end-user and may lead to complaints. To prevent Dynpro from the loading of SET/GET you can pass parameter DYNP_NOSETGET with value 1.

SET/GET parameters from another WebGUI sessions are not reused

While by nature WebGUI transactions are running in single external sessions and do not allow to create of new internal modes, per default SET/GET parameters from another WebGUI window are not reused in the next window, as it normally happens in WebGUI (e.g fields have not defaulted with previously entered values). From S/4 HC 1806, this gap between different GUI types was closed, and from now on, per default WebGUI also supports persisted SET/GET parameters and can share already typed values between sessions. But this behavior is controllable by the system profile parameter, and it may happen that in your system this parameter is switched off. So, if it does not work, please check that the system profile parameter dynp/shm_setget is set to true on your system for the default profile.

I want that navigation from a Tile to behave differently compared to Cross-App Navigation

To achieve that just add additional URL parameters controlling the behavior to the Tile definition. For example, you can add the parameter DYNP_SKIP_SEL_SCREEN=0 to a tile, that selection screen of the transaction would not be skipped when you navigate to it by clicking on the tile, but would be skipped if you navigate to the transaction from another app, pre-filling selection parameters.