Academia Basis

Índice

ACADEMIA BASIS 1
Índice 2

USERS AND AUTHORIZATION IN THE R/3 SYSTEM 5

Authorization Concepts 5

Authorization Checks 5

Profile Generator 5

User Master Record 7

Settings for System Profile Parameters 7

Security 7

Information System e Authorization Traces 7

BACKGROUND PROCESSING 8
Background Concepts and Features 8

Operation Modes and Scheduling 9

Events in Job Scheduling 9

Changing Background Jobs 10

Job Monitoring 10

Job API, XBP-API and XMI-API 10

Authorization for Background Jobs 11

Authorization for External Commands 11

Authorization for External Management Interfaces 11

ADVANCED BACKGROUND PROCESSING 12

Types of Background Jobs 12

Parallel Processing Using Asynchronous RFC 12

XMI/XBP Interface 13
Events in Job Scheduling 14

External Commands and External Programs 14

ABAP API scheduling 15

Background Check and Troubleshooting 15

DATA ARCHIVING IN R/3 16

Definition of Data Archiving 16

How Archive Works 16

Archive Environment 17

Acessing Archived Data 17

Preparations for Data Archiving 17

Monitoring an Archiving Run 18

CCMS MONITORING INFRASTRUCTURE 19

CCMS Architecture 19

CCMS Customizing 19

CCMS CONFIGURING 20
CCMS Overview 20

Profiles 20

Operation Modes 22

Starting and Stopping Instances with the CCMS 23

SYSTEM MONITORING 23
Monitoring Architecture 23

Preparing the Monitor 24

Monitoring and Tools 25

R/3 WORKLOAD DISTRIBUTION 27

Work Process Load Balancing 27

Logon Load Balancing 28

Background Load Balancing 29

Spool Load Balancing 29

Update Load Balancing 29

Configuration Summary 31

SOFTWARE LOGISTICS 31
R/3 System, Servers and Instances 31

R/3 Data 32

R/3 Clients 32

R/3 Landscape 33

Change Requests and Transports 34

CHANGE AND TRANSPORT SYSTEM PREREQUISITES 35

Configuring the System Landscape 35

Initializing CTO 36

The TMS, Transport Management System 36

Transport Domain 36
Users and Authorization in the R/3 System

Authorization Concepts
 As autorizações existem para limitar o acesso a transações e objetos do sistema R/3 que
necessitam de proteção
 As autorizações são agrupadas em profiles e estas profiles são associadas ao master
record do usuário.
 Autorizações podem ser no nível da transação ou nos mais diversos níveis, como por
exemplo em operações na transação ou ainda em range de valores de campos
 As autorizações sempre pertencem a authorization objects. Estes objetos de autorização
são agrupados em object classes que por sua vez são organizados ou categorizados por
business area (FI, SD, etc.)
 As autorizações são mantidas através da especificação de valores para determinados
fields dentro de cada objeto de autorização (que pode ter até 10 fields). Todas as
autorizações são do tipo positivas, ou seja, efetuam grants para o usuário e não revokes.
 Um user master record pode possuir uma ou mais profiles, que podem ter sido geradas
através da definição de activity groups (profile generator – PFCG) ou manualmente.
Uma profile pode ainda ser composta de mais de uma profile (composite profile).
 As profiles são associadas ao usuário tanto manualmente através da SU01 quanto
durante o processo de geração e manutenção das activity groups.

Authorization Checks
 Quando o usuário efetua o logon no sistema suas autorizações são carregadas para a
user context area (que fica na roll area da instancia) e são verificadas a cada transação
ou atividade executada pelo usuário
 Antes que uma determinada transação ou operação ocorra, os fields do authorization
object são checados contra os fields do usuário para aquele mesmo objeto de
autorização. Esta operação é do tipo AND, ou seja, todos os n fields do objeto tem que
ser atendidos. Caso a verificação falhe, o usuário recebe uma mensagem de erro e a
operação não é executada.
 Caso o usuário possua duas autorizações contrastantes, vale aquela que libera o acesso,
já que entre fields do mesmo tipo a operação é OR

Profile Generator
 O profile generator é uma ferramenta que simplifica a administração de segurança
através de uma visão voltada para o menu de transações da empresa permitindo que de

Basis – 2 Pag. 5
 forma mais interativa se crie e associe profiles para usuário ou grupo de usuários que
executam determinada função.
 Este grupo lógico de funções comuns que possuem profiles comuns são denominados
Activity Groups.
 Um usuário pode estar associado a um ou mais activity groups.
 Ao se associar uma transação a um determinado activity group, o profile generator
automaticamente identifica os authorization objects necessários para aquela atividade e
os associa a profile que será gerada. Caso os fields sejam customer-independents, o
sistema já provê os valores necessários para a atividade, caso contrário os valores
precisam ser completados pelo administrador durante o processo de geração.
 Ao gerar um activity group o administrador de segurança deverá checar os valores
propostos pelo sistema para os diversos field e altera-los ou provê-los conforme o caso,
antes de salvar o processo
 O R/3 permite ainda que se crie os activity group com responsabilities, o que permite
que uma mesma descrição funcional (activity group) seja associada para diferentes
grupos de usuários, provendo assim diferentes níveis de autorização dentro de uma
mesma funcionalidade. Isto simplifica a administração de segurança. Neste caso os
usuários são associados a responsabilitie e não mais ao activity group.
 Isto significa que caso grupos distintos de usuários que efetuam as mesmas transações
em um sistema R/3 diferindo apenas nas autorizações para operações permitidas dentro
destas transações não mais precisam ser administrados a partir de activity groups
distintos, mas sim através de responsabilities distintas dentro do mesmo activity group.
 Neste tipo de administração, as autorizações para transação são associadas apenas uma
vez no activity group para os diversos usuários, o que simplifica caso uma nova
transação comece a fazer parte de suas atividades
 Ao exibir a lista de autorizações no profile generator, o sistema divide a exibição em 3
níveis:
 O primeiro nível contém as object class, por exemplo “Standard Finantial
Accounting - FI”
 O segundo nível contém os authorization objects, por exemplo “Customer:
Authorization for company codes – F_KNA1_BUK”
 No terceiro nível contém authorizations, por exemplo “Customer: Authorization for
company codes – T.....” e abaixo dele o sistema lista todos os fields com seus
respectivos valores
 Nesta lista e possível dar manutenção nos valores (clicando no lápis) ou ainda obter
documentação detalhada de um authorization object é só dar um duplo click na sua
descrição (segundo nível). Ao se clicar no item da montanha (authorization object) é
possível obter uma lista das transações daquele activity group que necessitam deste
objeto de autorização.

Basis – 2 Pag. 6
User Master Record
 Através da transação SU01 é possível dar manutenção nos usuários.
 A transação SU3 (ou System  User profile  Own data) permite que o próprio
usuário altere seus dados, tais como Address, Defaults e Parameters

Settings for System Profile Parameters

 Diversos parâmetros configuram o funcionalidade de segurança no R/3 e começam
sempre com o string login/:
 O parâmetro login/fails_to_user_lock controla o número de tentativas de logon mal
sucedidos antes que o sistema bloqueie a sua chave.
 A meia noite todos os usuários bloqueados por tentativas erradas durante o dia são
desbloqueados pelo sistema, a menos que se especifique no parâmetro
login/failed_user_auto_unlock para que isto não aconteça
 Existem diversos outros parâmetros para configurar o sistema de segurança de login
do R/3.
 A transação SUIM exibe através da SARP a lista de todos os usuários bloqueados no
sistema

Security
 Os clients 000 e 001 possuem os users SAP* (pwd 06071992) e DDIC (pwd 19920706)
por default com autorizações SAP_ALL, devendo o administrador alterar suas senhas
na instalação
 O client 066 utilizado pela SAP para consultoria remota possui o usuário
EARLYWATCH (pwd support) que também deverá ter a sua password alterada.
 O SAP possui um usuário SAP* com password PASS e autorização SAP_ALL hard-
coded em todos os seus sistemas. Isto significa que quando não existe um usuário SAP*
na user master table (USR01) do sistema, este usuário pode ser usado para efetuar logon
como SAP_ALL. Por razões de segurança portanto é interessante que sempre tenhamos
um usuário SAP* definido em cada client. A nota 68048 sugere um parâmetro
(login/no_automatic_user_sapstar) que quando especificado suprime a possibilidade de
utilização deste SAP* hard-coded. Porém sempre que se for criar um novo client é
necessário permitir a existência desta feature hard-coded para que se possa logar no
novo client que não possua nenhum user ainda criado.

Information System e Authorization Traces

 A transação SUIM exibe o Information System que consiste de uma série de relatórios
que te permite efetuar uma série de verificações e extrair relatórios administrativos
referentes a usuários

Basis – 2 Pag. 7
 O R/3 permite que se check quais verificações de segurança estão sendo efetuadas em
uma determinada execução de programa através de traces, que são ativados através do
caminho Tools  Administration  Monitor  Traces  System trace (veja nota
66056 para detalhes de utilização)
 Para uma analise localizada de falha de segurança pode-se utilizar a transação SU53,
que exibe quais authorizations são requeridas em determinada task.
 A transação SU56 exibe o buffer de autorização do usuário. Se uma determinada
autorização não está aparecendo, verifique:
 Se não houve uma manutenção de profile ou activity group enquanto o usuário
estava logado. Neste caso é necessário um novo logon
 Se as autorizações foram alteradas através de um transporte, é preciso emitir um
reset dos user buffers para que os novos dados sejam carregados (SU01 
Environment  Mass changes  Reset all user buffs)
 Se o buffer não está muito pequeno. O parâmetro auth/auth_number_in_userbuffer
define o numero de entradas reservada nesta área para cada usuário, devendo ser
aumentado se for o caso
 Ao se criar um usuário pela SU01 deve-se especificar a sua categoria, se Dialog, BDC
(batch input), Background (batch jobs) ou CPIC (para conexão remota).

Background Processing

