Skip to Content
Technical Articles

Implementing SAP Marketing Forms using the SAP Web Dispatcher


Modern web browsers introduced new security measures to improve the secure handling of cookies, e.g. SameSite cookies or cross-site tracking prevention.

These measures may deny cookies for cross-domain requests. However, the following setup makes use of cross-domain requests and cookies to keep a session alive. This doesn’t work anymore with these modern web browsers.

Please see the following blog post for more details regarding the SameSite cookies and options to configure your SAP Web Dispatcher accordingly:

Alternatively, you can implement the same setup using a reverse proxy on your own web server instead of the SAP Web Dispatcher so that the communication is not cross-domain. This reverse proxy configuration could either just point to the web dispatcher which is configured as below or replace its configuration by applying the same settings as part of the proxy so that you don’t have to configure the web dispatcher at all.


SAP Marketing offers an easy to use editor to design and configure web forms. These forms are hosted on the customer web server to allow custom integrations into existing web sites and technologies.

The forms provide built-in functionality to send and receive the required data to and from the SAP Marketing system. To make this scenario work, you have to integrate the form on the web server with the SAP system.

While the SAP Marketing Installation Guide covers an example implementation using a PHP snippet, it’s also possible to configure the SAP Web Dispatcher in a way that allows easy integration without additional implementation effort. This guide describes the required steps.

You need to have basic knowledge about the SAP Web Dispatcher and its configuration to follow this guide. Furthermore you need to have access to the SAP Web Dispatcher directory and the profile file in order to perform the necessary changes.

Intended System Setup

The form itself has to be hosted using a customer web server and runs inside the user’s web browser client. The SAP Web Dispatcher acts as an interface (proxy) to access the SAP Marketing server.

The intended setup consists of a direct communication between the form and the SAP Web Dispatcher without any additional implementation to connect the two components. To make this communication possible, the Web Dispatcher needs to be configured to allow the anonymous HTTPS requests from the customer web server domain on which the form (HTML, CSS and JS files) is hosted.

The cookies sent by the SAP Marketing system are marked as secure which means that the web browser will only handle them if the form is using HTTPS. This means that the web server needs to use HTTPS to use this approach.

The described configuration can be performed once without additional effort for forms created afterwards.

Adding a Modification Handler for the Form Result Service

The SAP Web Dispatcher allows the modification of HTTP requests based on user-defined conditions.

To separate these modifications from the standard configuration you can define a dedicated modification handler file in your SAP Web Dispatcher profile as follows:

# Form Result Service Modification Handler

The above statement uses the profile parameter “icm/HTTP/mod_<xx>” for requests matching the given prefix “/sap/opu/odata/sap/CUAN_CONTENT_PAGE_RESULT_SRV” to define a modification handler file “CUAN_CONTENT_PAGE_RESULT_SRV.txt” inside the profile folder. The name and the location of the handler file can be chosen as desired. If there is already a modification handler in place, you have to increase the profile parameter index (“mod_<xx>”) accordingly.

Following this, you have to create the modification handler file as defined in the profile parameter. Simply create an empty text file that contains the configuration statements described in the following sections.

After setting up the profile parameter and the handler file, you have to restart the SAP Web Dispatcher instance. Afterwards you can check and reload the Modification Handler in the Web Administration Interface.

Preparing the Authentication with a Technical User

The form result OData service requires a backend user with the relevant role. The Installation Guide covers the creation of the user in the section “System User Authentication”.

In order to allow forms to call the service as an anonymous web user, the SAP Web Dispatcher needs to forward the HTTP requests with the proper user authorization. This guide uses Basic HTTP Authentication for this purpose.

Provide the necessary “Authorization” HTTP request header as follows:

# Authorization
SetHeader Authorization "Basic <Base64Encoded-Username:Password>"

You have to maintain the value of the header with a Base64 encoded string of “Username:Password” where “Username” is replaced by the name of the according technical user and “Password” is replaced by the user’s password while keeping the as the separator. You can find several online services by searching for “base 64 encode”.

Assuming the user name “TECHUSER” and the password “Secret123” you would have to encode the text “TECHUSER:Secret123” in Base64. The complete header value would then be “Basic VEVDSFVTRVI6U2VjcmV0MTIz”. The SAP system then uses this “Authorization” header to process the HTTP requests as the given user.

Please note that the Base64 encoding is not an encryption. Anyone with access to the SAP Web Dispatcher is able to read the encoded value and decode it to receive the user name and password combination. Thus it makes sense to create a “System” user that only has the landing page result role assigned in order to prevent abuse of it.

Enabling Cross-Origin-Resource-Sharing

Using the SAP Web Dispatcher directly for the form integration usually implies that the HTTP requests are being sent to a different domain. While the landing page HTML is hosted on the website’s domain, the Web Dispatcher runs on an own domain. This setup requires some additional preparation because modern web browsers implement security mechanism to prevent illegal requests.

