Introducing Oracle API Gateway Explorer

Overview

You can use the Oracle API Gateway Explorer testing utility to test the security and performance of enterprise services. API Gateway Explorer is a vital tool for administrators who want to test the policies acting on a service before moving the service from a testing environment to a production environment.

API Gateway Explorer can generate SOAP messages automatically from WSDL files and display them. Application-level security can then be applied to messages by adding XML Signatures, XML Encryption segments, SAML assertions, and WS-Security tokens. Requests can then be sent to the target service to make sure it is processing the security tokens appropriately. Traditional security technologies, such as SSL and HTTP authentication, are also supported.

Likewise, API Gateway Explorer can check the operational performance of the service through its comprehensive stress testing capabilities. By sending multiple request messages to the service in parallel, API Gateway Explorer can simulate the type of traffic the service will receive in the production environment.

Subsequent topics describe in detail exactly how to use API Gateway Explorer to perform security and performance testing on services. However, before doing this, this topic introduces some concepts to help define how API Gateway Explorer performs various types of testing.

API Gateway Explorer Classic View

Users of previous versions of API Gateway Explorer will recognize the Classic view because it has very similar features to previous incarnations of API Gateway Explorer.

You can use the Classic view to load SOAP messages, add security tokens into the messages, and send them to target services to see how they handle them. Whereas older API Gateway Explorer versions required you to copy and paste SOAP messages into the Request panel, API Gateway Explorer 11.1.2.3.0 enables you to auto-generate SOAP messages from the WSDL files that contain the service definitions.

For more details, see the topic on Using the API Gateway Explorer Classic Mode.

API Gateway Explorer Design View

The Design view enables you to auto-generate a SOAP message, or a Test Case, for each SOAP operation defined in the WSDL file. You can then configure a series of message filters to act on each of these messages before they are sent in batch mode to the service. For example, you can add security tokens, HTTP headers, and attachments, before sending them to the target service.

Similarly, you can configure a number of message filters to act on the SOAP response message returned from the service to ensure that the request was handled appropriately. For example, you may want to run an XML Schema against the response, or use an XPath expression to check the value of a particular element in the response, or you may even just want to check the HTTP status on the response.

You can also create a series of Attack Vector Messages that contain common attacks, such as SQL injection and XPath injection attacks, and send them to the service to make sure that the security in place can handle such threats.

For more information on generating Test Cases and Attack Vector Messages in the Design view, see the following topics:

Checking WSDL for WS-I Compliance

When using a WSDL file to auto-generate Test Cases, API Gateway Explorer can check the WSDL for compliance with the WS-I Basic Profile. The Basic Profile was designed to smooth out interoperabilty issues between different SOAP vendors. The assertions listed in the Profile are designed to ensure maximum interoperability between different implementations of SOAP and different services.

For more details, see the topic on Testing WSDL Files for WS-I Compliance.

Using the Send Request Command

You can use the Send Request utility to stress test services by sending large numbers of requests in parallel from the command line. The Send Request (sr) tool ships with a large number of configuration options that enable you to perform complicated tests on Web Services.

For more details, see the topic on Stress Testing with Send Request (SR).