ODI - Verificando o valor de uma variável na execução

Muitas vezes precisamos saber o valor de uma variável em um pacote no momento da execução. Uma maneira simples de fazer isso é criar uma procedure com o código abaixo:

vVar = '#V_VARIAVEL_NAME'
raise(a) 

Selecione a tecnologia Jython e marque a opção Ignorar erros. 

Agora basta colocar essa procedure em seu pacote no ponto em que deseja visualizar o valor da variável. Execute e confira no Operator o resultado.

Você pode aperfeiçoar essa procedure criando uma Option onde essa recebe a variável que desejar. Dessa forma você pode usar a mesma em todos seus projetos, sempre que precisar verificar o valor de determinada variável.

ODI - Integrando um campo CLOB (Oracle) para um campo TEXT (Sybase)

Em integrações onde a origem é uma campo CLOB (Oracle) e o destino é um campo TEXT (Sybase) é comum a ocorrência do erro abaixo:

java.lang.NumberFormatException: For input string: "4294967295"


Para resolver esse problema, basta utilizar a package DBM_LOB do Oracle mapeando o cmapo na interface da seguinte forma:

sys.dbms_lob.substr(CAMPO, sys.dbms_lob.getlength(CAMPO) , 1)

ODI - Criando uma Interface Amarela

Interfaces amarelas são interfaces no ODI que o destino não esta nos modelos de dados mapeados na guia Modelos. São interfaces onde o destino são criados no desenvolvimento, adicionando colunas manualmente.

Este tipo de interface serve para casos onde os dados da integração devem ser trabalhados antes de inseridos no destino.

Abaixo seguem os passos para criar uma interface amarela:
O processo de criação é igual a uma interface normal. Em interfaces insira uma nova interface:




Após defina o noma da interface e (isso é fundamental), como não existe um destino mapeado é preciso definir qual a área de testes a ser utilizada. Marque a opção indicada e selecione o esquema lógico. A tabela destino da interface será criada nesse esquema.




Insira as tabelas origens da interface, faça os devidos joins.




Agora vamos ao destino. Selecione o destino, defina o nome ada tabela que será criada e marque o esquema que deseja que a tabela seja criada:




Adicione as colunas que desejar. Para isto basta clicar com o direito no destino e ir em Adicionar uma Coluna:




Após defina o nome da coluna e o tipo de dados que ela vai receber:




Adicione todas as colunas que necessitar e faça os devidos mapeamentos:




Na guia Fluxo, não esqueça de marcar a opção para criar a tabela destino da interface:




Pronto, basta salvar que você terá na sua lista de interfaces uma interface amarela (literalmente):




Para usar a tabela criada pela interface criada, basta arrastar a interface amarela direto para a origem de outra interface:

ODI - Gerando senha criptografada

Ao configurar os agentes do ODI, no arquivo odiparams.sh (ou .bat) as senhas do usuário do banco e do ODI ficam criptografadas. Para gerarmos uma senha com a criptografia usada no ODI, basta executarmos o seguinte comando:

Windows
agent.bat encode minhaSenha

Linux
agent.sh encode minhaSenha

Esse comando irá resultar na senha (minhaSenha) criptografada.

ODI - Chamando um Webservice de um procedure ODI

É possível invocar webservices do ODI, isso não é nenhuma novidade. Mas como fazer através de uma procedure ODI. Abaixo segue o caminho das pedras:

Crie uma procedure ODI:



Adicione um passo novo e nele selecione a tecnologia SunopsisAPI:



A comando utilizado para chamda do webservice consiste em:

URL = Endereço do WS (end-point)
PORT_TYPE = Tipo fornecido pelo webservice o qual define quais mensagens um serviço pode processar por operações
TIMEOUT = Tempo de resposta a chamada
OPERATION = Operação do webservice que deseja invocar
após esse último parâmetro basta colocar o XML com as variáveis utilizadas pela operação selecionada.

