Data market checkout targets

The checkout target setting controls where Dawiso raises data cart access requests, one request per product in the cart. Route requests into the system your organisation already uses for approvals, instead of adopting a second one for data market access.

Three targets are available:

• Gate: Posts to dawiso-gate. This is the default.
• Jira Service Management: Raises one customer request per product.
• ServiceNow: Creates one record per product in a table you choose.

Only one target is active at a time, and it applies to the whole environment.

Choose the target

Navigate to Settings > General > Features and use the Checkout target picker. Selecting Gate, Jira Service Management, or ServiceNow reveals that target’s own configuration fields. Save applies the change immediately. No restart is needed.

Connect ServiceNow

Records are created through the ServiceNow Table API. Authentication decides which credentials Dawiso presents, and which of the fields below you need to fill.

Field	What it is
ServiceNow instance URL	Your instance, for example https://mydomain.service-now.com.
Authentication	How Dawiso authenticates. See Choose an authentication method.
User name	The integration account Dawiso authenticates as. Not used by client credentials.
Password	Stored encrypted and never shown again. Leave the field empty to keep the stored password.
Client ID	From the OAuth application registry entry in ServiceNow. OAuth modes only.
Client secret	Stored encrypted and never shown again. Leave the field empty to keep the stored secret. OAuth modes only.
Table	The table each record is created in, for example sc_request or incident.

The table name becomes part of the request URL, so it must be a plain table name: letters, digits, and underscores only.

Choose an authentication method

Authentication	What you fill in
User name and password (Basic)	User name, Password
OAuth: user name and password	Client ID, Client secret, User name, Password
OAuth: client credentials	Client ID, Client secret

Dawiso derives the token endpoint from the instance URL, so there is nothing else to configure there. OAuth: client credentials additionally needs the OAuth application registry entry in ServiceNow to be bound to a user, configured in ServiceNow itself.

Connect Jira Service Management

Field	What it is
Jira URL	Your site, for example https://mydomain.atlassian.net.
Service account email	The account Dawiso authenticates as.
API token	Stored encrypted and never shown again. Leave the field empty to keep the stored token.
Service desk ID	The service desk requests are raised in.
Request type ID	The request type each cart item uses.

Configure Gate

Gate needs no connection setup of its own, but its payload mapping and sync behavior are configurable on the same screen.

Payload mapping

These settings map a data product’s metadata into the fields Gate expects. They existed in the database before this settings screen did, so this is their first admin-facing UI.

• Platform fallback: the physical platform Dawiso assumes for a data product (e.g. databricks) when it can’t determine one another way.
• Valid platforms: a comma-separated list of the platforms Gate accepts (e.g. databricks,bigquery,snowflake,fabric,jsm).
• Default tier and Default row scope: defaults applied to an output port’s checkout (e.g. standard and filtered) when the data product itself doesn’t specify them.
• Target template: a token string, e.g. dawiso.products.{{product.name}}_{{product.id}}, used to compute the target catalog.schema.table location. Dawiso only uses this template when the output port doesn’t already have a valid catalog.schema.table of its own. The available tokens for your instance are shown in a hint banner above the field. Each dot-separated segment of the rendered result is sanitized to letters, digits, underscores, and hyphens, so a token that resolves to a name with spaces or punctuation still produces a valid location.
• Business confidentiality template, PII level template, and Row restriction template: token strings (e.g. {{product.confidentiality}}) that map a data product’s own classification metadata into the corresponding fields Gate expects when the product is checked out or pushed.

Sync settings

These settings were previously hardcoded Worker constants and are now configurable here.

• Nightly reconcile cron: a Quartz cron expression (default 0 0 2 * * ?, i.e. 2 AM daily) controlling when the nightly reconcile-by-absence job runs. This job keeps Dawiso and Gate’s data product and output port state in sync, catching drift that the event-driven path might have missed.

  A change to this field is validated for cron shape in the browser and validated again against Quartz’s parser when saved, but it only takes effect the next time the Worker service restarts. It’s read once when the Worker builds its schedule, not applied live.

• Retire safety ceiling percent: a whole number from 0 to 100 (default 5) that limits the nightly reconcile job. If more than this percentage of Gate’s known objects would be retired (deleted) in one reconcile run, the run aborts instead of proceeding, protecting against a bug or bad data wiping out most of Gate’s records in one pass. The ceiling never drops below 1 object, even for a small snapshot.

Both settings fail safe: an out-of-range retire ceiling falls back to the default of 5, and an unparseable cron expression falls back to the default schedule rather than the Worker failing to start.

For the Gate connection status, a live “Test connection” probe, and the metamodel readiness check, see the Data products panel on the General settings page.

Map the request fields

Both IT service management (ITSM) targets fill their request from templates you control, using your own wording and fields.

Templates substitute {{token}} placeholders. The Available template tokens panel above the template fields lists every token the environment accepts, read live from the server, so it never goes stale as tokens are added.

Tokens cover the order, the requesting user, the data product and its classification, and the terms the user requested:

• Order and requester: {{order.id}}, {{consumer.email}}, {{consumer.displayName}}
• Data product: {{product.name}}, {{product.domain}}, {{product.description}}, {{product.outputPorts}}
• Classification: {{product.piiLevel}}, {{product.confidentiality}}, {{product.visibility}}
• Ownership: {{owner.email}}, {{steward.email}}
• Requested terms: {{terms.purpose}}, {{terms.durationDays}}, {{terms.accessTier}}, {{terms.rowScope}}

Field mapping takes a JSON object that maps a field in the target system to a template, letting you populate fields beyond the summary and description:

{ "u_purpose": "{{terms.purpose}}", "u_data_product": "{{product.name}}" }

Save is blocked until the field mapping is valid JSON.

Attribute requests to the requester

By default, Dawiso raises every request as the integration account, not as the requesting user.

To attribute requests to the requester instead, set Caller (ServiceNow) or Raise on behalf of (Jira Service Management) to {{consumer.email}}. Both systems resolve that value against their own user directory, so this only works when your data consumers already exist there. That is why it is off by default. If the identity is unknown to the target system, it rejects the request.

What approvers see

Personal data reaches the target system only through the tokens you use. {{consumer.email}}, {{consumer.displayName}}, {{owner.email}}, and {{steward.email}} resolve to people, and {{terms.purpose}} is free text the requester typed. Remove them from your templates if the target system must not receive them.

Classification tokens are the opposite: {{product.piiLevel}} and {{product.confidentiality}} describe the data, not a person, and let an approver route a request without opening the catalog.

Partial results

Checkout reports each product separately. If some products are accepted and others rejected, the accepted ones are still created, and the cart shows the rejection reason for each one. A rejection from the target system carries that system’s own message; a connection or configuration problem shows as a generic error.

Troubleshooting

What you see	What it means
Every item rejected as not configured	The selected target is missing a required connection field. Check the URL, credentials, and (for ServiceNow) the table.
Every item rejected with a credentials error	The target system refused the stored credentials. On ServiceNow with Basic authentication this is usually the platform’s basic-auth restriction rather than a wrong password. Grant the integration account the snc_basic_auth_api_access role, or switch Authentication to an OAuth method.
A rejection quoting the target system	The target refused that specific request, usually a mandatory field its request type needs. Add it to the field mapping.
Requests appear under the integration account	Expected unless Caller or Raise on behalf of is set. See Attribute requests to the requester.