How to create an activity
If the default activities are insufficient for your specific use case it might be necessary to create a custom activity. This guide will cover everything necessary to create custom activities for Orchestrator, from developing and testing until deploying the activities.
Development
Activities are implemented as C# classes.
All custom activities have to be derived from a common base class called ExecutionActivity which is available in the Bosch.Nexeed.Orchestrator.Contract NuGet package.
A simple activity adding two numbers could look like this:
[Activity("My Sum Activity", "A custom activity that adds to integers")]
public class CustomActivity : ExecutionActicity
{
[InArgument("a_summand1", "The first in argument")]
public int Summand1 { get; set; }
[InArgument("a_summand2", "The second in argument")]
public int Summand2 { get; set; }
[OutArgument("a_sum", "The out argument")]
public int Sum { get; set; }
public override void Execute(IRuntimeContext context)
{
Sum = Summand1 + Summand2;
}
}This code can be broken down into the following basic concepts: - Properties - Execute Method - Attributes / Decoraters
Properties
Each argument that your activity should expose needs to be implemented as property with a public getter and setter. Arguments can have any type (primitive or complex) and don’t need to be initialized.
Execute method
Each activity derived from ExecutionActivity needs to implement the Execute method.
This method does not have a response type and is passed the current IRuntimeContext through which it can access certain features from the workflow engine.
All logic that your activity should implement needs to happen within this method.
Attributes / Decorators
In order for Orchestrator to understand your activity, the class and the arguments need to be decorated with attributes. Through these attributes you can provide additional metadata further describing your activity and its arguments.
The attribute to describe an activity has the following parameters:
| Name | Type | Mandatory | Description |
|---|---|---|---|
Name |
String |
x |
The display name of the activity to be used by a editor. |
Description |
String |
x |
The description of what the activity is intended to do. |
Version |
Version |
x |
The version of the activity. |
GroupId |
String |
A unique identifier to group multiple activities. |
|
GroupName |
String |
A name for a group of activitites. |
In C# code the activity attribute would look like this:
[Activity("My Sum Activity", "A custom activity that adds to integers", "1.0.0", GroupId = "b94d3f29-74a4-4310-b419-0c6ff7aec9f6", GroupName = "Math")]For arguments there are two different attributes (InArgument and OutArgument) that share the same properties but are used to differentiate between ingoing and outgoing attributes.
| Name | Type | Mandatory | Description |
|---|---|---|---|
Name |
String |
x |
The display name of the argument to be used by a editor. |
Description |
String |
x |
The description of what the argument is intended for. |
Mandatory |
Boolean |
Determines if the argument is mandatory or not (default: false). |
Testing
Unit tests
The first level of testing for your custom activity should be unit tests, mocking the IRuntimeContext interface.
You can either use a custom implementation of the interface, a mock using any available mocking library or the MockRuntimeContext provided by the Bosch.Nexeed.Orchestrator.Testing package (Coming soon…).
Integration tests
Coming soon…
End-to-end tests
Coming soon…