Existe mais variáveis na chamada do webservice usando OdiInvokeWebService. A listagem dessas variáveis e seus respectivos detalhes podem ser encontrada na documentação que vem junto com o ODI.

ODI - Listar Interfaces com Tabelas de Origem e Destino

Uma coisa que a algum tempo foi solicitado a minha pessoa foi a listagem de todas as interfaces e as respectivas tabelas de origem e destino de cada uma. Primeira coisa que ouvi: "Vais ter que abrir interface por interface.".
Graças ao SQL não foi preciso. Com o select abaixo é possível conseguir essa listagem em segundos:

select distinct f.pack_name as INTEGRACAO, a.POP_NAME as NOME_INTERFACE, D.TABLE_NAME as TABELA_ORIGEM, C.RES_NAME as TABELA_DESTINO
from SNP_POP a, SNP_POP_CLAUSE B, SNP_TABLE c, SNP_SOURCE_TAB d, SNP_STEP e, SNP_PACKAGE f
where a.I_POP = B.I_POP
and a.I_TABLE = C.I_TABLE
and a.I_POP = D.I_POP
and a.I_POP = E.I_POP
and E.I_PACKAGE = F.I_PACKAGE
order by 1, 2

Lembrando que esse SQL deve ser rodado no repositório de trabalho do ODI.

ODI - Limpeza Sessões de Execução

Em ambientes onde o espaço físico do banco é um tanto limitado, é importante realizar limpezas periódicas das sessões de execução do Operator. Pode-se realizar isso manualmente, selecionando cada sessão (ou um conjunto) e excluír.
Pode-se também usar o botão de limpeza () e informar os parâmetros conforme tela abaixo:



Porém o processo acima pode ocasionar um erro caso a área de UNDO do banco seja limitada e/ou não esteja com a opção AUTO EXTEND. Esse processo de limpeza realiza a delação de registros de várias tabelas do repositório de trabalho do ODI, porém o COMMIT é realizado somente no final de todo processo, o que faz que a área de UNDO fique um pouco "inchada".
Uma solução é a limpeza via script das sessões do Operator diretamente na base de trabalho fazendo commit a cada tabela excluída.
Abaixo segue a lista de comandos para execução dessa tarefa:


--crio uma tabela para armazenar os IDs das sessões que quero excluir:
create table XXX_SESSION_TO_DELETE
(
SESS_NO NUMBER(19) NOT NULL,
SESS_NAME VARCHAR2(400),
SCEN_VERSION VARCHAR2(35),
I_TXT_SESS_MESS NUMBER(19),
I_TXT_SESS_PARAMS NUMBER(19),
primary key (SESS_NO)
);

create index IDX_XXX_SESSION_TO_DELETE_NAME
on XXX_SESSION_TO_DELETE (SESS_NAME);

create index IDX_XXX_SESSION_TO_DELETE_MESS
on XXX_SESSION_TO_DELETE (I_TXT_SESS_MESS);

create index IDX_XXX_SESSION_TO_DEL_PARAMS
on XXX_SESSION_TO_DELETE (I_TXT_SESS_PARAMS);

-- insiro na tabela criada as informações que preciso das sessões que quero excluir
insert into XXX_SESSION_TO_DELETE
(SESS_NO, SESS_NAME, I_TXT_SESS_MESS, I_TXT_SESS_PARAMS)
select
SESS_NO, SESS_NAME, I_TXT_SESS_MESS, I_TXT_SESS_PARAMS
from SNP_SESSION
where sess_beg <>
commit;

analyze table XXX_SESSION_TO_DELETE compute statistics;
alter table XXX_SESSION_TO_DELETE enable row movement;


--faço a deleção de cada tabela de log de sessões de acordo com os registros que inseri na minha tabela auxiliar
delete from SNP_EXP_TXT where I_TXT in
(select I_TXT_TASK_MESS from SNP_SESS_TASK_LOG where SESS_NO in
(select SESS_NO from XXX_SESSION_TO_DELETE));
commit;

