Sap Redirect Url Is Null

admin



Skip to end of metadataGo to start of metadata

Purpose

This topic describes how to change the default portal URL to give users a more user friendly URL, e.g. to change from 'http://hostname.domain.com:50000/irj/portal' to 'http://hostname.company.com'.

Overview

On your authentication server there is a so-called 'client profile' which has a redirect URL field, and that field can contain anything, but whatever the field contains it needs to be identical to whatever you put in the Oauth2.0 token request screen of Soap-UI.

To change the URL which users employ to access the portal, there are in general 3 approaches, which are discussed in turn below.

  1. Httprequest.urlreferrer:Gets information about the URL of the client's previous request that linked to the current URL. Which means this urlreferrer is collected from the client side browser, so, if you use response.redirect there will be an entry at your browser and the urlreferrer won't be null.
  2. Demonstrate how the redirect can be used in the Web Dispatcher. This page will show 2 examples of how to configure the Web Dispatcher to redirect URL '/' to a custom start URL. The Web Dispatcher used in this example is connected to a Solution Manager and Netweaver systems, respectively.
  1. Change the instance configuration - for single-instance installations
  2. Use a load balancer - for clustered installations
  3. Use a reverse-proxy

1. Change the instance configuration

1.1 Remove the Port from the URL:

For Enterprise Portal 7.0X: Update the AS Java Configuration

  1. Open the Web AS Java Visual Administrator
  2. Goto -> Cluster -> Dispatcher -> Services -> HTTP Provider
  3. Choose Ports
  4. Change the port number to 80 for HTTP and 443 for HTTPS (SSL) - as these are the default ports for these protocols, they don't need to be explicitly entered in the URL used to call the portal
  5. Choose Update and save.

For Enterprise Portal 7.3X: Update the ICM Configuration

  1. As 7.3 uses the ICM instead of the Java Dispatcher for accepting incoming HTTP requests, the port configuration now takes place in the instance profile via parameter icm/server_port_0
  2. For example, to set the HTTP port to the HTTP default port 80 and the HTTPS port to the SSL default port 443 (so that the ports do not need to be explicitly stated in the URL), you would adjust the instance profile as follows:
    # Definition of the ports
    icm/server_port_0 = PROT=HTTP, PORT=80
    icm/server_port_1 = PROT=HTTPS, PORT=443

Note: On UNIX systems, you need root access to bind to ports less than 1024 - but you don't want to start your Application Server with the root user. You can achieve this by using the external program icmbnd, and updating the instance profile as follows:
# Use default ports
# icmbnd needs root permissions
# 'chown root icmbnd' and 'chmod 4755 icmbnd'
icm/server_port_0 = PROT=HTTP, PORT=80, EXTBIND=1
icm/server_port_1 = PROT=HTTPS, PORT=443, EXTBIND=1
exe/icmbnd = <path of executable>

1.2 Remove the irj/portal:

For Enterprise Portal 7.0X:

  1. Goto Cluster-> Server-> Services-> HTTP provider
  2. Enter /irj/portal in the start page text field
  3. Choose the save properties button
  4. Restart the instance.

For Enterprise Portal 7.3X:

  1. In 7.3x, this is done via the NetWeaver Administrator: 'http://<host>:<port>/nwa'
  2. Follow menu path: Configuration > Connectivity > HTTP Provider Configuration
  3. Enter /irj/portal in the default start page property
  4. Click save

Sap Redirect Url Is Null Error

Alternate approach for Enterprise Portal 7.3X:

  1. You could also achieve this at the ICM level using a redirect rule like the following:
    icm/HTTP/redirect_0 = PREFIX=/,TO=/irj/portal,HOST=hostname.company.com
Null

Note: Both of these approaches will result in a redirect response being issued to the browser, redirecting from 'http://hostname.company.com' to 'http://hostname.company.com/irj/portal', so users will still see /irj/portal in the adress bar - it just won't appear in the link provided to the users. If you want to avoid that it appears in the address bar, consider using a reverse proxy instead.

2. Use a Load Balancer