The server providing the web service (here: form result OData service) has to set specific HTTP response headers that define from which domains the service can be called. The web browser then checks these header values before sending HTTP requests. This system is called Cross-Origin-Resource-Sharing (CORS). If your setup doesn’t require CORS you can skip this section.

Form requests require the following CORS HTTP headers:

  • “Access-Control-Allow-Origin”
    • Defines the allowed domain from which the service can be called
  • “Access-Control-Allow-Methods”
    • Defines the allowed HTTP methods
  • “Access-Control-Allow-Credentials”
    • Enables the use of cookies which is necessary to satisfy the SAP Gateway OData protocol
  • “Access-Control-Allow-Headers”
    • Defines the list of allowed HTTP headers that can be send via requests
  • “Access-Control-Expose-Headers”
    • Defines the list of allowed HTTP headers that can be read from responses

You can set these HTTP response headers in the modification handler file as follows:

# CORS Enablement
SetResponseHeader Access-Control-Allow-Origin "https://<Form-Domain>/"
SetResponseHeader Access-Control-Allow-Methods "OPTIONS, HEAD, GET, POST"
SetResponseHeader Access-Control-Allow-Credentials "true"
SetResponseHeader Access-Control-Allow-Headers "Content-Type, X-CSRF-Token"
SetResponseHeader Access-Control-Expose-Headers "X-CSRF-Token"

Replace the value of the “Access-Control-Allow-Origin” header with the domain used for your web site hosting the landing page (e.g. “”).

Preparing CORS Preflight Requests

Modern web browsers send additional preflight HTTP OPTIONS requests for CORS requests to check for the required HTTP headers.

At present, the SAP NetWeaver OData Gateway doesn’t support  requests which use the “OPTIONS” method. Because of this it’s necessary to work around the missing functionality of the OData service by re-writing the OPTIONS requests to another path that supports the HTTP method. This approach does not lead to functionality or security limitations.

You can re-write the OPTIONS requests onto the “/sap/public/ping” service by adding the following to your modification handler file:

# OPTIONS Workaround
	RegIRewriteUrl ^(.*)$ /sap/public/ping

Adjusting the JavaScript File

The last step is to maintain the service URL in the form JavaScript file. By default, the file already contains the relative service path as follows: “/sap/opu/odata/sap/CUAN_CONTENT_PAGE_RESULT_SRV”. You must enhance this path to contain the domain of your SAP Web Dispatcher.

Example: “”.

Complete Modification Handler File

Having completed the configuration steps the complete modification handler file should look similar to the following:

# Modification Handler for /sap/opa/odata/sap/CUAN_CONTENT_PAGE_RESULT_SRV/

# Authorization
SetHeader Authorization "Basic VEVDSFVTRVI6U2VjcmV0MTIz"

# CORS Enablement
SetResponseHeader Access-Control-Allow-Origin ""
SetResponseHeader Access-Control-Allow-Methods "OPTIONS, HEAD, GET, POST"
SetResponseHeader Access-Control-Allow-Credentials "true"
SetResponseHeader Access-Control-Allow-Headers "Content-Type, X-CSRF-Token"
SetResponseHeader Access-Control-Expose-Headers "X-CSRF-Token"

# OPTIONS Workaround
	RegIRewriteUrl ^(.*)$ /sap/public/ping

Alternatives to the SAP Web Dispatcher

The described configuration of the SAP Web Dispatcher acting as a reverse proxy can also be implemented using other common web server technologies like Apache HTTP Server, Nginx or Microsoft IIS. This can be helpful in case it’s not possible or not wanted to change the SAP Web Dispatcher configuration.

Helpful Links


Preflight Request:

Modification of HTTP Requests:

Deleting, Adding, and Enhancing HTTP Header Fields:

Using the SAP Web Dispatcher for SAP Marketing:

