In the last days and weeks we saw a lot of questions regarding public parts and also regarding class loader issues in WCEM extensions.

Therefore I give here a short overview about the required DC dependencies you have to maintain if you create new or enhance already existing modules.

Actually the most import point is to understand the difference between Build Time and Runtime dependencies.

For the standard module part DC's (like Metadata, UI and BO part) only the Build Time dependency is relevant.

Let's take a look to an example of a catalog extension:

In this example you see already a lot of importing things:

• Only use PublicRestricted, PublicStable and ExtensionRestricted and ExtensionStable parts from SAP DC's.
• Never ever use any assembly parts here
• Internal parts are only allow for SAP internal unit tests
• Add the DC wec/frw/tc/core to have access to web channel framework functionality

If there are still SAP classes missing in SAP public parts, which should be available for extensions, then please raise an OSS message. This is an error, which has to be fixed by SAP.

Important: The SAP public parts are only relevant for the Build Time!

Your DPU DC now defines the runtime dependencies.

Please be aware that every module DPU has its own class and therefore only know classes to which a runtime dependency is maintained. Therefore your DPU should have dependencies to the following DC's:

• DPU of the module you extend
• the framework "module" wec/frw/tc/core/app, if framework functionality is used
• DPU's of any module, which you are using directly

Beside this a DPU should than only include your assembly parts.

Never ever deploy SAP assembly parts with your DPU's.

If you are using JSF objects directly you have also to add the JSF library in the application-j2ee-engine.xml:

<!--  JSF 2 Implementation -->

<reference reference-type="hard" prepend="true">

        <reference-target provider-name="sap.com"

            target-type="library">wec~frw~tc~jsf~lib</reference-target>

</reference>

Please use for all other references the DC dependencies instead of entries in the xml.

I hope this blog helps you to create more easily your own modules in the future!

Dear community members,

here a great article from the very experienced WCEM partner DeVilliers Walton, "A short walk from WCEM 1.0 to 3.0".

Thanks for sharting, Jie and Darron! It was a pleasure to meet you on the WCEM 3.0 RKT workshop.

Enjoy,

Ingo

A release upgrade of SAP Web Channel Experience Management is possible from any release to the latest in a direct upgrade. This is shown in the Product Availability Matrix (search for “SAP Web Channel”):

Please read the Release Information Notes for WCEM 2.0 and WCEM 3.0 to check the release requirements, especially the required Service Pack levels of the Java Application Server version and the MDM components. Additionally, obligatory upgrade steps are available in the Master Guide and Installation Guide on the Help Portal (http://help.sap.com/wec) for both releases.
Please be aware that until WCEM 3.0 the mandatory NetWeaver release is 7.30 (not 7.31 or higher!).

In WCEM release 2.0 a major upgrade of the technology stack has been performed: SAP upgraded the used JSF library from 1.2 to 2.1 version. This step opens up a whole range of new possibilities for development of state-of-the art web applications, simplifies the architecture and improves runtime performance. Based on the standard JSF2 architecture some JSF1 concepts are not available anymore so that such implementations need to be adjusted accordingly. These adjustments have been performed in standard WCEM 2.0 so that WCEM Framework and all WCEM Modules have been migrated to JSF2 technology.

Of course this cannot be ensured for custom extensions of the framework, extensions of the SAP modules and for newly created custom modules. This blog shows major aspects which need to be considered with regard to migration of such WCEM 1.0 based custom enhancements.

More information:

• WCEM Public WIKI, section „Installation“, „Configuration“, „Development & Extension“
• WCEM Platform – Technical Introduction
• Advantage of using Java Server Faces
• What's new in WCEM 2.0 and 3.0
• Feature List of WCEM 2.0 and 3.0
• A short walk from WCEM 1.0 to 3.0 by De Villiers Walton Consulting
      

Java Application Server (Java AS)

Because with beginning of WCEM 2.0 the technology basis changed considerably, you need to be careful while deploying of standard WCEM 2.0 or newer on a Java AS where WCEM 1.0 runs successfully including custom enhancements. The Java AS for WCEM cannot serve two different release versions in parallel so that in case the WCEM 1.0 based enhancements won’t be adjusted before, you have to expect that your custom development won’t be runnable anymore.

In case you rely on a runnable WCEM system w/o any down times, it is recommended to use a separate server for the higher release version in parallel. When the new release is running successfully, the older system can be dismantled accordingly.

In case you have no customer or partner specific changes yet, you can use your existing Java AS for the upgrade w/o any obvious risk. In general, the Java AS server can run on a virtual machine or on a physical server.

Customizing Settings

Generally the WCEM related settings, like customizing data maintained in the Web Channel Builder tool, will be upgraded automatically so that you don’t need to execute and manual configuration data migration. For all other steps please check the Release Information Notes, the Installation Guides and the Master Guides as mentioned above.

SSL Certificate

You should be aware about one important change which could hinder you after the upgrade: from WCEM 2.0 Patch 8 and higher, the application switches automatically to https protocol, latest before displaying logon screen. This is mandatory because of security reasons. In case you decide to disable this functionality, please read SAP note 1812800 how to achieve it.

Backend System Activation

Business functions in the backend systems ERP and/or CRM have to be activated in order to support the higher WCEM release. For backend activation please read the notes for WCEM 2.0 resp. WCEM 3.0

NetWeaver Development Infrastructure

As next step you need to take care about your developed extensions. It’s recommended at first to create new version of your already existing Software Component which hosts your custom code based on former release. 

Then a new Track needs to be created. You're creating it in the Change Management Service (CMS) of the NWDI and there you're assigning the Usage Dependencies to the SAP-delivered Software Components of the new release. In particular, you need to assign references to NW and MDM Software Components and to the SAP-delivered WCEM Software Components of the new WCEM release (please use always the newest patch). The process at this point is the same as for the former WCEM release so that you can follow the steps which you've done in the past.

Finally the new Software Component version of your extensions needs to be assigned to the newly created Track as well.

As a result you should have a new NWDI Track for the new WCEM release with all needed SAP components so that you’re able to deploy the standard SAP software on a Java AS successfully. Additionally you have new Software Component version for your custom made WCEM extensions which need to be migrated as the next step.

Net Weaver Developer Studio (NWDS)

Now you can use the NWDS for importing the new Track and focusing on the adoptions relating your WCEM extensions.

As already pointed out, WCEM switched in release 2.0 to the JSF2 standard. It’s strongly recommended to become familiar with JSF2 before any coding activities to get better understanding of available implementation options from the Java standard perspective. Additionally the WCEM 2.0 Development and Extension Guide provides extended documentation relating the technical basis of WCEM.

As additional prerequisite you shall update/install newest version of the WCEM Workbench Plugin. See WCEM 2.0 Development and Extension Guide, chapter 7.8 for more details.

At this point you should be able to start with code-related activities. All important implementation steps and cases are described in very detailed form in the WCEM 2.0 Development and Extension Guide, chapter 7.10. At this point it should be specifically highlighted that most of the needed migration steps will be covered by the WCEM Workbench Plugin in an automatic way. Additional, more special and manual steps has been described in chapter 7.10.

After your extensions have been migrated entirely you can deploy your custom Web Site (Main App) and your custom Web Channel Builder on a Java AS, open your web application in a web browser and test if the new WCEM release runs with customer/partner namespace changes successfully.

Dear community members,

WCEM is getting more popular every day. This guide shall help you to step into it in an effective way.

1) Overview and Introduction

• The best introduction in WCEM is to watch the recorded video sessions for WCEM 2.0.
  • Watch at least the sessions 1 to 4.
  • Developers should watch session 5 as well
• Watch the WCEM 3.0 Presentation
• Check the Application Help about what's new in WCEM 3.0

2) Deep Dive Training

• Perform the comprehensive RKT Learning Map trainings (see the WCEM Public WIKI, section Rampup)
  • Please note these are delta trainings. So start with 1.0 > 2.0 > 3.0
  • Customers/partners: These learning maps are not for free, but extremely comprehensive and worth every penny. You have to get a license for it, or participate in rampup or RKT workshops. Request access. 

3) Consulting Focus

• Read the blogs in the Expert Blog Index
• Make yourself familiar with the content of the WCEM Public WIKI which is THE central info source for WCEM
• Read the full version of the FAQ document
• Watch the recorded video sessions 6 to 10 for WCEM 2.0.
• Browse through the Application Help > see WIKI section Help, Support and Operation
• The Module Parameter Guide explains each and every setting in the Web Channel Builder > WIKI Configuration
• Read the installation guide (WIKI > Installation)
• Ask questions in the SCN WebChannel Community
• Again, check the WIKI and pick even special expertise from there
• In case you don't find specific information send me an email

4) Technical/Development Focus

• Follow 3)
• In addition watch the recorded video session 5, if relevant also 6 to 10 for WCEM 2.0
• Read the Development & Extension Guides (General and Application Specific)

You feedback is highly welcome, and I would love to include your learning experiences in this blog as well.

Best regards 

for the SAP Web Channel Experience Management team members

Dr. Ingo Woesner

Product Management
SAP Web Channel Experience Management - Rollout

SAP AG

In the previous release some customers asked if we support the “Early Logon” in the B2B-Scenario. Unfortunately there was no solution in the standard solution available and some customers have implemented this on project basis.

Now, with release 3.0 we also support the Early Logon. “Early Logon” means that the user is forced to logon right at the beginning. The user has no chance to see the product catalog, details of a single or any other page without an authentication.

Therefore the entry-page only shows the logon with the option to logon and to register. Even the Search-Field in the header is not visible as the “Search-As-You-Type-Search” already shows results in the overlay-window.

The Early Logon is rather a B2B-Feature but also in B2C there are some use cases for special shops where users have to be registered and logged on in order to really enter the shop.

How to activate the Early Logon?

The option to activate the Early Logon is available in the “User Module” in the Web Channel Builder (Section “Early Logon”).

Illustration I: Activation of the Early Logon in the Web Channel Builder (Module: User)

If you activate this setting every user will be forced to logon directly also if he navigates to the shop via a bookmark of a specific page.

However there are some exception …

In the footer you can see some links which are still active. These links are relevant even before the user registers. Therefore the standard-Links customerServicePage and aboutUsPage are always displayed.

Illustration II: Web-Shop with Early Logon and standard-links in footer

In addition there is an option in Web Channel Builder to exclude also other pages from the Early Logon. For all excluded pages the user will not get forced to logon if he opens these pages.

Further Information

SAP Web Channel Experience Management - Expert Blog INDEX

SAP Web Channel Experience Management - New 3.0 Release

Web Channel Experience Management WIKI

SAP WCEM 3.0 Learning Map

One of central topics of SAP Web Channel Experience Management (SAP WCEM), release 3.0 is the integration of product configuration capabilities into SAP WCEM. With this you would be able to offer individualized products to your customers. Well, the development teams did a great job to achieve this with SAP WCEM 3.0. Let me take the opportunity to give you an overview about the key features of product configuration@SAP WCEM.

You might notice that we reused some of the concepts from Internet Sales (ISA), while others are completely new or were reworked to fit better to WCEM's philosophy.

Key Features

Interactive Configuration

At the core of product configuration@SAP WCEM is a dedicated page, where the options (characteristic values) for the related attributes (characteristics) can be set and entered respectively. This page can be reached either from the product overview and product detail page respectively via the big per default green button or from the cart via the "Configure" link of the affected line item.

The content of the interactive configuration page is dynamically built based on the product modeling, which was created in the backend. This affects both, the more static part of the modeling such as attribute types, layouts, basic set of allowed options as well as the more dynamic part such as hiding or displaying attributes or options, validations and so on. The structure of the main area follows the modeling in terms of components (instances), attribute groups and attributes. Navigation on the page is supported by a "Previous/Next" navigation, which takes the user from one area of the structure (e.g. a group) to another, and by the option to expand/collapse areas of the structure.

As the page is built using our AJAX enabled WCEM UI framework, user inputs are per default validated immediately. To support those users, who prefer to set the options "top down", missing mandatory attributes are not claimed immediately, but upon checking the whole page using the button. If there are still entries missing, the user is guided towards the missing attributes.

Configuration Summary

To support users in getting a quick overview of the current status of the configuration, we offer two different kinds of summary views in different places: a table summary and an inline summary. Both kinds of summaries can be customized individually. The attributes to be shown can be configured based on definitions made in the modeling and the settings in the WCEM configuration tool, the Web Channel Builder (WCB).

Table summary

The table summary contains a list of attribute/value pairs and is integrated both into the product detail page and into the interactive configuration page (values only).

Examples:

Inline Summary

The inline summary lists attributes and values in a single text line, which is integrated into the item table of the shopping cart, checkout, order confirmation, order display and of the shopping template.

Example:

Price Display during Interactive Configuration

Product Price

On the interactive configuration page, you can see the net value on product level. This value is adjusted every time the user enters or changes options, that have an effect on the net value (please note, that I just mentioned the net value).

Prices for Options

We are able to show the amounts that are added to or subtracted from the price upon selection or deselection of price-relevant options. These values are based on the backend modeling on one hand and on backend price definition on the other hand.

Variants

With variants you can offer your customers predefined versions of a configurable product, representing typical customizations. This might make sense, if you want to optimize procurement, keep such items in stock or sell them at a special price.

Variant Determination

If the current status of a configuration matches the customization of one or more variants, the user is notified that variants are available. If desired, the user can navigate to the variant comparison to get details.

Variant Comparison

On this dedicated page, the user can compare attributes and values of the current configuration with the ones of all applicable variants. The layout is similar to the product comparison page. If desired, users can abandon their configuration and add a variant to the cart instead.

Shop Configuration

There is no explicit activation of the product configuration in WCB. As soon as the IPC module is added to an application configuration (which is the case e.g. as soon as you add the salestransaction module to the configuration), product configuration is available in the affected shop. The basic availability of the product configuration functionality is purely controlled by the backend in terms of

• Product master data
• Modeling
• Sales order customizing

For the Web shop as such, just certain features are adjustable:

• Summaries and filter for summaries
• Price information for options
• Variant comparison
• Switching to "validation on request" mode

Architecture

You didn't think, you could get away without any remarks on architecture, did you? Well, for those of you, who just want to know the gist, here are the crucial points:

• Both ERP and CRM backends are supported with their related back-end carts.
• Product configuration@SAP WCEM relies completely on SAP's sales configuration engine, the IPC. For the IPC, just the "Compatible-Mode" (as opposed to the "Advanced-Mode") is supported.
  Side note: Customers interested in WCEM-ERP are sometimes confused by this statement. It does not mean, that for IPC a separate installation is required. The IPC runs in the Virtual Machine Container (VMC), which is part of your (ERP-) NetWeaver Application server installation.
• Both catalog engines - ERP-TREX (just for WCEM-ERP) and Multi Channel Product Catalog - are supported. Even a shop without catalog (just with cart and checkout) would be supported.

Having said this, let's now come to the details.

Product Modeling using Variant Configuration in ERP

This scenario is available with both backends, ERP and CRM. With this scenario, obviously the famous "IPC-Delta-List" remains valid. The vast majority of modeling options is supported with product configuration@SAP WCEM. If you are new to SAP WCEM, this scenario provides you with the opportunity to reuse your product models without the need to adjust them for use in SAP WCEM.

The basic scenario looks as follows:

You model your products as usual in ERP Variant Configuration. You create characteristics, assign them to classes, maintain BOM's, configuration profiles, dependencies, constraints and so on and so forth (see Variant Configuration Online Help for details).

As a rule of thumb one could say, when you are able to configure the material in VA01 as desired, you are done. Important is that when you are done, a knowledge base needs to be created and a runtime version needs to be generated. The knowledge base is the central master data container the IPC uses  during configuration. For the sake of completeness, if you are using custom user-defined functions, you have to migrate them to Java if they are needed in the sales context.

If you are using WCEM-ERP, you are done at this point. If you are using WCEM-CRM, you have to make sure that the model data (actually the knowledge base and its runtime version) is downloaded to CRM. Personally, I found How-to-Guide: Middleware Settings for Download of IPC Configuration (KB) Data from R/3 to CRM System helpful for this task. With this, you are set for WCEM-CRM as well.

Product Modeling using the CRM Product Modeling Engine

This is a use case e.g. for configurable service products, where you do all your master data maintenance in CRM. With this it is applicable to WCEM-CRM only. Actually the CRM PME maintains the knowledge base directly and you are set for WCEM-CRM.

Runtime: WCEM-CRM

During runtime, when showing the interactive configuration page, WCEM communicates directly with the IPC to render instances, characteristic groups, characteristics and characteristic values. When the user navigates back to the cart or adds a product from the interactive configuration page to the cart, changes are passed to the CRM Order engine. The engine validates the changes via IPC and updates the shopping cart accordingly.

Runtime: WCEM-ERP

During runtime, when showing the interactive configuration page, WCEM communicates directly with the IPC to render instances, characteristic groups, characteristics and characteristic values. When the user navigates back to the cart or adds a product from the interactive configuration page to the cart, changes are passed to the SD Sales Order engine. The engine validates the changes through Variant Configuration and updates the shopping cart accordingly.

Further Information

• SAP ERP Central Component Application Help: Variant Configuration (LO-VC)
• SAP WCEM 3.0 Application Help: Configurable Products
• SAP WCEM 3.0 Learning Map

More WCEM Blogs to check out

Please check SAP Web Channel Experience Management - Blog INDEX for further blogs.

Since SAP Web Channel Experience Management Release 3.0 two new features for the Contact-Scenario (also known as B2B-Scenario) have been introduced:

a) B2B Selfregistration

b) Delegated Admin Scenario

B2B Selfregistration

With the B2B Selfregistration the registration of a Corporate Account for the Web Shop as a selfservice is supported. Two different options for the Selfregistration have been enabled.

a) Registration of a new user and a new company

b) Registration of an existing contact person for an existing company

The registration of a new user and a new company is the registration from scratch. This means there is no Business Partner data and related Contact Person in the database. There is also no user available for the Web Shop. In this case a Sold-To Party a related Contact Person and the related User will get created within the registration.

The registration of an existing contact person for an existing company is just to create a user for the already existing Business Partner data. In this case the user has to enter the correct Company ID and the related Contact ID.

The B2B Selfregistration is an option to reduce TCO as the involvement of internal employees will get reduced. There is still some effort for the internal employees as the registration request has to get validated. Therefore a 3rd type of the Selfregistration is not supported – the registration of new Contact Persons for existing Companies. This would always cause effort as this new user should not get access directly. The validation as such is quite cumbersome as there must be a check if the entered data is correct and if it is also intended by the customer that this new contact should have the right to order products or not. At the end the internal employee has to get in contact with the customer directly for this verification. This check is very important as the user has access to the Sales Documents right after the approval of the registration process.

Delegated Admin Scenario

Another option to empower the customers of the web shop and to reduce the effort for the internal organization is the activation of the delegated admin scenario.

A delegated admin is a contact person who has special authorization rights to create other users for the web shop. These users are also contact persons of the company the delegated admin is assigned to. In other words the delegated admin is the user of a customer and has the permission to also create users for his colleagues.  The delegated admin can also change some data of the users he is responsible for. He can lock/unlock the user, he can also change some date like phone-number, and he can assign predefined authorization rights.

The authorization roles have to get maintained in advance so that the delegated admin can assign these roles.

These settings can be made in IMG for a CRM Backend under Customer Relationship Management -> SAP Web Channel Experience Management -> Basic Settings -> User Management -> Set Up List of Authorization Roles and for ERP under Sales and Distribution -> SAP Web Channel Experience Management -> Basic Settings -> User Administration -> Set Up List of Authorization Roles.

In principle there are two options how to get delegated admin rights. One option is that the administrator of the Web-Shop directly asks a contact of a company to become a delegated admin. The other user case is that a user asks the administrator to get delegated admin rights.

After the delegated admin has created additional users there is no further automatism or workflow available in this release. The delegated admin has to inform new users about the logon with the defined username and password (e. g. via e-mail). As there is no expired password mechanism the user is not forced to change the password directly after the first logon. Therefore the delegated admin should also include such a recommendation for the user.

Combining Selfregistration and Delegated Admin Scenario

For the B2B Selfregistration with new Company there is also an option to automatically assign authorization roles. With this feature it is possible to e.g. assign special authorization only to the first registered user. This makes sense e. g. if only the first contact person of a company should get the right to create Service Requests. It’s also a good use case to assign Delegated Admin rights to the first Contact Person of a Customer. This is the ideal combination to reduce TCO. For the registration of a completely new company the involvement of the internal employee is not that high. In principle he just has to check if there is already a duplicate record or not. In this case the new created contact person could automatically get the delegated admin rights assigned.

The risk is also rather low, as there are no security relevant documents assigned to a new company.

Image I: Web Channel Builder (Module "User" with the settings to assign roles to the first contact of a new created Sold-To Party).

If the customer needs additional users at this shop for ordering products or requesting services there is no need to involve the Web Shop Administrator anymore. This can be done by the delegated admin. Here the Web Shop Admin would also not be in the position to judge this. Only  the delegated admin knows, if the user should get access or not.

Additional Information:

Web Channel Experience Management WIKI

SAP Web Channel Experience Management - New 3.0 Release

SAP WCEM 3.0 Application Help: Registration in a Contact Scenario

SAP WCEM 3.0 Application Help: Delegated User Administration

Overview.

You are using a CRM WebChannel or E-Commerce application and modified it with the SAP NetWeaver Development Infrastructure (NWDI). Now you want to upgrade to a newer CRM Release level. This is only relevant if you have modifies/enhanced a CRM WebChannel/E-Commerce application based on Java if this has not been done these steps can be ignored.

Solution

When planning an upgrade from one CRM Release to another you need to perform some steps before the upgrade.

First create a new track for the new release. SAP strongly recommends using a new Track for release upgrades. With this approach you can avoid critical situations during an upgrade process.

The blog “Best Practices for NWDI: Track design for ongoing development”  describes possible situations that may occur during an upgrade.

The process is the following:

• Create the track with your target version
  • Create the new Track and add the software components (SCs) to it If you only modifying content from SAP-SHR* packages, then you do not need the software components SAP-CRMAPP, SAP-CRMWEB. Only if you modify SAP-CRMAPP or SAP-CRMWEB, then you also need the SAP-SHR* software components.In addition you also should maintain the build variant properties. The main used properties are:
    • com.sap.jdk.javac.source = 1.4
    • com.sap.jdk.javac.target = 1.4
    • com.sap.xlf.trim-property-keys = true
    • Also if you are using a newer NWDI, then the default JDK is not a 1.4 JDK. Then you have to set the 1.4 JDK for the build variant. The SAP Help page describes how to do it with DI 7.30.
      The javac source and target should be 6 for versions starting with 7.3x. E.g. 7.31#
    • Set the Exclude from Deployment flag for all SCs except SAP-CRMDIC and CUSTCRMPRJ (or any other SC you will place your applications in)
    • Also set the Exclude from Deployment flag to the dependencies. This can be done by
      • Enter the edit mode of the track (click on the change button)
      • Click on "Filter" (in the software components (SC) section, just right to the Define Dependencies button.
      • Some new selection/filter screen will be shown.
      • Select in the selection box Show the option "All software components" or “Required Software Components”
      • Set the "Exclude from Deployment" flag for all SCs you do not want to be deployed/shown in the system info page
      • Switch back the filter to "Developed software components"
      • Click again on "Filter" to let the filter to be disappeared
    • The initial set up of the target track is finished.
• Prepare the target version track
  • Go to your track with your current application and find out the used version
    • Go to your CMS, tab System State
    • Select one of the Components you want to import later
    • Click on Details
    • In the pop up you will see the Support Package Number and the Patch Level
  • Take the unmodified SAP archives in exact the same version used by your current application and import it into the new created track
  • Import the target SAP version of the software components into the track. If you only modifying content from SAP-SHR* packages, then you do not need the software components SAP-CRMAPP, SAP-CRMWEB. Only if you modify SAP-CRMAPP or SAP-CRMWEB, then you also need the SAP-SHR* software components.
  • The track might have conflicts caused by SAP. Resolve these conflicts as described in note 1672262.
    This step also applies if you only use one track for the upgrade.
• Finish the upgrade
  • Go to your old track and assemble your software components depending if your new track will use the same Design Time Repository (DTR) or
    • If your new track will use the same DTR then assemble the SCs with the option:
      Include Source Pointer in Archive
    • If your new track will use another DTR then assemble the SCs with the option:
      Include Modifiable Sources in Archive (More information on software component assembly can be found in http://help.sap.com/saphelp_nw70/helpdata/en/46/708a9df11b0e9ce10000000a155369/frameset.htm )
  • Import the assembled SCs into the new track
  • Resolve the conflicts caused by your modifications/enhancements

  With a new track your active version will be the version from your old track. 

One Example:

Let’s assume you have CRM 6.0 and you want to upgrade to CRM 7.0. We also assume your CRM 6.0 is in the track CRM60P. In that case you have to do the following:

• Create the track with your target version

• Your CRM60P Track would look like this before the upgrade:

• Create a new Track for 7.0. That track might look like this after creation:

• Do not forget to exclude all SAP Archives
• Exclude dependencies from deployment
  • Click on the button “Filter” and select in the filter the selection box entry “All Software Components” or “Required Software Components”

• Set the “Exclude from Deployment” flag on all dependent SCs
• Switch back the filter to “Developed Software Components”
• Click again on Filter to hide the filter entries again
• Prepare the target version track
  • Go to your track with your current application and find out the used version
  • Go to your CMS, tab System State
  • Select one of the Components you want to import later
• Click on Details
• In the pop up you will see the Support Package Number and the Patch Level
  • Take the unmodified SAP archives in exact the same version used by your current application and import it into the new created track
  • Import the SAP version of the software components into the new track
  • The track might have conflicts caused by SAP. Resolve these conflicts as described in note 1672262.
• Finish the upgrade.
  • Go to your old track and assemble your software components depending if your new track will use the same Design Time Repository (DTR) or not.
    • If your new track will use the same DTR then assemble the SCs with the option:Include Source Pointer in Archive
    • If your new track will use another DTR then assemble the SCs with the option:Include Modifiable Sources in Archive

• Import the assembled SCs into the new track
• Resolve the conflicts caused by your modifications/enhancements.

The upgrade is finish after the steps above.

Content provided by Iwan Zarembo.