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 create and update all of the objects you use to design 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 models of your EDA using objects created in Designer and data collected from your event brokers.
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 represent the elements in a segment of your EDA. Every object in Event Portal 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 with 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 in Event Portal is an object that represents software that produces and consumes events. Within an application, a consumer represents a queue on an event broker or a consumer group in a Kafka event flow. Applications can publish events to be consumed by other applications and can subscribe to events to act on them in some way. To learn about creating and updating applications, see Applications.
Events
In Event Portal, 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.
Every event has one or more topic addresses that define the topics of each event instance at runtime. Topic addresses can include variable values to represent data specific to an event instance. Event brokers use topics to route each event instance to subscribing applications. For more information, see Topic Addresses.
Every 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 to model your events with payloads that are simple primitives and supports more complex schema definitions. To learn about creating and updating events, see Events.
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, Avro, and Protobuf format. Complex schemas can reference other schemas. 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 the object 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 different operational environments within your organization. For example, you may create several development environments for different lines of business, testing environments, a staging environment, and a production environment to correspond with 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 and allow you to audit your designed architecture against runtime data from your event flows. Each modeled event mesh should represent event flows through one or more event brokers that can send and receive event messages. Solace modeled event meshes generally represent a set of event brokers that are interconnected to form an event mesh. Kafka modeled event meshes generally represent a single Kafka cluster. You create modeled event meshes in Runtime Event Manager. For more information, see Designing Modeled Event Meshes.