Carga em BD é um processo de preencher tabelas com dados já existentes, normalmente jogando os dados em um arquivo .txt e fazendo o up-load. Podemos também alimentar tabelas internas e/ou estruturas utilizando programas e assim fazer as cargas desses dados em tabelas ou transações existentes.
Atualmente já existem algumas ferramentas que fazem este up-load automaticamente, em alguns casos podemos também fazer o up-load diretamente via código puxando dados de um outro BD já existente.
Alguns tipos de cargas existentes no SAP:
1 - Direct Input
Este tipo de carga não é utilizado pois não há uma consistência dos dados na inserção dos mesmos no SAP.
Se trata de uma gravação direta nas tabelas do sistema feita por um programa ABAP, essa técnica não é recomendada pela SAP para gravações em tabelas Standard devido a comprometer a integridade dos dados gravados pelas transações Standard.
Quando os dados são gravados eles não se propagam para as outras tabelas que manipulam os mesmos.
2 - Batch Input
O Batch Input é um processo de carga onde os dados não são inseridos diretamente em uma tabela, eles são carregados em transações.
Essas transações são indicadas no processo de Batch Input. Para cada transação diferente deve-se criar um novo Batch input. A partir do momento que
se manipula transações, evita-se o erro de inserção errada de dados nas tabelas pois o SAP trata da propagação desses dados dentre as várias tabelas utilizadas.
O mapeamento dos campos que serão manipulados nas transações pode ser feito de duas formas:
• Transação SHDB: Nesta transação efetua-se o mapeamento de todos os campos a serem utilizados na execução do Batch Input. É normalmente o método mais utilizado.
• F1 + F9: Utilizado quando a transação SHDB não está disponível, um pouco mais trabalhoso de se usar pois cada campo será mapeado individualmente, em cada campo a ser manipulado vou ter que pressionar essas teclas para efetuar a verificação.
No Batch Input podemos fazer uma leitura de um arquivo .txt que conterá os dados a serem inseridos nas transações, para isto utiliza-se a função WS_UPLOAD. Quando o up-load é efetuado a tabela BDC serve como interface entre o .txt e as transações, efetuando assim o gerenciamento dessa operação de carga, incluindo neste momento a manipulação dos campos e seus respectivos usos.
Podemos também fazer o carregamento da tabela BDC através de seleções de dados e append em tabelas internas que servirão de passagem de dados para a BDC.
A grande vantagem de utilização do Batch Input deve-se ao fato de que a carga não precisa ser efetuada no momento da criação da pasta que o conterá.
A pasta pode ser criada em um dado momento e em outro processá-la, o processo em si pode ser executado de diferentes formas, seja ele com a intervenção do usuário, oculto (sem intervenção) ou então somente o usuário intervir quando der um erro.
3 – Call Transaction
Normalmente utilizado como uma alternativa ao Batch Input, possui características próprias, mas também pode se utilizar do batch input para ser efetuado de uma forma mais “rápida”.
No call transaction existe uma transferência direta dos dados em contraste ao batch input. Para armazenar dados de tela temporariamente é usada uma tabela interna (tabela BDC com a mesma estrutura do batch input), a transação é
chamada no programa e o sistema importa os dados temporariamente armazenados na tabela BDC para as telas de transação.
Um programa de CALL TRANSACTION tem uma estrutura similar a do BATCH INPUT.
Chamada:
CALL TRANSACTION ‘nnnn’ USING a MODE b UPDATE ‘c’ MESSAGES INTO d.
Onde:
- ‘nnnn’ = número da transação - ‘a’ = tabela BDC – vide B.I. - Mode:
A (default) O sistema mostra todas as telas com seus dados. N O sitema não mostra as telas logo após a transação ter sido processada, existe um retorno do controle programa (o valor de UPDATE determina se haverá atualização no BD)
E Logo que um erro ocorre na tela o sistema devia para o modo A para que sejam efetuadas as correções.
- Update:
‘c’ Controla como as atualizações do BD chamadas pela transação são executadas.
Divide-se em 3 modos:
A (Atualização assíncrona) A transação chamada não aguarda até que o BD atualize o que tem que ser executado mas passa a atualização para o SAP UPDATE TASK, o programa de Batch Input será executado mais rápido porém não se terá um retorno se a atualização foi bem sucedida no BD.
As ferramentas de análise e correção de erros não são tão simples de se uasr quanto as do modo síncrono.
S (Atualização síncrona) A transação chamada aguarda até que a atualização esteja finalizada, o processamento por motivo dessa espera fica um pouco mais lento do que no modo assíncrono porém esta transação pode listar erros caso aconteça algum na execução, simplificando desta forma a análise e correção dos mesmos.
L (Local) O BD é atualizado na chamada do processo do programa.
- Messages Into <it_table>: Especifica que todas as mensagens geradas pelo sistema através do CALL TRANSACTION serão armazenadas na
tabela interna especificada, esta tabela interna obrigatoriamente deverá ter a estrutura: BDCMSGCOLL .
4 – BAPI
BAPI é uma ferramenta de carga de dados criada a partir da versão 4.0 e mais comumente usada a partir da 4.5. Trata-se de um conjunto de funções Standard criadas pela SAP que realizam de forma invisível o preenchimento dos dados necessários a determinadas transações Standard para a criação ou modificação de dados nessas transações sejam feitas de forma correta e consistente.
Internamente as BAPIs agregam diversos elementos de orientação a objetos e não permitem que a codificação da mesma seja alterada.
Devemos então passar parâmetros como tabelas e estruturas preenchidas corretamente de acordo com a necessidade de cada transação e regra de negócio.
Através da transação BAPI podemos visualizar as BAPIs disponíveis e temos também uma listagem com a descrição dos parâmetros a serem preenchidos para cada BAPI.
Se torna fundamental o acompanhamento do consultor funcional para podermos distinguir todos os campos/parâmetros que deveremos informar para o correto funcionamento da regra de negócio.
Exemplos de uso:
Criação de pedidos de compra; Criação de material;
Entrada física em estoque; Entrada fiscal em estoque; Etc...
SAPSCRIPT:
É a forma de imprimirmos em formulários customizados. Podemos criar formatos de páginas, tipos de parágrafo, tipos de caracteres de forma a exibirmos em tela ou em papel formulários completamente customizados de acordo com a real necessidade da aplicação.
Como exemplos de SAPscript tradicional temos o formulário de nota fiscal e o pedido de compra. Cada empresa pode utilizar um lay-out diferente e pessoal para a saída de sua nota fiscal de acordo com um modelo qualquer. Temos então alguns relatórios com formulários SAPscripts que podem seguir lay-outs estabelecidos.
Com a transação se 71 podemos criar um formulário de SAPscript.
Devemos informar no - cabeçalho -> configurações globais – o Formato de Página que é uma configuração de tamanho de página que é configurado e criado por BASIS na transação SPAD.
Assim para começarmos a criação de um formulário devemos saber em primeiro lugar qual o formato de página utilizar. Podemos utilizar um já existente ou teremos que fazer contato com a equipe de BASIS para ser criado um formato de página específico.
Informaremos ainda o alinhamento (vertical ou horizontal), os tamanhos do caracter, as distâncias de tabulador, a fonte padrão utilizada e variações como sublinhado, itálico e negrito.
Os formulários são divididos em páginas e janelas, sendo que a cada página são atribuídas as janelas que constarão da mesma. Ou seja, cada página deverá ter uma ou mais janelas associadas. E devemos ter ao menos uma janela de nome MAIN que indentificará a janela principal do formulário, onde as informações mais relevantes do formulário serão impressas.
Podemos criar formulários de SAPscripts para diversas aplicações não standards do SAP, ficando a critério de desenvolvimentos adicionais a criação dos programas e desenho do formulário. Temos então uma nomenclatura básica para a chamada, utilização e exibição via programa dos formulários de SAPscript:
Utilizaremos por padrão as seguintes funções:
1 – OPEN_FORM
CALL FUNCTION 'OPEN_FORM' EXPORTING device = 'PRINTER' dialog = 'X' EXCEPTIONS canceled = 1 device = 2 form = 3 options = 4 unclosed = 5 OTHERS = 6.
Utilizada para abertura do formulário, onde:
Device = Dispositivo de saída – por padrão ‘PRINTER’ Dialog = Abrir caixa de diálogo de impressão de SAPscript. 2 – START_FORM
CALL FUNCTION 'START_FORM' EXPORTING form = 'Z_SAPSCRIPT_CURS' EXCEPTIONS form = 1 format = 2 unended = 3 unopened = 4 unused = 5 OTHERS = 6.
Utilizada para informarmos o nome do formulário, onde: Form = Nome do formulário SAPscript.
3 – WRITE_FORM
CALL FUNCTION 'WRITE_FORM' EXPORTING window = 'CABEC' element = 'TEXTCB' EXCEPTIONS element = 1 function = 2 type = 3 unopened = 4 unstarted = 5 window = 6 OTHERS = 7.
Utilizada para chamar a janela e o elemento da janela corresponde no formulário, onde:
Windown = Nome da janela do formulário SAPscript. Element = Objeto ELEMENTO criado dentro da janela.
4 – END_FORM
CALL FUNCTION 'END_FORM' EXCEPTIONS
unopened = 1 OTHERS = 2.
Utilizada para informarmos que o formulário não está mais em uso.
5 – CLOSE_FORM
CALL FUNCTION 'CLOSE_FORM' EXCEPTIONS
unopened = 1 OTHERS = 2.
Utilizada para fechamento do formulário SAPscript.
• Utilizaremos para exemplo o programa: Z_SAPSCRIPT_CURSO e o
formulário Z_SAPSCRIPT_CURS.
Vale ressaltar ainda que na transação SE71 temos a opção Utilitários – Ativar depurador.
Essa opção liga o debuger de SAPscript que se apresenta num lay-out um pouco diferente do debuger conhecido para programas. Vale a pena então ativar o debuger de SAPscript e vermos como ele se comporta.
Exercício:
Criar um report onde:
Informado o código do aluno, o report deverá chamar um formulário de sapscript e imprimir 3 janelas onde:
Primeira janela:
RELATÓRIO DE ALUNO Código do Aluno: XXX
Segunda janela (janela MAIN):
Nome do aluno : XXXXXXXXX Classe : XXXX
Sexo : X
Terceira janela
Rodapé do relatório Data: XX/XX/XXXX. Hora: XX:XX:XX
• Todas as 3 janelas deverão ter BOX (quadrado separador com os textos dentro).