Skip to Content

Auto-generated Enterprise Service Test Stubs


During the life-cycle of a Composite Application it may necessary to replace the consumed Enterprise Services (ES) with so called Test Stubs, which return a predefined set of data.

Two of the most prominent use-cases for this are the following:

  • (Unit) Tests of your composite business logic
  • Demos, where the real backend is not available

Fortunately, SAP NetWeaver Composition Environment 7.1 ships with all you need to develop such Test Stubs as explained below.

Generating Enterprise Service Test Stubs

The process of how-to create a Web Service skeleton class based on an existing WSDL is really straight forward and explained in detail here. This approach is usually refered to as Top-down, Outside-in or Contract-first.  

Basically, all you need to do is the following:

  • Create an EJB Module DC/project (containing the EJB Stateless Session Beans that are exposed as Web/Enterprise Servcies) as explained here
  • Create an Enterprise Application DC/project (to assemble the EJB Module) as documented here
  • Import the WSDL file of the Enterprise Service you’d like to create a Test Stub for as explained here
  • Create the ES skeleton class as explained here
Bringing the  skeleton to life

So, with the skeleton in place all that is left to be done is to add the meat in the form of the actual coding. Probably the easiest approach to do so would be to launch the WS Navigator and to test-drive the targeted WS with some test data. You can then download the results to an XML file as shown below.


Arrmed with this set of test data you’ll face the tedious and boring task to hack down the necessary coding: mainly constructing new objects and setting attributes and child objects. This is really one of these moments you actually wish you’d have one of these trained monkeys everybody seems to be refering to all the time 😉

Automating the Java Code Generation

Being a really lazy virtuous programmer I strived to automate this last step by creating a tool, that would to this for me .. and you!

With the WSDL file on one side and the result set of test data obtained from the WS Navigator on the other, it seemed quite feasable to come up with a quick hack in a matter of hours. I mean all that needs to be done is to traverse through the test data XML file and look up the corresponding Java data types from the WSDL….

Honestly, I gave up on that approach due to several reasons… such as the complexity of the ES WSDL XSD schemas and the lack of an XPath API in CE to just state the major ones. (Of course, I could have used an Open Source tool, but I wanted a light-weight solution that would not require third-party tools.)

In fact, I changed my approach in favor of using the Java Reflection API to obtain all the required information from the class files created by the Web Service Skeleton tool:


JEST – Java Enterprise Service Test Stub Tool 

The result is a tool I called JEST and I posted the code here and I hope that the community finds it usefull. I’ve only tested several Enterprise Services with it so far, so I’d like to encourage the community to test-drive the tool with other ES and submit their results… not to mention how cool it would be if I’d get some assistance in further improving the tool. If you do so, please keep in mind that currently it’s barely more than a quick hack I pulled together and beautified a little before posting it on SDN. As such, the usual SDN Code Snippet disclaimer fully applies!

How-to use JEST

Now, that really is as easy as 1-2-3… simply copy the source code provided on the above mentioned Code Snippet page and create a class called “Jest” anywhere within the EJB Module of your Composite and paste the code – et voila! Now, you could also keep JEST outside of the EJB Module, but then you would have to make sure that Jest has access to the EJB skeleton classes, so either adjust your classspath or set corresponding DC references as applicable).

JEST ships with a main method that requires four parameters:

  1. the path of the WSDL file that was used to generate the ES Test Stub
  2. the path of the XML data file obtained from a successful WS Navigator test of the original ES
  3. the path of a file into which JEST should write the actual Java coding
  4. (optional) a debug level: debug, info, warning, error
Related Links
Be the first to leave a comment
You must be Logged on to comment or reply to a post.