Apostilha Conceitos Basis

Introdução na administração SAP R/3
1. INTRODUÇÃO A SAP R/3............................................................................................................................3

1.1. QUE É SAP R/3...........................................................................................................................................3
1.2. ARQUITETURA DO SAP R/3............................................................................................................................4
1.2.1. Arquitetura Cliente Servidor..............................................................................................................4
1.2.2. Arquitetura cliente servidor em SAP..................................................................................................5
1.2.3. Diferentes plataformas.......................................................................................................................7
1.3. SAP R/3 E SUA INTERAÇÃO COM O SO............................................................................................................8
1.4. COMUNICAÇÃO DO SAP COM A BASE DE DADOS.............................................................................................11
2. CARACTERÍSTICAS BÁSICAS DO SISTEMA......................................................................................11
2.1. ESTRUTURA GENÉRICA DE UM SISTEMA SAP R/3..............................................................................................13
2.2. ESTRUTURA DA BASE DE DADOS....................................................................................................................14
2.3. MANDANTES................................................................................................................................................14
2.4. PROCESSOS DE TRABALHO (WORKPROCESSES)..................................................................................................17
2.4.1. Modos de operação..........................................................................................................................20
2.5. ESTRUTURA DE DIRETÓRIOS DO SAP...............................................................................................................21
3. PERFIS DO SISTEMA................................................................................................................................23
4. USUÁRIOS E AUTORIZAÇÕES...............................................................................................................24
4.1. MESTRE DE USUÁRIOS...................................................................................................................................25
4.2. PERFIS........................................................................................................................................................25
4.3. OBJETOS DE AUTORIZAÇÃO.............................................................................................................................26
4.4. GRUPOS DE ATIVIDADE..................................................................................................................................26
5. SISTEMA DE TRANSPORTES..................................................................................................................27
5.1. WORKBENCH ORGANIZER E CUSTOMIZING ORGANIZER......................................................................................28
5.2. DIRETÓRIO DE TRANSPORTES..........................................................................................................................30
5.3. TP, TPPARAM.........................................................................................................................................31
5.4. TRANSPORT MANAGEMENT SYSTEM (TMS)....................................................................................................31
6. MONITORAMENTO..................................................................................................................................32
6.1. LOG DO SISTEMA..........................................................................................................................................32
6.2. MONITOR DE ALERTAS..................................................................................................................................33
6.3. PROCESSOS DO SISTEMA.................................................................................................................................34
6.4. USUÁRIOS DO SISTEMA..................................................................................................................................35
6.5. ANÁLISE DUMP............................................................................................................................................35
6.6. STATISTICS RECORDS....................................................................................................................................36
6.7. ANÁLISE DE CARGA.......................................................................................................................................37
6.8. BUFFERS DO SISTEMA....................................................................................................................................37
6.9. BASE DE DADOS..........................................................................................................................................38
6.10. ATIVIDADE DO SISTEMA OPERACIONAL..........................................................................................................39
7. ATUALIZAÇÃO E BLOQUEIO................................................................................................................40
7.1. ATUALIZAÇÃO..............................................................................................................................................40
7.2. BLOQUEIO...................................................................................................................................................42
8. REPARAÇÕES, CORREÇÕES E ATUALIZAÇÕES NO SAP..............................................................42
Daniel Chollet Página 1

8.1. HOTPACKAGES/SUPPORTPACKAGES................................................................................................................43
8.2. NOTAS, OSS, SAPNET...............................................................................................................................44
8.2.1. Transações SPAU, SPDD, estrutura de versão................................................................................45
8.3. UPGRADE DE KERNEL...................................................................................................................................46
8.4. UPGRADE DE VERSÃO DO SAP.......................................................................................................................46
9. ESTRATEGIAS DE BACKUP....................................................................................................................47
9.1. BACKUPS AO NÍVEL DO SISTEMA OPERACIONAL..................................................................................................47
9.2. BACKUPS AO NÍVEL DA BASE DE DADOS...........................................................................................................47
9.2.1. DB Calendário.................................................................................................................................48
9.2.2. Backup Offline..................................................................................................................................49
9.2.3. Backup Online..................................................................................................................................49
9.2.4. Backup do Log de transações...........................................................................................................49
9.2.5. SAPDBA/BRTOOLS.........................................................................................................................49
10. OUTRAS FERRAMENTAS, FUNCIONALIDADES E TAREFAS......................................................50
10.1. ADMINISTRAÇÃO DE IMPRESSORAS E SPOOL....................................................................................................50
10.2. JOBS.........................................................................................................................................................53
10.3. AUDITORIA DO SISTEMA...............................................................................................................................56
10.4. WORKBENCH ABAP/4...............................................................................................................................58
10.4.1. Editor ABAP/4................................................................................................................................58
10.4.2. Dicionário de Dados......................................................................................................................59
10.4.3. Editor de Tabelas............................................................................................................................60
10.5. COMANDOS EXTERNOS.................................................................................................................................61
10.6. MENSAGENS DO SISTEMA.............................................................................................................................62
10.7. SAPOFFICE..............................................................................................................................................62
10.8. AJUDA E DOCUMENTAÇÃO............................................................................................................................62
11. LITERATURA RECOMENDADA...........................................................................................................64
12. CONCLUSÃO.............................................................................................................................................65

1. Introdução a SAP R/3
1.1. Que é SAP R/3
SAP R/3 é um sistema de informática integrado que abrange as
necessidades de médias e grandes empresas em áreas como
contabilidade financeira e analítica, administração de materiais,
planejamento e controle de produção, vendas, recursos
humanos e muitas mais.
Tudo isso se realiza de forma integrada, mantendo a unicidade e
consistência da informação graças ao armazenamento
centralizado em uma base de dados que interage com cada um
dos módulos.
O seguinte(>) esquema nos da uma idéia do modelo de

integração utilizado no SAP R/3

1.2. Arquitetura do SAP R/3
1.2.1. Arquitetura Cliente Servidor

A arquitetura cliente servidor baseia-se no princípio de ter
um fornecedor de serviços e um cliente que realize petições
para esse servidor.
Na realidade pode existir vários fornecedores de serviços e
muitos clientes.
SAP suporta uma arquitetura de cliente servidor de até três
níveis, realizando uma separação total entre as tarefas
próprias da Base de Dados, a aplicação e a apresentação.
Estas três capas ou níveis possuem funções bem definidas e

são as seguintes:
Nível de Base de dados: É o nível encarregado de resolver

as consultas de informação realizadas pelo nível superior e
atualizar os dados que devem ser armazenados. SAP possui
sempre apenas uma base de dados em um só servidor
físico.
Nível de Aplicação: Neste nível se encontra toda a lógica de

processo, as regras de negócio do aplicativo. São os
programas que compõem os distintos módulos com os quais
o usuário terá interação. Podem ser utilizados vários
servidores de aplicação no SAP.
Nível de apresentação: Este nível é o encarregado de

apresentar de forma gráfica, e agradável ao usuário final o
resultado dos processos realizados no servidor de aplicação.
É um programa instalado nos PC de cada usuário.

1.2.2. Arquitetura cliente servidor em SAP
Não é necessário ter sempre os três níveis separados em
três ou mais computadores, o seguinte(>) esquema mostra
as possibilidades:
SAP obtém sua melhor performance quando o esquema

cliente servidor é de três níveis, tirando o máximo proveito
da potência de processo independente de cada estrutura de
hardware.
A utilização de múltiplos servidores de aplicação permitem
que a carga de trabalho possa ser distribuída entre os
mesmos e separar se é necessário as tarefas que serão
realizadas em um servidor ou em outro.
Para implementar este esquema o servidor de Base de

Dados e os de aplicação deverão se encontrar em uma rede
de alta velocidade, já que o tráfico de dados entre estes é
muito elevado.

Porém, pelo fato dos clientes serem encarregados de
resolver a apresentação, estes só recebem os dados
necessários e seu link com o servidor de aplicação pode ser
inclusive mediante uma linha discada sem notar grandes
perdas de velocidade.
Este esquema nos mostra de forma gráfica a hierarquia de
um sistema SAP utilizando a arquitetura cliente servidor em
três níveis.
A possibilidade de distribuir a carga mediante a adição de

