|
Post by hramasub on Feb 27, 2017 13:04:05 GMT
Please provide an illustrative example of a Service Metadata document for a service which has the following types of OEM extensions : a) custom resources (say, an Audit Log resource collection with Audit Log entries) b) custom properties for standard redfish resources (say, an Engineering Revision number for a Processor)
note: The above oem extension uses are made up just to understand the concepts. They are not necessarily per the redfish resource modeling guidelines.
|
|
|
Post by mraineri on Mar 7, 2017 20:18:34 GMT
In this example, ServiceRoot has the "Oem" property filled out to point to an OEM defined entity.
First, the $metadata resource; note that towards the bottom there are references to schemas found outside of the DMTF schema folder (in particular ContosoExtensions_v1.xml and TurboencabulatorService_v1.xml).
<?xml version="1.0" encoding="UTF-8"?> <!-- Copyright 2014-2016 Distributed Management Task Force, Inc. (DMTF). For the full DMTF copyright policy, see http://www.dmtf.org/about/policies/copyright.--> <edmx:Edmx xmlns:edmx="http://docs.oasis-open.org/odata/ns/edmx" Version="4.0">
<edmx:Reference Uri="http://redfish.dmtf.org/schemas/v1/ServiceRoot_v1.xml"> <edmx:Include Namespace="ServiceRoot"/> <edmx:Include Namespace="ServiceRoot.v1_1_1"/> </edmx:Reference>
<edmx:Reference Uri="http://redfish.dmtf.org/schemas/v1/AccountService_v1.xml"> <edmx:Include Namespace="AccountService"/> <edmx:Include Namespace="AccountService.v1_0_2"/> </edmx:Reference> <edmx:Reference Uri="http://redfish.dmtf.org/schemas/v1/ManagerAccount_v1.xml"> <edmx:Include Namespace="ManagerAccount"/> <edmx:Include Namespace="ManagerAccount.v1_0_2"/> </edmx:Reference> <edmx:Reference Uri="http://redfish.dmtf.org/schemas/v1/ManagerAccountCollection_v1.xml"> <edmx:Include Namespace="ManagerAccountCollection"/> </edmx:Reference> <edmx:Reference Uri="http://redfish.dmtf.org/schemas/v1/Message_v1.xml"> <edmx:Include Namespace="Message"/> <edmx:Include Namespace="Message.v1_0_0"/> </edmx:Reference> <edmx:Reference Uri="http://redfish.dmtf.org/schemas/v1/Role_v1.xml"> <edmx:Include Namespace="Role"/> <edmx:Include Namespace="Role.v1_0_2"/> </edmx:Reference> <edmx:Reference Uri="http://redfish.dmtf.org/schemas/v1/RoleCollection_v1.xml"> <edmx:Include Namespace="RoleCollection"/> </edmx:Reference> <edmx:Reference Uri="http://redfish.dmtf.org/schemas/v1/Session_v1.xml"> <edmx:Include Namespace="Session"/> <edmx:Include Namespace="Session.v1_0_2"/> </edmx:Reference> <edmx:Reference Uri="http://redfish.dmtf.org/schemas/v1/SessionCollection_v1.xml"> <edmx:Include Namespace="SessionCollection"/> </edmx:Reference> <edmx:Reference Uri="http://redfish.dmtf.org/schemas/v1/SessionService_v1.xml"> <edmx:Include Namespace="SessionService"/> <edmx:Include Namespace="SessionService.v1_0_2"/> </edmx:Reference>
<edmx:Reference Uri="http://redfish.dmtf.org/schemas/v1/RedfishExtensions_v1.xml"> <edmx:Include Namespace="RedfishExtensions.v1_0_0" Alias="RedfishExtensions"/> </edmx:Reference>
<edmx:Reference Uri="http://Contoso.com/schemas/ContosoExtensions_v1.xml"> <edmx:Include Namespace="ContosoExtensions.v1_0_0"/> </edmx:Reference> <edmx:Reference Uri="http://Contoso.com/schemas/TurboencabulatorService_v1.xml"> <edmx:Include Namespace="TurboencabulatorService"/> <edmx:Include Namespace="TurboencabulatorService.v1_0_0"/> </edmx:Reference>
<edmx:DataServices>
<Schema xmlns="http://docs.oasis-open.org/odata/ns/edm" Namespace="Service"> <EntityContainer Name="Service" Extends="ContosoExtensions.v1_0_0.ServiceContainer"/> </Schema>
</edmx:DataServices> </edmx:Edmx>
And this is how the ServiceRoot resource response is extended to provide a new navigation property; note how the "Oem" property contains the odata.type in the ContosoExtensions namespace.
{ "@odata.type": "#ServiceRoot.v1_1_1.ServiceRoot", "Id": "RootService", "Name": "Root Service", "RedfishVersion": "1.0.2", "UUID": "92384634-2938-2342-8820-489239905423", "SessionService": { "@odata.id": "/redfish/v1/SessionService" }, "AccountService": { "@odata.id": "/redfish/v1/AccountService" }, "Links": { "Sessions": { "@odata.id": "/redfish/v1/SessionService/Sessions" } }, "Oem": { "Contoso": { "@odata.type": "#ContosoExtensions.v1_0_0.ServiceRoot", "TurboencabulatorService": { "@odata.id": "/redfish/v1/TurboencabulatorService" } } }, "@odata.context": "/redfish/v1/$metadata#ServiceRoot.ServiceRoot", "@odata.id": "/redfish/v1/", "@Redfish.Copyright": "Copyright 2014-2016 Distributed Management Task Force, Inc. (DMTF). For the full DMTF copyright policy, see http://www.dmtf.org/about/policies/copyright." }
And for reference is the sample ContosoExtensions_v1.xml file; notice the ComplexType with the name "ServiceRoot"
<?xml version="1.0" encoding="UTF-8"?> <!----> <!--################################################################################ --> <!--# Contoso Schema: ContosoExtensions v1.0.0--> <!--# --> <!--# Copyright 2014-2016 Distributed Management Task Force, Inc. (DMTF). --> <!--# For the full DMTF copyright policy, see http://www.dmtf.org/about/policies/copyright --> <!--################################################################################ --> <!----> <edmx:Edmx xmlns:edmx="http://docs.oasis-open.org/odata/ns/edmx" Version="4.0">
<edmx:Reference Uri="http://docs.oasis-open.org/odata/odata/v4.0/errata03/csd01/complete/vocabularies/Org.OData.Core.V1.xml"> <edmx:Include Namespace="Org.OData.Core.V1" Alias="OData"/> </edmx:Reference> <edmx:Reference Uri="http://redfish.dmtf.org/schemas/v1/ServiceRoot_v1.xml"> <edmx:Include Namespace="ServiceRoot.v1_1_1"/> </edmx:Reference> <edmx:Reference Uri="http://Contoso.com/schemas/TurboencabulatorService_v1.xml"> <edmx:Include Namespace="TurboencabulatorService"/> </edmx:Reference>
<edmx:DataServices>
<Schema xmlns="http://docs.oasis-open.org/odata/ns/edm" Namespace="ContosoExtensions.v1_0_0">
<EntityContainer Name="ServiceContainer" Extends="ServiceRoot.v1_1_1.ServiceContainer"> <Singleton Name="TurboencabulatorService" Type="TurboencabulatorService.TurboencabulatorService"/> </EntityContainer>
<ComplexType Name="ServiceRoot"> <NavigationProperty Name="TurboencabulatorService" Type="TurboencabulatorService.TurboencabulatorService" Nullable="false"> <Annotation Term="OData.Permissions" EnumMember="OData.Permission/Read"/> <Annotation Term="OData.Description" String="Link to the Turboencabulator Service."/> <Annotation Term="OData.LongDescription" String="This property shall contain the link to the Turboencabulator Service."/> <Annotation Term="OData.AutoExpandReferences"/> </NavigationProperty> </ComplexType>
</Schema>
</edmx:DataServices> </edmx:Edmx>
|
|
|
Post by millerpau on Mar 15, 2018 22:00:24 GMT
Is there an example of how Oem Actions would be defined in an Oem extension and how such actions would be referenced in the Actions.Oem section of the resource instance. In the mockup for rack server ComputerSystem, I see an action Contoso.Reset but it is unclear how client would know which schema to reference. Just wondering if there is missing information in the mock?
Thanks
|
|
|
Post by mraineri on Mar 16, 2018 11:58:16 GMT
Actions in the response payload are represented in the following manner: { "#Namespace.ActionName": { "target": "some URI" } }
This format is defined by OData and leveraged by Redfish. "Namespace" is the CSDL Namespace where the action is defined, and "ActionName" is the name of the Action object in the schema file. The "Namespace" can ultimately be found based on the referenced namespaces in the $metadata resource. So, if a client were to come across the action "#Contoso.Reset", the methodology to resolve where the action is defined would be to: - Go to the $metadata resource and locate the namespace "Contoso"
- Go to the file referenced by $metadata and locate the namespace "Contoso"
- Within the "Contoso" namespace, locate the Action named "Reset"
This same process can be applied generically with all actions (not just OEM actions). Unfortunately the DPS2043 bundle does not have the $metadata resource updated to include these same OEM namespaces. But effectively to correct this, $metadata would also include something like this: <edmx:Reference Uri="http://Contoso.com/schemas/Contoso_v1.xml"> <edmx:Include Namespace="Contoso"/> </edmx:Reference>
|
|
|
Post by jautor on Mar 16, 2018 15:38:38 GMT
Is there an example of how Oem Actions would be defined in an Oem extension and how such actions would be referenced in the Actions.Oem section of the resource instance. In the mockup for rack server ComputerSystem, I see an action Contoso.Reset but it is unclear how client would know which schema to reference. Just wondering if there is missing information in the mock? Thanks Yes, you've found a small hole in the spec, which I'll work with the group to close. The answer will be to use the schema defined in the "Oem" section which should contain any definitions for OEM Action(s). We originally had placed the OEM Actions in the "Oem" section, but moved them under Actions in the final v1.0 spec so that software looking for Actions would be able to find them. But that move lost the linkage to the OEM schema. So if you have no OEM properties to extend in that schema, just create an "Oem" section with nothing except an "@odata.type" to refer to your OEM schema (which has the OEM Action defined). I'll recommend that the group add language to the spec to make that linkage... And update the mockups to show examples of that. Thanks! Jeff
|
|
|
Post by millerpau on Mar 19, 2018 15:38:25 GMT
That's what I was thinking but just wanted to make sure.
Thanks Paul
|
|