Page Comparison

...

• [Kafka specific] Make sure your code is running in an environment that has the confluent_kafka library installed along with its avro and schema-registry extras. See https://github.com/openedx/event-bus-kafka/blob/main/docs/decisions/0005-optional-import-of-confluent-kafka.rst for why this has to be done separately.

  • For local development, you can simply exec into the relevant container and run pip install confluent_kafka[avro,schema-registry]

  • Once you make sure confluent_kafka[avro,schema-registry] is available you can add the openedx-events and edx-event-bus-kafka as you would any other dependency.

• Anchor
  Add-required-Redis-config Add-required-Redis-config

  For Redis implementation:

  • Code Block
    language yaml
    # This tells openedx-events which library to use to create the event producer. # This allows us to plug in different implementations EVENT_BUS_PRODUCER: edx_event_bus_redis.create_producer # This tells openedx-events which library to use to create the event consumer. EVENT_BUS_CONSUMER: edx_event_bus_redis.RedisEventConsumer EVENT_BUS_REDIS_CONNECTION_URL: redis://:password@edx.devstack.redis:6379/' EVENT_BUS_TOPIC_PREFIX: dev

• Anchor
  Add-required-Kafka-config Add-required-Kafka-config

  For Kafka implementation:

  • Code Block
    language yaml
    EVENT_BUS_KAFKA_SCHEMA_REGISTRY_URL EVENT_BUS_KAFKA_BOOTSTRAP_SERVERS # This tells openedx-events which library to use to create the event producer. # This allow us to plug in different implementations EVENT_BUS_PRODUCER: edx_event_bus_kafka.create_producer # This tells openedx-events which library to use to create the event consumer. EVENT_BUS_CONSUMER: edx_event_bus_kafka.KafkaEventConsumer #### If using an auth-restricted broker ##### EVENT_BUS_KAFKA_SCHEMA_REGISTRY_API_KEY: 'MY_SR_KEY' EVENT_BUS_KAFKA_SCHEMA_REGISTRY_API_SECRET: 'MY_SR_SECRET' EVENT_BUS_KAFKA_API_KEY: 'MY_KEY' EVENT_BUS_KAFKA_API_SECRET: 'MY_SECRET'

•  We also strongly recommend using a topic prefix to distinguish between environments, eg ‘dev’, ‘stage’, or ‘prod.’ This prefix will be added to all topic names when both producing and consuming. Adding a topic prefix will reduce the likelihood of accidentally conflating data from different environments. To add a topic prefix, use the EVENT_BUS_TOPIC_PREFIX setting.

Producing a signal

As of openedx-events 9.0.0 version, producing a signal to event bus is possible by just adding below settings to the host application and including openedx_events in INSTALLED_APPS setting.

# .. setting_name: EVENT_BUS_PRODUCER_CONFIG
# .. setting_default: all events disabled
# .. setting_description: Dictionary of event_types mapped to dictionaries of topic to topic-related configuration.
#    Each topic configuration dictionary contains
#    * `enabled`: a toggle denoting whether the event will be published to the topic. These should be annotated
#       according to
#       https://edx.readthedocs.io/projects/edx-toggles/en/latest/how_to/documenting_new_feature_toggles.html
#    * `event_key_field` which is a period-delimited string path to event data field to use as event key.
#    Note: The topic names should not include environment prefix as it will be dynamically added based on
#    EVENT_BUS_TOPIC_PREFIX setting.
EVENT_BUS_PRODUCER_CONFIG = {
    'org.openedx.content_authoring.xblock.published.v1': {
        'content-authoring-xblock-lifecycle':
            {'event_key_field': 'xblock_info.usage_key', 'enabled': TrueFalse},
        'content-authoring-xblock-published': 
            {'event_key_field': 'xblock_info.usage_key', 'enabled': TrueFalse},
    },
    'org.openedx.content_authoring.xblock.deleted.v1': {
        'content-authoring-xblock-lifecycle':
            {'event_key_field': 'xblock_info.usage_key', 'enabled': TrueFalse},
    },
}

The above setting is read on application startup and a generic handler is connected to each event type allowing users to push to event bus without writing additional code.

...