[
https://issues.apache.org/jira/browse/NIFI-14325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alaksiej Ščarbaty updated NIFI-14325:
-------------------------------------
Description:
A processor responsible for consuming [enterprise
events|https://developer.box.com/guides/events/enterprise-events/]. The API
should be similar to the existing
[CounsumeBoxEvents|https://github.com/apache/nifi/blob/main/nifi-extension-bundles/nifi-box-bundle/nifi-box-processors/src/main/java/org/apache/nifi/processors/box/ConsumeBoxEvents.java].
The difference is between Box Event APIs being used.
h3. Why not enhance the existing processor?
These are 2 similar yet different resources.
*Api difference.* User events are consumed using [long
polling|https://developer.box.com/guides/events/user-events/polling/]. While
Enterprise Events have to be pulled.
*Functionality difference.* User events support no event filtering. While
Enterprise Events do. It also seems User Events with long polling don’t support
consumption from a particular offset.
*Permissions difference.* Enterprise events require very broad Enterprise-wide
permissions. While User events can be consumed with very basic permissions.
Taking all of this into account, it’d be better to distinguish between these 2
use cases and create 2 separate processors.
h3. Input
Forbidden.
h3. Output
|*Relationship Name*|*Description*|
|success|Events received successfully will be sent out this relationship.|
h3. Parameters
|*Name*|*Description*|*Example Value*|
|Box Client Service|Controller Service used to obtain a Box API
connection.|[BoxClientService instance]|
|Stream Type|A Type of Box Enterprise Events Stream to consume data from.
_Supported values = \{admin_logs, admin_logs_streaming}._|admin_logs_streaming|
|Event Types|A comma separated list of Enterprise Events to consume. See
supported Event Types in [Box
documentation|https://developer.box.com/guides/events/enterprise-events/for-enterprise/#event-types].|COLLABORATION_ACCEPT,DELETE,GROUP_ADD_USER|
|Start Event Position|What position to consume the Events from. _Supported
values = \{earliest, latest, a numerical stream_position value}._|earliest|
|Record Writer|A Record Writer to use for serializing Records to an output
FlowFile. If not specified, one FlowFile will be created for each Event that is
captured. If the Record Writer is specified, all Events will be written to a
single FlowFile instead of adding attributes to individual
FlowFiles.|[RecordSetWriterFactory instance]|
was:
A processor responsible for consuming [enterprise
events|https://developer.box.com/guides/events/enterprise-events/]. The API
should be similar to the existing
[CounsumeBoxEvents|https://github.com/apache/nifi/blob/main/nifi-extension-bundles/nifi-box-bundle/nifi-box-processors/src/main/java/org/apache/nifi/processors/box/ConsumeBoxEvents.java].
The difference is between Box Event APIs being used.
h3. Why not enhance the existing processor?
These are 2 similar yet different resources.
*Api difference.* User events are consumed using [long
polling|https://developer.box.com/guides/events/user-events/polling/]. While
Enterprise Events have to be pulled.
*Functionality difference.* User events support no event filtering. While
Enterprise Events do. It also seems User Events with long polling don’t support
consumption from a particular offset.
*Permissions difference.* Enterprise events require very broad Enterprise-wide
permissions. While User events can be consumed with very basic permissions.
Taking all of this into account, it’d be better to distinguish between these 2
use cases and create 2 separate processors.
h3. Input
Forbidden.
h3. Output
|*Relationship Name*|*Description*|
|success|Events received successfully will be sent out this relationship.|
h3. Parameters
|*Name*|*Description*|*Example Value*|
|Box Client Service|Controller Service used to obtain a Box API
connection.|[BoxClientService instance]|
|Stream Type|A Type of Box Enterprise Events Stream to consume data from.
_Supported values = \{admin_logs, admin_logs_streaming}._|admin_logs_streaming|
|Event Types|A comma separated list of Enterprise Events to consume.
See supported Event Types in [Box
documentation|https://developer.box.com/guides/events/enterprise-events/for-enterprise/#event-types].|COLLABORATION_ACCEPT,DELETE,GROUP_ADD_USER|
|Start Event Position|What position to consume the events from.
_Supported values = \{earliest, latest, a numerical stream_position
value}._|earliest|
|Record Writer|A Record Writer to use for serializing Records to an output
FlowFile.
If not specified, one FlowFile will be created for each Event that is captured.
If the Record Writer is specified, all Events will be written to a single
FlowFile instead of adding attributes to individual FlowFiles.
|[RecordSetWriterFactory instance]|
> Create ConsumeBoxEnterpriseEvents processor
> -------------------------------------------
>
> Key: NIFI-14325
> URL: https://issues.apache.org/jira/browse/NIFI-14325
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Extensions
> Reporter: Alaksiej Ščarbaty
> Assignee: Alaksiej Ščarbaty
> Priority: Major
>
> A processor responsible for consuming [enterprise
> events|https://developer.box.com/guides/events/enterprise-events/]. The API
> should be similar to the existing
> [CounsumeBoxEvents|https://github.com/apache/nifi/blob/main/nifi-extension-bundles/nifi-box-bundle/nifi-box-processors/src/main/java/org/apache/nifi/processors/box/ConsumeBoxEvents.java].
> The difference is between Box Event APIs being used.
> h3. Why not enhance the existing processor?
> These are 2 similar yet different resources.
> *Api difference.* User events are consumed using [long
> polling|https://developer.box.com/guides/events/user-events/polling/]. While
> Enterprise Events have to be pulled.
> *Functionality difference.* User events support no event filtering. While
> Enterprise Events do. It also seems User Events with long polling don’t
> support consumption from a particular offset.
> *Permissions difference.* Enterprise events require very broad
> Enterprise-wide permissions. While User events can be consumed with very
> basic permissions.
> Taking all of this into account, it’d be better to distinguish between these
> 2 use cases and create 2 separate processors.
> h3. Input
> Forbidden.
> h3. Output
> |*Relationship Name*|*Description*|
> |success|Events received successfully will be sent out this relationship.|
> h3. Parameters
>
> |*Name*|*Description*|*Example Value*|
> |Box Client Service|Controller Service used to obtain a Box API
> connection.|[BoxClientService instance]|
> |Stream Type|A Type of Box Enterprise Events Stream to consume data from.
> _Supported values = \{admin_logs,
> admin_logs_streaming}._|admin_logs_streaming|
> |Event Types|A comma separated list of Enterprise Events to consume. See
> supported Event Types in [Box
> documentation|https://developer.box.com/guides/events/enterprise-events/for-enterprise/#event-types].|COLLABORATION_ACCEPT,DELETE,GROUP_ADD_USER|
> |Start Event Position|What position to consume the Events from. _Supported
> values = \{earliest, latest, a numerical stream_position value}._|earliest|
> |Record Writer|A Record Writer to use for serializing Records to an output
> FlowFile. If not specified, one FlowFile will be created for each Event that
> is captured. If the Record Writer is specified, all Events will be written to
> a single FlowFile instead of adding attributes to individual
> FlowFiles.|[RecordSetWriterFactory instance]|
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