Background Concepts and Features

 Um job background é um ou mais programas ABAB, external programs ou external
commands que rodam sequencialmente (steps) sem a intervenção do usuário, baseados
em eventos (event-based) ou horários (time-based) pré estabelecidos. São utilizados
principalmente para:
 Processar automaticamente tarefas rotineiras
 Processar informações vindas de sistemas legados
 Processar tarefas baseado na ocorrência de determinados eventos
 Processar uma carga em massa no ambiente em horários de baixa atividade online

 Podem ser schedulados para serem disparados baseados em determinados eventos que
ocorram tanto dentro quanto fora do R/3 (event-based jobs)
 Podem ser arranjados em classes (A, B ou C) que possuem uma hierarquia de
prioridade na execução. O sistema permite que se reserve work process para execução
exclusiva de jobs classe A. Neste caso o work process somente será ocupado por jobs
classe A e se não existe nenhum outro work process onde o job A poderia rodar
 Os jobs são disparados através de um serviço, o batch scheduler, que roda no sistema
R/3. Este serviço é um programa ABAP que roda em um dialog work process no server
parametrizado nas profiles do ambiente através do parâmetro rdisp/bcttime. Neste
parâmetro é especificado o tempo em segundos com que este programa roda,

Basis – 2 Pag. 8
 normalmente 60 segundos. Quando se especifica um valor igual a 0, o batch scheduler
fica inibido naquele server.
 Um outro parâmetro, o rdisp/bctname, define o nome do server onde os events serão
checados para o disparo de jobs através desta facilidade, os event-based jobs

Operation Modes and Scheduling

 O sistema efetua balanceamento de carga automática entre os servidores, a menos que
se especifique o server target do job. A especificação do server durante o schedule faz
com que o job tenha prioridade sobre outros da mesma classe sem a especificação
explícita do server.
 É possível configurar operation modes (através da transação RZ04) para efetuar um
switch entre work processes de dialog e batch em horários pré determinados sem a
necessidade de um stop/start do R/3 para reconfiguração dos work processes
 A gerência dos jobs é feita a partir do CCMS e os jobs são schedulados a partir da
transação SM36.
 Ao efetuar o schedule do jobe é possível especificar o nome de quem irá receber o spool
request (opção Spool list recipient) que tanto pode ser um usuário R/3 quanto um mail
do SAPOffice ou mail externo
 Programas ABAP que requerem um determinada entrada de dados para execução
poderão ser schedulados em background bastando que se informe uma variant (lista de
parâmetros) para processamento.
 Quando um job background executa comandos ou programas externos, o R/3 starta o
programa server SAPXPG no host target através de chamadas RFC.
 Programas externos somente podem ser executados por usuários com autorização para
background administrator. Comandos externos podem ser executados por usuários com
autorizações R/3 apropriadas (????). Os programas externos somente rodam em modo
síncrono e os comandos externos rodam tanto em modo síncrono quanto assíncrono,
dependendo das necessidades do usuário.
 Os jobs podem ser schedulados para rodar de diferentes maneiras:
 Imediatamente,
 Com data e hora programada,
 Após a ocorrência de um evento
 Após a execução de um outro job
 Periodicamente, etc.

Events in Job Scheduling

 Os eventos com que os jobs poderão estar dependentes são eventos internos do R/3
(system start, opmode switch, etc) ou eventos definidos pelo usuário, como por
exemplo o término de uma transferência de dados

Basis – 2 Pag. 9
 Através da transação SM62 podemos definir os user events e a transação SM64 é
utilizada para disparar os eventos.
 O programa sapevt (Unix ou NT) é utilizado para disparar um determinado evento a
partir de uma linha de comando no sistema operacional. A sintaxe do comando é
sapevt <event> [-p <parameter>] [-t] [pf=<profile_path>] [name=<SID>]
[nr=<instance]
 O sapevt se conecta ao message server da instância via tcp/ip para disparar o trigger no
R/3
 Internamente em um programa ABAP é possível ainda disparar um evento a partir da
chamada a uma função, a BP_EVENT_RAISE
 É possível concatenar os steps e schedular os jobs de forma a atender praticamente
qualquer necessidade de schedule. O sapenv pode ser o programa externo ativado para
disparar eventos que liberam outros jobs.

Changing Background Jobs

 Um job que esteja com o status de scheduled ou released pode ser alterado através da
SM37. Estas alterações poderão ser desde a inclusão de novos steps quanto a alteração
de seu scheduling. Uma alteração típica é a classe de submissão, por exemplo para
alterar a fila de prioridades.
 Jobs que estão rodando ou que já foram processados não podem ser alterado.

Job Monitoring
 Através da SM37 se monitora tanto os jobs que já rodaram quanto aqueles que se
encontram schedulados
 O job log pode ser pesquisado para verificar as mensagens do sistema para aquela
execução. A Spool list exibe a saída da execução
 A lista exibida na SM37 depende dos critérios marcados na tela inicial. É necessário
uma especial atenção para os jobs que não possuem uma data de start e para aqueles que
dependem de algum evento.
 O Job Scheduling Monitor exibe em modo gráfico o schedule nos vários servidores que
compõem o sistema ao longo do tempo. É ativada a partir do Control/Monitoring do
CCMS

Job API, XBP-API and XMI-API

 Através de programas ABAP é possível gerenciar e schedular jobs utilizando o Job
Application Programming Interface, ou Job API
 Através do Job API é possível por exemplo rodar jobs sequencialmente ou ainda
incorporar lógica de decisão no ambiente de processamento

Basis – 2 Pag. 10
 As funções ABAP para o Job API se encontram no ABAP workbench com o nome
BP_*
 XMI ou External Monitoring Interface é um conjunto de módulos de funções que
agregam todas as funcionalidades para interface externas de gerenciamento do CCMS
 XBP ou External Interface for Background Processing é a interface externa para
background-job-scheduling. Estes módulos possuem o nome comum SXMI_* e não
devem ser confundidos com os Job APIs.
 Ferramentas externas de job scheduling (XBP) permitem que se integre em um único
ambiente o gerenciamento do schedule de jobs R/3 e não R/3 através de uma única
interface

Authorization for Background Jobs

 A utilização do job scheduling exige perfis especiais de autorização para as funções de
schedule e administração. Os objetos de autorização envolvidos são:
 S_BTCH_ADM que dá as autorizações para as funções administrativas. O usuário
com esta autorização com field setado para “Y” pode administrar jobs em todos os
clients do sistema e não apenas do client onde ele está definido
 S_BTCH_NAM dá aos usuários a autorização necessária para executar jobs em
background
 S_BTCH_JOB este objeto possui funções que dão aos usuários diversas facilidades
na administração de seus jobs e de outros usuários (DELE, LIST, PROT, RELE e
SHOW)

Authorization for External Commands

 Os objetos de autorização envolvidos são:
 S_RZL_ADM que através de seus activity codes dá autorização para administração
do CCMS
 S_LOG_COM que possui fields que autorizam a utilização de external commands
 S_TCODE que dá autorização para as transações SM49 e SM69

Authorization for External Management Interfaces

 Os objetos de autorização envolvidos são:
 S_XMI_PROD define através de seus fields quais interfaces XMI e quais
ferramentas externas poderão ser utilizadas
 S_XMI_LOG define se o usuário pode acessar interfaces XMI e como este acesso
será feito

Basis – 2 Pag. 11
Advanced Background Processing

Types of Background Jobs

 Os background jobs em um sistema R/3 podem ser divididos em duas categorias:
 Basis background jobs, que efetuam tarefas necessárias dentro do ambiente R/3,
seja na coleta e armazenamento de estatísticas ou na tarefa de housekeeping da
instância, onde são normalmente schedulados como jobs periódicos
 Application background jobs, que são os jobs disparados pelos usuários em suas
tarefas funcionais dentro do sistema.
 Os jobs de housekeeping efetuam tarefas tais como limpeza do spool, jobs antigos,
sessões de batch input já processadas, limpeza de estatísticas, etc. Alguns possuem
características de serem client independentes, outros já precisam ser schedulados em
todos os clients do sistema e outros ainda possuem a característica de que devem ser
schedulados através de usuários específicos ou ainda com autorizações específicas. A
nota 16083 define esta sistemática e descreve detalhadamente os jobs de housekeeping,
inclusive quanto a periodicidade aconselhada.
 Os outros jobs que se enquadram na categoria dos jobs Basis são aqueles utilizados
para coleta e organização de estatísticas de utilização do R/3. Nesta categoria, o
SAP_COLLECTOR_FOR_PERFMONITOR executa de hora em hora o programa
RSCOLL00 que, baseado em uma tabela (TCOLL) do sistema, dispara uma série de
outros programas a cada execução para efetuar as mais diversas tarefas relacionadas ao
recolhimento e consolidação de estatísticas.
 Os jobs que executam na categoria dos aplicativos efetuando tarefas funcionais dos
módulos do R/3 necessitam de monitoração constante, já que muitas vezes manipulam
grandes quantidades de dados e são elevados consumidores de recursos, podendo
portanto interferir com a performance do sistema online
 Os jobs de aplicação devem ter uma programação estudada e ser cuidadosamente
parametrizados pelas variantes para não trabalhar volumes muito elevados de
informação. Em um ambiante R/3 produtivo, deve-se inclusive montar uma planilha de
execução para evitar gargalos de elevados volumes de processamento simultâneos

Parallel Processing Using Asynchronous RFC

 É interessante que se verifique se programas batch problemáticos e que não utilizam a
facilidade de processamento paralelo através do uso de RFC assíncrono possam ser
reanalisados para incorporar esta facilidade.
 Uma chamada do tipo Asynchronous RFC permite uma otimização no
compartilhamento dos work processes por splitar o programa ABAP em várias partes
menores que são disparadas paralelamente entre os vários dialog work process
disponíveis que compõem um determinado grupo RFC, onde os resultados são
coletados mais tarde.

Basis – 2 Pag. 12
 Esta técnica foi desenvolvida para suprir o problema de que longos background jobs
