Skip to Content

Frequently Asked Questions

Accelerated Application Delivery for SAP NetWeaver

Here you can find the FAQ about accelerated application delivery (AccAD) - this page will be updated regularly. In case you cannot find your question and answer here, you can post it in our AccAD forum and get help from the experts.

General: Accelerated Application Delivery

Landscape Planning

Installation & Configuration

Optimizations: Compression, Caching & Application Awareness

General: Accelerated Application Delivery

What is accelerated application delivery?

AccAD is a Wide Area Network (WAN) accelerator. AccAD helps to address typical challenges in global setups when web-based content should be delivered to users not closely located to the application itself. The longer the distance to this application and the smaller the bandwidth, the worse response times get for end users. AccAD overcomes those challenges by providing generic and application-aware optimizations (caching and compression) that virtually brings the application closer to the end user and thus achieves near-LAN performance for remote users. For more information, please refer to overview presentation on AccAD.

How is AccAD priced or licensed?

There is no separate pricing model for accelerated application delivery, but it is included into the following SAP NetWeaver licenses:

    1. SAP NetWeaver Full Use
    2. SAP NetWeaver Application Specific Runtime License and Related Product Options
AccAD is also bundled in our partners solution to provide symbiotic improvements - faster implementation and extended functionality. See the following link.

For more details you might contact your SAP Account Manager.

What are SFEs and CFEs?

The SFE is the Server Front-End - it is the application delivery engine which resides in the data center next to the application servers. The CFE is the Client Front-End - this is the application delivery engine that is located in the remote offices. Between CFE and SFE a tunnel is setup, and the traffic between them is optimized by
    1. Caching data on the CFE (avoid roundtrips). The caching methods of AccAD are unique and application specific - This is not a standard cache proxy...
    2. Compressing the communication, i.e. minimizing the traffic flow
    3. TCP traffic optimization - minimizing roundtrips by keeping connections open and parallelizing transmission

Of course, 1 SFE can be the counterpart for multiple CFEs

Can I use one AccAD landscape in order to accelerate the access to different systems / services? How can I configure this?
The goal of accelerated application delivery is to be a separate system that optimizes all web-enabled services (especially focusing SAP scenarios and applications). In addition, AccAD can deliver generic TCP without awareness to the protocol. Within the so called "delivery policy" you can configure the whole landscape centrally: which services should be provided by AccAD and to which remote offices (CFEs). One AccAD landscape can accelerate the access to multiple systems, i.e. you only have to set up one Server Front-End and a Client Front-End per remote office to speed up numerous different applications.

How are other services which do not come from SAP systems treated?

Every http / https / tcp based traffic can be accelerated with AccAD - this covers SAP applications as well as Non-SAP applications. Of course support for application specific problems (e.g. for integration of Non-SAP systems into this landscape) will not be provided by SAP. The administrator might have to do calibration for the Non-SAP application which is then a custom effort.

Can AccAD help improving the performance of my portal?

AccAD addresses challenges in Wide Area Networks (limited bandwidth, high latency and network congestions). LAN performance has to be good already and you can optimize the WAN access to reach near LAN speed. AccAD does not mitigate any server-side performance issues within the data center - here separate performance optimizations for the applications themselves are required. AccAD offers a "local delivery" feature which can provide modest performance improvements within a LAN due to offloading effects of the server.

Does Linux come with the installation file of AccAD?

No, you have to obtain and provide the installation media of the operating system separately. SAP delivers the AccAD installation files and documentation on how to handle the combined installation steps. You don't have to manage the operating system separately, but the installation files are needed.

Did SAP approve export of AccAD (the software appliance)?

The AccAD software itself is approved for export since it does not contain any critical code. The operating system itself is provided by the customer and not shipped with AccAD itself. In this context you should ensure that you provide the full Linux installation files including cryptography so the kickstart-based installation works properly. Moreover, the different installation options provided by AccAD might help to adjust to different legal or process requirements for setting up the landscape.

What does regional IT staff (in the remote office) have to do in order to operate a CFE?

