search

eclipse-tractusx / item-relationship-service

https://eclipse-tractusx.github.io/item-relationship-service/docs/
Apache License 2.0
7 stars 22 forks source link

[CONCEPT] Deprecation of semantic Models #216

Closed jzbmw closed 9 months ago

jzbmw commented 1 year ago

As a PO , I want to make sure that the IRS is not impacted by deprecation of semantic models, so that the system is still stable when the deprecation process is fulfilled.

Hints / Details

Outcome / Acceptance Criteria

Outcome

Out of Scope

ds-ext-kmassalski commented 11 months ago

Currently, the IRS retrieves the names of all Aspects from the Semantic Hub service and compares them with the names submitted in the request body. The aspect status is currently ignored by the IRS, so it is possible to register a Job for aspects that have been marked as DEPRECATED.

"Concept covers the effect on the IRS is analyzed": As currently IRS is ignoring status, there is no effect on IRS - it will be still possible to register a Job and collect aspect marked as deprecated (just as its currently possible)

It is possible to implement a filter for aspects by status when retrieving them from Semantic Hub using the status query parameter like this: {{SEM_HUB}}/hub/api/v1/models?status=RELEASED. This way, attempting to start a Job with aspects marked as DEPRECATED will fail, with below response (assumption SerialPartType is deprected):

{
"statusCode": "BAD_REQUEST",
"error": "Aspects did not match the available aspects: '[SerialPartType]'",
"messages": null
}

So long story short, if we will use status query parameter we wont let to collect aspects marked as DEPRECATED. image

jzbmw commented 11 months ago

@ds-ext-kmassalski thank you for documentation. Some questions regarding that.

ds-ext-kmassalski commented 11 months ago

How about the semantic models, for which internal Classes are necessary? Like SingleLevelBomAsBuilt? We need some coding effort to support these, correct? We generally support the latest versions of traversal aspects, and we need code changes only if there are not compatible changes in newer aspects versions, eg. SingleLevelBomAsBuilt:v5.0 contains breaking changes to SingleLevelBomAsBuilt:v4.0. During last two years I think only once we have had not compatible changes in travel aspects (I might be wrong here).

Is it possible to retrieve different versions? For example Data Provider 1 has SingleLovelBomAsBuilt:v1.0.0 and Data Provider 2 SingleLevelBomAsBuilt:v2.0.0 what happens with the process? Thats a little bit tricky and it is related to the above question, there are two possible scenarios:

  1. if SingleLevelBomAsBuilt:v1.0.0 is compatible with SingleLevelBomAsBuilt:v2.0.0 IRS will be able to retrieve and build relationships from both DataProviders,
  2. if SingleLevelBomAsBuilt:v1.0.0 is NOT compatible with SingleLevelBomAsBuilt:v2.0.0 (v2 contains breaking changes) IRS will be able to retrieve and build relationships from only ONE DataProvider. Usually we are up to date with models, so probably from DP with SingleLevelBomAsBuilt:v2.0.0. It's worth mentioning that IRS will fall into an unexpected exception here - probably we should handle such situations and create a tombstone instead.

Do we need to change our API Versioning, when Semantic Modells will be changed? Its not necessary and I wouldnt do it, as our API doesnt change - in our API submodels payload is presented as a Map. image

What does that mean for Business Applications, when delivering multiple different Versions of the same model? In IRS payload is a map, we are returning necessary informations including versions, eg:

"submodels": [
    {
      "aspectType": "urn:bamm:io.catenax.batch:1.0.0",
      "identification": "urn:uuid:fc784d2a-5506-4e61-8e34-21600f8cdeff",
      "payload": {
        << payload of aspect in v1.0.0 version >>
      }
    },
    {
      "aspectType": "urn:bamm:io.catenax.batch:2.0.0",
      "identification": "urn:uuid:d4284d5v-5565-4f65-2e21-31600f8cdegg",
      "payload": {
        << payload of aspect in v2.0.0 version >>
      }
    }
]

If v1.0.0 is deprecated in Semantic Hub we will return payload anyway - as mentioned IRS is ignoring statuses of models.

Is there something we can do to mitigate this? Currently IRS is ignoring not only status, but also versions, so below request will retrieve batches with any version and any status from DataProviders:

{
    "aspects": [
        "Batch"
    ],
    "collectAspects": true,
    ...
}

If we would like to support collecting of aspects with specific versions, we should change our API to include full urn, eg:

{
    "aspects": [
        "urn:bamm:io.catenax.batch:2.0.0"
    ],
    "collectAspects": true,
    ...
}

Above would collect only batches with version 2.0.0 from DP's.

jzbmw commented 10 months ago

Within the to be released KIT Industry Core, there will be a section regarding backwardscompatibality. Therefore this information will be shared wit 24.03 Relese

jzbmw commented 9 months ago

@ds-ext-kmassalski do you think it might be possible, that the IRS, could for example run on two major versions of a relationship type? Is something like that possible?