novos servidores de aplicação, proporciona uma grande
escalabilidade aos sistemas.
Além disso, a possibilidade de utilizar plataformas
heterogêneas tanto para as capas de aplicação como
apresentação, dá a flexibilidade necessária para o início de
implantação do sistema, quando geralmente não se possui a
infra-estrutura de hardware definitiva.

Isto torna possível que um servidor de aplicação NT se
comunique com outro UNIX.
E a independência do formato de dados permite inclusive
migrar um sistema de uma base de dados a outra sem maior
complicação.
A continuação é mostrado um esquema com exemplos da
distribuição em um sistema SAP.
1.2.3. Diferentes plataformas

SAP é baseado em diversas plataformas, oferecendo ao
usuário final sempre o mesmo aspecto uniforme, já que o
nível de apresentação é que determina o aspecto final do
produto.
Há diversas bases de dados que podem ser utilizados pela

SAP e o número continua aumentando. Atualmente suporta:
Oracle, Informix, DB2, Adabas e SQL Server.

Quanto aos servidores de aplicação, basicamente são
suportadas todas as plataformas UNIX, AS/400 e Windows
NT.
os servidores de apresentação estão disponíveis para

Windows 3.x, 95/98, NT, OS/2, Macintosh e Unix.
Inclusive, existe versões do SAPGUI em applets Java
disponíveis para sua instalação e porções do sistema
codificadas em HTML.
As principais plataformas podem ser vistas no seguinte(>)

esquema:
1.3. SAP R/3 e sua interação com o SO

Para obter o máximo rendimento, SAP deve dialogar com o
Sistema Operacional de forma eficiente, utilizando todos os
recursos que este possa oferecer.
Além disto deve ser realizado mantendo a "independência" do
aplicativo respeitando a plataforma.

A forma com que SAP consegue isto é mediante a utilização de
um Middleware, que se faz de intermediário entre o Sistema
Operacional e os aplicativos da SAP.
Este Middleware, também chamado Kernel, está codificado e

otimizado para cada versão do Sistema Operacional e da Base
de Dados. É por isto que muitas vezes a migração de uma
versão de Base de Dados a uma superior, está acompanhada de
uma migração do Kernel.
Quando se instala SAP, o Kernel possui a mesma versão que o
sistema, mas podem ser instaladas versões posteriores que
ofereçam melhorias e/ou correções.
Quando se fala da versão da SAP, por exemplo 4.0B, estamos
referindo à versão da aplicação, dos programas que o usuário
visualizará, a qual é independente da versão de Kernel utilizada.
O seguinte(>) esquema nos mostra a interação de SAP mediante
o Middleware ou Kernel com o SO
O Kernel também deve dialogar com o servidor da Base de

Dados e está especialmente codificado para isto.
Portanto, se trocarmos a plataforma, basta trocar a franja do

Middleware no esquema superior, para ter o mesmo sistema,
com as mesmas aplicações e a mesma funcionalidade.
As aplicações R/3 estão formadas por "milhares" de programas,

funções e objetos codificados em uma linguagem de
programação própria da SAP chamado ABAP/4.
Esta linguagem é a peça fundamental sobre a qual SAP se
baseia, já que todo o sistema pode ampliar-se ou modificar-se
em base à codificação nesta linguagem.
O controle de todo o ambiente de desenvolvimento do SAP está

a cargo do chamado ABAP/4 Workbench, que oferece diversas
ferramentas para desenvolver seus próprios programas,
relatórios, interfaces, formulários, etc.
Toda esta informação reside em um dicionário de dados
centralizado que reside na base de dados e é acessado por cada
um dos servidores de aplicação do sistema.
O esquema de acesso ao dicionário de dados é o seguinte(>):

1.4. Comunicação do SAP com a Base de Dados
Como se verá em detalhe mais adiante, os aplicativos do SAP
não se comunicam diretamente com a Base de Dados, tanto por
segurança como por eficiência.
Existem "Buffers" na memória dos servidores de aplicação,

utilizados como "cachê" de informação.
Em particular o buffer de Base de Dados se utiliza tanto na
gravação como na recuperação dos dados, por tanto muitas
vezes nossas consultas não chegam a sair do servidor de
aplicação se o que necessitamos se encontra aí.
2. Características básicas do Sistema

O primeiro a saber para utilizar o sistema SAP R/3 é o modo em
que podemos acessar as opções disponíveis.

Como já mencionamos, cada aplicação dentro do SAP R/3 é um
programa codificado em ABAP/4 que ao ser executado nos dá
acesso à funcionalidade implementada.
Cada programa encarregado de uma funcionalidade específica tem
a sua vez associada a uma "etiqueta" denominada "transação".
Por exemplo, a entrada padrão de faturas do módulo financeiro
pode ser encontrado navegando pelo menu como se faz com
qualquer aplicativo para Windows ou "executando" a transação
correspondente, neste caso a "FB01".
A seguinte(>) imagem nos mostra uma tela standard do SAP,
indicando o campo onde se ingressam as transações, após
pressionar "Enter" executa-se o programa associado.
Existem muitos códigos de transação, um para cada funcionalidade

do menu, e o desenvolvedor pode criar suas próprias transações e
associá-las a seus programas.
Uma vez dentro de um programa podemos voltar atrás

pressionando a flecha verde.

2.1. Estrutura genérica de um sistema SAP R/3
Mesmo não sendo uma exigência, SAP recomenda que se tenha
três ambientes e ao menos dois sistemas SAP separados para
entrar em produção.
Os ambientes são: Desenvolvimento, Teste (ou qualidade) e
Produção.
Idealmente deveriam corresponder a três sistemas SAP
separados que cumpram estas funções, mas também é normal
que existam apenas dois, um cumprindo com as funções de
Desenvolvimento e Teste e o outro Produção.
A idéia é que se realizem os desenvolvimentos e as provas
primárias no sistema de Desenvolvimento, logo estes dados são
passados ao Teste é realizada uma prova integrada e mais
complexa. Quando tudo está correto se tudo é passado para a
Produção. Como se verá mais adiante, cada sistema estará
dividido em entidades lógicas chamadas mandantes ou clientes.
Maintenance of a Three-System Landscape

Development system Quality assurance Production system
system
Change Change
request request
DEV QTST PROD
Client Copy Client Copy

Change Change
request request
MAST MAST MAST
Change transport changes using DEV Development / Cust.

request customizing and transportable
MAST Test master / Cust. data
change requests
QTST Quality Assurance Test
Client Copy distribute change requests
Change req PROD Production
using the Client Copy tools
SAP AG

2.2. Estrutura da Base de Dados
A Base de Dados do SAP é única e por tanto contém toda a
informação necessária para a utilização do Sistema.
Inclusive os programas que compõem o aplicativo SAP se
encontram na Base de Dados, ao nível do SO só temos no
Kernel e os arquivos de configuração ou logs.
2.3. Mandantes
NO SAP existe um conceito muito interessante chamado
mandante ou cliente.
Mediante esta funcionalidade, um só sistema SAP pode ser
utilizado por empresas distintas, mesmo que compartindo a
mesma Base de Dados.
Isto é possível graças a separação "lógica" que nos oferece os
mandantes.
O primeiro que aparece na telade Login do SAP ao iniciar a

conexão é o mandante, dado que identifica a "Entidade
Empresarial" que vamos conectar.
Cada mandante tem seus próprios usuários, suas configurações

de acesso, seus planos de conta, seus dados contábeis e de

