Dynamically reloading a Global proerty in xMII

[Former Member]

I would like to reload a Global property dynamically reading from a config file whenever needed. To achieve this, I created a transaction 'ConfigLoader.trx'. this transaction was checking if this global property is already loaded and if not loaded, read the contents from the config file and assign it to this global property. After assigning this new value to the Global property, I am logging this global proerty. when I run the transaction, I see the new value in the log after the assignment.

But it looks like the new Global property value is available only inside the current transaction. Other transaction (or when you rerun the same transaction second time) dont see this newly assigned value.

Is it a bug in the xMII?

Thanks,

Sara

[Former Member]

Hi Saramani,

This you can not call as bug at all !!! You are saying that you are storing the value in the global property variable dynamically. Let me explain this practically.. Whenever you create the global variable in the transaction, after saving it will store inside of the global properties file location in the server. If you assign this value it will not store that one in the file. It will also store in the cache only. Whatever there in the Global property tab you saved at first it will only be there even after execution of the transaction.

For your problem i think you need to change the global property file in the server, but it is not at all feasible. I think it is better to redesign your solution.

Thanks,

Rajesh.

[Former Member]

Hi Rajesh,

Yes, now I undersnad that it may not be a bug in xMII, but may be a missing feature

What is the best way to handle this in xMII? My requirement is:

1. I have a configuration file.

2. I need to read this config file and cache it somewhere so that it could be accessed and used by multiple transaction. The main idea to do this is not to reload the configuration multiple times.

Is there anything in xMII, which we can use for storing the cached data?

Thanks,

Sara

[Former Member]

Can you give me some more detail on what your process is. Are you calling multiple BLS transactions?

Is one BLS calling another and another...etc?

What <i>EXACTLY</i> is going on?

[Former Member]

Alin,

I could be anything. My requirement is to a load configuration data (reading a configuration file) into somewhere (and cache it). The idea is not to re-read the configuration file and use the cached value when somebody wants it.

Thanks,

Sara

[Former Member]

I'm going to play the devil's advocate here and just ask what is the difference between loading a file and just going into a transaction and changing the globals?

Your approach with the config file does not seem to be something feasible. Considering that you can map parameteres for a transaction that can be declared when you call a transaction, this config file doesn't really make sense.

If you really want to use a config file then have a transactoin which loads it. From any other transaction you would then just execute a transaction call to your config file load trasaction which would then pass the necessary values it extracts from the file.

I just don't see what the reasoning is behind using a config file when you can pass params to a transaction anytime you call it...

[Former Member]

Let's change Sara's problem around a bit. Let's say there are some database records that several business processes use. I'm defining "business process" to mean an event-driven sequence of BLS transactions which do some work then end. Let's assume performance is an issue and database access is considerably slower than accessing an xMII global property. How would you solve this problem?

Wouldn't you want to load the data from the database once and make it available to all the business processes which need it? Including business processes which haven't been executed yet? You also want to be able to change the database records and force an update of the cached data. You could do this by writing a small xMII applet-thingy that let you read/update the values then press a button to force an update to the cache. But how can you build a cache in xMII?

Is everyone's database (or in Sara's case, filesystem) so fast that caches are irrelevent in xMII?

-tim

[Former Member]

Tim,

The simplest way would be to have a LOCAL instance of the cache as either a database located on the same machine as xMII or as a simple XML file again located on the same machine as xMII.

You could eithe setup a scheduled run to repopulate that cache every so often or manage it using a date-time stamp where xMII would verify the datetime value and if it's older then it requeries the data and refreshes the cache. Or you could just manage the refresh at runtime instead of using a schedule. Again running a comparison of the datetime of the data and refreshing the cache if needed.

[Former Member]

The answer I'm hearing is that a cache which can be used across disjoint transactions (transactions which do not call each other so they cannot pass this data), must be implemented as a file or a database. I suspected that was going to be the answer, but I just wanted to make sure I wasn't missing something.

Thanks for all the input.

[Former Member]

Tim,

You are correct! The ability to store values in global memory will be a capability in future versions of xMII...most likely in version 12.5 at the earliest.

[Former Member]

Not exactly.

Actually, there are a few other techniques to keep "memory resident data", provided that you don't need it persisted to disk. Obviously, if you want read/write values persisted to disk, a file or database makes the most sense anyway.

That said, there's a cool capability by adding "tags" to an instance of the simulator connector that can be read/write. These can be analog, discrete, or string values.

In fact, you can actually store images and XML documents in there as strings.

The elegant aspect of this is that you simply use Current and CurrentWrite modes in a tag connector to read/write them.

The downside is that the values are not persistent, though if you were really creative, there's an undocumented and unsupported way to make that happen, since the simulator tag configuration file is, itself, an XML file...

Also, I wrote an action block that provides (non persistent) global read/write name/value pairs. If you want this, let me know.

- Rick

[Former Member]

Thanks, Rick. I would be interested in seeing that transaction. Can you please email me the transaction to sara.mani@visiprise.com.

Thanks,

Sara

[Former Member]

I'm not sure what context you are trying to apply this to so maybe a bit more info is required. However, GLOBAL's are meant to be defined prior to any execution and on a manual basis so they are available to all transactions. Any type of parameter modification should be declared within the Transaction-->Properties.

For what you are trying to do, it would be a bit simpler to store whatever value you desire in a session variable using the following:

<b>document.iGrid.setPropertyValue(PROPNAME,PROPVALUE);</b>

• Note: you can replace the iGrid with any other applet type on your page or simply create a 1x1 pixel applet to allow this property access.

Once created you can call that session property with the following:

<b>document.iGrid.getPropertyValue(PROPNAME)</b>

From here you can pass this value to any transaction you may call or any other query you are working with.

I hope this helps. Thanks!

[Former Member]

Alin,

Yes, if I have something like session, I could cache this config file contents into it. But the problem is I don't have Web GUI. I have only transactions which are used for the integration.

I thought that Global property will be the one, can be used for storing the cached values and update this cached value during runtime whenever needed.

Thanks,

Sara