Update tag configuration allowed property choices

@PGriffith recently mentioned the TagActor subsystem that plays a key role in most tag value updates:

Which sent me off down the rabbit hole, as I realized it would be a better hook than registering a historian sink for one of my current product development efforts. (A wide table history mechanism, FWIW.)

My gateway hook has this snippet in .setup():

        actorFactory = new TypeHistoryActorFactory();
        context.getTagManager().getConfigManager().registerActorFactory(actorFactory);

and that factory supplies some new tag properties like so:

    @Override
    public void configureTagModel(MutableConfigurationPropertyModel model) {
        TypeHistoryTagProps.registerForTags(model);
    }

    @Override
    public void configureTagGroupModel(MutableConfigurationPropertyModel model) {
        TypeHistoryTagProps.registerForGroups(model);
    }

Those delegate here:

    public static void registerForTags(MutableConfigurationPropertyModel model) {
        model.addProperties(TypeHistEnabled);
        model.addDependantProperties(TypeHistEnabled, Boolean.TRUE, TypeHistProvider, TypeHistTable, TypeHistColumn, TypeHistPeriod, TypeHistDriver);
        model.setAllowedValues(TypeHistProvider, typeHistProviderNames);
        model.setAllowCustomValue(TypeHistProvider, true);
    }

    public static void registerForGroups(MutableConfigurationPropertyModel model) {
        model.addProperties(TypeHistProvider, TypeHistTable, TypeHistPeriod);
        model.setAllowedValues(TypeHistProvider, typeHistProviderNames);
        model.setAllowCustomValue(TypeHistProvider, true);
    }

What I don't see is a way to cause these to be called again when typeHistProviderNames is changed, so the Designer will see the update.

Has anyone done this? (I'm aiming for the same behavior seen for Storage Provider when adding/removing native historian instances.

2 Likes

Hmmm. Closing and re-opening the tag editor made the list update.

I guess that's good enough for the moment. :man_shrugging:

1 Like

I suppose, since I'm teasing the future availability of this, I can show the tag property descriptions that go with the above properties:

typeHistEnabled: Type History Enabled

Whether to store history in wide tables, via the Type Historian from the Time Series DB Cache module.

typeHistProvider: Type History Provider

Wide Type Historian Provider Name. A default can be specified in the tag's group.

typeHistTable: Type History Table

Database Table name in the Wide Type Historian Provider's configured datasource, unquoted, case-sensitive. For tags in the root of a UDT, defaults to the last element of the UDT type name. Required otherwise.

typeHistColumn: Type History Column

Database Column name in the target table of the Wide Type Historian Provider's configured datasource, unquoted, case-sensitive. Defaults to last element of a UDT member name or atomic tag name.

typeHistPeriod: Type History Period

Type Historian recording interval, milliseconds. Default from the tag group if present, otherwise 5000ms is used. The effective period will be the minimum period per tag folder per target table. A default can be specified in the tag's group.

typeHistDriver: Type History Driver

Tag Path of Boolean driver for this tag's moment-to-moment recording. Null will be inserted in the target table when this is a valid path, and the subject boolean is false. When all tags in a folder for a table are null, only the first all-null row will be inserted. Can be a relative path. A default can be specified in the tag's group.

I was bogged down in the native historian's HistorySink maze prior to Paul's mention of tag actors the other day. Much simpler to capture the values I need with an actor.

2 Likes

I'm not sure (after a few minutes of looking) where this happens.
The native history factory does basically what you're doing:

    @Override
    public void configureTagModel(MutableConfigurationPropertyModel model) {
        TagHistoryProps.register(model);
        model.setAllowedValues(
            TagHistoryProps.HistoryProvider,
            context.getHistoryManager().getStores(HistoryFlavor.SQLTAG)
        );
    }

I assume you're returning all your relevant properties in getMonitoredProperties?

It's possible, though I'd like to think we wouldn't have done this, that this is all "faked" in the tag editor specifically for history providers, but I don't see evidence of that so far.

1 Like