SAP released the SAP BR*Tools studio for oracle databases on 03/11/2008. I was really looking forward to this new webgui and its advantages. So i just downloaded it the same day and started to take a look at it.
At first i read the clearly arranged installation documentation and start my first try of the installation. My test installation system was an AIX 5L system with IBM java 1.4.2 SR7 and the other needed requirements (> BR*Tools 7.00 Patch 34, OC4J 10g or higher). I install it in “Multi-Instance Server Mode”, because of i want to administrate many remote databases with it.
The installation itself
The installation of the SAP BR*Tools studio itself was very easy. It is a guided installation with some necessary definition steps (port for the web application, password for administrator and SSL key store).
After that i installed the newest Oracle Application Server (OC4J standalone), which is a required component to run the SAP BR*Tools studio. I used the OC4J 10.1.3.4.0 which fits to the requirements.
The first start
The start of the application itself is very easy – you just run a shell script and the OC4J was starting – and breaking down.
I thought, that the SSL key store was generated and filled by the installation. But you have to do this by your own with the java-keytool. In my case i don’t need a HTTPS webserver in our LAN, and so i deconfigured the HTTPS and run it with HTTP.
You can change this by editing the https-web-site.xml in the config folder in your installation folder:
<?xml version=”1.0″ standalone=”yes”?>
<web-site port=”8888″ display-name=”SAP BR*Tools Studio”>
<default-web-app application=”global” name=”studio” root=”studio”/>
So i tried to start the OC4J server again, but it failed twice – now with another error message:
Set OC4J administrator’s password (password text will not be displayed as it is entered)
Error initializing server: OC4J administrator’s password is empty.
This error is described in metalinknote #601684.1 and you can fix it by setting the OC4J admin password like that:
java -Doracle.j2ee.home=../home/ -jar jazn.jar -activateadmin <password>
After all this manually configuration and try-outs the OC4J was coming up and you can connect to it on the configured HTTP port, but the application “studio” is not available.
It was really frustrating at this point and i opened a call for this situation. The SAP support points me to the OAS version 188.8.131.52.0 (also 10g) that is delivered with an oracle rdbms installation. The application is auto deployed with the OAS 184.108.40.206.0 and it works. But this is not a practicable solution, because of the middle-tier should be stand alone and have no dependencies to the oracle rdbms binaries.
After the application was running for a while i get many java heap dumps with the following error:
JVMST109: Insufficient space in Javaheap to satisfy allocation request
Java 1.4.2 is supported and you don’t find any recommendations by SAP for the java settings.
Within my other SAP call (OC4J-problem) i get the statement from SAP “Please use rather Java (JDK) from the Oracle Home ($ORACLE_HOME/jdk/bin) instead of IBM Java version.” But in this case it is also required to install a oracle rdbms and you also have dependencies. If you want to run the SAP BR*Tools studio on a completely different server you get in trouble.
The application SAP BR*Tools studio itself
The application itself runs very good and most of the functions are working. After i take a look at the “BR*Tools Studio admin console”, i configured some remote instances and see the field “Remote”.
I ask myself for what this should be, because i hoped that all tasks to remote databases are made via JDBC and SQL*NET – Sapnote 1224432 explains it:
“The remote call is the remote shell command you intend to use to \ connect to a remote database environment. BR*Tools Studio server \ appends all BR*Tools commands it creates to this string to make for a \ fully qualified remote call of the BR*Tools package on the remote host.”
And this is the truth – i finished my configuration and take a look at the tablesapces on the remote database – in the background the following command was executed:
/usr/bin/rsh <HOST> -l <USER> brspace -confirm force -language E -user / -function dbshow….
To be honest this is not what i expected, because this method may work on hosts with the same kind of operation system (for example from Unix to Unix or from Unix to Linux), but if you have a mixed system landscape with Unix, Linux and Windows it is not so easy to implement a passwordless remote access. I have no idea why this is implemented this way – the BR*Tools logic can also be included in BR*Tools Studio and the remote calls can be done via SQL*NET with SYSDBA privileges. Maybe this design was choosen to keep the interoperability with other databases, but this is only a guess.
In our environment this is absolutely not usable in this way.
I really liked the idea of having a central database administration tool and the first screens looks very nice. But with the actual problems, infrastructure design and the implementation for communicating with remote databases, the BR*Tools Studio has no benefit for me.
Please feel free to post your own experiences with BR*Tools Studio.