Ramp-Up for AccAD 2.2 Starts Soon – Register Now

Ramp-Up for AccAD 2.2 Starts Soon – Register Now: The Ramp-Up of Accelerated Application Delivery 2.2 for SAP NetWeaver is planned to start end of March – so just a few days to go. Lately I received a few mails and forum posts about “What’s next”. Thus, I would like to take the opportunity to share with you some more details about the enhancements in AccAD 2.2. In addition, I want to tell you a bit more about the Ramp-Up process: how you can register to participate in the AccAD 2.2 Ramp-Up.

Planned Enhancements in AccAD 2.2

Accelerated Application Delivery 2.2 implements learnings and feedback from the predecessor release. The major focus are operational improvements that simplify the overall set up and operations of AccAD landscapes. Please note that all the items listed here are only planned to be provided with Ramp-Up start – so it is still planning information (thus please do not make any purchasing decision based on this information about future functionality). The upcoming enhancements that I would like to highlight are:

• Engine can serve as SFE and CFE
• Simplified administration and configuration of AccAD landscape
• Higher scalability and further increased robustness of solution
• Additional service types for SAP applications

In the next paragraphs you will find some more details on each of those items.

Engine Can Serve as SFE and CFE

The structure of the AccAD components has changed: now you can install a single central repository which stores the whole landscape configuration. Additionally, you will still have the components Server Front-End (SFE) and Client Front-Ends (CFEs) – these are engines that build up the secure and optimized tunnel between remote locations. You can choose whether you want to deploy Repository and SFE onto separate physical entities / hosts, or whether you would like to deploy them together. Both options are possible and depend very much on the size of your landscape.
Every engine can consume and provide services. This means you can easily set up an AccAD landscape with multiple data centers. The delivery definition is unified – in AccAD 2.1 you had to set up reverse or local delivery for those kind of landscapes. Now you can just define deliveries between different locations and engines.

Illustration 1: Example Landscape Layout with 2 Data Centers

For easier understandability, let’s look at an fictious example (see illustration 1): Our major data center is in Germany / Walldorf. Here we set up the central AccAD Repository. This repository holds the overall configuration and traffic history information of the whole AccAD landscape. We have a separate AccAD Engine that connects to this repository – the SFE. In Walldorf we see various applications such as SAP CRM, SAP ERP and an SAP NetWeaver Portal. We would like to deliver those applications to our office locations distributed all over the world. One of the remote offices is in Palo Alto (USA). Here we build up another engine (CFE because it doesn’t need to connect to any repository directly). Now the users in Palo Alto can consume the services from Walldorf with boosted response times over WAN. In Palo Alto we have some SAP Business Objects applications that should be provided to the rest of the company. The same engine in Palo Alto can provide those BOBJ services to the office in Germany – and here the users can consume those with optimized performance as well. So we have constructed a landscape with two data centers in different locations easily.

Simplified Administration and Configuration of AccAD Landscape

A major enhancement within AccAD 2.2 is a standalone web-based administration UI called AccAD Administrator (see illustration 2 – screenshot). You do not need an SAP NetWeaver Portal for an AccAD Plug-In anymore. Now you can call the IP of the AccAD Repository or AccAD Engine directly and here you can perform all configuration steps including the network settings. This means that you have the AccAD Administrator available for configuring the overall landscape or for modifying the local settings of individual engines. In addition, there’s no separate appliance-config tool needed anymore to perform the initial network configuration. This eases the overall installation and configuration process. Of course you still have an alternative administration environment available – the Command Line Interface (CLI).
For the Windows-based CFE you can use the same administration environments – AccAD Administrator or Command Line Interface. So you can use CLI or AccAD Administrator according to your preference for administration environments.
Within the administration UI you can easily add configuration settings into an embedded archive – to be able to go back to a “safe state” after some changes.

Illustration 2: AccAD Administrator – Screenshot

For users that should be able to see the configuration and traffic history data, but that should not be allowed to change anything, there is a separate account available called “observer”. Here you can see everything in read-only mode.
In order to avoid multiple persons logging into the AccAD Administrator with user “admin” and to avoid the associated risk to overwrite each others changes, there is a locking mechanism included. Only one user “admin” can access the AccAD Administrator at a time – all other attempts will be blocked.

The administration concept for the delivery policy is restructured in order to support larger landscapes with less effort. In the delivery policy we find new entries for groups and locations. With groups you can define a logical grouping of engines and services, e.g. oriented on your organizational or regional structure. With locations you can define as meta-information the real physical locations where the AccAD Engines and / or services are placed. In addition, you can restrict within the definition of an engine, whether this can provide services to remote locations, consume services from other locations and / or whether local delivery is enabled. In the end a delivery policy defines which groups of services are delivered to which group of engines.

