User-based event filters

Who would benefit?

All customers with data creation and update integrations and portal-centric server extensions.

What impact would it make?

Ability to govern the portal enrichment of data, while facilitating highly performant data imports.

How should it work?

Using REST inbound data as an example:

• When a REST integration uses 10 concurrent requests, we get 10x throughput. We can get 20-30x throughput by saturating the service and managing any 429 errors.

• As soon as we introduce a server extension, this is reduced back to 1x throughput. The server extension is single threaded and negates the benefit of 10 concurrent transactions.

• Server extensions tend to be used to govern portal users. Automated inbound data rarely needs this level of governance as clean data is sent.

• By filtering out the REST user from the server extension, we return to the benefits of concurrent processing. In tests, we have shown a factor of 43x using REST without a server extension.

• It is not sufficient to filter out the user in code; this still requires around 50ms to validate and drop out of the extension.

• This is also a benefit to all other extension types. Again, clean data may not need to be post-processed by entity and channel listeners.

• This facilitates the better organisation of extensions. Where we used to recommend one listener of each type, different processes can now be added as separate extensions, and filter out the irrelevant parts for each inbound process.

Why is it needed?

Would immediately benefit 2 enterprise customers. There will be many other implementations that would benefit by adding the configuration to existing extensions.