New Asset Types

Occasionally when working with Orchestrator assets, my team will use a text asset to hold information that may be better represented as other types. Below are our two most common use cases with suggestions on implementation. In both cases, these can be treated the same way as global or per-bot text values in the database.

Typically this will be something like a list of email addresses, and thus a semi-colon delimited string. However, editing these values can be a bit ungainly, and often require being pulled out into a text editor to add or remove addresses.

The list type should present a UI similar to the existing list controls in Orchestrator (e.g. when listing configuring per-bot values). The ability to add a new free text entry, modify an existing entry, and delete an entry should be added. Additionally, the ability to select the list format should be added with entries including comma-separated values, pipe-separated values, semicolon-separated values, a custom separator character, and no separator character.

For per-bot list configurations, display the configuration in a condensed form (e.g. as comma-separated values). When the edit button is clicked, display a modal or a new screen with that same list box entry.

Json Text
Reuses the existing text type but allows for a JsonSchema document to be uploaded (shared across per-bot configurations) and informs the robot of the incoming text/json format. This can be allowed a per-bot value as well, so long as all values comply with the JsonSchema document. It will likely be the job of the consumer to verify compliance. Though an indicator within Orchestrator itself would be a nice to have, the goal with this is to reuse the existing schema functionality within Orchestrator (specifically, that which is found in the Queue system).

For database storage, both can be stored in the same way as existing global or per-bot text entries. The extra data in this case, such as the separator character or JsonSchema document, can be represented as part of the json. For instance, in the case of a comma-separated list, json like this can be used:

    "Separator": ","
    "SpecificData": [ "a", "b", "c" ]

This has a tangential benefit of being able to change the separator value, such as from a comma to a semicolon, without affecting the actual data. If no separator value is selected, the field should be omitted. If this data type is being retrieved, a new ListAsset type should be the value returned from the Get Asset activity.

public interface IListAsset
    string? Separator { get; }
    string[] SpecificData { get; }

This data type will allow for direct access to the data contained within the list so that it may be manipulated as best determined by the consumer. In most cases, this may be in an Assign activity which emulates the following code:

string emailRecipients = string.Join(asset.Separator, asset.SpecificData);

The json asset should return a very similar item from the Get Asset activity.

public interface IJsonAsset
    string? Schema { get; }
    string SpecificData { get; }

This enables the user to grab the raw json value via the SpecificData property where they may parse it themselves using Newtonsoft/S.T.J into the appropriate type. The parsing functionality could be built-in to the Get Asset activity, however I feel this is both out of scope for the activity as well as potentially limiting the consumer. Simply returning the raw json, whether or not this includes a schema document allows for a very similar use case for if the user had simply read the json from disk.

In the database, the json stored in the text asset would likely look something like this:

    "Schema": 4,
    "SpecificData": "{ \"Foo\": \"Bar\" }"

The 4 in this case points to the id of the stored schema document, likely stored in the same table as Queue schema assets. Both of these values would be retrieved and then the data of the json asset would be un-escaped to prevent issues with parsing on the consumer side. It should emulate as closely as possible the value the user would get if they had read the text from a json document on disk.

1 Like