Testing integration with enterprise backends

Most useful mobile applications are connected to enterprise backend services. During mobile application development, most teams need to do one or more of these tasks: create new backend services, connect to existing services, or create 'front-end facades' for existing services. This practice focuses on development-time techniques to use mock-up stubs to avoid hitting the real services that are often critical to the business of the enterprise.

Types of backend services

IBM® Worklight applications can invoke a wide range of backend services through the adapter mechanism. Most services can be invoked directly from the adapter code using the IBM Worklight server-side JavaScript APIs. Some services must be invoked from native clients that are written in Java™ which then can be scripted in JavaScript through Rhino (the IBM Worklight Server's JavaScript runtime environment). The sections that follow describe various development-time backend services.

REST or REST-like services

These services are accessible via direct HTTP calls. Most REST services are developed for integration with a user interface client (rather than machine-to-machine invocations) and use JSON as the data format on the wire. You can invoke these services directly from the IBM Worklight HTTP adapters.

SOAP-based web services

Typically developed for backend integration (machine-to-machine communication), these services are often used directly by user interface clients. You can use IBM Worklight's server-side JavaScript API to consume SOAP-based web services. Use an HTTP adapter for this type of backend.

Relational databases

Relational databases can be accessed from the 'SQL adapter.' The adapter connects to the database directly with JDBC connection strings or data source references. Using JavaScript code, the adapter can issue SQL statements or invoke procedures against the target database.

Enterprise applications

Enterprise applications, sometimes referred to as 'Enterprise Information Systems,' can be accessed through IBM WebSphere® CastIron. IBM Worklight provides a special adapter to integrate with CastIron. Use the 'CastIron adapter' to invoke services from the enterprise applications that are exposed by WebSphere CastIron.

Other enterprise services

Because IBM Worklight adapters can invoke arbitrary Java code from JavaScript using Rhino, provided you can write a Java client for the backend service, they are legitimate target backends for your IBM Worklight application. For example, you can write a Java client for an EJB as part of your IBM Worklight adapter implementation. Then, you can package the Java client code in a jar file that is deployed with the JavaScript code for the adapter implementation.

Techniques for Development-time mock-up

The simplest way to mock up backend services to perform tests on the application code is to have the adapters return sample data without making invocations to the actual backend services. This technique should be the primary technique that you use to develop application code to run on mobile devices. Alternatively, if your goal is to test the adapter implementation itself, for which you need to write code that invokes the backend services, then consider the recommended best practices that follow.

You use an IDE that supports Java EE development, such as IBM Rational® Application Developer, to create development-time artifacts to serve as your IBM Worklight adapter's invocation targets. The following sections assume that you are using Rational Application Developer together with IBM Worklight Studio for mobile development.

REST or REST-like services

For REST or REST-like services, if the data format is JSON, and only HTTP GET is needed, then the simplest way is to mock up such a service by using a JSON file. Create a 'Static Web Project' in the Rational Application Developer workspace, and create a file called something.json in the 'WebContent' folder. Use the JSON editor to add the expected data in it. Rational Application Developer has an embedded 'Web Preview Server' that can be used to deploy the static web project and serve up the JSON. Right-click on the JSON file and Run As> Run on server, then select the 'Web Preview Server' as the target. After successful deployment a browser is launched showing the JSON data, record the URL in the browser. Use this URL as a reference to configure the IBM Worklight adapter descriptor XML and the invocation code in order to properly reach the JSON data.

You can apply the same technique to backend services that produces XML data in response to GET requests. The only difference is that you use an XML file instead of JSON.

If other HTTP methods are required, some coding is required. You write a JAX-RS resource bean to implement a RESTful service. Refer to Rational Application Developer documentation in this space for details. To run it, you can also use the Web Preview Server.

To minimize the code changes needed when you switch from the mock-up services to the real services for integration testing, put the JSON file in a folder structure that mimics the URL of the real service. This way the JavaScript code in the IBM Worklight adapter implementation does not need to change. The only change needed is to modify the 'Domain' and 'Port' fields in the adapter descriptor XML.

SOAP-based web services

To mock up a SOAP web service, first obtain the WSDL that describes the real service. WSDL is an essential part of the WS-* programming model, so it should be easy to obtain one. Next, use Rational Application Developer to generate a skeleton service that is based on the WSDL. Then you need to plug in some simple code into the implementation class that mimics the logic of the real service. Deploy the resulting web application to a WebSphere Application Server test environment using Rational Application Developer.

Relational databases

To mock up a relational database service, create a local database that closely matches the actual one for development purposes. Use SQL commands to do this, but if you are not familiar with SQL commands, you can use the built-in database support in Rational Application Developer. The tool makes it easy to create the tables, constraints, and so on, that are needed to mock up the relational database.

Ask your database Administrator to provide you a set of SQL statements that can create some sample data based on the target database. In Rational Application Developer open the 'data source Explorer' view, click 'New Connection Profile' in the toolbar of the view, and follow the wizard to create a Derby database. You may choose other database types, but creating an instance of one of these may require more effort. To create a Derby database, make sure 'Create database (if required)' is checked in the wizard. After the new database is created, click 'Open scrapbook to edit SQL statements' and paste in the SQL statements you got for the sample data. Finally, right-click and select 'Execute All' to create the contents in the new database.

Once you have the sample database that is created locally, you can use it with the SQL adapter. The closer the mocked up database is to the actual database, the better chance you that will not need to modify the adapter implementation when you switch to test against the actual database. The only change that would be needed is the connection policy settings in the XML of the adapter.

Enterprise applications that are integrated through Cast Iron®

WebSphere Cast Iron supports a wide range of backend systems for integration purposes. These systems are typically sophisticated Enterprise Information Systems which are difficult to mock up. You can mitigate this situation by using Rational Test Virtualization Server, which can emulate backend services for application development. Visit http://www.ibm.com/software/rational/products/rtvs/ for more information.

Other Enterprise services

If the target services to be invoked from the IBM Worklight adapters are of any of the types EJBs, SCA, WebSphere Batch, or JCA, proceed as follows. Use Rational Application Developer tools to develop a sample version of the real service. Then, deploy to WebSphere Application Server or WebSphere Liberty Profile as the temporary testing target during the development phase. Do this until the application code is in good shape and you are ready for testing against the real services.

References

Rational Application Developer wiki home

Rational Test Virtualization Server

Rational Test Workbench


Feedback