PubSub+ Event Portal 2.0

Event Portal is a cloud-based event management tool that helps you to design your event-driven architecture (EDA). You can use Event Portal to design and track the relationships that exist between applications in a highly decoupled EDA. You can model applications and associate events to them, use topic addresses to define and categorize events into a taxonomy, and catalog events for reuse.

Event Portal helps you model your event meshes for the multiple operational environments that you maintain in a software development lifecycle. You can have multiple versions of applications, events, schemas, and enumerations, which enables you to maintain production versions while you develop and test new versions to extend and enhance your EDA at the same time.

Event Portal Tools

Event Portal includes several tools to help you design your event mesh:

  • Designer helps you design and view all of the objects in your EDA.

  • Catalog is a library of all the applications, events, schemas, and other objects in your organization's account in Event Portal.

  • Runtime Event Manager helps you create an architecture model of your event mesh to visualize how your EDA will perform in the runtime.

Designing your EDA in Event Portal

Event Portal helps you define the building blocks of your EDA.

Application Domains

An application domain represents a namespace where applications, events, and other EDA objects reside. Application domains organize your applications, events, and other associated objects for different teams, groups, or lines of business within your organization.

Within an application domain, you can create a suite of objects that belong within the application domain. Every object belongs to one application domain to maintain a clear ownership. You can control access to application domains to limit the users who can work in the domain and manage the objects within it. You can also share objects for use in other application domains, which lets you create common assets that you can make available across your organization and use to build relationships between different parts of your EDA. To learn about creating and working in application domains, see Application Domains

Application domains also define the topic domains for the events created within the application domain. Topic domains define the top levels of your topic hierarchy. You can use topic domains as the starting point for the topic addresses you set for events within the application domain. For more information about topic domains and addresses, see Topic Addresses

Applications

An application represents software that produces and consumes events. Applications connect to an event broker in an EDA and they communicate with other applications using events. Applications can publish events to be consumed by other applications and can subscribe to events to act on them in some way. In Event Portal, a single application added to the application domain represents the class of application instances that are running the same code base. To learn about creating and updating applications, see Applications.

Events

Within Designer, an event is an object that defines the properties that describe and categorize actual event instances. You create events in Designer to define the messages that applications publish for every instance of an event as it happens in real-time. Each event in Designer defines an event type that represents individual event instances produced in an EDA.

Each event references a schema that describes the payload of the event. Some event payloads consist of primitive schema types such as String and Numbers. Event Portal supports primitive types so that you can model your events with payloads that are simple primitives. To learn about creating and updating events, see Events.

Each event has one or more topic addresses that define the topics of each event instance at runtime. Event brokers use topics to route each event instance to subscribing applications. For more information, see Topic Addresses.

Schemas

A schema defines the payload of an event. Producers and consumers of an event can both understand an event's payload based on the schema definition assigned to the event. Some events need complex schemas to describe the properties of each value that could be used in the event. You can create complex schemas in Event Portal using JSON Schema, XSD, DTD, or Avro format. To learn about creating and updating schemas, see Schemas.

Enumerations

An enumeration is a bounded variable with a limited set of literal values. You can use enumerations to define acceptable values for a level in a topic address or topic domain. If you use enumerations, the values should include all potential values related to one element of data for the event, such as the days of the week, a list of cities where your organization has offices, or a list of actions that can be taken on a product order. To learn about creating and updating enumerations, see Enumerations.

Event APIs and Event API Products

After you've designed or imported the building blocks of your EDA, you can use event APIs to curate your event data into packages that you can share with others to use to build new applications. Event APIs can be shared with application developers by generating and sharing an Async API document.


An event API bundles together the following information:

  • events you want to provide to other application developers
  • associated schema information
  • information about the event operation (publish and/or subscribe)

To learn about creating and updating event APIs, see Event APIs

