DTR In Action: Migrating Existing Local Projects into DTR.
We had a set of Web Dynpro iViews that simplified SAP PM transactions. As our development team grew, we needed to migrate from using local Development Components into the SAP Design Time Repository (DTR) to simplify source control and enable interaction with Development Components developed by other teams and team members. We decided on the move for Service Stack 3.
Before there was DTR, we hacked a temporary solution using Visual Source Safe and Local Projects. Our build times were wild and unruly as any update to the Source Safe projects involved building all the projects in Netweaver Developer Studio, exporting all the jar files manually and moving them into the Web Dynpro project’s lib directory. This process was time consuming and error prone. Even worse, the classpaths and projects always needed to be recreated for each developer’s machines, and there was always uncertainty about which files corresponded to which Web Dynpro component.
There was no smart documentation on installing the JDI correctly, so we spent a couple of days trying to get WAS, JDI and hardware backup set up correctly.
The installation is pretty straightforward from the Installation Master CDs, select the JDI option from SAPINST and all the database tables are created automatically. We found that just doing the online/offline install from the SP6 JDI directory did not create the databases correctly, so it is better to install from SP3 CDs and update later.
The SAP documentation was not very clear on how to provide backup for the DTR. In fact, the advice was ‘contact your database administrator’. We set up daily backups of the Oracle database in case of hardware failure. If your company can justify the Oracle Agents, only the tables whose names start with ‘CBS_’ seem to need backup. We considered using the exportworkspace command in the DTR Administration tool, but we found that it was not implemented in Service Stack 3.
The Big Move.
Based on the existing local projects that we had, we decided on a scenario 2 configuration as we were unsure on the stablility and availability of the Change Management Service.
We went into the DTR and created our workspace. We then went into http://hostname:50000/CBSUtils/devconfwiz.jsp to create our development configurations. We made the mistake of not providing Name Server URL in the development configuration jsp file ( after all, it said optional). This came back to bite us in the *** later on when we tried to set up a dictionary DC, it complained that name reservation was not posible.
With our fresh new xml file exported, we launched Netweaver Developer Studio, opened the Development Configuration perspective, imported the xml file and were greeted by a nice friendly ‘not authorized’ error. After banging my head against the wall for a couple of hours, we figured out that for some strange reason, we had to go to http://hostname:50000/dtr with our web browser, login to the prompt, and then our friendly Development Configuration appeared.
So we had a fresh Development Configuration and a local project in hand. All we had to do was to copy and paste the directory structure (src -> src/packages) and we would be done. Or so we thought.
We happily created development components for each of our local java projects and tried to compile them. Ran into a couple of hundred errors warning that the classes did not exist. Trying to add them to the project class path simply did not work. After much digging, we discovered that all our local project dependencies had to be linked through SAPs’ good old public parts mechanism. It took us a while to figure out how to do this correctly, but we were able to define all our project dependencies correctly.
After migrating all our java projects, it was time to migrate the webdynpro project into DCs. We linked all our java projects correctly and added all our external jar files to the lib directory. Compiled. Deployed. ‘ClassNotFoundException’.
Turns out that DCs and not good friends with external jar files. Even worse, the jar files that would be included in the lib directory in a local project were simply not included in the final ear file. After much digging, we found that anything that gets included into a public part for assembly ends up inside a jar file. This means that if you included a jar file inside a public part, it will result in a ear structure that was ear>jar>jar>java class, which ensured that the java class will not be read, ever. We had 20 external jar files in our projects. What to do, what to do!?
After some heavy drinking, we realized that if we decompressed our jar files with winrar and added them into a directory structure, the way Public Parts thinks will simply reconstruct them into the original jar files. So we decompressed all our libraries and created a DC for them. We included all files under a directory and created a public part for it. This meant that we had all our external jars inside our DTR ready to use. Hopefully our good friends at SAP have solved this problem for stack 4.
We finally had our local projects migrated into development components and checked into the DTR. A couple of quick tests and compiles verified that it was indeed the same monster we started with, and all the functionality was intact.
Rollout to all our developers was simple. We simply included the xml file in our network drive and told everyone to use it. It was actually less painful than getting new developers up to date, as the DTR automagically created all the project classpaths and dependencies, which used to take us at least 2 hours to do with the old form.
Overall, it took me one week to set up the WAS, JDI and DTR, create all the workspaces and development configuration needed, figure out the JAR problem, create all public / private part linkages and get all our developers up and running with the DTR. We are still seeing some sporadic hissy fits from the DTR from time to time, but it is a much nicer enviroment that our previous solution.
Tips and Tricks
Instead of creating a new workspace in the DTR and overloading it with activities, create a temporary workspace to take care of the public and private part associations and linkages. Then use the progation list mechanism to move the final migrated workspace into a brand new workspace. This way, the DTR Administrator is not overwhealmed with 300 activities at the beginning of development.
I found that drawing all the project dependencies with pen and paper made the transition into Development Components much easier. Having a nice little diagram associating all the components provided a logical sequence of which projects to convert next.
Sometimes I found that kicking and begging the DTR to wipe away the development configuration just didn’t work. I even tried uninstalling my local WAS, Netweaver Developer Studio and the damn Development configuration was still there, mocking me. After hours of soul searching, I discovered that all the magical files reside in the .dtr and .dtc folders under the Document and Settings directory. Wipe these clean and your development configurations will be gone. (The dtc folder can be changed in the preferences, but the .dtr folder, which holds the key to all evil, will always be under Documents and Settings).
For developers used to local projects, there are many many many many places in Netweaver Developer Studio 2.0.6. that are not nicely integrated and cause errors from undetected modifications to ClassNotFoundExceptions. We found that doing the following minimizes these errors:
- NEVER do create archive from the right-click menu in the WebDynpro screen, instead, do ‘Development Component > Build ‘ and ‘Development Component > Deploy’. What works for local components causes catastrophic errors with DTR DCs. We found that using the local DC commands makes the Jar files in the DTR DCs not show correctly.
- The dialog that allows you to select which DCs to build is not to be trusted. Unselect the ‘build only when necessary checkbox’ and make sure that the webdynpro project is built. We found that if there are warnings in the DC build process, the building of other dependant DCs will stop sporadically.
- Make sure that when you are debugging, you always modify the Web Dynpro files and not the generated .java files. For buggy reasons unknown, the DTR will detect a modification in the Web Dynpro file and ask if you want to check it out, but never on the .java file
- The following options under preferences > Java Developer Infrastructure are lifesavers: ‘automatically ask for logon on startup’ and ‘use java project for dependencies’. The first one forces developers to logon and always be in sync with the DTR, the second ensures that the debuggers behave correctly.
I hope this log has been enjoyable. Happy DTRing!