I am facing a new requirement and would love to get your advice regarding it.
I would like to know if that will break the SID model, and i would love to hear your opinions for any other approches.
Anyone faced the same situation :)
The important aspect (in my opinion) is not how you model your catalog internally, but rather how you expose the model to consumers (e.g. UI clients at ordering time).
The SID is not noted for being an easy model to expose using APIs, which is why the Open API models tend to be simpler (less class hierarchies, less associations), possibly at the expense of denormalization.
Specifically here, the Open API has a 0..* relationship from ProductOffering to Channel, via the ChannelRef. Unfortunately, we never defined the Channel entity in the API model, but you could build one yourself as an extension. However this would not help your use case, since you want to add the code. You could "ignore" the existing relationship and create a new association class in the API model, where the association class would have this code as a property, much as you have described for SID.
An alternative approach might be to use characteristics, which we have added to ProductOffering in v5 of the API, but using characteristics gives a weaker contract.
Hope it helps
were you able to find a solution to your problem ? I would like to know more about it. I am some what new to SID and want to understand what are the rules of customization to SID for our individual implementation. Given that SID is a industry framework we need to keep the extensions minimal and there has to be a collaborations between all the SID designers.
How ever the excel format 22.5 version or version 23 , has only details at entity level , but not at field level and even the functional diagrams are mostly having 1 or 2 attributes/fields mentioned. How shall we know the detailed fields list in each entity ?
After some research I will be following the approach, I mentioned earlier.
I will remove the existing relation between product offering and sales channel entities, and I will replace it with a new association table with optional attribute "code" in the association table.
Actually, I found that approach used on other relations, for example the self-relation for the ProductOffering is created on association table ProductOfferingRelationship with additional attribute "type".
Regarding the API, I will expose the attribute as a non-mandatory query parameter in the API, if provided it shall be used for mapping to the ProductOffering, if not provided it will cause no issues as it is not mandatory.
For your question about the SID model, you should use a modeling tool like (Papyrus, Visual Paradigm, ..etc) and import the SID model project, then you will get access to all diagrams and entities.