Scoping of Variables in TDI

When it comes to scoping of variables in TDI, in general all variables are globally scoped within a Script Engine. And since each AL has its own instance of the Script Engine, this means that a variable declared in one place is available everywhere in your AL for the duration of this run.

There are a couple of exceptions. Firstly, if you declare variables in a function (using the "var" reserved word), then these are only locally scoped.

function myFunc() {

   var myVariable = 42;

}

In the above snippet, myVariable is only scoped locally within the function. So it will not affect any globally scoped variable with the same name, and this instance can only be accessed from within the myFunc() function.

Furthermore, scripted components (e.g. Script Connectors, Script Functions, and so on) each have their own Script Engine instance and can therefore not directly share scripted variables. The reason for this is historical, since in the Metamerge days Integrator allowed you to choose from a range of script languages to use, even combining different languages for the AL itself and its scripted components. However, this compartmentalized design still serves a useful purpose in the current version by forcing you to create scripted components that work independently of the context they are used in.

So this leads to the question of how to share variables between Script Engines, and as usual TDI offers you a couple of options to choose from:

  1. As you know, the value of an Attribute can be any type of Java object -- including a new Entry with its own Attributes and values, a component (e.g. Connector, Function, Parser, ...) or even the reference a running AssemblyLine. So one way to pass objects is as an Attribute value. Entries can be passed between ALs, as well as from an AL to any of its components (and back) via Attribute Maps or script calls.

  1. You can also use Java properties to pass variables between ALs and/or components, as long as they are all running in the same JVM:

// set up session

var domSes = createDominoSession();

// Save the session as a Java property

java.lang.System.getProperties().put( "myDomSession", domSes );

This can then be retrieved by a get() call from elsewhere in the JVM.

  1. Another option is to use the MemBufferQ object, which allows you to set up serial "pipes" between processes. There are convenience methods in UserFunctions (the system object) like newPipe() and getPipe(). Check out the TDI JavaDocs for more details.

-- EddieHartman - 06 Dec 2005
Topic revision: r1 - 06 Dec 2005, EddieHartman - This page was cached on 08 Aug 2023 - 11:41.

This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TDI Users? Send feedback