Development Epic Overview
This page informs about the XDM epics currently planned or in progress. Epics are descriptions of high level functionalities.
In Progress
XDEV-2011 UI Modernization
As an end user, operator, and administrator, I want a modern, consistent, role-appropriate, and high-performance web interface, so that I can complete my tasks efficiently and securely while benefiting from improved usability, accessibility, stability, maintainability, and faster delivery of new features.
This epic covers the redevelopment of the current XDM web interface into a modern single-page application built on a unified component library, a standardized design system, and sustainable engineering practices. The objective is to replace inconsistent interaction patterns, fragmented styling, and hard-to-maintain frontend structures with a clear, reusable, and extensible UI architecture.
Acceptance Criteria
-
The UI has a modern, professional, and consistent look and feel across layouts, components, and interaction patterns.
-
The UI clearly supports at least two role-oriented views: Operator/Admin View for technical users responsible for configuration, control, monitoring, and administration of XDM, Consumer/Self-Service View for non-technical or occasional users with reduced complexity and a focused feature set
-
The UI is fully available in English and German.
-
The UI supports both Light Mode and Dark Mode, including configurable dark mode behavior where applicable
-
The UI is responsive and performant, enabling smooth work in key user workflows and with larger data sets.
-
A unified component library, reusable UI patterns, and standardized frontend guidelines are established to support consistent implementation and faster rollout of future features.
-
The UI reflects user roles and permissions clearly, showing only relevant actions, content, and navigation options where appropriate.
-
The UI provides clear and consistent feedback for status, progress, validation, and error situations, especially for critical or long-running operations.
-
The UI fulfills baseline accessibility requirements and follows established accessibility best practices, including keyboard navigation and focus handling
-
Security-relevant interactions are appropriately protected through safe frontend patterns and consideration of sensitive data handling
Planned release version containing all features: 3.26.31 - Release date: 2026-08-10
Stories for this epic:
|
Story |
Title |
Release |
State |
|---|---|---|---|
|
XPU-367 |
Environment Color Configuration via Docker |
3.26.11 |
Done |
|
XPU-391 |
Group rules in own tab |
3.26.11 |
Done |
|
XPU-640 |
Execution Lifecycle Actions (cancel, restart, resume and cleanup) |
3.26.13 |
Done |
|
XPU-390 |
Reduce number of fields that are displayed on details Screen |
3.26.13 |
Done |
|
XPU-642 |
Schedule executions and pause and resume |
3.26.13 |
Done |
|
XPU-588 |
Add about page |
3.26.15 |
Done |
|
XPU-647 |
Approve and reject requested execution |
3.26.15 |
Done |
|
XPU-650 |
Publish and hide announcement |
3.26.15 |
Done |
|
XPU-576 |
Implementation of consumer view |
3.26.17 |
Done |
|
XPU-82 |
Interactive Database Browser Component |
3.26.19 |
Done |
|
XPU-666 |
Workflow execution view |
3.26.19 |
Done |
|
XPU-656 |
Clear Mapping Table Container |
3.26.21 |
Done |
|
XPU-657 |
Download File / Mapping Table Container |
3.26.21 |
Done |
|
XPU-653 |
Import Rule Lists from CSV |
3.26.21 |
Done |
|
XPU-655 |
Upload File / Mapping Table Container |
3.26.21 |
Done |
|
XPU-652 |
Export Lists as CSV |
3.26.23 |
Done |
|
XPU-512 |
Show announcements on login page, dashboard or headbar |
3.26.25 |
Done |
|
XPU-77 |
Add Yaml/Zip import action |
3.26.27 |
Done |
|
XPU-438 |
Display Backend Unavailability Status |
3.26.27 |
Done |
|
XPU-510 |
Enable move up and move down actions in embedded lists |
3.26.27 |
Done |
|
XPU-75 |
Permission Check Dialog for User Selection |
3.26.27 |
Done |
|
XPU-1593 |
Visualize Installed Application Relations |
3.26.27 |
Done |
|
XPU-7 |
Allow bulk operations on object lists |
3.26.27 |
In Progress |
|
XPU-437 |
Add option to create dependent objects at the place where they are needed |
3.26.29 |
Approved |
|
XPU-1588 |
Reorder Modification Rules |
3.26.29 |
Approved |
|
XPU-1591 |
Reorder Selected Modification Sets |
3.26.29 |
Approved |
|
XPU-1607 |
Show User and Change Date in History |
3.26.29 |
Approved |
|
XPU-436 |
Show number of entries on tab title for sub-lists |
3.26.29 |
Approved |
|
XPU-612 |
Integrate and Provide Access to the User Manual |
3.26.29 |
Done |
|
XPU-1605 |
Browse Mapping Table Container |
3.26.29 |
In Progress |
|
XPU-1503 |
Code Snippet Helper Dialog |
3.26.29 |
In Progress |
|
XPU-1592 |
Migrate List Permissions to Prime UI |
3.26.29 |
In Progress |
|
XPU-1085 |
Allow tab usage in script editor |
Approved |
|
|
XPU-1606 |
Schema and Table Selection Support for Rules |
Approved |
|
|
XPU-1268 |
Show task type in execution and scheduled execution lists |
Approved |
|
|
XPU-1594 |
Task Template Overview |
Approved |
|
|
XPU-600 |
Capture screenshots in tutorials with Prime UI |
In Progress |
XDEV-2008 XDM AI Assistent
As a user (XDM Operator), I want AI support for setting up and maintaining XDM configurations so that I can achieve an automated configuration more quickly and reliably.
Acceptance Criteria:
-
Coding support in the scripts
-
The assistant knows the functions and helper variables in the background
-
There is an action available on code blocks that allows me to enter a goal description via prompt
-
Existing code is reused and potentially improved
Configuration Assistant
-
I can enter my goal as a prompt , receive suggestions for partial configurations, and be asked follow-up questions for details
-
The result is a set of new and partially existing objects that represent the whole or part of the complete solution
Analysis Assistant
-
I can receive hints for error messages , explaining the possible root causes and providing an assessment of whether the issue is related to XDM configuration, a technical error, or an infrastructure problem
-
The function is a standalone, separately licensed component
-
It requires integration with an external model
Use Case:
An inexperienced user asks the system in plain language:
The AI may ask for more details (e.g., "All data or just specific rows?"). Once the user has answered all questions, they receive a concrete YAML file describing the required steps, which can then be used further.
XDEV-1989 Masking on domain entities
-
Möglichkeit Masking bei Entities modellieren
-
Microservice für Masking entwickeln
-
Microservice übernimmt Management von MappingTableContainers
Stories for this epic:
|
Story |
Title |
Release |
State |
|---|---|---|---|
|
XCOR-14083 |
Enable Modification for domain entities |
3.24.41 |
Done |
|
XBS-1 |
Entity Modification – Use Mapping Tables for Data Anonymization |
Approved |
|
|
XCOR-13719 |
Develop a Microservice that masks domain entities |
Done |
|
|
XBS-3312 |
Save mapping table container in PostgreSQL |
Funnel |
XDEV-2017 Replace Spring Cloud Data Flow in XDM
Spring Cloud Data Flow (SCDF) is no longer actively maintained and does not receive security updates. XDM currently relies on SCDF to start, control, and monitor task executions via the xdm3-core service and the xdm3-runner application (Spring Batch–based, with PostgreSQL-backed execution tracking and heartbeat/status reporting).
This epic aims to design and implement a secure, maintainable replacement for SCDF within the XDM ecosystem. The new solution must:
-
Provide controlled task execution (including execution queueing and limits on parallel runs)
-
Support both Docker Compose and Kubernetes deployment models
-
Allow running xdm3-runner as an isolated process or container (e.g., own Docker container / Kubernetes Pod)
-
Integrate with existing XDM components (xdm3-core, PostgreSQL, Spring Batch) for execution tracking, step-level status, and error reporting
-
Preserve or improve current monitoring behavior (heartbeat, start/end events, step status)
The outcome of this epic is a production-ready alternative (either an open-source platform or a custom implementation) that fully replaces SCDF in XDM without loss of functionality and with improved long-term security and maintainability.
Stories for this epic:
|
Story |
Title |
Release |
State |
|---|---|---|---|
|
XBS-3279 |
Analyze docker-java library as replacement for dataflow |
Done |
|
|
XBS-3648 |
Remove Spring Cloud Dataflow |
Funnel |
|
|
XBS-3647 |
Replace Spring Cloud Dataflow for Kubernetes Deployment |
Funnel |
|
|
XBS-3303 |
Replace Spring Cloud Dataflow for Docker Deployment |
In Progress |
Approved
XDEV-2021 XDM MCP Server
Develop an MCP server as a technical interface between a Large Language Model (LLM) and the XDM test data platform, enabling users to execute custom actions through natural language.
The MCP server allows users to find suitable test data via prompts, request or provision test data, and generate functionally correct test data.
Goal / Business Value
-
Faster access to suitable test data without requiring deep knowledge of tables, systems, or shop forms.
-
Functionally correct test cases and test datasets are made centrally discoverable and reproducible.
-
Reduction of manual coordination efforts (e.g. which data, which shop, which form).
-
Scalable test data generation for cases where no suitable data currently exists.
-
Interface for agent-based systems to enable AI agents to find and provision test data.
Acceptance criteria
The MCP server provides tools that enable the LLM to:
-
Extract criteria from a user prompt and clarify ambiguities through follow-up questions where needed.
-
Identify relevant datasets and test cases in the Test Data Finder based on business-related criteria.
-
Determine, based on the search results, which Data Shop, order form, or product is appropriate for provisioning the requested data.
-
Access information generated during task execution, such as reports, data, and other artifacts, and provide these as results for further use.
-
Initiate the ordering process in the Data Shop and return the following information to the user:
-
Order ID / reference
-
Status (e.g. in progress, provisioned, failed)
-
Resulting artifacts, links, or IDs for use in the test environment
-
XDEV-2012 Form Builder
As a user, I want to create custom forms as independent objects within the XDM platform, configure granular permissions, manage form lifecycle states, collect data from XDM end users, and trigger automated processes based on those inputs.
This Epic extends existing form-building functionality by enabling comprehensive permission control, so that administrators can define exactly which users or groups can view, edit, or submit a given form. Forms have clear lifecycle states—Draft, Published, and Archived—to support controlled rollout and maintenance. The forms are fully integrated with the XDM environment and support direct data entry by XDM end users. Collected data can automatically initiate downstream processes, such as data copy tasks or business workflows. All business logic can be enriched by user-configurable Groovy scripts that process submitted form data. Furthermore, users and end users can save and reuse completed form submissions.
Acceptance Criteria
-
Users can create a new form object, providing a unique name, a description, and configuring both form content and layout structure.
-
Users can add fields from a list of predefined types (e.g. text, number, dropdown) and configure field properties such as name, description, required status, and field-specific validation (e.g. regex, min/max values).
-
Dropdown fields allow users to define selectable options; dependencies can be set between fields to conditionally show or hide them based on user input.
-
For each form, three separate Groovy scripts (Init, Transmission, Validation) can be configured to define advanced initialization, data processing, and validation behavior.
-
Forms can be set to one of three states:
-
Draft: Visible and editable only to authorized users; not available to end users for submission.
-
Published: Form is visible to authorized users and available for submission by end users who have appropriate permissions.
-
Archived: Form is not available for new entries but remains accessible for viewing or reporting based on permissions.
-
-
Permissions can be configured on each form to control which users or user groups (e.g., administrators, business users, end users) can:
-
View the form
-
Edit form design/settings
-
Submit entries using the form
-
View submitted entries
-
Permission assignments support both individual users and user groups.
-
Forms are accessible to XDM end users according to assigned permissions. These users can enter data and submit completed forms as defined by the form’s state.
-
Scripts defined in the form (especially the Transmission script) can process input data and trigger automated follow-up processes (e.g., initiating data copy tasks, business workflows) based on end user submissions.
-
The execution of all configured business logic and follow-up processes must be reliable in both the preview and live environments.
-
Both users and end users can save completed form entries and retrieve or reuse them at a later stage.
-
The list of forms displays their current state and allows authorized users to view, edit, publish, archive, or delete forms, with all changes applied immediately according to permission and state constraints.
Example Use Case:
An administrator wants to empower business users in the insurance domain to create a custom order form for requesting the transfer of specific insurance policy records between source and target environments. The business user designs a “Policy Transfer Request” form, adding fields such as:
-
Customer Number (required)
-
Policy Number (required)
-
Policy Type (dropdown; e.g., Auto, Life, Property)
-
Contract Period (date range)
-
Optional: Attachments (supporting documents)
-
Comments
The form is set to “Published” and made available to the relevant team. Upon submission, the Transmission script evaluates the inputs, determines which insurance policies and data must be copied, and triggers an automated copy process in the XDM backend. All submitted requests can be stored and later reused for similar future operations. Only users with read rights on archived forms can access historical submissions for audit or reporting purposes.
XDEV-1187 Data Store
As a test data user, I want to store, structure, and manage my test data in domain-oriented GraphStores so I can efficiently backup, transform, and reuse test data across various environments. This allows technical data to be represented as business domain objects, enriched with both attributes and relationships.
Acceptance Criteria
-
Domain-oriented Data Modeling:
-
Test data can be modeled and stored according to a flexible, configurable domain model.
-
Data from multiple sources (e.g. relational databases, web services) can be mapped as domain entities with attributes and relations inside XDM.
-
Complex data structures, including N:M relations, can be represented in the model.
-
-
GraphStore as Central Data Store:
-
Test data is stored as GraphStores, where entities and their relationships are structured and accessible.
-
Multiple GraphStores can be created to organize data from different domains, departments, or projects.
-
I can add and delete data within a GraphStore.
-
Data can be transferred or copied between different GraphStores.
-
-
GraphStore Lifecycle Management:
-
A GraphStore can have a configurable lifetime. Upon expiration, the GraphStore is automatically deleted.
-
Each GraphStore contains meta information: creator, creation date, last update, domain model reference, and editable custom parameters.
-
-
Flexible Data Exchange:
-
Data can be read from or populated into technical systems by transforming them according to the defined domain model and storing them in a selected GraphStore.
-
I can use any GraphStore as a source or target when copying or synchronizing data, with selection based on meta information and custom parameters.
-
-
Metadata and Governance:
-
Each GraphStore and contained entity records comprehensive metadata.
-
Custom parameters on GraphStores can be configured, set, and queried individually, supporting governance and traceability.
-
Benefits:
-
Test data management is oriented towards the business domain and not limited by the underlying technical structure.
-
Seamless transfer, reuse, and auditability of test data across all environments and data sources.
-
Powerful tracing of dependencies and lineage, enabling better analysis, reporting, and quality assurance.
Use Case 1: Reusing a Test Scenario with GraphStore
Mr. Müller has prepared a test scenario and wants to persist the test data as a domain-oriented GraphStore so that he can reuse or extend the test data set for future tests.
Steps:
-
Create a new GraphStore with a meaningful name and relevant metadata for the test scenario.
-
Select the appropriate RLP task and configure the target as the newly created GraphStore.
-
Execute the RLP task, which reads the live environment and writes the transformed data into the GraphStore.
When the scenario requirements change and additional data is needed:
-
Run the RLP task again, targeting the same GraphStore to update or extend the data set.