Academia Basis

Semana 1 – 26/01/2000 a 28/01/2000 (Vera)

José Roberto A. de Lima – SAP Brasil
Índice

ACADEMIA BASIS 1
Semana 1 – 26/01/2000 a 28/01/2000 (Vera) 1

Índice 2

BASIS SYSTEM AND THE SYSTEM ENVIRONMENT 4

The Integration Model 4

Business Framework Architecture 4

R/3 as an Open System 5

Scalability and the Client/Server Concept 5

The Middleware Basis 6

Portability and System Plataforms for the R/3 System 7

NAVIGATION 8
Logging onto R/3 System 8

R/3 Menu Structure 8

SYSTEM KERNEL 10
R/3 Presentation Interface 10

R/3 Database Interface 10

Work Processes and Dispatcher 10

R/3 Application Services 11

R/3 Transaction and LUW 12

Lock Concept and Asynchronous Update 13

Background Processing 14

R/3 Printer Services 15

R/3 Instance 15

INTERFACES 16
R/3 as an Open System 16

R/3 Gateway Service 16

Communication with CPI-C 16

Remote Function Call 17

Business Objects and BAPIs 18

R/3 System as an OLE Server or an OLE Client 18

Internet Architecture 19

EDI Architecture 19

Distribution of Business Processes with ALE 19

Data Transfer and Batch Input 20

R/3 GRAPHICAL USER INTERFACE 20

Frontend Administration 20

Frontend Requirements 20

SAPGUI Installation 21

Types of Online Help 21

SAPLOGON 22

SAP MAPI 23

SAP ONLINE SERVICE SYSTEM (OSS) 23

OSS Overview 23

OSS Functionality 23

OSS Access 23

SAPNet 24

SAP TechNet 24
Basis System and the System Environment

The Integration Model

 O Sistema R/3 é composto dos seguintes módulos:
Logística
SD – Sales & Distribution
MM – Materials Management
PP – Production Planing
QM – Quality Management
PM – Plant Maintenance

Human Resources
HR – Human Resources

Accounting
FI – Financial Accounting
CO – Controlling
TR – Treasury
PS – Project System

Industry and Cross-Application

WF – Workflow
IS – Industry Solutions
 A camada Basis integra todos estes módulos. É a parte central do “diamante” do
diagrama do R/3

Business Framework Architecture

 Business Framework Architecture (BFA) é a arquitetura estratégica do produto R/3. Ela
trabalha com business components que são os módulos funcionais (FI, CO, etc.)
configuráveis para se adaptar a cada empresa.
 Esta arquitetura fornece agilidade para se adaptar a um novo negócio, além da
facilidade de se integrar com pacotes externos e fácil integração com a internet e
intranet, permitindo desta forma uma fácil evolução sem a interrupção da operação do
negócio da empresa.
 O Business Framework se mostra no R/3 como uma família de componentes separados
porém integrados entre si. Estes componentes são:
 Business Components: são os módulos funcionais (FI, CO, etc.)
 Business Objects: Ordem, Empregado, Material, etc.

Academia Basis – Semana 1 - 26/01 a 28/01/2000 Pag. 4

José Roberto A. de Lima – SAP Brasil
  BAPI Interfaces: São os métodos com que os objetos de negócio são
implementados dentro do R/3 (criar uma ordem, alterar o endereço de um
empregado, etc.)

R/3 as an Open System

 O R/3 utiliza protocolos standard da industria para garantir a integração com outras
aplicações:
 TCP/IP: é o protocolo de comunicação
 EDI: Electronic Data Interchange, é o mecanismo utilizado para trocar informações
de negócio com diferentes sistemas
 OLE: Object Linking and Embendding, integra aplicações PC com o R/3
 Open Interfaces, tais como arquivamento ótico, dispositivos de códigos de barras,
etc.
 Além de standards da indústria, o R/3 também utiliza protocolos proprietários para
comunicação:
 RFC: Remote Function Call, que utiliza o protocolo CPI-C standard da IBM para
comunicação e processamento das aplicações e tasks dentro do sistema R/3 ou com
o sistema R/2 ou outros sistemas.
 ALE: Application Link Enabling permite o processamento distribuído dentro do
R/3

Scalability and the Client/Server Concept

 O R/3 permite a sua implementação quer seja em uma configuração centralizada quer
seja em uma arquitetura totalmente distribuída client/server em vários servidores
dedicados.
 Esta arquitetura permite que se separe a lógica da aplicação da base de dados e da
camada de apresentação. Esta configuração permite ainda otimizar os custos e distribuir
a carga através de configurações variadas de hardware. Com isto é possível dimensionar
os servidores de acordo com a carga, permitindo a fácil escalabilidade do ambiente.
 Os ganhos nesta arquitetura na implementação R/3 são muitos:
 Simples instalação de novos servidores para atender gargalos
 Servidores trabalham em paralelo, com carga homogênea e execução local dos
programas.
 Baixo tráfego de rede com a localização dos buffers de dados e programas próximo
de onde serão utilizados
 Balanceamento de carga, seja para o processamento online (logon) seja para o
processamento batch
 Na implementação R/3, a arquitetura clint/server é orientada para o software, e não para
o hardware como estamos acostumados a ver. Desta forma, Client é quem requisita e
utiliza o serviço e Server é quem vai fornecer determinado serviço.

Academia Basis – Semana 1 - 26/01 a 28/01/2000 Pag. 5

José Roberto A. de Lima – SAP Brasil
 Um servidor de aplicação por exemplo é server de alguns serviços das estações clients,
porém é client dos serviços fornecidos pelo servidor de banco de dados.
 Os serviços (ou camadas) fundamentais de uma aplicação são três: Presentation,
Application e Database services.
 Existem várias formas de se implementar um sistema R/3:
 Central, onde todos os componentes estão implementados em um mesmo host. Esta
implementação corresponde a clássica implementação mainframe.
 Two-tier, onde uma camada normalmente executa as funções de presentation
(usualmente um PC) e a outra camada executa os serviços de application e database.
Uma outra implementação two-tier poderia ser uma camada executando os serviços
de database e a outra composta por PCs mais potentes que executariam as funções
de presentation e application. Esta última implementação é normalmente utilizada
em simulações ou desenvolvimento de software.
 Three-tier, onde cada serviço tem o seu próprio host. Nesta configuração é possível
ainda assegurar uma divisão de carga na camada de aplicação, garantindo que
determinados hosts fiquem dedicados para aplicações específicas. Por exemplo
dedicar um host para servidor de aplicação dos usuários de MM, ganhando com isto
performance na distribuição dos serviços.
 A configuração three-tier é a mais recomendada em R/3 por garantir a melhor
distribuição de carga e escalabilidade nos grandes sistemas
 Todos os servidores em uma configuração R/3 devem possuir endereço de IP fixo
 Um sistema R/3 agrupa todos os componentes que estão associados com um banco de
dados. Se utilizamos uma implementação em 3 camadas, os componentes do R/3
estarão presentes em todas as camadas da hierarquia:
 O Database Server, é instalado em um host central, onde todos os serviços de
bancos de dados serão executados.
 Um ou mais Application Servers conectados ao servidos de banco de dados.
Nestes servidores estarão sendo processados a lógica da aplicação, ou seja, os
programas.
 Vários Presentation Servers conectados aos servidores de aplicação. Estas
máquinas são também chamadas de frontends ou workstations. Nestas máquinas os
usuários irão interagir com o sistema R/3 utilizando uma interface que proverá os
serviços de presentation.

The Middleware Basis

 O software Basis do R/3 (também chamado de middleware) roda em diferentes
plataformas e também pode ser adaptado para atender as necessidades individuais das
empresas. São vários os serviços que ele presta:
 Provê o ambiente de runtime para as aplicações R/3
 Cuida da perfeita interação das aplicações com o sistema
 Define uma arquitetura estável para as melhorias do sistema
 Contem todas as ferramentas necessárias para a administração do ambiente
 Permite a distribuição equitativa dos recursos e componentes do sistema
Academia Basis – Semana 1 - 26/01 a 28/01/2000 Pag. 6
José Roberto A. de Lima – SAP Brasil
  Provê as interfaces necessárias para os sistemas descentralizados e os produtos
externos ao R/3
 As principais características da tecnologia Basis são:
 É uma arquitetura voltada para a configuração client/server
 Trabalha com bancos de dados relacionais
 Possui interface gráfica com o usuário (GUI)

 O Basis é o responsável ainda pela integração dos aplicativos e do ABAP workbench

com o software básico.

Portability and System Plataforms for the R/3 System

 Para garantir uma alta portabilidade, as interfaces com o software básico são divididas
em suas próprias camadas que variam de sistema para sistema (NT ou UNIX, Oracle ou
Informix, etc.). Acima destas camadas as funcionalidades dos componentes R/3 são
basicamente as mesmas, independentemente do hardware, software ou sistema
operacional.
 A System Interface é responsável pelo interfaceamento do R/3 com as diversas
plataformas em que ele pode ser implementado.
 O Flow Control fica logo acima das interfaces com o software básico (System
Interfaces). Ele é o responsável por tarefas tipo scheduling ou gerenciamento de
memória, tarefas estas muito próximas ainda do sistema operacional e que são
parcialmente efetuadas por ele, mas são gerenciadas pelo R/3 por razões de
portabilidade e performance.
 A User Interface provê as opções de apresentação dos aplicativos
 A Communication Interface é o canal para a troca de informações, seja pela
transferência de dados com o legado, seja pela comunicação program-to-program
provida pelo protocolo CPI-C ou ainda através da troca de informações pelo protocolo
EDI.
 Todos os programas no R/3 são escritos na linguagem ABAP, proprietária do sistema.
O DYNPRO é o screen interpreter e o sistema possui ainda um ABAP interpreter. A
interação entre estes dois componentes forma a tecnologia Basis das aplicações R/3. O
funcionamento destes dois interpretadores (tela e programa) se baseia em informações
armazenadas no dicionário do sistema, o ABAP Dictionary.
 O R/3 roda nos mais diversos hardwares, sejam plataformas Intel, Risc ou Unix
Systems
 Os sistemas operacionais são também os mais diversos, de acordo com as plataformas
utilizadas (AIX, Solaris, HP-UX, Windows NT, OS/400,etc.)
 Os bancos de dados utilizados pelo R/3, todos relacionais são: Oracle, Informix, MS
SQL Server ou ainda o DB2 para as diversas plataformas.
 O SAPGUI que faz a camada de apresentação possui versões para Windows (3.1, 95,
NT), OS/2 e Java
Academia Basis – Semana 1 - 26/01 a 28/01/2000 Pag. 7
José Roberto A. de Lima – SAP Brasil
 As linguagens utilizadas no R/3 são ABAP, C, C++, HTML e Java

Navigation

Logging onto R/3 System

 O R/3 é um sistema voltado para clients. Com este conceito é possível controlar várias
empresas em único sistema, separando-as por client (ou mandante)
 As chaves para se logar no sistema também são separadas por client. Para efetuar um
logon é preciso ter chave no client específico.
 Além disso o sistema exige uma password e por ser multilingua, deve-se ainda
especificar a lingua desejada no momento do logon.
 Um client pode ser visto como uma entidade organizacional separada dentro do R/3,
com seus próprios dados (master data, transaction data), user master records e
parâmetros específicos de customização.
 Apesar dos dados serem armazanados em tabelas únicas, os dados dos diferentes clients
coexistem separados pela diferenciação do campo MANDANT que faz parte da chave
da maioria das tabelas (client dependents).
 O conceito de customização é a adaptação do sistema R/3 para as necessidades
específicas de um usuário.
 Ao instalar um sistema R/3, ele vem basicamente com 3 clients default:
 000 é definido como um SAP standard é não deverá ser alterado pelos clientes,
devendo ser utilizado como um template para a criação de novos clients
 001
 066 utilizado pela SAP para se logar no ambiente do usuário para a execução de
determinadas tarefas
 Um client é identificado pelos três dígitos numéricos e, com exceção dos 3 citados
acima, cada instalação pode definir quantos clients se desejar (ou a sua base de dados
suportar)

R/3 Menu Structure

 Uma vez logado no sistema R/3 o sistema exibe um menu principal, onde temos as
principais áreas do R/3 (Logistic, Accounting, Human Resources) entre outras entradas.
Ao se escolher uma determinada entrada o sistema exibe um menu pull-down com
opções de cascading em algumas entradas.
 As opções System e Help são comuns a todas as telas do sistema
 Um nível abaixo fica o menu específico de cada aplicação, que exibe as funções básicas
disponíveis para aquele sistema (criar um registro, por exemplo)

Academia Basis – Semana 1 - 26/01 a 28/01/2000 Pag. 8

