Exception Handling in JCo

Exception handling is a very important part of writing software. This intensifies when connecting to many heterogeneous systems. JCo error handling enables programmers to encapsulate SAP errors and correctly warn users of problems.

JCo throws only runtime exceptions, which means a try-catch block isn't needed around JCo calls (that is, the compiler won't complain if the method doesn't use throws). However, when programmers write JCo programs, this might not be beneficial because they may inadvertently miss error handling and crash the runtime environment. In some cases this is fine, such as in standalone, run-once programs. But when programming Web sites, this isn't acceptable. The end user wants to be informed if there is a problem and directed in what she can do about it (even if it's a fatal system error). When programming JCo in Web environments, always catch and process or display as many errors as possible. JCo has three different types of exceptions:

• JCO.Exception— The base exception thrown by JCo and the parent of the other two exceptions.

• JCO.ConversionException— A JCo exception thrown when an incompatible value is entered into a field and cannot be converted.

• JCO.AbapException— A JCo exception thrown from the function being called within SAP.

JCo Exception

The base class of all JCo exceptions is JCO.Exception. This object classifies errors into several different error groups that can be retrieved with the getGroup() method. Check the Java documentation on JCO.Exception for more information. This is found in from the JCo home directory in docs\jco\com\sap\mw\jco\JCO.Exception.html.

The class uses two methods: getKey(), which returns the error key, and toString(), which returns a description of the error. Sometimes this message isn't very pretty, as in the case of network errors.

The following code checks for the resource that's unavailable in a connection pool and prints out a better error message:

try{
  client = JCO.getClient(POOL_NAME);
}catch(JCO.Exception e){
    if(e.JCO_ERROR_RESOURCE == e.getGroup())
     System.out.println("Pool is Full, create a larger one");
    else{
     System.out.println("Group  = " + e.getGroup());
     System.out.println("key   = " + e.getKey());
     System.out.println("Message = " + e.toString());
     System.exit(1);
    }
}

Conversion Exceptions

The "Java and SAP Type Conversion" section earlier in this chapter describes how JCo tries to convert values from set and get methods into the proper format. If this format is unacceptable and cannot be converted, a conversion exception is thrown. When working with input from a Web application and passing it to SAP, it's a good idea to catch these conversion exceptions and gracefully display errors back to the screen for invalid data. The following code checks for a conversion exception on an input parameter and saves the error for later processing:

try{
  ordersched.setValue(myQty,"REQ_QTY");
}catch(JCO.ConversionException ce){
    System.out.print("Error Key = " + ce.getKey());
    System.out.print("Error Text = " + ce.toString());
    Error = ce.toString(); //display back to front end
}

ABAP Exceptions

SAP has different ways of handling exceptions thrown in remote-enabled functions. BAPIs traditionally have a return structure that holds any error message or runtime exception thrown within the ABAP code. The return table usually has a similar type and can be programmatically accessed on the Java side and use the Java error handling. This definitely isn't the case 100% of the time. Some BAPIs and most RFCs have a different method for handling errors that throw ABAP exceptions.

The first segment of code lists a return table that contains errors from a BAPI. The TYPE field contains a one-character field representation that uses E to specify an error. This code loops and prints out all the errors and warnings. The following code is an example of retrieving errors.

client.execute(bapi_sales_create);
JCO.Table bapireturn =
  bapi_sales_create.getTableParameterList().getTable("RETURN");
if(bapireturn.getNumRows()>0){
    for(int num_err = 0; num_err < bapireturn.getNumRows();num_err++){
     if("E".equals(bapireturn.getString("TYPE"))){
       //an error
       System.out.println("Error: " + bapireturn.getString("MESSAGE"));
     }
     else{
       // a warning
        System.out.println("Warning: " + bapireturn.getString("MESSAGE"));
      }
    }
}

The second type of error handling found most often in RFCs is exceptions that are thrown and listed in the RFC. These errors are thrown during the execute method. When JCO.AbapException is thrown, the getKey() method returns the exception that was thrown.

The following sample code looks for an error message thrown by RFC_READ_TABLE, which is a useful function for getting table data from SAP:

try{
 client.execute(bapi_sales_create);
}catch(JCO.AbapException ae){
 if("SOME_ERROR".equalsIgnoreCase(ae.getKey()))
   System.out.println("Table is not Found");
}

Each of the previous examples is explored further in a sample program on the companion CD in examples/JCoTestExceptions.java for this chapter.

Sample Web Application for JCo

Instead of setting up a complex framework for the SAP connection, this sample uses JCo in only a JSP and a JavaBean. In a Web environment, the SAP connection is usually done within some sort of business object (an Action class in Struts or an EJB, for instance).

The example contains two JSPs and a JavaBean. The first JSP is a selection page, and the second contains the JCo call and lists the output. The JavaBean contains references to the MATNRSELECTION table, which has a common SAP structure known as a select-option. This is how ABAP handles searching. The structure has four different fields:

• The SIGN field can accept either I or E, meaning an inclusive or exclusive search, respectively. An inclusive search returns what was specified in the other fields. An exclusive search returns everything except what was specified in the query.

• The OPTION tab specifies the operation to perform. The OPTION field uses a two-digit code. In the following example, we use CP (standing for contains pattern), which enables us to use the * wildcard character. More documentation of this and other function modules this can be found in SAP under the transaction BAPI.

• MATNR_LOW and MATNR_HIGH, which contain the search values.

All the source for the application is contained with the compiled classes on the CD. They're located on the companion CD in the /webClient directory for this chapter. The JSPs are listed here, and the SAP connection JavaBean is in WEB-INF/classes/myApp/beans/MaterialSearch.java. To deploy the Web example, you must

• Download and install the JCo software from SAP (free for partners and customers).

• Copy the Web application directory named webClient from the ch32 directory on the companion CD to any temporary directory on your hard drive.

• Add jco.jar or sapjco.jar from the JCo install directory to the Web application's WEB-INF/lib folder, and the content of .../SAP/WEB-INF/classes to the Web application's WEB-INF/classes folder.

• The properties file must be configured with your SAP information. The location of the file is WEB-INF/classes/myApp/properties/saplogin.properties.

• Add a new application to the WebLogic domain, starting by picking the webClient directory from the temp location on your hard drive.

• Run the application by entering the following URL in a Web browser:

  http://[weblogic server web address]:[port]/webClient

When the application is correctly installed and the URL is typed in, you'll see the screen shown in Figure 32.1.

At this screen, type in material or a search criterion with an * to return a list of materials from SAP. The search length is limited to 100 items for performance and time reasons.