Events

Interfaces to simplify the implementation of event-handling using pyatlan:

AtlanEventHandler

An interface you can implement to split the overall functionality required for an event processor down into small pieces:

class pyatlan.events.atlan_event_handler.AtlanEventHandler(client: AtlanClient)

calculate_changes(current_view: Asset) → List[Asset]

Calculate any changes to apply to assets, and return a collection of the minimally-updated form of the assets with those changes applied (in-memory). Typically, you will want to call trim_to_required() on the current_view of each asset before making any changes, to ensure a minimal set of changes are applied to the asset (minimizing the risk of accidentally clobbering any other changes someone may make to the asset between this in-memory set of changes and the subsequent application of those changes to Atlan itself). Also, you should call your has_changes() method for each asset to determine whether it actually has any changes to include before returning it from this method. NOTE: The returned assets from this method should be ONLY those assets on which updates are actually being applied, or you will risk an infinite loop of events triggering changes, more events, more changes, etc.

Parameters:

current_view – the current view / state of the asset in Atlan, as the starting point for any changes

Returns:

a list of only those assets that have changes to send to Atlan (empty, if there are no changes to send)

get_current_state(from_event: Asset) → Asset | None

Retrieve the current state of the asset, with minimal required info to handle any logic the event handler requires to make its decisions. This default implementation will only really check that the asset still exists in Atlan.

Parameters:

from_event – the asset from the event (which could be stale at this point)

Returns:

the current state of the asset, as retrieved from Atlan

has_changes(current: Asset, modified: Asset) → bool

Check the key information this event processing is meant to handle between the original asset and the in-memory-modified asset. Only return true if there is actually a change to be applied to this asset in Atlan - this ensures idempotency, and avoids an infinite loop of making changes repeatedly in Atlan, which triggers a new event, a new change, a new event, and so on. This default implementation only blindly checks for equality. It is likely you would want to check specific attributes’ values, rather than the entire object, for equality when determining whether a relevant change has been made (or not) to the asset.

Parameters:

• current – the current view / state of the asset in Atlan, that was the starting point for any change calculations

• modified – the in-memory-modified asset against which to check if any changes actually need to be sent to Atlan

Returns:

True if the modified asset should be sent on to (updated in) Atlan, or False if there are no actual changes to apply

save_changes(changed_assets: List[Asset])

Actually send the changed assets to Atlan so that they are persisted.

Parameters:

changed_assets – the in-memory-modified assets to send to Atlan

upsert_changes(changed_assets: List[Asset])

Deprecated — send the changed assets to Atlan so that they are persisted. Use ‘save_changes’ instead.

Parameters:

changed_assets – the in-memory-modified assets to send to Atlan

validate_prerequisites(event: AtlanEvent) → bool

Validate the prerequisites expected by the event handler. These should generally run before trying to do any other actions. This default implementation will only confirm that an event has been received and there are details of an asset embedded within the event.

Parameters:

event – the event to be processed

Returns:

True if the prerequisites are met, otherwise False