Graph management¶

Graphs describe who can send a message and how it is to be processed.

They are managed via the graph command of the xbusctl program.

Publishing a new version of a graph¶

Update or create a yaml file with the graph definition (‘graph.yml’ below).
Send it to Xbus via the graph save command of the xbusctl program:
```
xbusct graph save a_name 1.0 graph.yml
```
A version can be updated as long as its status is ‘draft’.
Activate the graph (will disable older versions)
```
xbusct graph status a_name 1.0 --active
```

Example graph descriptions¶

Simple graph that sends any test_event to xbus-example-consumer:

nodes:
- id: emitter
  sourcematch:
    eventtypes:
    - test_event
  inputs: []
  outputs:
  - default
- id: consumer
  type: consumer
  actorids: []
  roles:
  - xbus-example-consumer
  rolebroadcast: true
  sourcematch: null
  inputs:
  - default
  outputs: []
edges:
- emitter.default->consumer.default

Same graph but with a matching by role (only emitters registered to the specified role may send a test_event) - note the rolebroadcast parameter being set to true in this case:

nodes:
- id: emitter
  roles:
  - xbus-example-emitter
  rolebroadcast: true
  sourcematch:
    eventtypes:
    - test_event
  inputs: []
  outputs:
  - default
- id: consumer
  type: consumer
  actorids: []
  roles:
  - xbus-example-consumer
  rolebroadcast: true
  sourcematch: null
  inputs:
  - default
  outputs: []
edges:
- emitter.default->consumer.default

Same as the first graph but with an explicit emitter, specified by name:

nodes:
- id: emitter
  type: emitter
  actorids: []
  roles: []
  rolebroadcast: false
  sourcematch:
    eventtypes:
    - test_event
  inputs: []
  outputs:
  - default
- id: consumer
  type: consumer
  actorids: []
  roles:
  - xbus-example-consumer
  rolebroadcast: true
  sourcematch: null
  inputs:
  - default
  outputs: []
edges:
- emitter.default->consumer.default