Postman resources migration
You can find information about the Postman resources that are migrated in to Rational® Integration Tester.
Mapping of Postman resources
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.
- 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.
![](../images/img_postman_prerequest_1.jpg)
![](../images/img_postman_prerequest_2.jpg)
Query parameters
![](../images/img_postman_queryparams_1.jpg)
![](../images/img_postman_queryparams_2.jpg)
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.
![](../images/img_postman_test_1.jpg)
![](../images/img_postman_test_2.jpg)
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.
![](../images/img_postman_header.jpg)
![](../images/img_postman_test_1.jpg)
![](../images/img_postman_header_body.jpg)
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.
![](../images/img_postman_fail.jpg)
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](../images/img_postman_mock_req2.jpg)
![image of the stubs created displayed in the Test Factory view](../images/img_postman_mock_stub1.jpg)
![image of the stub for request2](../images/img_postman_mock_stub1_req2.jpg)
![image of the stub for request2](../images/img_postman_stub_host.jpg)