não encontravam janela noturna suficiente ou ainda quando não se encontra background
work process em número suficiente para processar os jobs
 Esta sistemática exige alguns pré requisitos de ordem técnica e conceitual para que seja
implementada corretamente. É preciso garantir que:
 O comando ABAP que dispara RFC assíncrono é o CALL FUNCTION
STARTING NEW TASK DESTINATION IN GROUP. Outras técnicas de
processamento RFC assíncrono podem levar a um impacto negativo na performance
do sistema
 Existam pelo menos três dialog work processes disponíveis, uma vez dois são
necessários para o processamento dos dialogs
 O job possa ser dividido em unidades lógicas independentes, uma vez que serão
processadas paralelamente
 A dispatcher queue deverá estar com menos de 10% ocupada para garantir que o
critério de balanceamento da carga seja feito corretamente
 Este critério portanto não se adapta a programas que devem ser processados
sequencialmente onde as unidades lógicas dependem do resultado da anterior. Da
mesma forma não existe uma garantia da sequência com que as partes serão
processadas individualmente.
 Os resultados de todas as partes separadas deverão ser coletadas, sincronizadas e
analisadas no final.

XMI/XBP Interface
 A nota 69352 descreve a forma como external programs devem se comunicar com o
R/3 utilizando a external monitoring interface (XMI) ou o external background
processing interface (XBP)
 Através da transação SE37 pode-se ter acesso aos functions groups que implementam
estas facilidades:
 External job management: Function group SXJI cujos function modules possuem o
prefixo SXMI_XBP
 External monitoring basics: Function group SXMB cujos function modules
possuem o prefixo SXMI_XMB
 Connecting to esternal tools: Function group SXMI cujos function modules
possuem o prefixo SXMI
 Existem sistemas de terceiros certificados pela SAP que permitem a administração e
gerência do schedule de jobs no R/3 através de um ambiente externo ao sistema. Estes
sistemas se comunicam com o R/3 efetuando um logon via RFC e posteriormente
através dos function modules da interface XMI
 A principal vantagem neste sistema é a possibilidade de gerenciar diversas plataformas,
inclusive diversos sistemas R/3 a partir de uma única interface centralizada. A
desvantagem é que se trata de um produto externo ao R/3 que deve portanto ser

Basis – 2 Pag. 13
 homologado e de fornecedor idôneo e confiável para possibilitar possíveis upgrades em
novos releases do R/3

Events in Job Scheduling

 Os eventos utilizados para disparar jobs no R/3 podem ser:
 System events, que são definidos pela SAP e disparados a partir de determinadas
ações definidas no ambiente, tais como um switch de operation mode
 User events, que são definidas pelo próprio usuário através da transação SM62 para
permitir uma administração mais personalizada de operação
 Os eventos podem possuir argumentos que serão checados no momento em que
ocorrem para qualificar a execução de jobs diferencialmente em um mesmo evento.
Este argumento é especificado tanto quando se schedula o job quanto no momento em
que se dispara o evento, permitindo desta forma uma perfeita sincronização de tarefas.
 Jobs schedulados sem argumentos são disparados tanto quando o evento ocorre com
argumento quanto sem argumentos.
 Os user events podem ser disparados por três formas distintas: manualmente através da
transação SM64, dentro de um programa ABAP através de chamada própria de função
(BP_EVENT_RAISE) ou ainda através de chamada a um programa externo, o sapevt.
Neste último caso a chamada poderia estar contida em um script ou até mesmo como
um step de um job R/3 (external program step)

External Commands and External Programs

 External commands podem ser executados tanto pelos administradores do sistema
quantos por usuários que possuam autorização específica
 A transação SM69 é utilizada para criar e dar manutenção em external comands, que
posteriormente podem ser executados através da transação SM49 ou inseridos em steps
dos background jobs. Através de chamadas de funções específicas também é possível
executar external commands de dentro de programas ABAP
 External commands somente podem ser executados em modo síncrono
 Para garantir a correta execução dos programas e comandos, especifique sempre o seu
path completo
 Para rodar um external program os seguintes requisitos são necessários:
 O Gateway server do R/3 deverá estar ativo para estabelecer a comunicação entre o
servidor host do processo e o target system, já que o processo é startado utilizando o
CPI-C
 Se o comando/programa não se encontra no path do CPI-C user, o path completo
deverá ser especificado, que é quem será utilizado para executar o comando.
Normalmente este usuário é o <SID>adm

Basis – 2 Pag. 14
  O diretório de executáveis do R/3 (.../run) deverá estar no path do CPI-C user, uma
vez que o comando é executado através de um programa de controle do R/3 que
gerencia o código de retorno do sistema operacional.
 Um external program pode apresentar problemas para ser utilizado, ou por não poder
ser startado ou ainda por não conseguir retornar um resultado para o job background.
Estes problemas deverão ser identificados e corrigidos através da analise da log de erro
do job ou ligando o trace de analise de external programs
 O SAPXPG, ou trace de programas externos, pode ser ligado através da execução do
comando pela SM69 e pela especificação de uma variável de ambiente, a sapxpg_trace,
no sistema target onde o comando irá rodar. O trace mais detalhado é obtido quando
esta variável é setada com o valor 3 (levels 1, 2 e 3)

ABAP API scheduling

 A Application Programming Interface (API) permite que se gerencie e schedule jobs a
partir de programas ABAP ou external programs. Com isto é possível além da total
gerencia sobre o job (display, copy, delete), exibir a log gerada ou ainda disparar
eventos.
 A API oferece duas funções de uso simplificado que, apesar de não oferecerem muitos
recursos, são extremamente simples de se usar: A BP_JOBVARIANT_SCHEDULE
que schedula um report ABAP passando apenas a sua variante para execução e o
BP_JOBVARIANT_OVERVIEW para gerencia simplificada de jobs
 Para a programação normal, utiliza-se as funções JOB_OPEN, JOB_SUBMIT e
JOB_END
 Através destas facilidades é possível dar ao usuário a capacidade de schedular e
gerenciar jobs sem contudo ter acesso a transação SM36 e SM37. Com isto é possível
implementar uma maior segurança e implementar uma padronização no nome dos jobs
no ambiente através de uma interface bem mais simplificada para o usuário final

Background Check and Troubleshooting

 Além da SM37, existem outras transações no sistema que permitem ao usuário analisar
a sua pasta particular de jobs
 A transação SMX oferece uma forma simplificada para o usuário analisar seus próprios
jobs através de listas mais compactas e campos sumarizados
 A SM39 exibe uma analise bem mais detalhada, inclusive com informações estatísticas
 Caso o usuário não esteja conseguindo administrar seus jobs, a causa mais provável será
autorizações incorretas.
 Caso os jobs não estejam rodando, além de verificar a existência de work process
disponíveis (SM50), verifique se os batch schedulers (time-based e event-based) estão

Basis – 2 Pag. 15
 rodando corretamente através da transações SM61 e SM65. Lembre-se da configuração
dos parâmetros de profile vistos anteriormente.

Data Archiving in R/3

Definition of Data Archiving

 Archiving é uma sistemática que permite transferir dados das bases de dados R/3 para
arquivos armazenados fora do ambiente R/3, seja meio magnético ou ótico, em formato
compactado. É implementado no R/3 através da transação SARA
 Várias razões podem justificar um projeto de archive:
 Falta de espaço físico no database
 Problemas com backup e recovery devido ao tamanho do banco
 Performance baixa devido a tabelas muito extensas
 Banco de dados possui grandes volumes de dados que raramente são utilizados

 Devido a razões legais ou motivado pelo negócio da empresa, uma série de informações
precisam ser mantidas disponíveis para consulta ao longo do tempo
 A frequência e a necessidade de efetuar archiving varia portanto de empresa para
empresa, baseado nos seus recursos de hardware disponíveis e no seu objeto de negócio

How Archive Works

 O processo consiste de duas etapas: na primeira os dados são lidos na base de dados
R/3 e transferidos para arquivos externos. Na segunda etapa os dados são consistidos e
deletados da base de dados. Este processamento em duas fases existe exatamente para
garantir a máxima segurança desta sistemática.
 A arquitetura de archiving é baseada em objetos de archiving que definem os processos
e contém informações sobre o processo:
 Informação sobre as tabelas que contém os dados que serão arquivados
 O programa que extrai os dados e armazena em files externos
 O programa de deleção, que compara os dados armazenados com a base e efetua o
delete se ambos estão idênticos, garantindo a integridade dos dados extraídos
 Documentação do processo (visualizado através da opção Info na SARA)

 A compressão dos dados nos files gerados é da ordem de 5, embora cluster tables não
possam ser compactadas
 O processo pode demandar muito processamento e I/O sendo recomendado rodar em
horários fora do pico no sistema.
 O processo de delete (segunda fase do arquive) pode ser selecionado para rodar
imediatamente após o extact ou para processamento posterior, comandado pelo usuário.
Apesar do processo de deleção somente ocorrer após um verificação dos dados

Basis – 2 Pag. 16
 armazenados, é interessante que durante a implantação e testes de um ambiente de
archive garantir que esta facilidade não seja disparada automaticamente.

Archive Environment
 Existem uma série de objetos de archive já desenvolvidos pela SAP para
operacionalizar o archive em diversas áreas e tabelas standard do SAP. A cada nova
versão do R/3, é uma tendência que novos objetos sejam introduzidos.
 A ferramenta ADK (Archive Development Kit) é a interface disponibilizada pela SAP
entre os ABAP archiving programs e os archive files. Ela consiste de uma série de
function modules.
 Desta forma a leitura dos dados arquivados é efetuada através de chamada a funções do
ADK. Durante o processo de gravação, o ADK pode splitar os dados que serão
arquivados em vários files. Esta interface única através do ADK garante que o dado
armazenado seja visto pelos programas ABAP na forma exata com que foram
arquivados.
 É possível utilizar o ADK para desenvolver objetos de archiving para tabelas Z,
