Contexts

Contexts are a logical division that acts as markers for the event publishing URL. They allow you to reuse topics in different scenarios.

The external authorization server is set by context. This means that if two different contexts are provided for a topic, you can use two separate authorization endpoints for the same topic.

The Contexts screen shows all the contexts registered in your Events Hub:

How contexts work

To understand how contexts work, it’s important to know how the Events Hub manages the publication and subscription to events:

Event publishers send requests to the Events Hub, which distributes them to all registered subscribers.
To make sure that the publisher’s events are delivered to the right subscribers, Events Hub uses topics.
Each topic can have multiple subscribers.
When a publisher sends an event to a specific topic, the Events Hub shares that event with all the subscribers connected to that topic.

Event publication URL

To publish events, you need to create a path (URL) that acts as a channel for sending events from a publisher to the Events Hub.

This URL is composed of base URL + context + handler + topic:

Base URL: Defined by the Events Hub. It includes the client interface address + event-receiver + a unique code (hash).
Context, handler, and topic: these are created by you. They help organize and manage different publication channels.
- Topic is the most specific level.
- Handlers aggregate topics, serving as a logical grouping layer.
- Contexts add another level of grouping, allowing you to use the same topic in different situations. To enable a topic for a publisher, you need to activate it in at least one context.

Imagine that you want to create a flow for publishing various types of alert and test it without notifying subscribers. To do this, you can:

create a handler called "Alerts", with the path /alerts;
register topics grouped within the handler. For example: /latency for latency alerts and api-update for API update alerts;
create a context for tests (e.g., testing) and enable it for the topic you want to test, so that subscribers don’t receive alerts.
- To register subscribers in the testing context, you must link them to the topic and enable them only for the testing context.
- If you don’t register any contexts, Events Hub sets the "Default" context, and no bookmarks are added to the publishing URL. Therefore, requests for the latency or api-update topics will be sent to <url-base>/alerts/latency/<url-base>/alerts/api-update and all active subscribers in it will receive the events.

Considering the example above, the publication URLs for the latency topic will be:

Default context: <base-url>/alerts/latency
Testing context: <base-url>/testing/alerts/latency

The main advantage of using different contexts is that you can reuse the security policy settings and delivery attempts defined in the handler without creating new topics. And since authorization endpoints are defined by context, you can use a mock authorization for testing while keeping the default context authorization unchanged.

Contexts are logical divisions to facilitate the creation and maintenance of topics, allowing you to reuse them in different scenarios. They are not physically separate environments from each other.
This means that if you use the "Default" context for production events and the "Testing" context for test events, you can control publishers, subscribers, and authorization endpoints for each context. However, all events received and distributed in the Events Hub share the same infrastructure.
Tests that overload the infrastructure, even when conducted in the testing context, may affect the receipt and distribution of events in other contexts.

Authorization

The endpoints that validate publishers are defined for each context. This is done on the Authorizations screen, which contains two sections: OAUTH and JWT. Both sections display all contexts registered in the Events Hub, indicating the authorization URL defined for each one.

The use of security interceptors is optional. However, if you add policies to your handler, you need to configure the Authorization URL linked to the interceptor. Except for "IP Filtering Validation," all depend on this configuration to work.

See how to use the Sensedia API Platform for publisher authorization.

Associating contexts

Contexts are linked to topics through the Topics tab when creating or editing handlers. To publish events, you associate topics and their contexts with publishers and subscribers. This happens as follows:

Publishers: in the Topics step during publisher registration, select the topics you want.
1. You will see the available contexts for each topic. Choose which one the publisher will be allowed to publish in.
Subscribers: when registering a subscriber, you must subscribe them to the topics from which they will receive events. By enabling topic contexts for them, they will only receive events from active publishers in that context.
1. During subscriber registration, in the Topics step, select the desired topics. You will see the available contexts for each topic.
2. Choose which one the subscriber will receive events from.

Creating contexts

You can create up to 5 contexts in the Events Hub. The "Default" context is standard and cannot be edited or deleted.

When you reach the limit of created contexts, the + button will be disabled, preventing registration. If you need a new context, you will need to delete an existing one.

To create a new context, click on the + button. Fill in the fields:

Name: a unique name identifying the context.
Path: the context path, which will serve as the publication URL marker.
Description: an optional description for the context.

After registering it, the context will be displayed in the TOPICS step of handler creation/editing and can be enabled for any topic.

Context overview

By clicking on the name of a context, you will see the topics linked to it. On this screen, you can:

search for a topic using the Keywords field. The search looks for the name or description of the topics and the handler’s name;
edit the context by clicking the EDIT CONTEXT button. This option allows you to edit the name, path, and description of the context;
view details of a topic by clicking on the name in the Handler column. This will take you to the TOPICS tab on the Handlers page;
delete the context by clicking on the icon .

You can only delete contexts that are not associated with any topic. If it is, you will need to disable the context in each topic before being able to delete it.

Thanks for your feedback!

EDIT

How useful was this article to you?