On-premise and Managed Services
Author servlets: infinity.json and QueryBuilder.
An author account the connector can read with.
Dumont for Adobe Experience Manager
AEM content in your search index, the moment it is published
Pages, Content Fragments, Experience Fragments and assets, read through AEM's own APIs and kept in step through replication events. For AEM on-prem, Managed Services, AEM as a Cloud Service and Edge Delivery Services.
Every AEM you might be running
One connector, three deployment models
A source says which AEM it talks to, and the connector reads it the way that deployment allows.
AEM as a Cloud Service
Delivery APIs: model.json for pages, the Content Fragment API, Assets Search.
No author credential.
Edge Delivery Services
The site's query-index.json, and its sitemap if you want it.
The public aem.live address.
What it understands
Built around AEM's content model, not its HTML
Each content kind, read its own way
Pages through model.json, Content Fragments through the Content Fragment API, assets through Assets Search. A source decides per kind, so nothing is scraped that has an API.
AEM as a Cloud Service without an author login
A source can read from the delivery side instead of the author servlets. On-prem and AMS keep infinity.json and QueryBuilder; Cloud Service needs no author credential at all.
Extraction declared per content type
Composable extractors and versioned recipes, chosen by content type and shared across sites. A new site on the same templates is configuration, not a new connector.
Fragments propagate
When a shared Experience Fragment or Content Fragment changes, every page that embeds it is reindexed. The footer edit reaches search the same day it reaches the site.
Three ways to hear about a change
An Adobe I/O Events webhook, an OSGi bundle on the AEM side that sends replication events, and a journal poller that recovers events the other two dropped.
A wizard for the first source
Test the connection, browse the content tree and pick extractors in the console before the first run, instead of writing a configuration file and hoping.
Keeping up
Three ways to hear about a change, so none is the single point of failure
All three feed the same event dispatcher, an unchanged page is skipped by its checksum, and a page none of them reported is caught by the nightly audit.
- 1
Adobe I/O Events
A webhook per source answers the Developer Console's verification challenge and takes publish, modify, unpublish and delete events as they happen. The low-latency path.
- 2
The AEM-side bundle
An OSGi bundle installed in AEM sends page and Content Fragment replication events to Dumont. For instances where Adobe I/O Events is not an option.
- 3
The journal poller
Reads the event journal on a schedule and recovers whatever a push dropped. Off by default; turn it on when a missed event is more expensive than a poll.
# Adobe Developer Console → Events → Webhook URL
POST https://dumont.example.com/api/v2/aem/webhook/{source}
# The AEM-side bundle, or anything else that knows a path changed
POST https://dumont.example.com/api/v2/aem/index/{source}When the event is for a shared Experience Fragment or Content Fragment, Dumont works out every page that embeds it and reindexes those too, so a changed footer or product description reaches search without a full reindex.
What the nightly audit checksPoint it at one source this afternoon.
One container, a console in English or Portuguese, and a dry scan that shows what would be indexed before anything is. Apache 2.0, with the roadmap in the repository.
$
docker run -p 30130:30130 ghcr.io/openviglet/dumont-ce:latest