[
https://issues.apache.org/jira/browse/NIP-7?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Handermann resolved NIP-7.
--------------------------------
Resolution: Fixed
> Add Flow Action Reporter as Framework Extension
> -----------------------------------------------
>
> Key: NIP-7
> URL: https://issues.apache.org/jira/browse/NIP-7
> Project: NiFi Improvement Proposal
> Issue Type: New Feature
> Reporter: David Handermann
> Assignee: David Handermann
> Priority: Major
>
> h1. Motivation
> The framework
> [AuditService|https://github.com/apache/nifi/blob/main/nifi-framework-bundle/nifi-framework/nifi-administration/src/main/java/org/apache/nifi/admin/service/AuditService.java]
> interface supports storage and retrieval of Flow Configuration History
> Actions using a local persistence implementation based on JetBrains Xodus.
> The implementation supports viewing changes within the NiFi application using
> the Flow Configuration History screen, but does not provide an option to send
> Action information to other destinations at the time the Action occurs.
> Introducing a new Flow Action Reporter interface as a framework extension
> interface would support external tracking through custom solutions. The Flow
> Action Reporter interface should be limited to receiving flow action objects,
> supporting external export of Flow Configuration History. A new framework
> extension enables low-latency export of security-relevant events with a
> narrow set of application changes required.
> h1. Scope
> The new Flow Action Reporter interface should be defined in the
> {{nifi-framework-api}} module as opposed to the {{nifi-api}}. The
> {{nifi-framework-api}} does not have the same level of compatibility
> requirements as the public {{nifi-api}}, but provides sufficient stability of
> framework components. The Flow Action Reporter would follow the same pattern
> as the Status History Repository and Authorizer interfaces, both of which are
> located in the {{nifi-framework-api}}. Defining the Flow Action Reporter
> interface as an extension will require changes to extension loading, and
> adjustments to {{AuditService}} references.
> The {{Action}} interface includes the authenticated user identity, but does
> not include additional details from the HTTP request, such as the client
> address or user agent. This information is important to provide a complete
> description of the context related to flow configuration changes. The
> {{nifi-web-security}} module builds on Spring Security and makes some of the
> HTTP information available, requiring additional changes to support
> associating Flow Actions with HTTP request attributes.
> h1. Compatibility
> Introducing the Flow Action Reporter as a new framework extension will
> maintain compatibility with existing deployments and will not require a new
> major version. The default behavior will continue to work based on the
> JetBrains Xodus repository without requiring any new configuration properties.
> h1. Description
> The Flow Action Reporter interface should be defined in the
> {{nifi-framework-api}} module and support the following minimum methods:
> 1. void onConfigured(FlowActionReporterConfigurationContext context)
> 2. void reportFlowActions(Collection<FlowAction> flowActions)
> 3. void preDestruction()
> The {{onConfigured()}} method enables implementations to initialize
> collaborating components, such as network client services. The
> {{preDestruction()}} method enables implementations to close network client
> services or other resources. The {{FlowActionReporterConfigurationContext}}
> should include a method for retrieving an optional {{SSLContext}} loaded from
> application security properties, enabling TLS communication with external
> services when required.
> The {{reportFlowActions()}} method serves as the primary method for receiving
> Flow Actions. The method does not return any status or support any checked
> exceptions, indicating that the framework does not support tracking or
> retrying action reporting. The {{FlowAction}} object should be defined in the
> {{nifi-framework-api}} as an interface similar to the {{Action}} interface in
> {{nifi-api}}. The {{FlowAction}} interface should include additional
> properties for relevant HTTP request information, and provide a more generic
> structure for Action Details as opposed to the current class and subclass
> hierarchy. Following an approached based on a Map aligns with other
> conventions like FlowFile attributes, making it easier for implementations to
> handle new properties. The framework implementation will be responsible for
> translating {{Action}} objects to {{FlowAction}} objects prior to calling
> {{reportFlowActions()}}.
> Instances of the Flow Action Reporter will be loaded using standard NAR
> bundle packaging.
> The Flow Action Reporter will be configured using a new application property
> in {{nifi.properties}} that specifies the full class name to be loaded.
> h1. Verification
> Verifying the changes should include a combination of unit tests and system
> tests. Unit tests should cover localized behavior changes, and a new system
> test should exercise a custom implementation.
> h1. Alternatives
> The first alternative to a narrow Flow Action Reporter is a complete Flow
> Action Repository extension. This approach would follow the pattern of other
> Repository extension interfaces, but would require more substantial work to
> implement a custom solution. Managing the lifecycle of Flow Actions requires
> additional resource considerations, outside the scope of simple reporting.
> Although custom repository implementations could chose not to implement
> certain methods, such an approach would break the behavior of the Flow
> Configuration History screen and corresponding REST API. Introducing the
> scoped Flow Action Reporter does not preclude future improvements to support
> a complete Flow Action Repository.
> The second alternative to a new Flow Action Reporter is using a custom
> Reporting Task to retrieve flow changes. Although this approach could be
> implemented as an extension within current framework capabilities, it has
> several limitations. The Flow Configuration History allows an authorized user
> to purge the history, which could cause a Reporting Task to miss relevant
> actions. In addition, a Reporting Task requires periodic invocation,
> introducing potential latency for action reporting. Reporting Tasks are also
> user-facing extensions as opposed to framework extensions. With the goal of
> externalized action tracking, a framework extension provides better alignment
> as an infrastructure concern.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