The TCO for operating the CFE within a remote office is minimal and consists typically only of those tasks:

    1. Place the CFE in a physically secured location to ensure access - it can be treated like any other network device there
    2. Decide on the network integration and provide network configuration
    3. Start the installation with Kickstart files - more or less only insert the AccAD DVD

Backup / restore / upgrade activities are not required, since all configuration is available via the Server Front-End and thus done centrally

How can we achieve low Total Cost of Ownership (TCO)?

The AccAD concept in itself has the paradigm to be operated with a low TCO, for example:

    1. CFEs and SFEs can be operated on very lean hardware (not comparable to any application servers)
    2. Installation time is quite short - adding another remote office to the landscape takes approx. 60 min installation and configuration time
    3. Almost no lifecycle management for the system has to be performed: initial setup, configuration and installation is required and if required updates to the latest SPS. However, no backup / restore mechanisms, transports etc. are needed.
    4. All configuration steps can be handled centrally, there is almost no effort for administrating the CFEs in the remote offices (see Q&A above)

Are any customers using this now?

SAP uses AccAD as an underlying infrastructure to provide the SAP Corporate Portal, CRM, SAP Business Objects and the Learning Solution to 20,000 users located in remote offices every week.

The solution is deployed in production at more than 100 customer sites. Ranging from the largest SAP Fortune 100 customers to mid size customers.

Landscape Planning

How do I receive a device id and what is its purpose?

You should request a device ID range before building the productive AccAD landscape via customer message on component ‘BC-ACD-IDR'. The purpose is to have unique ID for every SFE and CFE worldwide, e.g. like MAC addresses for network adapters. This will ensure interoperability between AccAD landscapes, like for integrating business partners or customers into your AccAD infrastructure or for easily extending the AccAD network after mergers & acquisitions.

After you received a device ID range, you can maintain this via the Web Admin UI in the appliance landscape definition and when you add CFEs to your landscape the next available ID of this range is taken automatically.

Can I use AccAD to deliver services over the internet?

Generally AccAD does not enable public internet access for the end user (home user) out-of-the-box, since it is a symmetric solution. In case you would like to connect external user groups to your AccAD landscape, there are several options how to achieve this integration:

    1. Global DNS: this links the users to the closest available CFE
    2. Web Proxy in remote network: use the web proxy traffic interception in order to redirect traffic from a partners / customers network to the CFE within your network
    3. CFE installation for external customers / partners: a Windows or Linux based Client Front-End is deployed in the partners / customers landscape and connect to a Server Front-End within your network
    4. URL rewriting: only useful for very restricted scenarios - redirect to the closest CFE happens with unique different URL

If users are spread equally all over the world, then setting up AccAD everywhere usually would not be an economic approach - this is likely an expensive setup.

Why do I need multiple virtual IP addresses? How many addresses do I need?

You might need multiple virtual IP addresses on the SFE and CFE for the following reasons:

    1. On the SFE: In case you use a source-IP address based load balancer (Layer 4), multiple IPs are required in order to still operate load balancing properly and not to connect to same dialog instance all the time. The behavior here is similar to Terminal Servers that face similar challenges with regards to load balancing. In case you use a Layer-7 Load Balancing mechanism (e.g. based on cookies), then no additional IPs are needed on the SFE.
    2. On the CFE: Per delivered service a virtual IP address is required - it simulates the application or server in the remote location. For example if you provide a portal and ESS / MSS operated on a different server to this remote office, then those are 2 service and thus at least 2 virtual IPs are required for the CFE. Note that when using AccAD Web Proxy for traffic redirection, the Virtual IPs on CFEs are not needed, as all the traffic is going over the CFE HTTP proxy port.

The overall number of IPs needed depends on your setup, the existing landscape and the number of planned delivered services.

Do I have to manage MaxDB which is automatically installed with the AccAD installation?

AccAD comes with MaxDB when you install the Repository. The performance trace data (Traffic History) and Audit messages are saved in MaxDB. As MaxDB is integrated into AccAD, you don't have to manage it explicitly.

Can we assure High Availability with AccAD architecture?


First you can install and configure 2 instances of AccAD SFE and two instances of AccAD Repositories. In the SFE you should configure the 2 repositories IPs and in the CFE you should configure the 2 SFEs IPs. If one of the SFEs is down the CFE will connect to the second SFE. same for the SFE which connects to the repository.

In addition, you always have the option of a "fallback to wire" - the user receives the content directly from the application server in case the AccAD infrastructure is not available. How this can be enabled, depends on the traffic interception method that you use for integrating the Client Front-End into the remote office network, e.g.:

    1. Web Proxy: define fallback rules
    2. DNS Proxy: secondary DNS is defined which takes over in case of non-availability
    3. IP-Routing based: configure the routing rules accordingly

This "fallback to wire" of course means that you can always address the application server directly, however this implies then significantly higher response times. In case you would like to make the AccAD landscape itself highly available, you can set up secondary CFEs and SFEs as fallback options.

You can set up a Load Balancer in front of the CFEs which redirects traffic to the secondary CFE in case of hardware failure. In case of failure of the AccAD Engine, the Service Monitor (a component integrated into AccAD) will detect this malfunction, enables a bypass and thus redirects traffic to the secondary CFE.

In case of malfunctions on the SFE, the Service Monitor on the CFE can detect this as well and redirects traffic to the secondary SFE.

May I use VMware to install CFE and/or SFE?

Using VMware is possible, there are no known technical limitations.

So far there has been no research to determine a formula to calculate the associated performance penalty when using VMware instead of physical servers. Recent projects have shown that this depends on the virtualization technology used and ranges around 10 % performance penalty. Generally, the hardware requirement for CFE's/SFE's are quite low (see sizing recommendations described in the Implementation, Configuration and Administration Guide for AccAD). A general recommendation is to use virtualization mainly for test scenarios (because the drawback of using VMware would be some performance penalty) - whereas the costs for a physical server are often considered as minimal.

Remark: SAP supports only certain virtualization technologies, e.g. VMware ESX Server. You can find more information on the SDN Virtualization pages.

We plan to roll out MPLS in our network - does that make AccAD redundant?

No, MPLS and AccAD can be complementary means for optimizing the traffic within your network. Since MPLS optimizes the routing, of course partially the latency can be reduced / optimized. But AccAD works on TCP and HTTP level + offers application-aware optimizations - thus it should offer significant improvements in response times over WAN. In addition, as the high service level of MPLS may come with bandwidth limit and / or charged by volume, compression and caching of AccAD may also have a positive effect on optimizing costs.

Installation & Configuration

How long does it take to implement AccAD?

This depends on the specific landscape that you would like to implement. In general, installing a Server Front-End and Client Front-End can be done in a few hours. The more challenging task is to define together with your application and network groups the integration into the existing landscape, security requirements and thus the overall new architecture. The duration of this process of course depends on your internal structures and the scope of the implementation project.

Should I change parameters like the stream limit (number of connections opened in CFE – SFE tunnel)?

Usually this is not required, those settings are best practices determined in many early customer projects by SAP. Only in very exceptional cases changes to these default values are needed and in general they can be left as is. An exception might be a satellite connection with very high packet loss where it might be recommended to reduce the stream limit - however, it is recommended to carefully read the documentation and consult with AccAD experts before adjusting those parameters. This applies e.g. to parameters like Base Admin Port - http, Stream Limit and Port.

Why does AccAD install with the kickstart file some unrelated packages like "Bluetooth and WLAN Drivers"?

The AccAD kickstart file already contains a very reduced set of packages from the Linux operating system. Some packages seem to be unrelated, however due to dependencies within the operating system those are required nevertheless for the installation process.

Is it possible to have encrypted CFE-SFE tunnel?

Yes, this is described in the Installation Guide. Through the usage of Appliances Landscape, the AccAD administrator generates the configuration files for the various AccAD engines (CFE, SFE, Repository), which also contain the tunnel SSL certificates, signed by the Repository CA (Certificate Authority).

Do I need to open holes in firewall?

Yes. The CFEs in the remote offices connect over TCP/SSL to the SFE in the Data Center on a user-configured port (default is 4700).

Where is the AccAD configuration persisted? How can I backup AccAD configuration files?

AccAD configuration files are stored in the directory /usr/local/vl/base/cfg:
    adow-config.xml (Local Configuration)
    policy.xml  (Delivery Policy)
    appliances_landscape.xml (Appliances Landscape)

The AccAD Admin UI contains an Import & Export button that should be used for backup & restore procedures.

Optimizations: Compression, Caching & Application Awareness

There are application-aware caching mechanisms available for Portal, KM and LSO. What about other applications such as CRM, ERP business packages, SRM ,,,?

Accelerated Application Delivery offers efficient generic optimization mechanisms for caching data in the CFEs and compressing the traffic between CFE and SFE. Thus any http and https based application can benefit from the technology today - like CRM and Web Dynpro based applications (composite applications, business packages ...). On top of these generic mechanisms, additional application-aware optimization are added for SAP NetWeaver Portal, Knowledge Management and SAP Learning Solution. For future releases, additional application-aware optimizations for other SAP scenarios and applications are planned.

Is there any minimum version of portal or applications required to use the application-aware optimizations?

For using the generic optimizations like caching and compression no minimum releases or SPS are needed - it works in general with http and https-based traffic. The KM specific caching logic requires SAP NetWeaver 7.0 SPS 13 and above. For using the application-aware caching mechanisms of the SAP Learning Solution those versions are needed: LSOCP 602 SP02 (ECC/ERP 6.00 EhP 2 SP 2) or LSOCP 600 (ECC/ERP 6.00) SP 13 and above.

How can I see whether the KM documents are coming from the CFE cache or not?

Apart from the noticeable performance improvements for end users, there are some header details that you can view e.g. with HTTP Watch and that show whether a document is coming from the AccAD cache.

If the content really comes from the AccAD cache this means that another user has already accessed the document and now only the authentication is requested from the application server. The document itself comes from the web cache integrated in AccAD. Then you can see in the response the property "x-Cache = HIT by SAP Accelerator in process" (or "HIT by AccAD in process" in older versions).

How is Knowledge Management content invalidated e.g. after it has been updated?

For Knowledge Management some changes in the HTTP header were incorporated starting in SAP NetWeaver 7.0 SPS 13. It now contains a notion in the header whether the document was updated or whether this still is the version that is in cache. Thus when a roundtrip to the SFE and application server is performed in order to check the permissions of the user, then the validity of the cached document is verified as well.

Can AccAD accelerate the access to SAP GUI for remote users?

Yes. Significantly. It depends of course on your scenario, but in the AccAD partner edition, which is provided by our OEM partners, we offer additional significant compression and acceleration for SAP GUI.

What components of the Portal get off-loaded to the CFE/SFE?

If you are using AccAD, then these tasks can be offloaded from the application server and performed instead by AccAD:
    1. encryption (https to http and vice versa)
    2. compression (gzip compression of traffic)
    3. cached data does not require processing time on the application server
    4. serving content over slow WAN connection with many iterations. The content is transferred quickly to the AccAD SFE and the application server is free for the next tasks.

The offloading effects of encryption and compression usually could be achieved by using Load Balancers as well.

How do you synchronize/update the cached data during normal operations and after any updates (deployments)?

You can provide within AccAD information on how long the data of a certain type should be cached. This can be done within the policy configuration for certain transaction types - you define minimum and maximum freshness times which define whether the resource in the cache is fresh or whether it should be loaded from the application server again. Moreover, usually on the application server resources contain freshness periods as well. Then always the less restricting time is taken, e.g. freshness time within AccAD is 4 hours, freshness time of resource on application server is set to 24 hours - resource is considered fresh for 24 hours. For KM there is an additional logic incorporated (see question "How is Knowledge Management content invalidated?").


No comments