The above configurations take effect at the instance level. If you use a cluster, you need to use a load balancer in front of the portal, and you should perform any configuration on this component instead. You can use many types of software or hardware load balancer with the portal, the most common is probably the SAP Web Dispatcher, so the below example is for the Web Dispatcher. Configuration of the Web Dispatcher is similar to configuration of the ICM for the instance (since they are based on the same technology). So, to have the web dispatcher listen for HTTP requests on port 80, and redirect requests with no path to /irj/portal, you would use the following configuration:
icm/server_port_0 = PROT=HTTP,PORT=80,HOST=hostname.company.com
icm/HTTP/redirect_0 = PREFIX=/,TO=/irj/portal,HOST=hostname.company.com
Note: The comments above about using icmbnd for ports less than 1024 on UNIX systems still apply. It's also worth noting that you could use a Web Dispatcher even for a singe-instance system for exactly this use case: if you want to accept requests on port 80 on UNIX systems.

3. Use a Reverse Proxy

You can use a fully featured reverse proxy in addition to a load balancer, or the reverse proxy can also perform load balancing functions. There are several software solutions that can act as a reverse proxy. The most often used software is probably Apache. The general solution looks like this:
Browser <-> Reverse Proxy <-> Portal
The user connects to the URL 'http://reverseproxy.company.com', whereas the Reverse Proxy connects to the portal with 'http://hostname.company.com:50000/irj/portal'. This access is transparent for the user. If your reverse proxy is configured to perform URL rewriting, then the /irj/portal path can also remain invisible to the end user.

Related Documents

SAP Help (Web Dispatcher):
SAP Help (Sample Profiles for the ICM on 7.30):

Redirect Url In Html

Blogs:

HTTP redirects are an everyday thing when it comes to visiting websites, mostly used in the form of URL redirections. Although HTTP redirects in API consumption are not as massive, they are still frequent. In this blog we will review, redirections in sender and receiver scenarios.

A little background

HTTP redirections are used for different purposes: to load balancing, to maintain backward compatibility, whilst a maintenance work is being done, etc. To a request, the server will respond with a 3XX HTTP code accompanied by a “Location” header, which is the new URL to be accessed.

There is a large list of precautions before following redirections: validation of cyclical calls, redirections to unencrypted sites, malicious redirections, method used, and so on. Due to these caveats, it is not surprising that CPI by default does not follow the redirects and instead, throws an exception (in fact, there is a escalation event, that allows you to classify this error for a consumer of alerts). Then, what if you -need- to follow a redirection? (side-note: as CPI is constantly evolving, this could be enabled directly by SAP in a future release)

Url

1.- Following a redirection

In apache Camel, is not difficult to include and configure a clientConfig option for the AHC component. This configuration, will allow us to enable the redirections. However, I must confess that I couldn’t manage to configure this in CPI, as the communication channels temporarily overwrite the “CamelHttpQuery” header prior to a request execution. (If you have an idea, leave it in the comment section!)

Is there any workaround? Yes. For instance, it is possible to write a groovy script and handle the redirections there. The following script should follow a redirection. Please, consider this a simple/reference snippet as you should include the considerations given by the HTTP standard. Also, the used class (HttpURLConnection) also has features to deal with redirections.

In my proof of concept, I’m using this script during the exception raised by CPI.

Original exception:

iFlow with the exception subprocess, using the script:

For my own testings, I’ve created a quick-n-dirty redirector app in NodeJs, you can download it from the following GitHub repository

Google Redirect Url

2.- Redirecting from CPI

The early days of the then called “HCI” are now behind us… and in their passing, their left us with a naming conventions mess (with a few honorable exceptions and definitely not me!). A use case of HTTP redirections is to use them to correct and normalise endpoints while maintaining compatibility. (Assuming that the clients are able to handle redirections!)

An over simplified redirection implementation, simply requires to return an HTTP code 3XX and the target Location. You can create you own groovy script to analyse things such us the http method, the path, etc. The following iFlows returns the code and location set by a content modifier and as a result, the client is redirected to a different iFlow:

As a result, Postman is being redirected and it consumed both iFlows:

Note the HTTP code: 200, this is the code provided by the second iFlow. On the other hand, by changing the default behaviour of Postman, is possible to ignore redirections. In this case, the second iFlow is not being called:

For more information, have a look into the HTTP standard:

Types Of Url Redirects

And this easy to read documentation: