Noteworthy Information about Migration

There are several changes which might have an impact when you run applications on the new releases:

• There is a new URL scheme for Web Dynpro applications in place (…/webdynpro/resources/<dc-vendor>/<dc-name>/<app-name> instead of …/webdynpro/dispatcher/<dc-vendor>/<dc-name>/<app-name>). However, the old URL scheme still works for compatibility reasons. Furthermore, resource paths have changed in order to provide better support for the Web module.
  • Applications which use the WDURLGenerator API as required will continue to get the correct URLs.
  • Applications which create URLs using a custom written algorithm will need to be checked for compatibility as they might experience problems in certain scenarios.
• At the end of a controller's lifecycle, context elements are now cleaned up earlier. This might lead to runtime exceptions if elements of the context are accessed after they have become invalid. Such accesses have been an error already in 7.0, but could have gone unnoticed.
• Due to security reasons, the input data is checked more thoroughly by the server starting with 7.11. This might lead to runtime exceptions if an application relies on the more relaxed behavior of the framework in 7.0.
• In 7.20 additional security improvements have been applied which might break existing test tools,for example for load tests.
• Starting with 7.1, the Unified Rendering (UR) library called "Lightspeed" is used as the default UI rendering library. UR Classic is no longer available from 7.2 onwards. This especially has an impact on test tools relying on the used HTML.
• Using Java native types instead of the DDIC wrapper types for a view element's primary property makes the corresponding view element read only. Using the DDIC wrapper was mandatory in 7.0 but had not been enforced.
• Input fields with a numeric type show a calculator for value help starting in 7.11.
• Starting from 7.10, the lead selection change behavior in tables has slightly changed for components using the old component model. Previously, the lead selection was directly changed when you selected a table row. Now, the lead selection is only changed after the next server roundtrip. This implies that in a master-detail scenario, the detail form/table still shows the data for the old lead selection, while in the master table the data for the new row is edited. For components using the new component model, there are even more changes to the lead selection handling.
• There is a new table column concept. It is important not to mix new and old columns within the same table. Manual migration of the columns to the new concept is optional.
• There is a new context menu concept. This might interfere with the old context menus specifically available for some view elements (for example, if only one of the two context menus is shown at a time). So replacing the old context menus by the new concept might have advantages.
• There are several new ways of integrating Web Dynpro applications into the SAP Enterprise Portal. See the SAP Enterprise Portal documentation and note 1383062 (especially the attachment).

Migrating Web Dynpro components to the new component model will have the following side effects:

• It is an irreversible process: There is no way back once the Web Dynpro component has been migrated to the new programming model, you cannot later revert to the original programming model.
• Behavioral changes: The migration process might slightly change how the Web Dynpro component behaves at runtime. Therefore you will need to test your component's functionality extensively after the migration. This is particularly relevant for reusable components, especially if they are stored in separate Web Dynpro Development Components.
• Migrate those components that are heavily used by other components with extreme care!
• Hook method invocation changes: For components with the new programming model the hook methods doBeforeNavigation() and doPostProcessing() will only be called when the round-trip triggers an action event handler. Prior to the migration, these hook methods were always called. This may affect the runtime behaviour of your component and cannot be checked by the migration tool.
• Context specific changes: Do not invoke IWDNode.bind() for context nodes that have a supply function in the new programming model, calling the bind() method for a context node with a supply function will cause a runtime exception. This may affect the runtime behaviour of your component and cannot be checked by the migration tool.
• Table UI element changes: The Table UI element has a slightly different runtime behaviour for the new programming model. When the user clicks on a button within a row that is not selected, the lead selection will only change if the table is in read-only mode. This may affect the runtime behaviour of your component and cannot be checked by the migration tool.
• For the Calendar UI element, the new aggregation WeekDayPattern takes precedence over the old RecurrenceDayPattern. If aggregation WorkingTimes contains entries, they are considered for rendering the UI element.
• For the DateNavigator, the new property legendID takes precedence over the old aggregation Legend. Starting with 7.10, the property legendID has to be specified instead of using aggregation Legend.
• New naming convention for UI element IDs: In the new programming model, the programmatic creation of UI element IDs that start with '_' (underscore) is no longer permitted. Doing so will cause a runtime exception. This may affect the runtime behaviour of your component and cannot be checked by the migration tool.

The following table contains deprecated UI element features. Consider them when migrating Web Dynpro Components or creating new Web Dynpro Components. When a Web Dynpro Component is created, it gets the current version of the used IDE. If a Web Dynpro Component is migrated to the new component model, its version is changed to the then current version of the used IDE.

Special care has to be taken for deprecated aggregations. Therefore, they have already been mentioned at the beginning of this section. If a cell in the feature column contains no value, the whole view element is deprecated.