Difference between revisions of "Validation"
From AMTech WikiDocs
| Line 2: | Line 2: | ||
*To simplify the process of validating the configuration there is an option at in the UI to validate a bridge instance | *To simplify the process of validating the configuration there is an option at in the UI to validate a bridge instance | ||
| − | Validation requirements | + | '''Validation requirements''' : |
* Bridge type must produce crud observations (Check on thing type) | * Bridge type must produce crud observations (Check on thing type) | ||
| + | * Bridge must have observation production configuration | ||
* All thing types configured to produce observations behind the bridge, must have an instance in the bridge's instance list (property Bridge Intances) | * All thing types configured to produce observations behind the bridge, must have an instance in the bridge's instance list (property Bridge Intances) | ||
* All observation types configured to be produced behind the bridge must be published | * 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 (targe things is not required though) | * 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) | ||
* 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/…./#{deviceId}/…) | ||
| − | * Topics in config must have a root topic owned by the creator | + | * 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 (and all its links too) |
| − | * 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) |
| − | + | ||
| − | * | + | '''Aggregation validation''' : |
| − | + | ||
| − | * | + | * There must be at least one thing instance in bridgeInstances for those types in the aggregationTypes |
| + | * If the user performing the validation is a follower, it must have actor for all types in the bridge aggregationTypes | ||
| + | * Things in the bridge aggregationInstances must be included in the bridgeInstances property | ||
warning if the bridge has no property aggInstances (not via UI) | warning if the bridge has no property aggInstances (not via UI) | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | Network errors | + | '''Network errors''' : |
* Only one bridge in the network can be “aggregator” for a type (ex. BLEbeaconsScanner) | * Only one bridge in the network can be “aggregator” for a type (ex. BLEbeaconsScanner) | ||
| Line 34: | Line 30: | ||
** Aggregator source => bridge has the instance Reader1 in its aggregationInstances | ** Aggregator source => bridge has the instance Reader1 in its aggregationInstances | ||
| − | + | 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 | ||
Revision as of 07:41, 24 August 2016
- At startup time the M2MBridge validates its configuration with the cloud. If errors are found, the application aborts.
- To simplify the process of validating the configuration there is an option at in the UI to validate a bridge instance
Validation requirements :
- Bridge type must produce crud observations (Check on thing type)
- Bridge must have observation production configuration
- All thing types configured to produce observations behind the bridge, must have an instance in the bridge's instance list (property Bridge Intances)
- 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 (targe 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/…./#{deviceId}/…)
- 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 (and all its links too)
- 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)
Aggregation validation :
- There must be at least one thing instance in bridgeInstances for those types in the aggregationTypes
- If the user performing the validation is a follower, it must have actor for all types in the bridge aggregationTypes
- Things in the bridge aggregationInstances must be included in the bridgeInstances property
warning if the bridge has no property aggInstances (not via UI)
Network errors :
- Only one bridge in the network can be “aggregator” for a type (ex. BLEbeaconsScanner)
- A bridge can not be aggregator and aggregator source
- aggregator of type Reader => bridge has the type Reader in its aggregationTypes)
- Aggregator source => bridge has the instance Reader1 in its aggregationInstances
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
