Tag configuration error expression binding

Hey all I am having an issue when dynamically creating tags based off a UDT structure. I believe I have verified all the helpers but I would greatly appreciate any points of concerns. So I am generating a tag, this specific tag is an expression tag running a 'runscript' expression and is based off a UDT and has its own tag group.
Tag


So we can see this tag is using mes.config.sp.getLineConfig(LineName) if I run this script in the script console I get a Output and the correct data.

Script Console

res = mes.config.sp.getLineConfig('SampleLine')
column = res.getColumnNames()
for row in range(res.getRowCount()):
    for col in range(res.getColumnCount()):
        print column[col] + ' - '+ str(res.getValueAt(row, col))

I thought it may be the {[.]name} param but i have verified that param quality is good and i have a value

Name Param

Tag Diagnostics
[null, Error_ExpressionEval("Error executing script for runScript() expression:mes.config.sp.getLineConfig"), Mon Nov 11 13:45:08 EST 2024 (1731350708941)]

Tag Group

I am using the same UDT structure to generate all the other tags in the config UDT structure such as the name.

I have a feeling the reason the tag is failing has something to do with the tag group, but i cant seem to find an issue, any help would be greatly appreciated.

Is the script located in the Gateway Scripting Project?

2 Likes

yes, however now that you mention it I need to pull my most up to date gateway scripting project so let me try that real quick

If you look in the Tag Diagnostics panel is there any additional information presented there?

Is there any logging being used in the script?

Can you share the actual script?

So this is the diagnostic logging
[null, Error_ExpressionEval("Error executing script for runScript() expression:mes.config.sp.getLineConfig"), Mon Nov 11 15:00:28 EST 2024 (1731355228902)]

Script

#@timeit
@error_log
#@dump_args
def getLineConfig(line, db=db):
	""" TODO: None
		Args:line (string):
		Returns:None      
		Testing: mes.config.getLineConfig('SFN1')
	"""
	call = system.db.createSProcCall("tag.stp_getLineConfig", db)
	call.registerInParam("line", system.db.VARCHAR, line)
	system.db.execSProcCall(call)
	return call.getResultSet()

I have also verified db is valid.

I do have a question for this, I have made sure that the script exists on the mes_gateway (my gateway scripting library) however I have overridden a different file that does not pertain to this question but technically I did override my scripting gateway, could this be causing issue?

image

I’m a not sure, but I don’t believe that overriding a project resource would effect things outside of that resource, and I’m fairly certain it would not effect a gateway setting.

I will say that I have had very poor luck with the SProc suite of functions.

At the very least if you’re expecting the sproc to return a value upon completion you must also register a return parameter, even if you do not intend to use it.

I am also assuming that db is a top level variable in the scripting library. If it is not that could very well be the source of your error.

You should also implement some logging in the script to examine how far through the script processing gets and to examine the values of the variables at different times.

Personally, I would just call the SProc from a NamedQuery and be done with it.

Yes, I have verified the script runs fine and the db. connection is operational. However I do agree with logging and using a named query. The big issue is we want to be able to plug this data anywhere to whatever application we want so having a sproc to call from the database level always gives us this, ideally yes we would use a named query but I believe this case we don't necessarily have to use it. I will add some more logging, but the script itself is running fine in the script console its only in the expression tag it fails. Btw thank you for your insight and help so far.

You can call a SProc from a named query. No need to change your overall architecture and you don’t have to deal with all the odd behaviors of calling a SProc from script.

I believe we are getting a little of track, the way I'm calling a sproc works fine if I call it from the script console so i know the code fires error free. It is only when it is inside the expression tag that it ceases to function hence my confusion and the creation of this post. I agree with your logic and your conclusion for named queries but it is not the main issue i have at hand here.

Except for when you run a script from the script console you run it in Vision Client Scope, when you call that same script from Perspective or from a Tag, you call it in Gateway Scope which fundamentally changes the way that some functions work and sometimes even their signatures.

It is very much on track with the issues you are seeing. The designer script console is not an adequate test bed for perspective scripts of much complexity.

2 Likes

The designer script console is Vision Project scope. An expression tag runs scripts in Gateway Non-Project scope, which falls back to the gateway scripting project, if any.

Many system.* functions have different argument requirements and different default behaviors in gateway scope.

Basically, your test is not valid.

You should wrap your target function in another function that uses double-clause exception capture to explicitly log any errors. Like this:

from java.lang import Throwable

logger = system.util.getLogger("SomeLogger")
# Or with the Integration Toolkit
# logger = system.util.getLogger(system.util.getProjectName() + '.' + system.reflect.getModulePath())

def wrappedGetLineConfig(line, db):
	try:
		return mes.config.sp.getLineConfig(line, db)
	except Throwable, t:
		logger.info("Java Error:", t)
	except Exception, e:
		logger.info("Jython Error:", later.PyAsJavaException(e))
		# or with the Integration Toolkit:
		# logger.info("Jython Error:", system.reflect.asThrowable(e, None))

Call that from your expression tag instead.

2 Likes

Of particular note here is that the database parameter in system.db.createSProcCall() is optional in Vision Client scope, but not optional in Gateway Scope. It could be that there is an issue with your db variable not being correctly set. In the script console, the argument would default to whatever you have the projects default database set to, and would work as expected. In gateway scope this would result in an error.

thanks I had no idea they run in different scopes so I now see my tests are invalid. thank you for the documentation aswell I plan to use it in my testing

thank you for the exact code, I will implement it and get back with logs if i cant diagnose them myself. thanks for your help