Testing flows during development

You can use auto-generated or custom sample data to test the mappings and data transformations for the nodes in a flow.

About this task

When you map a field to a value from a previous node in your flow, you can see some sample data that represents the content of that field. If you apply JSONata to that mapping, the sample data is transformed to show the result.

Tip: Testing mappings and transformations for a field affects only the sample data that is shown for the field in the flow editor. This type of testing doesn't affect your connected applications.

To use sample data to test the mappings and transformations in your input fields, complete the following steps.

1. Open the flow that you want to test in App Connect Designer.
2. In the flow editor, select a node in your flow, then click Sample data.
   

   Alternatively, you can select a field then click Edit to open the Context and sample data pane with focus on the sample data for the selected field.

   

   If you have more than one mapping in a field, you can also click the mapping and select Edit sample data from the menu.

   
   When the Context and sample data pane opens, you can expand the fields for each of the previous nodes in the flow. The initial set of sample data depends on the field type:

   • String fields have a sample data value of SampleFieldName.
   • Integer fields have a value of 1.
   • Boolean fields have a value of true.
   • Date fields have a value of 1985-04-12T23:20:50.52Z.

   
3. In the Context and sample data pane, you can edit any of the sample data fields with your own custom values. Alternatively, click Regenerate sample data to automatically generate a set of more realistic sample values, such as names, addresses, and ID numbers.
   

   Changes that you make to the sample data in the Context and sample data pane are reflected immediately in the sample data for the node. The changes are also reflected in any later nodes in the flow that reference those mappings. These changes persist while the flow editor is open. If you applied JSONata functions to the mapping, the sample data is transformed to show the result of those functions.

4. To close the Context and sample data pane, click either Close or Sample data.
   

To test the effect of an action on a target application, trigger the action with sample data, then review the test results that the application returns.

To test the settings for an action, complete the following steps.

1. Open the flow that you want to test in App Connect Designer.
2. In the flow editor, select an action node in your flow, then click Sample data.
   
   When the Context and sample data pane opens, you can expand the fields for each of the previous nodes in the flow. The initial set of sample data depends on the field type:

   • String fields have a sample data value of SampleFieldName.
   • Integer fields have a value of 1.
   • Boolean fields have a value of true.
   • Date fields have a value of 1985-04-12T23:20:50.52Z.

   
3. Either edit the sample data to provide realistic values or click Regenerate sample data, which automatically generates a set of more realistic sample values, such as names, addresses, and ID numbers.
   Tip: Make sure that the sample data is appropriate for the type of action that you're testing. If you're retrieving data by using an ID or email address, the sample data must provide a valid ID or email address that exists in the target application. Or if you're creating a record, the sample data must match any special format that the target application requires for certain fields, such as an email address of abc@xyz.com instead of SampleEmail.
4. To test the action with the provided sample data, click Test action.
   

   The action is completed once in your connected account. In the previous example, a customer is created in Shopify by using sample data for a new lead in Salesforce. When the action is completed, a test result notification is shown.

   
5. To see the test result details that were returned from the application, click View details to open the Test results pane. This pane has Input and Output tabs. The results are shown on the Output tab as a list of values for the fields of the created or retrieved object. The Input tab shows the content of the request.
   In the Test results pane, click the Code icon to see the JSON output for the test. You can then copy this output by clicking the Copy icon .

   

   Tip: Not all properties are shown in the Test results pane. To see all input and output properties in JSON format, use the Code view.

   If a triggered action on a target application fails with an error, the test notification shows that the test failed. Click View details to find more information about the error.

After you configure all the nodes in a flow, you can test the effect of the flow on its target applications by using sample data and reviewing the test results.

About this task

Attention: Testing an action in this way completes the actions on the target applications that you're connected to. Before testing, verify that the connected accounts for the actions are appropriate for testing. You can use one account for testing, then use a different account when you deploy the flow.

If you enabled App Connect for end-to-end monitoring in IBM® webMethods Hybrid Integration, flows that you test with sample data aren't shown as part of end-to-end monitoring.

To test an event-driven or API flow, make sure that the actions in your flow are connected to appropriate accounts, such as your Salesforce developer account. And make sure that your flow doesn't have any validation errors. When these conditions are met, the status of the flow is Draft (ready to deploy) and the Test flow option is available in the flow editor.

Restriction:

• When you test a flow that contains a For each node, the node processes only the first three items that it receives.

To test all the actions in a flow, complete the following steps.

1. Open the flow that you want to test in App Connect Designer.
   If you're testing an API flow, open the API flow, then click Edit flow for the appropriate operation.

   
