Difference between revisions of "Validation"

From AMTech WikiDocs
Jump to: navigation, search
 
(22 intermediate revisions by 3 users not shown)
Line 1: Line 1:
*At startup time the M2MBridge validates it configuration with the cloud is an error occurrences the application aborts
+
*At startup time the M2MBridge validates its configuration with the cloud. If errors are found, the M2MBridge application aborts.
*To simplify the process of validation configuration there is an option at Sensor network to [[Sensor%27s_network#Observation_production_.26_M2MBridge_validation|validate]] a configuration for a M2MBridge instance
+
*To simplify the process of validating the configuration there is an option in the UI to validate a bridge instance.
 +
* Validations can be performed as creator or follower
 +
 
 +
'''Validation requirements''' :
  
 
* Bridge type must produce crud observations (Check on thing type)
 
* Bridge type must produce crud observations (Check on thing type)
* Bridge instance must be valid for its metadata (and all its links too)
+
* Bridge must have observation production configuration
* When adding observation production config, thing types must be one of the types of the bridgeInstances
+
* Bridge instances must exist for all types that produce observations (this will be shown as an error for creator and as a warning for followers validating bridge templates)
* All thing types configured to produce observations must have at least one observation type that they produce in the config (targe things is not required though)
+
* All observation types configured to be produced behind the bridge must be published
 +
* If the user validating the bridge is a follower, it must have actors for all thing types configured to produce observations behind the bridge
 +
* All thing types configured to produce observations must have at least one observation type that they produce in the config (target things is not required though)
 
* Topics in config cannot be empty
 
* Topics in config cannot be empty
* Topics in config must start with an explicit topic, and may have placeholders only after that (Ex. /topic1/…./#{deviceId}/…)
+
* Topics in config must start with an explicit topic, and may have placeholders only after that (Ex. /topic1/…./#{bridgeId}/…)
* Topics in config must have a root topic owned by the creator of the activity (this validation only applies for creators)
+
* Topics in config must have a root topic owned by the creator that owns the bridge template (this validation only applies for creators)
* There must be instances in the bridgeInstances for all types that produce observations (it is not doable via UI, only via DAP)
+
* Bridge instance must be valid for its metadata. All resources contained in the bridge must be valid too. Ex. ErrorConfig, StartConfig, StopConfig, etc.
* All links explicitly included in the property bridgeInstances
+
* All links must be explicitly included in the property bridgeInstances (ex. if a bridge has an instance behind it that is an LLRPReader, all the antennas associated to that reader must be explicitly included in the bridgeInstances as well)
* Clone can be performed (access to external links used in proximityArea)
+
* Things in the bridgeInstance list cannot be associated with any other bridge. This restriction will make sure that the instance can be uniquely addressed for sending commands to it.
* Validate aggregation types (there must be at least one instance in bridgeInstances for those types in the aggregationTypes)
+
warning if the bridge has no property aggtypes (not via UI)
+
* Validate aggregation instances (instances in aggregationInstances must be included in the bridgeInstances)
+
warning if the bridge has no property aggInstances (not via UI)
+
* A bridge may have bridge instances whose type is not configured to produce observations (ex. Instances behind the bridge that will only receive command, not send any observation)
+
* A bridge may be valid without having observation production (ex. A bridge with instances that receives commands only)
+
* Do not allow to configure crud inside bridge obs production
+
* If follower, validate it has access for types used in AggregationTypes and AggregationInstances
+
* Share bridge observationProduction with the bridge guest tenant and guest users when the bridge is validated
+
* Warning when there is no obs to validate (just warning, it may be that the creator added the obs production after sharing the bridge, but did not validate , and then the follower validates)
+
  
Network errors
+
'''Notes''':
 +
 
 +
* A bridge may have bridge instances whose type is not configured to produce observations (ex. Instances behind the bridge that will only receive command, not send any observation)
 +
* Upon bridge validation as creator, the bridge observationProduction is shared with the bridge guest tenant and guest users. This will ensure that followers cloning that bridge will have access to the observationProduction
  
* Only one bridge in the network can be “aggregator” for a type (ex. BLEbeaconsScanner)
+
'''User experience''':
* A bridge can not be aggregator and aggregator source
+
*To validate a single bridge select it at amtechM2mBridge collection:
** aggregator of type Reader => bridge has the type Reader in its aggregationTypes)
+
[[File:SingleBridgeValidation.png|850px|thumbnail|center|Validate a bridge]]
** Aggregator source => bridge has the instance Reader1 in its aggregationInstances
+
  
Note : Validation  can be performed selecting multiple bridges, with the goal of getting validation errors for the network of bridges being validated
+
*To validate multiple bridges select them at amtechM2mBridge collection:
 +
[[File:ValidatemultipleBridge.png|850px|thumbnail|center|Validate multiple bridges]]

Latest revision as of 14:29, 22 November 2018

  • At startup time the M2MBridge validates its configuration with the cloud. If errors are found, the M2MBridge application aborts.
  • To simplify the process of validating the configuration there is an option in the UI to validate a bridge instance.
  • Validations can be performed as creator or follower

Validation requirements :

  • Bridge type must produce crud observations (Check on thing type)
  • Bridge must have observation production configuration
  • Bridge instances must exist for all types that produce observations (this will be shown as an error for creator and as a warning for followers validating bridge templates)
  • All observation types configured to be produced behind the bridge must be published
  • If the user validating the bridge is a follower, it must have actors for all thing types configured to produce observations behind the bridge
  • All thing types configured to produce observations must have at least one observation type that they produce in the config (target things is not required though)
  • Topics in config cannot be empty
  • Topics in config must start with an explicit topic, and may have placeholders only after that (Ex. /topic1/…./#{bridgeId}/…)
  • Topics in config must have a root topic owned by the creator that owns the bridge template (this validation only applies for creators)
  • Bridge instance must be valid for its metadata. All resources contained in the bridge must be valid too. Ex. ErrorConfig, StartConfig, StopConfig, etc.
  • All links must be explicitly included in the property bridgeInstances (ex. if a bridge has an instance behind it that is an LLRPReader, all the antennas associated to that reader must be explicitly included in the bridgeInstances as well)
  • Things in the bridgeInstance list cannot be associated with any other bridge. This restriction will make sure that the instance can be uniquely addressed for sending commands to it.

Notes:

  • A bridge may have bridge instances whose type is not configured to produce observations (ex. Instances behind the bridge that will only receive command, not send any observation)
  • Upon bridge validation as creator, the bridge observationProduction is shared with the bridge guest tenant and guest users. This will ensure that followers cloning that bridge will have access to the observationProduction

User experience:

  • To validate a single bridge select it at amtechM2mBridge collection:
Validate a bridge
  • To validate multiple bridges select them at amtechM2mBridge collection:
Validate multiple bridges