4 berichten getagd met "OpenConnector"

OpenConnector is the integration engine for Conduction apps. Where OpenRegister stores the data you own, OpenConnector reaches out to data you do not — a case-management API, an open-data portal, a partner's REST service — and pulls it into a register on a schedule, reshaped to fit your own schema. It does this without a line of integration code: you describe where the data lives, how a record should be reshaped, and what should run, and OpenConnector does the fetching, the transforming, the writing and the deduplicating for you.

This tutorial fills the Pet Store register you built in Part 1 from a real, public, external API — the Swagger Pet Store. You register that API as a source, test it, write a Twig mapping that turns an external pet into a pet-academy object and test the mapping against a sample record, build a synchronisation that ties it all together, run it for real to create pets in your register, and schedule it so it keeps the register current. No code, no cron file, no glue.

The first three parts of this series set up the registers, the files, and a public catalog for Dutch open-government data. Conduction also has a three-tutorial pipeline that teaches the same three apps from the ground up, end to end, on the canonical Pet Store sample:

1. Model and manage your data with OpenRegister — registers, schemas, relations, objects, search, versioning, permissions.
2. Pull external data into your register with OpenConnector — a source, a mapping, and a scheduled synchronisation.
3. Publish a public catalog with OpenCatalogi — scope a catalog, publish with a date rule, expose a DCAT-AP-NL feed.

This capstone is the Woo & DCAT overlay on that pipeline. Rather than repeat the mechanics, it points you at each deep tutorial and then layers the open-government specifics on top: the canonical registers you import instead of hand-building, the open-data source you map to a Dataset, and the DCAT-AP-NL feed that national portals harvest. The shape is identical to the Pet Store chain — grab data from a source, and publish it on a catalog — only the domain changes.

This is Part 6 of the nine-part app-building tutorial series. Part 4 packaged the app and put it on the Conduction store; this part makes it talk to the rest of the workspace: three integration patterns layered from least to most invasive. By the end your orders know who their supplier is, every order shows the right care guide from xWiki, and a needs_followup order automatically opens a maintenance page in xWiki that flips the order back to delivered when the page is marked resolved.

The point isn't the specific integrations, it's the pattern. Cross-register reads are how Conduction apps share data without coupling. The OpenConnector source-and-synchronisation pattern is how you absorb data from anywhere into your own register. The webhook endpoint pattern is how external systems push state back. Once you've wired all three, you've covered the integration vocabulary the rest of the catalogue uses.

Part 4 of the nine-part app-building tutorial series. Part 3 made orders appear in NC Calendar with one schema annotation. Part 4 brings external knowledge, category-specific care advice, husbandry notes, feeding tips, from xWiki into the pet detail sidebar via a care_guide OpenRegister schema. Then we package the app and ship it.

External knowledge integration is the canonical case for OpenConnector. Pull data from a system you don't own (xWiki here, but the same applies to Confluence, Notion, SharePoint, Decos, Mendix), surface it inside Nextcloud-native UI without making the user context-switch.