Skip to Content

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.

The beginning

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”/>
</web-site>  

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:

cd <installation_folder>/web-app-server/oc4j/j2ee/home/
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 9.0.4.1.0 (also 10g) that is delivered with an oracle rdbms installation. The application is auto deployed with the OAS 9.0.4.1.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.lang.OutOfMemoryError

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”.

/wp-content/uploads/2008/11/config_brstudio_101085.jpg 

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.

Summary

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.

References

To report this post you need to login first.

1 Comment

You must be Logged on to comment or reply to a post.

  1. Michael Watson
    I must say, i have been very disappointed with the BR*Tools Studio. Like you, I expected that communication to remote databases would be done using JDBC, which surely would have made things a lot less complicated.

    I was really looking forward to using BR*Tools Studio for central administration of our databases, but it doesn’t look like we’ll be able to do it. It took a good 4 hours to get the tool running at all – even then I was only able to get it running by severely hacking the configuration files. But, after finally getting it started, I wasn’t able to establish connections to any of the databases, because its so hard trying to find a tool that will allow me to log in from a Windows box to a Unix box passing through a password. We normally use Putty for our communications, and even though the OSS Note mentioned by you says that Putty is supported, there was absolutely no way to make it work.

    So after a good 10 hours or so of fiddling, I’m giving up on this tool – good luck to anyone who gets it working well.

    (0) 

Leave a Reply