definidas pelo usuário. Nunca a utilize para acessar tabelas SAP standard, mesmo que
não exista um objeto desenvolvido para determinada tarefa.
 O SAP ArchiveLink é uma interface para gerencia dos files arquivados.

Acessing Archived Data

 Quase todos os objetos de archive possuem programas de leitura próprios que lêem o
arquivo sequencial gerado e emitem relatórios.
 Alguns objetos nos dão ainda a facilidade de emitir relatórios que mesclam informações
arquivadas com informações do banco, como é comum em quase todas as análises de
relatórios FI
 Algumas telas R/3 podem consultar dados diretamente dos archive files, como é o caso
da FB03, MB61, VB03, entre outras.
 Apesar de alguns objetos de archive possuírem a facilidade de reload dos dados
(operação inversa do archive), é recomendado que esta operação somente seja efetuada
para corrigir erros de operação, como por exemplo archive disparado antes da hora. A
SAP recomenda inclusive que esta operação seja efetuada somente nestes casos e
imediatamente após a operação mal feita, nunca alguns dias depois.

Preparations for Data Archiving

 Archiving é um projeto que envolve cooperativamente a área de Basis, analistas e
usuários das áreas funcionais além de uma assessoria jurídica para um amparo legal dos
documentos gerados.

Basis – 2 Pag. 17
 Do ponto de vista dos aplicativos, o archive se justifica já que alguns dados se tornam
obsoletos e não mais se fazem necessários para consulta online. É o conhecido arquivo
morto das empresas
 Do ponto de vista da administração do sistema, o archive se faz necessários para
esvaziar o banco, seja por questões de tempo de backup/restore, performance ou ainda
por falta de espaço em disco.
 Os administradores de sistemas acessam as funções de archiving normalmente através
da transação SARA. Os usuários dos aplicativos ativam a interface através de entradas
nos seus menus funcionais.
 É necessário uma identificação cuidadosa das tabelas com alto índice de crescimento e
objetos que se justificam pelas necessidades do negócio. A transação DB15 é um
excelente auxílio nesta análise por fornecer uma referência cruzada entre tabelas e
objetos de archiving.
 Identifique e estude todas as notas no OSS que se referem aos archive objects que serão
implementados
 Para cada objeto de archiving é preciso definir suas parametrizações que configuram os
dados que serão arquivados e a forma como esta operação será efetuada (tamanho dos
datafiles gerados, número de registros em cada file, etc.)
 A transação SF01 é utilizada para customizar o logical file e paths
 O objeto de archive possui duas variantes para o programa de deleção. O archive run
possui uma outra variante onde você define os dados que serão arquivados

Monitoring an Archiving Run

 Um archive roda em background e pode ser monitorado através da SM37. Dependendo
da configuração efetuada (tamanho dos files), o sistema pode gerar mais de um job de
write, um para cada file. Para cada file gravado o sistema gera ainda um respectivo job
para efetuar a segunda parte do archive, a fase do check e delete.
 Através da transação SAP (funcionalidade management) é possível monitorar o
tamanho, localização dos files e número de registros arquivados
 Caso o processo de archive não seja completado com sucesso, diversas opções terão que
ser tomadas, dependendo do caso:
 Caso ocorra um erro durante um dos jobs da primeira fase (write), é preciso fazer
um backup dos files que foram gerados com sucesso, excluir o que estava sendo
gerado no momento do erro e após isto restartar o processo para que os demais files
sejam gerados e os registros deletados
 Se o erro ocorrer durante a fase do delete, ou seja, todos os files foram gerados com
sucesso e um dos jobs da segunda fase abendou, basta startar os jobs de delete
manualmente.
 Se ocorreu um erro durante a primeira fase e os jobs de delete não estão com start
automático, é preciso deletar os files que foram gerados até o momento e recomeçar
o processo

Basis – 2 Pag. 18
 Para efetuar operações de archive é preciso possuir a autorização específica
(S_ARCHIVE). A transação SARA possui uma funcionalidade de Info que descreve
para cada objeto de archive as autorizações necessárias para percorrer as tabelas do R/3
e recolher os dados. Além disso não se deve esquecer que o archive roda em
background, significando que o usuário envolvido no processo precisa possuir as
autorizações suficientes para esta tarefa.

CCMS Monitoring Infrastructure

CCMS Architecture
 A interface de monitoração do R/3 no CCMS introduz alguns conceitos novos:
 Monitoring tree, que é a árvore de monitoração que incorpora os objetos de
monitoração e os respectivos nós
 Monitoring objects, que são entidades lógicas ou físicas que são objetos de
monitoração como por exemplo: Disk, CPU, etc.
 Monitoring Attributes, que são os itens passíveis de monitoração de cada objeto,
como por exemplo: CPU Idle %, CPU utilization, CPU queue length, etc.
 Monitoring tree element (MTE), que é cada um dos nós desta árvore

 Os atributos monitorados podem ser categorizados como de performance, de message,

de heartbeat ou de text.

CCMS Customizing
 Para funcionar efetivamente, o system monitor precisa ser configurado, ou
customizado, conforme as necessidades de administração
 Para evitar processos repetitivos de configuração dos MTE, procure agrupar os atributos
por MTE classes, e a partir daí defina para a classe seus alerts priorities, níveis de
visibilidade, mensagens, etc. que valerão para todos os MTEs da classe.
 Da mesma forma, agrupe os atributos que estejam logicamente interligados em
customizing groups. Para estes grupos associe então os thresholds dos alerts, as
mensagens de alerta, etc.
 Estes grupos podem ser divididos em dois tipos, baseado nos diferentes tipos de
atributos que eles contém: os performance grupos e os message grupos
 Daí para a frente todas as atividades de customizações serão efetuadas para as classes e
para os grupos
 Três tipos de ferramentas podem ser associadas às classes:
 Data Suppliers, que podem ser do tipo ativos (rodam permantemente) ou passivos,
que rodam disparados pelo autoABAP program SAPMSSY8
 OnAlert tools, que também são disparados pelo SAPMSSY8
 Analysis tools, que são disparadas manualmente

Basis – 2 Pag. 19
 AutoABAP programs são programas ABAP fazem parte do kernel do R/3 e que rodam
regularmente baseados no parametro de profile rdisp/autoabaptime (default 300). Uma
lista total destes programas pode ser obtida a partir do menu CCMS:
Control/Monitoring  Control Panel  Utilities  Diagnosis  Cyclic system prog.
A nota 16201 fornece mais detalhes sobre estes programas
 Ao analisar o monitor, ao terminar a analise de um alert é necessário setar a mensagem
no monitor para que a mesma desapareça nas próximas análises.
 É possível extender o monitor do CCMS através da transação SM59 para inserir
sistemas R/3 externos no processo de monitoração. Esta monitoração remota é
executada através de chamadas RFC
 É
possível ainda definir Monitor Sets para configurar suas próprias árvores de MTEs
 As customizações ficam armazenadas em tabelas AL* que são objetos passíveis de
transporte.

CCMS Configuring

CCMS Overview
 O CCMS permite executar as seguintes tarefas básicas
 Dar manutenção nas profiles do sistema R/3
 Definir operation modes para gerenciar um ambiente 24 horas onde é possível
alterar a configuração dos work processes sem necessidade de stop/start
 Start/stop de instancias
 Definir logon groups para load balancing
 Monitoração e análise do sistema e da rede
 Gerenciar o database e archiving

 Para o correto funcionamento do CCMS, o primeiro passo é a sua configuração, que

consiste dos seguintes passos
 Importar e manter as profiles
 Definir operation modes (pelo menos um)
 Criar a definição das instancias
 Configurar as instancias com os modos de operação
 Definir a timetable de operação

 A incorreta configuração do CCMS não impede o funcionamento do R/3, porém

impede que o CCMS exiba dados úteis

Profiles
 A transação RZ10 do CCMS permite que se dê manutenção nas profiles das instancias
do R/3. Ela mantém os parâmetros na base de dados do R/3 e a cada alteração efetuada

Basis – 2 Pag. 20
 uma nova versão é gerada nesta base de dados. Quando ativamos uma versão de profile
através desta interface, seus parâmetros são copiados e transferidos para a profile ativa,
que fica em diretório próprio do sistema operacional. Desta forma a base de dados do
R/3 pode conter várias versões de uma mesma profile, um histórico das alterações além
de documentação dos parâmetros.
 Através desta transação é possível efetuar as mais diversas operações:
 Importar as profiles do sistema operacional para a base de dados do R/3 (veja
preparação do CCMS) para permitir sua edição
 Manter várias versões de uma determinada profile e autodocumentar todas as
alterações efetuadas.
 Editar as profiles e ativar as novas versões geradas
 Efetuar várias opções de checagem das profiles

 Em ambientes distribuídos com várias instancias R/3, o diretório de profiles é

compartilhado entre todas as instancias e permanece como repositório central de todas
as profiles
 Para cada sistema R/3 existem várias profiles. Uma DEFAULT profile e, para cada
instancia do ambiente, uma instance e uma start profile.
 Através da ferramenta RZ10, existem dois modos de exibição/edição das profiles:
 Em basic mode, os parâmetros que são alterados mais frequentemente são
agrupados de acordo com suas interdependências de modo que a alteração em um
deles se reflita automaticamente nos demais. Nesta interface basic os parâmetros
aparecem sem os seus nomes técnicos, mas apenas como campos em screen.
 Em extended mode, os parâmetros aparecem e são editados em uma interface tipo
editor de texto, onde cada parâmetro é listado com o seu nome técnico e respectivo
valor. O administrador aqui deverá conhecer os seus nomes técnicos e é claro suas
interdependências.
 O programa de instalação, R3SETUP, cria a primeira versão das profiles no sistema
operacional de acordo com os recursos do sistema (memória e CPU). Durante o
processo de configuração inicial do CCMS, importamos estas profiles para a base de
dados R/3 utilizando a RZ10 e efetuamos as nossas customizações. Isto permite uma
gerencia centralizada de todas as profiles de um ambiente.
 As profiles utilizadas pelo R/3 para configuração da instância durante o startup é
