This page provides a brief overview how Event Portal Objects and AsyncAPI representing an Application Registration are mapped to a PubSub+ broker
Broker Object to EP / Mapping
Config Element | EP Developer App Object Mappings |
---|---|
All Elements - Target Brokers | · Applicable brokers are identified from the EAP Version associated with the App Registration· Taking the Access Request status into account - only EAP that are associated via an APPROVED or LIVE access request are relevant |
Client Profile | Client Profile is selected from a list of presets based on this criteria: EAP Plans associated with the App Registration: guaranteed messaging The events associated with the app registration - if a plan has guaranteed determine if client needs to publish and/or consume guaranteed message. * The protocols associated with the app registration - MQTT requires endpoint creation privilege.See diagram below for the selection rules |
ACL | · App Registration - registrationId becomes the ACL name |
ACL Subscribe Topic Exception ACL Publish Topic Exception | · All Events' topics associated to App Registration · Of access requests that are APPROVED or LIVE · Traversing EAP and Event APIs to find all applicable topics · Replacing parameters in topics with enum values, filters or wildcards (*, >) |
Authorisation Group | · App Registration - registrationId becomes the authorisation group name, references the ACL (again using the registrationId) and client profile (as selected before) |
Client Username | · App Registration’s credentials objects become clientUsername and password· References aclProfileName (registrationId) and clientProfileName (from the selected client profile) |
MQTTSession | · If the App Registration is associated with MQTT protocol via an APPROVED or LIVE access request and the EAP Version· mqttSessionClientId is the registrationId, owner a credential username from the app registration · If an associated EAP Version plan requires guaranteed messaging queue settings are derived from the plan - newSession.queueMaxTtl - the highest TTL of all associated plans newSession.queueMaxMsgSpoolUsage - the aggregate of all spool sizes of all associated plans newSession.queueRespectTtlEnabled - set to true if any associated plan specifies a TTL |
Queue | · The plans associated determine the number of queues to be created (one per EAP, one per API) and the scope of the queue determines the name of the queue · Queues are only created if there are applicable subscriptions (see below) · Queue Names: Per API Product: ${app.registrationId}/${eventApiProduct.id}/${plan.id} Per API: ${app.registrationId}/${eventApiProduct.id}/${plan.id}/${api} · Queue Properties: queueName: as derived from the EAP plans queue scope owner: username from the app registration accessType: as defined in the plan maxTtl: plan.solaceClassOfServicePolicy.maximumTimeToLive maxMsgSpoolUsage: plan.solaceClassOfServicePolicy.maxMsgSpoolUsage respectTtlEnabled: true if (plan.solaceClassOfServicePolicy.maximumTimeToLive > 0) |
Queue Subscriptions | · All Events' topics associated to App Registration · That client can SUBSCRIBE to (AsyncAPI that is PUBLISHED to the client) · Of access requests that are APPROVED or LIVE · Traversing EAP and Event APIs to find all applicable topics · Replacing parameters in topics with filters or wildcards (*, >) |