delete from SNP_EXP_TXT where I_TXT in
(select I_TXT_STEP_MESS from SNP_STEP_LOG where SESS_NO in
(select SESS_NO from XXX_SESSION_TO_DELETE));
commit;

delete from SNP_EXP_TXT where I_TXT in
(select I_TXT_VAR from SNP_VAR_SESS where SESS_NO in
(select SESS_NO from XXX_SESSION_TO_DELETE));
commit;

delete from SNP_EXP_TXT where I_TXT in
(select I_TXT_DEF_T from SNP_VAR_SESS where SESS_NO in
(select SESS_NO from XXX_SESSION_TO_DELETE));
commit;

delete from SNP_EXP_TXT where I_TXT in
(select I_TXT_SESS_PARAMS from XXX_SESSION_TO_DELETE);
commit;

delete from SNP_EXP_TXT where I_TXT in
(select I_TXT_SESS_MESS from XXX_SESSION_TO_DELETE);
commit;

delete from SNP_SESS_TXT_LOG where SESS_NO in
(select SESS_NO from XXX_SESSION_TO_DELETE);
commit;

delete from SNP_SESS_TASK_LOG where SESS_NO in
(select SESS_NO from XXX_SESSION_TO_DELETE);
commit;

delete from SNP_STEP_LOG where SESS_NO in
(select SESS_NO from XXX_SESSION_TO_DELETE);
commit;

delete from SNP_TASK_TXT where SESS_NO in
(select SESS_NO from XXX_SESSION_TO_DELETE);
commit;

delete from SNP_SESS_TASK where SESS_NO in
(select SESS_NO from XXX_SESSION_TO_DELETE);
commit;

delete from SNP_SESS_STEP where SESS_NO in
(select SESS_NO from XXX_SESSION_TO_DELETE);
commit;

delete from SNP_SEQ_SESS where SESS_NO in
(select SESS_NO from XXX_SESSION_TO_DELETE);
commit;

delete from SNP_VAR_SESS where SESS_NO in
(select SESS_NO from XXX_SESSION_TO_DELETE);
commit;

delete from SNP_SESSION where SESS_NO in
(select SESS_NO from XXX_SESSION_TO_DELETE);
commit;

delete from SNP_EXP_TXT where I_TXT in
(select I_TXT_SESS_MESS from SNP_SCEN_REPORT where SESS_BEG <>
commit;

delete from SNP_STEP_REPORT where STEP_BEG <>
commit;

delete from SNP_SCEN_REPORT where SESS_BEG <>
commit;


-- por fim executo o comando shrink para cada tabela para liberar espaço físico no banco
alter table SNP_EXP_TXT enable row movement;
alter table SNP_EXP_TXT shrink space;

alter table SNP_SESS_TXT_LOG enable row movement;
alter table SNP_SESS_TXT_LOG shrink space;

alter table SNP_SESS_TASK_LOG enable row movement;
alter table SNP_SESS_TASK_LOG shrink space;

alter table SNP_STEP_LOG enable row movement;
alter table SNP_STEP_LOG shrink space;

alter table SNP_TASK_TXT enable row movement;
alter table SNP_TASK_TXT shrink space;

alter table SNP_SESS_TASK enable row movement;
alter table SNP_SESS_TASK shrink space;

alter table SNP_SESS_STEP enable row movement;
alter table SNP_SESS_STEP shrink space;

alter table SNP_SEQ_SESS enable row movement;
alter table SNP_SEQ_SESS shrink space;

alter table SNP_VAR_SESS enable row movement;
alter table SNP_VAR_SESS shrink space;

alter table SNP_SESSION enable row movement;
alter table SNP_SESSION shrink space;

alter table SNP_STEP_REPORT enable row movement;
alter table SNP_STEP_REPORT shrink space;

alter table SNP_SCEN_REPORT enable row movement;
alter table SNP_SCEN_REPORT shrink space;

--sempre é bom recoletar as estatisticas de cada tabela :)
analyze table SNP_EXP_TXT compute statistics;
analyze table SNP_SESS_TXT_LOG compute statistics;
analyze table SNP_SESS_TASK_LOG compute statistics;
analyze table SNP_STEP_LOG compute statistics;
analyze table SNP_TASK_TXT compute statistics;
analyze table SNP_SESS_TASK compute statistics;
analyze table SNP_SESS_STEP compute statistics;
analyze table SNP_SEQ_SESS compute statistics;
analyze table SNP_VAR_SESS compute statistics;
analyze table SNP_SESSION compute statistics;
analyze table SNP_STEP_REPORT compute statistics;
analyze table SNP_SCEN_REPORT compute statistics;