sempre a profile ativa, ou seja, aquela que se encontra copiada no sistema operacional.
A partir do momento que importamos as profiles pela RZ10, todas as manutenções
sempre deverão se dar através desta interface nunca diretamente no sistema operacional
para evitar que haja dessincronização das ferramentas. Qualquer dúvida quanto ao
sincronismo poderá ser verificado através de seus mecanismos de check.
 Do ponto de vista do R/3, uma profile consiste de duas partes lógicas: entradas nas
tabelas da base de dados do R/3 e um arquivo no sistema operacional. Como a versão
utilizada pelo startup é a do OS (profile ativa), alterações efetuadas nos parâmetros
deverão ser salvas no sistema operacional e somente terão efeito no próximo start da
instância.

Basis – 2 Pag. 21
 Somente a versão mais recente de uma profile pode ser ativada pela ferramenta RZ10.
Na prática isto significa que a tentativa de ativar uma versão mais antiga faz com que a
profile seja copiada com uma nova versão e ativada. Qualquer manutenção vai sempre
gerando novas versões na base de dados que ficam documentadas como comentários e
headers no file do sistema operacional.
 Alterações em parâmetros de configuração de memória do R/3 poderão ser ativados
sem a necessidade de stop/start através da opção de Dynamic Switching na RZ10
 O procedimento de check de profiles oferece vários mecanismos de aferição de suas
integridades:
 Comparar a profile da base de dados com a profile ativa no sistema operacional
 Verificar a sintaxe dos parâmetros codificados
 Verificar se os valores especificados nos parâmetros são válidos ou ainda se não
estão muito discrepantes (por exemplo 10 vezes maior que o default, etc.)
 Efetuar comparações entre todas as profiles definidas para encontrar inconsistências
de definição. Com isto é possível encontrar erros na definição de mais de um
message server, por exemplo.
 O sistema efetua um check automático de consistência entre a profile ativa e a base de
dados sempre que efetua um startup. Caso encontre alguma discrepância um alert é
ativado no Alert Monitor

Operation Modes
 Operation mode é uma facilidade do R/3 que permite que se configure diferentes
combinações nos tipos de work processes que podem ser ativados ao longo do dia sem a
necessidade de stop/start da instância.
 Isto permite que possamos ter por exemplo uma maior disponibilização de background
work processes durante períodos de maior demanda desta funcionalidade, como
períodos noturnos. Já os períodos diurnos são caracterizados por uma demanda muito
maior de processamento dialog.
 Operation mode permite portanto maximizar a utilização dos recursos do sistema sem a
necessidade de stop/start das instancias para que as configurações tomem efeito
 Uma configuração básica de operation mode especifica os serviços ou tipos dos work
processes e os períodos escolhidos para cada intervalo.
 É através desta funcionalidade que conseguimos configurar background work processes
para processamento exclusivo de jobs classe A
 Operation mode pode ser configurado baseado em alguns conceitos básicos:
 O número total de work processes deve permanecer o mesmo entre os operation
modes de uma instancia, já que nenhum novo serviço será startado, apenas os
processos terão suas funcionalidades reconfiguradas.
 Cada instancia deverá permanecer com o requisito mínimo de dois dialog processes
 Cada sistema deverá permanecer com um processo de enqueue e pelo menos um
update.

Basis – 2 Pag. 22
 A transação RZ10, através de seus mecanismos de check, oferece recursos para efetuar
estas verificações das profiles e dos operation modes configurados.
 A mudança de configuração entre operation modes pode ocorrer manualmente sob
demanda do administrador do sistema através da RZ04 ou então de forma automática
através da definição de um schedule de horários chamado de timetable, que configura
um ciclo completo de 24 horas. Este schedule de horários é mantido através da
transação SM63.
 A timetable é única para todas as instancias de um sistema. Isto significa que todas
deverão possuir a mesma configuração de operation modes, porém cada uma poderá ter
a sua configuração individual de work processes.
 Além da timetable normal que configura o ciclo de 24 horas do operation mode, é
possível definir uma timetable excepcional para ser ativada em uma data específica.
Enquanto uma timetable normal deve possuir entradas que cobrem todas as 24 horas do
dia, uma timetable excepcional poderá possuir entradas apenas para um determinado
período do dia. Nos demais períodos continuariam valendo as definições da timetable
normal
 Quando a mudança entre modos de operação ocorre, os work processes são distribuídos
automaticamente, sem necessidade de parada e restart das instancias. Nenhum tempo é
perdido por indisponibilidade do sistema, apenas o tipo dos work processes é alterado,
permanecendo porém o número total inalterado.
 É possível simular o switch de um operation mode em test mode e desta forma analisar
possíveis falhas através da log de switch. Discrepâncias existentes na configuração das
profiles ou na definição dos operation mode poderão ser identificadas e eliminadas.

Starting and Stopping Instances with the CCMS

 Através do CCMS, transação RZ03, é possível startar e parar as instancias R/3 de um
sistema. A instancia de banco de dados e pelo menos uma instancia do ambiente
precisam porém ter sido startadas através das ferramentas do sistema operacional.
 Em plataformas UNIX é utilizada a facilidade de rexec para esta operação remota.

System Monitoring

Monitoring Architecture
 O Alert Monitor é uma ferramenta configurável que existe no R/3 e permite a
monitoração de todo o ambiente a partir de uma única interface que exibe mensagens e
sinais de alerta no sistema.
 A monitoração dos diversos componentes e ferramentas do ambiente R/3 é uma
operação necessária executada pelos administradores do sistema para melhorar a

Basis – 2 Pag. 23
 performance, garantir a disponibilidade do sistema e identificar, analisar e corrigir erros
que aparecerem no ambiente.
 Esta monitoração é uma tarefa periódica que abrange desde o sistema operacional,
passando pelos componentes do kernel R/3 e indo até a base de dados do sistema
 Os objetos passíveis de monitoração no ambiente R/3 são arranjados em uma árvore
que sumariza em seus nós as diversas áreas de atuação. Esta monitoring tree agrega
atributos em seus nós que podem ir sendo detalhados até chegar a granularidade mínima
da entidade monitorada.
 Um alert identificado em um destes atributos se reflete visualmente através de cores
(verde-ok, amarelo-warning, vermelho-alert) nos nós da árvore e hierarquicamente são
transferidos para os galhos mais elevados. É necessário portanto ir efetuando operações
de drill down no Alert monitor até identificar o atributo que gerou a mensagem
 É previsto para releases futuros do R/3 que a funcionalidade do monitor se estenda para
análise do transport system e das transações de aplicação
 O monitor do R/3 é concebido com uma arquitetura aberta que permite inclusive que
ferramentas de terceiros sejam incorporadas a sua árvore de monitoração.
 Cada nó da árvore é denominado MTE (monitoring tree element), que podem ser
agrupados em classes de monitoração. Os objetos físicos ou lógicos que são passíveis
de monitoração são denominados Monitoring Objects.

Preparing the Monitor

 O Alert Monitor precisa ser customizado e configurado para funcionar corretamente.
 Cada MTE class pode ser configurada baseado em quesitos tipo nível de visibilidade
(operador, administrador, etc.), prioridade do alerta e descrições. Estas configurações
ficam válidas para todos os objetos pertencentes a uma determinada classe, evitando
assim redundância de definições
 Os atributos comuns também podem ser agrupados em customizing groups aos quais
são associados thresholds para os alerts e textos de alerta
 Uma vez configurados os alerts, é possível então associar tools aos MTEs. Estas
ferramentas permitirão:
 Coletar dados
 Analisar os alerts
 Reagir aos alerts (OnAlert tool)

 As ferramentas podem ser associadas aos MTE classes ou a um MTE individualmente.

Estas ferramentas tanto poderão ser ferramentas standard da SAP quanto ferramentas
definidas e criadas pelo usuário.
 A árvore básica de monitoração contém o Basic monitor, porém o usuário pode criar
suas próprias árvores customizadas de monitoração.

Basis – 2 Pag. 24
Monitoring and Tools
 Na estrutura do Alert monitor cada server é exibido separadamente. Cada server tem
sua própria árvore que contém as seguintes estruturas: Operating system, Database, R/3
services, R/3 basis system, R/3 ABAP e R/3 system log
 A system log (transação SM21) contém informações referentes aos sistemas R/3 e exibe
mensagens categorizadas por classes: S (R/3 start/stop), W (rollback perfomed), K
(kernel program error) e T (ABAP transaction error)
 O nó R/3 services provê informações sobre os work processes do sistema
 A transação SM51 nos dá um overview dos servers disponíveis, enquanto a SM50
analisa os work process de um server específico. A SM66 oferece um overview de
todos os work processes ativos em todos os servidores do sistema
 A SM04 e AL08 nos dá um overview dos usuários logados no ambiente R/3
 O processo de update no R/3 é usualmente executado em modo assíncrono, onde os
dados são escritos em tabelas intermediárias (VB* tables) e posteriormente transferidas
para a base de dados pelos work processes de update V1 e V2. A transação SM13
permite a monitoração da fila e dos processos de update.
 A fila de update poderá conter processos que terminaram com erro. Apesar de ser
possível em alguns casos restartar estes processos, a SAP não recomenda que se
proceda ao restart da transação pelo usuário.
 O R/3 possui seu próprio mecanismo de lock que fica residente em uma tabela na
memória da instancia que contem o processo de enqueue. Os locks podem ser
monitorados através da transação SM12. Locks que permanecem no sistema poderão
ser eliminados manualmente após exaustiva verificação das causas, uma vez que o
procedimento normal é quando os locks postados são eliminados automaticamente pelo
update das tabelas ou cancelamento da transação.
 A transação ST22 permite que se analise os dumps de programas ABAP. Através desta
