Applications

An application in Event Portal represents a client application connecting to an event broker to publish or consume events. A client application may be a program, process, microservice, IoT device, integration component, or other runnable consumer or producer of events that interacts with an event broker. Applications in Designer can represent two types of objects on an event broker:

Standard Applications

A standard application in Designer represents a client application that connects to an event broker to publish or consume event messages. You can create standard applications for Solace or Kafka event brokers. For more information, see:

• Creating and Managing Standard Solace Applications
• Creating and Managing Kafka Applications

REST Delivery Points (RDPs)

An RDP application in Designer represents an RDP object provisioned on a Solace event broker. An RDP is a type of webhook that binds to a queue and provides a connection between the event broker and one or more REST endpoints to enable REST applications to consume Guaranteed messages from the queue. For more information, see Creating and Managing RDPs (Webhooks).

You can also import Solace queues and Kafka consumer groups from operational event brokers to add standard applications to Designer. For more information, see Importing Runtime Objects into Event Portal.

If you have runtime configuration fully set up for a Solace event broker, the application, queue, and REST consumer details you configure in an application are pushed to the operational event broker after you promote the application to a modeled event mesh. For more information about setting up and using runtime configuration from Event Portal, see Configuring Event Brokers in Event Portal. Runtime configuration is not supported for Kafka event brokers.

This section includes the following information:

• Considerations for Creating and Managing Applications
• Updating and Adding Application Versions
• Changing the State of an Application Version
• Promoting Applications to Environments

You can move applications to other application domains. For more information, see Moving Objects Between Application Domains.

You can create custom attributes for applications. For more information, see Using Custom Attributes.

Considerations for Creating and Managing Applications

Event Flows

Event flows specify events that are published and consumed (subscribed to) by an application. We recommend creating events in Designer before applications so you can design the event flow when you create the application.

When you design event flows for applications, you have the following options:

• Specify events that the application publishes. (Standard applications only; RDPs can only subscribe to events.)

• Specify events that the application intends to subscribe to. Identifying the intent before configuring consumers is helpful in these ways:

  • It flags the event in the modeled event mesh if no application publishes it.
  • It flags the application in the modeled event mesh if no consumer is configured to attract the event.
  • It enables Event Portal to help you create the consumer and topic subscription.
  • It includes the application when calculating the event reuse index in KPI Dashboard.

• Specify consumers that subscribe to the event in the runtime to attract the event to application. The type of consumer depends on the application type;

  • Event Queue—Represents a queue on a Solace event broker that attracts Guaranteed messages with topic subscriptions. The runtime application binds to the queue to consume messages. RDPs must bind to a Solace event queue; they don't support Direct messaging.
  • Direct Client—Represents a direct connection between an application and a Solace event broker that attracts Direct messages with topic subscriptions but does not store messages while the consumer is offline or reconnecting.
  • Kafka Consumer—Represents a consumer group in a Kafka cluster that subscribes to topics.

• You can specify a link between two applications without specifying an event flow. These links help you show a source and destination relationship between two applications in the graph view but do not make any changes to event brokers if runtime configuration is enabled. When you add an RDP application, a linked application is automatically added to represent the destination REST application in the graph.

Runtime Configurations

If you intend to push application details and queue configurations from Event Portal to your operational event brokers be aware of the following considerations:

• You enable runtime configuration at the environment level. Event Portal can update your operational event brokers automatically when you promote an application to an environment, or on demand when triggered using an Event Portal REST API. Your organization can also choose to use your own CI/CD processes to push configurations to operational event brokers. For more information, see Setting Event Portal Runtime Configuration Options.

• If runtime configuration is enabled, each Solace event queue consumer you create for an application configures a queue on the runtime event broker. Queue names must be unique on the event broker.

• You can provide queue configuration in JSON format in the Solace event queue consumer. Users with the Event Portal Manager role can create Solace queue templates in Runtime Event Manager to help users quickly configure the appropriate settings.

• If you create a Solace direct client consumer the topic subscription creates a subscribe topic exception in an ACL profile on the event broker to allow the client application to receive messages for the topic.

