Activities

How it works

Activity

Activity is a resource that links resource types Actor, Observer, Reasoner, Actions, Topics, Things, Observations and Observation Production Configuration with the objectives of:

• Deploy and publish reasoners to be executed in the cloud
• Publish Observation production configuration to be executed at M2MBridge
• Deploy Edge Reasoners to be executed in the M2MBridge
• SaaS unit of deployment
  • Allow followers to subscribe to activities

Observers

The activities have three collections of observers

• observers
• observers for API
• observers for follower

The first collection contains the activity observers while the other two are links to query observers that will be shared with those subscribed to the service associated to the current activity. For details on Observers, please see Observers.

Actors

• Actors are resources that define access control policies to thing and notification types
• Actors are defined for a tenant and they are not shared with other tenants (although their names must be unique accross tenants)
• Actors are associated to activities, meaning that the follower admin that subscribes to the service will adquire all those access control policies. The follower admin can then selectively give actors to the other followers he invites.

Thing types

• Things types are used in observers and reasoners
• Access to thing types is defined in the actors that are associated to the activity
• Thing types have a configuration for the production of observations that is used in the activity. Each thing type has the set of observations it may produce. This will be the observations available for selection when configuring the observation production of that thing type inside the activity observation production configuration

Notification types

See Notifications

• Notifications are defined as types in the same way that things and observations are.
• A notification type contains well-known supported properties, such as subject and body.
• Notifications types can be used in actor's policies to define access to the instances of the notifications types
• Instances of a notification type can be generated using an action notify in a reasoner

Reasoners

See Reasoners

Actions

See Actions

Observation production configuration

The objective of this configuration is to identify the observation types a Thing produces in a specific use case (Activity) it encompasses:

• Select observation type, this observation has to be an observation that the Thing type produces.
  • Topic
  • Producer
  • targetthings

This configuration can be used by followers subscribed to the service of the activity (for instances, the Amtech M2M bridge, consumes this configuration to generate the observations it sends)

the follower must have a role with access polices to the Thing type in order to get this information

• Configuration details
  • The configuration involved thing types and the observation types they produce. The following example shows where a thing type LLRPReader produces 2 observations type observationresourcecrud and graiEPC
  • 

    Select thing and observations type
  • Configure observations' properties required to produce selected observations and enforce security including topic, targetthings, producer, guestusers, and guesttenants. (See Observations and observation types). The following example illustrates an graiEPC observation type with:
    • topic thingsInBoardroom/LLRPReader/#{smoothingResult}, placeholder #{smoothingResult} is used to group observations in child branches new or lost
    • producer reunionMexicoEDN:llrpantenna#{antennaId}, placeholder #{antennaId} is used to group identify what antenna id produced the observation
    • 

      topic, producer, guest tenant and guest user
    • targetthings resource id reunionMexicoEDN:llrpantenna#{antennaId}:#{serialNumber}, placeholders #{antennaId} and #{serialNumber} are used to antenna id and product serial number from graiEPC values to uniquely identify the target thing.
    • 

      targetthings
• Placeholders
  • Allows to set identifiers that will be substituted by real values at different intelligence layers, the following example illustrates.
  • guesttenants #{companyPrefix}, placeholder is used to set a guesttenants from graiEPC value companyPrefix allowing to control the access to observations and things from the intelligence in the edge.
  • topic thingsInBoardroom/LLRPReader/#{smoothingResult}/#{country}, placeholder is used to group observations in child branches by countries.
  • 

    placeholder
• Relation with thing types observation production configuration (See Thing types)
  • Each thing type defines which observation types produces as part of the type semantic. The following example illustrates selecting observation type graiEPC produced by LLRPReader type.
  • 

    Select observation type

API's observers

• list of observers published with the activity for integration, it can be request by followers with access policies to the resources use in the configuration of the observer.

Validation for publication

In order to be published, an activity must be a valid json resource according to its metadata. All resources contained in the activity must also be valid for their metadata. The follower specific validations are also performed on the activity (some generate warning, others generate errors that will not allow publication)

• Types involved in reasoners, observers and actors must be published
  • If there is an unpublished type that is used, and it is owned by the activity owner, a warning is generated
  • If the unpublished type is owned by another user, an error is generated
• Types used in actors are involved in reasoners or observers (if not, a warning is generated)
• Actors must not contain policies for notifications of a different activity
• Reasoners must have topic, actions, and must have been run at least one in the debugger

Publishing

Actions taken upon activity publication:

• the service for the activity is generated/updated
• the observation production configuration, API Observers and Follower Observers are shared with service subscribers
• a test user with the role follower is created.

Unpublishing

The topology of an activity can be undeployed by selecting the activity, and going to the Execution Status menu, where actions can be taken on the topology, such as watching the logs, and undeploying the topology. Note that the unpublish process has no effect on the publication of the activity, so all the resources shared, and the actors given to users subscribed to the acivity remain unchanged. The undeploy process has effect only on the topology.

Test User with role Follower

• the test follower is automatically created when the creator publishes an activity
• it is automatically subscribed to the service
• its credentials are sent by email to the creator.
• it is generated with an ID in the form of follower_<creatorId>@@<creatorEmailDomain>.
• this test follower allows the creator to test the follower experience, without having to create a new user and subscribe it to the services.

When to deploy and publish

• a new reasoner has been created
• an existing reasoner has been modified or deleted
• a new action has been created
• an extincting action have been modified or deleted
• observation production configuration has changed
• actors has been modified

deployed activities are stooped for a short period of time an restarted

When to publish only

Publishing an activity is needed when:

• a new configuration of observation production is added
• a new observer is added to the list of Follower Observers or API Observers