In the last post , I showed how to create a configuration for an activity that shows up in the options menu. I also showed how you can use that configuration setting to modify the actions of the activity at runtime. In this post, I’ll show you how to modify design-time actions by using the imperative method of creating activities. For a refresher on how to create a basic activity using the imperative model, see this article on MSDN: Taking an Imperative Approach . Using the imperative model allows you to have some flexibility in defining the inputs and outputs of an activity programmatically, rather than having to define them all statically ahead of time. This is really beneficial when you’re dealing with variable data and you don’t want to try to fit everything to one specific template. In a future post, I’ll show some specifics about dynamically filling in output properties for published data based on the actual properties of an object being used. For now, let’s build on the Hello World example.
Starting with the “Hello World (Imperative)” activity demonstrated in the MSDN article, and re-using the HelloWorldConfiguration class from the previous post, I’m going to alter the design-time properties of the activity based on the configuration setting chosen. This is done by modifying the Design method. The example below shows that I am modifying the property name to be displayed based on the user configuration selection. Keep in mind that I could just as easily display different sets of properties (like parametersets in PowerShell), or display different default values for properties.
{
if (_settings.AlterationType == AlterationMethod.Reverse)
{
designer.AddInput("String to be reversed");
}
else if (_settings.AlterationType == AlterationMethod.Scramble)
{
designer.AddInput("String to be scrambled");
}
else if (_settings.AlterationType == AlterationMethod.None)
{
designer.AddInput("String to be left alone");
}
designer.AddOutput("Original input string");
designer.AddOutput("Modified string");
}
In addition, I add two output properties that are independent of the user selection. you should always be mindful of dynamically setting output properties, because this affects the published data properties available to other activities in the runbook. If a user configures activities later in the runbook to specific properties and then the activity changes the output properties so that the selected one is no longer there, you’ll cause problems. It’s best to have a static list of output properties unless you have a good reason to generate them dynamically. In the example above, I used “Modified string” to represent all types of modified strings so that this property is available regardless of what configuration the user selects.
At runtime, the Execute method is called. Just like the previous post, we modify the output based on the user selection. The formatting is a little different with the imperative model:
public void Execute(IActivityRequest request,
IActivityResponse response)
{
string hwinput = string.Empty;
string output = string.Empty;
if (_settings.AlterationType == AlterationMethod.Reverse)
{
hwinput = request.Inputs["String to be reversed"].AsString();
char[] arr = hwinput.ToCharArray();
Array.Reverse(arr);
output = new string(arr);
}
else if (_settings.AlterationType == AlterationMethod.Scramble)
{
hwinput = request.Inputs["String to be scrambled"].AsString();
output = ScrambleString(hwinput);
}
else if (_settings.AlterationType == AlterationMethod.None)
{
hwinput = request.Inputs["String to be left alone"].AsString();
output = hwinput;
}
response.Publish("Original input string", hwinput);
response.Publish("Modified string", output);
}
The rest of the activity is basically the same as the previous post. Now when I compile the code and use the class in the Invoke .NET activity, I can see the input property text changes depending on the configuration option I choose:
That’s pretty cool and not hard at all to do. I’ll keep building on these examples in future posts!