OpenText ITSM Data Connector

The BigPanda Unified Data Connector (UDC) syncs ITSM data from OpenText ITSM to provide context and insights for AI Incident Assistant (Biggy), AI Incident Prevention, and AI Detection and Response. Ingested data is securely stored and made available in the IT Knowledge Graph, powering accurate answers, deep analytics, trend analysis, and advanced capabilities.

This connector targets an OpenText ITSM instance that is fronted by an IBM API gateway (IBM API Connect or DataPower). The gateway wraps every record in an SMResponse envelope, and the connector reads that envelope on each response.

SMAX data connector

The OpenText ITSM Data Connector is separate from the OpenText SMAX connector.

Supported domains

The connector performs read-only (GET) syncs for the following ITSM domains. It writes one table per configured domain.

Domain	Endpoint	Envelope (envelope_path)	Record wrapper (record_path)	Cursor field	Primary key
`incident`	`/vwfsBigPandaIncidents`	`content`	`vwfsBigPandaIncident`	`lastUpdateTime`	`id`
`service_request`	`/vwfsBigPandaServiceRequests`	`content`	`vwfsBigPandaServiceRequest`	`lastUpdateTime`	`id`
`change`	`/vwfsBigPandaChanges`	`content`	none	`Tags.lastUpdateTime`	`identifier`

For incident and service_request, each list element wraps the record in a domain key, and the connector unwraps that inner key so the primary key and cursor field resolve at the row root. For change, each element exposes its fields directly.

Authorization

The connector supports two authorization methods: IBM API Gateway header authentication or HTTP basic authentication. Both are configured on the connection.

Create the required credentials for your chosen method, then send them to your BigPanda account team, who will finish the setup.

The connector also needs the gateway base URL. Provide the instance_url for your gateway, for example <https://your-gateway-host/path/to/itsm>. Resource paths are appended to this base URL.

Configure IBM API gateway header authentication

This method sends a client ID and client secret as gateway headers (X-IBM-Client-Id and X-IBM-Client-Secret) on every request. Provide the following to your BigPanda account team.

Field	Description
Instance URL	The gateway base URL. Resource paths are appended to it.
`client_id`	The client ID issued for your IBM API gateway.
`client_secret`	The client secret issued for your IBM API gateway.

Configure HTTP basic authentication

If you cannot use gateway header authentication, you can use HTTP basic authentication. Provide the following to your BigPanda account team.

Field	Description
Instance URL	The gateway base URL. Resource paths appended.
`username`	The username of the account used to authenticate.
`password`	The password of the account used to authenticate.

Sync preferences

Provide the following information about your sync preferences to your BigPanda account team.

Full collection sync

The gateway does not support a server-side "updated since" filter, so both sync modes iterate through the full collection on every run. Incremental mode then keeps only new or updated records. Plan initial and ongoing sync windows with this in mind, especially for large collections.

Required configuration

Option	Description
Mode	Choose `historical` or `incremental` (default `incremental`). Historical appends every record returned. Incremental keeps only new or updated records using a client-side cursor per domain.

Optional pipeline configuration

Option	Description
Start date	A date in `YYYY-MM-DD` format. Required for a historical sync. When set, it is also used as the initial incremental cursor.
End date	A date in `YYYY-MM-DD` format. Used for historical syncs only, to backfill a bounded window.

Performance configuration

Option	Description
Rate limit	The number of requests allowed per interval. The default is 5.
Rate limit timeout	The wait time, in milliseconds, after the rate limit is reached. The default is 1,000 ms.
Request timeout	The HTTP request timeout, in seconds. The default is 60 seconds.

Sync behavior

Each run pages through the full list for each configured domain, then writes the results to that domain's table.

Response validation: The connector validates the SMResponse.ReturnCode on each response. A ReturnCode of 0 indicates success and 9 indicates no records; the connector ends the page loop cleanly on 9. Other ReturnCode values cause the fetch to fail.
Pagination: List endpoints return a paged collection envelope that reports @start (a 1-based page index), @count (records in the page), and @totalcount (total available). The connector pages using start and count query parameters and advances start until the full collection is retrieved.
Incremental cursor: In incremental mode, the connector applies a client-side cursor per domain (for example, lastUpdateTime or Tags.lastUpdateTime) so a re-run with no changes yields approximately zero new rows.
Processing timestamp: Each record carries a _dlt_processing_time timestamp.

Output schema

For each configured domain, the connector produces one output table. The output schema follows these rules:

Each domain writes to its own table, named for the domain: incident, service_request, and change.
The primary key is the domain's configured primary_key: id for incident and service_request, and identifier for change. This is the identity and dedup key.
For incident and service_request, the connector unwraps the inner domain key from each list element, so record fields, the primary key, and the cursor field resolve at the row root rather than nested one level down. For change, fields are already exposed directly.
Each output record includes a _dlt_processing_time column that records when the connector processed the record.
All other fields returned by the gateway are passed through as-is.

Troubleshooting

Error	Cause	Fix
Fetch fails with a non-zero, non-`9` `ReturnCode`	The gateway returned an error in the `SMResponse` envelope.	Check the `ReturnCode` value and gateway-side logs. A `ReturnCode` of `0` is success and `9` means no records; any other value is treated as a failure.
Sync returns zero records	The gateway returned `ReturnCode` `9` (no records) for every page.	Confirm the resource `path` is correct for each domain, and that the authenticating account can read those collections.
Pagination-ignored warnings in the run log	The gateway is not honoring the `start` and `count` query parameters, so `@start` does not advance between pages.	Confirm the gateway passes pagination parameters through to OpenText. Test gateways commonly ignore them. Do not treat incomplete pages as data loss until pagination is verified.
Connection test fails	The gateway response did not include a valid `SMResponse` envelope with a `ReturnCode`.	Verify the `instance_url` points at the gateway base path, and that credentials for your chosen auth method are correct.
Incremental run returns far more rows than expected	The cursor field is missing or empty on returned records.	Confirm the domain's cursor field (`lastUpdateTime`, or `Tags.lastUpdateTime` for `change`) is populated in the gateway response.

In this section: