MVP Requirements for 25.06

[matbmoser]

Requirements

I have refined our tasks for R25.06 the MVP (I tried to detail it as good as I could)
If I am honest I am not sure we will fullfill this features until R25.06 since we are running out of time… I removed a lot of things, and also made some things easier to implement, so lets start working on them now.
      - I can also help with some programming if needed…

We should focus on fullfilling the “data privisioning” capability at least, even if we need to cut somethings, or reduce the ammount data we handle…
I made a resumed version and a detailed version, please read them both and create only the “Necessary Tickets”...

The resumed version (prioritiezed from top to down per product):

1. SDK (some guidance):

• NO microservices there, no API (/health, etc..)
• Just in the backend
• What ever it can be reusable, please add in the sdk, then use it in the backend.
• Please integrate the changes from BMW so we can start using the EDC.
• I am not sure if we are creating the twins like Catena-x uses it with aspect models (architecture guidance needed)...

2. Frontend:

• UI skeleton that is modular and can support different use cases views.
• Display products at “catalog level”
  • NO SEARCH, remove it, it looks weird right now, lets see if we put it in another place later…
  • Also no filters for now
• Sharing Button that displays pop requiring a BPNL (listing existing BPNLs also if already shared)
• Display a single product details
• No instance products for now (We only use type level) if you want we can keep the table...
• Create a product (button and formular) [in worst case we create if with the backend, but it would be sad not to have this.]

3. Backend:

• Make sure backend is connected to the DB, and it has our tables
• Product CRD (no update) (product information in the create)
  • Share API (bpn + unique product id)
  • Also an API to read with who we shared this product (unique product id)
• We also need to document a user manual (I can support)

4. Infrastructure:

• Helm charts/images needs to be published via workflows
• @gomezbc support the backend
• Deploy at the end our application in Argo CD at the Association Environmnet so we can be part of the release…
• Since LKS next is already part of the association I can give you access...

5. Testing

• @mgarciaLKS Please support the backend and the frontend (lets reduce or full testing effort for now)
• Unit Test backend only
• No frontend testing yet.
• Once the sharing API is done, Test if the data provisioning is working using another consumer EDC “with postman/insomnia/bruno” (i have a collection for that already)
  • I will be doing that to check if its working.
• We will need to write our test cases in a Jira before we release.
• So we need to define the test cases (the flow)

6. Architecture

• We need a Arch42 in both SDK and Industry Core Hub:
  • Example https://github.com/eclipse-tractusx/puris/tree/main/docs/architecture (instead if Index.md use README.md)
• Give guidance to the backend where to store what, and how to place the “meta product” into the necessary digital twins and submodel, when we share it.
  • Based on the industry core kit
• Give also guidance on the creation of twins, so we use the correct structure and provide “aspect models” instead of “submodel templates”. is just a simple json:
  • example: https://github.com/eclipse-tractusx/sldt-semantic-models/blob/main/io.catenax.part\_type\_information/1.0.0/gen/PartTypeInformation.json
• Do not invest time in the dispatcher, just implement it if we need it, lets store everything in the filesystem for now...

The Detailed Version (ordered from prio):

Frontend

@sonama please make sure the “necessary” tickets are created it does not needs to be 1:1 to the bullet points:

• UI skeleton that is modular and can support different use cases views. 
	○ Inspired on the Teams UI
	○ Sidebar there also
	○ Make sure is stable and scalable from the beginning...
• Products Managment (stabilize what we have already): 
	○ Display of Product Catalog View (with cards)
		§ Show how much products (but I think is alreday in the pagination)
	○ A sharing button 
		§ that displays with one pop up to introduce the “BPNL” from a partner. and then it calls the backend API
		§ please also display a list of “BPNL” if is already shared… (there will be an API for that)
	○ Display Product Details
	○ Create Products (Formular) -> fill the product detail and call the backend for creating the product (also a button to create the product, a big plus in the right down corner)
	○ Product Operations (Delete/Modify)
	○ NO SEARCH or filters anymore (sidebar hidden for now)

