Difference between revisions of "Validation"
From AMTech WikiDocs
| Line 5: | Line 5: | ||
* Bridge type must produce crud observations (Check on thing type) | * Bridge type must produce crud observations (Check on thing type) | ||
| + | * 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 | ||
* Bridge instance must be valid for its metadata (and all its links too) | * Bridge instance must be valid for its metadata (and all its links too) | ||
* When adding observation production config, thing types must be one of the types of the bridgeInstances | * When adding observation production config, thing types must be one of the types of the bridgeInstances | ||
Revision as of 07:31, 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)
- 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
- Bridge instance must be valid for its metadata (and all its links too)
- When adding observation production config, thing types must be one of the types of the bridgeInstances
- 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 of the activity (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)
- All links explicitly included in the property bridgeInstances
- Clone can be performed (access to external links used in proximityArea)
- 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
- 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
Note : Validation can be performed selecting multiple bridges, with the goal of getting validation errors for the network of bridges being validated