2. In the flow editor, specify realistic sample data for each node in your flow. Select an action node in your flow, then click Sample data.
   
   When the Context and sample data pane opens, you can expand the fields for each of the previous nodes in the flow. The initial set of sample data depends on the field type:

   • String fields have a sample data value of SampleFieldName.
   • Integer fields have a value of 1.
   • Boolean fields have a value of true.
   • Date fields have a value of 1985-04-12T23:20:50.52Z.

   
3. Either edit the sample data to provide realistic values or click Regenerate sample data, which automatically generates a set of more realistic sample values, such as names, addresses, and ID numbers.
   Tip: Make sure that the sample data is appropriate for the type of action that you're testing. If you're retrieving data by using an ID or email address, the sample data must provide a valid ID or email address that exists in the target application. Or if you're creating a record, the sample data must match any special format that the target application requires for certain fields, such as an email address of abc@xyz.com instead of SampleEmail.

   Repeat this step for each node in your flow.
   The following example shows the Request node of a simple flow for an API that retrieves contact details from Salesforce by ID. In the Context and sample data pane, the default sample data for the CustomerID request parameter is overwritten with an actual contact ID from the connected Salesforce instance.

   

   The Salesforce Retrieve contacts action defines the retrieve by ID condition and indicates that the custom sample ID from the Request node is used to call Salesforce.

   

   The Response node defines the status code and contact data that is returned for a successful response.

4. When you're happy with the sample data for all the nodes in the flow, test the flow.
   • If you're testing an API flow, click Test flow.
     
   • If you're testing an event-driven flow, click Test flow > Using sample data.
     
5. If your connected applications are appropriate for testing, click Test.
   When you test a flow by using sample data, the flow runs once and completes all the actions in your connected accounts. When the flow processing completes, a test result notification is shown.

   
6. To see the test result details that were returned from the application, click View details to open the Test results pane. The results are displayed on the Output tab. You can also see the content of the request on the Input tab.
   

   In the Test results pane, click the Code icon to see the JSON output for the test. You can then copy this output by clicking the Copy icon .

   

   Tip: Not all properties are shown in the Test results pane. To see all input and output properties in JSON format, use the Code view.

   For event-driven flows, successful test results show the message The flow test completed successfully. You can check the target applications to verify that you can see the expected results.

   

   If a triggered action on a target application fails with an error, the test notification shows a failed result, and the details provide more information. In the following example, a sample ID was generated to test the flow, which resulted in a failure because that contact ID doesn't exist in the connected Salesforce instance.

   

You can run an event-driven flow temporarily in the flow editor to verify its behavior before you deploy it.

About this task

Attention: Testing a flow in this way completes all the actions on the target applications that you're connected to. Before testing, verify that the connected accounts for the actions are appropriate for testing. You can use one account for testing, then use a different account when you deploy the flow.

You can start a flow to test it in the flow editor. When you test a flow with real data, the flow is triggered whenever your source application is updated while the flow is running in the flow editor. The flow remains active until you click Stop test.

Integration runtime hibernation: When you test flows in App Connect Designer, they run in a default integration runtime, and continue to run while you are logged in to your instance. After you are logged out for some time, the default integration runtime hibernates to save resources, and your development flows in App Connect Designer stop. When you log in again, the default integration runtime is restarted, and you can then restart your flows.

To test an event-driven flow with real data, make sure that the actions in your flow are connected to appropriate accounts, such as your Salesforce developer account. And make sure that your flow doesn't have any validation errors. When these conditions are met, the status of the flow is Draft (ready to deploy) and the Test flow option is available in the flow editor.

To test your flow with real data, complete the following steps.

1. Open the flow that you want to test in App Connect Designer, then click Test flow > Using real data.
   Alternatively, open the menu on the flow tile on the Designer dashboard, then click Test using real data.
2. If your connected applications are appropriate for testing, click Test.
   The status of the flow changes to Preparing to test while the flow is temporarily deployed to the default integration runtime. When the flow is ready to be tested, the status changes to Testing.
3. In the source application of your flow, complete the event activity that triggers the flow.
   For example, to trigger the following flow, you create a contact in the Salesforce instance that is linked to Salesforce Account 1.

   
   Tip:

   • To test a flow without using production accounts for applications, you can set up test accounts for the event and actions in the flow.
   • You can test the sequence of actions in a flow without completing the trigger event. Temporarily replace the event in the flow with a Scheduler event, and select Also run the flow when it's first switched on.

   When you test a flow by using real data, the flow remains active and runs every time that the event triggers it. The flow completes all the actions in your connected accounts.

