Scheduler Thing Parameters

[thomas-thomas-tfs]

How to specify schedule frequency and user on which scheduler to run on.

[BogdanMihaiciuc]

This is specified via configuration table values. I'll try to get a temporary solution in early next week to be able to specify this kind of information and look into refining it in the future.

[carlo-quinonez]

Please let us know if there's anything we can do to help.

[BogdanMihaiciuc]

There is now a new @config decorator that you can use by pulling the latest static/base/Decorators.d.ts file and updating to the latest transformer version. It is not properly type checked yet so make sure not to make any mistakes as that could lead to errors when importing.

Specifically for timers, it looks like this:

@config({
    Settings: {enabled: true, runAsUser: 'Administrator', updateRate: 60000}
})
@ThingDefinition class MyTimer extends Timer {

}

[carlo-quinonez]

Hi @BogdanMihaiciuc - So I finally gave this a shot, but I'm getting an error

Configuration properties must be array or object literals.

Failed parsing at: 
Settings: {
    enabled: true,
    runAsUser: 'Administrator',
    schedule: '0 0 0/1 * * ?',  // Run hourly
  } as {
    enabled: Boolean;
    runAsUser: String;
    schedule: SCHEDULE;
  }

If I remove the types, then it builds, but the entity won't load into thingworx. Without specifying a type, the generated XML looks like this:

<ConfigurationTables>
  <ConfigurationTable name="Settings" description="" isMultiRow="false">
    <DataShape>
      <FieldDefinitions>
        <FieldDefinition baseType="BOOLEAN" description="" name="enabled"/>
        <FieldDefinition baseType="STRING" description="" name="runAsUser"/>
        <FieldDefinition baseType="STRING" description="" name="schedule"/>
      </FieldDefinitions>
    </DataShape>
    <Rows>
      <Row>
        <enabled>true</enabled>
        <runAsUser>Administrator</runAsUser>
        <schedule>0 0 0/1 * * ?</schedule>
      </Row>
    </Rows>
  </ConfigurationTable>
</ConfigurationTables>

but when I export a scheduler from ThingWorx, I see the configuration is supposed to look like this:

<ConfigurationTables>
    <ConfigurationTable
        dataShapeName=""
        description="General Settings"
        isHidden="true"
        isMultiRow="false"
        name="Settings"
        ordinal="0">
        <DataShape>
            <FieldDefinitions>
                <FieldDefinition
                    aspect.defaultValue="true"
                    baseType="BOOLEAN"
                    description="Automatically enable scheduler on startup"
                    name="enabled"
                    ordinal="0"></FieldDefinition>
                <FieldDefinition
                    baseType="USERNAME"
                    description="User context in which to run event handlers"
                    name="runAsUser"
                    ordinal="0"></FieldDefinition>
                <FieldDefinition
                    aspect.defaultValue="0 0/1 * * * ?"
                    baseType="SCHEDULE"
                    description="Execution Schedule (Cron String)"
                    name="schedule"
                    ordinal="0"></FieldDefinition>
            </FieldDefinitions>
        </DataShape>
        <Rows>
            <Row>
                <enabled>true</enabled>
                <runAsUser></runAsUser>
                <schedule>
                <![CDATA[
                0 0/1 * * * ?
                ]]>
                </schedule>
            </Row>
        </Rows>
    </ConfigurationTable>
</ConfigurationTables>

I'm pretty sure the problem is the bad type on the schedule property (STRING vs SCHEDULE) and/or the CDATA encoding of the actual value.

[BogdanMihaiciuc]

Hey, there's no typecasting required as Thingworx handles the conversion from primitive types such as STRING to more specialised types like USERNAME or SCHEDULE on its own. Currently, the correct typing information (and therefore type checking) doesn't exist for configuration values.

If you are getting an error while importing it is most likely related to something else; you should be able to see what causes the failure in the Thingworx application logs.

A common issue when gulp reports a successful upload but you don't see the changes is if you roll back the version number in package.json - you will see a message in the application log after running the upload command similar to this one:

Extension bm-thingworx-vscode:1.7.6 skipped because it is already installed.

Also note that, when working with extensions, configuration table values don't get updated when updating the extension. This is because even if the extension entities aren't marked editable, users can go in and modify property and configuration table values. This way, any custom configuration gets retained when performing updates.

So, if you already had that scheduler without the config decorator in a previous version of your extension, the new version won't modify its previous configuration.

A workaround, and maybe a good practice in general, is to have a service that administrators need to invoke after installation/update that handles tasks that importing alone won't, such as updating configuration table values, setting up collection permissions, adding or removing session shapes and so on. With this, you could mark such a service with the @deploy decorator and use the deploy task to have gulp invoke that service for you after the import.

[carlo-quinonez]

Thank you for the additional information, I'll go back and double-check where it was failing.