Skip to Content
Author's profile photo Brian McKellar

BSP In-Depth: Fully Qualified Domain Names

Every once in a while, this error message comes back to haunt us:


In synchronized translation: “BSP Exception: The URL does not contain a full domain specification (ls0028 instead of”

Lovingly, this is referred to as the “Fully Qualified Domain Name” problem. FQDN requires that the hostname must be specified with a complete domain name when addressing the server.

For example:


Usually only the host name in the URL is required for the browser to determine the IP address to use. In the above example, ls0028 can easily be resolved to the correct IP address without the requirement of a domain name. See:


In the first instance, the hostname part of the URL is only for the browser to find a route to the Web server. Once on the Web server, the rest of the path starting at / is used to resolve the specific page to view.

So why would BSP require an FQDN and other services would not?

Motivation for FQDN

The first interesting aspect to understand is that the host name in the URL is effectively a routing string, which tells the browser how to reach the target. A typical situation is that a host might have an intranet name (example that is totally different from the Internet name (example – name changed to protect the innocent:). The name entered in the URL is important for the SAP Web AS, as this tells us the route that was followed to the server.

This host name is always placed into the HTTP header (header field “Host:”). The information is available on the server as to what the browser thinks the correct name is.

There are three big reasons why the browser must access the Web AS with FQDN.

  • Use of HTTPS protocol. The SSL protocol requires that the server and browser names match the names in the certificates (if used).
  • When setting cookies for a specific domain, it’s important to know the domain the browser requires for the cookie, so that the cookie will always be returned to the server. A typical example is the SSO2 cookie used for Single Sign-On over multiple servers.
  • For Java Script calls to work over different frames (from different hosts in the same domain), each frame must relax its document domain. Typically the hostname is stripped, and the domain is set to the FQDN. For this to work, the browser must already know the FQDN for the document that it’s retrieving. This information cannot be set from the server and must be correct from the beginning of the request.

Especially for the domain relaxation aspect, the BSP runtime cannot know beforehand if this will be used for the application. If FQDN is not enforced, it just opens the potential for many other types of more difficult-to-diagnose problems.

ICM Configuration

Usually, FQDN and its use are a browser-related problem. The URL is entered at the browser and should be correct.

However, there are many cases where a URL is created at the server. One typical example is when a BSP application is tested in the SE80. A browser window is opened with the URL to test. In this case of course, the URL must also be a FQDN!

Usually the ICM picks up the correct domain for the server from a Domain Name Server (DNS). However, there are many cases where this does not work accurately. For them, ICM supports a profile parameter icm/host_name_full. We recommend you configure this parameter at all times. This is the hostname that will be used to build fully qualified URLs.

References Configuration. Specifically icm/host_name_full.

For domain settings see OSS/CSN Note

Final War Story

Yesterday, a colleague ran into the office. They had a demo in 30 minutes for customers, and nothing worked. It turns out they had configured their system to use IP addresses inside the URL, and unfortunately this was not detected by our naïve domain detection algorithm. Result: the SSO2 cookie was set for domain “*.21.80.168” and failed to work. We immediately reworked that FQDN check!

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member
      Brian, We have implemented the 1/2004 "Customer SAP BW Web Logon" white paper from SAP in order to allow users to change their passwords (SOX compliance issue). Now we find that all the BW web reports users have bookmarked will be wrong -> we had used our NON-FQDN domain earlier, but the authentication causes those non-FQDN urls to fail. Is there any way we can let users see the old URLs, but keep the newer BSP active? (The BSP in BW 3.0b is under SYSTEM) and is in the SICF under PRIVATE and in PUBLIC alias. Thanks, Doug Grant
      Author's profile photo Former Member
      Former Member
      Hi Brian,

      We've just installed a sandbox Solution Manager 3.1, which is our first opportunity to use BSPs. Unfortunately, we were unable to view Business Process BSPs initially. However I was lucky enough to find your article, which resolved our issue.

      Many thanks,

      Arwel Owen.
      (Liverpool, UK)

      Author's profile photo Former Member
      Former Member
      Hi Arwel,

      Make sure you activate in SICF the "solman", "alertinbox" and "dswp*" BSP's under sap/bc/sap/bsp/  very cool BSP's built for use with the Solution Manager and they are major improvements to the ones that were there in SOL 2.10


      Author's profile photo Former Member
      Former Member
      I am using BSP application and its working fine inside organization. But when I try from outside (internet) using IISProxy (for redirecting to inside server), it is not able to authorize to WAS after asking user name and password 3 times. Any idea?
      Thanks for tips.
      Author's profile photo Brian McKellar
      Brian McKellar
      Blog Post Author
      My first recommendation would be to look into the Wiki area, where we have a complete trouble shooting guide on living with proxies in BSP section. Second recommend to run these types of questions through forum.