SAP SOAMANAGER — SOA Management
A web service is just a way for two systems to talk over HTTP by exchanging XML messages. One side publishes a service and describes it in a WSDL file (Web Services Description Language — a machine-readable contract listing the operations and the exact shape of every message). The other side reads that WSDL and calls it. SOAMANAGER is where you do both halves inside SAP.
The single most important thing to understand before you open it is that SAP splits every web service into a design-time part and a configuration part, and SOAMANAGER only does the second. A developer creates a *service definition* (provider) or a *consumer proxy* (consumer) in SE80 or SPROXY. Those objects are transported, but they carry no URL, no user and no password — because those differ in every system in your landscape. SOAMANAGER supplies exactly that missing half: a binding on the provider side, a logical port on the consumer side.
This is also why SOAMANAGER configuration is *not* transported by default and why your interface works in DEV and appears to be missing in QAS. Nothing is broken. The proxy came across; the logical port did not, because a logical port pointing at the DEV endpoint would be wrong in QAS anyway.
SOAMANAGER runs as a Web Dynpro ABAP application in a browser, not as a classic SAP GUI screen. That is the source of a whole class of problems that have nothing to do with web services: if the ICF service tree is not activated, or the message server hostname is not fully qualified, the transaction will not even open.
When you would actually use SOAMANAGER
- Exposing an SAP function module or BAPI so an external system can call it, and getting the WSDL URL to hand over.
- Calling an external web service from ABAP — creating the logical port that tells a consumer proxy which URL, which user and which certificate to use.
- Switching an SAP-delivered standard API on: most inbound services (e.g. the Journal Entry or Business Partner APIs) ship inactive and need a binding before they will answer.
- Changing the authentication on an existing interface — from basic user/password to X.509 client certificate, for example.
- Diagnosing an interface that used to work: reading the error log, turning on a payload trace, and seeing the message SAP actually received rather than the one the partner says they sent.
What the screen looks like
Web service configuration
Transport channel authentication
Transport guarantee
Endpoint
Consumer security
WSDL access settings
The fields, in plain English
SRT_WSPThe provider-side design-time object: the list of operations your system offers and the XML shape of each message. Created in SE80 from a function module, or delivered by SAP. It is transported.
Watch out: A service definition on its own exposes nothing. Until you create a binding in SOAMANAGER there is no URL and no WSDL to hand out.
The provider-side runtime configuration: which authentication a caller must use, whether HTTPS is required, and which SOAP version applies. One service definition can carry several bindings — for example one for an internal caller using assertion tickets and one for an external partner using certificates.
Watch out: Change the service definition and existing bindings can become inconsistent. Re-open and re-save the binding, or SAP will refuse the call with a mismatch error.
CO_* classThe consumer-side design-time object: an ABAP class generated from the partner's WSDL, with a method per operation. Created in SE80 or SPROXY. ABAP developers instantiate it and call methods; they never touch a URL.
Watch out: The proxy is generated from a specific WSDL version. If the partner changes their contract, regenerating the proxy is a development task — no amount of SOAMANAGER configuration will fix a shape mismatch.
The consumer-side runtime configuration bound to a proxy: target URL, port, path, credentials, timeouts, proxy server. This is the object that differs in DEV, QAS and PRD, which is precisely why it is not transported.
Watch out: Tick "Logical Port is Default". ABAP written as CREATE OBJECT lo_proxy TYPE co_service. with no port name uses the default one, and there is no default unless you set it.
When creating a logical port you either point SOAMANAGER at the partner's WSDL URL and let it read the endpoint and security settings out of the contract, or you type them in by hand.
Watch out: WSDL-based is quicker but means your SAP system must be able to reach the partner's WSDL URL at configuration time — often blocked by a firewall that permits only the runtime endpoint. Manual configuration exists for exactly that case.
Whether the channel itself must be encrypted. "SSL" forces HTTPS; the call is rejected over plain HTTP.
Watch out: Basic authentication over plain HTTP sends the password in a base64 header, which is encoding, not encryption. Setting transport guarantee to SSL is the one-click fix and is worth doing even internally.
Which hostname and port SAP writes into the WSDL files it generates. "Application Server" uses the machine's own name; "SAP Web Dispatcher" uses the reverse-proxy address your partners can actually reach.
Watch out: Left at the default on a system behind a web dispatcher, every WSDL you export names an internal host. The partner's tooling then fails to resolve it and you get told "your WSDL is broken" when the service is fine.
A named bundle of security and protocol settings that can be applied to many services at once, rather than configuring each binding by hand. Worth setting up when you are activating dozens of standard SAP APIs.
Step by step
- 1Before anything else, run report SRT_ADMIN and let it do the technical setup.Run it in each productive client and in client 000. It creates the RFC service destination the SOAP runtime needs and applies the bgRFC (background RFC) settings. On a system where this has never been run, SOAMANAGER screens open but nothing you save ever becomes active — which is a far more confusing failure than an outright error. Then run SRT_ADMIN_CHECK, which inspects the configuration and lists what is still wrong.
- 2Confirm the SOAP runtime background job is scheduled.SM36 → Standard Jobs → Schedule Standard Job → SAP_SOAP_RUNTIME_MANAGEMENT, hourly. This job activates saved configurations and maintains the log and trace data. Without it, bindings and logical ports stay stuck in an unactivated state and the Logs and Traces tab is permanently empty.
- 3Activate the ICF services in SICF.SOAMANAGER is a Web Dynpro application and the SOAP runtime is served over HTTP, so the ICF tree must be live. Activate /default_host/sap/bc/webdynpro/sap/appl_soap_management and the whole /default_host/sap/bc/srt subtree (right-click → Activate Service, and choose to include the subtree). A dead ICF node is what produces a blank page or a bare HTTP 403 instead of SOAMANAGER.
- 4Set the WSDL access hostname once, in Technical Administration → System Global Settings.Choose SAP Web Dispatcher and enter the externally resolvable host and port if you have one; otherwise Application Server with a fully qualified name. Check profile parameter icm/host_name_full is set to an FQDN — SAP writes the short hostname into URLs when it is not.
- 5PROVIDER — search for your service definition and create a binding.Service Administration → Web Service Configuration → search by Internal Name for the service definition (SE80-created ones usually start Z or Y; SAP-delivered ones do not). Open it, choose Create Service, and give both the service and the binding a name. On the Provider Security tab pick the authentication a caller must present and set Transport Guarantee to SSL. Save.
- 6PROVIDER — generate and hand over the WSDL.On the saved binding, open the WSDL generation option and copy the "WSDL 1.1 through SAP Web Dispatcher" URL if you have one. Open that URL in a browser yourself before sending it: if you cannot fetch it from outside SAP, neither can your partner. The WSDL is the whole contract — endpoint, operations and message shapes.
- 7PROVIDER, shortcut — for standard SAP APIs use Simplified Web Service Configuration.Service Administration → Simplified Web Service Configuration, type the service definition name in the search pattern, tick "User Name/Password (Basic)" against it and save. That is the whole job for an inbound standard API such as the Journal Entry or Business Partner service, and it avoids the full binding screens entirely.
- 8CONSUMER — have the proxy generated first, in SE80 or SPROXY.From the partner's WSDL, create an Enterprise Service → Service Consumer, supply a package and a prefix, and activate. This produces the CO_* proxy class. Nothing in SOAMANAGER can proceed until this object exists and is active.
- 9CONSUMER — create the logical port.Service Administration → Web Service Configuration → switch the search to Consumer Proxy, find your CO_* class, open it and choose Create Logical Port. Name it, TICK "Logical Port is Default", then choose WSDL-based (paste the WSDL URL plus a user that may read it) or Manual Configuration (type protocol, host, port and access path yourself).
- 10CONSUMER — fill in Consumer Security and Transport Settings.Consumer Security is the credential SAP presents to the partner: user and password for basic, or a client certificate for X.509. Transport Settings carries the endpoint and any HTTP proxy your network requires. Set a sensible timeout while you are here — the default will happily hang a dialog process.
- 11For HTTPS endpoints, import the partner's certificate chain in STRUST.STRUST → SSL client (Standard) → import the CA and any intermediate certificates, then restart the ICM (SMICM → Administration → ICM → Exit Soft → Selected Application Server). SAP will not trust a certificate it has no chain for, and it will not re-read the PSE without that restart. This step is skipped constantly and produces an SSL error that looks like a network fault.
- 12Test with Ping Web Service, then with a real payload.The Ping button on the logical port only proves the endpoint answers — it does not validate credentials or message shape. Follow it with a real call: use SE80's proxy test on the consumer side, or SoapUI/Postman against your provider WSDL. Note that the browser-based WS Navigator needs a Java stack and is unavailable on ABAP-only systems, which is why an external SOAP client is the practical choice.
- 13When it fails, go to SRT_UTIL — not back to SOAMANAGER.SRT_UTIL is the troubleshooting transaction: error log, performance monitor and, most usefully, the payload trace. Set a trace for the calling user, reproduce the failure, and read the XML SAP actually received. This is how you settle "we definitely sent it" arguments in one screen. SRT_MONI monitors asynchronous messages.
- 14Repeat the configuration in every system of the landscape.Bindings and logical ports do not travel in a transport. Plan for configuring QAS and PRD by hand — or export a configuration profile — and write the endpoint values down somewhere, because "which URL is PRD pointing at?" becomes an unanswerable question six months later.
Errors you will hit, and what they mean
Service cannot be reached / HTTP 403 Forbidden when starting SOAMANAGER
Why: The ICF node for the Web Dynpro application, or the /sap/bc/srt subtree, is not activated. This is the default state on a freshly installed system.
Fix: SICF → execute → navigate to /default_host/sap/bc/webdynpro/sap/appl_soap_management and activate it, then activate /default_host/sap/bc/srt including its subtree. If the URL still fails, check that an HTTP or HTTPS port is active in SMICM.
SRT: Unsupported xstream found: ("HTTP Code 401 : Unauthorized")
Why: The credentials on the logical port were rejected by the target. Usually a wrong password, an expired one, or a user locked after the interface retried and tripped the lockout.
Fix: Re-enter user and password on the logical port's Consumer Security tab and save. Check the target user is not locked and has not expired. If the target expects a certificate rather than basic auth, change the authentication method rather than the password.
SRT: Unsupported xstream found: ("HTTP Code 404 : Not Found")
Why: The endpoint path in the logical port is wrong — a missing or extra path segment, or a URL copied from documentation for a different release.
Fix: Compare URL Access Path on the Transport Settings tab against the soap:address location element in the partner's WSDL. Paste that URL into a browser to confirm it exists before changing anything in SAP.
Error during proxy processing: No logical port for proxy class CO_… found
Why: A logical port exists but was never marked as the default, and the calling ABAP does not name one explicitly.
Fix: Open the logical port in SOAMANAGER and tick "Logical Port is Default", or have the developer pass the port name in the CREATE OBJECT statement. The first is almost always the right answer.
ICM_HTTP_SSL_ERROR / SSSLERR_PEER_CERT_UNTRUSTED
Why: SAP does not trust the certificate the target presented, because the issuing CA is not in the SSL client PSE — or it was imported but the ICM has not re-read it.
Fix: STRUST → SSL client (Standard) → import the full chain (root and intermediates), then SMICM → Administration → ICM → Exit Soft. Test again only after the ICM has restarted; skipping the restart makes a correct import look like a failure.
ICM_HTTP_CONNECTION_FAILED
Why: Nothing answered at the address. Firewall, wrong port, an outbound HTTP proxy that was not configured, or DNS not resolving the hostname from the SAP server.
Fix: From the SAP host itself, confirm the name resolves and the port is reachable. If your network requires an outbound proxy, enter it in the logical port's Transport Settings, or globally in SICF → Client → Proxy Settings.
Configuration saved but binding stays inactive / "not all changes have been activated"
Why: The SOAP runtime background job is not scheduled, so nothing ever picks up and activates the saved configuration.
Fix: Schedule SAP_SOAP_RUNTIME_MANAGEMENT hourly via SM36 standard jobs, and run report SRT_ADMIN if the technical setup was never performed in this client. Then re-save the binding.
The WSDL URL works internally but the partner cannot reach it
Why: System Global Settings still names the application server, so the generated WSDL carries an internal hostname that does not resolve outside your network.
Fix: Technical Administration → System Global Settings → set access via SAP Web Dispatcher with the externally resolvable host and port, and set profile parameter icm/host_name_full to an FQDN. Regenerate the WSDL — the old file the partner holds still has the wrong address in it.
CX_ST_MATCH_ELEMENT — deserialization error / unexpected element
Why: The XML received does not match the shape the proxy or service definition expects. Almost always the contract changed on one side, or a namespace differs.
Fix: Not a configuration problem — no SOAMANAGER setting will resolve it. Capture the actual payload with the SRT_UTIL trace, compare it to the current WSDL, and regenerate the consumer proxy against the partner's new WSDL.
Binding is inconsistent with the service definition
Why: The service definition was changed and re-activated in SE80 after the binding was created.
Fix: Open the binding in SOAMANAGER and save it again to rebuild it against the current definition. Where a transport carried a changed definition into QAS or PRD, the same re-save is needed in each system.
Common questions
Why does my interface work in DEV but not in QAS?
Because bindings and logical ports are configuration, not development objects, and they are not included in a transport. The consumer proxy and service definition travelled; the endpoint, user and password did not. Configure SOAMANAGER separately in every system — and note that this is deliberate, since a logical port carrying the DEV endpoint would be actively wrong in QAS.
What is the difference between Simplified and full Web Service Configuration?
Simplified is a single screen where you tick an authentication method against a service definition and save; it covers activating standard SAP inbound APIs with basic authentication, which is most of what people need. The full configuration exposes every binding option — message-level security, reliable messaging, per-operation settings — and is what you need for anything beyond user and password.
SOAMANAGER or Communication Arrangements?
On SAP ERP and S/4HANA on-premise, SOAMANAGER is still the tool for SOAP web services. S/4HANA Cloud replaces it with Communication Management — Communication Users, Communication Systems and Communication Arrangements — because there is no direct system access. If you are following a tutorial that talks about arrangements and your system only has SOAMANAGER, you are reading cloud documentation for an on-premise system.
Do I have to use SOAMANAGER, or can I just call the service from ABAP?
You can build an HTTP call by hand with cl_http_client and an SM59 HTTP destination, and for a simple REST/JSON endpoint that is often the pragmatic choice. SOAMANAGER earns its keep for SOAP: it handles WS-Security, reliable messaging, message monitoring and certificate handling that you would otherwise write and maintain yourself.
Where do I actually see what went over the wire?
SRT_UTIL. Set a payload trace against the user or the interface, reproduce the call, and read the stored request and response XML. SRT_MONI covers asynchronous message monitoring. The Logs and Traces tab inside SOAMANAGER shows the same data, but SRT_UTIL is faster to work in and is where most consultants live during a go-live.
Can I test without an external tool?
On the consumer side yes — SE80 can execute a proxy method with test data. On the provider side the built-in WS Navigator needs a Java stack, so on an ABAP-only system you will want SoapUI or Postman pointed at your WSDL. Testing the provider with a real external client is worth doing regardless, because it exercises the network path your partner will use rather than a loopback.
Is basic authentication acceptable?
Only with Transport Guarantee set to SSL. Basic auth sends the credential base64-encoded, which is encoding rather than encryption — over plain HTTP it is readable by anything on the path. With HTTPS enforced it is a reasonable choice for system-to-system integration, and it is far easier to operate than certificate authentication. Use a dedicated technical user of type Communications Data, never a named person's account.
Nothing I save becomes active. What is wrong?
Two candidates, in this order. First, report SRT_ADMIN was never run in this client, so the SOAP runtime has no service destination or bgRFC settings. Second, job SAP_SOAP_RUNTIME_MANAGEMENT is not scheduled, so there is nothing to pick up and activate what you saved. Run SRT_ADMIN_CHECK — it reports both.
Transactions that go with SOAMANAGER
Reading about it only gets you so far
Practise SAP transactions in a safe simulated environment and keep what you learn.
Practise SAP transactions hands-on
Interactive modules, games, and an AI tutor — free to start.
Get started free →