cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - You can change your system assigned username to something more personal in your community settings. X

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

nagarwal
1-Newbie

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

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.

1 ACCEPTED SOLUTION

Accepted Solutions

Hi Vladi,

The below command worked for me -

     getStringConfigurationSetting("TableName", "PropertyName");

Regards,

Nitin

View solution in original post

15 REPLIES 15

Hi Nitin,

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

Best regards,

Vladi

Hi Vladi,

The below command worked for me -

     getStringConfigurationSetting("TableName", "PropertyName");

Regards,

Nitin

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
12-Amethyst
(To:nagarwal)

Can you please provide code example?

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

Is it just like this?

jgabriel
12-Amethyst
(To: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
12-Amethyst
(To:nagarwal)

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

Maybe some event?

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?

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?

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?

So it is this then?

     cl.setConfig(config1, config2);

on every service call...

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.

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?

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);

  }

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

Thanks JG.

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: 

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

  These lifecycle events correspond to the following methods: 

StateMethodDescription
Preinitialize (Entity) 1RootEntity#preInitializeEntity()Occurs only during the entity import process.
Validate1Thing#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.
StartThing#startThing()Brings the thing into an active state. Initialization should finish at this step.
NotifyThing#processStartNotification()Thing has entered active state and is about to run. Any final processing must occur here.
StopThing#stopThing()Thing has received a stop request. Any back-end processing should be torn down.
CleanupThing#cleanupThing()Thing has stopped and needs to clean up its resources. Any managed resources should be cleaned up.
DisposeThing#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.

Top Tags