The Active Component Framework (ACF) integrates active components in Web-based SAP user interfaces. The present implementation contains ActiveX controls, JavaBeans, and applets that run in Web browsers or in SAP NetWeaver Business Client (NWBC).
The ACF provides the necessary infrastructure for the following scenarios:
Processing mass data (fetch data from the back end and reset modified data)
Displaying data in-place or outside a Web browser or SAP NetWeaver Business Client (NWBC)
Integrating components in the Web Dynpro programming model (data binding, event handling)
Keeping the status of a component when a new page is loaded
The following UI elements can be installed separately as an alternative to the automatic download:
You can find the latest ACF version on SAP Service Marketplace in the following directory: Win32 link. Here you can find the installation to download. After downloading it, open the file to run the installation. For more information about the ACF installation, see SAP Note 766191 .. Open the ACF version displayed, and then choose the
ACF and Web Dynpro ABAP
Web Dynpro ABAP provides the following ACF-based UI elements for developers of user interfaces:
Note that complex UI elements can execute actions only if they are visible.
In Web Dynpros, user entries or information can be transferred to an active component nur using the context and action handler of a view. The relevant UI element must be available in this view and the view must be alive. To keep the active active component alive, set property lifeTime to whenAlive.
Active UI elements can only be used in containers where the scrollingMode is equal to none, which means they can not be used in popups.
Since rendered pages are normally displayed in a Web browser connected to the Internet in Web Dynpro, security issues must be considered for the UI elements below. This is especially important due to the generic structure of these UI elements.
For OfficeControl the whitelist concept is only relevant when using interface IF_IOS_PROJECT.
For this reason there are the following security measures:
The respective Web Dynpro UI element communicates only with authorized servers.
Only authorized executables on the client PC are triggered.
Data can only be stored in authorized directories.
Data can only be read from authorized directories.
The authorized servers and directories are listed in a whitelist, which means an administrator stored this information locally (transactions WDR_ACF_WLIST and ACF_WHITELIST_SETUP).
The administrator creates the whitelist in transaction WDR_ACF_WLIST. This transaction enables you to:
Maintain the white list
Store the white list in XML format on the front end (for example, for documentation)
Store the certificate on the front end so that it can be integrated into an installation, for example
Install the certificate, for example, for testing by an administrator
To work with a local white list in an SAP system, you need a certificate for the system in question. The administrator has to download this certificate using transaction ACF_WHITELIST_SETUP. This stores the certificate in a local directory; the installation process ensures that the certificate is copied to the correct directory.
You can use transaction WDR_ACF_GEN_CERT to create a certificate.
For more information see the SAP Implementation Guide (IMG). In transaction SPRO, choose Display SAP Reference IMG.
ACF: Create Whitelist or ., then and
SAPCRYPTOLIB (SAP Cryptographic Library) must be installed before the whitelist can be used.
The use of a whitelist is essential since Web controls can be used by potentially insecure Web pages (scripted). If users open malicious Web pages, unrestricted Web controls can present a considerable security risk.
The whitelist is created automatically once the administrator has made the relevant settings. It is no longer necessary for each user to install the whitelist locally.
The whitelist is transferred signed and decrypted at runtime. Changes to the whitelist become effective immediately. The administrator only has to store the decryption key in the system. The key can be distributed in the system environment usng the SAP GUI installation.
Instead of using transaction ACF_WHITELIST_SETUP, you can also use the SAP GUI installation (SAP front-end installation server) for distributing the whitelist on the frontend PCs. Depending on the operating system (Microsoft XP or Vista) different file paths are necessary for the SAP GUI run directory for %APPDATA% and folder SAP. An SAP front-end installation server does not have to be implemented exclusively for installing SAP GUI. It can also be used for the distribution of other files in the client environment. You can find information about VisualBasic Scripting that is available on an installation server in the documentation further below. Proceed as follows:
Set up an installation server using NwCreateInstServer.exe.
Define a package on the installation server
Create a script for an event in the new package.
Test the installation of the script that you created in step 3.
You can find more information about steps 1 and 2 in document SAP_Front_End_Installation_Guide.pdf. For more information about step 3, see Installation Server Help.chm in section.