PubSub+ Event Portal Overview

The PubSub+ Event Portal is an event management tool—presented through an accessible Web user interface (UI)—that enables you to create, design, share, and manage various aspects of your event-driven architecture. On this page, we will discuss the fundamental elements of the Event Portal, provide an overview of the tools, and look at some of the underlying features such as event sharing, revision history, tags, REST API, and the AsyncAPI.

Let's first understand the Foundational Elements of the Event Portal.

Foundational Elements of the Event Portal

When designing an event-driven architecture (EDA), it is essential to model the enterprise or interworking systems as a whole, which means dividing it into smaller, more manageable pieces. Once broken down into what the Event Portal defines as Application Domain, within each Application Domain, you can then create a set of event-driven entities or objects (schemas, events and applications) which represent the runtime interactions.

The following are the four foundational elements of the Event Portal:

Schemas, Events, and Applications are often referred to as objects in the Event Portal.

Application Domain

An application domain represents a namespace where applications, events, and schemas can live. Within this namespace, you can create a suite of applications, events and schemas that are independent of other application domains. This provides a way to create independent event-driven architectures for different products. You can also share events and schemas across application domains by creating the event or schema with the shared option selected.

Furthermore, application domains define a topic domain. For all the events in the application domain, the topics defined for these events should be named with the topic domain at the beginning of the topic. For example, if a topic domain is defined as solace/weather, then an event in that application domain may be named solace/weather/blizzard/started.


In simple terms, a schema represents the contract to describe the payload of an event. Producers and consumers of an event can trust that the payload of the event matches the schema definition assigned to that event. Schemas define a type of payload through JSON, XML, Binary, or Text. JSON and XML schemas have content that describes each property of the schema. The content is either in JSON Schema format or XSD/DTD format.


The event represents a business moment or an action that can be communicated with zero or more interested applications. The event is where you define metadata that describes and categorizes the event. An event is produced on a specific topic that must be defined for that event. From a modelling perspective, events reference payload schemas, and events are referenced by applications, thus forming the glue that binds applications together.

It is important to note that an event (or an event type), as referred to in the Event Portal is different from an event instance. For more information on this topic, refer to Event Type vs Event Instance.


An application represents a piece of software that produces and consumes events. Applications connect to the event broker in an event-driven architecture and communicate with other applications via events. A single application represents a class of applications that are running the same code base; therefore, there is no need to create multiple applications for each instance in a cluster.

Event Portal Tools

Use these tools to create, design, manage, visualize, and share all events within your ecosystem.

Event Designer: Design and view all aspects of your event-driven architecture.

Event Catalog: Browse for events, schemas, and applications defined in your environment using a searchable, sortable, and filterable interface.

Event Discovery (Demo): Discover and visualize events from your event brokers.

Event Designer

The Event Designer is a tool to design and views all aspects of your event-driven architectures. It is through the event designer that you can create new events and associate the payload schema to these events. It provides a graphical representation of application domains, applications and events. Use the designer to visualize the interaction of events between applications and to provision your architecture into the Event Portal.

Event Catalog

The Event Catalog acts as a storefront for all the applications, events, and schemas you've created in the Event Portal. Objects created in the event designer are automatically available in the catalog. Using the event catalog's searchable interface, you can access all the existing events, schemas, and applications.

Event Discovery (Demo)

The Event Discovery is a tool to analyze events running over your event brokers in real-time. The results can be visualized to understand better the events flowing in your event-driven architecture. You can currently view a breakdown of your events by topic, including topic hierarchy levels to see the number of events and the amount of bandwidth being sent on a per-topic, or per set of topics, basis.

Event discovery is still in a demo phase. In due course, it will have the ability to transform discovered event instances of the same type into a single event object, which will be saved in the event catalog and designer to visualize and understand your event-driven architecture.

Now that you are familiar with the essential Event Portal concepts try out some tutorials at Designing and Managing Events with the PubSub+ Event Portal .

Event Type vs Event Instance

An event type (or event as it is referred to in the Event Portal) represents a class of events produced in an event-driven architecture. The event type is made up of its topic and schema that represents the allowed payload for the event.

An event instance is a specific instance of an event that is produced. An event instance has an event type. It conforms to the schema of the event type and is produced on a topic defined for the event type. Over the lifecycle of an application, many event instances are produced and consumed.

Shared Events and Schemas

