Difference between revisions of "Actions"
From AMTech WikiDocs
(→Send command) |
(→Create thing) |
||
| (28 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
| − | == Create thing == | + | Actions are added to reasoners, in order to be executed. All reasoners must have al least one action to be valid for publication in an activity |
| + | == Create action workflow == | ||
| + | ===Select action from actions menu=== | ||
| + | [[File:Reasoner-action-editor.png|1150px|center|thumbnail|Actions editor]] | ||
| + | |||
| + | ===Set action's general properties=== | ||
| + | [[File:Action-generalproperties.png|center|thumbnail|Action general properties]] | ||
| + | ====Recipients==== | ||
| + | ====Media==== | ||
| + | ====Continue on failured==== | ||
| + | === [[Binding|Bind]] action's properties=== | ||
| + | |||
| + | == Types of actions == | ||
| + | ==== Create thing ==== | ||
* This action is configured to create a new thing. | * This action is configured to create a new thing. | ||
| − | * The name property will be used to generate a | + | * The name property will be used to generate a unique ID for this thing. |
* Things aren't immediately created. The creation action is queued as a promise. See [[CRUD promises]]. | * Things aren't immediately created. The creation action is queued as a promise. See [[CRUD promises]]. | ||
| + | * Security is copied from the observation (guest tenants and guest users) even when the things updated (create with update if exist) | ||
| + | Note: updating a thing via an action-update will set guests according to the guest bindings defined by the creator. When updating a thing via an action-create with updateIfExist, guests will be copied from the observation | ||
| − | == Update thing == | + | === Update thing === |
* This is only available in a for-each reasoner. | * This is only available in a for-each reasoner. | ||
| Line 11: | Line 26: | ||
* Things aren't immediately updated. The update action is queued as a promise. See [[CRUD promises]]. | * Things aren't immediately updated. The update action is queued as a promise. See [[CRUD promises]]. | ||
* In the configuration context (and also at execution time) the object referencing "the thing" doesn't change after the action update. It means that any further action using "the current thing" object will work with the same object that the observer retrieved from the DAP. | * In the configuration context (and also at execution time) the object referencing "the thing" doesn't change after the action update. It means that any further action using "the current thing" object will work with the same object that the observer retrieved from the DAP. | ||
| + | * Security properties can be set using the guest tenant and guest users bindings in the action | ||
| − | == Delete thing == | + | === Delete thing === |
* This action is only available in a for-each reasoner. | * This action is only available in a for-each reasoner. | ||
* This action is configured to delete the thing that is currently being visited by the for-each reasoner. | * This action is configured to delete the thing that is currently being visited by the for-each reasoner. | ||
| − | * The thing is not immediately | + | * The thing is not immediately deleted. The deletion action is queued as a promise instead. See [[CRUD promises]]. |
| − | == Send observation == | + | === Send observation === |
* This action can be configured to send an observation to the [[Sensor's network]]. | * This action can be configured to send an observation to the [[Sensor's network]]. | ||
* Most mandatory data must be configured in this action. See [[Sensor's network#Observations and observation types|Observations and observation types]] in the [[Sensor's network]] page. | * Most mandatory data must be configured in this action. See [[Sensor's network#Observations and observation types|Observations and observation types]] in the [[Sensor's network]] page. | ||
| − | == Send command == | + | === Send command === |
* This action can be configured to send a command. | * This action can be configured to send a command. | ||
| − | * Command objects | + | * Command objects have no differences with observation objects. In fact, you will be asked to provide an observation type as if you were sending a regular observation. |
| − | + | * At configuration time you must supply a thing type (the thing type that will receive the command) and an observation type to be send as command. | |
| + | [[File:Command-1.png|850px|thumbnail|center|Thing and observation type]] | ||
| + | * You can bind a thing id (target uri) of the thing type previously specified in order to be more specific about the thing instance that will receive the command. | ||
| + | [[File:Command-2.png|1150px|thumbnail|center|thing id]] | ||
| − | == Send notification == | + | === Send notification === |
* This action can be configured to send a notification. [[Notifications]] are configured as global objects under the activity's scope. | * This action can be configured to send a notification. [[Notifications]] are configured as global objects under the activity's scope. | ||
| − | * | + | * Once the notification action is created you can configure: |
| − | * | + | ** Media: is a comma separated list of the following values: |
| + | *** dap: notify based on the security for the execution of this action through the SaaS experience. If the security is taken from the observation that triggered this reasoner then the notification will be sent to the same tenant that owns the observation. On the other hand, if the security is taken from the iterated thing (in a foreach reasoner) then the observation will be sent to the same tenant that owns the thing being iterated when this notification was originated. | ||
| + | *** mail: notify by mail. The list of email addresses that will receive the notification is specified in the Recipients property. In the case of foreach reasoners, the email address list specified in the emaillist property of the thing being iterated is also used to enrich the list of recipients. | ||
| + | *** text: not in use yet. | ||
| + | ** Recipients: accept a list of email addresses that will be notified by email. | ||
| + | * You will need to provide string bindings for all the configured placeholders in the notification object. | ||
| − | + | === Send scheduled observation === | |
| − | == Send scheduled observation == | + | |
* Very similar to send observations action. | * Very similar to send observations action. | ||
| Line 44: | Line 67: | ||
** Occurrence: a number of repetitions: 0 for unlimmited repetitions | ** Occurrence: a number of repetitions: 0 for unlimmited repetitions | ||
** A frequency of repetitions specified as a combination of years, months, days, hours, minutes, seconds. For instance, 3 days, 4 hours, 30 minutes will specify that the observation will be sent each time a period of 3 days 4 hours and 30 minutes is elapsed. | ** A frequency of repetitions specified as a combination of years, months, days, hours, minutes, seconds. For instance, 3 days, 4 hours, 30 minutes will specify that the observation will be sent each time a period of 3 days 4 hours and 30 minutes is elapsed. | ||
| + | |||
| + | |||
| + | |||
| + | == Action security context == | ||
| + | The security info for executing actions is taken from the observation that triggered the reasoner. | ||
| + | * all actions are executed with the user and tenant of the observation | ||
| + | * for actions that create resources, the guest tenants, guest users and guest services of the observation are copied to the new resource | ||
Latest revision as of 10:09, 22 March 2021
Actions are added to reasoners, in order to be executed. All reasoners must have al least one action to be valid for publication in an activity
Create action workflow
Set action's general properties
Recipients
Media
Continue on failured
Bind action's properties
Types of actions
Create thing
- This action is configured to create a new thing.
- The name property will be used to generate a unique ID for this thing.
- Things aren't immediately created. The creation action is queued as a promise. See CRUD promises.
- Security is copied from the observation (guest tenants and guest users) even when the things updated (create with update if exist)
Note: updating a thing via an action-update will set guests according to the guest bindings defined by the creator. When updating a thing via an action-create with updateIfExist, guests will be copied from the observation
Update thing
- This is only available in a for-each reasoner.
- This action is configured to update an existing thing: the thing that is currently being visited by the for-each reasoner.
- Things aren't immediately updated. The update action is queued as a promise. See CRUD promises.
- In the configuration context (and also at execution time) the object referencing "the thing" doesn't change after the action update. It means that any further action using "the current thing" object will work with the same object that the observer retrieved from the DAP.
- Security properties can be set using the guest tenant and guest users bindings in the action
Delete thing
- This action is only available in a for-each reasoner.
- This action is configured to delete the thing that is currently being visited by the for-each reasoner.
- The thing is not immediately deleted. The deletion action is queued as a promise instead. See CRUD promises.
Send observation
- This action can be configured to send an observation to the Sensor's network.
- Most mandatory data must be configured in this action. See Observations and observation types in the Sensor's network page.
Send command
- This action can be configured to send a command.
- Command objects have no differences with observation objects. In fact, you will be asked to provide an observation type as if you were sending a regular observation.
- At configuration time you must supply a thing type (the thing type that will receive the command) and an observation type to be send as command.
- You can bind a thing id (target uri) of the thing type previously specified in order to be more specific about the thing instance that will receive the command.
Send notification
- This action can be configured to send a notification. Notifications are configured as global objects under the activity's scope.
- Once the notification action is created you can configure:
- Media: is a comma separated list of the following values:
- dap: notify based on the security for the execution of this action through the SaaS experience. If the security is taken from the observation that triggered this reasoner then the notification will be sent to the same tenant that owns the observation. On the other hand, if the security is taken from the iterated thing (in a foreach reasoner) then the observation will be sent to the same tenant that owns the thing being iterated when this notification was originated.
- mail: notify by mail. The list of email addresses that will receive the notification is specified in the Recipients property. In the case of foreach reasoners, the email address list specified in the emaillist property of the thing being iterated is also used to enrich the list of recipients.
- text: not in use yet.
- Recipients: accept a list of email addresses that will be notified by email.
- Media: is a comma separated list of the following values:
- You will need to provide string bindings for all the configured placeholders in the notification object.
Send scheduled observation
- Very similar to send observations action.
- You will be required to specify the following:
- An identifier for this scheduled observation.
- Start date: a starting point in the future where the send observation action will actually be executed.
- Occurrence: a number of repetitions: 0 for unlimmited repetitions
- A frequency of repetitions specified as a combination of years, months, days, hours, minutes, seconds. For instance, 3 days, 4 hours, 30 minutes will specify that the observation will be sent each time a period of 3 days 4 hours and 30 minutes is elapsed.
Action security context
The security info for executing actions is taken from the observation that triggered the reasoner.
- all actions are executed with the user and tenant of the observation
- for actions that create resources, the guest tenants, guest users and guest services of the observation are copied to the new resource
