Transaction SICF - ”HTTP Service Hierarchy Maintenance” holds settings on services, independent of the “way to Rome” implemented. Request handlers are set up on the service. Which ever “way to Rome” is chosen, the service is always a part of the plan. A service can be compared to a transaction code (starting point) for Web transactions (called services). Note: if you have no authorisarion for transaction SICF - make sure you get it...
The service holds:
- The Service description (language dependant) and whether it's active or inactive
- Service data (Information about the logon procedure, service options/service parameters, Anonomous logon data, Security requirements, Basic Authentication)
- A handler list (list of Request Handlers, usually only 1)
- Links to error pages (html pages), which will be presented when certain errors occur. E.g. for a Logon Error, a predefined html page can be displayed. It's also possible to use a redirect URL.
When using transaction SICF the full-blown hierarchy of nodes may be a bit daunting... Of course I'm not sure what all nodes are for, but here's some more important areas:
- Internet services:
/sap/bc/gui/sap/its/SERVICENAME/! - BSP:
/sap/bc/bsp/sap/SERVICENAME
A little more techical detail
Settings displayed by transaction SICF can also be found in transparent tables (easy for comparison):
ICFSERVICE |
ICF Service Tree in Internet Communication Framework |
IACS_C |
Parameters for service description (Service options - settings) |
ICFHANDLER |
Description of ICF Service Handler (Handler list) |