Xponent uses an internal Data Store during graph execution. This data store is used to keep track of all activities in the graph and holds data that is necessary for the processing. Every node has at least one input or output location that refers to the data store. The data in Xponent falls into one of three distinct types:

Data Schema - a JavaScript Object that lasts for the execution of a single graph - can be read from and written to from any node in the graph
Literal - a constant value which is used as an input to a node or the return value from a Return Node
Public Variable - a JavaScript object that exists outside of the schema. A public variable can be read from and written to from any node in the graph. Public variables have two modes: transactional and persistent. Persistent public variables last throughout the deployment of a graph and across all listen events.

When building a graph and choosing data locations for input and output to nodes the three options for choosing data are shown in the top right panel of the window. This panel can be rotated between the three views of 'Data Schema', 'Literals' and 'Public Variables' by using the tabs at the top of the panel:

Data Schema

The Data Schema can be thought of as a single JavaScript Object. The object can contain fields and other objects. It is represented as a hierarchical layout. Child schemas can contain fields and other objects. Elements can be opened and folded using the down chevron and up chevron buttons. Graphs can read and write individual fields or whole records from the schema during execution. It is not necessary to declare fields in the schema prior to graph execution but it is necessary if they are to be chosen as an input or output location for a node.

Adding a Single Field to the Schema

When you first start a new graph, the Schema section will be blank. New fields can be added to the schema using the Add Child Single Field to 'schema' button

The Add Field dialogue will be shown:

After adding the field the Schema will look like this:

The 'newChild' field does not have any children of its own so is shown with a single '>' rather than with up or down chevrons

Adding a Child Record via JSON to the Schema

A child record can be added to the schema by selecting the position at which the record is to be added and pressing the Add Record button . Records can be add at either the top level 'Schema' or somewhere further down the hierarchy. The Add Child Record window appears and you can type or copy in any valid JavaScript Object Notation (JSON) record definition. Actual values are not necessary and can be junk data but not missing. Missing values will return a JSON: SyntaxError message.

Error State:

There are many places where you can check that you have a valid JSON document - an easy to use one is JSON Lint. Note that this must be a valid standalone object and so must start and end with curly braces ({,}).

After the addition of this record the schema will now look like this:

Editing the Schema

Any record or field can be renamed by selecting the item and pressing the rename button .

Any record or field can be deleted by selecting the item and pressing the trashcan button .

Schema is Created

Once you have created your schema, you will now be able to define the key values in the graph nodes for input/output/source. Example, in a GET node, you can define your schema location to profile/profileCommon/PId

Schema Scope

The scope of the schema in unique to a single execution of a graph. Schema is shared across the parent graph, sub-graphs, and loop nodes that make up a single transaction.

Schema locations referenced inside a managed graph node instance will share scope with other nodes if their nesting and naming is identical to schema locations in the project in which the managed graph is being used. A future release, may isolate the schema of a managed graph from the schema of the project. However, because users of managed graphs may not have visibility into schema locations used by a managed graph, it is recommended to create a top-level schema location called "managed" or some other unique name and nest all other schema locations under this when creating a managed graph.

Literal Values

Literal values are any valid JavaScript object. This includes simple literal values such as strings, numeric values or more complex JavaScript objects.

Examples include:

Values

```
String - "Hello World" 
```
```
Numeric -  3, 4.5 
```

Objects

{ "car" : { "make" : "Ford", "model" : "Mondeo", "engine" : "diesel" } }

Public Variables

Public Variables can hold any valid JavaScript object. Public variables are usually used to hold data that is necessary but not related to the entity being processed. This may be a temporary value or an access key for example. If the data should be part of the transaction and discarded at the end of the graph execution then it is better expressed as part of the schema. Public variables can be initialized with values unlike schema elements.

Creating a Public Variable

To create a public variable use the Create New Public Variable button when the Public Variables window is selected.

This will bring up the Add Public Variables dialogue:

Public Variable Scope

Public Variables have a scope which can be persistent or transactional.

Transactional public variables' scope is limited to a single execution of a graph. After the graph execution completes, the value of the public variable is reset. Transactional public variables function very similarly to schema locations; however, unlike schema, you may specify an initial value.

Persistent public variables in a deployed graph share scope with all graphs deployed in the project within the same environment. Once a persistent public variable's value has been set, it will remain set as long as there is a graph deployed from the project within the environment. Once no graphs from the project and environment are deployed, the value of the public variable will remain set and available for a short period to allow any final graph executions to complete successfully.

When used in a visual test, public variables do not share scope with other visual tests, nor do they share scope with public variables in deployed graph.

Public variables that are used inside a managed graph do not share scope with public variables in the project in which the instance of the managed graph is being used. If two instances of the same managed graphs exist, the public variables of these managed graphs will have a shared scope. Under certain circumstances, the public variables of two different managed graphs created from the same source project may share scope, therefore, it is recommended to use a unique public variable for each managed graph.

Browser not supported