Adapter Components

An adapter includes a number of components. You should understand these components and their relationships when developing adapters.

An adapter includes the following components.

See Designing an Adapter for more information.

  • Defined Objects. You must created defined objects in Oracle Life Sciences Data Hub to create an adapter in the same way you do to create an application in Oracle LSH, in a similar hierarchy; see the Oracle Life Sciences Data Hub Application Developer's Guide for more information. You use public APIs to create these objects. The following objects, which are illustrated in Figure 1-1, are required except as noted:
    • Adapter Domain. Each adapter must have one Adapter Domain to hold all the other defined objects.
    • Adapter Area. Each adapter must have one Adapter Area in the Adapter Domain to hold object definitions and the adapter's Work Area. If your external system interacts with Oracle LSH in multiple ways, you may need to create multiple adapters. You can create a single Adapter Domain containing one Adapter Area for each adapter.

      An Adapter Area has attributes that identify functions you write that are required during Load Set, Data Mart, Program, or Business Area definition, installation, and execution. Other attributes determine which buttons are enabled in the user interface and which functions are required for your adapter. The Adapter Areas table (CDR_ADAPTER_AREAS) also includes a column for the Tech Type ID.

    • Work Area. Each Adapter Area must have one and only one Work Area in the Adapter Area to hold an instance of the Program. You install the Work Area and Program instance to create a database schema for the adapter that contains the PL/SQL packages that you write.
    • Program. Each adapter must have a Program definition inside the Adapter Area and an instance of it in the Work Area.

      If more than one person is writing the functions required for the adapter, you may want to put each person's package in a different Program so that they can install and test their functions at different times.

    • Source Code. Each adapter must have at least one Source Code definition and instance inside the Program to contain the PL/SQL functions and procedures you write. You can include all functions and procedures in one or more defined Source Code objects (one PL/SQL package per Source Code object) in one or more Program objects.
    • Parameters and Parameter Sets. If your adapter requires user input, you must define Parameters and their underlying Variables to receive the input. Each Parameter you define must be contained in a Parameter Set with a predefined name. The system looks for each Parameter Set by name at a different time during object definition and execution.
    • Remote Locations and Connections. If your adapter is for an Oracle-based product, you need to create defined objects to register remote locations and connections.
    • Tables. If your system has a fixed data structure from which you want to load data into Oracle LSH, you may want to define that structure in the adapter itself.
  • Technology Type. You run an API to add a row to the internal Tech Types table (CDR_TECH_TYPES). This table has columns to store the names of functions you write that are required during Load Set, Data Mart, Program, or Business Area installation or execution.
  • PL/SQL Functions and Procedures. For each action a user performs in the user interface (UI) to define or install a Load Set, Data Mart, Program, or Business Area, or to run a Load Set, Data Mart, or Program or launch a visualization tool, you must write a PL/SQL function or procedure to do the work. You must also enter the name of each function or procedure as a value in the appropriate column when you run the Create Tech Type or Create Adapter Area API.

    You write these functions and procedures in one or more PL/SQL packages and upload each package as the source code file for a defined Source Code object in the defined Program in your Adapter Area.

  • Service Type(s). Create a new service type for each new technology type.
  • Lookup Values. Extend the Technology Types and Service Types lookups for each technology type and service type you add. If you need new file types, extend the File Types lookup as well.

Figure 1-1 Adapter Components and Their Relationships

Description of Figure 1-1 follows
Description of "Figure 1-1 Adapter Components and Their Relationships"

The diagram shows the metadata object owning relationships for the adapter. All metadata is contained in the Adapter Domain except the technology type. The arrows in the Adapter Domain portion of the diagram show references between object definitions and instances; these are standard Oracle LSH object relations and you create the definition and instance at the same time, using an API. The Work Area is installed as a set of database schemas that store the custom functions and procedures you write. Each custom function's name is stored in a column of either the Adapter Areas or Tech Types table (CDR_ADAPTER_AREAS or CDR_TECH_TYPES). Each Adapter Area stores the ID of its primary technology type.