Assessing Third-Party Application Connectivity To XDM

Purpose And Scope

This section provides a practical guide for project leads and test data managers who need to assess whether a new third-party application can be integrated with XDM. It focuses on “blackbox” systems delivered by external vendors, where internal details are only partially known.

The goal is to support an early decision:

  • Is an XDM integration technically and organizationally realistic?

  • Which preconditions must be clarified with the vendor and internal teams?

  • What are typical next steps if an integration is feasible?

This section does not replace the detailed configuration and implementation guides. Instead, it structures the most important questions and points to related XDM documentation where appropriate.

Typical Integration Scenarios With XDM

From an XDM perspective, new applications usually fall into one or more of these categories:

  • Database-centric systems The core data is stored in a relational database that can be accessed via JDBC. XDM connects to such systems as source and/or target databases by using suitable JDBC drivers and license options.

  • Service-oriented systems Business data is exposed primarily through REST or other web APIs. XDM can interact with these systems via its public REST API (direct business object GET and POST) or automation concepts (for example, to trigger imports into staging tables).

  • File-oriented systems Data is exchanged via file exports and imports (for example, CSV, XML, JSON). XDM uses connections and storage locations to read and write such files, and tasks to move data between file-based staging areas and databases.

Integration scenarios that rely solely on GUI actions, screen scraping, or manual steps outside XDM are out of scope for this checklist.

Key Questions About The Third-Party Application

Data Access Options

When evaluating a new third-party system, clarify how XDM can technically reach the relevant data:

Database access

  • Which database product and version does the application use?

  • Is direct read access to the underlying database possible via JDBC?

  • Is write access required (for loading or refreshing test data), and is it allowed under vendor and security policies?

  • Are there restrictions on the database user (for example, no access to specific schemas, no DDL operations)?

API access

  • Does the application provide documented REST or web service APIs that expose the relevant business data?

  • Are there established patterns to extract data via the API into a staging database that XDM can access?

  • Are there rate limits or functional constraints that might impact bulk test data extraction?

File exports and imports

  • Can the system export data in structured formats (CSV, XML, JSON, fixed-width text, etc.) on a regular basis?

  • Who controls the export configuration (scheduling, scope, filters)?

  • Can exports be automated and written to a directory reachable from XDM (for example via a storage location or File Bridge)?

If the system does not provide at least one of these access paths in a controlled and automatable way, an XDM integration is usually difficult to justify.

Credentials, Roles And Access Governance

For any chosen access path, the following questions should be clarified:

  • Will separate technical users (service accounts) be provided for XDM access?

  • Which roles and permissions are required on the application side (for example, read-only vs. operational access)?

  • Who owns and manages these credentials (internal team, vendor, central IAM)?

  • How are passwords, tokens, and certificates stored and rotated in your environment?

Understanding The Data Model

A basic understanding of the data model is essential for meaningful test data provisioning:

  • Does the vendor provide up-to-date documentation of the logical and physical data model (tables, columns, relationships, key structures)?

  • Are naming conventions and key semantics documented (for example, business keys vs. technical surrogate keys)?

  • How frequently does the data model change, and how are schema changes communicated?

  • Who is the contact for questions about table relations, mandatory fields, and valid value ranges?

Without at least a minimal, stable view of the data model, it is hard to design robust XDM tasks, application models, or anonymization rules. It is possible to detect typical structures by analyzing naming, constraints and other information that can be automatically extracted. This demands some experience in building a TDM setup and a longer project runtime should be calculated if this information needs to be analyzed only based on available schema information.

Cross-System Keys And References

When integrating a new third-party application into an existing XDM landscape, cross-system relationships become important:

  • Are there key attributes in the new system that reference objects in other, already integrated systems (for example, customer IDs, contract numbers, claim IDs)?

  • Are these keys identical across systems (shared master data keys), or does each system use its own internal identifiers with mapping tables?

  • Where are the “leading” keys mastered (for example, central CRM, master data management system), and where are they only mirrored?

  • Are there reference tables or interfaces that formally capture these cross-system relationships?

Clarifying these points early helps to decide whether XDM can reuse existing test data selections across systems, and whether cross-system consistency must be preserved during anonymization.

Key Questions About The XDM Environment

License, Drivers And Supported Technologies

On the XDM side, you should verify:

  • Does your XDM license cover the database type used by the third-party system (for example, Db2, Oracle, SQL Server, PostgreSQL, Db2 z/OS, Db2 iSeries, IMS, generic JDBC)?

  • Are suitable JDBC drivers available and installed in the configured driver directory so that XDM can connect to the database?

  • Do you already operate similar database or technology types in XDM, or would this be a completely new stack?