--deleto minha tabela auxiliar
drop table XXX_SESSION_TO_DELETE purge;


Esse script eu achei no site abaixo, apenas adaptei uns poucos pontos para minha necessidade:
http://www.myoraclesupports.com/content/manually-deleting-odi-sessions-and-scenario-related-reports

ODI - Versionando interfaces

Um recurso que o ODI fornece é o versionamento de qualquer objeto criado no mesmo. Interfaces, variáveis, pacotes, procedures, armazenamento de dados, etc. Aqui vamos abordar apenas o versionamento de interfaces (apesar que não muda nada para versionamento de outros objetos :) ).

1 - Clique com o botão direito sobre a interface, acesse a opção Versão -> Criar



2 - Na janela que será exibida informe o número da versão que deseja gerar (número é incrementado automaticamente) e no campo Descrição informe o conteúdo da versão ou que lhe for mais conveniente


3 - Acessando a guia Versão na interface é possível visualizar as versões existentes da mesma


4 - No nosso exemplo criamos mais uma versão (1.0.0.1) na qual alteramos a interface apenas adicionando a funcção TRUNC em um campo

5 - Caso seja necessário voltar uma versão, basta clicar com o botão direito sobre a interface ir em Versão -> Restaurar


6 - Será exibida uma janela com as versões disponíveis para interface. Selecione a desejada e clique em Ok. Será exibida uma mensagem informand que a operação pode causar a perda de algumas referências. Isso acontece quando uma interface utiliza em uma versão antiga um armazenamento de dados que agora não existe mais e desejamos voltar a mesma para essa versão antiga, por isso é importante ter cuidado na restauração de versões


Pronto a interface voltou para a versão 1.0.0.0 (no caso a que selecionamos na restauração) onde a função TRUNC não existe ainda.

ODI - Instalando Agentes

Na primeira etapa vamos instalar o agente, na segunda vamos configurá-lo:

Instalação:

As primeiras telas da instalação basta seguir o roteiro abaixo:

1-

2 - Selecione a opção Server que nada mais é que o agente ODI.


3-Configuração do Oracle Home e diretório do mesmo.


4- Caso a instalação seja realizada em um cluster, o instalador automaticamente identifica o mesmo e fornece a opção para instalar em todos os nodos do mesmo o agente. Foi o que aconteceu na nossa instalação abaixo:


5- Marque as opções que deseja instalar. No nosso caso todas.


6- Nessa tela são as configurações do Data Profilling e Quality. Como o foco é a instalação somente do agente, vamos deixar os valores padrões, apensa vamos informar uma senha.


7-Resumo da instalação:


8- Nessa tela são exibidos o script de instalação e as máquinas onde serão instalados os agentes.

Pronto, o agente esta instalado, porém para ficar funcional é preciso configurar o mesmo.

Configuração:

Após a instalação do agente, é necessário realizar a configuração de algumas informações. A primeira etapa é alterar o arquivo odiparams.sh (odiparams.bat no Windows). Abra o arquivo e altere o seguinte trecho em negrito com as informações de conexão do repositório mestre do ODI:

# Repository Connection Information# ODI_SECU_DRIVER=org.hsqldb.jdbcDriver ODI_SECU_URL=jdbc:hsqldb:hsql://localhost ODI_SECU_USER=sa ODI_SECU_ENCODED_PASS= ODI_SECU_WORK_REP=WORKREP ODI_USER=SUPERVISOR ODI_ENCODED_PASS=LELKIELGLJMDLKMGHEHJDBGBGFDGGH

