New Slack forwarder, stream state clearing, and TLS enforcement for Email functions
We have added four new updates to UsageCloud: a new Slack forwarder function, the ability to clear a stream's stateful data, enforced TLS for the Email functions, and expanded Bearer token authentication support in the HTTP Client functions. These updates give you more ways to integrate, iterate, and secure your streams.
Slack forwarder
With the Slack forwarder function, you can post notification messages to a Slack channel directly from a stream, using a Slack incoming webhook. Use it to notify your team when a stream run completes, when a transaction finishes, or for individual records, without building a custom HTTP integration. Each webhook posts to a single channel, so add one Slack forwarder function per channel you want to notify.
For more information, see https://infozone.atlassian.net/wiki/x/EgBdZ.
Clear
The new Clear action resets all of a stream's stateful data, including deduplication history, open aggregation sessions, suspended Data correction records, and collector checkpoints, in a single action. This makes it much faster to reset a stream to a clean state while developing or testing, instead of manually deleting and reconfiguring each stateful function. Clear is currently available by request in non-production environments only. To request access, raise a support request through the https://digitalroute.my.site.com/s/.
For more information, see Clear.
Bearer token authentication in HTTP client functions
Bearer token authentication is now available to all users as a grant type when you select OAuth 2.0 as the authentication type in the HTTP client collector, processor, and forwarder functions. You can use a static bearer token, stored as a Global parameter, to connect to third-party servers that require it. Automatic token renewal does not apply to this grant type, so you need to keep the token valid yourself.
For more information, see HTTP client OAuth 2.0 authentication.
TLS enforcement in Email functions
Following our earlier notice in https://infozone.atlassian.net/wiki/x/BIAzYg, TLS enforcement for the Email notification and Email attachment functions is now in effect. Port 465 always uses implicit TLS and port 587 always uses STARTTLS; port 25 is no longer supported, and there is no fallback to an unencrypted connection if your SMTP server does not support the expected TLS mode. If you have not already checked your SMTP server's TLS support on port 465 or 587, we recommend doing so to avoid stream failures.
For more information, see Email notification and Email attachment.
We hope you enjoy these additions. As always, we appreciate your feedback. If you have any questions or concerns, please do not hesitate to reach out to us through the https://digitalroute.my.site.com/s/.