In newer SAP Fiori ships “legacy App” content ( e.g. WebDynpro, WebGUI transactions ) via so called “Backend Catalogs”. (Typically naming convention *_TC_*_BE_* Technical Catalog BackEnd ).
These are delivered in the backend Suite system.
On the Frontend-server(FES) “dangling references” to these Applications are delivered in Business catalogs *_BC_* , which are only satisfied once the technical catalogs have been *replicated* to the Frontend-server.
(As historically also legacy _TC_ s were part of the Frontend server deployment the introduction of this may surface as “Reference-lost-page X-SAP-UI2-ADCAT “).
This blog explains some of the entities and relations and links to appropriate documentations (for the new model):
Content is created using the mass maintenance tool, a WebDynpro FPM application:
- Start the FPM application SUI_TM_MM_APP from the ABAP Workbench (transaction SE80, package SUI_TM_MM).
here semantic object and signature are associated with a transaction (or WebDynpro Application).
This content is stored in table SUI_TM_MM_APP
note that the mass maintenance tool has the same name.
This content is delivered via software packages in the Backend system ( e.g. the SUITE or ERP system).
The respective transport object is R3TR UIAD, the transport key is seen in the APP_ID column above.
Selection in SE09 using R3TR UIAD <APP_ID>
In addition a record in table(VIEW) /UI2/SYSALIASCAT (/UI2/V_ALIASCAT) is shipped.
Transport object: View Maintenance: Data R3TR VDAT /UI2/V_ALIASCAT (with the key beeing the CATALOG ID).
Selection in SE09 using R3TR VDAT /UI2/V_ALIASCAT
It maps catalognames to an System alias name, e.g. SAP_NW_BE_APPS to the alias NW.
This record must be delivered into the Frontendserver.
Subsequently the sap defined logical destination name (S4, S4CA, …) has to be mapped to an actual
SM59 destination . This has to be done by the customer.
This Destination has to be created as described here and added to
table/view /UI2/V_ALIASMAP and corresponding SM59 destinations have to be created.
(Alternatively one can directly create SM59 destination called NW_RFC, S4CMD_RFC etc.).
This mapping is required to initially replicate the content and repeatedly update changes in the backend system ( e.g. after Installation / patches on the backentsystem) and replicate them to the Fiori Frontend server.
Replication of customer created content (Report /UI2/GET_APP_DESCR_REMOTE_DEV)
Alternatively, single Mass maintenance catalogs ( e.g. catalogs created by a customer for customer transactions) can be replicated, specifying a system destination:
Single catalog extracton works as follows:
Replication of SAP Shipped content (Transaction /UI2/APPDESCR_GET)
Hana content and SAP delivered content should be replicated as described here:
If you want to reuse SAP S/4HANA catalogs, you replicate these catalogs to the frontend system for all system aliases at once.
For more information, see http://help.sap.com/s4hana, select a release and choose .
Note that these technical catalogs are not appearing in the Fiori Launchpad designer prior to replication.
SAP may have shipped business catalogs built on top of these content. For these to operate the content must be replicated. In the frontendserver, SAP ships business catalogs, which refer to such a backend catalog. Here tile references map to application ids. Tiles become only visible, if the replicated catalog content exists.
Please refer to the original documentation for details.
The main purpose of this blog is to pull the pieces together and list some technical information (Tables, Transport objects) etc.
Note that transaction (above) and report (below) take *Different input* as catalog id!
This corresponds to the information below, e.g. for this app:
Note that for SAP Content replication via Business catalog and transaction /UI2/APPDESC_GET is strongly recommended.
By the way:
One can track individual references from a Business Catalog ( here SAP_FIN_BC_GL_FRGTRD_DE_PC) to a technical backend catalog, one can look into /UI2/PB_C_CHIP, selecting e.g. *ADCAT* for ReferenceChip Id.
The fields ID and REFERENCECHIPID contain names concatenated from the keys of the respective entities, note that the application tile keys FA16….53 is identical to the SUI_TM_MM_APP keys displayed above :-).
Note that this table is not a master table, but a cache table rebuild during processing.
it may not be filled in a blank system after setup.
/UI2/V_SYSALIAS is an table used for valuehelp restrictions in the SUI_TM_MM_APP transaction,
it has no other functional significance.
Note: Tables and technical information displayed here are for informational purposes only, never attempt to modify table content directly, bypassing the tools and documentation! Information here is a subset of the full information stored and used in the system and direct table manipulation will lead to inconsistencies.