Skip to end of metadata
Go to start of metadata

The ICF service hierarchy (the tree structure visible in transaction SICF) is built up of a number of DB tables - most importantly the tables ICFSERVICE and ICFSERVLOC. The SICF tree structure is based on the table ICFSERVICE and its fields ICFNODGUID (node ID) and ICFPARGUID (ID of the parent node).

To keep the ICF service hierarchy consistent, all changes to the structure (creation, deletion of service nodes) must be done in the same source system, and then transported to all the other systems of the landscape. The node ID (ICFNODGUID) and parent ID (ICFPARGUID) of an ICF service must be the same accross all systems of a landscape. This can be checked either in the table ICFSERVICE directly, or in the transaction SICF, on the tab Administration.

It is not recommended to transport ICF nodes from a system outside of the landscape, especially if it has a different support package level than the source system of the landscape. Also it is not recommended to create ICF nodes manually in any other system than the source system of the landscape. Such actions will create inconsistencies between the node IDs of the ICF structure - this can lead to missing ICF services, unexpected behavior of ICF services, transaction SICF freezing, etc.

To detect inconsistencies, the report ICFTREE_CONSISTENCY can be used. To fix the inconsistencies, the function module REPAIR_HTTPTREE can be used - this will put any corruped services unser the ICF node "_lost nodes". The services deleted by the function module should be re-transported from the source system.

Related Documents

Missing services in SICF - What to do?

Related SAP Notes/KBAs

SAP Note 411745: Consistency of the ICF tables