This blog contains experience gained over the years of implementing (and de-implementing) large scale IT applications/software.

Tag: Telnet

Patching SAP LaMa 3.0 to SP17

On the 9th of November 2020 SAP released support package 17 of SAP Landscape Management 3.0.
If you already run SAP LaMa 3.0 SP11 and above, then you can quite easily patch to SP17 by installing the 3 SCA files into your existing Netweaver 7.5 Java stack.

However, things are never so easy, as I will show.

Required Netweaver Stack

Before you can patch SAP LaMa you must always read the support package release note.
For SP17, it is SAP note 2908399 in component “BC-VCM-LVM”.

In the SAP note, it states that a minimum of Netweaver 7.5 SP15 is required for LaMa 3.0 SP17, with a recommendation of Netweaver 7.5 SP17.

That’s good for me, I have Netweaver 7.5 SP16, I should be good to patch with no issues. Right?
No, after applying the 3 SCA files for LaMa 3.0 SP17, the Netweaver stack starts and stops successfully, but when I try to log into LaMa I see the message on the screen “SAP Landscape Management is loading, please wait…“, but it does not progress any further.
When accessing Netweaver Administrator, it works perfectly.

The Error

For the sake of clarity, I also took a look at the Java stack log viewer and I could see an error:

“error binding ExecuteCustom/RMI …“, which didn’t mean a lot to me and produced no results in SAP notes.

The error record details mentioned: “com.sap.tc.vcm.engine.operation.handler.customop.CustomRMIOperationHandler.CustomRMIOperationProvider” in application: “sap.com/tc~vcm~engine~app“.

None of the above produced any SAP notes that looked vaguely related.

Let Groundhog Day Commence

I’ve been working with LVM and LaMa for a while now. When I actually started looking how long, I was surprised to see my knowledge went back to 2014.
I was sure at the back of my mind there was a slight recollection of this same issue.

I started searching the SAP notes and with this recollection of a problem in mind, I decided to search for the exact message that was staring at me on the LaMa post-login screen.
It was a direct hit on the SAP note search.
SAP note 2662354 “SAP Landscape Management is loading, please wait…” is an old SAP note for SAP LaMa 3.0 SP07, back in 2018.
The SAP note described the exact same symptoms, and the failure to progress into LaMa past the loading screen.

Inside SAP note 2662354, it referenced the support package release note 2542159 “SAP Landscape Management 3.0 SP07” which states: “Install at least SAP NetWeaver Application Server 7.5 for Java Support Package 11. If you use a lower Support Package, you have to update the SAPUI5 component“.

It was all coming back to me now. In the past, to apply LaMa 3.0 SP07, you needed to patch the NW stack, or an alternative was to simply apply a higher SAPUI5 software component (SCA).

SAP UI5 – Skipping Ahead

Once I understood the potential solution (apply a later SAPUI5 SCA), I needed to validate what I had already validated in the past.
Was it still supported to apply a later SAPUI5 software component to a SAP Netweaver 7.5 Java stack?

In SAP Note 2541677 “How to switch SAPUI5 versions in NW Java 7.50 SP07 and higher SPs“, it confirms that from SAPUI5 7.5 SP07, more than one version of the UI5 library will be included. The SCA effectively becomes cumulative as each SAPUI5 version is released.

More importantly the note says: “SAP recommends that you always implement the latest released Support Package. You are save to apply UI5 patches of higher SPs to your systems, as there as no direct dependencies.“.

That is exactly the confirmation I was looking for.

Patching SAPUI5

My Netweaver stack level is SP16. The recommended Netweaver stack level (based on that LaMa SP17 note) is SP17.
That left two options which could fix the problem:

  • The latest SCA patch level for SAPUI5 7.5 SP16
    or
  • The latest SCA patch level for SAPUI5 7.5 SP17 (taken from the NW 7.5 SP17 stack).

I decided that I would take the “slowly, slowly” approach and patch to the latest SAPUI5 7.5 SP16 patch first.
After patching and restarting the Netweaver stack, I still had the exact same problem.

Moving onto the second option, I applied the latest SAPUI5 7.5 SP17 patch level (UISAPUI5JAVA17P_18-80000708.SCA).
After patching and restarting the Netweaver stack, the issue was finally fixed!

As of Nov 11th, there is still no official documentation for this process.

Improving the Patching Efficiency

During the above problem resolution, I did not use SUM to apply the patches.
When patching SAP LaMa we are talking (usually) of only 3 software component archives.
For this reason, I prefer to patch using the Telnet deployment method.

As the Linux <sid>adm user on the JPAS host, log into the NW Telnet server port: 

telnet 127.0.0.1 5##08

[enter administrator user/pw]

deploy /<path-to>/<SCA-file>

The Telnet deployment order for SP17 is:

  • VCMCR4E17_0-70001063.SCA
  • VCM17_0-70001062.SCA
  • VCM_ENT17_0-70001064.SCA
  • [the SAPUI5 7.5 SP17 patch – if you are on NW SP16]

Once deployed, the NW stack needs a full restart.

