Running a Step Editing a Step’s Linked Object

11 Working with Integration Interfaces 11-1 11 Working with Integration Interfaces This chapter describes how to work with integration interfaces. An overview of the interface components and the Interface Editor is provided. This chapter includes the following sections: ■ Section 11.1, Introduction to Integration Interfaces ■ Section 11.2, Introduction to the Interface Editor ■ Section 11.3, Creating an Interface ■ Section 11.4, Using the Quick-Edit Editor ■ Section 11.5, Designing Integration Interfaces: E-LT- and ETL-Style Interfaces

11.1 Introduction to Integration Interfaces

An interface consists of a set of rules that define the loading of a datastore or a temporary target structure from one or more source datastores. Before creating an integration interface in Section 11.3, Creating an Interface , you must first understand the key components of an integration interface and the Interface Editor. An overview of the components that you use to design an integration interface is provided in Section 11.1.1, Components of an Integration Interface . The interface Editor is described in Section 11.2, Introduction to the Interface Editor .

11.1.1 Components of an Integration Interface

An integration interface is made up of and defined by the following components: ■ Target Datastore The target datastore is the element that will be loaded by the interface. This datastore may be permanent defined in a model or temporary created by the interface. ■ Datasets One target is loaded with data coming from several datasets. Set-based operators Union, Intersect, etc are used to merge the different datasets into the target datastore. Each Dataset corresponds to one diagram of source datastores and the mappings used to load the target datastore from these source datastores. ■ Diagram of Source Datastores 11-2 Oracle Fusion Middleware Developers Guide for Oracle Data Integrator A diagram of sources is made of source datastores - possibly filtered - related using joins. The source diagram also includes lookups to fetch additional information for loading the target. Two types of objects can be used as a source of an interface: datastores from the models and interfaces. If an interface is used, its target datastore -temporary or not- will be taken as a source. The source datastores of an interface can be filtered during the loading process, and must be put in relation through joins. Joins and filters are either copied from the models or can be defined for the interface. Join and filters are implemented in the form of SQL expressions. ■ Mapping A mapping defines the transformations performed on one or several source columns to load one target column. These transformations are implemented in the form of SQL expressions. Each target column has one mapping per dataset. If a mapping is executed on the target, the same mapping applies for all datasets. ■ Staging Area The staging area is a logical schema into which some of the transformations joins, filters and mappings take place. It is by default the same schema as the target’s logical schema. It is possible to locate the staging area on a different location including one of the sources. It is the case if the target’s logical schema is not suitable for this role. For example, if the target is a file datastore, as the file technology has no transformation capability. Mappings can be executed either on the source, target or staging area. Filters and joins can be executed either on the source or staging area. ■ Flow The flow describes how the data flows between the sources, the staging area if it is different from the target, and the target as well as where joins and filters take place. The flow also includes the loading and integration methods used by this interface. These are selected by choosing Loading and Integration Knowledge Modules LKM, IKM. ■ Control An interface implements two points of control. Flow control checks the flow of data before it is integrated into the target, Post-Integration control performs a static check on the target table at the end of the interface. The check strategy for Flow and Post-Integration Control is defined by a Check Knowledge Module CKM. The interfaces use the following components that should be created before the interface: ■ Datastores that will be used as sources and target of the loading process must be populated into the data models. See Chapter 5, Creating and Reverse-Engineering a Model for more information. ■ The correct physical and logical schemas along with their mapping in the interface’s execution context must be defined prior to creating the interface, if the staging area is to be defined in a schema different than any of the sources or the target. See Chapter 4, Setting-up the Topology for more information.