Generic app integration with IDM using the Integration Module for DatabasesE. Axel Larsson
Drew [email protected] EMEA Conference 2007
“Generic” IDM drivers
Integration Module for Tools Driver for Delimited Text SOAP Driver
Integration Module for Enterprise – Custom Edition Extend Composer based drivers
Integration Module for UNIX/Linux Scriptable framework for the bi-directional driver
Integration Module for Databases
What is the Integration Module for Databases? Integrates foreign applications with IDM
directly at the database level, rather than app specific APIs.
Supports subscriber and publisher channels Subscriber events converted into SQL queries –
INSERT, UPDATE, and DELETE actions. Publisher events based upon an event log or
polling (i.e. triggerless publication)
Decision Criteria
Things to consider when evaluating whether to use the Integration Module for Databases This is not a zero-impact solution
Driver imposes DB schema requirements Artifacts created in the application database – views,
intermediate tables, triggers. Application vendor comfort levels DBA comfort levels Schema stability Vendor provided APIs Database support for required features (i.e. triggers and
views) – MySQL?
Types of Applications
Extend your IDM system beyond user account provisioning in different directory services. Customer/patron databases
Helpdesk (at Drew – Supportworks) Campus card systems (at Drew – CS Gold)
LAMP apps that don’t integrate with a directory. Discussion forums, online communities, open source
portals (at Drew – vBulletin forums)
Two deployment models
“Direct” synchronization Views created in between the app database
tables and IDM. Views must be updateable if the subscriber
channel is to be used (INSTEAD OF triggers) “Indirect” synchronization
Database tables created in between the app tables and IDM.
Duplication of data from IDM tables to app tables (triggers)
Direct Synchronization
1 view for each object class. View exposes all attributes included in the driver
filter. Primary/foreign key hints (pk_ prefixes, etc.) Subscriber channel:
View must be updateable (INSTEAD OF triggers) Publisher channel:
Event Log table (triggers on underlying app objects to populate)
Alternative: Triggerless publication
Indirect Synchronization
Intermediate staging tables in between IDM and the application.
1 “parent” table for each object class. Parent table contains all single valued attributes. Must have a primary key.
1 “child” table for each MV attribute. Two columns, foreign key to parent table, and
unconstrained value column. Foreign key constraint must be explicitly defined.
Indirect Synchronization (cont’d) Related attributes
Map to DN type attributes in eDir. Use foreign key references.
Data synchronization. Triggers to move data between app tables and
IDM tables. Event log triggers for publication.
Which should I use?
App is primarily a publisher of data. Direct sync tends to be less invasive. Triggerless publication in JDBC 2.x.
App is primarily a subscriber. Indirect may be easier, because INSTEAD OF triggers can
be a hassle. Other considerations
Isolation Delegation of development responsibilities. App vendor comfort levels / support.
I use the indirect method.
What about MySQL 4.x?
Limitations of the database restrict its use with the IDM module for databases.
No triggers, no views Syncing directly to app tables. App database schema must conform to IDM
needs. MyISAM type tables, no foreign key support.
No MV attributes.
Questions?
E. Axel LarssonDrew [email protected]
Top Related