Fiori Remote content in Backend catalogs Technical base
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:
For SAP Content replication via Business catalog and transaction /UI2/APPDESC_GET is strongly recommended, which will attempt to replicate all catalogs contained in /UI2/V_ALIASCAT.
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.
An Entry in /UI2/VC_SYSALIAS or /UI2/V_SYSALIAS is required for the following purposes:
a) It is used as valuehelp restrictions in the SUI_TM_MM_APP transaction
b) An entry identifying the system must be present to replicate e.g. a Business Catalog.
For a single system installation, an entry in this table is sufficient, no additional system alias mapping has to be maintained. Then resolution will fallback to use the local system.
Replication has still to be executed even in a single system installation.
For a setup where Frontendserver/Gateway is on a separate system, corresponding aliases pointing towards the Suite /S4 Systems corresponding records in SM59 or /UI2/V_ALIASMAP have to be maintained.
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.
Other helpful resources:
A description on how to create custom content