Welcome to Tango GraphQL project’s documentation!¶
A GraphQL implementation for Tango.
Contents:
API Documentation¶
Contents:
AIOServer¶
A simple http backend for communicating with a TANGO control system
The idea is that each client establishes a websocket connection with this server (on /socket), and sets up a number of subscriptions to TANGO attributes. The server keeps track of changes to these attributes and sends events to the interested clients. The server uses Taurus for this, so polling, sharing listeners, etc is handled “under the hood”.
There is also a GraphQL endpoint (/db) for querying the TANGO database.
Listener¶
Routes¶
Schema¶
Contents:
Attribute¶
Base¶
Device¶
Mutation¶
Query¶
Subscriptions¶
Tango¶
Types¶
Module containing the different types.
-
class
tangogql.schema.types.ScalarTypes(*args, **kwargs)[source]¶ This class makes it possible to have input and output of different types.
The ScalarTypes represents a generic scalar value that could be: Int, String, Boolean, Float, List.
-
static
coerce_type(value)[source]¶ This method just return the input value.
Parameters: value – Any Returns: Value (any)
-
static
TangoDB¶
What is GraphiQL and how can be used¶
GraphiQL is deployed together with tangogql, it is a graphical interactive in-browser GraphQL IDE used to test GraphQL queries. For more info about it check:
Source code Docs for GraphiQL: https://graphiql-test.netlify.app/typedoc/
If you deployed the webjive suite with for example https://gitlab.com/MaxIV/webjive-develop
GraphiQL url link should be acessible for you at: `http://localhost:5004/graphiql/`
To check the type of queries you can use on graphiql see: Examples on query and mutation
Examples on query and mutation¶
Fetch information of devices¶
query{
devices{
name # e.g. get the names of all devices
}
}
query{
devices(pattern: "*tg_test*"){ #filter result with pattern
name
}
}
Accessing attributes¶
query{
devices(pattern: "sys/tg_test/1"){
name,
attributes {
name,
datatype,
}
}
}
query{
devices(pattern: "sys/tg_test/1"){
name,
attributes(pattern: "*scalar*") {
name,
datatype,
dataformat,
label,
unit,
description,
value,
quality,
timestamp
}
server{
id,
host
}
}
}
Deleting device property¶
mutation{
deleteDeviceProperty(device:"sys/tg_test/1", name: "Hej"){
ok,
message
}
}
Putting device property¶
mutation{
putDeviceProperty(device:"sys/tg_test/1", name: "Hej", value: "test"){
ok,
message
}
}
Deleting device property¶
mutation{
deleteDeviceProperty(device:"sys/tg_test/1",name:"Hej"){
ok,
message
}
}
Setting value for an attribute¶
mutation{
SetAttributeValue(device:"sys/tg_test/1", name: "double_scalar",value: 2){
ok,
message
}
}
Query all tango classes¶
query{
classes(pattern:"*"){
name
}
}
Query all tango classes and corresponding devices¶
query{
classes(pattern:"*"){
name
devices {
name
}
}
}
TangoGQL Logging¶
TangoGQL logging system uses a file called logging.yaml by default to configure the logging capabilites, this is an example of that file:
----
version: 1
disable_existing_loggers: False
formatters:
simple:
format: "%(asctime)s - %(levelname)s - %(message)s"
handlers:
console:
class: logging.StreamHandler
level: DEBUG
formatter: simple
stream: ext://sys.stdout
info_file_handler:
class: logging.handlers.RotatingFileHandler
level: INFO
formatter: simple
filename: /var/log/tangogql/info.log
maxBytes: 10485760 # 10MB
backupCount: 20
encoding: utf8
error_file_handler:
class: logging.handlers.RotatingFileHandler
level: ERROR
formatter: simple
filename: /var/log/tangogql/errors.log
maxBytes: 10485760 # 10MB
backupCount: 20
encoding: utf8
loggers:
my_module:
level: ERROR
handlers: [console]
propagate: no
root:
level: DEBUG
handlers: [console, info_file_handler, error_file_handler]
To change the format of the logging can simply change this line:
format: "1|%(asctime)s.%(msecs)03dZ|%(levelname)s|%(threadName)s|%(funcName)s|%(filename)s#%(lineno)d|%(message)s"
TangoGQL Features Toggle¶
TangoGQL has a function called features toggle capable of controling some features such as pub/sub. There is a file inside tangogql/ called tangogql.ini, the file looks like this:
# this configuration file is used to hold details of which features
# currently enabled in TangoGQL ( True = enabled False = disabled)
[feature_flags]
# Publish Subscribe is enable
publish_subscribe = True
Changing the publish_subscribe = True will enabled pub/sub on TangoGQL, in this case, TangoGQL will try to Subscribe to changeEvents on the device, if it fails it tries PeriodicEvents, and if that fails it falls back to polling
TangoGQL Case Sensitive Convention¶
Tango Controls Framework uses ZMQ to manage events. ZMQ is not case sensitive so, it is necessary to define a convention to use upper case and lower case.
The Tango convention is to uses only lower case in Tango attribute name. But it accepts also the upper case. Also different tools, as POGO, permit to declare an attribute name with a different style of the lower case.
The situation can create conflicts when TangoGQL uses ZMQ to pass attribute names that are not case sensitive.
In order to avoid conflicts, TangoGQL transforms every attribute name in lower case. In this way, also if the attribute name doesn’t follow the Tango Naming convention, the communication with TangoGQL proceed without problems.