Postman resources migration

Mapping of Postman resources

You can find information about how the Postman resources are mapped to the corresponding resources in Rational® Integration Tester during the migration process as described in the following table:


Postman resources	Rational® Integration Tester 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 Rational® Integration Tester.
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 Rational® Integration Tester.

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, Rational® Integration Tester splits the Postman variable into different Rational® Integration Tester 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 Rational® Integration Tester.

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 Rational Integration Tester.

Figure 2. Function action in Rational® Integration Tester

Query parameters

If a request has query parameters then a Web-URL schema is created and associated with the corresponding Operation in Rational® Integration Tester after migration.

Note: Rational® Integration Tester 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 Rational Integration Tester shows the Web-URI created in Rational® Integration Tester that corresponds to the query parameters.

Figure 4. Web-URI in Rational® Integration Tester

Tests

The tests in the Postman request are migrated as an Assert action in Rational® Integration Tester.

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 Rational® Integration Tester that corresponds to the Postman test is shown in Assert action in Rational Integration Tester.

Figure 6. Assert action in Rational® Integration Tester

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 Rational® Integration Tester, 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 Rational Integration Tester.

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 Rational® Integration Tester

Tests that are not migrated

If certain Postman tests are not migrated to Rational® Integration Tester, 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 Rational® Integration Tester. You can view the details by double-clicking the Fail action.

Figure 10. The Fail action as a Test Step in Rational® Integration Tester

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 Rational® Integration Tester, 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 Rational® Integration Tester.

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 Rational® Integration Tester.

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

image of the postman example request and response — Figure 11. An example request and response in Postman

After migration to Rational® Integration Tester, stubs that are created are displayed in the Test Factory view as shown in Stubs created in Rational Integration Tester.

image of the stubs created displayed in the Test Factory view — Figure 12. Stubs created in Rational® Integration Tester

The stub for the request that is created during migration can be as shown in Stub created in Rational Integration Tester.

image of the stub for request2 — Figure 13. Stub created in Rational® Integration Tester

The stub endpoint details of the stub created, when you open the physical resource can be as follows: