| Request for Feature Enhancement (RFE) Summary: |
The existing aem-event-proxy-skyline source code distribution enforces assumptions that are incompatible with many potential use cases, and future development in this direction should relax these constraints on AEM's role as an Adobe I/O event producer. |
| Use-case: |
* Developers should be empowered to fire custom Adobe I/O events from publishers, directly from custom servlet code. For example, POST requests from customers containing PII that must be sent to an Adobe I/O runtime for correlation with anonymized aggregate metrics from Analytics.
* In a a multisite hosting scenario, it is plausible that a Firefly App would be deployed to the organization that is only interested in consuming events originating from a particular regional site, without having to introspect the event payload to determine if the associated request resource actually maps to the appropriate domain. Of course, this is an established pattern for Analytics and Target cloud service integrations in AEM already.
* AEM developers working on site functionality should be able to iterate together with Project Firefly developers to evolve event payload formats without being forced to conform to XDM activity stream types. |
| Current/Experienced Behavior: |
* IMS Configurations cannot be replicated to publishers, even though system user nodes and keystores are replicable.
* (Aem-event-proxy) Workspace configuration is not runtime configurable.
* (Aem-event-proxy) Adobe I/O integration in publish environment is not supported and not enabled with distributed sources.
* (Aem-event-proxy) Only one adobe I/O configuration is supported for the environment
* (Aem-event-proxy) For custom events, API client code must flatten complex event payloads to the OSGi event structure, with no synchronous feedback. |
| Improved/Expected Behavior: |
* All Adobe I/O Configuration and IMS Configuration active in the publish environment should be modifiable at runtime by users authorized to use the Configuration Browser and IMS Technical Accounts consoles, respectively, in the author environment.
* AEM should allow users to create multiple Adobe I/O Configurations (and their associated IMS Configurations and CSM registrations) and should support context-aware association to zero-or-more content trees.
* CSM registration should be a deterministic activity occurring on the author environment, with the registration status of an Adobe I/O Configuration made visible to the user, and with reasonable ability to change labels and descriptions of the registration to support better management of integrations across the organization.
* Due to the synchronous nature of a servlet execution, the API provided by the native integration should support synchronous feedback to the servlet for the backend submission to eventsingress, in case the the request should be reattempted by the client. In other words, the AEM integration should not add an asynchronous layer like Sling Jobs, unless this behavior in the context of AEM is specifically desired by the client.
* XDM Schema Event mapping should be a feature available in the API, but not required by the fundamental postEvent method signature. |
| Environment Details (AEM version/service pack, any other specifics if applicable): |
Skyline |
| Customer-name/Organization name: |
Bounteous |
| Screenshot (if applicable): |
|
| Code package (if applicable): |
|
