Logical Schema Name + Context = 1 Physical Schema (and 1 Physical Data Server as well)
Physical and Logical Agents
A physical agent is an ODI Java service that runs on a host as a listener on a TCP/IP port. It can execute your scenarios when it is invoked from one of the ODI GUI modules or schedule these executions when it is started as a scheduler. You can find more information about how to setup agents and schedulers in the Architecture Case Studies section. A physical agent should have a unique name in Topology Manager. It is referenced by its host’s IP address or name and the TCP port it is listening on.
A physical agent can run multiple sessions in parallel (multi-threaded). For
optimization purposes, it is recommended that you adjust the maximum number of concurrent sessions it is allowed to execute. When this maximum number is reached, any new incoming session will be queued by the agent and executed later when other sessions have terminated. If you plan to run multiple parallel scenarios, you can consider load balancing executions as described in section “Setting up Agents”.
Physical agents are part of the physical architecture. Therefore, you can choose to have different agents according to your environment and contexts. To do so, you define one logical agent and link it to several physical agents according to the context. When starting a session, you simply indicate the logical agent and the context, and ODI will translate it to the physical address of the agent.
The Topology Matrix
As Topology defines the final location of data servers, schemas and agents, it is important to have a detailed idea of where the resources are in all environments. it is recommended that you have a document summarizing all required resources and
their logical mapping in Topology. An example of such a document - called a Topology Matrix – is given in the table below:
Context <Name of the Context> Physical Data Server Information:
Technology:
Technology of the data serverName in ODI: Name of the data server as it should
be declared in Topology
URL: URL for this server (usually
composed of an IP address, a port and eventually a database)
Login Name Dedicated to ODI: Account used to connect ODI to this data server
Default schema name for the Staging Area:
Optional ODI storage space for the staging area
Physical Schemas / Logical Schemas mapping:
Physical Schema Logical Schema
Physical schema 1 Corresponding Logical Schema
Etc.
Physical Data Server Information:
Etc.
Context <Name of the Context>
Etc.
The example given in Figure 13 can be defined as follow:
Context Development
Physical Data Server Information:
Technology: Teradata
Name in ODI: TERADATA_SRV_DEV_CRM
URL: devhost_srvdev
Default schema name for the Staging Area:
Sunopsis_db
Physical Schemas / Logical Schemas mapping:
Physical Schema Logical Schema
db_clients TERADATA_CLIENTS_APP
Physical Data Server Information:
Technology: Teradata
Name in ODI: TERADATA_SRV_DEV_SFA
URL: devhost_srvdev (defined twice to match
the production environment)
Login Name Dedicated to ODI: sunopsis
Default schema name for the Staging Area:
Sunopsis_stg
Physical Schemas / Logical Schemas mapping
:
Physical Schema Logical Schema
db_forecast TERADATA_FORECAST_APP
db_sales TERADATA_SALES_APP
Context Production
Physical Data Server Information:
Technology: Teradata
Name in ODI: TERADATA_CRM_PROD
URL: prod_crm
Login Name Dedicated to ODI: Sunopsis_prod
Default schema name for the Staging Area:
Sunopsis_stg_db
Physical Schemas / Logical Schemas mapping:
Physical Schema Logical Schema
db_clients TERADATA_CLIENTS_APP
Technology: Teradata
Name in ODI: TERADATA_SFA_PROD
URL: Prod_sfa
Login Name Dedicated to ODI: Sunopsis_prod
Default schema name for the Staging Area:
Sunopsis_stg_db
Physical Schemas / Logical Schemas mapping:
Physical Schema Logical Schema
db_forecast TERADATA_FORECAST_APP
db_sales TERADATA_SALES_APP
Object Naming Conventions
Topology defines the core information about your information system. This information is stored in the ODI Master Repository and is referenced in several Work Repositories. When naming objects in Topology, you should follow a strict convention to facilitate maintenance. The following are some suggestions for naming objects:
Object Type
Naming Rule Examples
Physical Data Server
We recommended that you prefix any data server name with the technology it belongs to. The name should be a meaningful name such as the one used usually to reference this server. Put the name in uppercase. <TECH_NAME>_<SRV_NAME> TERADATA_EDW ORACLE_CRM_DEV DB2UDB_SFA_TST1 XML_CLIENT001 Logical Schema
We recommended that you prefix any logical schema name with the technology it belongs to. The name should be a meaningful name such as the one used usually to reference applications, schemas or business areas. Put the name in uppercase. <TECH_NAME>_<SCHEMA_NAME> TERADATA_STG_LEVEL1 TERADATA_MSTR_DATA ORACLE_CRM_MAIN ORACLE_CRM_SALES ORACLE_CRM_FRCST Context You should use a meaningful name for the context.
However, the context code should be in uppercase. Avoid spaces and special characters in the context code.
Name: Development Ctx Code: DEV
Name: <Context Name> Code: <CONTEXT_CODE> Name: Production NY Code: PROD_NY Physical Agent
A physical agent is identified by the host name and the TCP port it is listening on. Try to define your agent names in uppercase. Avoid spaces and special characters in the agent name.
<HOST>_<PORT> AS400DEV_29000 WXFRAUN2345_PROD_29000 WXFRAUN_DEV2345_29010 LXWWWMAIN_29020 Logical Agent
Logical agent names should be meaningful according to the physical agents they refer to. Define the name in uppercase and avoid any spaces or special characters.
<LOGICAL_NAME>
WXFRA2345 LXWWWMAIN
DEFINING ODI MODELS
Introduction to Models