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

1. 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

2. 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

3. 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