Package parameters

This page explains how to add package parameters to your package, how to make the most of them and what are their strengths and limits.

Data anonymization is not an immutable process and often calls for adjustments and modifications. Most of these become known during the creation of the anonymization specification and package and can be controlled using package parameters on the BizDataX Portal.

Package parameters

To add a package parameter, open the Package.xaml file to open the package workflow, and click on the Arguments button. To add a new parameter, click on the Create Argument default argument name. You can change some parameter properties directly from this grid, while others become accessible in the Properties tab by selecting the desired parameter. You can change the following values:

• Name - name of the parameter.
• Direction - default is In. It can be changed to Out. Only these two directions are supported.
• ArgumentType - type of the parameter.
• Default value - value of the parameter if no other value is entered.
• IsRequired - boolean, true if a value is required, only accessible from the Properties tab.

While other values for Direction are possible, a valid package only supports In directional parameters. The supported parameter types are String, Int32, Boolean, Double and Decimal. Other types will result in the package not being valid which will prevent package publishing.

It is advisable to enter parameter names which will help you distinguish parameters on the BizDataX Portal to help with package executions.

Figure 1: An example of package with parameters

The example in figure 1 has two parameters: MaskCustomers and MaskAccounts. Both are Boolean and true by default, and are used to control whether a step will be executed or not by using parameter values instead of static values in the IsActive property of each step. The values of these parameters can be changed when starting a new package execution on the Portal, thus giving the user more control over package execution (in this case we control which tables we want to anonymize).

Parameter metadata

To further describe package parameters and provide a way to extend parameter handling logic, you can extend your parameter in the Package.Metadata.cs file, which also contains an example of how to extend a parameter. Should we want to extend the parameters in figure 1 with descriptions, the following must be added to Package.Metadata.cs:

public class Metadata
{
    [Description("If true, Customers table is masked")]
    public InArgument<bool> MaskCustomers { get; set; }

    [Description("If true, Accounts table is masked")]
    public InArgument<bool> MaskAccounts { get; set; }
}

The name, direction and argument type of the parameter must match the one from Package.xaml, but other values can be changed using the following attributes as annotations:

• DisplayName - parameter name on the Portal, accepts string as an argument
• Description - description of the parameter, accepts string as an argument
• Required - if used, then the parameter is required
• ConnectionString - used to mark the parameter as a connection string