JAVA stacks for SAP NetWeaver AS are not my favorite thing in the world. There are a lot of tools and transactions from ABAP stacks that I really miss when I’m working with a JAVA stack. Despite of this I must admit that patching a JAVA stack is becoming easier during the last years. For example, for using the Software Update Manager with an ABAP stack it is necessary to have a XML file in order to patch the system. In the case of a JAVA stack you only need to download the files and select the directory during the SUM execution. Easy right? Otherwise you can go really crazy and try to patch a JAVA stack using NWDI. You will have lots of fun, I promise!
A short history of patching JAVA stacks
Anyway, for you freshers that don’t know what I’m talking about here it’s a small explanation about patching JAVA stacks during the last years:
- Long time ago there was a thing named Software Deployment Manager (SDM). You could use the SDM to deploy/undeploy SCA files individually and to check which software components where installed within the JAVA system. There is a small guide about SDM right here.
- About the same time there was another thing named Java Support Package Manager (JSPM) which was an interface between the user and the SDM. The JSPM has a lot more features than the SDM and it was the standard tool for patching a JAVA NW. With the JSPM you could patch a full SPS, a single SP, install new software components, etc. There are plenty of guides about JSPM on the Internet since it was the most popular tool on those days.
- About some years ago SAP release the Software Update Manager (SUM) and they decided that both JSPM and SDM were not worthy of being use to patching a Java system. The SUM had a lot of advances for patching SAP system and even if the initial versions had a lot of problems there was a big improvement compared with SDM and JSPM.
About this time SAP thought it was a good idea to use the Solution Manager MoPZ in order to calculate the Support Package stack. This was a good idea in the beginning but there was a small problem: When calculating the SP stack the latest patches for the software components were not included in the stack.
Patch? What is a patch?
If you worked with Java stacks you’ll see that the software components have a patch level compare with the software components of ABAP stacks:
- On ABAP stacks SAP releases the new Support Package for a software component. When a new issue is discovered and fixed SAP releases a SAP note that you can implement with your system. When a lot of notes has been released there are grouped on a Support Package for that component. This is a really simple explanation, I know I’m missing a lot of stuff here.
- On JAVA stacks SAP does almost the same. They release Support Packages for a software component. The difference here is that is not possible to import a SAP note on a JAVA stack using the transaction SNOTE because there is no SNOTE on JAVA stacks. In this case SAP releases a patch for a specific Support Package when they find and fix an issue.
The patch number can be find in the Components Info inside the NWA on newer versions:
In this case the patch level for the SP09 of the FRAMEWORK component would be patch 1. On the contrary, the patch for the SP09 of the ESP_FRAMEWORK would be the patch 1.
What was the problem?
When calculating the stack for updating a JAVA system the SolMan MoPZ didn’t include the patches for each Support Package so you updated the system to the Patch 0. If SAP released a new patch for fixing an issue that patch wasn’t imported when patching the system… Fortunately all this changed when SAP released the Maintenance Planner. Now it is possible to add the latest patches to the stack file:
This saves a lot of time when patching a JAVA stack but… What would happen if I need to patch only one software component? For example the issue described on SAP Note 2297508 – The content of uploaded file is corrupted is fixed applying a patch for the ENGINEAPI component. When patching a software component you should check the dependencies of the new patch, never patch a software component without patching the whole dependencies. For calculating the dependencies for a patch you have two options:
- Check manually the dependencies within the Support Portal which usually takes a lot of time.
- Use the SAP NW Java Support Tool 1.0 which makes everything easier.
A helpful and unknown tool
After all this years I’m still surprised that most of the people doesn’t know about this tool. The SAP NW Java Support Tool is a really useful and powerful tool when working with JAVA stacks. It can be used to gather logs, traces, system information, record screen when reproduce an issue, etc. It’s kind of a holy grail for Basis consultants when working with JAVA NW. If we want to calculate the dependencies of a patch for a software component we can do the following steps:
- Open the application and connect to your JAVA system. You will need the sidadm user from the operating system:
- Choose the option SC Patch Tools in the main window:
- Write your OSS user and its password:
- After this it will take a while so the application will connect to the Support Portal and download the information:
- Choose the software component you want to update within the list:
- The dependencies will be calculated and shown after some minutes. On the list you can choose the software components, the patch level and add them to the download basket:
- After this you will only have to download the SCA files from the download basket, upload them to a directory in the server and patch the system using the Software Update Manager.
As you can see it’s really easy to calculate and download the dependencies when patching a software component. I’ll write in the future a little bit more about the SAP NW Java Support Tool and all the possibilities we have when using the tool.