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-2000 Support for Kafka Topics
This epic introduces support for Apache Kafka within the XDM platform. The goal is to enable XDM to read from Kafka topics, interpret and optionally transform the message data, and write the processed messages into other Kafka topics. Messages are expected to be in JSON format. Kafka systems can be configured as source and target systems, and message structures are defined using XDM’s domain modeling functionality. Users will be able to define the format of Kafka messages, apply transformation rules, and filter messages before writing them to their destination.
Acceptance Criteria
-
Kafka systems can be configured within the XDM user interface as source and/or target systems.
-
Kafka messages are interpreted based on domain models created from imported JSON examples.
-
A service is available to read messages from Kafka topics using offset or timestamp filters.
-
A service is available to write messages to Kafka topics based on the interpreted structure.
-
Fields within Kafka messages can be modified using configurable Modification Methods.
-
Filtering of messages is possible using Reduction Rules based on the message content.
-
Kafka-based data transfer is supported within task templates in XDM.
-
All configuration is accessible through the XDM user interface.
-
Kafka support is included in regular XDM releases.
Use Case
As a data engineer, I want to integrate Kafka topics into my XDM-based workflows so I can efficiently process real-time data streams. I need to read messages from Kafka topics, define how those messages are structured and interpreted, apply field-level transformations, and selectively filter data before writing it to new Kafka topics. With this functionality integrated into the XDM UI, I can manage streaming data pipelines without needing custom implementations, using standard XDM configuration and task templates.
Stories for this epic:
|
Story |
Title |
Release |
State |
|---|---|---|---|
|
XBS-407 |
Kafka - Microservice for Topic Reading |
3.25.35 |
Done |
|
XBS-405 |
Kafka - Microservice for Topic Writing |
3.25.39 |
Done |
|
XBS-1686 |
Add 'Kafka Topic' Object to XDM for Integration Purposes |
3.25.39 |
Done |
|
XBS-414 |
Kafka - Copy Task |
3.25.43 |
Done |
|
XBS-2210 |
Kafka – Copy message headers, key, partition and timestamp. |
3.25.45 |
Done |
|
XBS-2214 |
Kafka – Authentication Method Selection and Configuration. |
3.25.45 |
Done |
|
XBS-1689 |
Kafka - Copy Task Filtering |
3.25.49 |
Done |
|
XBS-2422 |
Kafka – NULL values not copied from source topic |
3.25.49 |
Done |
|
XBS-2234 |
Kafka – Enhanced logging |
3.25.51 |
Done |
|
XBS-2610 |
Entity Copy Task - Bypass Graph Store |
3.26.3 |
Approved |
|
XBS-2778 |
Domain Entity – /import action generates attributes from JSON |
3.26.3 |
In Progress |
|
XBS-2802 |
Kafka Copy Task - multiple identical keys cannot be copied |
3.26.3 |
In Progress |
|
XBS-1688 |
Entity Copy Task Modification Methods |
3.26.5 |
Approved |
|
XBS-1691 |
Prototype to copy Kafka topics |
Done |
|
|
XBS-2211 |
Kafka – Custom Partitioner Script for Dynamic Message Distribution. |
Funnel |
|
|
XBS-2212 |
Epic Abnahme für Kafka Support |
Approved |
|
|
XBS-2213 |
Documentation – Kafka Support Epic Overview for Non-Technical Stakeholders. |
Done |
|
|
XBS-2302 |
Kafka – Configure Consumer Group |
Approved |
XDEV-2011 UI Modernization
This epic aims to rebuild the current web application interface using a unified component library, standardized design system, and modern engineering practices. The objective is to address technical and design debt accumulated over recent years—including inconsistent UI paradigms, high maintenance effort, limitations in feature scalability, and suboptimal performance. By the end of Q4/2025, the platform should deliver a consistent user experience, faster and more reliable UI, streamlined development workflows, and full German language coverage.
Acceptance Criteria:
-
Critical UI bugs reduced: By the end of Q4/2025, the number of critical UI bugs (priorities P1 and P2) in the modernized interface is reduced by at least 50%, as evidenced by bug tracking reports.
-
Full migration to design system: 100% of the user interface is implemented using the standardized design system (with all components documented in Storybook) and contains no custom, project-specific UI extensions at the time of release.
-
Performance target met: The main dashboard loads in under 1 second (Lighthouse performance score ≥ 90) in standard test conditions by Q4/2025.
-
German language support: All UI elements (components, features, and system messages) are fully available in German, with no untranslated text remaining as of Q4/2025.
-
Improved development metrics: Average duration for UI bug fixes and minor feature changes is reduced by 30% (compared to current metrics), and new UI features can be developed (from design to merge) in under 5 days from Q1/2026 onwards, as tracked in development workflow tools.
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-1704 Support Webservices
As a user I want to read data from web services and write it back into other web services of the same type in other environments. This stands in contrast to reading the test data from database tables and write it into them.
-
There is one Connection which is the base connection.
-
You can define different endpoints and model which data forms exist on them.
-
Modification?
Stories for this epic:
|
Story |
Title |
Release |
State |
|---|---|---|---|
|
XCOR-13534 |
Build a webservice extractor tasklet |
3.24.27 |
Done |
|
XCOR-13718 |
Support token based authentication |
3.24.29 |
Done |
|
XUI-13034 |
Add import action to create domain model for REST service modeling |
3.24.35 |
Done |
|
XCOR-13831 |
The "webservice source" should recognize the correct entity if it is derived from a parent entity |
3.24.35 |
Done |
|
XCOR-14084 |
Import domain entities from OData service |
3.24.43 |
Done |
|
XCOR-13399 |
Implement prototype for webservice copy task |
3.24.39 |
Done |
|
XCOR-14085 |
Authentication against Microsoft Dynamics 365 |
3.24.39 |
Done |
|
XCOR-13830 |
Import OpenAPI specification files to create domain entities |
3.24.37 |
Done |
|
XCOR-14209 |
Inheriting response codes in webservice apply |
3.24.47 |
Done |
|
XBS-1338 |
Epic Abnahme |
Approved |
|
|
XCOR-11993 |
Install OData sample service |
Done |
|
|
XCOR-13392 |
Add import action to create domain model for REST service modeling |
Done |
|
|
XCOR-13405 |
Add webservice indexing task type |
Done |
|
|
XCOR-13794 |
Prototype to write data into a webservice |
Done |
|
|
XCOR-14232 |
Testing with Microsoft Dynamics 365 |
Done |
Approved
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.
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.