Illustration 3: Simple Delivery Policy – use group “all” only

You can see a very basic example in the screenshot above (illustration 3). This would be a typical initial setting for test or small landscapes. You can define just one group called “all” where all services and engines are assigned to. Then you can define a delivery rule, which says that all services from group “all” are delivered to all engines in group “all”.

Illustration 4: Advanced Delivery Policy – Using Different Groups

Let’s look an example which really makes use of the grouping concept (see illustration 4). We define 4 groups: an all-embracing group called “all”, a group for all internal users, a group for the internal employees in the R&D department and an external group for suppliers.
Into group “all” we can add all service instances and all engine instances. However, I decided not to define an according delivery rule, because I don’t want to give any engine access to all services.
Group “Internal-All” contains the service for the internal Corporate Portal (e.g. SAP NetWeaver Portal-based) and should be provided to all engines that are used internally, i.e. the engines in Walldorf, Palo Alto and Tokio. With the rule “internal-all to internal-all” we say, that this internal service can be consumed by all internal engines (CFEs and SFEs).

Ramp-Up for AccAD 2.2 Starts Soon

A special internal group is the R&D group. An R&D specific BW system available for this group – and the according locations with R&D members are Walldorf and Palo Alto. Thus we add those engine instances to this group as well. Again the rule R&D to R&D says that all R&D services should be provided to the engines in R&D locations.
The last item in our list is an external user group of suppliers. They have an engine (CFE) in Bangalore and should be able to access the supplier portal. We define the according rule again.
Having done this we have a mapping based on groups and locations. This can easily be extended in the future then – e.g. if you want to add an SAP CRM system access for all internal employees, you just define the service instances and define that it belongs to the group “internal-all”.

Higher Scalability and Further Increased Robustness of Solution

AccAD 2.2 supports a high number of delivered services and engines (CFEs and SFEs) and thus improved in terms of scaling. The policy definition especially for large landscapes is more convenient and can be achieved and adjusted a lot faster compared to AccAD 2.1 (see explanation of the new delivery policy approach above). In addition, the option to deploy SFE and Repository separately increases the overall reliability for large landscapes.

As background information: the structure within the AccAD Engines and AccAD Repository was simplified as well. There is no LDAP used anymore. The configuration information and traffic history data is centrally stored in a MaxDB (version SAP MaxDB 7.6). However, since AccAD comes as a software appliance, this will not have any impact on your administration tasks, but that’s just information as background knowledge.

Additional Service Types for SAP Applications

Within AccAD 2.2 we provide a number of templates for common service types. You can see different SAP Business Objects products as well as SAP CRM, SAP NetWeaver BW, SAP NetWeaver Portal and Web Dynpro applications (see illustration 5). In case the application you want to deliver via AccAD is not available s a template, you can use generic services for http / https or tcp instead.

Illustration 5: Predefined Service Types in AccAD 2.2

How to Register for Ramp-Up (Simple Deployment)

Are you interested in trying out AccAD 2.2 within your company? The registration particating in  Ramp-Up has just been opened and we still have free seats available.

Ramp-Up for AccAD 2.2

This Ramp-Up is a simple deployment, which means it’s a pretty straight-forward procedure: Just go to https://service.sap.com/rampup – in the section “Upcoming Ramp-Ups” you can find Accelerated Application Delivery 2.2 for SAP NetWeaver. In the next weeks this entry will move to section “Active Ramp-Ups”. On the page you can find a link to the nomination form. Then you just need to fill in a few basic infos regarding the contact persons in your company, rough project plans etc. After you have filled and submitted this form, you will receive a confirmation and once the software is available, you will receive a download link.

With the Ramp-Up type simple deployment there is no need to involve a Ramp-Up coach and there are no additional costs involved. Moreover, you will receive access to Ramp-Up Knowledge Transfer material (eLearnings about the new release) and invitations for Live Expert Sessions. The major goal of Ramp-Up is of course that SAP would like to receive early feedback from your side about the overall project progress and your experience with AccAD 2.2. Thus we would like to ask you to be in contact with SAP and provide feedback from time to time.

Two additional comments in this context:

• If you have no previous experience with AccAD 2.2, we usually recommend to involve consulting for planning the landscape, implementation and performance measurements. SAP Consulting has a fixed price offering available – in case you are interested in more details, please contact .
• If you would like to participate in a training session around AccAD, there’s good news: We will conduct a 1-day Virtual Life Classroom (this is mixture of an in-person session in Walldorf with the option to participate virtually). It is planned to take place on 21. May 2010 – find more details on the education pages.