Using Google Chrome?

Download my
free Chrome Extension, Power Notes Searcher, to make searching for and evaluating SAP notes, much easier.

Thursday, October 30, 2014

Finding Your SAP F&R Version

The Forecasting & Replenishment offering from SAP runs on SAP SCM.
SAP originally bought the F&R binary calculation engine from a Swiss company called SAF.  This was integrated to the SCM platform and is called through an RFC connection.

If you're planning an upgrade you need to easily identify which version you're running.

There are two areas to check:
- The SAP SCM version.
- The SAF (FRP) binary version.

Check in SPAM (or in SAP GUI, System -> Status -> Component Version) for the SAP SCM Server version.

Note that:
SCM 7.02 (EHP 2) = F&R 5.2.
SCM 7.01 (EHP 1) = F&R 5.1.

Checking the SAF binary must be done at the operating system level.
The usual location is either “/usr/sap/<SID>/SYS/global/frp/bin" or "/usr/sap/<SID>/FRP/bin".

As the <sid>adm user simply call the "safcnfg" binary with the "-version" command line option:

SAP F&R SAF binary version  

See SAP note 1487615 for details on where to find FRP binary patches.

Finally, you should note that SAP SCM is itself a Business Suite software package like SAP ERP.  Therefore, it is not classed as a HUB or Sidecar landscape pattern, but instead, a source business system.  This means that there is no real dependency link to the SAP ERP version (providing you're on the same technology platform level e.g. 7.31). 
You do need to consider that the interface from ERP to F&R may need some notes applying, some of which may be better implemented through an SPS upgrade instead of notes upon notes. 

See application component SCM-FRE-ERP.

Thursday, October 23, 2014

SAP FRP Data Environment Locations

The locations on disk where the SAP FRP data environments are stored, are administered through transaction /FRE/FRP_ADMIN.

However, if you don't have authorisation for this transaction, you can also check the table "/fre/frpmid_srv" (a client dependent table).

Friday, October 17, 2014

SAP NW 7.31 Java - HTTP Tracing

Scenario:  You would like to trace a HTTP connection to a Netweaver 7.31 Java stack.

Prior to NW 7.31 you would have enabled tracing in either the old Java Administrative Tool, or newer Netweaver Administrator by setting the "enable" flag for tracing parameters of the HTTPProvider dispatcher service (see my previous blog article here).

Since Netweaver 7.31, the Java stack now includes an ICM (Internet Communication Manager) which is the main access point to which HTTP communications are routed to the Java server nodes.
Therefore, tracing in NW 7.31 Java is actually more like the ABAP stack tracing, because you simply increase the trace level in the ICM and then check the dev_icm trace file.

So the next question is, how do you access the ICM to increase the trace level in a Java stack?
Well this can be performed with the help of the SAPMC (only one "M" and not to be confused with SAP MMC for Windows).
The SAPMC was introduced in later NW 7.0 patches and is part of the sapstartsrv service.
The sapstartsrv actually listens on TCP port 5<##>13.  So if you have access through your firewall, navigate to http://<app server>:5<##>13   and the the Java based applet will start up (note that you'll need Java 1.4 or above on your PC).

Once loaded, you can see the SAP MC and expand the "AS Java" branch to locate the "Process Table" item:

SAP MC management console

From the "Process Table" you should be able to right click the ICM (on the right) and increment the trace level:

SAP MC increase ICM trace level

The trace level is dynamically increased.
To see the trace file, right click again and select "Show Developer Trace":

SAP MC ICM display trace

You can always see the current trace level by right clicking the ICM and selecting "Parameters...", or actually right clicking the ICM node further up the tree and selecting "Parameters...":

SAP MC show ICM parameters

The current trace level is shown as the "rdisp/TRACE" parameter value on the Dispatcher tab:


Again, right clicking the actual ICM node in the tree gives you direct access to the ICM management web page:

MWSnap106 2014-07-23, 09_39_44

From the ICM management page, you can also see the current trace level:

ICM Manager Monitor

Good luck with your tracing.

Sunday, October 05, 2014

Netgear ReadyNAS & DynDNS Replacement

With the demise of free DNS services from companies such as DynDNS, I was left with no free method of reliably accessing my Netgear ReadyNAS via the internet.

Before these free services closed down, my ReadyNAS was configured to automatically update it's IP address to the DynDNS service website, which allowed me to use a DynDNS provided host address (e.g. to access the ReadyNAS no matter what it's IP address was changed to by my home ISP provider.

When the free service eventually stopped, I decided that I didn't want to pay for such a small service offering, so I wrote a small script to perform the same sort of service.
The script simply checks my current ISP assigned IP address and compares it to the previous run of the script.  If the IP address has changed between checked, the script sends an email to my email account, which I can then use to access the device by directly entering the IP address into my web browser.

It's not neat, but it works.
Here's how I did it.

What you'll need:
- Root access to your ReadyNAS (you need the SSH addon installed).
- Configure email alerting on your ReadyNAS (do this in FrontView by giving it access to your email provider e.g.

Step 1 - Create the script.

As the root user connected to your ReadyNAS via SSH, use vi to create a small script in the home directory of the root user:

# cd $HOME
# vi check_ip_address

#  Get IP address and mail it to us.
#  Place this script in $HOME/root
#  Call it from crontab.
#-------------------------------------------------------- user="ReadyNAS"
email_from=$(grep '^from' /etc/msmtprc | cut -f2 -d' ')
email_addr=`grep email /etc/frontview/alert.conf | awk -F '!!' '{ print $2 }' | awk -F ',' '{ print $1 " " $2 " " $3 }'`

subject="IP Address Changed" newfile=/tmp/myip.html

# Call a generic site to get our IP.
wget --no-cookies --no-cache --user-agent="Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2049.0 Safari/537.36" --no-verbose --output-document=/tmp/myip.html

# Read output.
myipnew=`awk -F "tt>" '{ if($2 ~/\./){ sub(/<\//,"",$2); print $2} }' $newfile`
myipold=`cat $oldfile 2>&1`
if [ "$myipnew" != "$myipold" ]; then
  # IP is different to last, so save it and mail it.
  echo "$myipnew" > $oldfile
  mesg="New IP Address: $myipnew"   headers="From: $email_from\nTo: $email_addr\n"
  full_content="${headers}Subject: ${subject}\n${content}\n\n$mesg"
  echo -e "$full_content" | /usr/sbin/sendmail -B8BITMIME -f $email_from $email_addr &> /dev/null
  echo "RC: $?"

Set permissions on the script:

# chmod 750 check_ip_address

Step 2 - Schedule the Script.

Add the script to a cron schedule:

# export EDITOR=vi
# crontab -e
30 09 * * * /root/check_ip_address
30 14 * * * /root/check_ip_address

The above schedules the script to run at 09:30am every day, and again at 14:30.
That's it!