You can also bundle one or more event APIs into an Event API Product that you can provide to other organizations so they can consume the events that you have included in your event APIs. An Event API Product contains one or more event APIs plus service plan details for deploying the product to allow others to consume the events.

To learn about creating and updating Event API Products, see Event API Products.

Object Versions and Lifecycle States

In Designer, you can define multiple versions of applications, events, schemas, enumerations, event APIs, and Event API Products. Object versioning allows you to update objects and test updated objects in a development environment while the previous version remains in production. Each object version can be assigned a lifecycle state to help you track the lifecycle stage for each version. Each object version can have one of these states:

  • Draft — The object version is still in development and subject to change.

  • Released — The object version will no longer be modified, can be added to new designs without concern over changes, and is ready to be added to a modeled event mesh or promoted to another modeled event mesh in an environment that is at a more advanced stage of production.

  • Deprecated — The object version is still supported but it will be phased out and it should not be used in new designs. A newer version of the object is, or will soon be, released and objects that reference this version should be updated to reference the new version

  • Retired — The object version is no longer supported and no other active object versions can reference it

When you create or update an object, you define the version using semantic versioning in the format major.minor.patch. For more information about semantic versioning and best practices for using it, refer to the Semantic Versioning Specification. You also have the option to specify a version name to help identify the version or align with your organization's version naming conventions.

All new object versions are created in Draft state. Only object versions in Draft state can be edited. If you need to update a Released object, it is best-practice to create a new version of the object. When you create a new version, you can duplicate an existing version and increment the version number or create a completely new version from scratch.

When you add a reference to one object from another, for example, you specify a schema or enumeration that an event depends on or specify an event that an application publishes, you select theobject version that you want to reference. Designer enforces lifecycle state restrictions when you add a reference or change the state of an object to avoid disallowed combinations and ensure that referenced and referencing object versions are in appropriate states. Designer enforces these state relationships for events:

Event version state Referenced schema and enumeration version states Referencing application and event API version states

Draft

Referenced schema and enumeration versions must be in Draft, Released, or Deprecated state.

Referencing application and event API versions must also be in Draft state.

Referenced event versions must be changed out of Draft state before any application or event API version that references it can change to Released state.

Released

Referenced schema and enumeration versions must be in Released or Deprecated state.

An event version can't change from Draft to Released state if a referenced schema or enumeration version is in Draft state.

Referencing application and event API versions can be in any state.

Deprecated

Referenced schema and enumeration versions must be in Released or Deprecated state.

An event version state can't change to Deprecated state if a referenced schema or enumeration version is in Draft state.

Referencing application and event API versions can be in any state.

Retired

Referenced schema and enumeration versions must be in Released, Deprecated, or Retired state.

A schema or enumeration version can't be changed to Retired state unless all event versions that reference it are in Retired state.

Referencing application and event API versions must also be in Retired state.

A referenced event version can't be changed to Retired state unless all application and event API versions that reference it are in Retired state.

Environments

You can create environments in PubSub+ Cloud to represent the operational environments within your organization. For example, you may create multiple development environments, a testing environment, a staging environment, and a production environment that correspond to the product release cycle within your organization.

You create environments at the PubSub+ Cloud account level,. Each account must have at least one environment and can have up to 50 environments. PubSub+ Cloud provides a default environment for each account. For more information, see Environments.

Modeled Event Meshes

A modeled event mesh represents an operational event mesh in a specific runtime environment. They can help you define and visualize event flows between publishing and subscribing applications. You create models of event meshes to align with your operational event meshes or event broker clusters. Each modeled event mesh should represent a set of actual event brokers that can send and receive messages between each other. Solace modeled event meshes generally represent a set of event brokers or event broker services that are interconnected to form an event mesh. Kafka modeled event meshes generally represent a Kafka Cluster.

Each modeled event mesh belongs to a single environment. You create modeled event meshes in Runtime Event Manager. For more information, see Modeled Event Meshes.

Additional Resources