Logging GRC Web Service Calls in VDS 7.2 SP8

Troubleshooting the IdM-GRC interface is so much easier when you have  the full SOAP messages sent back and forth between Virtual Directory Server and GRC web services. In earlier VDS support packages, these SOAP messages used to be written to the standard log file “operation.trc”  when log level was DEBUG or higher. In an SP8 environment I have recently worked in, however, I couldn’t find the SOAP messages in the logs any more, no matter how high I raised the log level. This article will explain how I got the SOAP message content back into the logs.

Customizing the log4j configuration

Open the file externals\log4j.properties underneath your VDS home directory in a text editor. Append the following lines:

# Increase log level to ALL for category in Apache Axis
# where full SOAP request/responses messages are logged
log4j.logger.org.apache.axis.transport.http.HTTPSender=ALL

I found that any customizations to this file will be lost when I uninstall and then re-install VDS. To avoid having to re-customize the file after update to the next support package, I prefer to copy the customized file to a customer-specific location, and then have the VDS runtime load that customer copy via JVM option. Here’s how to do that:

Copying your custom log4j.properties to an update-safe location

Create a customer-specific directory underneath your VDS home directory. I choose the subdirectory name “custom” here. My example commands assumes that your VDS home is at C:\usr\sap\IdM\Virtual Directory Server. Adapt that to your environment as required. Open a Windows command prompt, and enter the following commands:

set VDS_HOME="C:\usr\sap\IdM\Virtual Directory Server"
mkdir %VDS_HOME%\custom

Copy the externals\log4j.properties to which you have applied your customizations into the custom directory:

copy %VDS_HOME%\external\log4j.properties %VDS_HOME%\custom

Loading the custom log4j configuration file location via Java system property

Start the VDS console, and choose Tools -> Options from the menu bar:

Select the Classpath tab, and add the following JVM option into the “Additional Java options” field:

-Dlog4j.configuration=file:///C:/usr/sap/IdM/Virtual%20Directory%20Server/custom/log4j.properties

Press OK to save your changes.

Note that you must specify the location of the log4j configuration file as a URL; anything else won’t work.  Again, you may need to adapt that URL according to the VDS home directory of your specific environment. For more information regarding MS Windows file URIs, refer to this MSDN article.

In order for the changed JVM options to be picked up by any already installed VDS operating system service, I found that I need to re-install the service. Just saving the JVM options and updating the service configuration via “Update” button, or re-starting the service didn’t work for me. The service would still use the externals\log4j.properties file in this case. See my comments above regarding potential update problems with that approach. So my recommendation is that you re-install at least the VDS GRC service before proceeding to test in the next section.

Testing SOAP message logging

This test assumes that you have a GRC configuration running in VDS, either as a service or as an application. We’ll use the simple GRC web service GRAC_SELECT_APPL_WS, which returns the list of all applications (aka connectors) configured in GRC. It’s invocation from the integrated LDAP browser in the VDS console is pretty straight-forward, so it’s ideal for a simple test.

From the VDS console menu bar, select Tools -> Browse LDAP…

The LDAP browser dialog will be displayed. Press the “Wizard…” button and enter the required connection data to connect to your VDS GRC service via LDAP:

You should be able to specify the exact same values as shown below, except for the port number. Make sure that matches the LDAP port number of your running VDS GRC configuration. If you have this configuration open while doing the test, as is the case in my screen shot below, you can see the port number in the status line at the bottom of the VDS console.

Host name: localhost
Port number: <your configuration's LDAP port number>
Starting point: ou=selectapplications,o=GRC
Return attributes:
Search type: ONE
Filter: (objectclass=*)

Save your data by pressing OK in the LDAP URL dialog.

From the “Credentials” drop-down list of the LDAP browser, select “User + Password”:

Enter the internal VDS user name and password to connect to your GRC configuration’s LDAP server. In a default installation, that’s grcuser/grcuser

Press the “Search” button. A list of GRC applications, whose CN typically corresponds to a logical ABAP system name, should be displayed in the LDAP browser.

The “Search” operation has invoked the ABAP web service GRAC_SELECT_APPL_WS on the GRC ABAP server. We can now verify that the SOAP request and response message of this web service call have been recorded into the log files. From the VDS console menu bar, select View -> Select and view a log…

In the “Open File” dialog, you should now see a new trace file “external.0.trc”, in addition to the well-known operation.trc and operation.log files. Open the “external.0.trc” file to display it directly in the VDS console’s log viewer.

The SOAP request message is contained in the log message starting with “POST /sap/bc/srt…”. The corresponding SOAP response message is contained in the log message starting with “<soap:Envelope>”, as highlighted below:

As I don’t find the integrated log viewer of VDS console to be very well usable, I’ll show the full log message text of both lines in a  text editor instead of in the VDS console directly:

SOAP Request XML

A word of caution

Note that as in in previous support packages, the information contained here is sensitive because it includes the HTTP basic authentication header in full. That’s why I manually grayed out the respective line in the SOAP request XML screen shot above. This HTTP header exposes the ABAP user name and password which VDS uses to connect to the GRC systems more or less in clear text (BASE64 encoding only). For that reason, I recommend to carefully restrict access to these log files at the OS level, and if possible apply the whole logging configuration demonstrated here in development environments only, but not in production.

SOAP Response XML

As you can see, the full information we require for detailed problem analysis is there. Contrary to previous SPs, the information is now no longer in the operations.trc file, but in a separate log file (external.0.trc). But I guess that doesn’t hurt.

Hope that helps!

Lambert