SAP Screen Personas
Create: Kranthi Kumar Muppala
Last Update: Tamas Hoznek
Scripting: Error Handling and Debugging
SAP SCREEN PERSONAS KNOWLEDGE BASE - by Tamas Hoznek , Regina Sheynblat , Kranthi Kumar Muppala
Updated in Application Help SP08 9/20/2018
This article describes a few options available to handle errors that occur in scripts and a few tips on how to debug scripts.
These exceptions and any other exceptions raised within the script can be caught using a try-catch block and necessary actions can be taken.
Handling Known Exceptions
In the following example, I will use the getCellValue function of the GuiGridView control to fetch the contents of a column that does not exist. From the documentation, the function raises or throws two exceptions - RowIndexOutOfRange and WrongColumnName.
This function returns the value of the specified cell. This method will only return values if the row is visible or in other words the following conditions are met: firstVisibleRow <= rowIndex < min( firstVisibleRow + visibleRowCount, rowCount) . Use property firstVisibleRow to page to the right set of rows before reading their values. If the specified cell is outside of the visible row range or the column does not exist, then an exception is thrown.
If I execute the following piece of code in the details screen of SU01 transaction with the 'Parameters' tab highlighted, an error occurs because there is no column named 'XYZ' in the Grid View control.
There is no error displayed to the user. However, this statement causes the script to stop execution and there is some error information logged to the browser console that looks like below.
The error situation shown above is most likely a script developer mistake. The same behavior occurs when the the getCellValue function is used with a row index that is outside the bounds of the available rows. In this case, a RowIndexOutOfRange exception is raised by the scripting engine. The following piece of code will demonstrate how the exception can be caught and execute a fail-safe or display a prompt to the user with details of the error.
The exception object contains properties like the name (ID of the exception from the API documentation), message and stack (stack trace for detailed information of function stack).
Handling Other Exceptions
It is not necessary to display the error message to the user. There are instances where a user needs to correct data - like filling in a field value or fix an incorrect value. In such cases, the exception can be caught and an appropriate error message on the status bar can indicate the user to fix the data.
Handling Backend Errors
There are scenarios where a document being processed is locked by another user and a script tries to modify a field's value. Since the transaction will not allow the document to go into edit mode, there will be an error when the text of such a field is being set to another value. In the following example, I will use SU01 and go to display mode to view the details. The following script tries to set the last name field and there is a backend error popup that shows up.
The above result is in contrast to the previous examples where the error could be caught in the catch block. There are a couple of reasons for this behavior:
- The error does not originate from the scripting engine as the engine does not detect such errors. The backend error popup is created by the SAP GUI for HTML application as a means to indicate to the user that the request sent by the script was invalid. In this case, a read-only field cannot be modified.
- For optimization purposes, all write requests and actions are queued in the scripting engine and sent to the server only when something is read in the script. Since there is no property being read after setting the text property, the queue of requests are sent to the server after the script execution is completed. Since this is outside the scope of the try-catch block, this exception cannot be caught and the backend error popup is displayed.
One trick to catch the backend error without displaying it to the user is to make sure a control's property is read just before the end of a script or wherever there is a possiblilty of such errors. The following script when executed will not display the backend error, but will show the user the custom alert popup like in previous examples. The catch routine could be substituted to take other actions like going into edit mode etc.
The backend error popup displays information regarding the requests that are sent to the server. However, it does not show the origin of the error like the line number in the script etc. To display such information, use the URL parameter sap-clientDebug=X during troubleshooting. The same example will display the following popup with this URL parameter indicating that the error occurred on line number 23.
NOTE: The sap-clientDebug=X URL parameter should not be used in production as it has a lot of overhead in logging debug information to browser console.
If the breakpoint needs to be set at a specific condition, the 'debugger;' statement can be set within an if condition or the breakpoint in the line number gutter can be right-clicked and a conditional break point can be set. More information on this is available in Google Chrome's KB article referenced at the end of the article.
Browser Console Logging
Alternatively, the session.utils.log function can be used so the script can be used across GUIs. Here's an example.
More information on the browser console can be found in Google's KB article referenced at the end of the article.
Debugging OnLoad and OnAfterRefresh Scripts
The scripts assigned to OnLoad and OnAfterRefresh screen events can be tricky to debug in scenarios where a particular screen is skipped or a switch to another flavor or transaction occurs. In such cases, the URL parameter suppressOnLoadEvents=X can be used to deactivate execution of such scripts. The script editor can then be opened to debug or modify the scripts.
Related Search Terms:
SAP Screen Personas, Scripting, Debugging, Error Handling, Developer Tools