análise é possível identificar o erro pela análise dos campos e variáveis envolvidos e
eventualmente procurar no OSS por notas que corrijam o problema.
 A ST03 é o workload monitor que permite analisar os tempos de resposta. As
estatísticas dos tempos de resposta das transações são apresentados de forma detalhada
e estratificados por componentes (rolltime, wait time, DB time, processing time e load
time) permitindo a rápida identificação de possíveis gargalos no ambiente R/3
 As estatísticas apresentadas pela ST03 permanecem em um arquivo do sistema
operacional (file stat no diretório data da instancia) e são recolhidas e consolidadas de
tempos em tempos pelo programa RSCOLL00 schedulado no ambiente. Este programa
se baseia na tabela TCOLL para disparar uma série de programas satélites que efetuam
as mais diversas tarefas de consolidação.
 A SMLG permite definir e monitorar logon groups. Com esta facilidade é possível fazer
balanceamento de carga através da distribuição inteligente dos usuários das diversas
áreas pelos servidores de aplicação da rede.

Basis – 2 Pag. 25
 A transação ST02 provê informações referentes aos status dos buffers e o
gerenciamento de memória do ambiente
 Os work processes alocam áreas na memória para trabalhar os processos. Um dialog
work process trabalha em modo multiplexado para otimizar a sua utilização entre os
diversos dialog steps que compõem um transação R/3. Para permitir esta multiplexação,
os dialog work processes efetuam operações de roll out e roll in da user context area
dos processos. Quando um processo é rolled out por um work process e posteriormente
rolled in por outro dialog da instancia ocorre o que chamamos de work process
dispatch
 Diferentes tipos de memória são alocados pelos dialog work processes. Inicialmente o
sistema aloca uma pequena porção da roll area (definido no parâmetro ztta/roll_first)
onde estabelece ponteiros para os diversos pedaços de memória que vão sendo alocados
na extended memory do sistema. Uma vez esgotado o limite de memória obtido na
extended memory, o dialog passa a utilizar o restante da roll area disponível. Note que
ao entrar em multiplexação, o processo de roll out/roll in efetua rolagem apenas da
porção de memória alocada na roll area, já que a extended memory permanece alocada
mas tem os seus ponteiros salvos no processo. Quando toda esta área esgota, o dialog
lança então mão da memória local, ou heap area. Como esta memória não pode ser
rolled out (por ser grande), o dialog entra em modo PRIV (private) e para de fazer
multiplexação, permanecendo alocado para o usuário mesmo durante os dialog steps.
 Como os background work processes não necessitam fazer roll in/roll out por não serem
conversacionais, a sequencia de alocação de memória varia em relação aos dialog. O
sistema aloca a roll area, posteriormente a privaty memory (heap) e somente então faz
uso da extended memory, que fica desta forma mais dedicada para os dialog process.
 Quando se trabalha com vários application servers em um ambiente R/3, é necessário
que os servers permaneçam sincronizados para garantir a integridade dos insert e
updates que ocorrem no ambiente. Os dados que necessitam de sincronização são
escritos em uma tabela (DDLOG) que de tempos em tempos é consultada e os dados lá
presentes sofrem refresh na memória das instancias, sendo desta forma sincronizados. O
parâmetro rdisp/buffrefmode especifica como a escrita e leitura desta tabela ocorre e o
parâmetro rdisp/buffreftime especifica a frequencia do refresh.
 O parametro rdisp/buffrefmode possui um valor dividido em duas partes. O primeiro
campo especifica se o sistema irá (sendon) ou não (sendoff) escrever valores na
DDLOG. O segundo campo especifica se o sistema irá (exeauto) ou não (exeoff) efetuar
leitura e consequentemente refresh dos dados lá gravados.
 Sistemas distribuídos com várias instâncias deverão ter o parâmetro
rdisp/buffrefmode=sendon/exeauto especificado em cada uma de suas instance profiles.
 Até mesmo sistemas que possuem apenas uma instancia deverão especificar este
parâmetro para sendoff/exeauto já que durante o processo de transporte o tp grava
entradas nesta tabela para posterior refresh.
 A transação ST04 permite monitorar a base de dados do ambiente deforma detalhada,
seja através de análise de buffers ou da análise física de discos e locks.

Basis – 2 Pag. 26
 A ST06 exibe informações referentes ao sistema operacional recolhidas pelo programa
saposcoll. A análise pode ser tanto um retrato do instante quanto uma comparação
evolutiva das últimas 24 horas.

R/3 Workload Distribution

Work Process Load Balancing

 A ferramenta de instalação R3SETUP é utilizada tanto para a criação de central
instances (DVEBMGSnn) quanto de dialog instances (Dnn) no ambiente R/3. O sistema
configura profiles iniciais que podem ser editadas seguindo a vontade do administrador
para configurar novos serviços.
 Através da definição de operation modes podemos distribuir os work processes (dialog,
background, update) entre os diversos servidores que compõem um sistema R/3
 Os work processes de spool são distribuídos através da definição das profiles pela RZ10
 Uma vez que o usuário se logou a um determinado servidor do sistema, todos os seus
dialog steps são despachados dentro daquela mesma instancia. Já as suas requisições de
serviços de spool, update e background poderão ser atendidos por qualquer um dos
servidores distribuídos na rede.
 Cada instancia R/3 possui seu próprio dispatcher e sua própria queue de requisições
organizada de forma FIFO – first in first out, mantida na shared memory da instancia
 Qualquer chamada de serviço (outbound request) que não seja uma comunicação com o
frontend e nem uma chamada RFC é encaminhada pelo dispatcher para o message
server. Isto aconterá com os outbound requests para spool, update, enqueue e batch
processamentos que a instancia não possuir work process para atender
 A fila do dispatcher pode ser visualizada através do programa dpmon (nível do sistema
operacional) ou da transação RZ03, Edit -> Other views -> Dispatcher queues
 Cada dispatcher organiza sua fila criando queues para cada tipo de work process: DIA,
BTC, UPD, UP2, SPO, ENQ e uma fila NOWP para outgoing requests vindos destes
vários work processes. O tamanho default para cada uma destas filas é 2.000. Caso a
instancia não possua um determinado serviço (por exemplo UP2), sua fila terá um
tamanho de 5 requests apenas. O tamanho da fila do dispatcher é mantida através do
parâmetro de profile rdisp/elem_per_queue
 Caso ocorra um overflow na queue, será gerada uma mensagem na SYSLOG. A
monitoração das filas pode ser executada através da SM51, selecionando um servidor e
requisitando Goto -> Queue information
 Para comparar a distribuição de carga entre os diversos servidores, a transação ST03.
Através do Detail analysis menu é possível inclusive requisitar que as comparações
sejam exibidas em modo gráfico: Compare all servers -> Graphics -> Avg response
time/Dialog steps

Basis – 2 Pag. 27
 Uma análise do CPU tme dos work process pela SM50 permite efetuar uma análise
para cada tipo de serviço se o número de work process foi definido suficientemente.
Como a distribuição dos serviços pelo dispatcher é feita de forma sequencial, os últimos
work processes de um determinado tipo com valores elevados de CPU indicam
ocupação constante e portanto espera de processos na queue. O incremento do número
de work process entretanto precisa ser analisado visando o recurso de hardware
disponível na instancia.
 Evite o logon de usuários na central instance para evitar sobrecarga, já que
normalmente esta instancia estará oferendo os serviços de DB. Distribua as interfaces
entre as instancias e faça o mesmo com a carga de spool e background

Logon Load Balancing

 O logon load balancing é utilizado para dinamicamente distribuir os usuários entre os
diversos servidores de um sistema. Isto trás uma série de benefícios:
 Caso um server caia, os usuários poderão continuar a se logar nos outros servers do
sistema sem a necessidade de reconfiguração do saplogon
 Possibilidade de agrupar usuários de áreas afins em servidores específicos com isto
otimizando a utilização dos buffers das instancias que somente conterão dados e
programas relacionados com aqueles usuários
 Utilização racional de code pages específicas quando houver necessidade deste tipo
de configuração (por exemplo japanese)
 A configuração dos frontends passa a especificar o logon para um grupo específico e
não mais um servidor específico. A conexão neste caso é feita com o message server
(serviço 36nn) e não mais diretamente com os dispatcher (32nn)
 O dispatcher inicialmente procurar avaliar entre os servidores disponíveis no grupo
aquele mais indicado para receber a conexão de logon e aí então encaminha o usuário
para o dispatcher selecionado.
 O programa RSRZLLG0 é utilizado para efetuar o balance baseado em critérios como
tempo de resposta e número de usuários logados em cada server. Este programa roda a
cada 5 minutos ou a cada 4 usuários que se logam e determina o server favorito para o
logon a cada instante. Este balanceamento é baseado em pesos que são dados aos itens.
A nota 51789 descreve o critério e como altera-lo para melhor se adaptar as suas
necessidades
 A transação SMLG pode ser utilizada para monitorar a lista global dos usuários
logados (Goto -> User list), a distribuição de carga entre os servers (Goto -> Load
distribution) ou ainda ver qual o server favorito para logon (Goto -> System diagnosis
-> Msg. Server status area)
 Procure sempre especificar logon groups com mais de um server provendo assim uma
maior disponibilidade para o sistema.

Basis – 2 Pag. 28
Background Load Balancing
 A tabela TBTCS exibe informações sobre os jobs schedulados no ambiente. Através da
transação RZ01 é possível monitorar os jobs que estão ultrapassando o tempo médio de
tempo de execução.
 A transação RZ15 permite monitorar os interface-driven jobs. O global work process
monitor (SM66) pode ser utilizado para analisar a distribuição de carga dos background
jobs no sistema.
 Não permita que jobs batch rodem na central instance. Deixe suas CPUs reservadas
para os processos de update
 Considere a possibilidade de especificar valores diferentes para o parâmetro
rdisp/btctime, o batch scheduler, entre os vários servidores (por exemplo 61, 62, etc.).
Com isto eles rodarão em tempos diferenties e efetuarão uma distribuição mais eficiente
dos background jobs entre as instâncias.