Summary

  • Patching SAP LaMa should be simple, sometimes it has issues.
  • LaMa depends on the SAPUI5 component version.
  • You may need to patch SAPUI5 to make LaMa work.
  • SAPUI5 support packages include prior versions (after 7.5 SP07).
  • SAP permits you to use a higher SP of SAPUI5 compared to the NW stack SP level.
  • It is possible to use Telnet to deploy the patches, providing you follow the correct order of deployment.
Useful Links
  • SAP Note 2908399 “SAP Landscape Management 3.0 SP17” v7
  • SAP Note 2662354 “SAP Landscape Management is loading, please wait…” v1
  • SAP Note 2541677 “How to switch SAPUI5 versions in NW Java 7.50 SP07 and higher SPs” v7
  • SAP Note 2542159 “SAP Landscape Management 3.0 SP07” v6

You may also be interested in:

Deploying SAP Portal JDBC Adapter SDA using Telnet

Once you’ve built a new com.sap.aii.adapter.lib.sda file ready for deployment into the SAP AS Java, you have two options for deployment in a NW 731 system:
– Deploy using SUM
– Deploy using Telnet

The SUM method can be arduous, taking anywhere from 20 minutes to over a couple of hours if you don’t already have the software.
Using Telnet is the lowest common denominator, uses existing software already installed and can take as little as 5-10 minutes.
As the <sid>adm user on the AS Java application server, use Telnet (must be installed on the Unix, Linux or Windows O/S, to perform the deployment:

sidadm> telnet 127.0.0.1 5<##>08
Administrator
<pw>

Once connected, you can query the version of the SDA: 

explore name=com.sap.aii.adapter.lib

Development Component:
name: [com.sap.aii.adapter.lib], vendor: [sap.com], location: [SAP AG], version: [7.3113.20140808110905.0000], software type: [primary-library], csn component: [BC-XI-CON-AFW], dependencies: [[name: ‘engine.j2ee14.facade’, vendor: ‘sap.com’]], archive type: [DC]

Then deploy your new SDA file:

deploy /tmp/sap.com_com.sap.aii.adapter.lib  on_deploy_error=stop version_rule=all

Notice that you are disconnected from Telnet at this point.
You should wait around 5-10mins, then re-connect into Telnet as Administrator, then run get_result:

> get_result
The status of the deployed SDUs is Success.
Additional information:

[sdu id: [sap.com_com.sap.aii.adapter.lib]
sdu file path:
/usr/sap/<SID>/J##/j2ee/cluster/server1/temp/tc~bl~deploy_controller/archives/124/1416245030759972000/com.sap.aii.adapter.lib.sda]
version status: [SAME]
deployment status: [Success]
description: []

That’s it.

Network Port Test Using SAP NIPING

Some companies have additional security policies that remove the Telnet application from the local desktop PCs.
This can prove difficult for SAP BASIS people trying to test if a specific network port is reachable, since Telnet is a perfect way of testing if a server port is accessible, or being blocked by a firewall.
Instead, you can use the NIPING tool (Network Interface Ping) supplied with the SAP Frontend installation on the desktop PC.

Check if you have NIPING.exe, it should exist in the default install location: “C:Program FilesSAPFrontEndSAPgui”.

You have to call NIPING from a command prompt:

C:> cd C:Program FilesSAPFrontEndSAPgui

There are two command line options that are useful when calling NIPING.
The command line option “-R” tells NIPING to attempt a RAW TCP connection.
Option “-P” specifies that NIPING should option slightly more detail.

If you need to test if a network port is available, you need to use the RAW option.
You don’t care what transport layer protocol is required (SMTP, HTTP, Telnet, SSH), you just want it to try and open a bare TCP connection to the specified port and see what happens.

To use NIPING with the RAW option:

> niping -c -H <dest host>  -S <dest port>  -R  -P

You will get some fairly detailed output.
What you are looking for is a return code (RC) of “-6” and “ERROR connection to partner ‘xxx.xxx.xxx.xxx:pppp’ broken“.

The RC of “-6” indicates that NIPING was able to open the TCP connection (NIPCONNECT) successfully, but it was not able to receive (NILREAD)  because the server closed the connection when we didn’t send any information (it was a raw connection).

If you receive an RC of “-10” and “ERROR partner xxx.xxx.xxx.xxx:pppp not reached” this indicates that NIPING was not able to even establish a basic TCP connection (NIPCONNECT) to the server host and port.
You may not have an network route to the server, the server IP may be invalid, the port may not be listening on the server, a firewall may be blocking you and many other reasons.

If you are simply trying to connect to a known SAP system dispatcher port (for SAP GUI connections), then using NIPING without the RAW option will perform an RFC connection to the SAP system dispatcher, if possible:

> niping -c -H <dest host>  -S 32<SAP_sys_id>

When you use NIPING without the RAW option, it will return success (“Connect to server o.k.“) if it can successfully connect to the SAP system dispatcher.  It will always complain about “bytes_written <> bytes_read“, so ignore this error.

You should note that connecting to the SAP ABAP message server (36xx) will return a “ERROR connection to partner xxx.xxx.xxx.xxx:pppp broken” and RC “-6” (just like a RAW connection) if it was successful.
The reason is that this is not a straight RFC connection that supports NIPING.  It’s meant to hand-off to a specific dispatcher or other tasks, but not ping.