How to get value of the field defined in Configuration Table while building an extension.

[nagarwal]

I can see option only for getDefaultValue() not getValue(). I followed as:

     getConfigurationTable("TableName").getField("fieldName").getDefaultValue().

The option for getValue() was not there, hence changes in configuration is not reflectiong after importing this extension in Thingworx Platform.

[VladimirRosu]

Hi Nitin,

Could you try getConfigurationData().getValue("TableName", "PropName") ?

Best regards,

Vladi

[nagarwal · Accepted solution]

Hi Vladi,

The below command worked for me -

     getStringConfigurationSetting("TableName", "PropertyName");

Regards,

Nitin

[ttielebein]

Hello,

If this is the correct answer, then could you please mark it as correct to help other developers find the answer to this in the future?

Thanks!

Tori

[jgabriel]

Can you please provide code example?

String myProp = getStringConfigurationSetting("TableName", "PropertyName");

Is it just like this?

[jgabriel]

Actually found answer in apendix A of thingworx_extension_development_user_guide.pdf.

@ThingworxConfigurationTableDefinitions(tables = {

@ThingworxConfigurationTableDefinition(name="ConfigTableExample1", description="Example 1 config table", isMultiRow=false, dataShape = @ThingworxDataShapeDefinition( fields = { @ThingworxFieldDefinition(name="field1",description="",baseType="STRING"), @ThingworxFieldDefinition(name="field2",description="",baseType="NUMBER"), @ThingworxFieldDefinition(name="field3",description="",baseType="BOOLEAN"), @ThingworxFieldDefinition(name="field4",description="",baseType="USERNAME")})),

@ThingworxConfigurationTableDefinition(name="ConfigTableExample2", description="Example 2 config table", isMultiRow=true, dataShape = @ThingworxDataShapeDefinition( fields = { @ThingworxFieldDefinition(name="columnA",description="",baseType="STRING"), @ThingworxFieldDefinition(name="columnB",description="",baseType="NUMBER"), @ThingworxFieldDefinition(name="columnC",description="",baseType="BOOLEAN"), @ThingworxFieldDefinition(name="columnD",description="",baseType="USERNAME") })) })

String field1Value = (String)getConfigurationSetting("ConfigTableExample1", "field1");

Double field2Value = (Double)getConfigurationSetting("ConfigTableExample1", "field2");

Boolean field3Value = (Boolean)getConfigurationSetting("ConfigTableExample1", "field3");

String field4Value = (String)getConfigurationSetting("ConfigTableExample1", "field4");

[jgabriel]

It there any way to handle configuration change? For example regenerate internal values base on that config?

Maybe some event?

[VladimirRosu]

Hi Jan,

There's no such an event regarding the configuration. Considering the typical usage, you always read the configuration parameters when you start the Thing.

If you need such a functionality you can store in internal properties (maybe an infotable holding all previous parameters) the old values then compare the new values to the old ones?

[jgabriel]

I wanted to put internal logic to custom class:

MyCustomLogic cl = new MyCustomLocic(config1, config2);

Then in services:

     cl.method1();

I dont want to do:

     cl.setConfig(config1, config2);

on every service call...

Any solution to this?

[VladimirRosu]

You can use that. It's only that because there's no event for "data change" for the configuration - since it's not a property - you need to actually store each time the previous "config" to a store of your own. For this you can use the Infotable, or anything that you'd like.

Then, each time when you start the thing, the config1 will be the current config, and config2 will be something like "readPreviousConfigFromStore".

Makes sense?

[jgabriel]

So it is this then?

     cl.setConfig(config1, config2);

on every service call...

[VladimirRosu]

I would use it only at the initialization, in the constructor.

That's because each time you click the Save button on the entity the initialization will happen again.

[jgabriel]

You mean like when you save configuration, it makes new instance of the Thing and you can safely use:

this.cl = new MyCustomLocic(config1, config2);

In Thing constructor?

[VladimirRosu]

Hi Jan,

