Designing a Connector
7 min
a connector design defines how data will be matched, imported, and acted upon this section outlines how to plan and structure a connector before creating it in activate key design concepts a connector consists of schema — defines what data looks like and how changes are detected workflow — controls how imports and processing occur handlers — define what happens when data changes each connector should have a unique name a defined source of truth (hr, cmdb, sql, etc ) clearly identified key fields (for uniqueness) a delete strategy (how removed records are identified) choosing a key select a unique and stable identifier from the source system (for example, employeenumber, departmentcode, or ticketnumber) mark one column in the schema as the key \<column name="employeenumber" type="varchar(20)" default="''" key="1" /> delete strategy two supported patterns exist for handling deletes option 1 — result set deletes (recommended) only import current rows any previously imported rows missing from the current import are marked as deleted automatically example select from employees where isactive = 1 option 2 — flagged deletes import all rows, including deleted ones, and mark the condition in your schema \<deletecondition>$import$ status = 'deleted'\</deletecondition> planning for history activate automatically logs every detected change into a history table by default the history table is specified in the schema like this \<historytable enable="true">employee history\</historytable> this allows complete auditing of data changes and rollback validation this functionality can be disabled by setting enable="false" on the historytable node in the schema the value of the setting can be blank as no history table will be generated this does require a regeneration of the schema \<historytable enable="false">\</historytable> example connector lifecycle import data into the import table compare import with current data detect changes (create, update, delete) process each change through the selected change handler trigger actions such as job submissions, notifications, or publishing