SMICM — ICM Monitor for HTTP and Web Traffic

SMICM is the administration and monitoring screen for the Internet Communication Manager, the process that terminates and originates HTTP, HTTPS, and SMTP connections for an ABAP application server. The structural fact that explains most confusion: ICM runs as its own operating system process, separate from the dispatcher and work processes. It can be up while the ABAP work processes are stuck, or down while SAPGUI logons via the dispatcher still work fine, because SAPGUI traffic does not go through ICM at all. SMICM lets a Basis consultant see active services and their ports, connection and thread counts, SSL configuration, and trace settings for that process, and restart it independently of the rest of the instance.

Reached for whenever Fiori launchpad, OData services, RFC-over-HTTP destinations, or any inbound/outbound web service call fails with a connection refused, timeout, or SSL handshake error, and the failure looks like a transport-layer problem rather than a service-activation problem. Used before or alongside SICF: SICF answers whether a specific service is active and correctly assigned; SMICM answers whether the underlying HTTP/HTTPS port is even listening and accepting connections. Also used when checking whether a soft restart of ICM is enough to clear a hung connection pool, instead of bouncing the whole instance, and when reviewing SSL certificate or PSE issues that block HTTPS.

SMICM is a runtime monitor, not a Customizing transaction, so there is no application table it writes on save. What it displays comes from three places: the ICM process memory (current services, threads, connection queue), the instance profile parameters that started ICM (ports, thread limits, timeouts), and the dev_icm trace file on the application server's work directory. Configuration of the HTTP services themselves lives in the service activation tree maintained through SICF, and TLS/SSL certificates live in the Secure Storage and PSE files managed through STRUST, not in a table reachable from SMICM.

There is no SE16 table to query for this one; the proof lives in the ICM's own runtime screens and files, not in the database. To confirm a symptom, cross-check the port and status shown under Goto then Services in SMICM against the port the failing client actually connected to, then open the dev_icm trace file for the exact timestamp of the failed request and look for connection refused, SSL, or queue full entries. For persistence beyond the current process instance, check the profile parameters directly in the instance profile or via RZ11 for the icm/server_port and icm/HTTP related keys.

The ICM concept is unchanged on S/4HANA; it remains the process fronting HTTP, HTTPS, and SMTP traffic, and SMICM is the same monitor. It carries more weight on S/4HANA because the Fiori launchpad, OData services, and most UI traffic run over HTTP through ICM rather than through classic SAPGUI, so an ICM outage has a broader visible impact than it did on a mostly GUI-based ECC landscape. Many S/4HANA landscapes also put a separate SAP Web Dispatcher in front of ICM, which is a distinct process monitored separately, not from within SMICM.

This is Basis territory, specifically whoever owns the application server infrastructure and network configuration. A good handover from a functional or ABAP consultant includes the exact failing URL or service, the timestamp of the failure, whether SAPGUI access to the same system works, and any error code returned to the client, so Basis can go straight to the relevant dev_icm entry instead of starting from scratch.

SICF is the natural companion: check service activation there once ICM confirms the port is up and listening. SMGW covers the equivalent monitor for RFC and gateway traffic, useful when the failing connection is RFC-based rather than HTTP-based. SM51 shows whether the ABAP work processes and dispatcher are healthy, which rules in or out a broader instance problem. SM21 and RZ11 are useful next stops for correlating ICM trace entries with system log messages and for checking the exact value of a profile parameter referenced in an ICM trace.