Cluster de visão e Atualização de duas etapas

Olá,

Como comentado no post anterior, se tudo desse certo, eu subiria alguns print's referentes a estes dois pontos. Trata-se do Cluster de visão e Visão de atualização de duas etapas.

Foi um pouco trabalhoso quanto à construção, mas no final deu tudo certo. Algumas vantagens que vale a pena destacar em relação a utilização do cluster de visão.

• Navegação: num cluster de visões, é possível navegar confortavelmente entre os diálogos de atualização individuais, simplificando a atualização dos dados em um cluster de visões.
• Consistência: com eles é possível assegurar a consistência dos dados quando eliminamos, copiamos, gravamos, recuperamos e transportamos manualmente. Desta forma, quando eliminamos uma entrada em uma visão superior, asseguramos automaticamente que todas as entradas dependentes em visões inferiores são também eliminadas.

Bom, vamos aos print's...

Bom, basicamente é isso aí.
Um abraço!

Visões e Diálogos de atualização (Parte 2/2)

Olá,

Este post aborda a segunda parte sobre Visões de tabela e Diálogos de atualização. No post anterior, abordei as Visões de tabela. Agora, será a vez das Visões de atualização.

Criação de visões de atualização: Os dados que estão distribuídos em mais de uma tabela formam o que chamamos de objeto de aplicação para o usuário. Nele poderíamos exibir, modificar e criar os dados de um objeto de aplicação, em conjunto. Contudo, o usuário geralmente não está interessado na implementação técnica do objeto de aplicação, como a distribuição dos dados em N tabelas.

Através da visão de atualização podemos atualizar objetos de aplicação complexos de maneira simples, sendo que dados são automaticamente distribuídos entre as tabelas de BDs e todas as tabelas utilizadas em uma visão de atualização devem estar ligadas com uma chave externa. Não se pode entrar diretamente com a condição JOIN, tal como acontece em uma visão de banco de dados. Quando uma visão de atualização é criada, são gerados automaticamente módulos de função que distribuem os dados atualizados com a visão nas tabelas. Para a interface de atualização, utilizando o tcode SE54.

Em visão de atualização de uma etapa, os dados das linhas de tabela são representados como TableControl. Os campos-chave têm um fundo cinza e não podem ser alterados. Os campos de função têm um fundo branco e podem ser alterados.

Já se criarmos uma visão de atualização de duas etapas, pode ser aberta outra tela, efetuando clique duplo em uma linha de tabela na qual o registro de dados selecionado é apresentado de modo claro.

A seguir, alguns print's com um exemplo de atualização simples.

Vantagens e desvantagens de uma visão de atualização simples:
+ Eles podem ser criados em um período de tempo breve.
- Sem atualização assíncrona.
É somente indicado para tabelas do customizing e do cliente.

Há também opção de atualização de duas etapas e clusters de visões que não abordei com print's neste post. Enfim, o assunto não pára. Se tudo der certo, numa próxima atualização no Blog, tratarei de colocar algo relacionado a estes dois últimos pontos que cito.

Bom, basicamente é isso.
Um abraço e bom final de semana!

Visões e Diálogos de atualização (Parte 1/2)

Olá,

Neste post falarei um pouco sobre Visões de tabela. Na parte 2, falarei um pouco sobre Diálogos de atualização. Estes pontos são uma continuidade sobre o tema ABAP Dictionary.

Por que necessitamos de visões?  Geralmente os dados para um objeto de aplicação são, muitas vezes, distribuídos em N tabelas. Por essa razão, os SGBD's fornecem uma forma de definir visões específicas em dados de várias tabelas. Elas são chamadas de visões.

Das visões restritas ou ampliadas em tabelas de BD, temos o seguinte:

• JOIN: Combinação de dados de várias tabelas de uma maneira significativa;
• PROJEÇÃO: Ocultação de informações nas quais não há interesse;
• SELEÇÃO: Exibição de apenas registros de dados que atendem determinadas condições.

Uma visão de BD é definida no ABAP Dictionary e criada automaticamente no BD durante a sua ativação. Os acessos a uma visão de BD são transferidos diretamente para o BD pela sua interface. O SW de BD efetua a seleção de dados. Se a definição de uma visão de BD for modificada no ABAP Dictionary, a visão criada no BD é eliminada efetuando assim o ajuste a essa modificação. Isso ocorre, em razão da visão não conter dados como uma tabela.

Anexação dinâmica de campos de tabela em visões: Podemos incluir tabelas inteiras em visões de BD. Neste caso, todos os campos da tabela incluída se tornam campos da visão. Se forem incluídos novos campos na tabela ou se os campos  forem eliminados, a visão é automaticamente ajustada a essa modificação;  Já se uma estrutura append for adicionada a uma tabela incluída em uma visão, os campos adicionados com a estrutura append são automaticamente incluídos na visão. 

Uma visão append está atribuída a EXATAMENTE UMA visão de BD. Pode ser criada mais de uma visão append para uma visão de banco de dados.

A seguir, mostro alguns print's com um exemplo de visão criada a partir do exercício proposto pelo material que estou estudando. Aqui, a ideia é montar uma view adequada, a fim de satisfazer as necessidades do setor de RH, pois se faz necessário exibir alguns dados dos funcionários. Vamos aos print's:

Como pode ver, foi criado uma view e posteriormente realizada uma configuração para somente um setor ser selecionado com tal visão. Como não havia dado algum com o parâmetro inicial (no caso, 'F'), alterei o mesmo para mostrar o do tipo 'A', onde então foi possível visualizar um registro de acordo com o critério de pesquisa. Por fim, armazenado em buffer a visão gerada.

No próximo post, darei uma continuidade abordando a parte 2.
Um abraço e até lá!