TagProvider record with connection to external DB

Module Development
1

AS stated in my other post, I’m developing a driver which would use and external tag store. This will be a driving Tag Provider.

I’m creating the Extension Point via a persistent record. This record has a Reference to ProvideID in SQLTagProviderRecord.

The question is, what do I need additionally in order to get connection parameters to the SQL database?

I’m looking at the javadocs for DatasourceProviderSettingsRecord. Should I use that as a template? That is, reference to a DatasourceID? And same Poll parameters?

Cheers
Ivan

2

I’ve been working on this but run into the same problem as last year.

Here’s what I’m doing:

  1. Extended SQLTagProviderType
  2. Created a settings record, right now it just holds a reference to the base SQLTagProviderRecord:

[code]public class MyTagProviderSettingsRecord extends PersistentRecord {

public static final RecordMeta<DpwsTagProviderSettingsRecord> META = new RecordMeta<MyTagProviderSettingsRecord>(
		MyTagProviderSettingsRecord.class,
		"MyTagProviderSettings");

public static final LongField ProfileId = new LongField(META, "ProfileId", SFieldFlags.SPRIMARY_KEY);
public static final ReferenceField<SQLTagProviderRecord> Profile =
	new ReferenceField<SQLTagProviderRecord>(META, SQLTagProviderRecord.META, "Profile", ProfileId);	

@Override
public RecordMeta<?> getMeta() {
	return META;
}

}[/code]

  1. in my GatewayHook, I call context.getSchemaUpdater().updatePersistentRecords(MyTagProviderSettingsRecord.META);

  2. then I call context.getTagManager().addSQLTagProviderType(myTagProviderType);

This leads to my provider type being available to add through New Realtime SQLTags Provider

But…

At this point I can set the name and description, but then it gives me a choice of existing providers to fill out the ProfileID field. I would expect that a new ID is generated and that’s how the field is filled.

Also, the names that show up for fields are like: ¿MyTagProviderSettingsRecord.Profile.Name?

How do I set names/descriptions for these? Is there a key/value file that is needed?

Thanks for the support,
Ivan

3

Some further info:

When I create a new provider, it will let me choose one of the existing providers for the ProfileID reference field.

If I choose “none”, then a new ID is generated (as verified in the internal database).

How can I hide this Field from showing in the configuration?

It would be very useful to take a look at the internals of DatasourceProviderSettingsRecord for an example.

Cheers
Ivan

4

Hi,

Sorry I haven’t been responding this week, we’ve been a bit busy on a few fronts. Honestly, I need to take a look at DBTagStore and see how reusable it is, the fact that it’s in the API package is probably a mistake at this point. Still, some sort of straight forward way to work with external tags would be good, so I’ll see what we can do.

Now, your questions here are pretty straight-forward:

  1. You need to make the Profile and ProfileId hidden in your record using a static constructor:

[code]public static final LongField ProfileId = new LongField(META, “ProfileId”, SFieldFlags.SPRIMARY_KEY);
public static final ReferenceField Profile = new ReferenceField(META,
SQLTagProviderRecord.META, “Profile”, ProfileId);

{
	ProfileId.getFormMeta().setVisible(false);
	Profile.getFormMeta().setVisible(false);
}

[/code]

  1. The description keys - PersistentRecords look for a localization file located next to themselves with the same name. In your case, create a file called “MyTagProviderSettingsRecord.properties” next to your class. Inside, define the values, such as:

Profile.Name=Name MySetting.Name=My custom setting

As I mentioned, I don’t think DBTagStore is all too “3rd party friendly”, but I suppose you should be able to get somewhere with it. Making an entire tag provider is quite a bit more work, as you have to deal with scan classes as well, but I suppose it might be worth it. Maybe if you describe a bit more about the big picture of what you want to do, and the limitations of the SimpleTagProvider that you want to get around, I can guide you a bit more. Feel free to send it as a private message if you want.

Regards,

5

Hi Colby,

Many thanks for your reply. I will implement the changes as you wrote them.

So far things are going OK with DBTagStore, I’m able to store and retrieve scan classes. Now I’m working on Tags.

The limitations I’m finding with SimpleTagProvider are:

  • Tags are lost after restart. The extensions are saved but the base tags are not. The tags are created dynamically so some times it can take a while for a tag to be re-created, and the projects that use it display errors. Would be nice to also store the value so it appears after restart.

  • I can’t handle tag modifications or deletes

  • My client would like to browse the tags through SQL, so external storage is preferred. I’m not sure if there is another way to easily browse tags for their use in projects without SQL.

  • My client would like to edit Tag configuration via SQL. For large projects they feel they can automate the process better this way.

  • My client feels storing in SQL would help integrate historical data as well.

So what I’m looking to develop is something very similar to SimpleTagProvider, but with storage of entire Tag definition in External DB and better handling of edits/deletes. Value updates will be Async as in SimpleTagProvider. ScanClasses would be used to poll for configuration changes, and perhaps value changes done externally (I don’t know if this is feasible or necessary).

Cheers
Ivan

6

Hi,

So yes, it does sound very much like external tags are what they want. So much so, though, that maybe the correct question for me to ask instead is: What is it about the current external tag provider that doesn’t work for you? Is it because you’re generating the values in your module? If so, would it make more sense for you to write your part as a device, so that it goes through the OPC-UA server (added benefit: 3rd party clients can also read it), and then just use opc tags in the external provider?

Regards,

7

Hi Colby,

I don’t have much experience writing drivers as a OPC-UA device, but after a quick review, this is my concern:

  • Implementing as a OPC-UA driver and then copying the tags to an External Driving Provider would make all the configuration and current values available externally, as required

  • Could I use this in the opposite direction, i.e. when the driver restarts can it read the stored configuration to recreate the Tag tree and load saved values?

  • Can I use this method to listen to configuration changes in the SQL database?

Cheers
Ivan

8

I forgot to answer your question:

Yes, the only thing short in the current External Driving Provider is that I generate tags and values internally as well. We also listen for value changes/write requests which are sent back to the device.

If there were a mechanism to get a handle of the provider and add tags, and then get a handle on the tag object, it would be ideal.

Cheers
Ivan