Spool Load Balancing

 Considere a possibilidade de acrescentar as impressoras mais críticas ao Alert monitor
 A SM66 deverá ser utilizada para identificar spool work processes super ou sub
utilizados
 Defina spool lógicos para efetuar uma melhor distribuição de carga.
 Quando especificando um device, não utilize a opção Sequential Request Processing e
habilite a opção Do not ask for print requests on host spool
 Utilize preferencialmente os spools tipo L ou C

Update Load Balancing

 Cada sistema R/3 precisa ter definido pelo menos um update work process. É
recomendado ainda que pelo menos um update tipo 2 seja definido no ambiente para
tratar as atualizações que não são time criticals
 O Dynamic Update Assignment cuida de distribuir os updates V1 e V2 entre os
diversos servidores de update disponíveis.
 Apesar de processado em work processes separado (quando disponível), os updates V2
somente serão processados após a porção V1 do processo tiver sido executada com
sucesso.
 Quando um request de update é disprado por um dialog server, o sistema verifica uma
área da shared memory denominada Update Dispatcher Information, para descobrir em
qual server o update deverá ser executado. Ele se baseia em algoritmos internos de
balanceamento de carga (o dynamic update assignment) e a partir daí o update request é
colocado na NOWP queue do dispatcher onde o update foi gerado.

Basis – 2 Pag. 29
 Os updates são distribuídos em um processo cíclico sequencial entre os servers
disponíveis obedecendo ao número de update work processes disponíveis em cada um.
Quando um ciclo completo de distribuição se fecha, o sistema inicia outro baseado no
mesmo critério. Este processo faz com que os updates sejam distribuídos ao acaso
fazendo com que updates pesados sejam distribuídos aleatoriamente entre os servidores
disponíveis.
 Quando o algoritmo endereça um update para um determinado server, o message server
entra em ação e movimenta o request da NOWP queue do server que gerou o request
para a UPD queue do server que executará o serviço
 Ao analisar os update work processes pela SM66, observe se o último update de cada
instancia mostra pouca ou nenhuma CPU. Além disso o primeiro work process deverá
apresentar muito mais CPU que os demais. Se o sistema não apresentar este perfil,
possivelmente estará havendo um gargalo no ambiente causado pela definição de
poucos work processes de update. Use ainda a transação SM51 para exibir o maximum
request wait. Este valor deverá ser muito próximo de zero. Por outro lado caso existam
muitos work processes com zero de CPU, certamente está havendo um excesso de
recurso alocado.
 Para verificar a fila dos processos de update no dispatcher, utilize transação RZ03 (Edit
-> Other view -> Dispatcher queue). A transação SM13 exibe o status do update. Nesta
transação, através da opção Goto -> Server, podemos ainda verificar o número de
updates enviados para cada server bem como informações do dispatching
 Por questões de performance, ao analisar o CPU time dos update processes em cada
server, mantenha pelo menos um com 0 de CPU. Isto garante que não haverá gargalos
neste serviço
 Existe uma relação de custo benefício em se manter os updates centralizados na central
instance ou distribuídos pelos servidores:
 Central instance: a vantagem é que as instâncias não precisarão manter programas
de update de todos os módulos otimizando assim a alocação dos buffers dos
servidores do logon group. A desvantagem é que não se faz uso do balanceamento
de carga do update, que se encontra centralizado
 Distribuído pelas instancias: a principal vantagem é o balanceamento distribuído
do processamento de update, conforme descrito acima. A contrapartida é que todas
as instâncias terão em seus buffers programas de update de todos os módulos, já que
quem distribui os processos é o automatic load balancing de update.
 A configuração do update é executada pelos seguintes parâmetros de profile:
 rdisp/vbname: especifica o nome do servidor de update quando o automatic
dispatching é desabilitado
 rdisp/vb_dispatching: habilita o automatic dispatching. Este parâmetro somente
deverá ser alterado quando explicitamente recomendado pela SAP
 rdisp/vb_context: seletor para partes do contexto de update
 rdisp/vb_included_server: lista dos servers que participam do dispatching. Quando
não especificado o sistema assume todos os servidores que possuem updates
configurados

Basis – 2 Pag. 30
  rdisp/vb_refresh_info: especifica o tempo em segundo com que haverá um refresh
da lista de dispatching
 rdisp/max_vb_server: máximo número de VB servers
 rdisp/wp_no_vb e rdisp/wp_no_up2: especificam os números de update work
processes (tipo 1 e 2) configurados na instancia

Configuration Summary
 Não existe uma regra específica para o número de work processes configurados em
cada instancia, devendo o número ser ajustado por observação da demanda.
Recomenda-se apenas que se deixe sempre um work process de cada tipo com 0 de
CPU garantindo a ótima distribuição da carga. Existe uma recomendação informal da
SAP que se configure 3 spool work processes por servidor de spool para que se tenha
sempre um livre enquanto os outros dois estejam efetuando job quering e connection
checking.
 Utililize a seguinte regra por instancia:
Tipo Mínimo Máximo No sistema
Dialog 2 n 2xS - n
Background 0 n 0(2) – n
Update 0 n 1–n
Update 2 0 n 0–n
Spool 0 3 0(3) – n
Enqueue 0 1 1

Software Logistics

R/3 System, Servers and Instances

 Uma instancia R/3 é um grupo de serviços que são inicializados e parados
simultaneamente por um dispatcher, possuindo em comum uma profile de instancia.
O nome de uma instancia é composto pelos nomes que identificam os serviços (Dialog
Update Enqueue Background Message Gateway) por ela executados (update em alemão
se escreve Verburren). Uma central instance contém tipicamente todos os serviços R/3
instalados, daí o seu nome ser DVEBMGSnn, já uma dialog instance possui o nome
Dnn, onde nn é o system number utilizado para compor o número das portas que
efetuarão as chamadas ao dispatcher (32nn) e ao message server (36nn) na camada
TCP/IP.
 Um server pode conter uma ou mais instancias R/3 configuradas. Um PC com o
frontend SAPGUI instalado também é considerado um server da camada presentation
na arquitetura R/3
 O database server é um hardware que possui o RDBMS relacional instalado. É comum
em R/3 instalarmos o database server no mesmo host que contém a central instance.

Basis – 2 Pag. 31
 O conjunto de todos estes servidores com suas respectivas instancias R/3 compõem um
R/3 System. Um sistema agrega uma única central instance que aloja o message server
e normalmente um ou mais application servers.

R/3 Data
 Os dados no R/3 podem ser divididos em duas categorias:
 Client dependents data, que são os dados pertencentes a apenas um client de um
sistema R/3, como por exemplo os master (dados mestres das tabelas) ou os
application data (dados transacionais)
 Client independent data, que são as informações pertencentes a todo o sistema,
como algumas configurações ou o repositório de objetos
 O dicionário ABAP é um dicionário de dados que faz parte do repositório ABAP de
um sistema R/3. Seus dados são client independents. Os programas ABAP armazenados
no dicionário são compilados uma vez no primeiro acesso (early binding) e ficam
armazenados em um outro repositório de executáveis (tabelas D010*). Cada alteração
em um programa força a sua recompilação no primeiro acesso posterior. Este
procedimento denominado late binding é possível através de um mecanismo de
comparação de timestamp.
 Este mecanismo de early binding e late binding garante que a integridade das
informações contidas no dicionário ABAP não afete a performance do sistema, uma vez
que os executáveis de telas e programas são mantidos atualizados automaticamente em
uma área separada dos respectivos fontes.

R/3 Clients
 Um client em R/3 é uma unidade independente em termos organizacionais, técnicos e
comerciais. Um client possui seus próprios usuários e seus próprios dados nas tabelas
do R/3. Isto permite que um único sistema R/3 administre vários clients diferentes,
cada um com seus próprios dados.
 Como a base de dados (consequentemente as tabelas) é única em um sistema R/3 os
dados dos diferentes clients ficam armazenados no mesmo local e são diferenciados
pelo kernel do R/3. Na prática o R/3 implementa esta separação através de um campo
MANDT (de mandante, ou client em alemão) que participa da chave primária das
tabelas client dependents do R/3. Em qualquer chamada a estas tabelas o sistema
incorpora na clausula WHERE do SQL o campo MANDT = ‘nnn’
 Este campo que identifica um client é composto de 3 dígitos númericos. É portanto
importante que sempre que efetuamos um logon informemos o número do client. Este
campo é obrigatório na tela de login inicial do R/3, juntamente com a chave e a
password do usuário.
 Como os dados de clients diferentes funcionam no R/3 comro bases de dados diferentes
(separação por kernel), as empresas quando desejam implementar uma administração
corporizada de suas subsidiárias, o controle centralizado é possível através de uma outra

Basis – 2 Pag. 32
 facilidade que é o campo configurável denominado company code. Este campo define
a menor unidade administrativa com que os relatórios externos podem varrer para uma
visão centralizada.
 O conceito de authorities do R/3 sobre este campo company code permite ainda que
uma companhia matriz acesse as suas filiais com finalidades de consultas ou auditoria
impedindo que as diversas subordinadas tenham acesso aos dados uma da outra.
 É recomendado que um ambiente R/3 de uma empresa tenha no mínimo os seguintes
clients:
 Client CUST, como o ambiente central onde o desenvolvimento e as customizações
são efetuadas
 Client QTST, utilizado para o teste de novas customizações
 Client PROD, que é a produção da empresa

 Em um ambiente ideal, os seguintes clients adicionais são recomendados:

 Client SAND, que é um sandbox onde novas customizações são experimentadas
antes de efetivamente efetuadas no ambiente CUST
 Client TEST, para teste de customizações com massa de dados
 Client TRNG, como um ambiente de treinamento

R/3 Landscape
 O conceito de Landscape no R/3 refere-se a um grupo de sistemas R/3 compreendendo
normalmente um desenvolvimento, uma qualidade e uma produção que compartilham
change requests e rotas de transporte com o propósito de manter um sistema de
desenvolvimento e customização consistente.
 Por questões de segurança, é aconselhado proteger o sistema utilizando o conceito de
