Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Current »

CPS-817 - Getting issue details... STATUS

Creating a new get cm handle endpoint.

REST layer

  • nmcp.yml
    • New endpoint for retrieveCmHandleByName to retrieve cm handle details by the cm handles name/id.
  • NetworkComProxyController.java
    • New method retrieveCmHandleByName() which calls a new method getCmHandleDetails from NetworkCmProxyDataService
  • NetworkCmProxyController.groovy
    • Add test for scenario above.

Service Layer

  • NetworkCmProxyDataService.java
    • New getCmHandleDetails() method to be overwritten.
  • NetworkCmProxyDataServiceImp.java
    • Implement getCmHandleDetails and call retrieveCmHandleDetails from the persistence layer.

Persistence Layer

PersistenceCmHandleRetriever.java

  • New method retrieveCmHandleDetails().

API details

Description

URI

Sample Response Body

Get Cm Handle details by name.

GET

 {ncmpRoot}/ncmp/v1/ch/PNFDemo

{
    "cmHandle": "Bookstore",
    "cmHandleProperties": [
        {
            "Public-Book1": "Public Sci-Fi Book",
            "Public-Book2": "Public Horror Book",
            "Public-Book3": "Public Crime Book"
        }
    ]
}

Open Question

Currently within CPS we have two separate models for CmHandles these being CmHandle and PersistenceCmHandle. These are both very similar models, the primary difference being that persistenceCmHandle also contains references to the dmiServiceName, the dmiDataServiceName and the dmiModelServiceName as seen below.

Is it necessary to have both these models?

As PersistenceCmHandle has all the necessary fields of CmHandle, can we just modify existing code to use PerisistenceCmHandle and remove CmHandle?

Cm Handle ModelPersistence Cm Handle Model
CmHandle.java
/**
 * CmHandle.
 */
@Validated
@Getter
@Setter
@NoArgsConstructor
public class CmHandle {

    @JsonProperty("cmHandle")
    private String cmHandleID;

    @JsonSetter(nulls = Nulls.AS_EMPTY)
    @JsonProperty("cmHandleProperties")
    private Map<String, String> dmiProperties = Collections.emptyMap();

    @JsonSetter(nulls = Nulls.AS_EMPTY)
    @JsonProperty("publicCmHandleProperties")
    private Map<String, String> publicProperties = Collections.emptyMap();

}

PersistenceCmHandle.java
/**
 * DmiRegistry.
 */
@Getter
@Setter
@NoArgsConstructor
public class PersistenceCmHandle {

    private String id;

    @JsonProperty("dmi-service-name")
    private String dmiServiceName;

    @JsonProperty("dmi-data-service-name")
    private String dmiDataServiceName;

    @JsonProperty("dmi-model-service-name")
    private String dmiModelServiceName;

    @JsonProperty("additional-properties")
    private List<Property> dmiProperties;

    @JsonProperty("public-properties")
    private List<Property> publicProperties;
  • Both contained within the same package
  • Properties are only used within PersistenceCmHandle to set Persistence Cm Handle ID, DMI and public properties when a cm handle is being retrieved using the get data node api.
  • Both are contained in the same package
  • Properties are also used in DmiModelOperations and DmiData operation when getting and writing resource data to DMI, and when fetching yang resources. 
  • Is also used to persist the cm handle to the fragment table within CPS db

PROS

  • Removing potentially redundant model that is not used.

CONS

  • Could be a time consuming process to refactor the code for functionality which already works

Potential Issue

If we decide to only use one model, one potentially backwards incompatible change is the property names, which differ between persistenceCmHandle and the CmHandle class.

Also should this refactoring be done as part of a separate story?

Conclusion

Add more detailed comments to both models. Rename cm handle model to RestCmHandle to further represent that it is the request body format of the REST api.

  • No labels