The other day I wrote about my experiences while trying to repair my ABAP Netweaver Sneak Preview installation after a computer rename. Today I wanted to write about another “opportunity to learn” that I encountered while trying to write a Java WebDynpro application on my local systems.
My goal was to create a Java WebDynpro application that ran on my local Netweaver installation that could access data from the local ABAP sneak preview system. I was using Adaptive RFC to make the calls from Java to ABAP. For those of you who have worked with Adaptive RFC, you know that there are several setup steps that must be done.
First you have use the SLD to store all your system information. Adaptive RFC will only connect to a system that is setup in the SLD. So my first goal was to get my ABAP Sneak Preview system installed into my Java system’s SLD.
I had already gone through the SLD’s Post-Installation setup guide and I had the Local Java system information populating just fine. I figured all that I had to do was go into transaction RZ70 inside the ABAP system and send my information over to the SLD.
On my first try, the call to the SLD failed. I was getting Gateway registration errors. I even went directly to SM59 and tried just testing the SLD RFC destination (SLD_NUC) and I continued to get gateway errors. After looking in the gateway logs (transaction SMGW), I found entries where it looked like the system was trying to connect to the gateway on a hostname that had been truncated. I just recently corrected my problems following the computer rename, so this seemed rather ironic. My computer name was very long: 13 characters. I incorrectly assumed that this truncation was the problem and that gateway communications were failing because my hostname was too long. Later I would find out the truth was quite different and that this truncation was probably just the harmless shorting of a variable within an error message.
I thought that I had found a problem that I couldn’t work around. After all I couldn’t change my computer name to be shorter. I thought I would just have to work around the problem by manually entering my ABAP system information into the SLD.
With my ABAP system information finally resting comfortably in my SLD, I was ready to finish the Adaptive RFC setup for my WebDynpro application. Inside the WebDynpro Content Administrator, each deployed component is shown. Inside the maintenance for each component, you should already see any Adaptive RFC destinations that you created in your application.
Image 1 – WebDynpro Content Administrator
I started by setting up my Model Data Destination. This Adaptive RFC type allows you choose between Load-balanced and single server connections. I am running locally with the sneak preview, so I assumed there was no real reason to go with the load balanced connection. I finished the setup, which grabbed the rest of the connection information from the SLD. The new RFC destination tested fine, so I assumed that my ABAP system was setup correctly.
Image 2 – Application Data RFC Setup
Next I needed to setup the second RFC destination. For ever Adaptive RFC, there are two destinations. The first one I setup is used to make the actual model method calls. This next one is used to retrieve Dictionary Meta Data. However when I reached the screen for the connection type, I learned that the Meta Data connection only support Logon Balanced connections.
Image 3 – Meta Data RFC Setup
I had gone into the ABAP system in transaction SMLG and setup some logon groups. I had even remembered to enter them manually into the SLD information for the ABAP systems. However when I finished the Adaptive RFC setup and did a test, I received a connection failure. Little did I know that I had actually hit upon the same problem that caused my SLD connection to originally fail as well.
The Message Server
I returned to transaction SMLG to try and determine the cause of my problem. Everything appeared to be setup correctly. However when I viewed the Load Distribution for the logon groups, I found it strange that each logon group’s Current Logon Instance was listed as initial. It appeared as though the load statistics were not being populated into the Message Server.
Turning to my trusty friend, the note search on OSS, I soon found a note that gave some background on how this information is populated. According to note 26317, there is a program that should be running every 5 minutes or with every 5th SAPGui logon to populate this information. Could the answer to all my problems really be as simple as logging on 5 times! Sure enough, after logging on 5 times my message server load information now showed up in SMLG.
The root cause of the problem has to do with the instance profile parameter rdisp/autoabaptime. This is the parameter that controls how often the program RSRZLLG0 runs to populate this information. The parameter had a value in my sneak preview system of 0. There is a special check in RSRZLLG0 for value of <= 0. If the program finds this value, it assumes an upgrade is process and doesn’t populate the load statistics. This is also why even if you submit RSRZLLG0 manually, the information doesn’t populate. You can change this instance parameter or just run program rsrzllg0_actual with FRCE_SAV unchecked.
Not only did the properly working Logon Groups fix my Adaptive RFC connection, but it also corrected my inability to automatically send my ABAP information to the SLD. In the end I finally have my application working that combines processing from my local Java and ABAP systems.