Hi @Ludovic Robert,
thanks for getting back to me, really helpful thoughts, I've interpreted this as: -
Hi @Ludovic Robert, thanks for going into this detail, this is really helpful! (a picture always helps i find!)Whilst i do you follow you thinking here i'd question that if we were to model the 'Method' as a characteristic of a single service spec created for the installation then how would we drive the onward dependency of the other characteristics?i.e. 'newLine' requires the client to pass CharacterisitcA and CharacteristicB
'siwtch' requires the client to pass CharacteristicC and CharacteristicD
A list of service order items (ServiceOrderItem [*]). A list of order items embedded to this order item.
A list of service order item relationships (ServiceOrderItemRelationship [*]). A list of order items related to this order item.
thanks @Ludovic Robert, you're correct the swagger doesnt say that the service order id is mandatory, its the user guide i'd understood was defining this as part of the 'additional rules' for 'create service order'
If i look at the swagger the serviceOrderItem.serviceOrderItemRelationship defines the 'orderItem' property as a ServiceOrderItemRef. Within that object it mentions that a field called 'id' is required but there is no field in that object called id?
"description": "Identifier of the line item"
"description": "Link to the order to which this item belongs to"
"description": "Identifier of the order that this item belongs to"
"description": "When sub-classing, this defines the super-class"
"description": "A URI to a JSON-Schema file that defines additional attributes and relationships"
"description": "When sub-classing, this defines the sub-class Extensible name"
"description": "The actual type of the target instance when needed for disambiguation."
hey @Koen Peeters,thanks as always for your response. Definately see that there could be something in 'inventrifying' those more 'state change' based services which get us from a place of not having a network service to having one.
Could you point me at the SID document that made a start on this for Product? I'm still learning how to navigate the TMF docs :-)
thanks again @Derrick Evans."The only other way I can see it is to put up with the repetition of characteristics across multiple varients of the specifications for each installation method or include all the characteristics in the one specification and have an horrendous set of rules to validate the various combinations."Where as i could see that TMF model would allow this i fully agree with you that should the framework be used in this way its so loose that IMO a client has no hope of 'getting it right' therefore we steered well clear of that :-). It really goes against the idea of a self documenting platfrom and whilst i know that not everything lives in swagger docs but if the combination of them and the catalog setup can provide this in a way that is clearly understandible for a client on what they need to do then this is a far better approach. Once we start to open up word docs or wiki pages to explain the complexity of the backend logic its fraught with human error.
really great to get this feedback so thanks for spending the time on it, I agree that ludovics suggestion seems like a good approach. My only reservation is that if these are 'fake' services (the installation service) then I dont see how the 641 API can honour the contract and return an id for the installation service as it doesnt really feel like something that would make it into the inventory at all, any thoughts?