Deployment

Once a graph has been tested visually, it is ready to be deployed in a lights-out or headless fashion.

Before deploying a graph, ensure that the graphs have the latest desired changes in the version that is selected to be deployed. This is important as each environment can only have one version deployed. An example would be if you decided to deploy Version One in the Production environment, then all the deployable graphs following that deployment would need to be in Version One. 

Open

The deployments tab will show all graphs in each Environment. In order to deploy a graph, the graph must have a valid listener node. A deployable graph is any valid graph that has a listener node. 

If a graph does not have a listener it will not be shown in the list. If the environment does not have valid connections then the Invalid Connections message will be shown when the  (deploy button) is clicked. The version of the graph that is deployed in the particular environment is the currently active version as selected from the Versions tab. 

If the listener graph is using the Xponent Graph API then the end point will be different for the chosen environment. This allows deployment to a higher production environment while development continues in the development environment.   

Starting and Stopping a Graph 

• Open

  

   The deploy button is used to start the graph. Graphs will continue to execute until the Halt button is pressed. 
  
  

   

• When the graph is running in the selected version and the Halt button is also shown. 

Redeploy the Graph 

If the graphs had already been deployed before the Single Source of Truth launch into production.
Which is not available in the Engine but not in the Hub’s database.

This status allows the user to stop the graph, which removes the graph from the Engine database.

Also, it allows the user to redeploy the graph, which adds the same record to the Hub's and Engine's database.  

Multiple Listeners

By default, each graph will have the Listener status set to 1. You can set the listener count to multiple if you wish to speed up the processing for a Queue listener. It is important to make sure that the increase in listeners will be balanced with data processing needs. Xponent recommends that a max of 2 on the queue listener should be suitable in most circumstances. You do not need to set listener count for any other types of listener graphs, as Xponent will automatically scale based on the data processing volumes. It is also not advisable to increase the Listener count for Twitter and Database Listeners in case of any conflicting data override.

When you increase the listener count in a version and then publish said version, the listener count will then be increased in that new version.

Queue, Database, and Batch Listeners Rate Limiting

The node-level timeouts allow us to track how often an execution or a deployed graph times out. If a deployment continuously times out:

• The listeners set the graph to a critical state

• Record the information

• Pause the listening to avoid overwhelming resources

For example: The deployments tab will show the below critical listener error.

Deployment Alerts

Once the graph is deployed any execution problems will be emailed to contacts that have been added in the Contacts tab of the Project Admin screen. 

The email will come from no-reply@Xponent.com and will have this format: