Activities

An activity from a user perspective refers to any tool that can be dragged onto a Warewolf Studio design surface. Activities are composed into Warewolf services and are the basic building blocks for Warewolf services.
There are two overall categories of Activity, Grid Activities and Non-grid Activity. Grid Activities can accept any number of user inputs via a data grid on the design surface while Non-grid Activities have a fixed number of user inputs.
Activities are developed using the design pattern and SOA principles. Each activity is made up of three distinct layers:

  • View,
  • View Model, and
  • Server Logic

Warewolf activity view model

View

The XAML that defines the activity look and feel. Views can be found in the Dev2.Activities.Designer project. Activities can have both a large detailed view as well as a small condensed view.

ViewModel

Encapsulates design surface logic, like validation of inputs and enabling and disabling an item on the designer. Activity view models are located in the Dev2.Activities.Designer project. Non Grid Activities inherit the ActivityDesignerViewModel class while Grid Activities inherit the ActivityCollectionDesignerViewModel  class.

Server Logic

Each Warewolf activity has a corresponding server side execution class. The server execution classes can be found in the the Dev2.Activities project. Server activities inherit from the DsfNativeActivity base class which abstracts away the common execution parts. The following abstract and virtual methods should be overridden when creating new activities

  • OnExecute – The execution logic of an activity is encapsulated here. In general the OnExecute method does the following
    • Retrieves inputs from the Datalist
    • Performs activity logic
    • Handles known errors
    • Coordinates debug input and output.
    • Store results in the Datalist
  • GetDebugOutputs – Used by the server to retrieve debug outputs
  • GetDebugInputs – Used by the server to retrieve debug inputs

Nested Services and microservices

Warewolf encourages reusability by allowing services and microservices to be nested. A service can be dragged and dropped onto the design surface and will execute like any other activity.
Nested services derive from the DSFActivity class and encompass plugins, web services, database services and workflow services. During execution, nested services are run in isolated execution containers that handle the scope and data transfer.

 

 

Not what you were looking for? Ask our expert users in the Community Forum.

FacebookTwitterLinkedInGoogle+Email

Rate This Article

(58 out of 151 people found this article helpful)