Backend

@CDiezRodriguez please make sure this is created into tickets, if you create or you delegate is up to you) also not 1:1 to the bullet points… (maybe will be less tickets):

• Metadata Registry:
     ○ Migrations -> Database set up (data model that was worked in arch)
     ○ Be able to connect to the postgresql -> some config needs to be done

• Products Managment APIs:
	○ Read products (meta level only) -> only important metadata
		§ Title
		§ Status (low prio to implement the logic)
			□ SHARED  -> Product exist and is visible by one or more partners (one is the mvp)
			□ REGISTERED  -> Product exists but is not yet in a DT
			□ DRAFT -> Still modified (when clicking on adding it will be set by default in draft)
		§ Unique ID -> so we can search for the details later
		§ Category
	○ CRD product (detailed) -> all information of product (no update yet)
		§ We need a unique id for the products
		§ This are the “complete” product information (we need to build a json that translate what is in the metadata registry) -> architecture needs to define together with backend
			□ Product Information (some points may already be in the Datamodel from Michael):
				® Name -> the unique name of the product
				® Unique id -> Asigned automatically
				® Status -> will be asigned automatically
				® Add the company using the ichub as owner -> BPNL (probably needs to be done per config) (participantId)
				® Description -> string
				® Category -> Is like the class example "Battery"
				® manufacturerPartId -> this is the unique “human readable id” of the product
				® Country of Origin: BPNS (its a different BPN that links the partner with the location of production ->  https://catenax-ev.github.io/docs/next/standards/CX-0010-BusinessPartnerNumber#1521-business-partner
					◊ This is the REGEX from the BPN in general: BPN[LSA][A-Z0-9]{10}[A-Z0-9]{2}
					◊ Can be stored in part site:  https://github.com/eclipse-tractusx/sldt-semantic-models/blob/main/io.catenax.part_site_information_as_planned/1.0.0/gen/PartSiteInformationAsPlanned.json or in part type  https://github.com/eclipse-tractusx/sldt-semantic-models/blob/main/io.catenax.part_type_information/1.0.0/gen/PartTypeInformation.json
				® Materials:
					◊ Just a list of it would be good we can do an array as input: [{“name”:“Aluminium”, “kg”:20} , {“name”: “Iron”, “kg”: 50}…] I want to have it but we can see where we share or add this later (maybe we need a new aspect model for now)
	○ Share APIs (send BPNL and product unique id) -> focus on type level, instance is easy then later
		§ Shared API:
			□ Check if is not already shared… (keep a list of what is shared with who)
			□ Check if digital twin registry is shared in the EDC as an asset
			□ Create digital twin in type level on the background -> how is defined in the KIT:  https://eclipse-tractusx.github.io/docs-kits/kits/Industry%20Core%20Kit/Software%20Development%20View/Digital%20Twins%20Development%20View%20Industry%20Core%20Kit#property-specificassetids
				® Industry Core Part/product information submodel (from product information in database merge into the datamodels):  https://eclipse-tractusx.github.io/docs-kits/kits/Industry%20Core%20Kit/Software%20Development%20View/Aspect%20Models%20Development%20View%20Industry%20Core%20Kit
					◊ With the policies I would create them by default for this aspect models with bundle (Michael/architecture can tell you how) (per configuration first, like the “semanticId”: {policy} (or something like this))
					◊ Maybe dispatcher is not needed for now (good that the concept is there)
			□ Check that the partner has access to the twin, there is a “AAS” policy definition for that:  https://github.com/eclipse-tractusx/sldt-digital-twin-registry/blob/main/docs/development/postman/access-rule-management-v3-postman-collection.json , or we can also add it in the twin itself.
		§ Read API:
			□  with who I am already sharing this product (LIST of BPNLs) -> keep track of that.