gestão, seus próprios fornecedores e credores, assim como
suas contas de maior.
Em resumo, toda os dados gerados pela utilização dos
aplicativos são próprios de cada mandante, permitindo criar
"ambientes" juntos físicamente mas separados de forma total ao
nível lógico.
Isto é muito importante, já que por exemplo em um sistema de
desenvolvimento, é normal a criação de um mandante para os
desenvolvimentos e outro para os testes onde se tem mais
dados de prova.
Mas se tudo isto fosse tão perfeito, não seria necessário a
utilização de vários sistemas em um ambiente produtivo.
O que acontece é que existem certos dados que são
"dependentes" do mandante e outros que são "independentes"
do mesmo.
Portanto os dados independentes de mandante ao serem
modificados afetam todo o sistema.
Um exemplo claro de dados independentes de mandante são os
próprios programas e tudo o que é desenvolvido no Workbench.
Se tenho um sistema com um mandante para desenvolvimentos
e outro para teste que os programas alterados em um sejam
automáticamente alterados no outro.
Isto acontece pois na realidade para cada sistema os programas
se encontram em um único lugar da Base de Dados, o qual é
muito perigoso para um ambiente produtivo, se tivésse apenas
um sistema, não poderíamos baseando-se em uma só estratégia
de mandantes, evitar problemas em produção ao trocar os
programas.
Se temos que falar ao nível de Base de Dados, a implementação
dos mandantes consiste simplemente em ter para cada tabela
"dependente" de mandante um campo que indique o mandante
mas que seja transparente para o usuário.
A seguinte(>) imagem corresponde à transação SCC4,
encarregada da manutenção de mandantes dentro de um
sistema SAP R/3.

Aqui podemos visualizar que o sistema consta de 4 mandantes,
três deles são standard do SAP e vem "pré-instalados" com o
sistema.
Os mandantes 000 e 001 são de referência e servem de base
para criar os mandantes de usuário.
O mandante 066 ou "EarlyWatch" é utilizado para o serviço de
assistência remota de SAP.
Neste caso existe um mandante de usuário, o 555 criado
originalmente como cópia do mandante 000 ou 001.
Podemos realizar certas configurações dentro de cada mandante
também com a transação SCC4, estas configurações permitirão
indicar coisas como:
•Registro ou não das mudanças realizadas no mandante.

•Papel do mandante (produção, teste, etc.)
•Possibilidade de alteração de dados indep. de mandante.
•Possibilidade de alteração de dados dep. de mandante.
•Nível de proteção contra cópia ou atualização.

2.4. Processos de trabalho (WorkProcesses)
Os processos de trabalho são os programas ao nível do sistema
operacional, pertenecentes a SAP que realizam todo o
processamento e diálogo com o SO e a B.D.
Não são mais que programas integrantes do Kernel do SAP que
oferecem os serviços básicos ao sistema. Do SAP podemos
obter informação sobre o que acontece com os processos de
trabalho e efetuar alterações sobre os mesmos.
Os usuários podem ter dois tipos de processamento no SAP,
processamento de diálogo e processamento background.
O processamento de diálogo é aquele em que o usuário inter-
atua com o sistema, como o ingresso de uma órdem de
compras.
O processamento background se faz sem interação do usuário e
geralmente corresponde à tarefas como carga de dados,
emissão de informes, processamentos, etc.
SAP dispõe de dois tipos de processos de trabalho para atender
estas duas modalidades de processamento.
A seguinte(>) figura nos mostra os distintos processos de
trabalho do SAP.

Cada um destes processos estabelece uma conexão com a base
de dados (as conexões efetivas do SAP à BD estão dadas pelo
número de processos de trabalho).
Os usuários não se conectam diretamente à base de dados a
não ser que obtenham os serviços do SAP.
A função de cada um destes processos é a seguinte(>):
•Dialog
Este processo se encarrega de dar serviço aos usuários de
diálogo do sistema. Cada um destes processos estabelece
uma conexão com a Base de Dados e recebe petições dos
usuários. Por norma cada um pode dar serviço a uma média
de 5 ou 6 usuários.
•Update
Como se verá mais adiante, as atualizações no SAP são
"diferidas" passando a uma "lista/fila" de atualização, estes
processos são os encarregados de direcionar tal lista/fila.

•Background
Estes processos dão serviço aos programas background
como listados, cargas de dados e processos noturnos. Cada
um deles atende apena um usuário por vez.
•Spool
Os processos de Spool se encarregam de administrar a lista
de impressão do SAP, já que os encarregados de imprimir são
os servidores de aplicação.
•Enque (Lock)
SAP mantém bloqueios internos independentes da base de
dados para seus objetos de forma integral (uma fatura, uma
ordem de compra, um programa, uma proposta de
pagamento, etc.).
É este processo que se encarrega de administrar tais
bloqueios.
•Message
Em um ambiente com mais de um servidor de aplicação, este
processo, que deve residir em um deles, se encarregará de
distribuir aos usuários de forma a também distribuir a carga do
sistema redirigindo cada novo usuário ao servidor menos
utilizado.
•Gateway
É um processo necessário se é que se quer por exemplo
estabelecer comunicação entre um sistema R/3 e um sistema
R/2.
Do SAP é possível monitorar o estado de tais processos de

trabalho mediante a transação SM50 que será como a
seguinte(>) tela:

Aqui vemos uma lista com distintos processos, seu status, o
usuário que o está utilizando, o programa e outros dados úteis
para determinar seu estado.
Os nomes na lista tem a seguinte(>) correspondência:
DIA: Processo de diálogo

BTC: Processo background
UPD: Processo de Update U1
UP2: Processo de Update U2
ENQ: Processo de bloqueio
SPO: Processo de impressão
*Os processos de Update U1 e U2 são semelhantes mas se

utilizam por SAP para diferenciar prioridades de atualização.
2.4.1. Modos de operação.
É normal que durante o dia se realizem mais processos de
diálogo e à noite mais processos background.
É por isso que SAP oferece uma ferramenta que permite
configurar por horario a quantidade de processos de trabalho
de diálogo e background que teremos no sistema.

Supomos que durante o dia temos 10 processos de diálogo
e 2 de background, mas À noite se executam muitos
processos de fundo e necessitamos mais recursos, então
podemos programar que logo após a finalização do horario
do escritório se diminua a 6 os processos de diálogo e se
aumente a 6 os de background.
Logo às 9 da manhã voltamos a colocar 10 de diálogo e 2 de
background.
Podemos fazer isto pois sabemos que durante a noite não
temos muitos usuários e sim muitos processamentos.
Os modos de operação otimizam a distribuição dos recursos

do sistema.
2.5. Estrutura de diretórios do SAP

Os servidores de aplicação SAP possuem uma estrutura de
diretórios desenhada para facilitar o trabalho do administrador de
sistemas, essa estrutura é a seguinte(>):

R/3 Directory Structure

R/3
Global Directories Instance Directories

usr
sap
trans <SAPSID> tmp put
SYS <Instance_name>
profile exe global work data log
run dbg opt
 SAP AG

Esta estrutura facilita a integração entre sistemas SAP e entre
instâncias do mesmo sistema.
Quando temos um sistema SAP com apenas um servidor de

aplicação, este é considerado a instância 00, e se temos mais
servidores de aplicação então teremos uma instância a mais
para cada um deles.
No esquema visto <SAPSID> é o nome do sistema que deve ser
sempre de 3 letras e não pode se repetir dentro de uma
instalação.
Dentro de cada sistema temos então o número de instância que
dependerá da quantidade de servidores de aplicação
disponíveis.
Dentro do diretório SYS se encontram os executáveis, os perfis
do sistema e os logs e dentro de TRANS a árvore de diretórios
do sistema de transporte do SAP, que como se verá mais adiante
é o encarregado da comunicação entre os sistemas.
Do SAP podemos ver os diretórios do sistema e navegar no seu
conteúdo mediante a transação AL11 que nos oferece uma
interface como esta:

3. Perfis do sistema
SAP precisa para funcionar corretamente e para apresentar
determinado comportamento de configurações de início.
Estas configurações determinam coisas como a quantidade de
memória a ser utilizada pelos usuários, as linguagens instaladas, o
mandante por default, o tamanho dos Buffers, a quantidade de
processos de diálogo e muitos outros parâmetros.
Todas estas configurações se armazenam nos "perfis" do sistema,
que são arquivos localizados em
/usr/sap/<SAPSID>/SYS/profile.
Apesar destes arquivos poderem ser editados e manipulados
manualmente, SAP oferece uma interface adequada para isso com
três níveis de atualização.
Temos três tipos de perfis:
•Perfil de instância
Contém a configuração de cada servidor de aplicação do sistema
possuindo um para cada servidor.
•Perfil de Arranque
Especifica os processos a nível do sistema operacional que se

inicía ao levantar SAP
•Perfil por default
Igual que o perfil de instância mas suas configurações afetam
todos os servidores.
A transação SAP encarregada da administração dos perfis é a

RZ10 mostrada a seguir:
Assim que modificamos um perfil é necessário reiniciar SAP para

que as mudanças sejam reconhecidas.
4. Usuários e Autorizações
Para acessar SAP devemos ter um usuário registrado em algum de
seus mandantes e para realizar alguma tarefa devemos ter as
autorizações pertinentes.
O grau de detalhe que se pode obter com as autorizações é muito
alto, podendo especificar combinações de restrições que fazem
possível limitar o acesso e as tarefas a qualquer coisa virtualmente.

4.1. Mestre de usuários
O mestre de usuários é próprio de cada mandante e nele
definimos os dados de direção do usuário (Nome, departamento
que pertence, endereço, telefone, etc.)
Por outro lado temos parâmetros que associaremos aos usuários
como por exemplo se usará vírgula ou ponto para os decimais,
ou formato da daTA ou a impresSora por default.
Finalmente existe outra informação associada ao mestre do
usuário que são os perfis de autorização.
Estes perfis de autorização definirão o que o usuário pode ou
não pode fazer. A transação de manutenção de usuários é a
SU01 e tem este aspecto:
4.2. Perfis
Como já mencionamos, os perfis dão a cada usuário as
autorizações para trabalhar no SAP, mas estes perfis na
realidade não contém as autorizações, englobam-as.
Existem dois tipos de perfis, os normais e os compostos, os
perfis compostos estão formados por outros perfis e somam as
autorizações destes, os perfis normais têm autorizações

associadas.
Acessamos a manutenção de perfis mediante a transação SU02
4.3. Objetos de autorização

Os objetos de autorização do SAP são as definições de certo
tipo de autorização. Por exemplo o objeto de autorização
S_TCODE permite definir as transações que se terá acesso.
Quando damos valores a um objeto de autorizações temos uma
autorização. É como a definição de classe e instância na
orientação a objetos.
4.4. Grupos de atividade

Mediante os grupos de atividade automatizamos as tarefas de
dar autorizações aos usuários já que de forma unificada
selecionamos as autorizações pertinentes com seus respectivos
objetos, associamo-os a um perfil e logo a um usuário. A
transação utilizada para manipular os grupos de atividade é a
PFCG.
Para definir as tarefas de um usuário simplesmente deve-se
indicar os ramos do menú aos quais este deve acessar, e
depois apenas indicar as limitações sobre cada tarefa (por

exemplo se este vai visualizar ou também poderá criar, ou se
poderá trabalhar apenas com os fornecedores que começam
com "S").
5. Sistema de transportes
O sistema de transportes de SAP é uma das ferramentas mais
potentes para a comunicação entre mandantes do mesmo sistema
ou entre sistemas separados.
Pensando em armazenar de forma eficiente todas as mudanças
efetuados no ambiente de desenvolvimento e a parametrização de
SAP, idealizou se um objeto que serviria de "caixão" chamado
"ordem de transporte", que recebendo programas, dados de tabelas
ou modificações de parametrização fosse capaz de transportá-los
de um ambiente a outro de forma transparente.
Estas órdens de transporte, podem ser "exportadas" e gravadas
como arquivos no nível do sistema operacional, com a grande
vantagem de que são independentes da plataforma, sem nenhum
problema em gravar em uma órdem que contenha um programa
gerado para AS400 e logo levantar tal órdem em um sistema dentro
do Windows NT.

Além de oferecer esta facilidade de transporte de dados, existe uma
grande vantagem adicional em utilizar órdens.
Se um programador está trabalhando em um projeto, com suas
tabelas, objetos do dicionário, programas, etc., pode colocar tudo
dentro de uma órdem e assegurar-se que nada pode modificá-la
pois os objetos ficam "bloqueados".
Então temos um repositório de dados que controla de forma muito
eficiente o acesso dos usuários aos objetos, impedindo
inconsistências.
Temos básicamente dos tipos de órdens, de Customizing e de
Workbench.
As órdens de Customizing contém as modificações realizadas na
parametrização do sistema, as órdens de Workbench contém tudo o
que foi criado ou modificado pelos desenvolvedores e que se
armazena no dicionário de dados.
SAP oferece uma interface para manipular cada um dos tipos de
órdens de transporte chamadas Workbench Organizer e
Customizing Organizer.
Um mandante pode ser configurado para gravar as modificações de
forma automática em órdens ou deixar que o usuário o faça de
forma manual.
5.1. Workbench Organizer e Customizing Organizer

Tanto o Workbench Organizer como o Customizing Organizer
possuem uma interface muito similar e permitem administrar as
órdens criadas.
Sè possível alocar usuários a uma órdem, de forma que só
essas pessoas possam trabalhar com a mesma. Para cada
usuário alocado se cria uma tarefa dentro da órdem.
Podemos desde aqui editar o conteúdo das órdens, criar ou
apagar órdens e o mais importante "liberá-las".
Quando liberamos uma órdem estamos dizendo que as tarefas
que esta contém estão finalizadas e portanto vamos transportar
esses dados a outro sistema e eliminar os bloqueios sobre os
objetos. Ao liberar uma órdem esta pode ser "exportada" ao
sistema operacional, permitindo que seja acessada por outros
sistemas.

O aspecto do Customizing Organizer que também nos permite
manipular órdens de Workbench é o seguinte(>):
Quando consultamos as órdens vemos separados as de

Customizing e Workbench, assim como as liberadas ou não.

5.2. Diretório de transportes
Dentro da sua estrutura de diretórios SAP possui alguns
dedicados ao sistema de transporte. Neste diretórios são
gravadas as órdens exportadas, os erros ocorridos, os Buffers
que contém as órdens a importar, etc.
Estes diretórios são utilizados também quando se importam
linguagens ao sistema ou se instalam como veremos mais
adiante correções (HotPackages).
Este diretório encontra-se em /usr/sap/trans e contém uma série
de subdiretórios onde SAP gravará toda a informação
relacionada com as órdens de transporte.
As órdens de transporte se encontram repartidas em
/usr/sap/trans/data e /usr/sap/trans/cofiles.
Em /usr/sap/trans/bin se encontram os arquivos de configuração
para o transporte como veremos a continuação.
Em /usr/sap/trans/buffer/ se encuentran os Buffers de cada
sistema com a informação das órdens listas para importar.
Em /usr/sap/trans/log se guarda um registro de todo o
acontecido no processo de importação de cada órdem.

5.3. TP, TPPARAM
Apesar do SAP realizar todos os transportes de órdens desde
sua interface gráfica, é possível fazê-lo de forma manual desde o
sistema operacional mediante o comando TP, este comando se
encarrega de importar uma ou mais órdens no sistema e
mandante indicados.
Para seu funcionamento utiliza a configuração indicada no
arquivo TPPARAM localizado em /usr/sap/trans/bin
5.4. Transport Management System (TMS)

Quando temos vários sistemas em um ambiente, é necessário
configurar a forma em que os dados vão ser transmitidos.
Por exemplo se tivéssemos um sistema de desenvolvimento e
teste e outro produtivo, teríamos que definir no TMS estes dois
sistemas e uma rota entre desenvolvimento e produção
indicando o caminho que seguirão as órdens ao se exportar e
importar.
No TMS é também onde podemos realizar o transporte de
órdens de um sistema a outro.

Nesta imagem vemos os sistemas com as rotas de transporte
definidas entre eles que permitem a passagem das órdens.
6. Monitoramento
SAP possui diversas ferramentas que permitem saber o que está
acontecendo com o sistema, a continuação mostramos os principais
e mais utilizados.
6.1. Log do sistema

Mediante o log do sistema podemos saber que aconteceu em um
determinado momento e é muito útil para detectar problemas.
Podemos encontrar registrado para cada usuário, mandante,
transação e horário cada acontecimento, seja uma informação,
uma advertência ou um erro.
O nível de detalhe apresentado no log do sistema pode se
ajustar variando parámetros do perfil do sistema.
O nível de detalhe que por default é 1, vai desde 0 até 3, os
níveis mais altos só são recomendáveiss quando se realiza a

busca de um erro difícil de detectar, já que o registro de grande
quantidade de dados diminui notavelmente o rendimento do
sistema.
A transação utilizada para chamá-lo é a SM21, apresentando o
seguinte(>) aspecto:
6.2. Monitor de Alertas

O monitor de alerta permite obter através de uma visualização
rápida, uma idéia geral do que ocorre com o sistema, com a
vantangem de que podemos aprofundar até chegar ao detalhe.
Os dados se apresentam em estrutura de árvore com
codificação de cores o que torna muito mais fácil o seguimento
dos problemas.
Um exemplo do mesmo que é chamado mediante a transação
RZ20 pode ser visto a continuação:

6.3. Processos do sistema
Os processos do sistema mostram o estado atual dos
WorkProcesses, podendo detectar situações anormais, reiniciá-
los ou abortar processos em caso de ser necessário.
Mediante a transação SM50 obtemos essa informação.

6.4. Usuários do sistema
Muitas vezes é necessário saber quem está conectado ao
sistema, o que está fazendo, e desde quando.
Inclusive, se necessário, poderíamos ter que eliminar um
usuário.
Isto obtemos mediante a transação SM04 mostrada a seguir:
6.5. Análise Dump

O análise Dump é uma ferramenta poderosa que permite saber
com alto nível de detalhes o que ocasionou o cancelamento de
um programa ABAP/4.
Seja uma alocação inválida, um número fora de rank ou um
excesso no tempo de execução, esta ferramenta registra a
situação no momento do erro.
Podemos ver as variáveis envolvidas, as linhas de código onde
ocorreu o problema, uma descrição e uma análise do mesmo
sugerindo possíveis causas e se isto não for suficiente, critérios
de busca para procurar mais informação sobre o erro.
A transação encarregada disto é a ST22.
Um exemplo de parte de um relatório vemos a seguir, mais
abaixo na listagem a informação sobre a fonte ABAP/4 que
gerou o problema, o conteúdo das variáveis ou tabelas e as

funções envolvidas.
6.6. Statistics Records

Estes registros oferecem informação estatística muito útil no
momento de detectar problemas de rendimento ou verificar
condições específicas.
Podendo limitar por vários critérios como transação, usuário,
memória utilizada e tempo de processo, é possível obter
informação extremamente detalhada do que acontece com o
sistema. Estes dados em forma de lista são um diagnóstico
preciso no caso de anomalia de rendimento.
A transação utilizada é a STAT

6.7. Análise de carga
A análise de carga mostra de forma efetiva onde temos o
gargalo no sistema já que faz uma análise detalhada da
distribuição dos tempos (CPU, Base de Dados, carga de
programas, etc.)
Acessamos esta análise com a transação ST03
6.8. Buffers do sistema

Por motivos de rendimento SAP utiliza Buffers em memória em
forma de caché, evitando ter que acessar sempre à base de
dados quando se necessita de algo. Podemos controlar o índice
de acerto destes buffer e verificar se não estão tendo muito
Swap, se isto ocorre significa que esse buffer é pequeno e
deveremos aumentar seu tamanho nos perfis do sistema.
Acessamos à informação dos buffer com a transação ST02. Um
exemplo deste reporte é o seguinte(>):

6.9. Base de Dados
Mediante a transação DB02 temos acesso à informação sobre o
estado atual da Base de Dados como índices perdidos, espaço
utilizado, consistência com o dicionário de dados, problemas de
espaço e outros dados úteis.

6.10. Atividade do Sistema Operacional
Pelo fato da que SAP possuir grande integração com o sistema
operacional é possível, desde o SAP, obter informação
detalhada do que acontece, como utilização da CPU, os discos,
memória e muitos outros parámetros. Acessamos esta
informação mediante a transação OS06
Da mesma transação acessamos a informação mais detalhada se for

necessário:

7. Atualização e Bloqueio
SAP possui como medida de segurança e como forma de aumentar
a eficiência dos subsistemas controlados por processos de trabalho
independentes.
Um destes sistemas é o de atualização, encarregado de gravar as
mudanças realizadas na base de dados e controlado pelos
processos tipo UPD e UP2.
Outro sistema é o de bloqueio, utilizado para assegurar a
consistência dos dados e controlado pelo processo ENQ.
7.1. Atualização
Como mencionamos, por motivos de eficiência e também por
segurança e recuperação ante falhas, SAP não grava
diretamente a informação gerada por suas aplicações à Base de
Dados.
Isto provocaria grandes esperas do usuário, que teríam que
aguardar até que a BD confirme a atualização dos dados.
Para isto SAP utiliza uma "lista de Update" onde vão parar todas
as atualizações pendentes. Quando um usuário grava algo, suas

atualizações vão para esta lista e imediatamente é liberado,
podendo fazer outras tarefas sem esperar a confirmação da
gravação.
Isto dá grande agilidade ao sistema mesmo quando está sob
muita carga.
Além disso no caso de erro do sistema, podemos ver a
informação que não pôde ser atualizada, tentar atualizá-la
manualmente, ou inclusive desativar a atualização para evitar
mudanças à base de dados.
Em caso de problemas com a base de dados (por exemplo falta
de espaço), SAP automáticamente desativa a atualização e a
informação ingressada pelo usuário não se perde a não ser que
esteja armazenada na lista de atualização e uma vez que o
problema é solucionado basta ativá-la para voltar à normalidade.
O Update Manager como se chama o processo encarregado de
administrar a atualização, pode ser accessado mediante a
transação SM13 e pode ser observado a seguir:

7.2. Bloqueio
O bloqueio é utilizado por motivos de segurança para evitar que
os usuários alterem objetos que estão sendo manipulados por
outros.
Funciona de forma independente dos bloqueios da BD já que
está desenhado para oferecer integridade aos objetos do SAP
(uma fatura completa, um programa, uma órdem de compras,
etc.). Em todo momento pode-se observar os objetos bloqueados
e desbloqueá-los se necessário.
Algumas vezes quando se desconecta um terminal e o usuário
fica "pendurado" no SAP é necessário eliminar os bloqueios que
este tinha.
A administração dos bloqueios se faz mediante a transação
SM12 mostrada a seguir:
8. Reparações, correções e atualizações no SAP

Como todo sistema de informática, é normal que se apresentem
erros em uma versão do SAP não detectados durante a etapa pré-
release do produto. Para isto SAP montou um esquema de
atualização do software baseado principalmente em duas técnicas:
atualização dos aplicativos e atualização do Kernel.
Para realizar a atualização do aplicativo (programas ABAP/4) exite
duas possibilidades, a primeira é aplicar notas e a segunda é a
aplicação de HotPackages

Para atualizar o Kernel, SAP oferece suas revisões corrigidas e
atualizadas.
Para obter os HotPackages e as atualizações do Kernel há também
duas posibilidades, uma é instalar dois CD's que SAP envia de
forma regular à seus clientes com os últimos HotPackages para a
versão do SAP correspondente e as últimas revisões de Kernel
para a plataforma e versão utilizadas. A outra opção é obter
diretamente de algum dos servidores FTP que SAP possui e que só
acessaremos tendo uma linha dedicada com eles ou desde o site
SAPNet accessível pela Internet.
Temos que destacar que mediante a aplicação de uma nota, é

possível modificar um programa SAP standard, mas para fazer isto
primeiro temos que solicitar uma senha para alterá-lo, a partir desse
momento se considera o programa testado de "reparação", já não é
mais um standard SAP e será tratado de forma especial quando se
realizar em upgrades do sistema ou se instalar HotPackages, já que
SAP deve saber se queremos manter nossa versão modificada ou
se desejamos instalar a nova proposta.
Além de ser marcado como uma reparação, o programa permanece
bloqueado dentro de uma órdem de transporte de reparação, pelo
qual tem que "liberar" tal órdem se o programa deve ser substituído.
A continuação veremos com mais detalhe cada tipo de atualização:
8.1. HotPackages/SupportPackages
Os HotPackages contém órdens de transporte iguais as geradas
pelo sistema com correções nos programas, tabelas, funções e
qualquer objeto que forme parte do aplicativo do SAP.
Existe uma transação no SAP encarregado da carga dos
HotPackages que deve ser chamada logo de que os arquivos
pertinentes da órdem sejam colocados no diretório de transporte.
Esta transação é a SPAM.