Not quite, there is no new instance of a Thing.

The idea is that the following method, initializeThing() will be executed each time the Save button will be clicked for a Thing that inherits the Template you define in Java.

Look below for an example.

protected void initializeThing() throws Exception {

  this.FTPServer = ((String) getConfigurationData().getValue(

  "ConnectionInfo", "FTPServer"));

  this.FTPPort = ((Integer) getConfigurationData().getValue(

  "ConnectionInfo", "FTPPort"));

  this.FTPUser=((String) getConfigurationData().getValue(

  "ConnectionInfo", "FTPUser"));

  this.FTPPass=((String) getConfigurationData().getValue(

  "ConnectionInfo", "FTPPass"));

  this.bool_UseSSL=((boolean) getConfigurationData().getValue(

  "ConnectionInfo", "UseSSL"));

  FTP_Utils.DestroyInstance();

  FTPUtilitiesClass=FTP_Utils.getInstance(FTPServer, FTPPort.intValue(), FTPUser, FTPPass,bool_UseSSL);

  }

[jgabriel]

Thanks for information, very helpfull. Is there any documentations on Thing Lifecycle a these Java specifics?

Thanks JG.

[VladimirRosu]

This is maintained in the Javadoc for the Thing class, so you can see it in your editor of choice.

For ease of use I'm pasting here the 7.3 information (please check your javadoc as it might differ based on version).

Each of the methods also have their own Javadoc btw, so you can see which are the objects to which you have access there.

---------------------------------------------------------------------------------------------------------------------------------------------------------------------

An entity containing services, properties, events, and subscriptions representing an instance of a thing based on a specified template. 

  Thing entities are one of the fundamental entity types in Thingworx. They are used to represent an instance of an object that is actionable (services), declarative (properties), reactive (events), and observable (subscriptions). Things must define a single  ThingTemplate to inherit shared functionality, as well as any number of  ThingShapes that add additional functionality that is independent of the  ThingTemplate hierarchy. The consolidation of all inherited functionality must not have any name collisions within the same behavioral type (i.e., a property and service can share the same name, but two services cannot). 

  All Things have the following lifecycle: 

ThingState	OFF	→	ON	→	OFF	→	N/A
Events	Inactive → Preinitializing (Entity) → Validating → Initializing (Entity) → Initializing (Thing) → Starting	→	Notifying → Active → Stopping	→	Cleaning Up → Deactivated	→	Disposing

  These lifecycle events correspond to the following methods: 

State	Method	Description
Preinitialize (Entity) 1	RootEntity#preInitializeEntity()	Occurs only during the entity import process.
Validate1	Thing#validateConfiguration(ImportedEntityCollection)	Occurs only during the entity import process. Validates all requirements of the entity.
Initialize (Entity)	Thing#initializeEntity()	Initializes the entity. Should be used to initialize anything needed by thing initialization.
Initialize (Thing)	Thing#initializeThing()	Initializes the thing. Should be used to construct the initial state of the thing.
Start	Thing#startThing()	Brings the thing into an active state. Initialization should finish at this step.
Notify	Thing#processStartNotification()	Thing has entered active state and is about to run. Any final processing must occur here.
Stop	Thing#stopThing()	Thing has received a stop request. Any back-end processing should be torn down.
Cleanup	Thing#cleanupThing()	Thing has stopped and needs to clean up its resources. Any managed resources should be cleaned up.
Dispose	Thing#dispose()	Removes any remaining references of this entity (e.g., networks).

Note 1: The preinitialization and validation states only execute when a Thing is imported. They are skipped when the entity is created from the persistence store. 

  When developing extensions, you must extend from the Thing class for any classes that are assigned to a com.thingworx.thingpackages.ThingPackage entity. If the package is assigned to a thing in the extension, then the code will execute in the context of that entity. If the package is assigned to a thing template, then the code will execute in the context of the things that have been created with the thing template in its hierarchy. 

Thing is not thread-safe nor is it designed to be mutated by multiple threads simultaneously.