• If the application publishes events, the event topic creates a publish topic exception in an ACL profile to allow the client application to publish messages to the topic.

• You can specify the name of the client profile on the event broker that applies to the client application when it authenticates with the event broker. Client profiles assign a common set of configuration properties to client applications. Users with the Event Portal Manager role can create Client Profile Name templates in Runtime Event Manager to specify the client profiles available on your event brokers and require users to select from a list of names when configuring the application in Designer. For more information about managing client profiles on event broker services, see Using Client Profiles and Client Usernames.

• You must provide the client credentials that the application uses to connect to the event broker. The client username you specify is the owner for any queues created for the application on the event broker.

• When you create an RDP, in addition to an event queue, you must also specify the queue binding and connection details for the REST consumer object on the event broker that enable it to send messages to the REST application.

• For more information about setting up runtime configuration, see Configuring Event Brokers in Event Portal.

Shared Event Access and Approval

Applications can publish or subscribe to events in other application domains only if the events are allowed to be shared. Shared events may also require approval.

• If an application publishes or consumes an event that it does not have approval for, a banner appears at the top of the Application Details page. An application must get approval to access an event when all of these conditions are true:

  • The event's Access Approval option is set to Requires Approval.
  • The application and the event that requires approval are located in different application domains.
  • The application publishes the event that requires approval or the application attracts the event through a consumer with an appropriate subscription.
• All event access requests must be approved before the application can be promoted to an environment. For more information about requesting event access, see Managing Event Data Access.
  

Creating Applications

For information about creating applications, see one of the following:

• Creating a Standard Solace Application
• Creating an RDP
• Creating a Kafka Application

Updating and Adding Application Versions

Applications and other objects you create in Designer can have multiple versions. When you update an application, you can update an existing version or create a new version of the application. Versions allow you to work on updates and test new versions in development and staging environments while the stable version remains in the production environment. Each version has a lifecycle state. For more information, see Object Versions and Lifecycle States.

Object version numbers use semantic versioning in the format major.minor.patch. You can update object versions only when they are in draft state. If you want to update a version that is in Released, Deprecated, or Retired state, it is best practice to duplicate the version to create a new Draft version rather than returning the existing version to Draft state.

When you reference an object, for example, you specify the schema that an event uses or an event that an application publishes, you select the version of the object that you want to reference. If a new version of a referenced object is created, the reference does not update automatically. You can choose when to update references to the new version.

The graph view displays the most recent non-retired version of an application. If you create a new version, the new version takes the place of the previous version in the graph and the displayed event flows change if the new application version is not associated with the same event or application versions.

If allowed for objects in the application domain, the description of an application version can be edited at any lifecycle state. This option allows you to add information to the description at a later time, such as deprecation and retirement dates and notes about the object's functionality or runtime behavior.

For help updating existing application versions see one of the following:

• Updating Standard Solace Applications in the Component View
• Updating an RDP in the Component View
• Updating a Kafka Application in the Component View

Changing the State of an Application Version

When you create a new version of an application, the version is in Draft state. When the version is ready, you can change the version state to Released. When you release a new version of an application, you may also want to change older versions of the application to Deprecated or Retired. You must have at least Manager level access to the application domain to change the version state of an object. For more information about version states, see Object Versions and Lifecycle States.

You can only change an application version from Draft to Released state if no event versions that the application references are in Draft state.

You can change the state of the most recent version in the graph view. If you change the state to Retired, the version disappears from the graph, and is replaced by the latest non-retired version.

To change the state of an application version, perform these steps:

1. Log in to the PubSub+ Cloud Console if you have not done so yet. The URL to access the Cloud Console differs based on your authentication scheme. For more information, see Logging In to the PubSub+ Cloud Console.
2. On the navigation bar, select Designer .
3. On the Application Domains page, click the application domain that contains the application you want to update.
4. Right-click the application in the graph view and select Manage Lifecycle.
5. Select the new state.
6. (Optional) if you selected Deprecated or Retired, specify the End of Life Date.
7. Click Save.

Promoting Applications to Environments

