Vumi Go event magic

gistfile1.md

Events

We add a new type of Vumi Go message, similar to a VumiApiCommand to handle events:

VumiApiEvent:
  account_key
  conversation_key
  conversation_type
  event_type
  event_data

A kind of event is uniquely identified by conversation_type and event_type, and event_data is a dict. All events go to an event dispatcher (either part of or similar to the command dispatcher) which looks up what needs to happen with each event and does the appropriate things.

Event sources

Event sources generate and publish events.

All application/conversation workers are potential event sources. We may want to have some additional non-conversation event sources as well at some point.

Event handlers

Event handlers are pieces of code (perhaps workers, perhaps part of the event dispatcher) that accept an event and then do something with it. Handlers would have to be specific to certain event types, but could also be event sources and fire their own events in response to things the're handling.

For example: A vxpolls conversation could fire a poll_complete event containing the poll results when someone finishes filling in a poll. The account has a create_contact handler listening for poll_complete events from that particular conversation, and configured to extract certain values from the poll data to create a contact with.

Configuration

Event handlers would have to be configured in the UI somewhere, probably in a manner similar to a conversation start. Perhaps this kind of flow:

1. Create new event handler
2. Select event source and type
3. Select event handler type
4. Configure handler-specific options
5. Profit!

We'd need to be able to chain handlers, so we could create a new contact and then send an SMS when a poll finishes.

Routing and tags

Not entirely event-related, but this might be a good place to set up account-level tag routing and such, perhaps with a default account-wide message handler that does something sane rather than just throwing all the messages on the floor.

@hodgestar:

• That's something we need to decide. It'll probably be a bunch of yucky account-level UI work pushing a configuration into a datastore somewhere the event dispatcher can see it.
• Event handlers live in vumi-land, not Django-land. Probably either in the event dispatcher or in their own workers. I'm leaning slightly toward the former at the moment, but we need to figure out what will work best for us.
• The poll_complete event is actually the example that kicked this whole thing off. At an account level, we need certain actions outside the poll worker to be triggered when a poll completes. This could be contact creation, SMS sends, payment gateway notification, whatever. The point is that none of that behaviour belongs in the poll worker, and we want to be able to configure it for whatever the account owners need.