By default, you can only reference events and schemas within their own application domain. For another application domain to reference your events and schemas, the event or schema must be marked as shared. For example, imagine a situation where there are two application domains modelled in the Event Portal: the Weather Events and the Traffic Events. Say, an event is created in the Weather Events application domain called the Blizzard. Since the Traffic Events application domain should be able to consume the Blizzard event, the creator of the Blizzard marks the event as shared. Now when an application is created in the Traffic Event application domain, it can choose to publish or subscribe to the Blizzard event. If it were not marked as shared, it would not be allowed to reference by applications in the Traffic Events application domain.


Applications, events and schemas all have the option to have tags associated with them. Searching for a tag name in the event catalog will find all the objects associated with that tag.

Tags can be a great way to share information with other members of your organization by grouping sets of objects together. Here are some examples of how you can use tags:

  • Create a tag called Java and set it against all of your Java-based applications
  • Create a tag called User and tag all of your schemas related to users
  • Create a tag called Sign in Flow and tag the series of events and applications that are involved in the sign in flow for your application

In the future release of the Event Portal, the event designer will have the ability to filter applications and events based on the tags applied to them. This will give another layer of customization to visualize your event-driven architectures.

Revision History

Revision history track the changes to objects in the Event Portal. Any time an application, event or schema is updated, it creates a new revision.

You can restore an old revision of an object at any point. The act of restoring an object to a previous revision creates a new revision of that object. For example, an object whose current revision is at Rev 2, when restored to Rev 1, will result in it having three revisions. The new Rev 3 will be the same as Rev 1 since it was restored from it.

There are few exceptions you should consider when using the revision history of an object:

  • Owner and tag information of an object is not included in the revision history. Changing the owners or tags of an object will not create a new revision of the object.
  • Restoring to a revision of an object whose associations have changed will not change the associated objects. For example, imagine an event and schema that have both undergone ten revisions. At the time of the second revision of the event, the schema was on its first revision. Reverting the event to its second revision will not return the schema to its first revision, it will continue to be its tenth revision.
  • Application domains do not track revision history. Instead, if you need to revert an application domain and all of its contained objects to a point in time, it is recommended to use the import/export functionality.


AsyncAPI is an open-source initiative that seeks to improve the current state of Event-Driven Architectures (EDA). Using AsyncAPI allows development teams to create applications that communicate asynchronously through events more easily. The core of AsyncAPI is a specification that describes how to create a document that explains the inner workings of an event-driven API.

You can use an AsyncAPI specification document for many functions, such as:

  • Generating documentation
  • Generating code
  • Validating events received by your application
  • Applying API management policies

Learn more about AsyncAPI on their website at

AsyncAPI and the Event Portal

The Event Portal natively supports the AsyncAPI 2.0.0 specification and applications can be exported into an AsyncAPI document. You can export applications in JSON and YAML; the two supported formats of AsyncAPI.

To learn how to generate an AsyncAPI document for an application, refer to Generating an AsyncAPI.


The Event Portal provides a RESTful API that you can use to manage your data in Solace PubSub+ Cloud. Use the REST API to integrate other applications, systems, or client applications with the Event Portal, and model or retrieve your event-driven architectures from your own client applications.

For more information, refer to the Event Portal REST API documentation.

Associating Objects to Build Relationships

A key benefit of using the Event Portal is its ability to track the relationships that exist in an extremely decoupled EDA. It enables the reuse of schemas and events, and graphically presents the relationships that exist between applications and events. For example, a schema may be used by many different events, as the business object changes through a transaction. Multiple producers may produce an event, and an application may consume and/or produce many events. Finally, events may be shared across various application domains. Thus, the Event Portal helps you manage and understand the EDA regardless of which event broker is being used at runtime.

Using Event Portal in Multiple Operational Environments

As an Event Portal user, you can model your event-driven architecture (EDA) in different operational environments. For instance, many organizations will have their applications running in at least one of these environments: development, staging, and production. Some enterprises also operate additional environments such as developer, quality assurance, user acceptance testing (UAT), or multiple production environments. The goal, therefore, is to keep these operational environments separate in terms of software running and user access permissions.

The Event Portal allows for environment separation, in the same way, the PubSub+ Cloud messaging services are separated within enterprises. This means you can create a different cloud console or Event Portal account for each environment within enterprise. You can then create and grant different user access permissions for each of these environments, and use that to model your EDAs as they progress from one environment to the next.

EDAs, including all associated applications, events, and payload schemas, can be promoted from one environment to the next by exporting entire Application Domains from the previous environment and importing it into the next, using the Import/Export Application Domain functionality in the Event Portal.

Next steps