Testing a running API flow

To test a running flow in your App Connect Designer instance, complete the following steps:

1. If the flow is not already open, click Dashboard in the navigation pane and then click the flow tile.
   • If your App Connect Designer instance is running in IBM® Cloud Pak for Integration, the Designer tab is shown by default in the API editor.
     
   • If your App Connect Designer instance is running in a standalone deployment, the Define tab is shown by default in the API editor.
     
2. Click the Test tab.
   • If your App Connect Designer instance is running in IBM Cloud Pak for Integration, the Overview page displays the API type, the protocol, the base URL for the API endpoint, and the security scheme. If the API was automatically published to your API Connect instance when you started the flow (as described in IBM Cloud Pak for Integration only: Creating flows for an API from scratch), the API endpoint is provided by the Gateway service in API Connect. Otherwise, the endpoint is supplied by your App Connect Designer deployment.
     
   • If your App Connect Designer instance is running in a standalone deployment, the Overview page displays the API type and the base URL for the API endpoint. To the right of the Overview title, a tag is provided for each model that is defined in the API flow.

     
     A Download Open API Document link is also provided for the OpenAPI document that describes the API. If you download this document, it is saved as a YAML file to the default download location that is configured for your browser. The format of the file name is flowName-version.yaml; for example, Customer API-1.0.0.yaml. The version number is derived from the version of the API in the OpenAPI document, and is always set to 1.0.0.

     

   The left pane provides a Filter menu and lists the operations that are implemented for the API flow, and the model definitions. You can use the Filter menu to change how the operations are labeled or grouped in this pane. (The operations can be grouped by model name.)

   

   From the left pane, you can click each operation to view its details and test the behavior. Notice that the tag shown (above the Details and Try it tabs) will identify the model that an operation belongs to.

   For each operation, the Details tab displays the following information:

   • The HTTP method and request for the operation.
   • The authentication method (security scheme) that the API uses.
   • The header parameters in a collapsible section.
   • The body, path, or query parameters with examples, and the schema if relevant, in collapsible sections. The parameters that you see will depend on the operation's settings.
     
   • Tooling languages that can be used when making the request, and a code sample for calling the operation in the selected language.
   • Response status codes for the operation, and the response body schema with an example.
     

   You can also click Definitions in the left pane and expand the sections to view the schema definition for each model, and an example.

   
3. To test any of the API operations, complete the following steps:
   1. Click the operation and then click the Try it tab.
      Generated security credentials are displayed together with the request parameters.

      • If your App Connect Designer instance is running in IBM Cloud Pak for Integration and meets the requirements for integrated authoring (previously termed co-authoring), the Security section indicates that a Client ID security scheme will be used with an X-IBM-Client-Id parameter to pass the credentials in the request header of the API.
        

        If you want to call the operation by using one of the supplied code samples in the Example request section on the Details tab, you will need to include the Client ID value in the request. This Client ID is not visible in your App Connect Designer instance, so you will need to obtain it from your API Connect instance. From the API Manager UI, open the Sandbox or user-defined Catalog to which the API was published and then click the Applications tab to view and copy the Client ID.

        
      • If integrated authoring is not applicable for your App Connect Designer instance, basic authentication credentials will be used for the security scheme. If you want to call the operation by using one of the supplied code samples in the Example request section on the Details tab, you can copy the displayed username and password for use in the Authorization header of the request; for example, Authorization: Basic REPLACE_BASIC_AUTH. The REPLACE_BASIC_AUTH value is typically the Base64-encoded value of username:password.
        
   2. In the Parameters section, provide test data to pass in the request by using the Generate button to generate sample data or by specifying your own. The data required will vary by operation type and definition. For example:
      • For POST operations, you can generate sample data for body or query parameters. Or you can manually specify data that conforms to the body or query schema for the operation.
      • For GET operations, you can specify query or path parameters, and might need to specify an existing valid ID or some other value that uniquely identifies the data you are trying to retrieve from the target application.
      • For PUT operations, you can specify path or body parameters.

      The following example shows generated sample data in JSON format, for a POST operation that creates a contact in Salesforce. (In this particular example, we'll delete the CustomerID entry from the sample data because an ID does not need to be provided when creating a contact in Salesforce. Instead, Salesforce will generate an ID for the newly created contact and return it in the response. The CustomerID entry is generated by default in the sample because it was defined as one of the properties for the Customer model.)

      
   3. Click Send to invoke the API operation and then review the request and response that are displayed.

      For our POST example, the Response section displays the success code that is returned (201 Created), the headers, and the CustomerID value that represents the contact ID assigned by Salesforce.

      
   4. If relevant for the operation, check for the expected results in the target applications.

      For our POST example, we can see that our generated sample data was used to create a contact in our Salesforce instance. Notice that the contact ID in the URL for the Salesforce record is identical to the CustomerID value that is shown in the Response section in the test window.