What are Application Events and how can I use them?

It is now possible to send events using existing Notification Drivers from a single configuration, without the need of having to set up Notifications for every single Application. 

You do not need to know or provide any technical configuration. The oh22 admin team will add the settings to the app config. You only need to tell them what data to use.

What to send to the oh22 Admin Team

Which provider/s should receive the events

Choose one or more:

• Azure Event Grid
• 
  
• Email (requires an email server to be configured)
• HTTP (webhook)
• MS SQL

Which events should be sent

Provide either/both:

• Whitelist: events that should be sent (e.g. ["Import.Started", "Import.Persisted"])
• Blacklist: events that should not be sent (e.g. ["Application.Deleted", "Application.Updated"])

Wildcards can be used (e.g. ["Application.*", "Import.*"]).
See the full list of events at the bottom.

Provider-specific data (what you must supply)

Azure Event Grid

• Endpoint URL
• Event schema: CloudEvent or Custom
• Event type (or say “use the event-specific type/name”)
• Authentication choice:
  • Application Service Principal
  • Custom Service Principal (tenantId, clientId, clientSecret)
  • Access Key (accessKey)
• Optional: custom body/payload requirements (or “use default payload”)

Databricks

• SQL
  - SQL Query
• Notebook
  - Notebook Path
  - Parameters
• Job
  - Job Id
  - Parameters

Email

• To (recipient email)
• Subject
• Body text (optionally mention which event fields should be included)

HTTP

• URL
• Method (GET/POST/PUT/PATCH/DELETE)
• Headers (optional)
• Body (JSON or text; optionally mention which event fields should be included)

MS SQL

• Connection target (connection string or where admins can find it)
• SQL command to execute (optionally mention which event fields should be used)

Payload/body (optional)

This will be the message transmitted via Event in the case of every event type except Databricks and MS SQL. You can generate one in the Notification form inside WOODY.IO, using the appropriate tokens and paste it in the request.

Copy/paste request template

• Providers: <...>
• Whitelist: [...]
• Blacklist: [...]
• Provider details: (from the relevant section above)
• Payload/body: default or custom: (from the relevant section above)

Basically, you want to use the same information/data that you would use to create a per-app notification, with the difference that you can send us a Whitelist and/or Blacklist of events and more than one provider, so that the events can be propagated to multiple destinations.

Event Types:

• Application.Created

• Application.Deleted

• Application.Updated

• Metamodel.Created

• Metamodel.Deleted

• Metamodel.Published

• Metamodel.Updated

• Import.New

• Import.Loading

• Import.ErrorLoading

• Import.Loaded

• Import.ReadyToValidate

• Import.Validating

• Import.Valid

• Import.Invalid

• Import.Adjusting

• Import.WaitingForApproval

• Import.Approved

• Import.Declined

• Import.ReadyToPersist

• Import.Persisting

• Import.Persisted

• Import.ErrorPersisting

• Import.ReadyForCleanup

• Import.Cleaning

• Import.Cleaned

• Import.ErrorCleaning

• Import.WaitingForComment

• Import.Information

• Import.Comment

Key Vault Reference Supported Fields

WOODY.IO now supports Key Vault references, which means that for sensitive information, you can instead send us a Key Vault reference, if you have a Key Vault already configured in WOODY.IO. See the following article on how to configure and use Key Vaults.

Azure Event Grid

• Endpoint
• Tenant ID
• Client ID
• Client Secret
• Access Token

HTTP Request

• Url
• Headers

Email

• 'To'

Send any information via a secure channel (for example, email within the customer domain) to a member of the oh22 team.

We are working on improving this process.

If you have any further questions, please feel free to Contact Us.