Editing an operation

You can edit the component details of an operation in the operations editor.

Before you begin

You must have created an operation in a service component. See Creating an operation.

About this task

The properties of an operation that you can change are name, parent, message exchange pattern (MEP), stub page, references, Recording Studio color, and the linked OSLC-compliant change management system. The properties are technology-specific. The examples shown are for an HTTP transport. Therefore, the examples are different if you are working with another transport type, such as WebSphere MQ, Oracle Forms, SAP, Java, and so on.

An operation is a set of functions and their specified properties to which calls can be made.

You can edit any of the properties of the operation in the following ways:

Changing the name of an operation

You can change the name of an operation in the operation editor or by using the Rename option.
  1. Use the operation editor or use the Rename option.
    • To open the operation editor, double-click the operation or right-click it and select Open from the menu. Enter a new name for the operation in the Name field.
    • Right-click the operation, select Rename from the menu, and enter a new name for the operation in the Rename to dialog box.
    Note: The rename check is case-insensitive. If you only change the capitalization of the resource name, the OK button in the Rename dialog is not enabled.
  2. Click OK to save your changes and close the editor.

Changing the parent of an operation

You can change the parent of an operation in the operation editor.

  1. Open the operation editor.
  2. Click Parent. The Select a Resource dialog box is displayed.
  3. Locate and select the new parent component and click OK.

Changing the message exchange pattern for an operation

The MEP defines the pattern, schema, and binding for messages that are exchanged by the operation.
  1. Open the operation editor.
    The Message Exchange Pattern tab is highlighted, by default. Image of the message exchange pattern tab for the operation.
  2. Modify the various properties of the MEP as described in the table:
    Property Description
    Pattern Select the appropriate message pattern. Select Publish or Request/Reply.
    Schema Select the schema or format that is to be applied to each applicable message type.
    • Click Browse to locate and select a schema. For more information about schemas information, see the related links.
    • Click Clear to clear the current selection.
    • Click Properties to view and edit the WSDL message properties. For more information about WSDL properties, see the related links.
    Note: If you specify a Web URL schema for the Request, an additional row of fields is displayed between the Request and Reply rows. Use the Browse button to locate a sub-schema for the Body and Root fields.
    Binding Click Browse to select an existing transport to apply to the operations messages.
    Important: The binding settings apply only to tests because a transport is already selected in the Stub tab that is used for virtualization. See the Stub configuration information in the MEP tab.
    Depending on the transport, configure more message options by using the tabs below the transport selection. For more information about message transports, see the related links.
  3. Click OK to save any changes and close the editor. Otherwise, click or Cancel to close the editor without saving changes.

Changing the stub page for an operation

The Stub properties for an operation define the binding and timeout details that are used to create a stub from the operation.
  1. Open the operation editor and select the Stub tab. The Stub page of the Operation editor
  2. Modify the various properties in the dialog as described in the table:
    Property Description
    Transport Click Browse to select an existing transport that is to be applied to the operations Stubs. Depending on the transport, you can configure more message options by using the fields in the transport selection. For more information about message transports, see the related links.
    Message Type If available, which depends on the selected transport and formatter, select the type of message from the Message Type drop-down list.
    Filter resource path, Resource Path (HTTP transports only) If you select the Filter resource path check box and enter, for example, /customer in the Resource Path field, the resource path filters for /customer. The result, however, depends on the value you select from the Subpaths drop-down list. In this case, if you select Exact path, a request for /customer/orders does not match and HTTP server error 503, which means the service is unavailable is returned.
    Filter HTTP method(HTTP transports only) Select this option to filter requests by HTTP method type, such as GET and PUT. Select a method from the accompanying list. An HTTP server error 503 is returned if the following conditions are met:
    • An HTTP request is received
    • There is no stub currently running with a filter that matches the request
    The Subpaths drop-down list (HTTP transports only) This drop-down list enables the matching of subpaths. You can configure a stub to match any request where the first part of the path matches the filter. If the Resource Path is populated when an operation is created, you must select one of the following options:
    • Allow subpaths: This option enables the URL in the HTTP request to include any subpath following the specified Resource Path, that is, it can be an exact match, or it can start with that value and then can contain additional characters after that value. For example, if a stub is listening for messages with the /addNumbers resource path, and Allow subpaths is selected, the stub also receives messages destined for a resource named /addNumbers*, where * is any subpath. For example, it matches /addNumbers/mypath, /addNumbers/123/abc/mypath, /addNumbers/123/abc, and so on. This option is primarily meant for new operations created in Rational® Integration Tester 8.5.0 or later.
    • Exact path: This option is for matching only those requests whose paths exactly match the specified Resource Path.
    • Only subpaths: The URL in the HTTP request must start with the given value and must have additional characters after it. That is, stubs for such an operation do not receive requests that are an exact match for the given value.
    • Path Template: This option is for parametrized path parameters, such as in a Swagger, RAML or an OpenAPI 3.0 definition. When you use Path Template, the value in the Resource Path supports variable names enclosed in curly braces {}. For example, /shop/{productId}/cost. The name used by the variable can be empty, but if it is not then it must be alphanumeric. The only other allowable characters are underscore "_" and percent "%" for percent-encoding. The variables can appear in both the path and the query components. The only difference in match logic is what characters match. For a variable in the path, all characters are allowed apart from forward slashes "/", question marks "?" and number signs "#'. For the query string, the characters that do not match are the separator characters number sign "#" and ampersand "&".
      For example, for the template /shop/{product-id}/cost?currency={cur} the following matches:
      
