How to upload changes to objects using scripting from OMI runtime?

(Edited with some clarifications)

Hi,

In InTouch you have the Retentive value configuration witch retains configuration data on a tag between shutdown and start up of the application.

But with Application there is no such thing and for years there has been different approaches to resolve the issue you are describing.

The Upload Runtime changes is one, but it will retain ALL settings and you have no control over witch of the settings are saved, performing this in IDE will save alarm settings, comments, data source configuration etc.

This problem was resolved by introducing the Preserve Runtime changes setting on the deploy prompt, and you can configure an attribute to align to this setting. But as you say it is not always 100% reliable, certain configuration changes on a object will upon deploy disregard of the setting and I would advise to test the function if you come to rely on it for production data.

AND if you find bugs or issues, report it to AVEVA tech support.

So back to the Upload Runtime changes, witch is one option.

There is no native way of triggering this action from OMI but the GRAccess Toolkit allows for programmatically perform Upload Runtime changes.

In similar scenarios I have created a 'helper object' (using GRAccess in script) that you can trigger to perform this action, and similar from any other instance/object. using this method i have created self configurating applications and applications that can create, modify and deploy objects without the usage of IDE. Big disclaimer here, GRAccess will require a license for connecting to the galaxy as a development session, so make sure that the object is deployed on the node that you are normally use IDE on, or make sure you have enough development licenses available. GRAccess is not a free path to development actions 

Another workaround is to store requested limits / configuration in a database, or even in xml files, reading settings upon deploy.

If you have them in a database it allows for easy bulk modifications and customer documentation.

The solution of using external storage of important configuration data is commonly used in many systems, and as mentioned, there are several methods in doing so. I would say using a custom database is very common.

Triggering the read configuration upon deploy. Note, to NOT put the database access in the Onscan or startup script since it can effect your deploy stability, there are some good examples on how to implement scripting that triggers on deploy in the Scripting Guide from Aveva.

And to support the update of values you store upon the change of data.

Same thing here, it is not advisable to put the 'save' of data in the Offscan or Shutdown script for the same reasons as Onscan/Shutdown.  

From GRAccess manual:

Upload Method
Uploads AutomationObject configuration changes made at run time.
Class
IInstance
Syntax
[C#]
void Upload(
EAutomaticallyUndocheckout automaticallyUndocheckout,
ESkipOtherUsersCheckedOutObjects
skipOtherUsersCheckedOutObjects,
ESkipObjectsWithPendingUpdates skipObjectsWithPendingUpdates
);

Here is a example on how to do this using GRAccess in a ArchestrA object script.

Keep in mind that it is an example and I would put some effort in improving the error management etc.

but it gives you an idea on how to begin.

I believe it requires you to import the dll for usage in your galaxy (ArchestrA.GRAccess.dll) as a script function library

Also using scripts like this requires you to understand the way of how synchronous vs asynchronous scripting works to avoid locking up you application engine. 

if Me.GR.TagName <> "" then 
	dim ok as boolean;
	try
		dim tagnames[1] as string;
		dim gals as ArchestrA.GRAccess.IGalaxies;
		dim galaxy as ArchestrA.GRAccess.IGalaxy;
		dim cmd as ArchestrA.GRAccess.ICommandResult;
		tagnames[1] = Me.GR.TagName;

		dim grAccess as ArchestrA.GRAccess.GRAccessAppClass;
		grAccess = new ArchestrA.GRAccess.GRAccessAppClass();
		gals = grAccess.QueryGalaxies(MyPlatform.NodeName);
		galaxy = gals["myGalaxyName"];
		galaxy.Login("", "");
		dim queryResult as ArchestrA.GRAccess.IgObjects;
		queryResult = galaxy.QueryObjectsByName(ArchestrA.GRAccess.EgObjectIsTemplateOrInstance.gObjectIsInstance,tagnames[]);
		cmd = galaxy.CommandResult;
		if (cmd.Successful) then
			LogMessage("Command successful");
			dim myInstance as ArchestrA.GRAccess.IInstance;
			myInstance = queryResult[1];
			if (myInstance.CheckoutStatus == ArchestrA.GRAccess.ECheckoutStatus.notCheckedOut) then
				myInstance.Upload(ArchestrA.GRAccess.EAutomaticallyUndocheckout.dontAutomaticallyUndocheckout,ArchestrA.GRAccess.ESkipOtherUsersCheckedOutObjects.doSkipOtherUsersCheckedOutObjects,ArchestrA.GRAccess.ESkipObjectsWithPendingUpdates.doSkipObjectsWithPendingUpdates);
				ok = true;
			else
				LogMessage("Will not complete: object is checked out");
			endif;
		else
			LogMessage("Failed to upload changes,  error: "+cmd.CustomMessage);
		endif;
	catch
		LogError("Error in Upload changes: "+error);
	endtry;

	if ok then
		Me.GR.TagName = "";
	endif;
endIf;



Me.GR.UploadRT = false;

Thanks Richard! this really helps. I was also thinking of the database solution but was curious if there is an upload change command via scripting. 

No problem, I'm happy that you found it useful, please note that i made some minor updates in my original post, I don't know if the forum notifies about this.

I saw the changes thanks!

Great, if you feel that your question was answered please mark the post a Answered, and also let me know if you want to discuss the topic further. 

Hey Richard,

Hi Mario,

I agree with Rickard that using GRAccess in a "low code system" requires some thought and you have to be aware of the effects of modifying configuration in/from runtime. The intension with GRAccess is to enable bulk modifications. You need to ensure a robust error handling and it has to match your backup strategy and version management of the Galaxy. and if you run in to issues with your galaxy it might be a challenge to get support from your Aveva tech support engineers. And as stated, the connection made by your object will require a development session in the perspective of license. The points made by Rickard are still valid.

And lets say you do modifications from an object hosted on the same engine as your production critical objects, time consuming tasks will require you to manage asynchronous execution to avoid locking your object executions.  

But with all that said it is still possible to utilize GRAccess to make changes to your system in "runtime".

There are some systems I am aware of where this is implemented in but the term "recommended" is diluted some by that this moves the responsibility from (supported) core product functions to you as the developer.

Thank you for your assessment Richard.

Best regards

Mario

Hey, that looks like one of my old rants

I think my perspective is pretty much the same as way back then.

Furthermore, Upload Runtime Changes is a "funny" feature given that it offers no granularity and may update a bunch of things beyond the intended scope. I would make extra sure that it will not perpetuate a transitory state that causes problems during a fresh deploy. In some applications it may work ok, but I can see some scenarios where it could cause problems