Use this to view the distribution of execution among different execution units that represent physical servers. You can use the diagram to move components between execution units or onto the diagram background, which would create a separate execution unit.
A physical diagram is stored as a Physical Mapping Design. A mapping can have multiple physical mapping designs; they are listed in tabs under the diagram. By having multiple physical mapping designs the user can create different execution strategies for the same mapping. In order to create a physical mapping design, click the right-most tab at the bottom of the physical diagram. To delete physical mapping designs, use the context menu on the Physical Mapping Design tabs.
Shows general properties for the physical design and execution of a mapping.
| Properties | Description |
|---|---|
| Description | Detailed description of the Physical Mapping Design. |
| Use Unique Temporary Object Names | If selected, generates unique staging table names to avoid collisions between concurrent scenario executions of the same mapping. |
| Is Frozen | If selected, prevents recalculation of the execution units based on the logical design. This ensures that the execution units remain the same even if the staging location is changed. |
| Name | Name of the Physical Mapping Design. |
| Optimization Context | Context used at design time to identify physical details of participating datastores. The execution context is selected separately at runtime. |
| Preset Staging Location | When left blank, target execution unit is used as staging location.
As a general rule, if the target data server has join and transformation capabilities (classic SQL capabilities), it is advised to use the engine of this data server for the transformations. Temporary objects are created in a schema on this server called the Staging Area. If the target server doe not have adequate SQL capabilities (for example if the target is an MOM or a file), you can choose another transformation engine, which can be another data server, or the internal engine working in memory. Caution: Only by choosing a transformation engine on the target can the data flow consistency be checked automatically. |
| Remove Temporary Objects on Error | Removes all temporary objects including staging tables if a session execution fails. |
Note: To add a second Physical Mapping Design, click on the "new" tab to the right of existing Physical Mapping Design tabs.
Source Groups and Target Groups contain one or more execution units.
| Properties | Description |
|---|---|
| Name | Name of the execution group. |
| Description | Detailed description of the execution group. |
An Execution Unit represents a physical server or process that can execute parts of a mapping.
Additional execution units can be created by dragging and dropping components from an existing execution group onto the physical diagram background.
| Properties | Description |
|---|---|
| Name | Name of the execution unit. |
| Description | Detailed description of the execution unit. |
| Location | Logical Schema associated with the execution unit. |
| Technology | Technology associated with the execution unit. |
Shows expressions that are either owned by components in the execution unit, or are intended to be executed on the unit.
| Properties | Description |
|---|---|
| Name | Name of the attribute owning the expression. |
| Expression | Text of the expression available for pushing. |
| Owner | Name of the logical component owning the expression. |
| Execute on | Execution unit where the expression will be executed. <here> indicates the expression will be executed in the currently selected execution unit. Select a different execution unit to move the expression. |
In the physical diagram, an Access Point is a physical component that controls the loading of a component that is remote to the target. In a target execution group, whenever the flow of data goes from one execution unit to another there is an access point (shown with a round icon). Loading Knowledge Modules (LKMs) control how data is transferred from one execution unit to another.
| Properties | Description |
|---|---|
| Name | Name of the access point. |
| Description | Detailed description of the access point. |
| Node Component Type | Type of the component, set to AP Node. |
| Logical Component | Name of the logical component linked to this physical component. |
| Logical Connection Point | Name of the logical connection point linked to this physical component. This applies when the access point node has a downstream component with multiple input connector points. |
| Fixed Execution Unit | Set to true if the physical node is moved explicitly by the user to the parent execution unit. ODI will try to preserve the execution unit and the physical node in that execution unit when synchronizing between the logical and physical mapping. |
| Fixed by Hint | Set to true if the physical node is moved to the parent execution unit by the Execute on hint property, specified in the logical mapping. ODI may not preserve the execution unit where the current physical node resides when synchronizing between logical and physical mapping, but considers the position of the physical node based on execute on hint. |
The attributes that need to be made available from the upstream execution unit to this execution unit. If the execution unit containing the access point node is Oracle, ODI creates a staging table with a prefix C$, and a set of columns to load the necessary data from the upstream execution unit.
| Properties | Description |
|---|---|
| Name | Name of the attribute. |
| Description | Description of the attribute. |
| Source Attribute | Name of attribute bound from source component.
The logical map attribute that is used to derive this physical attribute (thus it is called source attribute of the physical attribute). In other words, the data of the source logical map attribute in the upstream execution unit is staged in this C$ table column. |
| DDL Datatype | Datatype string that will be used to create the staging table. |
| Datatype | Logical datatype of the source attribute. |
| Size | Size of the logical attribute, for numerical data types. |
| Scale | Scale of the logical source attribute, for numerical types. |
| Properties | Description |
|---|---|
| Loading Knowledge Module | Loading Knowledge Module (LKM) used to extract the data from the selected space toward the staging area or target space. It is possible to select either a global LKM or a LKM imported into the project.
Note: only appropriate KMs for this technology are displayed here. |
| Description | Detailed description of the LKM, written by the KM developer. |
| Options | Lists the LKM options with their names and values in a table. Options have a default value specified during the creation of the KM. |
Physical components define how a mapping is executed at runtime; they are the physical representation of logical components. Depending on the logical component a physical component might have a different set of properties.
| Properties | Description |
|---|---|
| Name | Name of the physical component. |
| Description | Detailed description of the physical component. |
| Node Component Type | Type of the component. |
| Logical Component | Name of the logical component linked to this physical component. |
| Logical Connector Point | Name of the logical connector point linked to this physical component. This applies when the Access Point node has a downstream component with multiple input connection points. |
| Fixed Execution Unit | Set to true if the physical node is moved explicitly by the user to the parent execution unit. ODI will try to preserve the execution unit and the physical node in that execution unit when synchronizing between the logical and physical mapping. |
| Fixed by Hint | Set to true if the physical node is moved to the parent execution unit by the Execute on hint property, specified in the logical mapping. ODI may not preserve the execution unit where the current physical node resides when synchronizing between logical and physical mapping, but considers the position of the physical node based on execute on hint. |
| Parent Reusable Mapping Components | Lists reusable mappings in which this component is contained. |
| Execution Context | Datastore Only
Context that is used to resolve the logical schema of the datastore physical node to the physical schema. The context of a target datastore can be explicitly set through its Component Context (Forced) property in the logical diagram. If this property is set to some context, the context is shown under Execution Context in the physical diagram. |
| Datastore Logical Schema | Datastore Only
Logical schema of the datastore. |
| Journalized Data Only | Datastore Only
Select to enable Journalized data collection for this datastore. |
| Temporary Indexes | Join Only
Select to define the temporary index information. |
Attributes are fixed and provided by the logical component. The list of attribute properties varies by component. See Component Attributes for details.
In addition to the logical attributes, physical components have the following property:
| Properties | Description |
|---|---|
| Execute On (Push Expression) | Directive for the execution location. Select a different execution unit to move expression. |
Defines options for data extraction from source components. Shown for source components only. The properties are divided into three tabs: Options, Description, and Advanced.
Options: lists extract options for this module, in a table. Each option has a Name, Description, Value, and Use Default check box. Select the check box to reset the value to default. See knowledge module documentation for details of options available for each module.
Description: A description of the selected knowledge module, if available.
Advanced: The Extract Knowledge Module field shows the EKM selected for data extraction. You can select a different EKM from a drop-down list; only EKMs applicable to the underlying datastore type can be selected.
Defines options for data integration into target components. Shown for target components only. The properties include the Integration Knowledge Module field, and two tabs: Options and Description.
Integration Knowledge Module: shows the IKM selected for data integration. You can select a different IKM from a drop-down list; only IKMs applicable to the underlying datastore type can be selected.
Options: lists integration options for this module, in a table. Each option has a Name, Description, Value, and Use Default check box. Select the check box to reset the value to default. See knowledge module documentation for details of options available for each module.
Description: A description of the selected knowledge module, if available.
Defines options for flow control. Shown for datastore components only. The properties include the Check Knowledge Module field, and two tabs: Options and Description.
Check Knowledge Module: shows the CKM selected for flow control. You can select a different CKM from a drop-down list; only CKMs applicable to the underlying datastore type can be selected.
Options: lists checking options for this module, in a table. Each option has a Name, Description, Value, and Use Default check box. Select the check box to reset the value to default. See knowledge module documentation for details of options available for each module.
Description: A description of the selected knowledge module, if available.
Defines options for data loading into target components. Shown for target components only. The properties include the Loading Knowledge Module field, and two tabs: Options and Description.
Loading Knowledge Module: shows the LKM selected for data loading. You can select a different LKM from a drop-down list; only LKMs applicable to the underlying datastore type can be selected.
Options: lists integration options for this component type, in a table. Each option has a Name, Description, Value, and Use Default check box. Select the check box to reset the value to default. See component documentation for details of options available for each component.
Description: A description of the selected knowledge module, if available.
"Physical Design" in the "Creating and Using Mappings" chapter in Oracle Fusion Middleware Developing Integration Projects with Oracle Data Integrator