Translate topic in your language

Friday 1 February 2019

What Is an Agent? Different type of Agents in ODI and what is the major difference between them.


What Is an Agent?



An agent is a Java process that's usually located on the server and listens to a port for incoming requests. It runs the requested scenario, reverse-engineers requested datastores, etc.









When a job submitted through ODI Studio GUI or through the startscen.sh agent gets scenario from the work repository and topology definitions from master repository, it combines and converts them into a runnable job, usually consisting of more than one code block. Then, it sends code blocks to destination environments, which may be DB servers, file servers, Hadoop name nodes, etc. Finally, the agent gets job statuses from these environments and writes into work repository tables for us to see from the Operator tab of ODI Studio.



Agent Types:-



1) Standalone Agent

Historically, this is the original ODI agent, and it is still available today. The number one benefit of this agent is its very light footprint: it does not require an application server since it is a standalone Java program. This makes it ideal for installations on busy and already active systems, including database servers. It provides all the required features to orchestrate data integration processes, including exposing these processes as web services. The lightweight nature of the agent brings many benefits:











In an ELT architecture, the agent can reside on the same server as the target database, hence reducing the number of network hops when transferring data through JDBC (see Understanding Where to Install the ODI Standalone Agent for more details on this);

For integrations that require access to flat files, scripts and utilities that are not accessible from the network, installing the agent on the file server or the machine that hosts scripts and utilities makes for a very flexible infrastructure.

Lifecycle and availability of a Standalone Agent is managed by Node Manager monitoring and restarting the agent.



2) JEE agent :-

The ODI Agent can be deployed in a standalone environment as well as on the industry leading WebLogic Server. It is with the WebLogic server deployment that ODI achieves scalability and high availability. For deploying on WebLogic server ODI ships with a JEE application and a domain configuration deployment template to assist in configuration of the agent/

Some pros of JEE agent are:









High availability: Through Web Logic Server’s cluster architecture, even if a node is down, agents may run on other nodes.



Configurable connection pooling: Connection pool can be configured through WLS.



Monitoring: Oracle Enterprise Manager can monitor, configure, alert, and manage ODI JEE agents. But there is a plug-in to be installed to achieve this tasks from OEM.



3) Colocated Agent

This is the newest agent type that arrived with ODI 12c. It's like a combo of other two types. The agent is a standalone agent, but it can be monitored and configured through WLS. Unfortunately, it does not take advantage of connection pooling or high availability. Our agent will be in the WLS domain and can be managed through WLS — and that’s all. It is lighter than the JEE agent. Companies that prefer JEE Agent as production agents should choose the colocated agent as their dev/test agent.



Where to Locate an Agent:-

To decrease network I/O, it is better to locate the agent for the target DB server. Since the agent submits code to DB Engine, it is better for them to be on the same machine. Don’t forget that ODI is an ELT tool, which means it will load data into target server and then transform your data. So, most of the load will be on the target server, which also means that most of the code will be submitted to the target server.



Also, since an agent is a local Java process, the agent will write files to the machine upon which it is set up. If you have a file server other than the DB server, it's better to have another agent on the file server to handle read/write file processes. Mounting the file server directory to the DB server as a directory and setting up only one agent is another solution.



Also, these solutions will prevent any firewall-related problems

No comments:

Post a Comment

Note: only a member of this blog may post a comment.