This chapter includes the following sections:
The Oracle Data Integrator Topology is the physical and logical representation of the Oracle Data Integrator architecture and components.
Before you can perform the procedures described in this chapter, you must have installed and configured Oracle Data Integrator, database schemas, domains, and agents, as described in the Installation Guide for Oracle Data Integrator.
The Installation Guide uses the term "topology" in some sections to refer to the organization of servers, folders, and files on your physical servers. This chapter refers to the "topology" configured using the Topology Navigator in ODI Studio.
This section contains these topics:
The physical architecture defines the different elements of the information system, as well as their characteristics taken into account by Oracle Data Integrator. Each type of database (Oracle, DB2, etc.), file format (XML, Flat File), or application software is represented in Oracle Data Integrator by a technology.
A technology handles formatted data. Therefore, each technology is associated with one or more data types that allow Oracle Data Integrator to generate data handling scripts.
The physical components that store and expose structured data are defined as data servers. A data server is always linked to a single technology. A data server stores information according to a specific technical logic which is declared into physical schemas attached to this data server. Every database server, JMS message file, group of flat files, and so forth, that is used in Oracle Data Integrator, must be declared as a data server. Every schema, database, JMS Topic, etc., used in Oracle Data Integrator, must be declared as a physical schema.
Finally, the physical architecture includes the definition of the Physical Agents. These are the Java software components that run Oracle Data Integrator jobs.
Contexts bring together components of the physical architecture (the real Architecture) of the information system with components of the Oracle Data Integrator logical architecture (the Architecture on which the user works).
For example, contexts may correspond to different execution environments (Development, Test and Production) or different execution locations (Boston Site, New-York Site, and so forth.) where similar physical resource exist.
Note that during installation the default GLOBAL context is created.
The logical architecture allows a user to identify as a single Logical Schema a group of similar physical schemas - that is containing datastores that are structurally identical - but located in different physical locations. Logical Schemas, like their physical counterpart, are attached to a technology.
Context allow to resolve logical schemas into physical schemas. In a given context, one logical schema resolves in a single physical schema.
For example, the Oracle logical schema Accounting may correspond to two Oracle physical schemas:
Accounting Sample used in the Development context
Accounting Corporate used in the Production context
These two physical schemas are structurally identical (they contain accounting data), but are located in different physical locations. These locations are two different Oracle schemas (Physical Schemas), possibly located on two different Oracle instances (Data Servers).
All the components developed in Oracle Data Integrator are designed on top of the logical architecture. For example, a data model is always attached to logical schema, and data flows are defined with this model. By specifying a context at run-time, the model's logical schema resolves to a single physical schema, and the data contained in this schema in the data server can be accessed by the integration processes.
Oracle Data Integrator run-time Agents orchestrate the execution of jobs. These agents are Java components.
The run-time agent functions as a listener and a scheduler agent. The agent executes jobs on demand (model reverses, packages, scenarios, mappings, and so forth), for example when the job is manually launched from a user interface or from a command line. The agent is also to start the execution of scenarios according to a schedule defined in Oracle Data Integrator.
Third party scheduling systems can also trigger executions on the agent. See "Scheduling a Scenario or a Load Plan with an External Scheduler" for more information.
Typical projects will require a single Agent in production; however, "Load Balancing Agents" describes how to set up several load-balanced agents.
ODI Studio can also directly execute jobs on demand. This internal "agent" can be used for development and initial testing. However, it does not have the full production features of external agents, and is therefore unsuitable for production data integration. When running a job, in the Run dialog, select
Local (No Agent) as the Logical Agent to directly execute the job using ODI Studio. Note the following features are not available when running a job locally:
Stale session cleanup
Ability to stop a running session
If you need any of these features, you should use an external agent.
The lifecycle of an agent is as follows:
When the agent starts it connects to the master repository.
Through the master repository it connects to any work repository attached to the Master repository and performs the following tasks at startup:
Execute any outstanding tasks in all Work Repositories that need to be executed upon startup of this Agent.
Clean stale sessions in each work repository. These are the sessions left incorrectly in a running state after an agent or repository crash.
Retrieve its list of scheduled scenarios in each work repository, and compute its schedule.
The agent starts listening on its port.
When an execution request arrives on the agent, the agent acknowledges this request and starts the session.
The agent launches the sessions start according to the schedule.
The agent is also able to process other administrative requests in order to update its schedule, stop a session, respond to a ping or clean stale sessions. The standalone agent can also process a stop signal to terminate its lifecycle.
Refer to Chapter 21, "Running Integration Processes" for more information about a session lifecycle.
Agents are not data transformation servers. They do not perform any data transformation, but instead only orchestrate integration processes. They delegate data transformation to database servers, operating systems or scripting engines.
Agents are multi-threaded lightweight components. An agent can run multiple sessions in parallel. When declaring a physical agent, it is recommended that you adjust the maximum number of concurrent sessions it is allowed to execute simultaneously from a work repository. 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 sessions, you can consider load balancing executions as described in "Load Balancing Agents".
The Oracle Data Integrator agents exists in two flavors: standalone agent and Java EE agent.
A standalone agent runs in a separate Java Virtual Machine (JVM) process. It connects to the work repository and to the source and target data servers via JDBC. Standalone agents can be installed on any server with a Java Virtual Machine installed. This type of agent is more appropriate when you need to use a resource that is local to one of your data servers (for example, the file system or a loader utility installed with the database instance), and you do not want to install a Java EE application server on this machine.
A Java EE agent is deployed as a web application in a Java EE application server (for example Oracle WebLogic Server or IBM WebSphere). The Java EE agent can benefit from all the features of the application server (for example, JDBC data sources or clustering for Oracle WebLogic Server). This type of agent is more appropriate when there is a need for centralizing the deployment and management of all applications in an enterprise application server, or when you have requirements for high availability.
It is possible to mix in a single environment standalone and Java EE agents in a distributed environment.
A physical agent corresponds to a single standalone agent or a Java EE agent. A physical agent should have a unique name in the Topology.
Similarly to schemas, physical agents having an identical role in different environments can be grouped under the same logical agent. A logical agent is related to physical agents through contexts. When starting an execution, you indicate the logical agent and the context. Oracle Data Integrator will translate this information into a single physical agent that will receive the execution request.
An agent runs on a host and a port and is identified on this port by an application name. The agent URL also indicates the protocol to use for the agent connection. Possible values for the protocol are
https. These four components make the agent URL. The agent is reached via this URL.
A standalone agent started on port 8080 on the odi_production machine will be reachable at the following URL:
The application name for a standalone agent is always oraclediagent and cannot be changed.
A Java EE agent started as an application called oracledi on port 8000 in a WLS server deployed on the odi_wls host will be reachable at the following URL:
Languages defines the languages and language elements available when editing expressions at design-time. Languages provided by default in Oracle Data Integrator do not require any user change.
The following steps are a guideline to create the topology. You can always modify the topology after an initial setting:
Create the contexts corresponding to your different environments. See "Creating a Context".
Create the data servers corresponding to the servers used by Oracle Data Integrator. See "Creating a Data Server".
For each data server, create the physical schemas corresponding to the schemas containing data to be integrated with Oracle Data Integrator. See "Creating a Physical Schema".
Create logical schemas and associate them with physical schemas in the contexts. See "Creating a Logical Schema".
Create the physical agents corresponding to the standalone or Java EE agents that are installed in your information systems. See "Creating a Physical Agent".
Create logical agents and associate them with physical agents in the contexts. See "Creating a Logical Agent".
To create a context:
In Topology Navigator expand the Contexts accordion.
Click New context in the accordion header.
Fill in the following fields:
Name: Name of the context, as it appears in the Oracle Data Integrator graphical interface.
Code: Code of the context, allowing a context to be referenced and identified among the different repositories.
Password: Password requested when the user requests switches to this context in a graphical interface. It is recommended to use a password for critical contexts (for example, contexts pointing to Production data)
Check Default if you want this context to be displayed by default in the different lists in Designer Navigator or Operator Navigator.
From the File menu, click Save.
A Data Server corresponds for example to a Database, JMS server instance, a scripting engine or a file system accessed with Oracle Data Integrator in the integration flows. Under a data server, subdivisions are created in the form of Physical Schemas.
Frequently used technologies have their data server creation methods detailed in the Connectivity and Knowledge Modules Guide for Oracle Data Integrator.
It is recommended to follow the guidelines below when creating a data server.
Some technologies require the installation and the configuration of elements such as:
Installation of a JDBC Driver. See Installing and Configuring Oracle Data Integrator for more information.
Installation of a Client Connector,
Data source configuration.
Refer to the documentation of the technology you are connecting to through the data server and to the Connectivity and Knowledge Modules Guide for Oracle Data Integrator. The connection information may also change depending on the technology. Refer to the server documentation provided, and contact the server administrator to define the connection methods.
For each database engine used by Oracle Data Integrator, it is recommended to create a user dedicated for ODI on this data server (typically named
Grant this user privileges to
Create/drop objects and perform data manipulation in his own schema.
Manipulate data into objects of the other schemas of this data server according to the operations required for the integration processes.
This user should be used as follows:
Use this user name/password in the data server user/password definition.
Use this user's schema as your Work Schema for all data schemas on this server.
To create a Data Server:
In Topology Navigator expand the Technologies node in the Physical Architecture accordion.
The list of technologies that are displayed in the Physical Architecture accordion may be very long. To narrow the list of displayed technologies, you can hide unused technologies by selecting Hide Unused Technologies from the Topology Navigator toolbar menu.
Select the technology you want to create a data server for.
Right-click and select New Data Server
Fill in the following fields in the Definition tab:
Name: Name of the Data Server that will appear in Oracle Data Integrator.
For naming data servers, it is recommended to use the following naming standard: <
... (Data Server): This is the physical name of the data server used by other data servers to identify it. Enter this name if your data servers can be inter-connected in a native way. This parameter is not mandatory for all technologies.
For example, for Oracle, this name corresponds to the name of the instance, used for accessing this data server from another Oracle data server through DBLinks.
User/Password: User name and password for connecting to the data server. This parameter is not mandatory for all technologies, as for example for the File technology.
Depending on the technology, this could be a "Login", a "User", or an "account". For some connections using the JNDI protocol, the user name and its associated password can be optional (if they have been given in the LDAP directory).
Define the connection parameters for the data server:
A technology can be accessed directly through JDBC or the JDBC connection to this data server can be served from a JNDI directory.
If the technology is accessed through a JNDI directory:
Check the JNDI Connection on the Definition tab.
Go to the JNDI tab, and fill in the following fields:
User/password connecting to the JNDI directory
Protocol used for the connection
Note that only the most common protocols are listed here. This is not an exhaustive list.
The driver allowing the JNDI connection
Example Sun LDAP directory:
The URL allowing the JNDI connection
The directory element containing the connection parameters
If the technology is connected through JDBC:
Un-check the JNDI Connection box.
Go to the JDBC tab, and fill in the following fields:
Name of the JDBC driver used for connecting to the data server
URL allowing you to connect to the data server.
You can get a list of pre-defined JDBC drivers and URLs by clicking Display available drivers or Display URL sample.
From the File menu, click Save to validate the creation of the data server.
The following actions are optional:
These properties are passed when creating the connection, in order to provide optional configuration parameters. Each property is a (key, value) pair.
For JDBC: These properties depend on the driver used. Please see the driver documentation for a list of available properties. It is possible in JDBC to specify here the user and password for the connection, instead of specifying there in the Definition tab.
For JNDI: These properties depend on the resource used.
To add a connection property to a data server:
On the Properties tab click Add a Property.
Specify a Key identifying this property. This key is case-sensitive.
Specify a value for the property.
From the File menu, click Save.
On the Data Sources tab you can define JDBC data sources that will be used by Oracle Data Integrator Java EE Agents deployed on application servers to connect to this data server. Note that data sources are not applicable for standalone agents.
Defining data sources is not mandatory, but allows the Java EE agent to benefit from the data sources and connection pooling features available on the application server. Connection pooling allows reusing connections across several sessions. If a data source is not declared for a given data server in a Java EE agent, this Java EE agent always connects the data server using direct JDBC connection, that is without using any of the application server data sources.
Before defining the data sources in Oracle Data Integrator, please note the following:
Datasources for WebLogic Server should be created with the Statement Cache Size parameter set to 0 in the Connection Pool configuration. Statement caching has a minor impact on data integration performances, and may lead to unexpected results such as data truncation with some JDBC drivers. Note that this concerns only data connections to the source and target data servers, not the repository connections.
If using Connection Pooling with datasources, it is recommended to avoid ALTER SESSION statements in procedures and Knowledge Modules. If a connection requires ALTER SESSION statements, it is recommended to disable connection pooling in the related datasources.
To define JDBC data sources for a data server:
On the DataSources tab of the Data Server editor click Add a DataSource
Select a physical Agent in the Agent field.
Enter the data source name in the JNDI Name field.
Note that this name must match the name of the data source in your application server.
Check JNDI Standard if you want to use the environment naming context (ENC).
When JNDI Standard is checked, Oracle Data Integrator automatically prefixes the data source name with the string
java:comp/env/ to identify it in the application server's JNDI directory.
Note that the JNDI Standard is not supported by Oracle WebLogic Server and for global data sources.
From the File menu, click Save.
After having defined a data source for a Java EE agent, you must create it in the application server into which the Java EE agent is deployed. There are several ways to create data sources in the application server, including:
Configure the data sources from the application server console. For more information, refer to your application server documentation.
On the On Connect/Disconnect tab you can define SQL commands that will be executed when a connection to a data server defined in the physical architecture is created or closed.
The On Connect command is executed every time an ODI component, including ODI client components, connects to this data server.
The On Disconnect command is executed every time an ODI component, including ODI client components, disconnects from this data server.
These SQL commands are stored in the master repository along with the data server definition.
Before setting up commands On Connect/Disconnect, please note the following:
The On Connect/Disconnect commands are only supported by data servers with a technology type Database (JDBC).
The On Connect and Disconnect commands are executed even when using data sources. In this case, the commands are executed when taking and releasing the connection from the connection pool.
Substitution APIs are supported. Note that the design time tags
<% are not supported. Only the execution time tags
<@ are supported.
Only global variables in substitution mode (
#<VAR_NAME> ) are supported. See "Variable Scope" for more information. Note that the Expression Editor only displays variables that are valid for the current data server.
The variables that are used in On Connect and Disconnect commands are only replaced at runtime, when the session starts. A command using variables will fail when testing the data server connection or performing a View Data operation on this data server. Make sure that these variables are declared in the scenarios.
Oracle Data Integrator Sequences are not supported in the On Connect and Disconnect commands.
The commands On Connect/Disconnect have the following usage:
When a session runs, it opens connections to data servers. every time a connection is opened on a data server that has a command On Connect defined, a task is created under a specific step called Command on Connect. This task is named after the data server to which the connection is established, the step and task that create the connection to this data server. It contains the code of the On Connect command.
When the session completes, it closes all connections to the data servers. Every time a connection is closed on a data server that has a command On Disunite defined, a task is created under a specific step called Command on Disconnect. This task is named after the data server that is disconnected, the step and task that dropped the connection to this data server. It contains the code of the On Disconnect command.
When an operation is made in ODI Studio or ODI Console that requires a connection to the data server (such as View Data or Test Connection), the commands On Connect/Disconnect are also executed if the Client Transaction is selected for this command.
You can specify whether or not to show On Connect and Disconnect steps in Operator Navigator. If the user parameter Hide On Connect and Disconnect Steps is set to
Yes, On Connect and Disconnect steps are not shown.
To set up On Connect/Disconnect commands:
On the On Connect/Disconnect tab of the Data Server editor, click Launch the Expression Editor in the On Connect section or in the On Disconnect section.
In the Expression Editor, enter the SQL command.
The Expression Editor displays only the substitution methods and keywords that are available for the technology of the data server. Note that global variables are only displayed if the connection to the work repository is available.
Click OK. The SQL command is displayed in the Command field.
Optionally, select Commit, if you want to commit the connection after executing the command. Note that if AutoCommit or Client Transaction is selected in the Execute On list, this value will be ignored.
Optionally, select Ignore Errors, if you want to ignore the exceptions encountered during the command execution. Note that if Ignore Errors is not selected, the calling operation will end in error status. A command with Ignore Error selected that fails during a session will appear as a task in a Warning state.
From the Log Level list, select the logging level (from 1 to 6) of the connect or disconnect command. At execution time, commands can be kept in the session log based on their log level. Default is
From the Execute On list, select the transaction(s) on which you want to execute the command.
Transactions from 0 to 9 and the Autocommit transaction correspond to connection created by sessions (by procedures or knowledge modules). The Client Transaction corresponds to the client components (ODI Console and Studio).
You can select Select All or Unselect All to select or unselect all transactions.
From the File menu, click Save.
You can now test the connection, see "Testing a Data Server Connection" for more information.
It is recommended to test the data server connection before proceeding in the topology definition.
To test a connection to a data server:
In Topology Navigator expand the Technologies node in the Physical Architecture accordion and then expand the technology containing your data server.
Double-click the data server you want to test. The Data Server Editor opens.
Click Test Connection.
The Test Connection dialog is displayed.
Select the agent that will carry out the test. Local (No Agent) indicates that the local station will attempt to connect.
Click Detail to obtain the characteristics and capacities of the database and JDBC driver.
Click Test to launch the test.
A window showing "connection successful!" is displayed if the test has worked; if not, an error window appears. Use the detail button in this error window to obtain more information about the cause of the connection failure.
An Oracle Data Integrator Physical Schema corresponds to a pair of Schemas:
A (Data) Schema, into which Oracle Data Integrator will look for the source and target data structures for the mappings.
A Work Schema, into which Oracle Data Integrator can create and manipulate temporary work data structures associated to the sources and targets contained in the Data Schema.
Frequently used technologies have their physical schema creation methods detailed in the Connectivity and Knowledge Modules Guide for Oracle Data Integrator.
Before creating a Physical Schema, note the following:
Not all technologies support multiple schemas. In some technologies, you do not specify the work and data schemas since one data server has only one schema.
Some technologies do not support the creation of temporary structures. The work schema is useless for these technologies.
The user specified in the data server to which the Physical Schema is attached must have appropriate privileges on the schemas attached to this data server.
To create a Physical Schema:
Select the data server, Right-click and select New Physical Schema. The Physical Schema Editor appears.
If the technology supports multiple schemas:
Select or type the Data Schema for this Data Integrator physical schema in ... (Schema). A list of the schemas appears if the technologies supports schema listing.
Select or type the Work Schema for this Data Integrator physical schema in ... (Work Schema). A list of the schemas appears if the technologies supports schema listing.
Check the Default box if you want this schema to be the default one for this data server (The first physical schema is always the default one).
Go to the Context tab.
Select a Context and an existing Logical Schema for this new Physical Schema.
If no Logical Schema for this technology exists yet, you can create it from this Editor.
To create a Logical Schema:
Select an existing Context in the left column.
Type the name of a Logical Schema in the right column.
This Logical Schema is automatically created and associated to this physical schema in this context when saving this Editor.
From the File menu, click Save.
To create a logical schema:
In Topology Navigator expand the Technologies node in the Logical Architecture accordion.
Select the technology you want to attach your logical schema to.
Right-click and select New Logical Schema.
Fill in the schema name.
For each Context in the left column, select an existing Physical Schema in the right column. This Physical Schema is automatically associated to the logical schema in this context. Repeat this operation for all necessary contexts.
From the File menu, click Save.
To create a Physical Agent:
In Topology Navigator right-click the Agents node in the Physical Architecture accordion.
Select New Agent.
Fill in the following fields:
Name: Name of the agent used in the Java graphical interface. Note: Avoid using Internal as agent name. Oracle Data Integrator uses the Internal agent when running sessions using the internal agent and reserves the Internal agent name.
Host: Network name or IP address of the machine the agent will been launched on.
Port: Listening port used by the agent. By default, this port is the 20910.
Web Application Context: Name of the web application corresponding to the Java EE agent deployed on an application server. For standalone agents, this field should be set to oraclediagent.
Protocol: Protocol to use for the agent connection. Possible values are
https. Default is
Maximum number of sessions supported by this agent.
Maximum number of threads: Controls the number of maximum threads an ODI Agent can use at any given time. Tune this as per your system resources and CPU capacity.
Maximum threads per session: ODI supports executing sessions with multiple threads. This limits maximum parallelism for a single session execution.
Session Blueprint cache Management:
Maximum cache entries: For performance, session blueprints are cached. Tune this parameter to control the JVM memory consumption due to the Blueprint cache.
Unused Blueprint Lifetime (sec): Idle time interval for flushing a blueprint from the cache.
If you want to setup load balancing, go to the Load balancing tab and select a set of linked physical agent to which the current agent can delegate executions. See "Setting Up Load Balancing" for more information.
If the agent is launched, click Test. The successful connection dialog is displayed.
To create a logical agent:
In Topology Navigator right-click the Agents node in the Logical Architecture accordion.
Select New Logical Agent.
Fill in the Agent Name.
For each Context in the left column, select an existing Physical Agent in the right column. This Physical Agent is automatically associated to the logical agent in this context. Repeat this operation for all necessary contexts.
From the File menu, click Save.
This section describes how to work with a standalone agent, a Java EE agent and how to handle load balancing.
Managing the standalone agent involves the actions discussed in these sections:
The agent command line scripts, which are required for performing the tasks described in this section, are only available if you have installed the Oracle Data Integrator Standalone Agent. See Installing and Configuring Oracle Data Integrator for information about how to install the Standalone Agent.
Configuring a standalone agent is described in Installing and Configuring Oracle Data Integrator. See:
The standalone agent is able to execute scenarios on predefined schedules or on demand. The instructions for launching the standalone agent are provided in "Starting the Node Manager and Standalone Agent," in the Installation Guide for Oracle Data Integrator.
Managing a Java EE agent involves the actions discussed in the sections:
Configuring a Java EE agent is described in Installing and Configuring Oracle Data Integrator. See:
Oracle Data Integrator provides a Server Template Generation wizard to help you create a server template for a run-time agent.
To open the Server Template Generation wizard:
From the Physical Agent Editor toolbar menu, select Generate Server Template. This starts the Template Generation wizard.
In the Agent Information step, review the agent information and modify the default configuration if needed.
The Agent Information includes the following parameters:
Agent Name: Displays the name of the Agent that you want to deploy.
From the list, select the server on which you want to deploy the agent. Possible values are
Oracle WebLogic and
Master Repository Connection
Datasource JNDI Name: The name of the datasource used by the Java EE agent to connect to the master repository. The template can contain a definition of this datasource. Default is
Connection Retry Settings
Connection Retry Count: Number of retry attempts done if the agent loses the connection to the repository. Note that setting this parameter to a non-zero value, enables a high availability connection retry feature if the ODI repository resides on an Oracle RAC database. If this feature is enabled, the agent can continue to execute sessions without interruptions even if one or more Oracle RAC nodes become unavailable.
Retry Delay (milliseconds): Interval (in milliseconds) between each connection retry attempt.
Supervisor Key: Name of the key in the application server credential store that contains the login and the password of an ODI user with Supervisor privileges. This agent will use this user credentials to connect to the repository.
In the Libraries and Drivers step, select from the list the external libraries and drivers to deploy with this agent. Only libraries added by the user appear here.
Note that the libraries can be any JAR or ZIP file that is required for this agent. Additional JDBC drivers or libraries for accessing the source and target data servers must be selected here.
You can use the corresponding buttons in the toolbar to select or deselect all libraries and/or drivers in the list.
In the Datasources step, select the datasources definitions that you want to include in this agent template. You can only select datasources from the wizard. Naming and adding these datasources is done in the Data Sources tab of the Physical Agent editor.
In Template Target and Summary step, enter the Target Template Path where the server template will be generated.
Click Finish to close the wizard and generate the server template.
The Template generation information dialog appears.
Click OK to close the dialog.
The generated template can be used to deploy the agent in WLS or WAS using the respective configuration wizard. Refer to Installing and Configuring Oracle Data Integrator for more information.
After deploying the template, it is necessary to declare the Supervisor into the WLS or WAS Credential Store. Refer to Installing and Configuring Oracle Data Integrator for more information.
You can create datasources from the Topology Navigator into an application server (either Oracle WebLogic Server or IBM WebSphere) for which a Java EE agent is configured.
To deploy datasources in an application server:
Open the Physical Agent Editor configured for the application server into which you want to deploy the datasources.
Go to the Datasources tab.
Drag and Drop the source/target data servers from the Physical Architecture tree in the Topology Navigator into the DataSources tab.
Provide a JNDI Name for these datasources.
Right-click any of the datasource, then select Deploy Datasource on Server.
On the Datasources Deployment dialog, select the server on which you want to deploy the data sources. Possible values are WLS or WAS server.
In the Deployment Server Details section, fill in the following fields:
Host: Host name or IP address of the application server.
Port: Bootstrap port of the deployment manager
User: Server user name.
Password: This user's password
In the Datasource Deployment section, provide the name of the server on which the datasource should be deployed, for example
This operation only creates the Datasources definition in WebLogic Server or WebSphere Application Server. It does not install drivers or library files needed for these datasources to work. Additional drivers added to the Studio classpath can be included into the Agent Template. See "Creating a Server Template for the Java EE Agent" for more information.
When setting up datasources in WebLogic Server for Oracle Data Integrator, please note the following:
Datasources should be created with the Statement Cache Size parameter set to 0 in the Connection Pool configuration. Statement caching has a minor impact on data integration performances, and may lead to unexpected results such as data truncation with some JDBC drivers.
If using Connection Pooling with datasources, it is recommended to avoid ALTER SESSION statements in procedures and Knowledge Modules. If a connection requires ALTER SESSION statements, it is recommended to disable connection pooling in the related datasources, as an altered connection returns to the connection pool after usage.
Oracle Data Integrator allows you to load balance parallel session execution between physical agents.
Each physical agent is defined with:
A maximum number of sessions it can execute simultaneously from a work repository
The maximum number of sessions is a value that must be set depending on the capabilities of the machine running the agent. It can be also set depending on the amount of processing power you want to give to the Oracle Data Integrator agent.
Optionally, a number of linked physical agents to which it can delegate sessions' executions.
An agent's load is determined at a given time by the ratio
(Number of running sessions / Maximum number of sessions) for this agent.
When a session is started on an agent with linked agents, Oracle Data Integrator determines which one of the linked agents is less loaded, and the session is delegated to this linked agent.
An agent can be linked to itself, in order to execute some of the incoming sessions, instead of delegating them all to other agents. Note that an agent not linked to itself is only able to delegate sessions to its linked agents, and will never execute a session.
Delegation cascades in the hierarchy of linked agents. If agent A has agent B1 and B2 linked to it, and agent B1 has agent C1 linked to it, then sessions started on agent A will be executed by agent B2 or agent C1. Note that it is not recommended to make loops in agents links.
If the user parameter "Use new Load Balancing" is set to
Yes, sessions are also re-balanced each time a session finishes. This means that if an agent runs out of sessions, it will possibly be reallocated sessions already allocated to another agent.
When for a given agent the number of running sessions reaches its maximum number of sessions, the agent will put incoming sessions in a "queued" status until the number of running sessions falls below the maximum of sessions.
If an agent is unavailable (because it crashed for example), all its sessions in queue will be re-assigned to another load balanced agent that is neither running any session nor having sessions in queue if the user parameter Use the new load balancing is set to Yes.
To setup load balancing:
Define a set of physical agents, and link them in a hierarchy of agents (see "Creating a Physical Agent" for more information).
Start all the physical agents corresponding to the agents defined in the topology.
Run the executions on the root agent of your hierarchy. Oracle Data Integrator will balance the load of the executions between its linked agents.