Ao instalar um HotPackage ao sistema estamos atualizando as
versões de muitos programas que continuará sendo standard
para SAP.
Se achamos que um programa standard foi modificado
manualmente e o HotPackage deve atualizá-lo, não poderá fazê-
lo até que liberemos a órdem de transporte onde se encontra
atestado de reparação.
8.2. Notas, OSS, SAPNet

Devido ao fato que continuamente se reportam erros e melhorias
sobre os aplicativos SAP de cada versão, BD e plataformas, SAP
criou-se uma grande base de dados com as respostas a todos os
problemas encontrados e recomendações próprias sobre muitos
outros. A cada uma destas recomendações chamamos"Notas".
Podemos procurar informação nas notas por versão do SAP,
Base de Dados, ou inclusive por letras ou palavras contidas na
mesma. Esta é uma ferramenta muito potente para o consultor
BASIS no momento de encontrar a solução para um problema, já
que possivelmente isto já aconteceu com alguém e está

devidamente documentado.
Para acessar estas notas existe duas posibilidades, mas é
necessário ter o que chamamos de usuário de OSS que SAP
fornecer a cada cliente na documentação contida no pacote de
instalação.
Com este usuário podemos acessar ao site Internet de SAPNet
com a direção: http://service.sap.com
No caso de contarmos com um acesso aos servidores do SAP
(X.25, ISDN, Frame Relay, VPN, SNC, etc.) poderemos conectar-
nos ao serviço OSS com o mesmo usuário.
Este serviço OSS permite obter as notas, traçar consultas que
serão respondidas pelos consultores SAP.
Existem muitos outros serviços no SAPNet como: literatura,
manuais, novidades, software que podem ser acessados
diretamente pela Internet.
Uma vez que temos uma nota, esta pode ter simplemente uma
recomendação ou uma modificação a um programa do SAP.
Se modificamos um programa do SAP mediante uma nota, este
programa será considerado como reparado, deixando de ser
standard e portanto sendo uma fonte a mais de complicações ao
momento de fazer upgrades ou instalar
HotPackages/SupportPackages.
É por isto que se recomenda instalar sempre o último nível de
HotPackages para evitar ter que se implementar notas que
modifiquem programas no sistema.
8.2.1. Transações SPAU, SPDD, estrutura de versão.
SAP mantém uma estrutura de versões dos seus programas
e objetos, por isso logo de que instalamos um HotPackage
permite-nos eleger entre a nova versão ou a que tínhamos
originalmente, demonstrando as diferenças e permitindo
inclusive fazer uma combinação dos mesmos como
programa final.
Para manipular as versões dos programas atualizados
utilizamos a transação SPAU e a transação SPDD para
manipular as versões dos objetos atualizados do dicionário

de dados.
8.3. Upgrade de Kernel

Também podemos realizar o upgrade do Kernel do sistema. O
Kernel pode ser atualizado de duas formas, atualizando a
"revisão" ou a versão do mesmo.
O mais comum é atualizar a revisão do Kernel, sem trocar de
versão podemos obter a solução dos problemas da revisão
anterior.
Estando o Kernel formado por programas a nível do sistema
operacional, a substituição do mesmo é muito simples, só temos
que baixar SAP e substituir os executáveis velhos pelos novos,
fazendo um respaldo no caso de surgirem problemas.
A mudança da versão de Kernel é um pouco mais complexo.
As versões de aplicação do SAP são compatíveis com certas
versões do Kernel recentes. Por exemplo SAP 3.0F pode operar
com os Kernels 3.0F a 3.1I, sendo recomendado sempre utilizar
a última.
Neste caso, se tivéssemos por exemplo Oracle como Base de
Dados, o Kernel 3.0F utiliza Oracle 7.2.2.x enquanto que o 3.1I
necessita de 7.3.3.x com o qual antes de fazer o upgrade do
Kernel é necessário fazer o upgrade da Base de Dados. Logo o
processo de cópia dos arquivos é igual ao de troca de revisão.
8.4. Upgrade de versão do SAP

O upgrade de versão do SAP é um dos processos mais
complicados para o consultor BASIS, já que se pode enfrentar
com muitas dificultades ao fazê-lo, ainda que em teoria deveria
ser uma tarefa bastante automática.
Um upgrade de versão envolve novas interfaces, novos
programas, trocas nas tabelas, conversão e mudança de dados,
e muitas modificações que assegurem que o usuário não
perderá nada do que tinha na sua versão original.
O processo de Upgrade do SAP é similar ao de instalação inicial
de um sistema, inclusive com as complicações adicionais
mencionadas.

9. Estrategias de backup
É muito importante estabelecer uma estratégia de backup global
para o sistema SAP.
Esta estratégia deverá incluir desde backups completos a nível do
sistema operacional incluindo todos os arquivos do SAP, até
backups totais ou parciais da base de dados.
Vamos diferenciar então em dois grandes grupos os tipos de
backups que devem ser realizados.
9.1. Backups ao nível do sistema operacional

Estes backups são necessários para reestabelecer uma
instalação SAP R/3 de forma rápida no caso de danos nos
discos dos servidores de aplicação.
Se realizará com ferramentas próprias da plataforma, pelo que
irá variar de uma a outra, sendo mais ou menos complicado mas
direcionado a se ter um respaldo da estrutura de diretórios tanto
do sistema operacional como do SAP.
Este backup evitará ter que instalar novamente SAP no caso de
ocorrer um desastre e o mais importante, preservará as
configurações realizadas nos perfis do sistema.
É recomendável realizar um backup total pelo menos uma vez
ao mês, não se pode esquecer que durante o backup não pode
ter atividade nos arquivos já que isto provocaria inconsistências,
isto implica que SAP deve estar baixodo durante o processo.
Esta última característica faz o tipo de backup ideal para os fins
de semana, podendo programar a nível do sistema operacional
todos os scripts necessários para baixar e subir SAP logo depois
do backup.
9.2. Backups ao nível da base de dados.

Os backups a nível da base de dados também dependerão muito
da mesma, tanto no tipo como nas ferramentas utilizadas para
fazê-lo.
Para algumas como Oracle ou Informix, SAP fornece
ferramentas próprias que interagem com a Base de Dados, sem
a necessidade de utilizar ferramentas previstas pelo fabricante.
Para outras como DB2, é necessário também a utilização de

ferramentas próprias da Base de Dados.
É muito importante definir um ciclo de backups da Base de
Dados e isto dependerá da quantidade de mudança dos dados.
Algums clientes consideram impensável e inútil voltar a um
respaldo da Base de Dados do SAP de mais de uma semana,
outros consideram que um mês está bom, tudo dependerá do
que se deseja.
Uma vez determinado o ciclo de backup basta implementá-lo e
isto dependerá da BD.
9.2.1. DB Calendário
SAP nos oferece a posibilidade de programar de forma
completa todos nossos respaldos e atividades que queremos
realizar contra a BD mediante um calendário.
Nele indicamos o dia, a hora e a tarefa que queremos
realizar, por exemplo um respaldo offline, online, dois logs ou
até uma atualização das estatísticas da BD.
Acessamos ao DB Calendário mediante a transação DB13
Mostrada a seguir:

9.2.2. Backup Offline.
Este backup da base de dados geralmente se realiza
durante os fins de semana, já que o sistema não pode ser
utilizados.
É normal realizá-lo logo depois de instalar o sistema ou
realizar mudanças importantes e depois uma vez por
semana
9.2.3. Backup Online.
Este tipo de backup deve ser feito diariamente pois o
sistema pode estar em linha. Deve-se realizar à noite
quando há menos usuários já que o acesso à base de dados
diminui o rendimento do sistema.
Se a BD for muito grande pode se realizar um backup
adicional durante a semana.
É importante notar que em um backup online se os logs de
transações são inconsistentes recomenda-se realizar um
backup de tais logs cada vez que se realiza um backup
online.
9.2.4. Backup do Log de transações.
Estes logs não são nem mais nem menos que as mudanças
realizadas na base de dados e nos permitem no caso de
problemas voltar a BD em um ponto específico no tempo.
Seu respaldo deve-se fazer diariamente depois do backup
online da Base de Dados.
9.2.5. SAPDBA/BRTOOLS
Para aqueles sistemas que utilizam uma Base de Dados que
pode ser manipulada por ferramentas do SAP R/3 como
Oracle ou Informix, SAP oferece uma ferramenta que não é
muito amigável gráficamente isto é compensado pela
potência oferecida.
A partir dela é possível levantar ou baixar a base de dados,
realizar todo tipo de respaldos e recuperações, modificar
parâmetros das tabelas e índices e inclusive realizar
modificações online da estrutura da BD. Também nos
permite realizar verificações de espaço, fragmentação e

validações da configuração da BD.
É uma ferramenta disponsível a nível do SO e se executa
com o comando sapdba, mas que pode ser utilizado
programando suas distintas operações desde o DB
Calendário.
Um exemplo da tela inicial com as principais opções é a
seguinte(>):
10. Outras ferramentas, funcionalidades e tarefas.

A continuação se tratará das ferramentas e funcionalidades que
normalmente se utiliza dentro do SAP, assim como algumas tarefas
que são próprias de um consultor BASIS que tem que administrar
um sistema R/3.
10.1. Administração de Impressoras e Spool

Uma tarefa que sempre está presente é a administração das
impressoras.
Já que a impressão é controlada por SAP e o cliente só nos

permite interagem com o mesmo, todas as impressoras devem
estar definidas no SAP para poder se utilizadas. Mesmo
quando se utiliza um método especial que permite imprimir
pelas impressoras do Windows, SAP deve estar infomrado
disso.
Há diversos tipos de impressoras, dependendo de como o
servidor de aplicação que é quem vai imprimir, as considere.
A continuação veremos a informação que devemos obter para
instalar uma impressora.
•Modelo
SAP necessita saber os códigos de comando utilizados pela
impressora para poder enviar gráficos e para isto devemos
selecionar dentro de uma série de modelos de impressora.
Por isso que não estão todos os modelos do mercado e a
lista é pequena, mas em geral funciona muito bem com as
impressoras láser HP.
•Tipo de lista de impressão.
Outra coisa a ser determinado é se a impressora é
considerada local ou remota.
Uma impressora é considerada como local quando a fila de
impressão se encontra definida no mesmo servidor de
aplicação e remota quando a fila de impressão se encontra
em outro equipamento.
Isto determinará o tipo de acoplamento da impressora, ou
seja, se vamos conectar fazendo uma chamada direta ao
sistema operacional, mediante LPD, impressão local,
impressão frontend ou o que for.
Por exemplo é normal utilizar o tipo de acoplamento local "L"
ou via LPD "U" para servidores UNIX com impressoras locais,
enquanto que para Windows NT pode ser utilizados o tipo de
acoplamento "C" de chamada ao sistema operacional ou "S"
de impressão SAPLPD.
Se queremos imprimir com as impressoras definidas no frontend
pode-se utilizar o método de acoplamento "F" que habilita a SAP
R/3 a imprimir na impressora por default do Windows.
Isto é muito útil, já que é muito mais fácil definir impressoras no
Windows que no SAP e definindo uma no SAP podemos imprimir

na qual queremos simplemente trocando impressora por default,
realmente algo muito cômodo.
A transação utilizada para a administração dos dispositivos de
saída é a SPAD.
Na seguinte(>) tela podemos ver parte dos dados de definição de

uma impressora:

Já que SAP tem o controle do que se imprime, podemos a todo
momento ver um registro da fila de impressão, ver as órdens de
impressão que deram erro e reimprimi-las ou diretamente
eliminá-las.
Este administrador da fila de impressão nos permite ver também
o conteúdo das órdens de impressão e realizar buscas de órdens
especificando critérios como data e hora, usuário, impressora,
etc.
A transação SP01 nos dá essa funcionalidade.
10.2. Jobs
Os Jobs são uma ferramenta pensada para agendar tarefas,
mediante estes jobs podemos instruir o SAP para executar um
programa ABAP/4 ou um programa no sistema operacional em
determinado momento.
E não só podemos pedir que faça determinado dia e a
determinada hora, como podemos fazê-lo repetitivo e
determinar o ciclo de repetição que queremos, diário, semanal,
por minuto, etc.
Se queremos podemos fazer que se execute logo após
determinado evento, ou depois de que outro Job se execute.
Os Jobs se executam como tarefas de fundo, pelo qual
devemos especificar dentro dos dados de Job o servidor onde

este deve ser executado, isto a SAP não faz automáticamente o
enviando-o ao que tenha menos carga nesse momento.
Cada Job pode ter um ou vários "steps", passos onde
indicamos o que fazer, assim que se pode executar um
comando do sistema operacional e logo um ABAP/4 no mesmo
Job.
Em todo momento os Jobs podem ser editados, modificados,
apagados e até executados se necessário, e guarda-se um log
de todo o acontecido durante seu processamento.
Os Jobs são utilizados normalmente para programar tarefas

pesadas durante a noite ou atualização de interfaces cada certo
tempo.
Por exemplo, podemos programar um Job que execute um
programa ABAP/4 encarregado de ler um arquivo contendo
dados gerados por um sistema externo, e incorporá-los ao SAP.
Podemos alocar três prioridades aos Jobs, desde as mais alta
"A" à mais baixas "C", o que significa que se em uma máquina
temos apenas um processo de fundo disponível e há dois Jobs
em determinado momento para ser executado, será feito de
maior prioridade e o outro terá que esperar.
A transação utilizada para a definição de Jobs é a SM36
A seguinte(>) imagem nos mostra os dados básicos de um Job
de prioridade "A" com data de começo 10 de julho de 1999 às
10:30 e um ciclo semanal.

A seguinte(>) tela nos mostra o primeiro passo deste Job onde se
especifica a execução do programa ABAP/4 "ZACTFACT":

10.3. Auditoria do sistema
Algumas vezes é necessário saber quais usuários estão
entrando no sistema, a que hora, quantos tentativas falhas de
Login ocorreram a partir da qual terminal, etc.
Tudo isto e mais se pode ser conseguido ativando os logs de
auditoria no SAP.
Para fazê-lo devemos utilizar a transação SM19 onde podemos

especificar quais atividades vamos registrar, para quais usuários,
mandante, etc.
Se o que queremos é consultar o registro de auditoria o que

devemos fazer é utilizar a transação SM20 que nos permite,
especificando uma série de filtros, observar o acontecido em um
período de tempo.

10.4. Workbench ABAP/4
Como foi mencionado anteriormente, o Workbench ABAP/4 é o
ambiente onde trabalham os desenvolvedores, mas vale a pena
conhecer um pouco dele para tirar proveito nas situações
difíceis para o administrador do sistema.
10.4.1. Editor ABAP/4
O editor ABAP/4 é a ferramenta utilizada para criar ou
modificar os programas do sistema, também é a utilizada
para modificar os programas standard ao aplicar uma nota.
O importante é que algumas vezes é possível fazer
pequenos programas que realizam tarefas que não podem
ser feitas mediante as ferramentas que oferece SAP, como
por exemplo a alteração de algums dados muito específicos
de tabelas, que de outra forma seria impossível realizar.
Podemos acessá-lo mediante a transação SE38.

10.4.2. Dicionário de Dados
O dicionário de Dados, chamado com a transação SE11
permite navegar dentro de todos os objetos de SAP e em
particular é útil quando queremos ver a estrutura e definição
dos mesmos, como a tabela mostrada a continuação:

10.4.3. Editor de Tabelas
O editor de tabelas é também uma ferramenta muito útil que

permite ver, modificar, apagar ou criar dados em certas
tabelas que permitem manutenção.
Podemos acessá-lo mediante a transação SE16
É muito simples procurar dados desta forma pois podemos
filtrar pelos campos de tal tabela e visualizar o resultado em
forma de lista como mostra a seguinte(>) imagem:

