Debugging an application comes down to see what is going on during execution of the application. One way of debugging is to log specific messages to a file. To get e detail analysis of the program flow you set breakpoints. These breakpoints are set in your source code and are instructions of the Java VM to stop execution when it hits a breakpoint. After the execution stopped you can see the current values of variables.
The instructions here are for SAP Portal 7.x, but the overall process should be the same for the 7.3 portal.
Before you can start debugging a portal application (PAR) you have to enable the debug option on your portal server. This means that you will enable a specific debug port to which your NWDS will connect. To actually debug the portal application you’ll use NWDS. This implies that you rarely will activate and execute a debug session in your productive portal environment. If you have debug a PAR that already is in production, something is wrong with how you release software.
The debug port is activated using the configtool. You set the debug port to an arbitrary value, just make sure that the port is free.
In the portal application, set breakpoints where you want the Java VM to stop execution so you can take a closer look at the VM environment.
This will instruct the VM to stop every time the array a gets a value assigned. Next step is to deploy the PAR. Make sure that you select the option: “Include the source code of the portal application”. If not, the debug won’t work.
To actually start the debug session you create a remote java application configuration:
Specify the portal project, the server and debug port (the one you gave in configtool). After clicking on debug, NWDS will connect to the Java VM and already present you with some nice information of the VM:
When you now execute the PAR, the Java VM will stop the application where you have set the breakpoint.
You can start exploring the current state of your application. The variables are shown with their current values:
To gain a deeper understanding of the environment of the PAR, you can also look at the request object and find out variables and their values:
Resuming execution and the values are being updates:
These are the technologies you need when writing modern web applications. And that is what makes it so hard to use SAP together with modern web applications: Currently you only get REST from SAP with Gateway, but not JSON. OData comes from Microsoft and support is not as wide spread as someone expects. How OData does looks like? You can try it out by downloading the Gateway Trial from SCN or use the online demo system. To experiment with Gateway the usual flight example from SAP can be used. To get the details of a specific flight: sap/opu/sdata/iwfnd/RMTSAMPLEFLIGHT/FlightCollection(carrid=’AA’,connid=’0017′,fldate=’20110601′)
Data returned from Gateway looks like this:
Instead of being able to use the data exposed by Gateway by the widely used Javascript frameworks like jQuery you need to find an OData plugin. Of course you can still use SAP UI5, but what when you are forced to use jQuery, Sencha, Dojo or something else?
That’s a problem with SAP and ABAP in general: you have to wait until SAP or developer implements functionality, and because of the limit resources available in the ABAP ecosystem this can take a while, costs some serious amount of money or will never happen. That’s where we can be happy that SAP also embraces the use of Java. As Java was made for the internet there is a huge Java community out there that most probably already developed a tool that fits your needs.
For exposing data as JSON in a REST-full way the tool available is: Jersey.
After Jersey transformed the data, the response looks like:
{“EXTENSION_IN”:{“item”:[]},”EXTENSION_OUT”:{“item”:[]},”RETURN”:{“item”:[{“TYPE”:”S”,”ID”:”BC_IBF”,”NUMBER”:”000″,”MESSAGE”:”Method was executed successfully”,”LOG_NO”:””,”LOG_MSG_NO”:”000000″,”MESSAGE_V1″:””,”MESSAGE_V2″:””,”MESSAGE_V3″:””,”MESSAGE_V4″:””,”PARAMETER”:””,”ROW”:0,”FIELD”:””,”SYSTEM”:”NPLCLNT001″}]},”ADDITIONAL_INFO”:{“FLIGHTTIME”:361,”DISTANCE”:2572.0000,”UNIT”:”MI”,”UNIT_ISO”:”SMI”,”PLANETYPE”:”747-400″,”FLIGHTTYPE”:””},”AVAILIBILITY”:{“ECONOMAX”:385,”ECONOFREE”:20,”BUSINMAX”:31,”BUSINFREE”:1,”FIRSTMAX”:21,”FIRSTFREE”:3},”FLIGHT_DATA”:{“AIRLINEID”:”AA”,”AIRLINE”:”American Airlines”,”CONNECTID”:”0017″,”FLIGHTDATE”:1306897200000,”AIRPORTFR”:”JFK”,”CITYFROM”:”NEW YORK”,”AIRPORTTO”:”SFO”,”CITYTO”:”SAN FRANCISCO”,”DEPTIME”:50400000,”ARRTIME”:61260000,”ARRDATE”:1306897200000,”PRICE”:422.9400,”CURR”:”USD”,”CURR_ISO”:”USD”}}
Jersey needs Java 6 and runs in a servlet container. As NetWeaver CE >= 7.2 fulfills these requirements, Jersey can be used to transform POJOs into JSON and expose them using REST. NW CE comes with a framework for creating composite applications (CAF) that can consume BAPIs. CAF uses standard J2EE technology like JCA and Beans. This bean can be used by Jersey to automatically extract the data, transform it into JSON and make it accessible using REST.
Consuming a BAPI using CAF can be done with no coding involved at all as CAF comes with some nice wizards. Just map the input and output parameters and the code will be generated including the bean that can be used to interact with the BAPI. In the Jersey web application the URL and protocol get defined:
The CAF bean gets called using the parameters retrieved from the URL:
out = e.bapiFLIGHTGETDETAIL(null, null, null, carrid, connid, flightDate);
That’s it. Jersey will do the rest:
How the URL gets constructed is up to you, the parameters can be part of the URL as above or a query. You can also define if it is GET, POST, PUT, etc. If you want to do some coding you can adjust the output, or combine the result of several BAPIs into one Java object that JSON will expose.
Now that the BAPI can be accessed in a RESTful way and the data retrieved is in the JSON format, it’s easy to use the data in a Javascript framework like jQuery with Datatables:
The actual coding for making the CAF bean accessible to Jersey and expose the data is less than 10 lines of code. From CAF to Jersey to a running HTML application it does not even take 30 minutes.
The framework I used for interacting with the ABAP system is CAF, a framework available for NetWeaver Java since a while (7.0): well documented enterprise ready and supported. If you want or need to expose your BAPI by REST and JSON or XML and you have a NetWeaver CE >= 7.2 (like Portal 7.3) available, you can start today. As your NW CE system is a separate one, upgrades won’t affect your backend system and as Jersey is also a separate application; changes to Jersey don’t affect your other CE server and applications. Of course you don’t need NW CE for using Jersey and CAF for interacting with BAPI. Every platform that Jersey supports and where you can use JCo from SAP to call a BAPI can be used like tomcat. It just means that some extra configuration and coding will be necessary. This also implies that your backend ABAP system can be used as long as a JCo connection to it is possible.
Before an application can go into production, it needs to be tested. For Java there are several widely adopted test frameworks available like jUnit or TestNG. As these are used to test Java applications, what about web applications? How to test the UI that actually is constructed by using HTML, CSS, JSP and JavaScript? This is not easy as you have to simulate user input and validate the generated response, including different browsers. The example in this blog is about testing a simple HTMLB checkbox.
A tool that can help you creating test cases for web applications is Selenium. Selenium offers a Firefox plugin called Selenium IDE that records what the user is clicking and translates these actions into HTML code. To test an application with Selenium the following steps are needed:
Record the user action
Select a test framework and save the recorded actions in Java code
Import the generated code into your Java project
For the 1st step, Selenium offers a Firefox plugin called Selenium IDE. This means while the user actions can be replayed by several browsers (IE, Opera, FF, mobile, etc.), with the IDE only the user actions from a Firefox user can be recorded.
In the generated HTML code of Selenium, these values are shown as HTML:
It is easy to see a possible problem here: how Selenium will find the actual HTML UI to test. In the above example the absolute path is used. When the portlet is not run as a single application but inside the portal the path will change. So make sure that the HTML code of the application is surrounded by a unique HTML that can serve as a starting point of the path. As the HTML isn’t really useful, you’ll have to export the actions to a framework of your choice (I created my own export template called SAPHtmlbTestNG).
For those who already know Selenium: the IDE does not come with an export to TestNG and WebDriver, so you are bound to use Selenium RC. After exporting the test case you get Java code that actually can be used to run the tests:
What does that actually mean? In the Selenium IDE I added a test that checks if a HTML element (e.g. a UI element like a button, checkbox or any other HTML element) is in the HTML code retrieved from the application:
verifyElementPresent
For this Selenium identified the actual location of the element in question in the HTML source code:
As for Selenium and testing: the actual Java code for executing the tests is Selenium. TestNG only serves as the framework running the Selenium Java code. That’s why there are testing annotations like @BeforeClass. TestNG will control the flow of the tests (starting selenium, running the tests, stopping selenium).
Running the Selenium test with TestNG
To run the tests a few things have to be considered:
A Selenium server needs to be up and running
TestNG can be controlled over a XML file
Starting the Selenium server can be done via a (ant/maven) script or manually. What is more interesting is the XML file that controls TestNG. There the actual tests to be performed together with parameters are defined:
<?xml version=“1.0” encoding=“UTF-8”?>
<!DOCTYPE suite SYSTEM “http://testng.org/testng-1.0.dtd”>
The parameters are read by the annotation @Parameters and are used to define the selenium server. I added a listener that allows me to take a screenshot when a test fails and in the <test> section the actual tests are listened. There is only one test listened; to add more tests just add them by <class> definitions.
Run the test
After the tests are prepared and the tests and parameters are defined in the XML, the tests can run: either by invoking them directly in Eclipse or by running a script. TestNG will create HTML reports of the tests results.
Adding new test cases isn`t really hard when using the Selenium IDE. Where the IDE doesn`t help creating test cases, the developer can create them directly in Java. A benefit of Selenium is that you`ll end up having functional tests, as a real browser will make the calls to the application and validate the result.
From the 21 tests in my test suite, 2 failed.
Because of my screenshot class added to my test suite, TestNG made a screenshot when the test failed.
Selenium with a test framework like TestNG allows for functional testing of SAP web application. This is not bound to SAP Portal or WDJ apps, everything that has a HTML based UI can be tested. You have to keep in mind as UI testing is important, you should not focus solely on it. Unit and service tests should make the largest part in your test efforts.
