Postman resources migration

You can find information about the Postman resources that are migrated in to HCL DevOps Test Integrations and APIs (Test Integrations and APIs).

Mapping of Postman resources

You can find information about how the Postman resources are mapped to the corresponding resources in Test Integrations and APIs during the migration process as described in the following table:

Postman resources

Test Integrations and APIs resources

Collections

Service components

Folders

Service components

Environments

Environments

Variables

Tags
Note: Tags are created based on the scope of the variables.
Restriction: If a collection-level variable with the same name but with different values is used in multiple collections, during the migration process only one tag is created with the name of the variable and only one value of the variable selected randomly from any collection is retained.

Pre-requests

Function actions

Requests

Operations and transports

The connection details in requests such as host, port, SSL configuration, and so on are mapped to transports during migration.

The resource path and headers are mapped to corresponding fields in the operation configuration.

Request parameters

Web URL schema parameters

Tests

Test assertions

Note: All tests are merged into a single assert action.

Example requests and responses used by a mock server in Postman

Stubs are created with the Postman example requests and responses as events.

The other parameters in the requests and responses are migrated to their corresponding parameters in Test Integrations and APIs.

Documentation

Document options
Note: Additional information that corresponds to the information that you entered in Postman for the collections and the elements contained in collections are mapped.

Environments and variables

All the Environments in the Postman JSON file are migrated as RIT environments and variables created under them. One of the Environments is randomly assigned as the current environment.

Variables are split into multiple variables to match the resource model in Test Integrations and APIs.

For example, consider that a request was defined in Postman with a URL as a variable. If the URL variable <payment_system_url> was defined with a value as https://paymentsystem:9090/makepayment, then during the migration, Test Integrations and APIs splits the Postman variable into different Test Integrations and APIs variables as follows:
  • payment_system_host as paymentsystem
  • payment_system_port as 9090
  • payment_system_url as /makepayment

Pre-requests and requests

The pre-request script in Postman request is migrated as a Function action in Test Integrations and APIs.

For example, if a script in Postman is created as shown in Pre-request script in Postman. After migration, the script is migrated as a Function action as shown in Function action in Test Integrations and APIs.
Figure 1. Pre-request script in Postman
Figure 2. Function action in Test Integrations and APIs

Query parameters

If a request has query parameters then a Web-URL schema is created and associated with the corresponding Operation inTest Integrations and APIs after migration.
Note: Test Integrations and APIs does not create any corresponding resource for a query string, which is part of a variable in Postman.
For example, Query parameters in Postman shows the request that has query parameters while Web-URI in Test Integrations and APIs shows the Web-URI created in Test Integrations and APIs that corresponds to the query parameters.
Figure 3. Query parameters in Postman
Figure 4. Web-URI in Test Integrations and APIs

Tests

The tests in the Postman request are migrated as an Assert action in Test Integrations and APIs.

Certain fields in Postman requests are mapped to assertions in the Receive Reply action in the fields such as Response code, Reason phrase, and Request timeout.

For example, if a test in Postman is as shown in A test in Postman, then the assert action that it is created after migration in Test Integrations and APIs that corresponds to the Postman test is shown in Assert action in Test Integrations and APIs.
Figure 5. A test in Postman
Figure 6. Assert action in Test Integrations and APIs

Headers and body

The Headers and Body in Postman requests are migrated as HTTP Headers and Body in messages in a Send Request action step.

For example, The headers configured in a Postman request shows the headers configured in a Postman request and The body configured in a Postman request shows the body configured in the request. After migration to Test Integrations and APIs, the headers and body in the messages in a Send Request action step are as shown in The migrated headers and body in a Send Request in Test Integrations and APIs.

Figure 7. The headers configured in a Postman request
Figure 8. The body configured in a Postman request
Figure 9. The migrated headers and body in a Send Request in Test Integrations and APIs

Tests that are not migrated

If certain Postman tests are not migrated to Test Integrations and APIs, you can find information about such tests displayed under a Fail action.

For example, you can find the information about the test that was not migrated in the Fail action under the Test Steps for the test created in Test Integrations and APIs. You can view the details by double-clicking the Fail action.
Figure 10. The Fail action as a Test Step in Test Integrations and APIs

Virtualized services or stubs

You create requests and responses that you expect from the service endpoint. When the actual service endpoint is not available, you can mock a request and response. You can create an example request and an example response that are used by a mock server in Postman.

When such example requests and example responses are migrated to Test Integrations and APIs, stubs are created with the example requests and example responses as events in the stub.

If the service endpoint was configured in Postman, then in the migrated resource the physical transport is created with the service endpoint as the host. For example, if the service endpoint was gmail.com, the physical transport is created with gmail.com as the host and you must configure the HTTP proxy in the transport for the request to be sent to the stub in Test Integrations and APIs.

If a mock server was configured as the host to receive requests and send responses, then in the migrated resource the stub endpoint is created that has the host and port configured as localhost and 443. For example, if the URL in the Postman requests has mock.pstmn.io, then the host for the transport is configured as localhost. You might have to configure the client application to route traffic to where the stub is run. You might have to change the server settings or use the HTTP proxy to configure the host and port to represent the endpoint that you want to mock.

The other parameters in the requests and responses are migrated to their corresponding parameters in Test Integrations and APIs.

For example, if you created an example request and example response as shown in An example request and response in Postman.

Figure 11. An example request and response in Postman
image of the postman example request and response
After migration to Test Integrations and APIs, stubs that are created are displayed in the Test Factory view as shown in Stubs created in Test Integrations and APIs.
Figure 12. Stubs created in Test Integrations and APIs
image of the stubs created displayed in the Test Factory view
The stub for the request that is created during migration can be as shown in Stub created in Test Integrations and APIs.
Figure 13. Stub created in Test Integrations and APIs
image of the stub for request2
The stub endpoint details of the stub created, when you open the physical resource can be as follows:
Figure 14. Stub endpoint details in Test Integrations and APIs
image of the stub for request2