Web Dynpro for Java 7.31, NWDI 7.4, ESS migrations, EHP4
Why this blog:
This blog is aimed at developers already familiar with versions of Web Dynpro Java 7.0 and Web Dynpro Java 7.31. This helps with how to migrate Web Dynpro ESS WDJ Components from NW 7.0 to NW 7.4 and approach followed. I am putting together below information on ESS migrations as per my understanding and what we followed. I cannot guarantee the correctness of it. Your inputs & suggestions are always welcome. I hope it will help members as a small guide to perform the ESS migrations.
Author: Nutan Sangai
Company: Infosys Ltd
Created on: January 28, 2015
- Keep using the “old” WDJ XSS services by upgrading them. If you are on EHP4 this is your only option
- The upgrade of the Java packages is necessary because 7.3 runs on a newer Java engine (Java 6) compared to older portal installations that ran on Java 1.4 or below. Basically SAP has taken the old XSS Java components and re-compiled them with Java 6 without introducing new functionality. The new re-compiled Java packages for NW 7.3 are called ESS 633, MSS 630, PCUI_GP 633, XSS BP version 1.41, Web Dynpro ABAP (WDA) is called BPERPESSWDA 1.50
- Migration needed for ESS WDJ? – YES
In SAP Net Weaver CE 7.1 and higher there is source code compatibility of Web Dynpro Java applications but not binary compatibility.
This means that the old source code must be imported, re-compiled, and redeployed to the new system.
- We can migrate ESS STD/Custom components to 7.4 using ARFC or ARFC2. SAP recommends to use ARFC2 with NWDS 7.2 onwards.
However ARFC is still supported. Please refer below link how to operate with ARFC
- We need to deploy ESS Java components through NWDS for standard or custom components.
2. System Usage
- R/3 system: EHP4, Migration from NW 7.0 to NW 7.4 SP05, nwds-extsoa-7.3-EHP1-SP10-PAT0003-win32; ESS 633, PCUI_GP 633,
XSS BP version 1.41
- We used ARFC, Grey ESS WD components (WD component not migrated to 7.4) Deployed on NW7.4 without any error or issues
- Please refer my previous blog for prerequisites for WD components migration from 7.0 to 7.4
- Move ESS DC from NW 7.0 to NW 7.4 using NWDS 7.31
3. Support Logic
- We used ARFC and deployed ESS WD components (non-migrated) gray on NW7.4 without any error or issues. We followed the component dependencies by default.
- COD plays an important role when we consider any component for migration. ESS components like ess/us/bank, ess/us/addr does not have COD available and we can use/deploy the Standard ESS components or ESS components with little
customization on NW 7.4 version without any errors.
- ESS components are complex in terms of RFC uses as it contains dependency on other ESS components. If we decide on component
migration, we need to follow complex migration process considering dependent components, code correction, number of RFC – model migration etc.
- RFC Models have been re-used in number of ESS components which we might not aware and cause unknown issues
- As these are SAP’s standard components, we may not aware what problems and fixes should be applied whencomponents are migrated as there are no documentations on the same.
- Although ESS components without migration are supported on NW 7.4 version with all EHPs. We recently upgraded EHP4 to EHP7 and WDJ still supported with old BP is use.
4. Steps to be performed
- Please refer my previous blog for steps to be performed for WD components migration from 7.0 to 7.4. We follow the same steps with ESS track and create project with ESS required DCs for modification or migration.
- For some ESS DCs like ess/us/bank etc. automatic migration wizard opens. For some ESS DCs like ess/us/addr, automatic migration wizard does not open and you have to run it manually.
- Once automatic migration wizard completes, you can perform the modifications in ESS DCs like View, components etc.
- We have added custom field in ess/us/bank DC View of type “Personal email id”. We added this custom field at backend RFC. We reimported RFC to reflect the field on WD JAVA code. We did context modifications throughout the ess/us/bank as well as dependent DC like ess/per. We did code modifications to support personal id logic in code.
- We skipped ess/us/bank development component manual migration with “Migrate component” option along with cheat sheet migration depending upon the complexity of process and time unavailability to do so.
- Saved the corrections & modifications. We then built the WD component and deployed all the related components to portal server.
- We did successful deployment with custom field shown and working perfectly on portal.
- We must do portal server restart once ESS application deployed with any RFC reimport happened.
- We should have RFC destinations for model data & meta data configured to work ESS application without error as per required for ARFC.
- We can deploy the ESS standard components in a similar way.