Skip to content
PYD ENTERPRISES

API tooling · Export

PYD ENTERPRISES and Postman

Export Postman Collection v2.1 files with one request per synthesized operation, example bodies drawn from equivalence fixtures, and test scripts that assert legacy outputs.

Postman logo

Postman

API tooling

Export
loan-accrual.postman_collection.json (excerpt)JSON
1{
2 "info": { "name": "Loan accrual (LNACCR02)", "schema": "https://schema.getpostman.com/json/collection/v2.1.0/collection.json" },
3 "item": [{
4 "name": "getDailyAccrual: R3 boundary 365/360",
5 "request": { "method": "GET", "url": "{{baseUrl}}/loans/LN0004471/accrual?asOf=2026-03-31" },
6 "event": [{ "listen": "test", "script": { "exec": [
7 "const b = pm.response.json();",
8 "pm.test('accrual matches LNACCR-0412', () => pm.expect(b.dailyAccrual).to.eql('13.89'));"
9 ] } }]
10 }]
11}

From extracted interface to runnable requests

When PYD ENTERPRISES synthesizes an OpenAPI 3.1 document from a CICS COMMAREA, an EJB remote interface or a WCF service contract, it already knows each operation's inputs and outputs and, from the behavioral test generator, a set of concrete input and output pairs taken from real execution branches. The Postman export turns that into a Collection v2.1 file your developers and testers can open immediately.

  • One folder per legacy program or service, one request per operation.
  • Request bodies populated from equivalence fixtures, so the first request a developer sends is a realistic one, not an empty schema.
  • Collection variables for base URL and authentication, so the same collection points at a developer laptop, a staging environment or the new service in production.
  • Test scripts per request that assert the response fields the legacy program would have produced for that input, with decimal tolerances matching the original rounding (for example ROUNDED half-up to two places).

Running collections in CI

Collections are plain JSON files, so they belong in the target service's repository. Most teams run them with Newman, Postman's command-line collection runner, as a stage in their pipeline against the new service. A failure means the new implementation disagrees with the behavior PYD ENTERPRISES extracted from the legacy code for that branch, and the failing request names the rule ID and source lines it was generated from.

Collections complement the full fixture suites from the behavioral test generator rather than replacing them: fixtures cover every boundary for every decision, while the collection gives developers a curated, readable subset for daily use.

Keeping collections in step with the spec

Each export is regenerated from the approved OpenAPI baseline. Request names and IDs are stable across exports, so diffs show only real changes: a new operation, a renamed field, a tightened constraint. PYD ENTERPRISES never uploads collections to a Postman workspace on its own; you import the file, or commit it and let your team's existing workflow pick it up.

FAQ

Postman questions.

Do we need a Postman account to use the export?

No. The export is a standard Collection v2.1 file. You can run it with Newman in CI without signing in to anything.

Why are decimal values strings in the assertions?

Legacy COMP-3 amounts are exact decimals. PYD ENTERPRISES' JSON Schema exports carry them as strings with a pattern by default so binary floating point never changes a cent; you can switch to numbers if your target service uses them.

How many requests does a collection contain?

One per operation, each with one curated example. The complete boundary suites live in the behavioral test generator output, which can contain thousands of fixtures.

See the Postman flow on your own code.

Run PYD ENTERPRISES on 100,000 lines of COBOL or Java in your private VPC and review OpenAPI specs and DMN tables tomorrow.