Skip to content

Feat/data exchange request be#1116

Open
OlgaIvkovic wants to merge 5 commits intoeclipse-tractusx:feat/data-exchange-request-and-approvalfrom
achtzig20:feat/data-exchange-request-be
Open

Feat/data exchange request be#1116
OlgaIvkovic wants to merge 5 commits intoeclipse-tractusx:feat/data-exchange-request-and-approvalfrom
achtzig20:feat/data-exchange-request-be

Conversation

@OlgaIvkovic
Copy link
Contributor

Description

  • added backend implementation for data exchange requests
  • added a simple bruno test for creating a simple data exchange request

Resolves #1090 .

Pre-review checks

Please ensure to do as many of the following checks as possible, before asking for committer review:

  • DEPENDENCIES are up-to-date. Dash license tool. Committers can open IP issues for restricted libs.
  • Copyright and license header are present on all affected files (TRG 7.02
  • Documentation Notice are present on all affected files (TRG 7.07)
  • If helm chart has been changed, the chart version has been bumped to either next major, minor or patch level (compared to released chart).
  • Changelog updated (changelog.md) with PR reference and brief summary.
  • Frontend version bumped, if needed (frontend/package.json, frontend/package-lock.json)
  • Backend version bumped, if needed (backend/pom.xml)
  • Open API specification updated, if controllers have been changed (use python script scripts/generate_openapi_yaml.py with running customer backend)

@OlgaIvkovic OlgaIvkovic force-pushed the feat/data-exchange-request-be branch from 7e117d6 to 52ee4c0 Compare March 11, 2026 14:22
@ReneSchroederLJ ReneSchroederLJ force-pushed the feat/data-exchange-request-be branch from 52ee4c0 to e126630 Compare March 11, 2026 15:09
@ReneSchroederLJ
Copy link
Member

ReneSchroederLJ commented Mar 11, 2026

I've helped fix some git history issues thus my commit. I did not author the actual content of the commit.

@ReneSchroederLJ ReneSchroederLJ linked an issue Mar 12, 2026 that may be closed by this pull request
Copy link
Member

@ReneSchroederLJ ReneSchroederLJ left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for your contribution. Overall great work. My feedback is mostly down to validations

@ResponseStatus(HttpStatus.CREATED)
public OwnDataExchangeRequest createDataExchangeRequest(@RequestBody OwnDataExchangeRequest ownDataExchangeRequest) {
if (!validator.validate(ownDataExchangeRequest).isEmpty()) {
throw new ResponseStatusException(HttpStatus.BAD_REQUEST);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
throw new ResponseStatusException(HttpStatus.BAD_REQUEST);
throw new ResponseStatusException(HttpStatus.BAD_REQUEST, "Invalid Own Data Exchange Request");

@ApiResponse(responseCode = "500", description = "Internal Server Error.", content = @Content)
})
@ResponseStatus(HttpStatus.CREATED)
public OwnDataExchangeRequest createDataExchangeRequest(@RequestBody OwnDataExchangeRequest ownDataExchangeRequest) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be better to create a DataExchangeRequestDto that is passed here. The DTO should replace notification with notificationId for simplicity.

}
if (ownDataExchangeRequest.getNotification() == null || ownDataExchangeRequest.getNotification().getNotificationId() == null) {
throw new ResponseStatusException(HttpStatus.BAD_REQUEST, "Own Data Exchange Request misses notification identification.");
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This check becomes unnecessary with the DTO change.


@PrePersist
protected void onCreate() {
if (timestamp == null) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This leaves room for timestamp to be manually set. I think it should always overwrite manually set timestamps.

errors.add(message);
}
}
private void validateDesiredDate(List<String> errors, Date desiredDate, String fieldName, ReportedDemandAndCapacityNotification notification) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would make sense to refactor this method to specifically test both dates together, because currently we're lacking the validation dataExchangeRequest.getDesiredStartDate().before(dataExchangeRequest.getDesiredEndDate())

}

public boolean validate(OwnDataExchangeRequest dataExchangeRequest) {
return validateWithDetails(dataExchangeRequest).isEmpty();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At the moment we're providing the elaborate validation feedback messages, but not using them anywhere. The question is will they be used or would a simpler method of validation akin to the one for notifications suffice.

It is arguable that any time an attempt is made to create or update an entity, this kind of detailed feedback is valuable, however we only use detailed feedback for data imports so far.

I will open a separate issue for a potential refactor, but for the time being I suggest converting to returning a simple boolean.

}