clients, implementando a segurança através do conceito de autorizações garantindo a
separação dos dados entre clients
 É aconselhável ainda separar fisicamente os ambientes de implementação do
desenvolvimento, qualidade e produção. Além das questões óbvias de segurança e
performance do ambiente produtivo, tal implementação protege o sistema evitando que
configurações client independents do ambiente de desenvolvimento sejam
implementadas na produção antes de um teste de validade.
 Uma implementação em dois ambientes também não é aconselhável porque todos os
objetos transportados para o ambiente de consolidação ficam imediatamente valendo do
ambiente de produção.
 A implementação mais recomendada pela SAP é um landscape de três ambientes que
implementam clients e rotas próprias de transporte, consistindo dos 3 clients básicos e
os 3 adicionais:
 Um host composto de três clients (SAND, TEST, CUST) onde fica o ambiente de
desenvolvimento
 Um host de quality assurance (com dois clients QTST e TRNG) onde os novos
desenvolvimentos são testados antes de serem migrados para o ambiente produtivo
 Um host para o ambiente de produção – com o client PROD

Basis – 2 Pag. 33
 Os sistemas R/3 que compõem um mesmo landscape devem possuir system IDs
diferentes para a correta identificação das rotas de transporte

Change Requests and Transports

 O sistema R/3 integra mais de 800 processos de negócio que precisam ser customizados
e configurados de acordo com as necessidades de cada empresa para atender e se
adequar ao seu ramo de negócio.
 Através de customizações e desenvolvimentos específicos o sistema R/3 é adaptado ao
processo de negócio da empresa e estas alterações precisam ser distribuídas entre todos
os clients que compõem o landscape da empresa, garantindo assim a consistência do
sistema
 Transporte é o processo no R/3 que permite a distribuição destas alterações ao longo do
landscape
 O R/3 fornece todas as ferramentas necessárias para a criação, documentação e
distribuição das alterações no landscape. A correta configuração do ambiente de
transporte é fundamental para o sucesso desta administração:
 Todas as alterações devem ser bem documentadas
 Um único client é recomendável para todas as customizações
 Todo o trabalho de desenvolvimento deverá ocorrer em um único sistema R/3,
garantindo uma origem única de todos os change requests
 Os desenvolvedores e customizadores deverão ter profiles de autorizações de acordo
com suas necessidades de criação e release de change requests
 O CTS (Change and Transport System) é uma facilidade introduzida pela SAP no
release 4.0 do R/3 e é composta das seguintesferramentas:
 O CTO, Change and Transport Organizer que provê funções para gerenciar o
desenvolvimento de projetos que ocorram centralizados ou distribuídos no ambiente
 O TMS, Transport Management System que organiza, monitora e executa os
transporte ao longo de um landscape definido. O TMS é utilizado ainda para as
rotas de transporte ao longo do landscape
 Ferramentas a nível do sistema operacional que executam a comunicação com o
sistema R/3, o banco de dados e os arquivos gerados no processo de export dos
transportes
 O CTO é composto das segintes ferramentas: Workbench organizer (transação SE09),
Customizing organizer (SE10) e Transport organizer (SE01)
 O TMS é gerenciado no R/3 através da transação STMS

Basis – 2 Pag. 34
Change and Transport System Prerequisites

Configuring the System Landscape

 Antes de iniciar a instalação de um sistema R/3, defina a estrutura de rede necessária
para comportar o ambiente.
 Inicie a instalação pelo ambiente de desenvolvimento. É nele normalmente que residirá
o Transport Management System. Durante a instalação do sistema defina um diretório
para o transport system. Este diretório será posteriormente compartilhado pelos demais
ambientes que comporão o landscape
 Após a instalação do R/3, configure o arquivo TPPARAM que parametriza o sistema de
transporte, inicialize o Change Transport Organizer (CTO) e configure o system
landscape utilizando o Transport Management System (transação STMS)
 As change requests que permitem sincronizar as customizações e desenvolvimentos
entre os sistemas R/3 fluem no landscape através de rotas pré definidas em um único
sentido. São as denominadas transport routes.
 O sistema de transporte utiliza um diretório próprio para onde os change requests
liberados são exportados da base de dados. Neste diretório o sistema armazena além de
data files, arquivos de comandos e logs de transporte.
 Fisicamente em um landscape de três sistemas, o transporte de um change request
ocorre em três etapas:
 Todos os objetos encapsulados em um change request que é liberado (released) são
exportados da base de dados do sistema fonte para o diretório de transporte
 Em um segundo passo, os objetos serão importados do diretório de transporte para a
base de dados do ambiente de quality assurance.
 Finalmente após o teste e verificação das alterações, os objetos são importados para
a base de dados do ambiente de produção (delivery system) definido
 O diretório de transporte (/usr/sap/trans) e todos os seus subdiretórios são exportados
pelo ambiente onde foi originalmente definido (normalmente o desenvolvimento) e
montado via NFS nos demais hosts dos sistemas que compõem o landscape. Este
compartilhamento de uma área única é pré requisito para o correto funcionamento do
sistema de transporte.
 O arquivo TPPARAM contém informações que parametrizam o funcionamento do
programa de transporte, o tp
 O TPPARAM reside no subdiretório bin do transport directory e deve ser configurado
após a primeira instalação a partir do arquivo template fornecido durante a instalação. A
cada novo sistema introduzido posteriormente no landscape, este arquivo precisa ser
editado para incorporar os parâmetros dbname e dbhost do novo ambiente.
 Para checar se o programa tp está disponível em todos os ambientes do landscape,
utilize o comando R/3 system -> Check -> Transport tool. É possível ainda testar todo o
diretório de transporte através do check de transport directory

Basis – 2 Pag. 35
 Para consultar os parâmetros definidos no arquivo TPPARAM, utilize o caminho de
menu Goto -> TP parameter

Initializing CTO
 A transação SE06 é utilizada para configurar o change and transport organizer. Ela
deve ser executada uma vez a cada nova instalação de um sistema R/3,
independentemente de ser uma instalação standard ou um database copy. Estas
configurações são globais no sistema R/3 e tem prioridade inclusive sobre as
configurações dos clients (SCC4)
 A transação SE06 estabelece o valor inicial para os change request e configura as
opções iniciais do sistema definindo se o repositório de objetos e os objetos de
customização client independents serão globalmente modificáveis.

The TMS, Transport Management System

 Através da transação STMS é possível definir as regras de transporte no landscape,
definindo assim a estratégia de transporte baseadas em rotas pré definidas.
 As rotas podem ser definidas de forma gráfica ou no editor hierárquico da STMS,
onde é possível ainda visualizar as filas de transporte e importar objetos.

Transport Domain
 Um transport domain compreende todos os sistemas R/3 administrados
centralizadamente através do TMS
 Quando se configura uma definição no TMS, o sistema cuida de distribuir via RFC a
definição entre todos os sistemas que compõem o domínio. Isto garante que as
configurações de transporte sejam consistentes em todos os sistemas
 O TMS suporta vários diretórios de transporte em um transport domain. Os sistemas
R/3 que compartilham um mesmo diretório compõem um transport group. Através do
TMS podemos executar transportes entre sistemas que pertençam a transport groups
distintos
 O landscape pode ser definido como todos os sistemas R/3 que compartilham
change requests com o propósito de manter ambientes consistentes de
desenvolvimento e customização. Por este motivo um system landscape normalmente
é sinônimo de um transport domain, embora um transport domain possa conter mais
de um system landscape apenas para fazer uso da vantagem de um ambiente TMS
centralizado
 A configuração do TMS é executada através da transação STMS no client 000 e com o
usuário DDIC e passa pelos seguintes passos:

Basis – 2 Pag. 36
  Configuração do transport domain através da especificação dos sistemas R/3 e dos
transport groups além da definição de um deles como sendo o controlador do
domínio.
 Configuração das rotas de transporte através da definição do sistema onde as
changes serão consolidadas e do sistema onde a change será finalmente delivered
após os testes
 Check e verificação das configurações através das ferramentas do TMS
 O sistema escolhido como controlador do domínio deverá ser um sistema com alto grau
de segurança e disponibilidade, normalmente o production system ou o QAS. Esta
tarefa não oferece nenhuma carga adicional ao sistema.
 A transação STMS irá criar um transport domain (DOMAIN_<SID>), um transport
group (GROUP_<SID>), um user CPIC no client 000 (user TMSADM), os destinos
RFC requeridos pelo TMS e um arquivo DOMAIN.CFG no subdiretório bin do
diretório de transporte que conterá a configuração do TMS.
 É recomendado que se tenha um servidor configurado como backup controller para o
TMS, em caso de falha do principal.
 Como e comum que no momento da configuração do TMS nem todos os sistemas
existam, o R/3 permite que se defina todo o ambiente através da especificação de
sistemas virtuais, permitindo com isto que se configure antecipadamente todas as rotas
de transporte.
 A SAP provê o TMS com configurações standard default que já prevêem rotas para
landscape de um, dois ou três sistemas, agilizando desta forma o trabalho de
configuração inicial
 As rotas de transporte são de dois tipos: de consolidação do desenvolvimento para o
sistema de quality assurance através de uma transporte layer (Z<SID>) e as rotas de
delivery onde os transportes consolidados são finalmente transportados do sistema de
qualidade para a produção
 Após configurar o transport domain e definir as rotas de transporte, o TMS é utilizado
para distribuir esta configuração entre os sistemas e ativar a nova configuração
 As alterações efetuadas em objetos SAP são transportadas através da consoludation
route SAP
 Através do hierarchical list editor é possível visualizar e editar a configuração do TMS.
O sistema aceita ainda a configuração através de ferramenta gráfica drag-and-drop
 O TMS provê ainda ferramentas para testar as conexões RFC, checar o diretório de
transporte e verificar o funcionamento do programa tp

Basis – 2 Pag. 37