feat: implement bill of materials as planned edc offering

[gobica]

Description

Please describe your PR:

• implement java class representations of the SingleLevelBomAsPlanned semantic model
• create a new SAMM Mapper for bill of materials
• register EDC and DTR assets for bill of materials
• contract defintion for own bpnl is created on initial registration
• create new Request Api controller and service for bill of materials

due to line restrictions, unit tests will be added in a separate PR.

resolves #1087

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)

[ReneSchroederLJ]

Great contribution overall. I found some inconsistencies that should be addressed.

I tested the request endpoint with the following bruno request:

meta {
  name: test bom endpoint
  type: http
  seq: 5
}

get {
  url: {{CUSTOMER_PURIS_BACKEND}}/catena/single-level-bom-as-planned/request/b399d6dd-9e58-4b5b-a719-14a40e7253be/submodel/$value
  body: none
  auth: apikey
}

headers {
  edc-bpn: {{CUSTOMER_BPNL}}
}

auth:apikey {
  key: X-API-KEY
  value: {{CUSTOMER_PURIS_BACKEND_API_KEY}}
  placement: header
}

settings {
  encodeUrl: true
  timeout: 0
}

I got the correct materialNumberCx for "Central Control Unit" from the Master Data view in the frontend.

I got the result:

{
  "catenaXId": "b399d6dd-9e58-4b5b-a719-14a40e7253be",
  "childItems": [
    {
      "createdOn": "2026-03-10T10:13:52.722+00:00",
      "quantity": {
        "quantityNumber": 7.0,
        "measurementUnit": "unit:piece"
      },
      "lastModifiedOn": "2026-03-10T10:13:52.793+00:00",
      "validityPeriod": null,
      "businessPartner": "BPNL1234567890ZZ",
      "catenaXId": "6555e865-1c75-4b5c-8d21-62644eaa2019"
    }
  ]
}

The result has the expected shape, but mistakenly returns our own materialNumberCx instead of the supplier's one for child materials. I addressed this in my comments.

[ReneSchroederLJ]

Thank you for the changes. I added a suggestion regarding error handling for you to consider.

[tom-rm-meyer-ISST]

Great contribution. Found a typo and three points, where we could better reuse the mprService now and in future.

Things to note @ReneSchroederLJ

• If I understood him correctly, we don't add further filtering to boms now (restrict to children affected by disruption) but maybe in future prs.
• we update the changelog later on feature branch (I released the 5.1.0 already for another purpose)

[ReneSchroederLJ]

Things to note @ReneSchroederLJ

• If I understood him correctly, we don't add further filtering to boms now (restrict to children affected by disruption) but maybe in future prs.

Currently, the plan is to keep BOM unfiltered. It just shows the actual slice of the BOM. The filtering, which will be needed for IRS for example, should happen via an endpoint based on Data Exchange Approvals. This way we tie the filtering logic closely to the approval mechanism and leave BOM independent of this use case.

• we update the changelog later on feature branch (I released the 5.1.0 already for another purpose)

Whether we update the changelog now or later is up to preference. Updating it now would have the advantage that merging is easier later on and the helm pipeline would stop failing.

[tom-rm-meyer-ISST]

LGTM, thanks for contributing!

I would go for later merging and updating as there might be a bugfix release in between just duplicating the efforts.