Virtual DataPort: Data Sources, Base Views, and Connection Management
What this domain tests
This domain covers how Virtual DataPort (VDP) reaches external systems and turns each connection into a base view - the only view type that reads real data. Expect questions on driver and adapter selection, connection-pool settings, credential modes, schema inference and the effect of connection parameters on execution.
Data sources
You create a data source inside a VDP database. JDBC sources store a driver class, URL, database adapter and credentials; other types include ODBC, delimited text, JSON, XML, LDAP, Salesforce and SAP BAPI. The adapter is not cosmetic: it decides how VDP generates SQL - identifier quoting, pagination, function mapping - for that engine. "Test connection" only proves the URL and login work.
Base views
A base view is built from a table or a source query, and VDP infers field names, types and nullability. You may retype fields, rename them without touching the source, and declare a primary key. That key is what later lets cache invalidation and incremental loads identify rows; without it, refresh logic falls back to full reloads.
Connection management
Credentials can be fixed (stored in VDP), pass-through (the calling user's identity is sent to the source) or Kerberos-based. Pool settings - initial size, maximum active, idle timeout - bound concurrency at the source. Fetch size controls rows per driver round trip, and query timeouts plus maximum-result limits stop runaway scans.
Worked example
Requirement: an Oracle base view where Oracle's own row-level security must apply per employee. With fixed credentials every query runs as one account, so Oracle cannot distinguish users; choose pass-through authentication and the Oracle adapter. Keep the pool at default until concurrency is measured, and declare the primary key because the view will later be cached and refreshed incrementally. If the requirement instead said "one shared read-only reporting account", fixed credentials would be correct.
Traps that cost marks
- Treating a successful connection test as proof the adapter is right; a wrong adapter connects and then emits invalid SQL.
- Using pass-through against a source that has a single generic account.
- Enormous fetch sizes that exhaust heap on wide result sets.
- Assuming a source-query change automatically propagates everywhere; dependent views and metadata may need refreshing.