Custom Activities

Relevant for: API testing only

Custom activities enable you to create or import your service models, and then create activities for use in an API test.

In this topic:

Web Services

To create Web service activities, you must import a WSDL file. This file provides a structure for the test by describing the service in terms of its elements, argument values, and properties.

The WSDL import supports both Document/Literal and RPC type Web services.

After you import the WSDL, OpenText Functional Testing represents the data differently depending on the type of Web service:

Document/Literal Web services	The Properties pane displays the input and output properties for a Web service method in the grid, enabling you to assign values to the properties.
RPC-type Web services	The WSDL file and SOAP body contain the complete operation name, its input and output properties, and their values. There is no schema for this type of service and it is not supported by the WS-I conformance standard. As a result, the Properties pane does not display the input and output properties for RPC type services.

If your service document is unique and cannot be imported in the normal way, you can use the SOAP Request activity to send a manual SOAP request to the server.

For details about importing a Web service, see Import a WSDL-based Web service.

Back to top

REST Services

To create REST service models in OpenText Functional Testing, you have multiple options:

• Define the service's Service, Resource, and Method manually using the REST service editor. This model is stored as a prototype activity within your test and the test's methods are added as test steps.

  In addition, you can also define properties and parameters for your REST service at all levels of the hierarchy. You can then pass these properties or parameters from the service and resource levels to the resource and method levels.

  For details, see Pass REST service properties.

• Import a service model from a Swagger API or OData REST Service API. OpenText Functional Testing reads the service description from the file or URL and creates the corresponding services, resources and models.

For more details, see Create a REST service model.

Back to top

Web Application Services

Web Application services provide a description of an HTTP-based Web application in XML format, saved in a Web Application Description Language (WADL) file. The WADL file describes the resources provided by a service and the methods used to access the service.

Like a Web Service, you import a Web application service into OpenText Functional Testing. The resources and methods are then displayed in a hierarchy like a REST service, in a Service/Resource/Method hierarchy.

The URL for a Web application is defined in the XML of the WADL file. You can, however, define other HTTP properties and add input and output parameters for an activity's methods.

If you import a WADL from a URL, you cannot edit the WADL's properties manually.

Like REST services, you can define parameters and their values at all levels of the Web Application hierarchy. You can then pass these parameter values to lower levels of the hierarchy.

The imported Web Application service methods serve as a prototype for test steps. You can modify the parameter values of a method after dragging a method to the canvas.

Back to top

Network Capture Activities

Network capture activities enable you to create test steps by recording network traffic. Importing a network capture file is another way to create test steps measuring the network activity of your application or Web service.

Instead of using the standard Network activities to design steps for your application's network processes, perform a network capture, and use the captured information as a basis for your test.

Using a network capture program, capture the network traffic for your application or Web service into a saved fill and then import this file into OpenText Functional Testing.

OpenText Functional Testing takes the TCP network stream and creates test steps based on the request and response information for each TCP stream in the network traffic capture.

Based on the request and response information, OpenText Functional Testing creates a test activity differently:

These activities are not stored in the Toolbox pane. If you need to reuse the steps in your test, you can reimport the network capture file or cut and paste the existing steps into your test.

For more details, see Import a Network Capture file.

Back to top

.NET Assemblies

The .NET importer lets you create activities for testing APIs in the form of .NET assemblies. You can interface with the types defined in the assembly.

Begin by importing the .NET assembly into your test. The Toolbox pane then displays the assembly as an activity and you can add a .NET activity on to the canvas.

When you import a .NET assembly, it saves a local copy of the assembly with the test. This makes the test portable and allows you to copy it to another machine. If the assembly calls other assemblies, the test may not run until you copy the additional assemblies to the new machine.

For more details, see Import and create a .NET Assembly API test step.

Back to top

SAP-based Services

Create additional activities by importing SAP Intermediate Documents (IDoc) and Remote Function Calls (RFC).

These activities can be useful for testing the SAP server response in several common scenarios:

• Sending an IDoc to an SAP server, and confirming that the IDoc was sent

• Checking an IDoc's status on the SAP server

• Calling an RFC in SAP and ensure that it returned the expected results

These activities can be also be useful when upgrading a system to verify that the integration patterns are still functional, such as Aggregator, Enricher, Router, Translation, Bridge, or Splitter.

For more details, see Create an SAP API test step.

Back to top