Environments

Environments keep your development, test and production data apart. The same template, with the same version, reads the development database while you design it and the production database when your ERP renders it, without a connection string in the template.

What an environment is#

An environment belongs to a workspace and has a key (used by the API: production), a name and a production flag. It decides one thing: which connection of each data source a query uses. It does not hold templates or versions of its own.

The default environments#

developmentDevelopment

Where you design and test. The Designer uses it by default.

stagingStaging

For acceptance tests against a copy of production data.

productionProduction

Your real data. Flagged as production: shown in red in the environment selector; test keys cannot use it.

Add and edit environments#

• In the workspace settings, Environments (permission workspace.manage: admins and owner): Add an environment with a key, a name and the production flag, or change the name, order and flag of an existing one.
• Keys start with a lower-case letter, then lower-case letters, digits and hyphens, at most 32 characters (for example uat or customer-test), unique in the workspace. A key never changes once created; environments cannot be deleted.

Connections per environment#

Each data source has at most one connection per environment, each with its own host, credentials and mode (gateway or direct). A typical setup:

developmentgateway

ERP_DEV on the development server, through the gateway of the office.

staginggateway

ERP_TEST, a nightly copy of production.

productiongateway

ERP_PROD, through two gateways for high availability.

If the environment of a request has no connection for a data source, the request fails with DATA_SOURCE_NOT_CONFIGURED: Prynt never falls back to another environment's database.

Environments in the Designer#

The environment selector at the top of the application decides the connection used by the SQL editor, the database explorer, dataset tests, previews and render tests. It starts on Development; production environments are highlighted so you always know when you are looking at real data.

Environments in the API#

A render reads the data of the environment named in the request's environment member, or else of the API key's default environment. The response says which one it used in the X-Environment header.

curl -X POST https://api.prynt.it/api/v1/render \  -H "Authorization: Bearer prynt_test_..." \  -H "Content-Type: application/json" \  -d '{ "template": "INVOICE", "environment": "staging", "parameters": { "DOCUMENT_ID": 18425 } }'

ENVIRONMENT_NOT_FOUND404

No environment with this key in the workspace.

ENVIRONMENT_NOT_ALLOWED403

A test key asked for a production environment.

DATA_SOURCE_NOT_CONFIGURED422

A data source of the template has no connection for the environment.

Live and test keys#

• Every API key is live (prynt_live_…) or test (prynt_test_…) and has a default environment, chosen when you create it.
• Without a choice, live keys default to production, test keys to development.
• Test keys can never use an environment flagged as production, neither as default nor per request: a test system cannot read production data by mistake.

See Authentication.

Environments and versions#

Versions are not promoted from one environment to another: a template has one current version for the whole workspace, and every environment renders it (or the version named in the request). To try a new version against staging data before your production systems print it, preview the draft in the Designer with the Staging environment selected, or publish it and render it from your test system with "environment": "staging"; a rollback brings the previous version back at once.