Testing a Graph

Xponent allows graphs and nodes to be tested interactively before deployment. This enables the testing of individual components using user-supplied test cases, by specifying one of the input data JavaScript objects, a number of iterations of a graph, or by specifying a fixed time duration.

Graphs can only be tested when they are valid.

Click on the Validate button located at the top of the graph to test the Graph validity, or this will be pushed automatically if the start button is pressed.

The valid graph icon is displayed at the top right of the graph window if the graph is Valid.

The valid graph icon is displayed at the top right of the graph window if the graph is Invalid.

It is unnecessary to manually validate the graph as the graph will be automatically validated before the testing console is opened, and any errors will prevent it from opening.

The Testing Console

The testing console is available at the bottom of the graph window. It provides insight into the execution of each step in the graph and the state of the data store and public variables at the end of the execution. The testing console bar provides four buttons for control of the testing console. From left to right:

• Start: Starts the graph engine and shows the Testing Settings window. They have shown grey when the graph is executing. The Start button is only available for a valid graph.

• Stop: Stops the execution of the current graph. Shown as green when the graph is executing.

• Clear Logs: Clears out the Testing Console and removes information from all previous runs.

• Maximize and minimize: Maximize or minimize the Testing Console. The Console can also be enlarged or shrunk by grabbing the bar between the graph window and the Console and moving it up or down.

Testing Settings

At the start of each execution, after the Start button has been pressed, the Testing Settings window will appear. For a standard graph, without a listener or most types of nodes, the window will look like this:

This allows you to paste in some JSON data to be used as the input to the graph. This data could be the output of a previous graph test.

If the graph has a listener, then the Testing Settings window will show the three modes of testing the graph:

There are three modes of testing graphs interactively:

• Iterations - for non-listening graphs, the graph will always execute once. The number of iterations for listener graphs will limit the maximum number of times the graph is executed.

• Duration - specify the number of seconds that the graph should execute for - this is only applicable to listener graphs.

• Data - execute the graph using the supplied JSON data.

Note that during visual testing, there are some limits on graph execution:

• The maximum number of iterations is 1,000.

• Duration - the maximum runtime of any graph is 30 minutes.

These limits are set so that interactive graphs don't lock up engines unnecessarily.

Testing Console Output

The testing console will show the button if the graph is a listener. If the graph is not a listener, then it will progress to the state.

The Testing Console displays the following information for every node executed in the graph:

• The name of the node and the type of the node if it is an adaptor.

• The execution time - usually in milliseconds.

• The return value of the node.

The information in the testing console must be expanded using the + icon. The second and subsequent runs appear below the first run.

Console Error

Errors are highlighted in orange and display detailed error messages from the engine.

If the graph is a listener and there are multiple iterations, then the graph will show the path for a particular transaction if the mouse is held over that transaction. The graph highlights the path with a dark blue highlight.

Transaction Logging

A transaction represents a single execution of a graph, including any sub-graphs. It encompasses all nodes that were processed during that run, whether they completed successfully or failed. Transaction Logging is an Xponent capability that captures and stores detailed execution data every time a graph runs in production. It allows users to monitor, review, and troubleshoot graph behavior by linking all node activity under a unique transaction ID.

Standardized Transaction Log Fields: Each transaction log captures consistent metadata to enable traceability and troubleshooting. The following fields are included:

• Client/Org ID - Identifies the organization that owns the graph.

• Project ID - Specifies the associated project.

• Graph ID - Unique identifier for the executed graph.

• Transaction ID - Unique ID assigned to each graph execution.

• Transaction Timestamp - When the transaction started.

• Node ID - Internal ID of the node.

• Node Name - User-friendly label for easier recognition.

• Execution Status - Indicates whether the node succeeded (true), failed (false), or was skipped.

• Error Code / ID - Coded representation of the error (if applicable).

• Error Message - Descriptive error message (if applicable).

• Execution Time - Duration taken to execute the node.

• Environment - The environment name (For Example: Default, Dev, QA, or Prod).

The final state of the schema is available to be viewed and copied by pressing the view JSON button in the testing console.

{
   "transactionId": "4b569fb3-2511-4c99-97c2-d067a96a92e5",
   "deploymentId": "797a6c09-6675-4b48-b120-624bfceb842a",
   "organizationId": "3593305318831948804",
   "organizationName": "DemoSession",
   "projectId": "3597640920259888161",
   "projectName": "TransactionLog",
   "graphId": "3597641056826426515",
   "graphName": "That's My Graph Name",
   "subgraphId": null,
   "subgraphName": "",
   "environmentId": "3597640920335385639",
   "environmentName": "default",
   "versionNumber": "0",
   "versionName": "Current",
   "nodeId": "3597641056910312754",
   "executed": true,
   "error": {},
   "prototypeId": "4",
   "nodeType": "api_return",
   "processTime": "0.012789011",
   "timestamp": "2025-03-27T16:18:49.969865"
}

Where I Can Find Transaction Logs For Production Hub?

Transaction logs are available through Transaction Logging, a log search and analytics platform. You can access it via SSO using dedicated environment-specific URLs.

User access to Transaction Logging will not be available at the time of the 25.1 release. It will be enabled shortly after. For access-related queries, please contact your CSG Customer Success Team representative.

Transaction Logging is introduced to provide users visibility into graph executions in production environment, visibility that was previously only available during testing. It bridges the gap between what users can validate in the testing console and what they can troubleshoot in live, real-world deployments.

For Example: Imagine a graph meant to process a file with 100 rows and send only 70 emails. If only 70 emails are sent, users can use transaction logs to:

• Verify whether the graph executed and how many times.

• Identify which nodes completed successfully and which ones failed.

• Locate the specific errors and understand where they occurred.

• Act on the issue immediately without needing assistance from TechOps.