Difference between revisions of "Validation"

From AMTech WikiDocs
Jump to: navigation, search
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 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 at in the UI to validate a bridge instance
 +
 
 +
Validation requirements
  
 
* Bridge type must produce crud observations (Check on thing type)
 
* Bridge type must produce crud observations (Check on thing type)

Revision as of 08:27, 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 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