Existem dois parâmetros que são obrigatórios em programas concorrentes do tipo “Procedimento Armazendo do PL/SQL”, que são o ERRBUF e RETCODE. Eles são parâmetros de saída (OUT) e são utilizados para retornar informações sobre a execução do concurrent. São esses parâmetros que controlam a cor de cada resultado de execução de um concurrent que aparece na tela de solicitações do EBS: Cor padrão para sucesso, amarelo para alerta e vermelho para erro. Você não precisa informá-los no cadastro do concurrent, mas devem estar configurados no Continue lendo→

Se você já precisou desenvolver uma tela customizada no Forms onde o bloco precisava mostrar informações de colunas que não eram de base, ou seja, colunas de uma tabela que não era a principal do bloco, vai adorar essa dica. Nas tabelas geralmente temos informações de outras tabelas, mas não a informação completa, apenas uma chave para que possamos relacionar com a tabela original. Essa chave pode ser um ID ou código de outra tabela. Por exemplo, na tabela de pedidos do OM temos o Continue lendo→

Quando estamos criando um programa concorrente e configurando os parâmetros, muitas vezes precisamos que um (ou vários) deles seja dependente de outro parâmetro. Mas como assim? Já explico! Imagine que você tenha duas tabelas, uma pai e outra filha, ou mestre e detalhe, como preferir. A filha é dependente da pai, certo? Vamos usar como exemplo as tabelas do Order Management, onde nós temos a tabela de pedidos (OE_ORDER_HEADERS_ALL) e tabela de linhas de pedido (OE_ORDER_LINES_ALL). A tabela de linhas é dependente da tabela de Continue lendo→

Não sei se você já notou, mas alguns forms do EBS exigem logo ao abrir que você escolha uma organização de inventário. Depois que você escolhe uma organização, não será solicitado novamente até você trocar de responsabilidade ou forçar a troca manualmente. No cadastro de itens lá no INV você consegue verificar essa funcionalidade. Nesse artigo vou mostrar o passo a passo para você utilizar esse recurso e implementar nos seus forms. Caso você não seja desenvolvedor, também é interessante saber como funciona, principalmente pela Continue lendo→

As chamadas “Who Columns” são colunas específicas existentes nas tabelas nativas do Oracle EBS para controle e rastreamento de alterações. Essas colunas são preenchidas quando novos registros são inseridos ou quando registros existentes são atualizados. São as informações dessas colunas que aparecem no EBS quando pedimos pra ver o histórico de alterações de algum registro, seja Form ou tela OAF/WEB (Inclusive eu mostro nesse artigo aqui como ver esse histórico em telas OAF/WEB). É uma boa prática adicionar essas colunas em tabelas customizadas também, assim Continue lendo→

A package FND_FILE é utilizada para escrever no log e/ou saída de concurrents. Um programa concorrente bem desenvolvido necessita do extenso uso dessa package, quanto mais detalhes fornecidos no log e saída, mais fácil será a identificação dos detalhes da execução do programa, seja para acompanhar o andamento do processo ou na resolução de problemas. Ela suporta um buffer máximo de linha de 32K, tanto para log quanto para saída. Nesse artigo vou abordar: FND_FILE.PUT FND_FILE.PUT_LINE FND_FILE.NEW_LINE FND_FILE.PUT_NAMES FND_FILE.CLOSE Exceções Geradas Fique comigo até o Continue lendo→

A API FND_PROFILE pode ser utilizada em programas PL/SQL. Ela se encontra no banco de dados como uma package e também dentro da biblioteca FNDSQF. Com essa API podemos manipular valores de profiles de usuário do EBS. A FND_PROFILE pode ser utilizada tanto no lado do servidor quanto no lado do cliente. No lado do cliente, o cache de uma profile de usuário é compartilhado por múltiplas sessões de forms. No lado do servidor, cada sessão de Form tem seu próprio cache de profile de Continue lendo→

A API FND_GLOBAL é uma package “server-side” armazenada no banco de dados muito utilizada por profissionais Oracle EBS. Suas principais utilidades são retornar o conteúdo de globais de sistema e inicializar o contexto de segurança numa sessão de banco de dados, assim é possível simular uma sessão EBS diretamente no banco de dados. Essas variáveis são muito utilizadas para auditoria e controle, assim é possível identificar com facilidade os responsáveis por determinadas ações ou transações. Nesse artigo vou abordar: FND_GLOBAL.USER_ID FND_GLOBAL.LOGIN FND_GLOBAL.RESP_ID FND_GLOBAL.RESP_APPL_ID FND_GLOBAL.CONC_LOGIN_ID FND_GLOBAL.PROG_APPL_ID Continue lendo→

Quem trabalha ou já trabalhou com o EBS sabe da relação de amor e ódio que existe com o Java. O EBS precisa do Java pra funcionar, principalmente por causa das telas desenvolvidas em Forms. Já passamos pela fase do JInitiator (lembra daquela faixa amarela?), depois fomos para o plugin JRE (que é o atual) e já estamos caminhando para um novo produto (Java Web Start – JWS), já que o NPAPI deixou de ser suportado por alguns navegadores, como o Google Chrome. Mesmo com Continue lendo→

Enfim o Form de Concurrents, ou Standard Request Submission (SRS), foi atualizado e recebeu algumas melhorias. O profissional Attiq Ahmed sugeriu essas melhorias para a Oracle e elas foram aceitas. Sem sombra de dúvidas, uma das mais interessantes é a opção de Auto Refresh na tela de visualização de concurrents, já que praticamente todo profissional Oracle EBS tem a mania de clicar no botão de Refresh enlouquecidamente com frequência. É como se a quantidade de cliques e a velocidade dos mesmos acelerassem a execução do Continue lendo→