You must be Logged on to comment or reply to a post.
    • Hello,

      Unfortunately Tomcat doesn't offer reverse proxy functionality out of the box so you will have to use third-party libraries. I didn't set up such configuration yet, sorry.

      Kind Regards,

  • Hi Steffen,

    we are trying to implement this approach at the customer's. However, I am getting back the error

    Request requires preflight, which is disallowed to follow cross-origin redirect.

    Any idea what goes wrong here?



    • Hello,

      Could you please provide more details about the error? I think a screenshot of the error in the browser console or of the network request details might help.

      It sounds like the OPTIONS preflight request doesn't receive the CORS HTTP headers. However, the described configuration should set these headers for any request method.

      Kind Regards,


  • Hi Steffen,

    we could solve the issue. There was a typo on Website configuration. By now we also upgraded our Web Dispatcher so that we could allow different domains, not only one.

    Seems to work fine also. So thank's a lot for this great How To. Allows the easy setup of landing pages without php script but still making use of the files generated by yMKT.

    Best regards


  • Hi ,

    This is a setting for an on-premise system , do you have info how to do the 'same' for an Hybris cloud Marketing solution .






    • Hi Jean,

      As a Cloud customer you need to use an own SAP Web Dispatcher or your own web server as a reverse proxy.

      You can apply the same approach using the Apache configuration.

      Please find an example below:

      # Landing Page Integration Reverse Proxy
      # Replace /LP/integration/ with an own path if necessary
      <Location "/LP/integration/">
      	# Replace <>:<port> with the URL to your SAP system
      	ProxyPass https://<>:<port>/sap/opu/odata/sap/CUAN_CONTENT_PAGE_RESULT_SRV/
      	ProxyPassReverse https://<>:<port>/sap/opu/odata/sap/CUAN_CONTENT_PAGE_RESULT_SRV/
      	# Replace <Base64Encoded-Username:Password> with the Base64 encoded "Username:Password" combination
      	RequestHeader set Authorization "Basic <Base64Encoded-Username:Password>"
      	# Replace <LandingPageWebSite-Domain> with your web server address to enable Cross-Origin Resource Sharing
      	Header always set Access-Control-Allow-Origin "https://<LandingPageWebSite-Domain>"
      	Header always set Access-Control-Allow-Methods "OPTIONS, HEAD, GET, POST" 
      	Header always set Access-Control-Allow-Credentials "true"
      	Header always set Access-Control-Allow-Headers "content-type, x-csrf-token"
      	Header always set Access-Control-Expose-Headers "x-csrf-token"
      	# Workaround for CORS OPTIONS request
      	RewriteEngine On
      	RewriteCond %{REQUEST_METHOD} OPTIONS
      	RewriteRule ^(.*)$ $1 [R=200,L]

      Kind regards,


  • Hi Steffen,

    Firstly, thanks a lot for a great blog and many useful information which help us to finish Landing Page Integration. Secondly, I have a question about Prefill Contact Data and as I have read in SAP Integration Guide there are two possibility of Prefill Contact Data:

    1. When we send the email with link to Landing Page with Outbound-ID. And this case is working fine for us
    2. “When a Web user who accesses a landing page is identified, it is possible to prefill data for the Input and Permission elements on the landing page. Selecting the Prefill Contact Data checkbox allows the landing page elements to be filled with data for the identified contact, which is maintained in the SAP Hybris Marketing system.” – this information is from SAP Integration Guide 1702. And with this we have problem. Can you please give me some tip how it works and how we can use this? I haven’t found any documentation for that.




    • Hi Jakub,

      Thanks for the kind words.

      As of now, the tracked email link using an Outbound ID is the only way to identify a contact on a landing page. Therefore, this is the only scenario to support prefilling of landing pages.

      There are intentions to support an additional identification mechanism called "login scenario" but it's necessary to implement additional security mechanisms before this can be released. I can try to post a comment here as soon as the feature is available.

      I hope this information helps to clarify the problem. Please let me know if you have further questions.

      Kind regards,


      • Thanks a lot for instant answer.

        Unfortunately, this is not the answer I was hoping for. Because, if this is not a standard solution, we will have to develop a custom solution. And maybe you have some good idea or tip how can we do that. We are thinking about expand the ODATA with the parameter like DB Key or SAP ID. Do you think that can work? I would like to add that the Landing Page will be available for logged in users of the custom online store (no SAP Hybris Commerce).


        Best Regards,



        • Thanks for the feedback.

          I'm sorry that this functionality isn't available yet. I have noted that you require this functionality as part of the standard.

          Lets discuss the possibilities for a custom solution for your scenario in a dedicated conversation.

          Kind regards,

          • I will be grateful if you will finde time to discuss the possibilities for custom solution. But I just started using the SAP Blog and when you're talking about a dedicated conversation what do you mean? I should use  function like 'Ask a Question' or 'Send a Message'?

            Best Regards,


  • Hello,

    I just submitted a minor update to this blog post which mentions that the landing page web server needs to use HTTPS because the SAP Hybris Marketing system uses secure cookies.

    Kind regards,

  • Hi Steffan,

    Thanks for the blog in detail. Hope you are doing good.

    We are creating Landing Pages in Hybris Marketing On-premise and wanted to check if you can help us to clarify a question. Once we create Landing Pages in Hybris Marketing On-Premise using content editor

    1.Can we expose these landing pages to Users externally ( I mean can users click on the hyperlink in Email and access the landing page in Internet ) ? Because Need to understand if we need users to be available inside our client environment ?
    2.Can we deploy that HTML page in any other Webserver apart from Apache Tomcat webserver ?




    • Hi Raj,

      1. It depends on how/where they are hosted. Usually, you would host them on your existing public web server which should be accessible externally. If they would be hosted on an internal web server, they would not be accessible.

      2. Yes, you can use any web server technology of your preference.

      Let me know if you have further questions.

      Kind regards,