4. Check the target applications to verify that you can see the expected results.
   For example, check your Asana instance to verify that a task was created to process actions that are related to the new Salesforce contact.

   If streamed events trigger the flow, actions on applications are completed soon after the flow is triggered. If polled events or a Scheduler event trigger the flow, actions on applications are completed according to the configured schedule.

5. When you finish testing the flow, click Stop test.
   The status of the flow returns to Draft (ready to deploy).

When you create an API flow, the definition provides an API that you can call. Verify the behavior of an API by using the built-in test facility to call the endpoints for each API operation.

About this task

Attention: Testing an API in this way completes actions on the target applications that you're connected to. Before testing, verify that the connected accounts for the actions are appropriate for testing. You can use one account for testing, then use a different account when you deploy the flow.

If you enabled App Connect for end-to-end monitoring in IBM webMethods Hybrid Integration, flows that you test with sample data aren't shown as part of end-to-end monitoring.

You can test an API in the flow editor before you deploy it. You can also use sample data to test the flow that implements an API operation instead of the API itself. For more information, see Testing a flow with sample data.

To test an API, make sure that all operations have flows and that the actions in your flows are connected to appropriate accounts, such as your Salesforce developer account. And make sure that your flows don't have any validation errors. When these conditions are met, the status of the flow is Draft (ready to deploy) and the Test API option is available in the flow editor.

When you test an API, the API remains active until you click Stop test.

Note: When you test flows in App Connect Designer, they run in a default integration runtime, and continue to run while you are logged in to your instance. After you are logged out for some time, the default integration runtime hibernates to save resources, and your development flows in App Connect Designer stop. When you log in again, the default integration runtime is restarted, and you can then restart your flows.

To test your API, complete the following steps.

1. Open the API that you want to test in App Connect Designer and click Test API.
   Alternatively, open the menu on the flow tile on the Designer dashboard, then click Test API.
2. If your connected applications are appropriate for testing, click Test.
   The status of the API changes to Preparing to test while the flow is temporarily deployed to the default integration runtime. When the API is ready to be tested, the status changes to Testing and the Test tab is available.
3. Click the Test tab.
   The Overview page shows the API type, protocol, base URL for the API endpoint, and the security scheme. If the API was automatically published to your API Connect instance when you tested the flow, the API endpoint is provided by the Gateway service in API Connect. (For more information, see Creating flows for an API from scratch.) Otherwise, the endpoint is supplied by your App Connect Designer deployment.

   

   When the API endpoint is supplied by App Connect, the endpoint is different depending on whether the API is deployed or being tested.

   • When you test an API, the API is deployed temporarily to the default integration runtime. Therefore, the API endpoint begins with https://default-integration-runtime; for example:

     https://default-integration-runtime-https-ac0abcd2def.p-vir-d1.appconnect.ibmappdomain.cloud/Bookstore_API

   • When you deploy an API, the API is deployed to the runtime that you create. Therefore, the API endpoint begins with the name of your runtime; for example:

     https://my-custom-ir-https-ac0abcd2def.p-vir-d1.appconnect.ibmappdomain.cloud/Bookstore_API

   The Test tab 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. (You can group the operations by model name.)

   

   Click each operation to view its details and test the behavior. The tag that is shown identifies the model that an operation belongs to.

   For each operation, the Details tab shows 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 depend on the settings for the operation.
     
   • Languages that can be used when you make 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 and expand the sections to view the schema definition for each model, and an example.

     
4. To test an API operation, select the operation, then go to the Try it tab.
   Generated security credentials and request parameters are shown.

   If unified authoring is enabled, the Security section indicates that a Client ID security scheme is used with an X-IBM-Client-Id parameter to pass the credentials in the request header of the API.

   

   To call the operation by using one of the supplied code samples in the Example request section on the Details tab, include the Client ID value in the request. This Client ID is not visible in your App Connect Designer instance, so you 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. Then click the Applications tab to view and copy the Client ID.

   

   If unified authoring isn't enabled, basic authentication is used for the security scheme. You can call the operation by using one of the supplied code samples in the Example request section on the Details tab. Copy the displayed username and password to 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.

   
5. In the Parameters section, provide test data to pass in the request by clicking Generate to generate sample data or by specifying your own. The data that is needed varies by operation type and definition.
   • 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. You might also 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 product (a book) in Salesforce.

   
6. Click Send to call the API operation, then review the request and response that are shown.
   The following example shows the request and response for a POST operation to create a customer in Salesforce. The response includes the success code that is returned (201 Created), the headers, and the CustomerID value that represents the contact ID that Salesforce assigns.

   
7. If relevant for the operation, check for the expected results in the target applications.
8. When you finish testing the API, click Stop test.
   The status of the API returns to Draft (ready to deploy).