José Roberto A. de Lima – SAP Brasil
 O Dynamic Menu disponível na tela inicial dá a opção de navegar em todas as opções
disponíveis no formato de árvore do explorer, podendo selecionar a função desejada. É
uma ferramenta que permite efetuar searchs por palavras chave
 Uma tela típica do sistema R/3 possui as seguintes partes:
 Title Bar, exibe o título da task que está sendo executada
 Command Field, onde se pode escolher uma task diretamente sem a necessidade de
navegar no menu
 Options, o mickey, onde se pode configurar a interface SAPGUI de acordo com
necessidades individuais dos usuários
 Standard Toolbar, onde se encontram os ícones mais frequentemente usados para
navegação no sistema, bem como ícones para salvar dados e ativar o online help
 Checkboxes, Radio buttons, Text boxes e outras interfaces comuns no ambiente
windows para a exibição de dados
 Status bar, exibe informações referentes ao status atual do sistema (session
number, system name, application server, worksation’s time, além de mensagens de
interação com o usuário.
 Text box inicializados com interrogação (?) são de preenchimento obrigatório
 Uma tela no R/3 pode ser acessada de 3 maneiras distintas:
 Selecionando a opção no menu
 Através de teclas de atalho (ALT + tecla)
 Através do código da transação diretamente digitado no command field

 O command field aceita vários comandos que funcionam em conjunto com o código da
transação
 /n para encerrar a transação atual
 /o para abrir uma nova sessão
 /i para encerrar a sessão corrente
 /nend e /nex para efetuar logoff no sistema com e sem prompt, respectivamente

 A tecla F1 ativa o help de campos, menus, funções e mensagens

 O help também exibe informações técnicas referentes aos campos de uma tela, como
por exemplo o parameter ID do campo que pode ser utilizado para customizar a tela
com parâmetros default do usuário. (F1 + F9 também exibe as technical infos)
 A tecla F4 exibe os valores possíveis em um campo, onde esta informação está
disponível (combo boxes)
 A opção System do menu é utilizada para exibir as tarefas comuns aos usuários do R/3
 A opção User profile  Own Data do menu System permite ao usuário especificar
valores defaults para seus campos, baseado no ID do campo (ver technical info)
 Na opção System é possível ainda configurar a lista de favoritos de cada usuário (User
Profile  Favorite maint)
 O Session Manager é uma ferramenta que permite ao usuário gerenciar todo o ambiente
e até mesmo vários sistemas de uma única interface. No release 4.0 esta ferramenta
ainda não se encontra em um estágio muito útil, mas cresceu muito no release 4.6
Academia Basis – Semana 1 - 26/01 a 28/01/2000 Pag. 9
José Roberto A. de Lima – SAP Brasil
System Kernel

R/3 Presentation Interface

 A interface de apresentação do R/3 é o SAPGUI que apresenta uma funcionalidade
muito parecida entre as diversas plataformas do R/3. Um usuário treinado em uma
determinada plataforma, salvo pequenas exceções está apto a operar o sistema nas suas
mais diversas implementações
 O fluxo de informação entre o SAPGUI e o servidor de aplicação não consiste de telas
preformatadas, mas sim de strings lógicos contendo dados e caracteres de controle, o
que faz com que o tráfego de dados se mantenha na casa de 1 a 2K por tela (cada enter)

R/3 Database Interface

 O R/3 trabalha com bases de dados relacionais, que são compostas de tabelas
bidimensionais e interagem com os sistemas através da linguagem padronizada SQL
(Structured Query Language) que é comum a todas as implementações de bases
relacionais, embora cada fabricante implemente algumas extensões no seu produto.
 O DB Interface é um módulo dentro do R/3 que converte os comandos SQL codificados
nos programas ABAP para o SQL nativo do banco implementado em cada ambiente
R/3. Ou seja, cada implementação (Oracle, Informix, SQL Server) possui um módulo
de DB Interface particular para aquela implementação, o que torna os programas ABAP
independentes da implementação do banco.
 Estes comandos SQL escritos no ABAP são denominados OPEN SQL e o DB Interface
é responsável pela sua correta transcrição para o SQL nativo do banco. Além disso, um
programa ABAP pode codificar o comando diretamente em Native SQL. Neste caso o
comando não passará pelo DB Interface, indo diretamente para a DB machine. Estes
comandos poderão não ser independentes do banco utilizado, se utilizarem extensões
particulares de um determinado RDBMS.
 Os comandos SQL escritos em OPEN SQL tem sua sintaxe verificada pelo DB
Interface que inicialmente faz um acesso no buffer interno do application server para
evitar acessos desnecessários ao DB server. Comandos escritos em native SQL não
fazem uso deste buffer interno, uma vez que o acesso não passa pelo DB Interface.

Work Processes and Dispatcher

 Os principais componentes de um application server são:
 Um dispatcher como o controle central da instance
 Dispatcher queues para enfileirar as requisições (FIFO)
 Um número configurável de work processes para processar os programas ABAP
 Buffers e shared memory

Academia Basis – Semana 1 - 26/01 a 28/01/2000 Pag. 10

José Roberto A. de Lima – SAP Brasil
 Os work processes são serviços dentro de um sistema R/3 especializados em
determinadas tarefas.
 O centro de um sistema R/3, a nível de controle de aplicação, é o Dispatcher. Ele,
juntamente com o sistema operacional, é o responsável pelo controle e disponibilização
dos recursos do sistema.
 Suas principais tarefas são o controle da comunicação, a conexão com o presentation e
a distribuição de carga entre os work processes.
 O dispatcher distribui os serviços requisitados entre os WP disponíveis e se encarrega
de enviar o dado processado para o SAPGUI, que deverá interpreta-lo e exibir para o
usuário.
 Não existe um WP fixo para um determinado usuário, cuidando o dispatcher de ir
utilizando-os conforme as requisições vão chegando, em um processo de fila FIFO
 Quando um sistema R/3 é inicializado, o dispatcher é o responsável por ler os
parâmetros de configuração (profiles), gerar as rol areas, inicializar os work processes e
se conectar com o message server da central instance.
 Cada dialog work process é coordenado por um componente interno denominado Task
Handler. Ele ativa o screen processor ou o ABAP processor e é ainda o responsável
pelo roll in e rool out das áreas de usuário.
 Existem memórias de uso exclusivo de um determinado work process e memórias que
podem ser compartilhadas por todos eles. Esta diferenciação é gerenciada pelo memory
management. A memória utilizada exclusivamente por um work process possui duas
áreas reservadas para dados específicos de uma determinada sessão de usuário (user
context area) e devem ser mantidas entre as pseudo conversas do dialog. Estas áreas são
denominadas roll e paging areas. A roll area contem dados que ficam imediatamente
disponível para o processamento no início do dialog step (roll in) e é salva novamente
no final do dialog step (roll out).
 Este mecanismo de roll in e roll out é que permite o share dos work process permitindo
o compartilhamento do recurso entre todos os usuários. Nesta área são salvos os dados
referentes ao usuário (user context) tais como suas autorizações, informações
administrativas além de dados adicionais para o ABAP e dialog processors, que são
dados que já foram coletados por dialog steps anteriores.
 Na shared memory existem dados disponíveis para todos os work processes, tais como
o calendar, screen, table e program buffers.

R/3 Application Services

 Um sistema R/3 é composto de uma série de work processes que funcionam em paralelo
cooperativamente. Cada application server possui um dispatcher e um número
configurável destes processos, que depende dos recursos disponíveis no host
(basicamente memória e processamento). Work processes podem ser instalados para
efetuar serviços de dialog, update, backgrond e spool

Academia Basis – Semana 1 - 26/01 a 28/01/2000 Pag. 11

José Roberto A. de Lima – SAP Brasil
 Uma central instance possui ainda serviços de enqueue para gerenciamento de lock e
dois outros serviços próprios:
 O Message Server responsável pelo serviço de comunicação entre os vários
dispatchers que compõem um sistema R/3, que é portanto um pré requisito para a
escalabilidade de vários servidores de aplicação trabalhando em paralelo.
 O Gateway Server, também chamado de CPI-C handler, que permite a comunicação
entre R/3, R/2 e aplicativos externos.

R/3 Transaction and LUW

 Transações são unidades de processamento agrupadas em funções que executam
alterações consistentes na base de dados, de acordo com a funcionalidade a que se
propõem. Um exemplo típico seria o débito em uma conta para crédito em outra, que
somente fazem sentido consistente quando executadas como um todo.
 Uma transação SAP é implementada através de uma série de dialog steps consistentes e
conectados de forma coerente.
 Uma transação SAP não executa necessariamente em um único work process, uma vez
que cada um dos seus dialog steps poderão estar sendo atendidos por WP diferentes que
o dispatcher encontrou disponível em cada momento. Além disso, quando se utiliza o
asynchronous update para processar as atualizações da base de dados, estes processos
estarão sendo atendidos por outros work process que poderão inclusive se encontrar em
outros hosts.
 No R/3 cada dialog step é composto de um processamento que inicia após o usuário
entrar o dado (PAI – Process After Input) e pelo processamento e envio da próxima tela
(PBO – Process Before Output).
 Do ponto de vista do usuário, cada dialog step começa com o preenchimento de uma
tela e o posterior processamento até o envio da próxima tela. Para o sistema apenas as
partes referentes ao processamento (PAI e PBO) compõem o dialog step já que durante
o preenchimento da tela nenhum processamento será requerido.
 Este conceito de transação, que pode compor de um ou vários dialog steps, é chamado
de LUW, ou Logical Unit od Work.
 Como os bancos de dados não suportam o conceito de transação para todos os processos
(begin/end transaction commands), é necessário saber diferenciar uma transação do
ponto de vista SAP (SAP-LUW) de uma transação de banco de dados (DB-LUW) que é
totalmente executada ou totalmente desfeita. Não existe meio termo numa DB-LUW.
 Enquanto uma SAP-LUW garante a integridade lógica do banco de dados (um
determinado lançamento deverá existir nas tabelas x, y e z), uma DB-LUW garante a
integridade física do DB e é executado necessariamente pelo gerenciador do banco.
 Uma transação SAP inicia uma SAP-LUW que somente termina ao encontrar um
comando COMMIT WORK no programa ABAP ou então no final do asynchronous
update.

Academia Basis – Semana 1 - 26/01 a 28/01/2000 Pag. 12

José Roberto A. de Lima – SAP Brasil
Lock Concept and Asynchronous Update
 A técnica principal utilizada numa SAP-LUW é a atualização assíncrona, onde as
requisições de update na base de dados são coletadas separadamente e iniciam após o
COMMIT WORK, onde são executadas em uma única DB-LUW para garantir a
integridade do banco.
 Os mecanismos de lock existentes nos gerenciadores de bancos de dados não são
suficientes para garantir a correta manipulação dos objetos de negócio, que muitas
vezes envolvem uma série de tabelas em um único lançamento. Com o seu próprio
mecanismo, O R/3 assegura que determinados dados permaneçam protegidos durante
todo o processo de atualização do objeto.
 Esta tarefa é executada pelo Enqueue Work Process que utiliza uma tabela armazenada
na memória principal (de onde o enqueue work process está rodando, normalmente a
central instance) para este gerenciamento.
 Sempre que um lock é requisitado o sistema verifica (através do enqueue wp) se a
requisição não fere outro lock já postado na tabela. Havendo colisão de interesses, o
processo é informado através de uma mensagem de erro, o que permite ao programa
ABAP informar ao usuário que a sua operação não poderá ser executada no momento.
 Caso o enqueue work process não se encontre na mesma instance em que o processo
está correndo, o que é normal em uma aplicação three-tiers, esta comunicação é
efetuada pelo message server.
 Para que este mecanismo de requisição de lock funcione no sistema R/3, é necessário
que um objeto de lock seja definido no dicionário ABAP especificamente para aquele
objeto que se deseja travar.
 Já existem objetos definidos em uma tabela primária no dicionário do R/3, porém o
usuário pode definir seus próprios objetos em tabelas secundárias (estes objetos do
usuário precisam ter seus nomes começados por “EY” ou “EZ”.
 Os locks podem ser do tipo “S” (read) ou “E” (write). Um lock do tipo E somente
poderá ser postado se não existe nenhum outro lock já definido sobre o registro.
 Quando um objeto de lock é ativado, o sistema gera duas funcion modules, uma para
ENQUEUE_<object> e outra para DEQUEUE_<object>
 Os lock postados por um programa permanecem até que sejam retirados pelo próprio
programa ou ainda pelo procedimento de update (segunda parte da SAP-LUW).
 Work processes podem gerar atualizações diretamente na base de dados mesmo que o
banco não se encontre no mesmo host.
 Quando o programa ABAP utiliza os comandos CALL FUNCTION ‘...’ IN UPDATE
TASK, é criado no R/3 o mecanismo de asynchronous update. Neste caso a requisição é
direcionada para uma tabela (a VBLOG) existente fisicamente no banco de dados que
age como um buffer intermediário onde as requisições de atualização são enfileiradas.
 Esta tabela contém basicamente o nome da rotina que será disparada para efetuar a
atualização e os dados (parâmetros) para a rotina efetuar as atualizações necessárias.
Academia Basis – Semana 1 - 26/01 a 28/01/2000 Pag. 13
José Roberto A. de Lima – SAP Brasil
 Transações que são canceladas pelo usuário não tem o seu registro de header
completado na VBLOG e portanto suas atualizações não são efetuadas.
 Os registros de atualização podem ser divididos em componentes V1 e V2.
Basicamente processos que são críticos são armazenados em componentes V1 e
processos secundários que são menos time-criticals são armazenados nos componentes
V2. Informações de estatísticas caem nesta segunda categoria.
 O processo assíncrono de update é disparado pelo comando COMMIT WORK
especificado no último dialog step de uma SAP transaction.
 Nesta fase que ocorre na segunda parte da SAP-LUW, os registros escritos na VBLOG
são recuperados e atualizados fisicamente na base de dados.
 Caso ocorram erros nesta fase em processos V1, as alterações no DB daquela DB-LUW
são desfeitas por rollback e os registros permanecem na VBLOG assinalados com um
flag de erro. Caso ocorram erros em processos V2, apenas aquele registro será setado
com erro e as demais atualizações V2 continuam sendo executadas.
 Quando ocorrem os error descritos acima, o usuário é notificado através de mail e
medidas corretivas precisam ser avaliadas.
 Ao término da SAP-LUW, a task de update remove os locks postados pelos dialog steps
anteriores. Caso ocorram erros durante o update os locks também serão removidos.
 Updates pendentes com erro podem ser restartados pelo administrador do sistema. A
SAP não recomenda que updates V1 sejam restartados, devendo este procedimento
somente ser efetuado para updates dos tipo V2. Processos V1 deverão ser regerados
processando novamente a transação (veja nota 16083)
 Quando um sistema R/3 sai, as entradas que estão com status INIT na VBLOG são
processadas tão logo o sistema retorne ao ar. Esta funcionalidade pode ser
parametrizada pela profile do sistema.

Background Processing
 Processos que são schedulados para processamento pelos background work processes
são tratados no sistema da mesma forma que os processos online.
 Processos background são schedulados na forma de jobs. Cada job possui um ou mais
steps (que podem ser external ou ABAP programs) que são processados
sequencialmente.
 Através das classes de processamento (A, B ou C) é possível setar prioridades entre os
jobs.
 Os jobs batch normalmente não são schedulados para processamento imediato, mas são
especificados para uma data/hora futura podendo ainda, quando necessário, serem
definidos como periódicos.
 O batch scheduler é o responsável pelo disparo automático dos jobs configurados no
sistema. Este módulo é um programa ABAP que roda em um dialog work process e ao
Academia Basis – Semana 1 - 26/01 a 28/01/2000 Pag. 14
José Roberto A. de Lima – SAP Brasil
 varrer a tabela de scheduling e encontrar um job candidato o encaminha para
processamento pelos background work processes.
 O sistema efetua balanceamento de carga para distribuir os jobs batch entre os diversos
servers que possuem work processes disponíveis (do tipo B). Jobs batch podem ainda
ser schedulados para processamento em servers específicos.
 Na escala de prioridade Jobs classe A tem maior prioridade que os classe B e por último
os jobs classe C. Dentro de um mesmo servidor e jobs schedulados com a mesma
classe, tem prioridade aquele schedulado com especificação explícita de server (sem
balanceamento)

R/3 Printer Services

 Spooling é a transferência bufferizada de dados para dispositivos de saída do tipo
printers, fax, etc. O R/3 suporta spooling para dispositivos locais ou em rede.
 As requisições de spool são geradas tanto pelo processamento online (dialog) quanto
pelo processamento batch (background). Os dados a serem impressos ficam
armazenados nos TemSe (Temporary Sequential Objects).
 Quando o sistema necessita de impressão, é gerado um spool request que é
encaminhado para um spool work process. Uma vez formatado o dado para impressão,
a requisição de impressão é encaminhada para o spool do sistema operacional, que fica
responsável pelo encaminhamento do spool para o dispositivo de saída.

R/3 Instance
 Uma instancia R/3 é uma unidade administrativa que combina componentes de um
sistema R/3 para prover um ou mais serviços. Todos os serviços providos por uma
instancia são iniciados (start da instancia) e parados (stop da instancia) ao mesmo
tempo.
 Uma instancia é parametrizada através de parâmetros que descrevem todas as suas
características.
 Cada instancia possui seus próprios buffers e um sistema R/3 central é composto de
uma única instancia que possui todos os serviços (DVEBMSGnn)
 O message server é o responsável pela comunicação entre os application servers e um
central message service para prover serviços de update trigger, enqueue e dequeue,
background requests, por exemplo.
 Cada dispatcher de um application server se comunica com um único message server
em cada ambiente R/3, que portanto só é instalado uma única vez na central instance.
Até mesmo os presentation (SAPGUI) poderão se logar nos application server através
do message server para desta forma efetuar balancemento automático de carga (load
balancing)

Academia Basis – Semana 1 - 26/01 a 28/01/2000 Pag. 15

José Roberto A. de Lima – SAP Brasil
 São as profiles que configuram as diversas instancias e desta forma definem quem
executa quais serviços.

Interfaces

R/3 as an Open System

 O R/3 é um sistema aberto que permite a comunicação com várias outras plataformas,
quer seja entre as instancias de um sistema R/3 ou com outros sistemas R/3, R/2 ou
sistemas não SAP através de rede
 Comunicação em rede pode ser dividida em 7 camadas, onde cada camada serve de
interface entre a camada de baixo e camada de cima. Do ponto de vista da programação,
desenvolver uma comunicação entre sistemas é mais fácil a medida que esta conversa é
implementada nas camadas mais superiores.
 A SAP suporta os protocolos TCP/IP e SNA LU6.2. A comunicação entre sistemas R/3
se dá em TCP/IP e a comunicação LU6.2 é utilizada para a comunicação com sistemas
R/2 baseados em mainframe.
 A programação R/3 suporta ainda CPI-C, RFC e OLE Automation como interfaces de
comunicação. Os dois primeiros protocolos são proprietários da SAP e o OLE é um
protocolo da Microsoft para a comunicação entre aplicativos na plataforma windows

R/3 Gateway Service

 O SAP Gateway é o CPI-C handler, responsável pela conexão entre os protocolos
TCP/IP e LU6.2, utilizado para a conexão entre sistemas R/3 e sistemas R/2 baseados
em mainframe
 O Gateway pode rodar tanto em um application server quanto em um database server
 Pequenas mensagens, como visto anteriormente, fluem entre os application e a central
instance em um sistema R/3 através do message server. Já os volumes mais elevados de
dados, tais como os dados da aplicação fluem através do gateway.
 Com isto podemos ver que a comunicação através do gateway tanto pode se dar dentro
de um sistema R/3 quanto entre um sistema R/3 e um sistema R/2 ou com programas
externos. O gateway utiliza o protocolo TCP/IP para comunicação com os clients e
LU6.2 apenas para a comunicação com mainframes.

Communication with CPI-C

 O CPI-C é um protocolo utilizado para a comunicação elementar program-to-program.
É utilizada basicamente para a comunicação entre sistemas R/2 e outros aplicativos
mainframe. É a implementação SAP da LU6.2

Academia Basis – Semana 1 - 26/01 a 28/01/2000 Pag. 16

José Roberto A. de Lima – SAP Brasil
 A comunicação faz uso dos verbos básicos da comunicação LU6.2 (INIT, ALLOCATE,
ACCEPT, SEND, RECEIVE e DEALLOCATE)
 É um protocolo de comunicação que exige que enquanto um parceiro esteja
transmitindo o outro se encontre em modo de escuta, e vice versa.
 Os parâmetros enviados pelo comando INIT são definidos através da tabela TXCOM e
mantidos pela transação SM54.

Remote Function Call

 O RFC é uma interface de comunicação baseada em CPI-C mas que possui mais
funções além de ser mais simples de se utilizar. Pode ser utilizada para a comunicação
entre sistemas R/3, R/3 com R/2 bem como aplicações externas.
 O RFC permite a chamada de subrotinas remotamente pela rede. Estas subrotinas são
chamadas de function modules. Estas funções possuem parâmetros e retornam valores
como qualquer outra função e são gerenciadas dentro do R/3 através de sua própria
function library, denominada Function Builder.
 O Function Builder (transação SM37) dá ao programador uma excelente ferramenta
para programar, documentar e testar as function modules, que tanto podem ser
chamadas em modo local quanto remotamente. O Sistema R/3 gera automaticamente
todo o protocolo necessário para a comunicação RFC entre os sistemas.
 Os requerimentos para o RFC são os mesmos para o CPI-C. Os parâmetros para a
comunicação RFC são mantidos través da transação SM59.
 O R/3 vem ainda acompanhado de uma biblioteca de funções C para comunicação
externa via RFC com o R/3, o RFC-SDK (Software Development System)
 O que diferencia uma chamada RFC local de uma remota é apenas o parâmetro
(destination) que especifica onde o comando será executado
 Existem três tipos de chamadas RFC
 Synchronous RFC call, onde o programa que emitiu a chamada suspende a
execução até o retorno da chamada
 Asynchronous RFC call, onde a função chamada roda em paralelo e independente
do programa que emitiu o comando. O programador fica responsável pela conexão
lógica dos resultados obtidos
 Transactional RFC call, onde várias funções são agrupadas em uma única transação
que é executada no sistema remoto como uma única LUW na sequencia com que
elas foram codificadas. Caso ocorra um erro, o sistema que emitiu o comando
recebe um código de retorno que pode ser consultado pela transação SM58. Ainda
neste caso o sistema destino não precisa estar disponível no momento em que o
comando é emitido, podendo ainda ser parametrizado o intervalo entre os queries.

Academia Basis – Semana 1 - 26/01 a 28/01/2000 Pag. 17

José Roberto A. de Lima – SAP Brasil
Business Objects and BAPIs
 Os business objects formam a base para a comunicação em alto nível no sistema R/3,
tornando possível por exemplo implementações R/3 na internet e tem as seguintes
características:
 Formam a base para uma bem sucedida comunicação em sistemas client/servers
 São orientados ao negócio. Existem BAPIs chamados Customer, Order, etc.
 Possui métodos, que são os business functions que facilitam e padronizam a
utilização destes objetos
 São gerenciados internamente pelo R/3 em uma biblioteca central, a Business
Object Repository, ou BOR
 As BAPIs (Business Application Programming Interfaces) são interfaces funcionais que
utilizam business methods para executar funções de negócio. Elas podem ser chamadas
tanto pelos programas R/3 quanto encapsuladas e instanciadas por programas externos.

R/3 System as an OLE Server or an OLE Client

 O OLE (Object Linking and Embedding) é uma forma de comunicação entre programas
orientada para objeto. Com isto é possível conectar aplicações desktop que utilizam
OLE2 (Word, Excell, etc.) com o sistema R/3
 Quando o sistema R/3 está agindo como um client OLE, o usuário chama o programa
(word, excell) de dentro do programa ABAP. Os comandos OLE são transferidos para o
PC através de chamadas RFC
 Os objetos OLE aos quais o R/3 pode se conectar como client são definidos
internamente no R/3 (através de type informations) onde se definem os métodos,
atributos e parâmetros do objeto. A linguagem ABAP possui comandos próprios
(CREATE OBJECT, CALL METHOD, GET/SET PROPERTY e FREE OBJECT) que
permitem instanciar e manipular o objeto.
 Quando o R/3 funciona como um OLE server, suas funções podem ser chamadas de
dentro das aplicações que rodam no desktop. Estas chamadas são enviadas ao SAP
Automation Server que converte os calls para RFCs que são enviados ao sistema R/3.
Estas chamadas ativam BAPIs ou function modules dentro do sistema R/3 que
processam as informações que são então enviadas de volta para o Automation Server
que a repassa para o aplicativo no desktop.
 Do ponto de vista da programação, usuários podem utilizar as function modules do R/3
em uma programação orientada para objeto, como por exemplo utilizando C++ ou
Visual Basic. Isto é válido para todos os objetos que são gerenciados centralizadamente
pelo R/3 através da BOR (Business Object Repository)
 Como os BOR e function modules se encontram no R/3, para utiliza-los é necessário
antes efetuar um logon, que pode ser feito de forma automatizada pelo programa.

Academia Basis – Semana 1 - 26/01 a 28/01/2000 Pag. 18

José Roberto A. de Lima – SAP Brasil
Internet Architecture
 O IST (Internet Transaction Server) forma o componente principal da arquitetura
Internet da SAP. Ele é composto de dois componentes, o Application Gate (A Gate) e o
Web Gate (W Gate)
 Do ponto de vista do R/3, o A Gate age como um usuário comum, uma vez que o IST
converte toda a conversa com o sistema para protocolos utilizados pelo SAPGUI. O A
Gate mescla os dados recebidos com templates HTML e os envia através do W Gate
para o HTTP server, onde são finalmente exibidos para o usuário através dos browsers
padrão (explorer ou netscape)
 A SAP fornece o IAC (Internet Application Component) que possui Web Transactions
que nada mais são que mapeamentos Web de transações standard R/3. Assim como
qualquer página HTML, o usuário pode customizar o lay out de acordo com suas
necessidades.

EDI Architecture
 O Electronic Data Interchange é uma forma estruturada e eletrônica para trocar
informações entre diversos sistemas. Esta arquitetura tem as seguintes características:
 EDI-enabled applications, que permite que transações de negócio sejam processadas
automaticamente
 A interface IDOC, que foi criada como uma interface aberta e consiste de
documentos intermediários e seus respectivos function modules
 O subsystem EDI, que converte os documentos intermediários em mensagens EDI e
vice versa. O SAP não implementa esta facilidade
 O componente principal desta interface é o Idoc, que é um SAP standard que especifica
a estrutura e o formato do dado que está sendo transferido

Distribution of Business Processes with ALE

 Por razões técnicas ou de negócio pode ser necessário fazer uma implementação
descentralizada do R/3. O conceito ALE (Application Link Enabling) permite
configurar e operar aplicações distribuídas em SAP.
 O ALE consiste de uma troca controlada de mensagens de negócio que permitem a
integração consistente de sistemas distribuídos. Os aplicativos são integrados através de
comunicações tanto síncronas quanto assíncronas.
 Para especificar um sistema distribuído é necessário especificar o modelo lógico em que
o sistema rodará e ainda entre quem e como os dados deverão ser intercambiados
 Os dados são transferidos através de Idocs (Intermediate Documents) através da
interface EDI.

Academia Basis – Semana 1 - 26/01 a 28/01/2000 Pag. 19

José Roberto A. de Lima – SAP Brasil
Data Transfer and Batch Input
 Quando se transfere dados entre sistemas R/3 ou entre o legado e o R/3, é importante
garantir que estes dados entrem de forma consistente dentro do sistema.
 Desde que se utilize as mesmas transações conversacionais utilizadas pelos usuários
para entrar com os dados no sistema, fica assegurado que os dados passarão pelas
mesmas consistências que se efetuam nas entradas online de informação
 O método comumente utilizado para entrada de dados do legado é conhecido como
batch input. A SAP provê uma série de métodos implementados através de técnicas de
batch input para a transferência de dados do legado. Estes métodos standard são
controlados através do Data Transfer Workbench (transação SXDA). Caso não existam
SAP standard disponível, é possível definir e criar seus próprios métodos
 O método consiste na bufferização das operações em uma BDC table (Batch Data
Communication) que fica organizada em uma fila (batch input session). No passo
seguinte esta fila é processada e os dados são transferidos para a base de dados. O
método funciona como uma screen cam para processamento de transações
 Um outro método para entrada de dados é o CALL TRANSACTION que força a
chamada de uma transação para processar os dados armazenados na BDC table
 Tanto o batch input quanto o método de call transaction chamam os mesmos programas
que são processados em dialog mode pelos usuários, o que garante desta forma que as
mesmas consistencias sejam efetuadas sobre a massa de dados.
 Outra forma de atualização é o Direct Input, onde os dados são lidos diretamente do
arquivo de entrada, consistidos e transferidos para a base de dados sem passar pelas
funções de aplicação normais. Dado a natureza atípica desta operação, ela é efetuada
apenas por algumas poucas funções R/3 e reservadas apenas para programas
desenvolvidos pela própria SAP.

R/3 Graphical User Interface

Frontend Administration
 Usuários não necessitam da mesma configuração em seus PCs, embora uma
padronização da workstation simplifica o trabalho de administração.
 Considere a facilidade e a dificuldade para atualizar os softwares da estação

Frontend Requirements
 A nota 86895 descreve detalhadamente a configuração da estação
 Configuração para Windows 95
Item Configuração Mínima Configuração desejável
Processador 486 Pentium 133
Academia Basis – Semana 1 - 26/01 a 28/01/2000 Pag. 20
José Roberto A. de Lima – SAP Brasil
 RAM 16MB 32MB
Net connection Winsocket API Winsock.dll
 Configuração para Windows NT
Item Configuração Mínima Configuração desejável
Processador Pentium 90 Pentium 133
RAM 32MB 48MB
Net connection TCP/IP TCP/IP
 Para testar o funcionamento da rede entre a estação e o host basta efetuar um ping ou
telnet. As configurações no windows ficam nos arquivos host e services
 Para testar o funcionamento do SAPGUI utilize o comando
sapgui <appserver> sapdp<nn>

SAPGUI Installation
 Sempre que for instalar uma nova versão do SAPGUI é necessário deletar a versão
anterior. O programa sappurge.exe pode ser utilizado para esta finalidade.
 A instalação é feita individualmente em cada PC. Programe a melhor forma para
otimizar o trabalho
 O arquivo SAPSETUP.INI pode ser editado para parametrizar a instalação. Nele se
configura quais os componentes a serem instalados e os diretórios target e de work.
 O sapsetup permite uma instalação dialog free startada a partir da linha de comando
(veja o R/3 Installation Guide) o que assegura uma distribuição automática do software
e a manutenção do frontend utilizando logon scripts.
 A vantagem neste tipo de instalação é que a configuração das estações é feita a partir de
uma localização central através de um logon script, que faz todas as checagens
necessárias (hardware e network) e executa as operações necessárias para instalar e
manter o frontend.
 A desvantagem deste método é que se tem mais trabalho para implementar o check de
versão no logon script e para analisar os resultados da instalação no arquivo
sapsetup.log
 A SAP recomenda que sob windows 95 e NT primeiro se faça uma instalação em um
servidor (installation server) utilizando o installation wizard e posteriormente se instale
os clients a partir dele. O programa utilizado na instalação é o
\Gui\Windows\Win32\Sapsetup.exe

Types of Online Help

 Existem diversos tipos de implementação do online help no R/3:
 PlainHtmlHelp converte documentos para HTML standard. Pode ser instalado em
todas as plataformas de frontends e é exibida através dos browsers convencionais.

Academia Basis – Semana 1 - 26/01 a 28/01/2000 Pag. 21

José Roberto A. de Lima – SAP Brasil
 Pode ser utilizado tanto com Windows 95, NT ou ainda quando um Web server é
disponível na instalação (intranet)
 PlainHtmlFile converte documentos para HTML standard. Pode ser instalado em
todas as plataformas de frontends e os documentos são acessados através de um file
server que disponibiliza os dados de um diretório por compartilhamento onde são
exibidos através dos browsers convencionais nas estações. Pode ser utilizado tanto
com Windows 95, NT ou ainda quando um Web server é disponível na instalação
(intranet)
 HtmlHelpFile converte documentos armazenados no formato HTML comprimido
para Html convencional. Pode ser utilizado apenas em estações Windows 95 ou NT.
É instalado em um file server compartilhado, como o anterior, mas sua principal
vantagem é que o espaço necessário no file server é cerca de 90% menor, já que os
arquivos se encontram compactados. O único pré requisito é que o browser já esteja
instalado na estação antes da instalação do SAPGUI, já que é o browser que contém
todos os HTML controls necessários.
 O tipo de help e sua localização são especificados como parâmetros nas profiles do R/3
 A configuração do arquivo SAPDOCCD.INI no frontend overrida a definição genérica
das profiles do R/3

SAPLOGON
 O programa saplogon.exe se encontra no diretório drive:\<target>\sapgui, conforme foi
definido no momento da instalação. O saplogon utiliza o programa sapgui.exe para se
conectar com o application server.
 O arquivo saplogon.ini configura as entradas disponíveis na janela do saplogon e é
mantido quando se atualiza as entradas disponíveis do usuário. As informações lá
contidas são utilizadas para montar o string de conexão ao application server. Para
evitar que o usuário edite as entradas deste arquivo é preciso defini-lo como readonly.
 Ao se clicar no canto esquerdo da janela do saplogon é possível obter informações
about que descrevem a localização dos dois arquivos (sapgui.exe e saplogon.ini)
 O botão do canto superior esquerdo da janela permite ainda que se configure as opções
de trace do saplogon e as funcionalidades de edição. Estas definições ficam
armazenadas na seção [Configuration] do saplogon.ini
 Assim como o saplogon.ini, os arquivos sapmsg.ini e saproute.ini são mantidos
implicitamente quando edita as entradas do saplogon. O primeiro contém a relação dos
message servers e seus respectivos serviços (logical service names) que será lido
sempre que se efetua uma requisição de logon a um logon group através do saplogon. O
segundo arquivo (saproute.msg) lista os saprouters que podem ser selecionados no
saplogon.
 Já o arquivo services do windows não é editado pelo saplogon embora possua entradas
fundamentais para o seu funcionamento, devendo portanto ser editado em separado.
Nele são especificadas entradas para os message servers definidos no sapmsg.ini, como
por exemplo: sapms<SID> 36nn/tcp
Academia Basis – Semana 1 - 26/01 a 28/01/2000 Pag. 22
José Roberto A. de Lima – SAP Brasil
 O saplogon utiliza o programa sapgui.exe para se conectar com o sistema R/3 e o string
de conexão depende do target escolhido:
 Para conexão com uma instancia R/3: sapgui /H/<appserver>/S/32nn
 Para conexão com um message server: sapgui /M/<host name>/S/36nn/G/<logon
group>
 Para conexão saprouter: sapgui /H/<host 1>/S/3299/H/<host 2>/S/3299/H/<oss
host>/S/36nn/G/Public
 Os números dos serviços poderão ser substituídos pelas respectivas entradas colocadas
no services: sapdp<nn> para o dispatcher e sapms<SID> para o message server

SAP MAPI


SAP Online Service System (OSS)

OSS Overview
 O OSS é um serviço 24 x 7 disponibilizado pela SAP que permite acesso ao banco de
dados de Notas, que provêm soluções para problemas no sistema R/3
 Através do OSS os clientes abrem chamados ao suporte relatando problemas que são
analisados pela equipe da SAP

OSS Functionality
 A tela de pesquisa permite entrar com palavras chave relacionadas ao problema e
incluir filtros na pesquisa, tais como release, database, versão de Hot Package, etc.
 Ao abrir chamados, o OSS já configurado com dados gerais da sua instalação requisita
informações sobre área do problema, transação, descrição do problema e severidade.
 O SSCR é uma funcionalidade do OSS que permite ao cliente obter key para
desenvolvedores e para os objetos SAP que irão sofrer modifications.
 O SSCR exibe uma lista de todos os objetos e desenvolvedores registrados para o
cliente na SAP
 Através da lista de Hot Packages disponíveis e das datas dos treinamentos oferecidos
pela SAP

OSS Access
 O acesso ao OSS é efetuado através da transação OSS1, que abre uma nova conexão
SAPGUI no frontend do usuário

Academia Basis – Semana 1 - 26/01 a 28/01/2000 Pag. 23

José Roberto A. de Lima – SAP Brasil
 O acesso ao OSS é preciso ser configurado através de um SAPRouter gateway que abre
uma conexão segura entre a instalação do cliente e a rede mundial da SAP.

SAPNet
 A SAPNet é uma ferramenta que provê informações e serviços via internet. O acesso a
SAPNet é feito através da área CUSTOMER PARTNER da página pública da SAP
(WWW.SAP-AG.DE)
 Dentro da SAPNet existem áreas de Assistência, Informação, Comunicação e Serviços

SAP TechNet
 A SAP TechNet é uma ferramenta focada mais para o lado técnico, acessada através de
endereço www.sap.com/technet ou através da área de communication da SAPNet
 Os assuntos na SAP TechNet estão divididos por áreas de interesse e podem ser
navegados para encontrar uma grande diversidade de documentos e pdfs

Academia Basis – Semana 1 - 26/01 a 28/01/2000 Pag. 24

José Roberto A. de Lima – SAP Brasil