/shop/foo/cost?currency=bar
/shop/text text/cost?currency=foo bar
      But the following does not match: 
      /shop/foo/bar/cost?currency=foo&bar
    The Allow subpaths and Only subpaths options are useful when you use path parameters, such as a Web URL schema.
    Example:

    You have a REST API that lists people, and you use a URL path such as /people/ to list all the people and /people/1 of the pattern /people/{id} to get the details of a specific person. You create an operation called List all with /people/ for the resource path and have Exact path selected, and another operation called Get person with /people/ for the resource path, but have Only subpaths selected. In this scenario, requests for the Get person operation are distinguished from those for the List all operation based on the ID that is at the end of their path. Alternatively, if you have only one operation with /people/ as the resource path to manage both the cases and you want the matching to be successful even if the path contains a person ID (path parameter value), then select Allow subpaths.
    Filter header values (HTTP transports only) Select this option to create a list of services whose messages are processed by the stub. Click New to add a header to the list. Provide the following information for each new header:
    Name
    The header type. Typically, the type is SOAPAction.
    Value
    No restrictions are placed on the value. In the SOAPAction case, specify a URI that identifies the service, enclosed in quotation marks.
    Note: SOAPAction header values are expected to be quoted. The quoted empty string and the unquoted empty string are treated as unequal values.

    By default, the Enabled check box is selected. If you want to temporarily disable the filter, you can clear this check box.

    You can click Edit to change the Name and Value fields, or click Delete to remove the header from the list.

    Always select the Participate option for stubs.
    Default Timeout Enter the minimum, maximum, and average response times in milliseconds that the stub is to use when it replies to requests.
  3. Click OK to save any changes and close the editor. Otherwise, click or Cancel to close the editor without saving changes.

Changing the references for an operation

The references show the dependencies that the selected operation has on other items within the system under test. The references that are displayed correspond directly to the dependencies that are displayed in the diagram.
  1. Open the operation editor and select the References tab.

    Direct references, which are no components between the operation and the dependency are displayed in the upper portion of the dialog. Indirect references, which are where one or more components link the operation with the dependency are displayed at the lower portion of the dialog.

  2. To add a reference, click Add and select the resource to which you want to create a dependency.
  3. To remove a reference, select it and click Remove.
  4. Click OK to save any changes and close the editor. Otherwise, click or Cancel to close the editor without saving changes.

Changing the Recording Studio color for an operation

When you are monitoring events in the Recording Studio perspective, events for each operation are displayed in their own unique color. This feature is especially useful if you are viewing events from multiple operations.
  1. Open the operation editor and select the Recording Studio tab.
  2. Click the color box next to Display Color to display the Select color dialog.
  3. Select the tab of the required color model. Select Swatches, HSB, or RGB and select the desired color.
  4. Click OK to save the new selection.
  5. Optional: Click Reset to revert to the original color, or click or Cancel to close the dialog without saving changes.
  6. Click OK to save any changes and close the editor. Otherwise, click or Cancel to close the editor without saving changes.

Change the preferred change management integration for an operation

Rational® Integration Tester can be integrated with OSLC-compliant change management systems for raising defects within the context of a Rational® Integration Tester test asset. If multiple change management integrations are configured in the current project, you can override an inherited integration from an operation or service component higher up the project resource tree or from the default integration under the Change Management tab. You can then specify a different integration to be used for items from the list.

To specify a different or non-default integration for the current operation and its child operations, you can enable the Override option and select an integration from the list.