public final OwnDataExchangeRequest create(OwnDataExchangeRequest ownDataExchangeRequest) {
if (!validator.apply(ownDataExchangeRequest)) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
if (!validator.apply(ownDataExchangeRequest)) {
if (ownDataExchangeRequest == null || !validator.apply(ownDataExchangeRequest)) {


addIfNull(errors, dataExchangeRequest.getCriticality(), "Missing criticality.");
addIfNull(errors, dataExchangeRequest.getText(), "Missing text.");
addIfNull(errors, dataExchangeRequest.getTimestamp(), "Missing timestamp.");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This validation for timestamp seems problematic to me. On one hand an existing DataExchangeRequest should always have a valid timestamp. However, this check would require manually setting it before the entity is created even though it will automatically be set at creation. My suggestion would be to remove this check or replace it with something like:

(dataExchangeRequest.getUuid() == null || dataExchangeRequest.getTimestamp() != null)

"n-tier"
],
"text": "Please provide the requested data.",
"timestamp": "{{DATA_EXCHANGE_TIMESTAMP}}",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As previously discussed timestamp should not be manually set sinc eit will be ignored.


script:post-response {
console.log("STATUS:", res.getStatus());
console.log("BODY:", JSON.stringify(res.getBody(), null, 2));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

remove unnecessary scripts

Copy link
Member

@ReneSchroederLJ ReneSchroederLJ left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for the changes. I found some further potential improvements. Please also update the version numbers in charts/puris/README.md

throw new ResponseStatusException(HttpStatus.BAD_REQUEST, "Referenced notification does not exist.");
}

OwnDataExchangeRequest ownDataExchangeRequest = convertToEntity(requestDto);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm aware we used to use these kinds of helper methods in the past, but I would opt to use ModelMapper to simplify the process.

This would look something like:

OwnDataExchangeRequest ownDataExchangeRequest = modelMapper.map(requestDto, OwnDataExchangeRequest.class);
ownDataExchangeRequest.setNotification(notification);

ownDataExchangeRequest.setNotification(notification);

try {
return convertToDto(ownDataExchangeRequestService.create(ownDataExchangeRequest));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as above. This can be handled with ModelMapper:

OwnDataExchangeRequest newEntity = ownDataExchangeRequestService.create(ownDataExchangeRequest);
DataExchangeRequestDto responseDto = modelMapper.map(newEntity, DataExchangeRequestDto.class);
responseDto.setNotificationId(notification.getNotificationId());
return responseDto;

dataExchangeRequest.getNotification()
);
}
private boolean validateDesiredDates(Date desiredStartDate, Date desiredEndDate, ReportedDemandAndCapacityNotification notification) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since all 3 parameters are properties of OwnDataExchangeRequest I would opt to pass it directly instead of each individual property.

if (!desiredStartDate.before(desiredEndDate)) {
return false;
}
if (notification.getStartDateOfEffect() != null) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This check is not necessary since start date is mandatory for notifications

}

@Test
void emptyRequest_testValidateWithDetails_returnsValidationErrors() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fix the function name please due to removal of validateWithDetails

Copy link
Member

@ReneSchroederLJ ReneSchroederLJ left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I found two very small details to fix. Otherwise good rework.

# puris

![Version: 6.1.0](https://img.shields.io/badge/Version-6.1.0-informational?style=flat-square) ![Type: application](https://img.shields.io/badge/Type-application-informational?style=flat-square) ![AppVersion: 5.1.0](https://img.shields.io/badge/AppVersion-5.1.0-informational?style=flat-square)
![Version: 7.1.0](https://img.shields.io/badge/Version-6.1.0-informational?style=flat-square) ![Type: application](https://img.shields.io/badge/Type-application-informational?style=flat-square) ![AppVersion: 6.1.0](https://img.shields.io/badge/AppVersion-5.1.0-informational?style=flat-square)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The versions should be 7.0.0 and 6.0.0. also please update the badge urls accordingly

}
private boolean validateDesiredDates(Date desiredStartDate, Date desiredEndDate, ReportedDemandAndCapacityNotification notification) {
if (!desiredStartDate.before(desiredEndDate)) {
private boolean validateDesiredDates(DataExchangeRequest ownDataExchangeRequest, ReportedDemandAndCapacityNotification notification) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since notification is also a child of dataExchangeRequest it can be omitted from the function parameters as well

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Story] Data exchange request backend implementation

2 participants