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.
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, UFT 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 outputproperties 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.
To create REST service models in UFT, 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 Passing REST service properties.
- Import a service model from a Swagger API or OData REST Service API. UFT 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.
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 UFT. 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.
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 UFT.
UFT 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, UFT creates a test activity differently:
If the TCP stream request and response is compatible with or matches an already existing Web service, UFT creates a Web Service step.
If the TCP stream request has a SOAP request structure, UFT creates a SOAP Request step.
If the TCP stream is not similar to an existing Web service method or a SOAP request transaction, UFT creates a HTTP Request step.
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.
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.
Create additional actitivites 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, Splitter, and so forth.
For more details, see Create an SAP API test step.