If new JDBC drivers are required, they must be placed in the configured driver directory and XDM services need to be restarted so the drivers are registered.

Connectivity, Security And User Management (High Level)

Before implementation, check at a high level:

  • Can the XDM core and dataflow services reach the database, API, or file share from their network zone (firewalls, routes, ports)?

  • Which authentication methods are required (username/password, certificates, API Tokens)? Are these compatible with XDM capabilities (for example, certificate-based connections, API Token configuration)?

  • How will XDM users and roles be provisioned so that only authorized users can work with the new system’s test data (for example, via LDAP groups or OpenID roles)?

Security and detailed configuration topics (such as certificate installation and token-based authentication) are described in dedicated chapters and are only referenced here.

Functional Test Data Management Perspective

Even if technical access is possible, integration is only meaningful if XDM can support relevant test scenarios:

  • Which business processes or use cases should be supported by test data from this system (for example, end-to-end process involving multiple systems)?

  • Do you primarily need complete tables (for cloning and regression testing), or smaller, representative subsets (for integration and functional testing)?

  • Are there strong dependencies to data in other systems that must be reflected (for example, contracts with corresponding claims and payments in separate systems)?

From a masking perspective, clarify:

  • Which attributes in the new system contain personal or otherwise sensitive data that must be anonymized or pseudonymized?

  • Are there attributes that must remain consistent with anonymized values in already integrated systems (for example, anonymized customer IDs or case numbers reused across systems)?

  • Can the required consistency be implemented using XDM features such as lookup tables, replacement mappings, and dependency-aware anonymization sequences?

Where consistency is required across systems, you typically need globally applied anonymization rules that yield the same replacement for the same original value, regardless of which system it comes from.

Cross-System Keys And Consistent Anonymization

In addition to the general masking questions, the new system should be evaluated specifically for cross-system consistency:

Key attributes referencing other systems

Identify key fields that:

  • Point to master data or transactions maintained in other applications (for example, Customer_ID, Policy_Number, Case_ID).

  • Are used as foreign keys or matching criteria in XDM tasks, application models, or Data Shop offerings.

Clarify for each such attribute:

  • Is the value originally created in the new system, or is it copied from another system?

  • If copied, does the new system enforce the same value domain (for example, same format, no additional transformations)?

Attributes requiring consistent anonymization

For attributes that are used to link data across systems and contain personal or sensitive information, you should decide:

  • Must these attributes be anonymized in the same way as in already integrated systems (for example, same replacement ID for the same person)?

  • Is it sufficient to anonymize them independently in each system (for example, completely synthetic test data without cross-system linkage)?

For consistent anonymization, XDM typically uses:

  • Central lookup tables to ensure that the same original value always receives the same replacement value.

  • Intermediate or mapping tables that store original and replacement values keyed by stable identifiers.

  • Dependency-aware anonymization sequences, where base keys are anonymized first and related attributes are derived from those anonymized values.

When planning the integration of a new system, verify whether its key attributes can be included in existing anonymization concepts, or whether additional lookup and mapping structures are required.

First Assessment And Outcome

After clarifying the questions above, the project lead should be able to answer three guiding questions:

  1. Can XDM technically access the relevant data of the third-party system in a supported way (JDBC, API, files)?

  2. Are the necessary credentials, roles, licenses, and drivers realistically obtainable and maintainable?

  3. Does the system’s data model, including cross-system keys, allow meaningful test data provisioning and consistent anonymization where required?

Depending on the answers, the result of the assessment will typically fall into one of these categories:

  • Integration into XDM is clearly feasible and useful.

  • Integration is possible but requires further clarification or additional investments (for example, new license options, network adjustments, extended anonymization concepts).

  • Integration is currently not recommended due to missing access paths, strong vendor restrictions, or lack of meaningful test data use cases.

Next Steps And References

If the initial assessment is positive, typical next steps are:

  • Organize a short intake workshop with:

    • Application owner or vendor contact,

    • Database administrator or technical owner of the platform,

    • XDM administrator,

    • Test data manager or project lead.

  • Define the preferred integration path (database, API, files) and confirm responsibilities for:

    • Providing and managing credentials,

    • Network and security configuration,

    • Maintenance of data model documentation,

    • Masking and anonymization rules, especially for cross-system keys.