-
Story
-
Resolution: Done
-
Low
-
None
Where should this validation be implemented?
- Dataspace Creation(Cps-Core)
- Schema Sets(Cps-Core)
- Anchor Creation (Cps-Core).
- During CM Handle Registration for cm handle name(Cps-NCMP Extends Anchor creation).
- NCMP Properties(Potential Future debt fix Cps-NCMP)
The name should not have
- comma - which is mostly used to separate name when providing multiple. In CPS Temporal, we need to provide an option to get data for multiple anchors. And, a comma-separated string is a concise way to provide it as a query parameter.
Note - Look for current network function id's convention.
https://wiki.onap.org/display/DW/VNF+HEAT+Requirements
Potential Implementation proposals
Use general reg ex string validation. Investigate potential Apache library.
Use Spring validator at service layer, using @Validated,@Valid tags.
Throw Data Validation exception 400 BAD_REQUEST
Open Issues
- CPS-Core-exact rules for valid names (suggestion: [A-Za-z0-9_]+ consider dash ?!)
- Dataspace
- Schemaset
- Anchor
- CM-handle ID (NCMP interfaces) more strict or same as anchor-names ?!
- if same rules apply can we rely on CPS-Core validation (exception thrown) or use early validation
Might need to change code to attempt to create anchor BEFORE registering - alternative: CPS-Core might expose validation (JAVA) interface lis isValidAnchorName()
- if same rules apply can we rely on CPS-Core validation (exception thrown) or use early validation
- Validation on get/query scenarios
- recommend not, little value, high costs!
Out-of-scope:
- exception handling/partial failure ->done in separate user story
- CSIT Test (not on negative scenarios)
A/C
- Document and agree with team and stakeholders (regex) for valid names (dataspace,schemaset,anchor,cm-handle)
- Agree with team and stakeholder where validation is implemented and if exposed as interface
- Demo negative scenario's for each
- dataspace
- schemaset
- anchor
- cm-handle