10.5. Comandos externos
Algumas vezes não nos é possível acessar ao sistema
operacional mas necesitamos alguma de informação sobre o
mesmo e não temos uma consola ou um telnet, podemos então
recorrer aos comandos externos definidos no SAP.
O que fazemos é definir uma série de comandos e ao executá-
los obtemos sua saída em uma lista SAP.
Um exemplo simles disto é ver o conteúdo de um diretório de
um servidor de aplicação UNIX.
Criamos então um comando e associamos a instrução do SO
"ls", logo ao executá-lo especificamos –l e o diretório
/usr/sap/trans. O resultado é o seguinte(>):
A transação utilizada para criar os comandos é a SM69 e com a

SM49 as executamos.

10.6. Mensagens do sistema
Quando é necessário avisar todos os usuários algo importante
como por exemplo "O sistema se baixará em 10 minutos por
manutenção, por favor se desconectar”, podemos fazer uso das
mensagens do sistema que chega a todos os usuários
conectados. Podemos especificar aqui um tempo de expiração
da mensagem e assim ela será apagada.
Este tipo de mensagem aparece quando esta é enviada e cada
vez que o usuário se conecta ao sistema, sem importar o
mandante já que são consideradas urgentes.
A transação utilizada para criá-los é a SM02.
10.7. SAPOffice
Se o que se pretende é enviar mensagens a usuários em
particular de mandantes SAP possui uma ferramenta chamada
SAPOffice com toda a funcionalidade de um servidor de
correios, pastas de entrada e saída, possibilidade de
attachments, lista de destinatários, etc.
As transações para chamar o Inbox e OutBox de SAPOffice são
respectivamente SO01 e SO02.
A seguinte(>) tela mostra o Inbox:
10.8. Ajuda e documentação

Um dos aspectos fundamentais de um sistema é ter acesso à

ajuda e que esta seja útil.
Há vários tipos de ajuda e documentação do sistema, tanto seja
da área funcional como BASIS e podemos diferenciar 3 deles:
•Ajuda interna
SAP inclui uma ajuda interna que pode ser acessada a
qualquer momento mediante a tecla F1 e muitas vezes
contém mensagens esclarecedoras que nos permite
compreender mais sobre algo.
É a ajuda mais extensa, já que quase todos os objetos,
campos de telas e funcionalidades têm esta ajuda codificada.
É além de mais rápida que já reside na Base de Dados.
Um exemplo desta ajuda ao pressionar F1 sobre o campo de
data do documento é o seguinte(>):
•Help Online
Esta é a ajuda mas completa que dispõe SAP, englobando
com muito detalhe cada um dos aspectos do sistema.

Devido à sua extensão, é proporcionada em CD, oferecendo
grandes facilidades de busca de termos e conceitos.
Posssui uma estrutura de árvore por funcionalidade o que
agiliza a busca de dados. Alé, disso cada tema possui em
umerosos vínculos a outra informação relacionadas.
Esta ajuda deve ser instalada e configurada dentro dos perfis
do sistema para poder ser utilizados dentro de SAP, algo
muito útil já que ao fazê-lo deste modo a ajuda solicitada é
sensível ao contexto, podendo obter informação ampliada
com só solicità-lo.
Ao presionar F1 obtemos a ajuda interna e se pressionamos
"Ajuda Ampliada" obtemos acesso à ajuda online sobre esse
tema em particular.
A tela de ajuda online para a versão 4.0 de SAP tem o
seguinte(>) aspecto:
11. Literatura recomendada
É muito bom recorrer periódicamente aos sites da SAP na Internet pois

há publicações muito boas sobre temas específicos relativos à
administração do sistema para cada uma de suas versões.

Alguns destes sites são:
http://www.sap.com Site oficial da SAP com muitas

publicações em formato. PDF e .DOC
http://service.sap.com Site do SAPNet ao qual se acessa com

um usuário do OSS. Se pode encontrar
muita documentação em formato .PDF e
.DOC, instalacao, upgrade, white papers,
etc.
http://www.sapfans.org É o "SAP FAN CLUB".
http://help.sap.com Help Online dos produtos SAP.
http://www.sdn.sap.com SAP Developer Network.
http://www.microsoft-sap.com SAP para plataformas Microsoft.
http://www.basisconsultant.com SAP Basis Community
12. Conclusão
Este manual foi preparado para introduzir ao novo consultor BASIS

R/3 em as funcionalidades e tarefas que deverão ser vividas ao
trabalhar com um sistema R/3.
Está pensado como uma ajuda-memória ao curso dado pelo
instrutor e não como uma ferramenta de autoestudo.
Portanto não tem o grau de detalhe nem informação que um curso
sobre um tema específico tería.
Há muitas tarefas importantes dentro das funções do administrador
que só são mencionadas, isto se deve à grande variedade e
combinação de plataformas existentes.
Estes temas que só são mencionados no manual, serão

aprofundados pelo instrutor durante o desenvolvimento do curso.
Os dados aqui contidos deverão ser complementados em todo os
casos com outras fontes de informação que oferecem ajuda
específica sobre os diversos temas tratados.
Na literatura recomendada se faz referência a essas fontes de
informação.

Apostilha Conceitos Basis

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Apostilha Conceitos Basis

Enviado por

Direitos autorais:

Formatos disponíveis

Introdução na administração SAP R/3

1. INTRODUÇÃO A SAP R/3............................................................................................................................3

Daniel Chollet Página 1

Daniel Chollet Página 2

O seguinte(>) esquema nos da uma idéia do modelo de

Daniel Chollet Página 3

1.2.1. Arquitetura Cliente Servidor

Estas três capas ou níveis possuem funções bem definidas e

Nível de Base de dados: É o nível encarregado de resolver

Nível de Aplicação: Neste nível se encontra toda a lógica de

Nível de apresentação: Este nível é o encarregado de

Daniel Chollet Página 4

SAP obtém sua melhor performance quando o esquema

Para implementar este esquema o servidor de Base de

Daniel Chollet Página 5

A possibilidade de distribuir a carga mediante a adição de

Daniel Chollet Página 6

1.2.3. Diferentes plataformas

Há diversas bases de dados que podem ser utilizados pela

Daniel Chollet Página 7

os servidores de apresentação estão disponíveis para

As principais plataformas podem ser vistas no seguinte(>)

1.3. SAP R/3 e sua interação com o SO

Daniel Chollet Página 8

Este Middleware, também chamado Kernel, está codificado e

O Kernel também deve dialogar com o servidor da Base de

Daniel Chollet Página 9

As aplicações R/3 estão formadas por "milhares" de programas,

O controle de todo o ambiente de desenvolvimento do SAP está

O esquema de acesso ao dicionário de dados é o seguinte(>):

Daniel Chollet Página 10

Existem "Buffers" na memória dos servidores de aplicação,

2. Características básicas do Sistema

Daniel Chollet Página 11

Existem muitos códigos de transação, um para cada funcionalidade

Uma vez dentro de um programa podemos voltar atrás

Daniel Chollet Página 12

Maintenance of a Three-System Landscape

Client Copy Client Copy

MAST MAST MAST

Change transport changes using DEV Development / Cust.

Daniel Chollet Página 13

O primeiro que aparece na telade Login do SAP ao iniciar a

Cada mandante tem seus próprios usuários, suas configurações

Daniel Chollet Página 14

Daniel Chollet Página 15

•Registro ou não das mudanças realizadas no mandante.

Daniel Chollet Página 16

Daniel Chollet Página 17

Daniel Chollet Página 18

Do SAP é possível monitorar o estado de tais processos de

Daniel Chollet Página 19

DIA: Processo de diálogo

*Os processos de Update U1 e U2 são semelhantes mas se

Daniel Chollet Página 20

Os modos de operação otimizam a distribuição dos recursos

2.5. Estrutura de diretórios do SAP

R/3 Directory Structure

Global Directories Instance Directories

trans <SAPSID> tmp put

profile exe global work data log

run dbg opt

Daniel Chollet Página 21