Open kmohr-soprasteria opened 6 months ago
Tested ok 1.1.2.c_impl
Example for mount-name: 513250009
Tested with latest MWDI version 1.1.2.g_impl, Issue is no longer observed.
http://XXXXXX:XXXX/v1/provide-list-of-actual-device-equipment
{
"top-level-equipment": [
"SLOT-1"
],
"actual-equipment-list": [
{
"uuid": "RMM-1",
"equipment-type-name": "Removable Memory Module"
},
{
"uuid": "SFP-1.2",
"equipment-type-name": "10GBASE_LR_LW"
},
{
"uuid": "SFP-1.3",
"equipment-type-name": "1000BASE_T"
},
{
"uuid": "SFP-1.4",
"equipment-type-name": ""
},
{
"uuid": "SLOT-1",
"equipment-type-name": "MINI-LINK 6352 80/21H"
}
]
}
The service
/v1/provide-list-of-actual-device-equipment
returns on data from the Cache, derived as follows:ElasticSearch://control-construct={mountName}?fields=top-level-equipment;equipment(uuid;actual-equipment(manufactured-thing(equipment-type(type-name))))
I tried running a responseBody completeness test in the lab, where the responseBody is compared to the responseSchema. The required property equipment-type-name of actual-equipment-list sometimes is missing, therefore the testcase fails (which is not actually an MWDI issue).
See example for mount-name: 513559991A
For SFP-1.4 there is no equipment-type-name.
The OAS lists this attribute as required. As this is a convenience server and not a ressource path, MWDI should not just return what is see's in the cache 1:1. Instead MWDI implementation should be modified as follows:
(If required the description in the OAS could be extended to reflect that requirement more clearly (with own issue), this would be done with milestone v1.1.3_spec.)