Onde:
ODI_SECU_URL= String de conexão com o repositório do ODI ODI_SECU_USER= Usuário do repositório mestre do ODI ODI_SECU_ENCODED_PASS= Senha do usuário do repositório mestre do ODI ODI_SECU_WORK_REP=Nome do repositório de trabalho

Importante: Os drivers jdbc para conexão com banco de dados devem ser copiados para o diretório drivers na instalação do agente.

Para inicializar o agente, é necessário definir algumas variáveis de ambiente antes. Para isso é recomendável criar um script que inicialize essas variáveis e o agente. Abaixo segue instruções a serem incluídas neste arquivo, o qual chamaremos de agentstar.sh:

export ODI_JAVA_HOME=/app/oracle/agent10g/jdk ./agentscheduler.sh "-PORT=20910" "-NAME=DB50_20910" "-V=2" 1> ../logs/agent.log 2> ../logs/agent.err

Antes de iniciar o agente, é necessário adicionar o mesmo no repositório do ODI, para isso siga os passos abaixo:

1- Acesse o módulo Topology, vá na guia Arquitetura Física, clique com o botão direito sobre agentes -> Inserir Agente:


2 - Informe o nome do agente (mesmo nome colocado na opção -NAME do arquivo agentstart.sh), o host e porta:


Salve clicando em aplicar. Inicialize o agente na máquina onde foi instalado chamando o script de inicialização criado:

./startagent.sh

Verifique se ocorreu algum erro na inicialização do agente acessando o arquivo logs/agent.err. Caso o arquivo esteja sem erros volte ao Topology e clique no botão Testar para testar a conexão com o agente:

Pronto, agente ativo e funcionando!!

ODI - Não truncar hora para campos data

No ODI campos data que são mapeados entre tabelas de bases diferentes, o valor do campo é truncado ficando somente a data e eliminando a hora, minuto e segundo. Para evitar isso basta adicionar uma propriedade na conexão física com o banco. No Topology, acesse o servidor de dados e adicione a propriedade conforme figura abaixo:


Esse ATND é crédito do colega Mateus (Tedy)

ODI - com.sybase.jdbc2.jdbc.SybSQLException: Cursor 'jconnect_implicit_1' was declared with a FOR UPDATE clause. This cursor was found to be read only

O erro acima é facilmente corrigido apenas alterando o parâmetro "Tamanho de busca do Array" (Array Fetch Size) do valor padrão 30 para 0.

ODI - Buscando informações do repositório de trabalho

Em algumas situações, precisamos fazer uma pesquisa nas informações do repositório de trabalho do ODI, como por exemplo ver todas as interfaces que foram alteradas, e/ou verificar quem as alterou e quando. Abaixo segue um pequeno script que retorna todos os objetos do ODI que foram alterados:

select * from SNP_POP where LAST_DATE <> FURST_DATE order by LAST_DATE;


Quem sabe você precisa saber quais os objetos que você criou e alguém alterou:

select * from SNP_POP where LAST_USER <> 'MY_USER' and FIRST_USER = 'MY_USER' order by LAST_USER;

Onde MY_USER é o nome do seu usuário no ODI.

Abraço

ODI - Usando cursores do Sybase

Para quem é habituado a trabalhar com PL/SQL no Oracle, fazer isso no ODI é simples. Porém quando se trata de passar um bloco do Sybase para o ODI é necessário atenção a algumas particularidade. Aqui vamos demonstrar como fazemos uso de cursores no Sybase utilizando o ODI.

No exemplo criamos um procedimento ODI, porém a mesma técnica pode ser implementada em KMs.

Crie dois passos:


No primeiro passo faça a declaração do cursor. Se existirem mais de um cursor, faça um passo para cada:


No passo seguinte escreva o bloco que irá usar o(s) cursor(es):



Os créditos desse ATND são dos colegas Silveirinha e Valdo.