Change Management in SAP NetWeaver’s Enterprise Portal (EP) and Knowledge Management (KM) has always been some what of a sore point with clients. Clients that implement EP and KM, most likely, are already leveraging other SAP solutions such as CRM, HR, BW, etc. and therefore, utilize the tried, tested and true methods of the SAP Transport Organizer under SE10. Enter NetWeaver, all transports are done manually and there are many different transport tools that one must learn to offer a fully capable Change Management solution. Further, while SAP will recommend strategies, the actual process is usually left to the client to detail. This white paper will attempt to outline every type of transport mechanism involved with EP and KM as well as offer a generic process that would fit any clients’ needs. While this white paper will touch upon simple custom Portal Archive Application transports, it will not cover CM in pure development environments such as the NetWeaver Development Infrastructure (NWDI).

Change Management Introduction

Before we consider CM (Change Management) in SAP NetWeaver, let us recognize that CM affects many layers of the SAP NetWeaver stack. Regarding EP and KM, we will touch upon People Integration, Information Integration and Application Platform – 3 of the 4 layers as depicted in the SAP NetWeaver stack diagram below, affectionately referred to as the “NetWeaver Refrigerator”.


The CM model must cover the following entities to be considered a robust solution:

• Portal Objects (iViews, Pages, Worksets, etc) – People Integration
• URL Reference Files – People Integration
• Portal Display Themes – People Integration
• KM Documents and Repositories – Information Integration
• Layout Sets – Information Integration
• Custom Portal Archive Applications (PAR) – Application Platform

Transporting Entities in SAP Netweaver EP and KM

Portal Objects

The mechanism for transporting Portal Objects is probably the most commonly known transport practice in CM for EP. Most clients already have some sort of change control administrator that will create the export package (.epa) and import it to the target system. Here are the basic steps:
a. System Administration–>Transport–>Transport Packages–>Export
b. Browse the Portal Content structure for the folder in which you would like to create the transport package
c. Right-click to get the context menu and choose New–>Transport Package

After filling out the required meta-data fields, open this object for editing and you will be presented with your transport package that already contains an object, the package contents. It may seem redundant to have a package within a package but this is actually a very important piece of the CM process as we will see in later sections of this white paper. For now, let us accept this object as being simply the information on what is going to be in our transport package, a sort of “table of contents”.
d. Browse the Portal Content folder and use the context menu to add your objects to the transport package
e. Click Export to review your package

After the export has completed, the package will automatically be copied to a location on the server (usrsap[sid]SYSglobalpcdExport) – which can be changed. You will also be given the chance to copy down this package to your local file system or a share on the network. The recent patches have removed the “include all dependant objects” option from this process. The arguments on both sides of this decision are still raging so let us leave that topic to another white paper.
f. Log into the target system and navigate to System Administration–>Transport–>Transport Packages–>Import
g. Select your package from where ever you decided to put it and click Upload then Import.

It is a good idea to overwrite all contents since your transport will most probably have the most recent changes to the Portal objects that you are transporting.

URL Reference Files

In an ideal SAP world, the client would have separate systems for each environment, and that includes systems for applications such as, intranets, document repositories and files systems. While your transport of Portal Objects would have brought across the actual iViews, Pages, Worksets and such, it would not have included the target source for objects such as URL iViews. So now we have a QA environment pointing to a DEV application server, ouch. This is where reference files and manual changes come into play. To append the steps above:
h. Edit the URL iViews to point to the target systems application servers
i. Copy over the changed application server files that are referenced by the URL iViews

A good example of this is a simple URL iView that points to the intranet page “intranet.mycompany.com/PaulaShultz.htm” however in DEV it is “dev.mycompany.com/ PaulaShultz.htm” and in QA it is “qa.mycompany.com/ PaulaShultz.htm”. These post steps should be well tracked and vigilantly controlled. To keep transports in synch, PaulaShultz.htm should be a file that is also packaged with the .epa file that was created.

Portal Display Theme

Look and feel of the Enterprise Portal is almost always a customization that the client asks for. Whether they choose to simply work within the framework of the Theme Editor or completely customize the PAR files which the framework references, the separate transport mechanism is the same. Here are the basic steps:
a. System Administration–>Portal Display–>Theme Archive
b. To export, simply click on the name of the theme you have customized and download the resultant .zip file
c. To import, use the same interface in the target system and browse to the downloaded .zip file in the previous step

Again, it is a good idea to overwrite. The importing of a theme, while it may only be a few hundred K in size, needs to be run through the Theme Editor to ensure compliance with all the fields for every customizable object. This takes a lot longer than simply uploading the .zip file so if you notice a considerable delay during this task, don’t worry, it’s normal. You will eventually get a confirmation message that will give you the warm and fuzzies.

KM Documents and Repositorie

To transport KM content, we use the ICE (Information and Content Exchange) protocol. This method allows for both online and offline synchronization of KM content. The online method simply synchronizes the backend KM repositories on an ad-hoc basis and therefore, does not require a separate process for transporting. For the purposes of change management, let us explore the offline method. When it comes to KM and ICE, we should start using the words “Syndicate” and “Subscribe” which more or less equate to “Export” and “Import” respectively. Ensure that the offline method is enabled by following these steps:
a. System Administration–>System Configuration–>Knowledge Management–>Content Management–>Repository Managers–>Content Exchange Repository.
If you do not see Content Exchange Repository as an option you must switch to Advanced Mode.
b. Edit this repository manager and ensure that “Hide in Root Folder” is unchecked
c. Restarting the servlet engine after making this change is actually not needed
Under Content Administration–>KM Content you should now see an “ice” folder under the root. Here we see our exporting/syndicating and importing/subscribing tools. Let us go through an example of transporting a simple KM repository.
d. Click Syndicator–>Global Offer and select Folder–>New–>Link from the menus
e. Browse to the repository you wish to syndicate and select the radio button beside it and click Save
f. Back in the Global Offer folder you will notice the folder you selected in the list
g. Click Complete Package and this will allow you to download the syndication in .zip format as “fullupdate.zip”
h. Subscribe in the target system by navigating to the Subscriber–>Update folder and uploading your “fullupdate.zip”
Now you have transported a KM repository between systems.

Layout Sets

While SAP delivers a handful of default layout sets, some clients will still want to customize the look, feel and behaviour of their KM iViews. Assuming the developers have adhered to the developing standards for Layout Sets here are the basic steps for transporting them:
a. System Administration–>System Configuration–>Knowledge Management–>Content Management–>User Interface–> Settings–>Layout Set
b. Here you can export from the source system and import to the target system

The exported file will be of type .configarchive and may also be bundled with the transport package.

Custom Portal Archive Applications

A PAR (Portal ARchive) file is basically a custom application written in JAVA that will be displayed within the Enterprise Portal. While this application can be a completely new piece of functionality, SAP has offered documentation to developers for customizing the EP pre-packaged PAR files (https://www.sdn.sap.com/irj/sdn/javadocs). The most common PAR that clients customize is the logon screen PAR file (com.sap.portal.runtime.logon.par). The tool of preference is the NWDS (NetWeaver Developer Studio). This tool may deploy PAR files directly to any system, DEV, QA, etc. Since that may be a choice for some clients on a transport process it would not offer much control for administrators or proper change management solutions. Luckily, there is a way to transport PAR files. Here are the basic steps:
a. System Administration–>Support–>Portal Runtime–>Browse deployment
Now you are simply browsing the instances backend file system. From here you can view or download the intended PAR file to be transported. Previously in this section, we touched upon the “include all dependant objects” option that used to be available in the Portal Objects transport function. This option would have included any PAR files that the iViews would have been built on. Now that option is gone and we must deal with it.
b. Download the PAR file and remove the .bak extension
c. Import to the target system under System Administration–>Support–>Portal Runtime–>Administration Console

This is a very powerful console. From here, you can deploy PAR files directly to the SAP J2EE engine, view them, delete them and even get reports on what PAR files have not been deployed or a list of every single PAR file that has been deployed.

Change Management Strategies, Best Practices and Processes

Transport Strategies and Best Practice

You will notice that every transport mechanism that is detailed in section 2, results in some sort of frozen-in-time file (.epa, .zip, .configarchive, etc). This makes packaging a transport that contains many different entities very easy. This is also where the package within the package idea comes in (or “table of contents”). If say, a transport was moved to QA and it failed testing and was requested to be backed out. In the Enterprise Portal, the only way to ensure a clean backout, is to export the target objects (if existing) from QA and then re-import after such a failure. Well the table of contents in the package would let us know exactly what was inside the package for this purpose. Further, to tie it all together, it would be prudent to have developers or administrators fill out a transport form that would detail all the entities to be transported. Here is a suggested list of transport form fields:

• Transport Package ID – this could also be the physical name of the folder that would contain all the frozen-in-time files
• Iteration Number – if the transport was performed in the past
• Requester
• Approver
• Source System
• Target System
• Technical ID’s of All Entities to be Transported
• Manual Changes (if any) – such as changing the URL to point to the target systems application server

When transporting, it is advised by SAP, to transport from DEV to QA. Then if the transport succeeds, transport that very same package from DEV to PROD. This would ensure that QA and PROD remained in synch. It is also advised that the developers should create and export their packages, as they are the only ones who would know when the content is ready for transport as well as know exactly what entities should be packaged. A transport to production is considered successful once the business users have approved it. In summation, here are the points on strategies and best practices:

• Create a folder for all frozen-in-time files
• implement a backout strategy
• Use a transport form
• One export (from DEV) and two imports (to QA and PROD)
• Developers create and export their packages
• Have business users approve transports in production

Process Flow Diagram

Below is a sample transport process diagram that should fit any clients’ basic transporting needs. Of course, this process can be expanded to custom fit to the clients’ needs.

Concluding Change Management

The world of SAP NetWeaver has come a long way in Change Management. Prior to NetWeaver, there were no such mechanisms and clients resolved to manually re-doing all changes in all environments, that is, if the client chose to have more than one environment in the first place back then. Alas, the good old simple architecture days are behind us. This white paper is a good start to getting your clients well on their way to a robust and fully capable Change Management solution. Recognizing that CM affects many layers in the SAP NetWeaver stack and many departments in your clients’ organization is the key. To recapitulate, here are the main entities that are transportable in the current versions of NetWeaver:

• Portal Objects (iViews, Pages, Worksets, etc) – People Integration
• URL Reference Files – People Integration
• Portal Display Themes – People Integration
• KM Documents and Repositories – Information Integration
• Layout Sets – Information Integration
• Custom Portal Archive Applications (PAR) – Application Platform

Coupled with a detailed Transport Process diagram, let us review the strategies and best practices:

• Create a folder for all frozen-in-time files
• Implement a backout strategy
• Use a transport form
• One export (from DEV) and two imports (to QA and PROD)
• Developers create and export their packages
• Have business users approve transports in production