SQLDeveloper no Linux (Ubuntu 11.10)

Ao instalar o SQLDeveloper no linux, me deparei com a seguinte mensagem ao tentar executar o mesmo:

Type the full pathname of a J2SE installation (or Ctrl-C to quit), the path will be stored in ~/.sqldeveloper/jdk

Para resolver esse problema basta adicionar a seguinte linha no arquivo sqldeveloper.conf:

SetJavaHome /usr/lib/jvm/java-6-openjdk/

 O caminho pode variar dependendo do java que tiver instalado.

JDeveloper - Configurando um servidor SOA para deploy

Vá até a guia Application Server, clique com o botão direto e acesse New Application Server:

Na janela seguinte selecione a opção Standalone Server para mapear um servidor instalado em qualquer máquina da rede. Se deseja usar o servidor que vem integrado com o JDeveloper utilize a segunda opção:

Informe um nome para a conexão com o servidor. Esse nome será exibido na lista de opções de deploy das aplicações:

Informe o usuário e senha apra acesso ao SOA:

Informe os dados do servidor (host, porta e domínio da instalação). Caso não saiba o nome do domínio, não se preocupe, deixe o padrão e no momento que for testar a conexão será exibido o nome correto. Volte e informe o nome correto:

Teste a conexão. Caso o nome do domínio esteja incorreto será exibido uma mensagem com o nome correto dele:

Finish:

Para fazer o deploy no servidor configurado basta clicar com o direito sobre o projeto -> Deploy:

Selecione a opção Deploy to Application Server:

Essa tela muda em algumas versões do Jdev, basicamente nela se altera a versão que deseja gerar e fazer o deploy do projeto:

Selecione o servidor configurado anteriormente:



Selecione a instância SOA que deseja fazer o deploy bem como a partição na mesma:

Confira as informações e Finish:

JDeveloper - Criando uma conexão com o banco Sybase

Na guia Database Connections, clique com o botão direito e selecione a opção New Connection:

Selecione a opção Generic JDBC:




Clique no botão Browse:

Será necessário criar uma entrada para a biblioteca de conexão com o Sybase. Clique no botão New:

Clique em Add Entry:




Selecione a biblioteca que será utilizada para conexão com o Sybase. No nosso caso iremos usar a jconn3.jar:




Clique em Ok:

Altere o campo Driver Class para com.sybase.jdbc3.jdbc.SybDriver:

Informe os parâmetros da conexão e faça um teste. Importante informar a URL de conexão de acordo com a biblioteca que foi usada. No nosso exemplo ficaria como a tela abaixo:

Pronto!

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)

E se os motoristas fossem contratados como profissionais de TI?

Vaga: Motorista
Requerimentos Necessários: Experiência em direção veículos normais e de carga pesada, ônibus e caminhões, micro-ônibus, trens, metrô, escavadeiras, tanks de pequeno e grande porte atualmente utilizados pela OTAN.
Experiência em rally e direção defensiva são obrigatórias!
Experiência em Formula-1 é diferencial.
Conhecimento e experiência em reparos de pistões e motores rotor e Wankel, transmissões manual e automática, sistema de ignição, computadores de bordo, ABS, ABD, GPS e sistema de áudio conhecidos mundialmente – obrigatório!
Experiência com pintura e funilaria são diferenciais.
Os interessados devem ter certificados pela BMW, GM e Bosch, mas os certificados devem ter no máximo 2 anos.
Remuneração: $15-$30/hora, depende do resultado da entrevista.
Formação Obrigatória: Bacharelado em Engenharia.

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.

Hora do café...

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