Environments in PubSub+ Cloud represent the operational environments within your organization. In Event Portal you create modeled event meshes within environments to represent event flows through one or more operational event brokers. When you promote an application to an environment, you add a version of the application to a model event broker in a modeled event mesh. For more information about environments, see Creating and Managing Environments.

Be aware of the following considerations when you promote application versions to environments:

Environment Considerations

• To promote an application, you must have at least Editor level access to both the application domain for the application and the environment.

• The environment must have at least one modeled event mesh of the same type as the application (Solace or Kafka) and the modeled event mesh must have at least one model event broker. For more information about creating and updating modeled event meshes, see Modeled Event Meshes.

• If an application references an event that requires approval, a banner appears on the application details page. All event access requests must be approved before the application can be promoted to an environment. For more information, see Requesting Event Access.

• Only one version of an application can be associated with an event broker. If you promote a new version of an application to an event broker while another version is associated with it, the previously promoted version is replaced with the new version.

• You can promote application versions to more than one model event broker. For example, you may have a released version of an application in a production environment and an updated draft version in two different model event brokers in a development environment.

• You can promote application versions in any lifecycle state.

• When you promote an application, if there are any discrepancies between the declared event versions that the application intends to subscribe to and the events attracted by consumer subscriptions for the application, or if no application in the environment publishes a subscribed event, a message displays and allows you to view the list suggestions to fix the discrepancies. You don't need to fix the issues to promote the application. After you promote the application, warnings may display in the graph view in Runtime Event Manager.

Runtime Configuration Considerations

The following considerations apply when you have enabled runtime configuration for the environment and you are using Event Portal to configure endpoints and clients on event brokers. Runtime configuration is supported only for PubSub+ Cloud event broker services and Solace software event brokers and appliances.

• You can enable runtime configuration to occur automatically when you promote an application or on demand when triggered using an Event Portal REST API. Your organization can also choose to use your own CI/CD processes to push configurations to operational event brokers. For more information, see Setting Event Portal Runtime Configuration Options.

• When you promote an application to a model event broker that is connected to an operational event broker configuration details such as Solace event queues, ACL profiles, client usernames, and client credentials can be pushed to the operational event broker. RDP applications also send REST consumers and queue bindings. For more information about the application details sent, see How Application Settings are Applied to Event Brokers.

• Your Middleware Integration team must still configure the event broker, including client profiles, management and messaging authentication, uploading certificates, and other settings that apply to the event broker or Message VPN. You configure only the settings for endpoints and clients from Event Portal.

• You must select how the client application authenticates with the event broker for messaging access and provide the credentials required by the client application. The authentication type your application uses for messaging (basic authentication, LDAP group, OAuth group, or certificate-based) must already be configured on the event broker. For more information about configuring authentication for event broker services, see Configuring Authentication for Messaging Clients.

• We recommend following best security practices for event broker access and authentication and disabling basic authentication for messaging access to the Message VPN if you have a more secure method configured.

• If using a Solace queue template is required for the environment, you must use an allowed template for all queue configurations to be able to promote the application to the environment. For more information about Solace queue templates, see Creating Solace Queue Templates.

• You can specify the name of the client profile on the event broker that applies to the client application. Client profiles are configured on the event broker to assign a common set of configuration properties to a client. Users with the Event Portal Manager role can add Client Profile Name templates in Runtime Event Manager to specify the client profiles available on your event brokers and require users to select from a list of profile names when configuring the application.

  If a client profile name template is required for the environment, you must use an allowed template for the client profile name to be able to promote the application to the environment.

• For more information about setting up runtime configuration, see Configuring Event Brokers in Event Portal.

• After configuration is pushed to the event broker, you can see your updated queues, ACLs, and RDPs on the event broker in PubSub+ Broker Manager. For more information, see:

  • Configuring Queues
  • Controlling Client Access with ACL Profiles
  • Creating REST Delivery Points

• For help promoting applications, see:

  • Promoting a Standard Application to an Environment
  • Promoting an RDP to an Environment
  • Promoting a Kafka Application to an Environment