Basis and others: October 2021

Niping network diagnosis SAP Note 500235

Basis consultant often feels stuck in a situation when it come to performance issues where user or factory located far away from the central server of the SAP, for instance:-

SAP ECC EHP7 server located in New Zealand DC ( Server)

While user is located in New York Office ( User)

A factory located in France. (Factory)

Basic consultant often blinded by the fact that to look at connectivity and QOS (SAP Network dedicated throughout the corporate network which sometimes termed as quality of service)

Now when P1 raised by the user saying SAP is slow for them, the first thing support will look at are system performance, dev_traces files for any hints, abap dump if its ever generated by users and etc . BUT never the thought comes most of the times to look at network quality.

This is the reason why SAP introduced their own version of ping test which is called NIPING. while niping test is often associated when user connects to the central system through SAProuter.

NIPING is similar to PING and the whole idea is to check if there's any latency in comparison for the particular user connecting to SAP server located remotely.

There are few ways in utilizing NIPING as below

1. Measuring RTT

niping -c -H <nipingsvr> -B 1 -L 100
(The buffersize of 1 may cause an error in other version of niping. If yes please use niping -c -H <nipingsvr> -B 20 -L 100 )

Some examples in using Niping

2. Long LAN stability test:

niping -c -H <nipingsvr> -B 10000 -D 100 -L 360000

The uses 100000 bytes per second of bandwidth (about 10% of a 10 mbps Ethernet) and will last 10 hours as how the parameter works.

3. Long WAN test (idle timeouts):

niping -c -H <nipingsvr> -P -D 3600000

Every hour, this test starts a TCP connection and delivers a test packet (delay of 3600000ms). It lasts for ten hours. The purpose is to see if a "idle timeout" interrupts the TCP connection.

4. Short throughput/stability test:

niping -c -H <nipingsvr> -B 1000000 -L 100

Connection is tested with 100 MB of data as quickly as possible. This should take roughly 10 seconds on a 100 Mbps Ethernet connection.

Maintenance Planner Stack. XML - Please leave comments

I notice that many might be a expert in planning your xml stacks while those working in operations or handking SAP day to day operation might not even tasted in creating xml stacks ever in their lifes.

I hope those you come by this this particular blogs can share in the comments atleast of some topics related to creation of xml stacks, purpose for, why the intention and etc.

Generally the evolution of Stacks.xml started with making installation and upgrade media available through secure network instead previously it was distributed via disc, CD and other media ( that was the way back then).

The last time around we used to receive CD's from SAP for the collection of product that we were using. After which we safeguard those CD's in a tight locker for security and safety purposes.

As time passes by when internet became more violantly available, SAP came up with loading these installation CD's through website, for me it was interesting, eventough ordering CD was easy by just raising a ticket but getting it online was even better.

Then i knew the comes SAP download Manager where you can park all you downloads and if you get ever intererupted due to network failure, the activity resumes back after and the downloads are intact with the use of SAP download manager.

Its was then SAP start introducing or maybe introduced much earlier, just that i might have realized about Solution manager t-code MOPZ ( Maintenance optimer ) this is used to download your stacks.

To cut it short now through SAP LaunchPad -> SAP has Maintenance planner . Now this is where it get more simpler for integrator, installers, implementers, compared to previously it requires tremendous effort navigatin through MOPZ.

For those whom are experts, maybe share our ideas, how you use this day to day basis, thanks.