In the previous blog (Easier Troubleshooting with Enhanced Duet Client Support Tool (Part 1)) (Part 1), I introduced the "Cache Viewer" feature. In this blog I will demonstrate how to take advantage of the enhanced "Test Landscape" feature.
Testing Duet Landscape - Using the "Test Landscape" feature
For those of you who are not yet familiar with the "Test Landscape" feature, this dialog allows testing the landscape with three built-in tests (the "Ticket Issuer" test verifies that the user can be authenticated against the Ticket Issuer component; the "Service Provider" and "Service Mapper" tests verify the user is able to download data from the relevant components on Duet J2ee server).
For start, let's open the "Test Landscape" dialog by right clicking on the CST icon in the system tray bar and choosing "Test Landscape". The following dialogs will appear:
In order to run the tests, the "Tests Landscape" platform needs to get Duet web-services URLs. To do that, we need to enter a path to the "Base Application" metadata file (i.e. BaseApplication.BaseApplication.xml in Duet 1.5) or the Duet Read Service URL (available in Duet 1.5 clients only). Once we hit the "Test" button, the Read Service or the Metadata file will be queried for the required URLs, the tests will start to run and inform the user with the final statuses:
!https://weblogs.sdn.sap.com/weblogs/images/251810051/tests_list.jpg|height=156|alt=Tests List|width=597|src=https://weblogs.sdn.sap.com/weblogs/images/251810051/tests_list.jpg|border=0!
If from some reason the “Tests Landscape” platform fails to get the URLs from Duet Read Service or from the metadata file, an appropriate error message will be displayed:
*Adding More Tests </p><p style="margin: 0in 0in 10pt" class="MsoNormal">A new enhancement to the “Test Landscape” dialog is the option to add externally developed tests. This feature allows any .NET developer to easily develop tests, compile it as class library project and upload the DLL to the “Test Landscape” platform (check out the “Developing External Tests” section in the CST documentation for more details).</p><p style="margin: 0in 0in 10pt" class="MsoNormal">Here is a short example; I have created a separate class library (DLL) which contains a simple test. By clicking on the “Add Button” test I can choose the DLLs I want to use:</p><p style="margin: 0in 0in 10pt" class="MsoNormal">!https://weblogs.sdn.sap.com/weblogs/images/251810051/add_tests.jpg|height=52|alt=Add Button|width=238|src=https://weblogs.sdn.sap.com/weblogs/images/251810051/add_tests.jpg|border=0!</p><p style="margin: 0in 0in 10pt" class="MsoNormal">Then, the platform scans the chosen DLLs for the specific “TestItem” classes and uses it as part of the existing tests collection:</p><p style="margin: 0in 0in 10pt" class="MsoNormal"> </p><p style="margin: 0in 0in 10pt" class="MsoNormal">!https://weblogs.sdn.sap.com/weblogs/images/251810051/example_test.jpg|height=183|alt=Added Test|width=578|src=https://weblogs.sdn.sap.com/weblogs/images/251810051/example_test.jpg|border=0!</p><p style="margin: 0in 0in 10pt" class="MsoNormal"> </p><p style="margin: 0in 0in 10pt" class="MsoNormal">As shown, enhancing the tests collection and using it can be done easily.</p><p> </p><p>Performing Pre-installation Tests – Using the command-line option*
Fixing potential problems before installing Duet on the clients might save us significant efforts. This is where the CST command line feature comes in hand:
Let’s say we are about to install Duet 1.5 Preview on a “clean” landscape. After Duet server components were installed and configured, and before rolling out the clients’ installation, we can use the Support Tool to remotely test the readiness of the clients.
Using an IT script/software distribution system (i.e. SMS), the Support Tool can run in a command line mode to test the clients with the three built in tests or other external tests that were developed.
When the Support Tool finish running the tests it provides the results in two ways:
The CST process returns an “exit code” which represents the result of the run; for example if one of the tests fails, “603” is returned (see CST documentation for the full list). This integer code can be used by the IT script to alert the admin about a problem without reading each log.
The command line syntax is as follows (see CST documentation for more details):
SAP.Office.Supportool.exe <Path to the metadata file (not url)> < Full path to the log file > [-v <Duet version>] [-e <Full path to external tests directory>]
In order to run CST from command line we will need to provide two mandatory options:
1. The “Base Application” metadata file:
In Duet 1.0 this is the Metadata file under “DuetMetadata” shared folder in Duet server; in Duet 1.5 Preview this file should be downloaded from the J2EE server using the Duet Administration screens.
2. Path to the destination log file (usually a path to a shared folder with the log’s name).
So in our case, since we are going to install Duet 1.5 Preview on the landscape, we should use the following command:
SAP.Office.Supportool.exe
myserverDuetMDBaseApplication.BaseApplication.xml
myserverDuetCSTLogsmachineX.xml -v 1.5.0
For example, I ran the command on a single client, the process returned exit code “603”. This indicates that at least one of the tests failed; if the code was “0” then I would know all tests were successful.
To understand which of the test failed let’s look at the XML log:
As you can see, the user failed to be authenticated. Logging on to the client revealed time difference between Duet server and the client.
After fixing the problem and running the command again, “0” was returned as an exit code and the log shows the following:
!https://weblogs.sdn.sap.com/weblogs/images/251810051/success_log.jpg|height=390|alt=XML Log|width=595|src=https://weblogs.sdn.sap.com/weblogs/images/251810051/success_log.jpg|border=0!</body>
1 Comment
